Article

(View Disclaimer)

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 (http://www.novell.com/documentation/novellaccessmanager/adminguide/index.html?page=/documentation/novellaccessmanager/adminguide/data/b5n5bff.html). 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
   :04:20Z">
                        <saml:AuthnContext>
                           <saml:AuthnContextClassRef>
                            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
                           </saml:AuthnContextClassRef>
                           <saml:AuthnContextDeclRef>
                            secure/name/password/uri
                           </saml:AuthnContextDeclRef>
                        </saml:AuthnContext>
                     </saml:AuthnStatement>
                     <saml:AttributeStatement>
                        <saml:Attribute Name="ldapcncust" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" xmlns:xsd="http://www.w3.org/2001/XMLSc
   hema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                           <saml:AttributeValue type="xs:string">
                            XX
                           </saml:AttributeValue>
                        </saml:Attribute>
                        <saml:Attribute Name="ldapcn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" xmlns:xsd="http://www.w3.org/2001/XMLSchema
   " xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                           <saml:AttributeValue type="xs:string">
                            XX
                           </saml:AttributeValue>
                        </saml:Attribute>
                        <saml:Attribute Name="ldapcninf" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" xmlns:xsd="http://www.w3.org/2001/XMLSch
   ema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                           <saml:AttributeValue type="xs:string">
                            XX
                           </saml:AttributeValue>
                        </saml:Attribute>
                     </saml:AttributeStatement>
                  </saml:Assertion>
               </samlp:Response>
   
   

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.