Environment
Novell Access Manager 3.1 Linux Novell Identity Server
Novell Access Manager 3.1 Windows Novell Identity Server
Situation
Customer wished to do single sign on (SSO) with a vendor that is using a Shibboleth service provider. The vendor indicated that they implement the InCommon federation attributes (http://www.incommon.org/attributesummary.html) and require that the user’s eduPersonPrincipalName be included within the SAML assertion’s attribute statement. The vendor requested a service provider (SP) initiated SSO configuration using the POST method. The vendor’s software configuration was as follows:
Shibboleth SP: 2.4.3
Xerces-C: 3.1.0
XML-Security-C: 1.5.1
OpenSAML-C: 2.4.3
This was running on Ubuntu 10.04LTS x86_64.
A SAML 2.0 SP configuration was added to the Access Manager Identity Server for this application. A shared attribute configuration was setup to pass the user’s email address as the eduPersonPrincipalName (this was also used as the remote attribute name in the mapping).
Upon initial testing, SSO failed. In addition, the Shibboleth SP crashed upon each attempt. Apparently, when the SP did not see the attribute it required (the eduPersonPrincipalName) in the SAML assertion, it issued a SOAP request to the Access Manager IdP for it. Access Manager returned an error the SP did not know how to parse and crashed.
Shibboleth SP: 2.4.3
Xerces-C: 3.1.0
XML-Security-C: 1.5.1
OpenSAML-C: 2.4.3
This was running on Ubuntu 10.04LTS x86_64.
A SAML 2.0 SP configuration was added to the Access Manager Identity Server for this application. A shared attribute configuration was setup to pass the user’s email address as the eduPersonPrincipalName (this was also used as the remote attribute name in the mapping).
Upon initial testing, SSO failed. In addition, the Shibboleth SP crashed upon each attempt. Apparently, when the SP did not see the attribute it required (the eduPersonPrincipalName) in the SAML assertion, it issued a SOAP request to the Access Manager IdP for it. Access Manager returned an error the SP did not know how to parse and crashed.
Resolution
The SP crash was rectified by upgrading the vendor’s Xerces library to version 3.1.1. However, the SP was still not able to identify the eduPersonPrincipalName.
The Shibboleth SP was actually looking for the attribute’s formal name as defined by the MACE-Dir SAML Attribute Profiles ( http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf ). This requires that the name be an object identifier or OID, NOT the short or “friendly†name (i.e. eduPersonPrincipalName). The attribute mapping was changed to use the OID value for eduPersonPrincipalName: urn:oid:1.3.6.1.4.1.5923.1.1.1.6. This is shown in the add attribute mapping dialog below.
The name format was also required to bet set to “uri.†This resulted in an attribute statement as follows:
<saml:AttributeStatement><saml:Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance Name="urn:oid
:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xsd:string">**</saml:AttributeValue></saml:Attribute></saml:AttributeStatement>
The SP was able to understand this attribute statement that in turn allowed the user to access the application.
The Shibboleth SP was actually looking for the attribute’s formal name as defined by the MACE-Dir SAML Attribute Profiles ( http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf ). This requires that the name be an object identifier or OID, NOT the short or “friendly†name (i.e. eduPersonPrincipalName). The attribute mapping was changed to use the OID value for eduPersonPrincipalName: urn:oid:1.3.6.1.4.1.5923.1.1.1.6. This is shown in the add attribute mapping dialog below.
The name format was also required to bet set to “uri.†This resulted in an attribute statement as follows:
<saml:AttributeStatement><saml:Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance Name="urn:oid
:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue xsi:type="xsd:string">**</saml:AttributeValue></saml:Attribute></saml:AttributeStatement>
The SP was able to understand this attribute statement that in turn allowed the user to access the application.
Additional Information
Credit to Matt Weisberg (Weisberg Consulting, Inc) for the information.