Environment
Novell Access Manager 3.1 Linux Novell Identity Server
Novell Access Manager 3.1 Windows Novell Identity Server
Novell Access Manager 3.1 SUpport Pack 3 applied
Novell Access Manager 3.1 Windows Novell Identity Server
Novell Access Manager 3.1 SUpport Pack 3 applied
Situation
Access Manager setup and working fine. Administrator expanding the authentication types for users to include X509 based authentication with smart cards and personal certificates. New contracts were applied with these authentication classes and users confirmed that they could authenticate successfully. However, when trying to enable single sign on (SSO) to back end resources via the Access Gateway, users credentials were not being passed as expected.
The fact that the x509 based authentication (similar to Kerberos) does not use a password to identify users, it is not possible to retrieve user attributes for these authenticates users via LDAP (which requires the password for the LDAP bind operation). To overcome this, the PasswordFetch class is required. AFter configuring and enabling the passwordFetch class, all local users were able to SSO to the back end applications.
Remote users, authenticating to a 3rd party SAML2 Identity Server were not able to SSO. The passwordFetch class requires that the username is passed in the NameIdentifier section of the incoming assertion. The passwordFetch class retrieves this username and does a lookup to locate the full context where the user is located before searching for the password. If the NameIdentifier does not include unique user specific details, the lookup will fail. This is exactly the case with transient identifiers where a temporary ID is included in the assertion - and this ID is not anywhere to be found in the user store. This makes the passwordFetch class unuseable with transient identifiers.
The fact that the x509 based authentication (similar to Kerberos) does not use a password to identify users, it is not possible to retrieve user attributes for these authenticates users via LDAP (which requires the password for the LDAP bind operation). To overcome this, the PasswordFetch class is required. AFter configuring and enabling the passwordFetch class, all local users were able to SSO to the back end applications.
Remote users, authenticating to a 3rd party SAML2 Identity Server were not able to SSO. The passwordFetch class requires that the username is passed in the NameIdentifier section of the incoming assertion. The passwordFetch class retrieves this username and does a lookup to locate the full context where the user is located before searching for the password. If the NameIdentifier does not include unique user specific details, the lookup will fail. This is exactly the case with transient identifiers where a temporary ID is included in the assertion - and this ID is not anywhere to be found in the user store. This makes the passwordFetch class unuseable with transient identifiers.
Resolution
Apply SP4 and define the user matching criteria to locate a unique user based on attributes received in the assertion, rather than based on the NameIdentifier.
Look at the what's new section of the SP4 documentation to get all the details.
Look at the what's new section of the SP4 documentation to get all the details.