Environment
Novell Access Manager 3.1 Linux Access Gateway
Novell Access Manager 3.1 Linux Novell Identity Server acting as both a Liberty Identity provider and SAML2 service provider
3rd party SAML2 Identity server providing assertions
Novell Access Manager 3.1 SUpport Pack 3 applied
Novell Access Manager 3.1 Linux Novell Identity Server acting as both a Liberty Identity provider and SAML2 service provider
3rd party SAML2 Identity server providing assertions
Novell Access Manager 3.1 SUpport Pack 3 applied
Situation
Users accessing Linux Access Gateway protected resources where Identity Injection is used to provide single sign on to the web applications. Users authenticate to a remote 3rd party SAML2 Identity Server which sends the assertion to the Novell Identity Server acting as a SAML2 service provider. This Novell Identity Server is also acting as a Liberty Identity server and generates the assertion for the LAG ESP (Liberty Service Provider) for authentication purposes.
The SAML2 SP is defined in such a way that it executes a PasswordFetch class upon receiving the assertion. This allows the Access Manager host to retrieve the password of the user that we consume in the assertion details, and allows us to retrieve that users password. The goal of this process is to be then able to retrieve LDAP attributes for this user at the user store we are pointing to with the PasswordFetch class. These attributes can then be used to single sign on the user at back end accelerated web servers.
With the above setup, everything appeared to work correctly with the exception of one back end application. This application was never passed a valid email value in the LDAP mail attribute injected by it's identity injection policy. The attribute in the user store pointed to by the PasswordFetch class was defined correctly and an LDAP trace even showed the correct request/response from that LDAP server. Yet the Identity Injection profile would continue to inject a different value for the users email address.
The SAML2 SP is defined in such a way that it executes a PasswordFetch class upon receiving the assertion. This allows the Access Manager host to retrieve the password of the user that we consume in the assertion details, and allows us to retrieve that users password. The goal of this process is to be then able to retrieve LDAP attributes for this user at the user store we are pointing to with the PasswordFetch class. These attributes can then be used to single sign on the user at back end accelerated web servers.
With the above setup, everything appeared to work correctly with the exception of one back end application. This application was never passed a valid email value in the LDAP mail attribute injected by it's identity injection policy. The attribute in the user store pointed to by the PasswordFetch class was defined correctly and an LDAP trace even showed the correct request/response from that LDAP server. Yet the Identity Injection profile would continue to inject a different value for the users email address.
Resolution
Remove the attribute map enabled for the SAML2 Identity Server on the Access Manager SAML2 SP mapping one of the attributes sent by the SAML2 IDP server to the LDAP attribute mail.
By having the above mapping, we would immediately store that value in the local cache. Even though the Identity Injection policy evaluation would generate another LDAP mail attribute to the local user store pointed to by the PasswordFetch class, we would never overwrite what we had stored in the first place. By removing the above mapping, the LDAP mail attribute received in the assertion would never get cached and the subsequent LDAP mail request would be used.
By having the above mapping, we would immediately store that value in the local cache. Even though the Identity Injection policy evaluation would generate another LDAP mail attribute to the local user store pointed to by the PasswordFetch class, we would never overwrite what we had stored in the first place. By removing the above mapping, the LDAP mail attribute received in the assertion would never get cached and the subsequent LDAP mail request would be used.