Recently, when setting up a SAML2 relationship between a Novell Identity (IDP) Server, and a remote SAML2 Service Provider (SP), I needed to send a list of user attributes within a SAML assertion from the IDP server to the SP. Two of the attributes that I was adding to the attribute set were of the same LDAP type (it was the users cn attribute). This cn attribute was to be mapped to two different remote attribute names, that would be sent with the SAML assertion.

The problem started when the Administration Console interface would not allow me to specify the required cn attribute twice within the attribute set. When defining the attribute set on the IDP server configuration, if a local attribute name is used once in that set, it is not available for selection again within that set. As the remote attribute mapped is the one that we send within the assertion, there is no reason for this limitation.

A workaround to the problem can be easily implemented using the LDAP Data mapping feature available on the Identity Server ( Using this feature, we can try and map the attribute we want to select twice in the SAML attribute set to another attribute name. Once done, we can go back to the SAML attribute set and select the original attribute name, and the one we just remapped. To do this, simply follow the steps below:

  1. Enable the custom profile under Liberty -> Web Services Provider -> Custom Profile TAB

  2. Make sure that the “Data Location Settings” use “LDAP Data Maps”. The default is to read/write from the “Configuration database” data location. I just moved the “LDAP Data Maps” to the top (but you can also removed “Configuration DataStore” from the read and write Data Location lists if you want).

    Click to view.

  3. Go to the LDAP attribute map settings under Liberty -> LDAP attribute mapping TAB and modify the “Default One-To-One Ldap Attribute Mapping” option

  4. Decide what attribute you want to remap to the LDAP attribute and modify the access rights to be read/write. The attached screenshot shows me mapping the Liberty Personal Profile ‘Informal Name’ attribute to be that of the LDAP CN.

    Click to view.

    Another option would be to map the custom profile strings to the LDAP CN as shown below:

    Click to view.

  5. Update the IDP server and make sure that all is ok.

  6. Login to the IDP portal page and view the profile info for the user. Make sure that the customisation string 1 (in above example) or Informal name actually includes the users CN.

    Click to view.

  7. Assuming all is ok at this stage, we now need to define the list of SAML attributes we want to send at Authentication time. This list will include the LDAP CN attribute as well as the Customisation string 1 or Informal name.

    Click to view.

  8. Assign these attributes to the SAML Service Provider and make sure that they get ‘sent with Authentication’

    Click to view.

  9. Login to the SAML service Provider via the SAML Identity Server and make sure that the AttributeStatement includes the values we expect:

    // snippet from catalina.out file on SAML Identity Server with Assertion details ...
                      <saml:AuthnStatement AuthnInstant="2008-11-06T11:49:17Z" SessionIndex="083C64AD20954878FC873AEB678F41FB" SessionNotOnOrAfter="2008-11-06T12
                         <saml:Attribute Name="ldapcncust" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" xmlns:xsd="
    hema" xmlns:xsi="">
                            <saml:AttributeValue type="xs:string">
                         <saml:Attribute Name="ldapcn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" xmlns:xsd="
    " xmlns:xsi="">
                            <saml:AttributeValue type="xs:string">
                         <saml:Attribute Name="ldapcninf" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" xmlns:xsd="
    ema" xmlns:xsi="">
                            <saml:AttributeValue type="xs:string">
0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
By: ncashell
Dec 22, 2008
2:14 pm
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow