Symantec Access Management

I have a requirement where I need to strip th employeeID ("ABC_123456") to just number (123456).

When I tried to use the expression AFTER in the nameID, it has errored out. well just thought I would give it a shot.

I have added a new row with an expression and value to be AFTER(employeeID,'-'). In the assertion , the value was the expression itself.

My version of siteminder is 12.5.2 SP01

The screenshot are shown as below from my SSO configuration and the FWTrace.

The Thread referred is https://communities.ca.com/thread/100045213

Thank you,

Sowmya

Thank You Sowmya sowmya.gadang

Is it R12.52 SP1 CR00 or any specific CRs?

Nevertheless, there could be multiple issues here, which can only be confirmed by looking at relevant places.

A. Expression does not work with Federation, a Federation code issue.

Check : SMTRACEDEFAULT log with Federation trace enabled on the CA SSO Profiler Tab.

B. A Data Definition Issue (e.g. see Support Case 00300147: Variables Request Context) hence the Federation Code does not understand Expression as an Expression Object, rather picks it as a Static attribute.

Check : Using XPSExplorer the Partnership object. The traverse through the submenu's into the Assertion Attributes. Then check if the Expression Assertion Attribute is linked correctly. Compare this with your working Expression Response which is working. Do you see any differences in the linked attributes of both Response Types (i.e. Working Expression Response and non Working Expression Assertion Attribute).

Based off this we could look at opening a CA Support Case if needed.

Regards

Hubert

Sowmya sowmya.gadang

I like what David suggested here SiteMinder's Certificate Mapping & Custom Mapping Expression

1. Build a named expression.
   1. #IDNumOnly
   2. Use the expression: AFTER(EmployeeID,'-')
2. Create an attribute mapping on the user directory
   1. IDNumOnly
   2. Selection expression:  The definition should reference the Named Expression: #IDNumOnly
3. Use IDNumOnly as the name of the attribute to send.

OR

1. Create an attribute mapping on the user directory
   1. IDNumOnly
   2. Selection expression:
   3. Paste the expression in Definition Section : AFTER(EmployeeID,'-')
2. Use IDNumOnly as the name of the attribute in NAMEID.

Try this and see if it works. Nevertheless the one using Assertion Attributes should also work, unless there is a fundamental bug.

Regards

Hubert

HI Hubert and David,

Yes!!! That worked. I was able to add the Attribute in the user Directory and mapped it to the NameID and it worked.

Thank you so much for your assistance.

thanks again,

Sowmya

It appears the expression is not being executed at the policy server side. May be the policy server is missing some federation related objects. Did you import ampolicy.xml and fedpolicy-12.5.xml during policy server setup?

Does the employee ID has a underscore _ or hyphen - ? From your example it appears the employeeID has _ but your expression has - in it.

Thanks Saravanan! I wasnt able to resolve my issue by adding the attribute to the attributelist in the user Directory.

Thanks,

Sowmya

Sowmya

Glad you could get it working one way.

However I am still thinking why it did not work when you used Expression within Attribute Assertion in a Federation Partnership. May be something we need to check on our end (within CA).

Regards

Hubert

I finally had the opportunity to test this on a federation partnership. It looks like this EXPRESSION within FEDERATION PARTNERSHIP is broken. My Policy Server version is R12.52 SP1 CR02 GA Build 766. Would raise a defect as I get some space.

[SAMLSPEntitlementGenerator.java][processExpressionEvaluation][][ Expression configured: juel:Get('uid') + '@abc.com'][][][][][][][][][][][][][][][][][][][][

[SAMLSPEntitlementGenerator.java][processExpressionEvaluation][][Expression before evaluation: Get('uid') + '@abc.com'][][][][][][][][][][][][][][][][][][][]

[SAMLSPEntitlementGenerator.java][processExpressionEvaluation][][Return value: Get('uid') + '@abc.com'][][][][][][][][][][][][][][][][][][][][][][][][]

[SAMLSPEntitlementGenerator.java][generateValue][][Entitlement: NameAttrFormat = unspecified, Encrypt = false, Mode = User, ExpressionAppend = NOT PRINTABLE]

.

.

.

<ns2:Attribute Name="ExpressionAppend" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

                <ns2:AttributeValue>Get('uid') + '@abc.com'</ns2:AttributeValue>

            </ns2:Attribute>

        </ns2:AttributeStatement>

    </ns2:Assertion>

SAMLSPEntitlementGenerator.java simple processes the Expression as a STRING and passes it into the Assertion as a STRING as is (without processing it).

The workaround is anyways is provided here.

Is this issue resolved?  I am 12.7 SP1 and experiencing the same behavior.   My need is to remove an apostrophe from surname.  I do understand the workaround of creating a attribute mapping.  My preference would be to use TRANSLATE  right on the assertion attribute.  (SN2 in the example)  

The assertion:

<ns2:Attribute Name="sn2"                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"                >     <ns2:AttributeValue>TRANSLATE(sn,&quot;&apos;","")</ns2:AttributeValue> </ns2:Attribute> <ns2:Attribute Name="sn3"                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"               >     <ns2:AttributeValue>AFTER(sn,&apos;i')</ns2:AttributeValue> </ns2:Attribute>

And the log:

[01/26/2018][15:53:14.601][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][processExpressionEvaluation][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][ Expression configured: juel:TRANSLATE(sn,"'","")]
[01/26/2018][15:53:14.601][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][processExpressionEvaluation][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][Expression before evaluation: TRANSLATE(sn,"'","")]
[01/26/2018][15:53:14.603][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][processExpressionEvaluation][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][Return value: TRANSLATE(sn,"'","")]
[01/26/2018][15:53:14.603][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][generateValue][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][Entitlement: NameAttrFormat = unspecified, Encrypt = false, Mode = User, sn2 = NOT PRINTABLE]

[01/26/2018][15:53:14.603][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][processExpressionEvaluation][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][ Expression configured: juel:AFTER(sn,'i')]
[01/26/2018][15:53:14.603][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][processExpressionEvaluation][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][Expression before evaluation: AFTER(sn,'i')]
[01/26/2018][15:53:14.606][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][processExpressionEvaluation][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][Return value: AFTER(sn,'i')]
[01/26/2018][15:53:14.606][15:53:14][20634][140647541495552][SAMLSPEntitlementGenerator.java][generateValue][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][Entitlement: NameAttrFormat = unspecified, Encrypt = false, Mode = User, sn3 = NOT PRINTABLE]
[01/26/2018][15:53:14.606][15:53:14][20634][140647541495552][AuthnRequestProtocol.java][generateAttributeStatement][4b19e51b-cb619b84-5665aae2-8df4a5f6-57532f5c-43][][][][][][][][][][][][][][][][][][][][Generating SAML Assertion AttributeStatement...]

Please advise.

dfsdk

I haven't had the opportunity / space to raise an Internal defect. But it seems like you are seeing the same behaviour in R12.7 SP1 with expression within a partnership. Best to raise a defect via CA Support and request for a fix from Engg. The workaround is always present, but that is not an excuse to leave this broken always.

Regards

Hubert

Hi Hubert,

We have checked internally and this is intended behavior. The help docs on the Assertion Configuration screen state the following for Assertion Attributes:

Assertion Attributes (SAML 2.0 IdP) 

Expression

Enter a string using the Java Unified Expression Language to transform, add, or delete an of attribute assertion. For more information about claims transformation and expression strings, see the CA SiteMinder Federation: Partnership Federation Guide.

Value: Specify a JUEL expression.

The Expression type for Assertion Attributes are specifically for JUEL expressions, and Siteminder functions not shared with JUEL expressions are incompatible.

Thank You Edward cheed02 for confirming.

The EXPRESSION in Partnership is really the result of FEDMGR being merged into CA SSO as Partnership Model. JUEL EXPRESSIONs were part of the FEDMGR build.

The fundamental problem is we call it EXPRESSION in Response in Policy Domain or Attribute Mapping in UD AND we call it EXPRESSION in Attributes within PARTNERSHIP. Where as both EXPRESSIONS are NOT the same and have nothing in common. This is enough to create confusion in the field.

The documentation talks in detail about standard CA SSO expressions i.e. https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/policy-server-configuration/attributes-and-expressions-reference

But there is no detailed documentation in the CA SSO space for JUEL, other than a few tiny examples. What functions are available, What operators are available, nothing of such detail is mentioned. https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/partnership-federation/assertion-configuration-at-the-asserting-party/how-to-configure-claims-transformation-at-the-asserting-party. It is a straight rip-off from FEDMGR documentation, just as the feature itself. https://support.ca.com/cadocs/0/CA%20SiteMinder%20Federation%20Standalone%2012%2052-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?claims-transformation.html

Over a period of time we should be consolidating things, not diversifying, to be sustainable. There are solutions where we need to diversify to be successful + sustainable. There are solutions where we need to consolidate / cut-down to be successful + sustainable. It works both ways.

I see larger benefit of standardizing EXPRESSIONs (Standard CA SSO Expressions, than JUEL) across all facets of the product than trying different things in different spaces (especially when JUEL is used only within Partnership, no where else).

For now I think in the field most of us make Expression work using Attribute Mapping in UD, as that part of the documentation is more complete.

Lastly I can raise an idea for Product Management to review, consolidating expressions within Partnership. I'll let someone else do the honors for raising the idea.

Regards

Hubert

Unfortunately, most of what our documentation states about using JUEL, is that it requires the user to be familiar with EL, and doesn't go a whole lot in more detail other than that, and leaves it as an exercise to the reader.

For reference, this may be a useful cheat sheet for EL if customers wish to use the Expression route:

Unified Expression Language - The Java EE 5 Tutorial 

That being said, looking through it, I wasn't able to find any great string manipulation functions with JUEL, so unless the attribute in question is pulling straight from existing attributes, or doing math, using Attribute Mapping would be our best option until this is expanded upon.

 that's exactly the point (What is the VALUE of that JUEL expression). You summarized it perfect on point (Likes!). I'd never want JUEL expanded upon. Just adopt one single strategy, across the board. Replace JUEL expression with Standard expression in Partnership and be done with it.