000033795 - RSA Identity Management & Governance AuthRequest asking for a transient ID in SAML SSO integration

Document created by RSA Customer Support Employee on Jan 3, 2017Last modified by RSA Customer Support on Mar 1, 2018
Version 5Show Document
  • View in full screen mode

Article Content

Article Number000033795
Applies ToRSA Product Set: Identity Governance & Lifecycle
RSA Version/Condition: 7.0
IssueWhen implementing Security Assertion Markup Language (SAML) Single Sign On (SSO) integration in RSA Identity Management & Governance since the SAMLRequest is based on the SAML-2.0-NameID-Transient profile, the SAMLResponse will be transient with the random number in the NameID field which will never match the identity column value in T_Master_Enterprise_User Table, resulting in the failure of SSO.

The NameID format is as follows:
<saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
ResolutionTo resolve the issue, follow the steps below.
  1. Log into the RSA Identity Management & Governance User Interface.
  2. Navigate to Admin > System and click on the Authentication tab. 
  3. Select the SSO Authentication Source.
  4. Update the SAMLAuthenticatorClass value com.aveksa.server.authentication.SAMLPingAuthenticatorImpl. By default the value is set as com.aveksa.server.authentication.SAMLAuthenticatorImpl.
  5. Restart the application.
  6. After the restart, the SAMLRequest will be built on the correct profile and will create a SAMLResponse with the UnifiedUserColumn value into the NameID field.
Below is an example USER_ID using the configuration described above.  Note that the java class name is case sensitive.
User-added image
NotesSAMLPingAuthenticatorImpl class in the source code, has the function to generate the NameID policy based on 'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified' 

Please make sure that the Identity Provider (IdP) set by the customer in a nameid-format. RSA Identity Management & Governance code looks at that, parses the nameid and locates it in the T_Master_Enterprise_User Table. If the user is there (and not terminated or disabled), it returns as an authentication success.