Symantec Access Management

 View Only
  • 1.  Case of Name ID in assertion

    Posted Mar 03, 2015 05:53 PM



    I have a service provider who uses the name ID parameter to identify the user on their end.


    unfortunately, the name ID on their end is case sensitive.


    Is there any way in the partnership when I mention the name id, to have siteminder do a upper or a lower to the value out of the box?




  • 2.  Re: Case of Name ID in assertion

    Posted Mar 06, 2015 12:52 PM

    I don't know a way to do that with a partnership...But really the SP side needs to fix themselves rather than IdP having to do whacky things like upper/lower case certain pieces IMO.


    Out of curiosity what type of situation is it? Do they use like but IdP is sending ?

  • 3.  Re: Case of Name ID in assertion

    Posted Mar 06, 2015 05:56 PM

    Absolutely Agree.


    Anand anand3g


    SAML has standard and specification. It is like me conversing with you in English; If I spell incorrect or using improper grammar; then I am wrong.





    So the "NameID" has to be in this format. One cannot use NAMEID or nameid.


    I would request to work with Service Provider and make sure we follow SAML specifications.


    CA Single Sign On does not have any options to modify the Case sensitivity of SAML specification values.






  • 4.  Re: Case of Name ID in assertion

    Posted Mar 12, 2015 03:53 PM

    Before me are two very different takes on what you said.

    Would it be possible for you to elaborate and give some examples?

  • 5.  Re: Case of Name ID in assertion

    Posted Mar 12, 2015 07:43 PM

    @Hubert. Thank you. But the Specification isn't the issue. The value of the Name ID parameter, that is case sensitive on the SP end. not the case in the XML tag.


    @CBertagnolli That's the exact issue. Bur reverse. IDP is sending ARao. But SP accepts only arao.


    I'm wondering if I'll have to write a assertion generator plugin and push it to lower case there. I have another SP, who appends the org name at the end so they expect the value as ARao@CA or ARao@ORACLE. Right now I'm doing a ugly solution to store a value in this format in the user directory and retrieving that.

  • 6.  Re: Case of Name ID in assertion

    Posted Mar 13, 2015 10:55 AM

    Thank You Anand anand3g


    Could you tell me what is you User Directory Version / Type?



    There may be a possible solution instead of having to write a MCP. I haven't tried this I would request you to try.


    NOTE : You would need to create a one OR two named expression depending on your logic.

    One of the Named Expression has to be (cn ~CONTAINS %s).

    ~CONTAINS does a case insensitve check.


    1. Modify your User Directory Object.
    2. Create a Virtual Attribute Mapping e.g. NameCheck.
    3. Select Expression. Associate the Named Expression. Make sure the Expression returns a True or False (boolean).
    4. Now in your SAML Partnership in the User Search criteria instead of cn=%s; use NameCheck=%s.



    Try this and let know.






  • 7.  Re: Case of Name ID in assertion

    Posted Mar 13, 2015 11:25 AM

    On the org name issue, can the SP use an assertion attribute instead? It's pretty easy to append attributes together or add static text using the expression option instead of "user attribute". Never done that for a nameid unfortunately; maybe someone else knows how or named expression could work here too like H. mentioned of the case...? Anyhow, using the assertion attributes instead of nameid is pretty straight forward to use the expressions for situations like that.


    For example, I have 2x users: (1) uid=myuser and orgCode=companyA and (2) uid=otheruser and orgCode=companyB . The SP wants USER attribute to return the uid@orgcode


    I would set the assertion attribute to "expression" and add "USER = #{attr["uid"]}@#{attr[“orgCode”]} ".


    The response for user 1 (myuser) would return myuser@compnayA and response for user 2 (otheruser) would return otheruser@companyB



    Or you can also use static text if the org code isn't defined in your directory but known value between IdP and SP.


    E.g.,  #{attr["uid"]}@SomeCompany  which would return myuser@SomeCompany and otheruser@SomeCompany



    Lots of flexibility with the assertion attributes to modify with expressions. Same if you had to add an attribute if it's between X-Y values but delete if it's not. So if you're following something like the TSCP SAML Profile and need to return IPVLevel; Say the IdP has an attribute called userIdentityLevel that has a range from 10-20 - any user within that range equals the TSCP profile for IPVLevel2 so I need to return that for these users could do something like:

   =  #{((attr["userIdentityLevel"] >= '10') && (attr["userIdentityLevel"] < '20')) ? 'urn:tscp:IPVLevel:2' : 'DELETE' }


    If the user meets that criteria it will return the attribute"" with a value of "urn:tscp:IPVLevel:2" . If the user does not meet the criteria then the assertion is removed.

  • 8.  Re: Case of Name ID in assertion
    Best Answer

    Posted Jul 09, 2016 02:56 PM



    We can do this quite easy using Expression.


    However you have to do this using a workaround since Federation Partnership Expressions don't work. So the hack is to do it via the Attribute Mapping in User Directory Object.

    How to format a nameID value in the assertion configuration for a federation partnership



    Try this Expression, it would work.