Identity Server acting as SAML 2.0 SP is not provisioning user correctly if the user store contains multiple replicas

  • 7022123
  • 18-Oct-2017
  • 07-Nov-2017


Access Manager 4.2
Access Manager 4.3


Access Manager 4.2.4 setup as a SAML 2.0 service provider (SP), where users login at a remote SAML 2.0 Identity (IDP) Provider. When the users authenticate successfully at the remote IDP server, an assertion is sent to the SP which we consume and try and identify a local user based on user matching settings. If not local user exists, we will attempt to provision based on the provisioning configuration. This works well in most cases where the user is provisioned in the local user store, with the attributes received in the assertion, but on occasions users are simply provisioned but without the attribute values expected ie. they are missing the attributes that were received in the assertion.
The local user store had 4 LDAP servers defined - when we reduced this to one, we never saw the issue. It looks like we may have an issue with persistence to the back end LDAP servers when provisoning the user, and adding the LDAP attributes to that user. These are typically two seperate LDAP operations, and maybe going to two different LDAP servers that do not have time to sync up between them.
The exact use case we had was the following:
1. NAM is Service provider and Shibboleth is Identity Provider
2. NAM sends a SAML Authentication request to Shibboleth.
3. User login to Shibboleth using user ID user1 and authenticates successfully
4. Shibboleth sends SAML Assertion with user infomartion.
5. User matching criteria fails and Provisioning part of user starts
6. User is created in the user store.
7. Only User is created in the user store but its attributes are not updated with the attribute values from Assertion.


Apply NAM 4.2.5 or NAM 4.3.3 (and 4.4.0). The fix was to verify the LDAP stickiness code was added to the Provision Profile.