SAML assertion mapping to local user

This topic has 17 replies, 7 voices, and was last updated 5 years, 6 months ago by jasoninmel.

  • Author
  • #7775


    I have a simple set up of SAML federation using one OpenAM server as SP and other one as IDP

    Through on my webpage I am redirecting user to authenticate through IDP.

    IDP sends the SAML assertion to SP

    I want to know what is the order through which SP OpenAM maps the incoming assertion with the local user.
    On the Assertion Processing tab of SP OpenAM Console I do find the Attribute Mapper, Auto Federation and Account Mapper, but I am not sure how the mapping is performed.

    I appreciate your help.


     Rajesh R

    @chirag501 The Attributes Mapping section is where you map the attributes from IDP with the attributes in SP. So if I define a mapping that says x=y, ‘x’ being an attribute in IDP and ‘y’ in SP, the value of ‘x’ from IDP is mapped to the value of ‘y’ in SP. In the case, where you are using ForgeRock OpenAM as both IDP and SP, the user profile may have the same attribute names, meaning the attribute ‘uid’ in IDP is mapped to attribute ‘uid’ in SP.

    If you enable ‘Auto Federation’ while configuring Federation, we can provision Users in SP using the attributes coming from IDP. For this the other change required is to enable ‘Dynamic User Profile Creation’ at SP.

    If you’ve some time to spare,let me give a link to one of the screen-casts around configuring Federation in OpenAM 13.

    The above screen-cast demonstrates how a user is provisioned in SP using the attributes of a User in IDP. This might give a more clearer understanding, but I’m sure there are many more things to explore when it comes to Federation

     Javed Shah

    What Rajesh said.. Plus, the general flow w.r.t attribute mapping would be roughly-
    1. A user attempts to login at SP and is redirected to the IDP, or as in your case starts at the IDP
    2. User authenticates to IDP, and is redirected using to the SP
    3. SAML response sent to SP contains AttributeStatement
    4. OpenAM parses the SAML assertion and populates session with all attributes received in SAML assertion AttributeStatements
    If a custom attribute mapper is defined at the SP, then the custom mapper is used by SPACSUtils before the attributes are pushed into the Session. I don’t think it is relevant here but is just FYI. Typically, you would use the custom SAML2ServiceProviderAdapter if you wanted to alter the session in some way immediately after SPACSUtils created it. SPACSUtils calls the custom SP adapter. Note that
    com.sun.identity.saml2.profile.SPACSUtils takes care of adding the attributes from AttributeStatement into the session (SPACSUtils calls the attribute mapper first but until then the SP session is not present): setAttrMapInSession(sessionProvider, attrMap, session). If you enable debug level tracing for Federation, you should see messages of the type: SPACSUtils.setAttrMapInSession: AttrMap


    Thanks Javed and Rajesh. Appreciate your response as I was studying it.

    1. Let’s say I am doing Auto-federation. There is no confusion as such.
    SP-OpenAM will search the attribute in the saml-assertion whose name is matching with Auto Federation config on SP-side.
    SP-OpenAM will take the value of above attribute from assertion and find out the local user from the datastore.
    (of course we can Dynamically create account also on SP site as Rajesh explained)

    2. If we have turned off auto-federation, let’s say I am doing transient-federation.
    Transient-federation does NOT mean that you have to Map all Remote Accounts to a Single Service Provider Account.
    Instead of mapping with a single user, SP can challenge user and then federate to that particular user.

    If you are Mapping all Remote Accounts to a Single Service Provider Account, then in this case of Transient fed.
    I would like to know what is the purpose of sending Attributes in the SAML-assertion.
    Because putting this attributes into SSO session is of no use. Am I correct ?

    3. If you do not do Auto-federation, if you do not do transient-federation or persistent-federation, then I guess finally the SP-OpenAM will try to Use value of Subject/Name ID from the incoming Assertion to find the local user as the final resort.

    Am I correct in the order OR is there something more in mapping that I am missing.


     Rajesh R

    @css What you said about enabling the ‘Auto Federation’ option is correct. Once a User is authenticated against an IDP, the User’s profile in SP is identified by using an attribute that you’ve mentioned (say ‘uid’), and if a User is not found in SP, it will provision that User (If Dynamic Profile Creation option is enabled).

    There are situations where the same user may have different values for their attributes in IDP and SP. Let’s take example of uid itself. A user may have ‘idpuser.0’ as uid in IDP and ‘spuser.0’ as uid in SP. This is when we decide not to opt for Auto Federation (because we can’t identify the SP User with an attribute value from IDP), instead ask the User to first authenticate against IDP, and on successful authentication redirect to SP for a second level of authentication. Now when the User supplies his/her credential in SP, a link between the User’s account in IDP and SP is established, meaning from then onwards the User is expected to only authenticate with IDP.

    Transient Federation is used in situations when the SP doesn’t have or want to store the User’s profile. So all Authenticated Users from IDP is mapped to a User in SP (many to one mapping), which by default happens to be ‘anonymous’ user. But it could a User that you specify the Federation Configuration. If you’ve time and would like to see Transient Federation is action, I do have a video tutorial on the same:

    Hope you’ve got a bit more clear picture on this.


    Thanks Rajesh for your response as I am studying it. Their is a slight disconnect but let me look into it first.



    I am currently facing some issues with my SAML configuration and I would appreciate any kind of support or hints.

    Following starting point:

    I configured OpenAM (13.5.0) as a SP and an ADFS3 as IdP.

    My aim is that the user authenticates with SAML and get stored to my database (OpenDJ) after successful authentication.

    Actually my situation is that the SP initiates the authentication request and a response is coming back from the IdP and I am facing with a “HTTP Status 500 – Single Sign On failed”

    Following configurations are done:

    AuthenticationSettings  User Profile: Dynamic  Alias Attribute Search name: UID

    Following were created:

    Module 1 – LDAP with an OpenDJ

    Module 2 – SAML

    Chain 1 contains an SAML module and the “Linking authentication chain” is a chain 2 and Chain 2 contains the LDAPmodule

    Following “NameID Format” were agreed by the ADFS Team  „urn:oasis:names:tc:SAML:2.0:nameid-format:persistent“

    In the Federation Tab I configured the Entities as well as a CoT

    Following setting were also done: Global  Configure  Authentication  Realm Authentication Defaults “Core Attributes”  User Profile: Dynamic: Alias Attribute Search name: UID

    Test 1: I invoked the authentication chain from a client pc and I got a HTTP Status 500 – Single Sign On failed.

    I placed an extract from the log at the end…

    Test 2: If I create the AD account manually – SSO succeeds.

    Test 3: If I set up the user profile to „ignored“ – SSO succeeds

    Anyway “Test 1” is desired where the users are created on the first time to the database dynamically

    The <AuthResponse> from the AD contains following information: NameID as well as following AttributeStatements: „pnr“, „givenname“, „name“, „emailaddress“

    I mapped these in the LDAP module as follows: uid|NameID sn|name mail|mailadress givenName|givenname employeeNumber|pnr

    Where else do I have to map the attributes and how? Did I missed any settings?

    I appreciate any kind of support and or hints.

    Best regards,

    Federation Log extract:

    libSAML2:11/24/2016 06:33:02:747 PM MEZ: Thread[http-nio-80-exec-6,5,main]: TransactionId[789fc740-325b-4bc2-805c-0027e0dad637-13211]
    ERROR: spAssertionConsumer.jsp: SSO failed.
    com.sun.identity.saml2.common.SAML2Exception: Login failed with unknown reason.
    at com.sun.identity.saml2.profile.SPACSUtils.processResponse(
    at org.apache.jsp.saml2.jsp.spAssertionConsumer_jsp._jspService(
    at org.apache.jasper.runtime.HttpJspBase.service(
    at javax.servlet.http.HttpServlet.service(
    at org.apache.jasper.servlet.JspServletWrapper.service(
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(
    at org.apache.jasper.servlet.JspServlet.service(
    at javax.servlet.http.HttpServlet.service(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.forgerock.openam.validation.ResponseValidationFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at com.sun.identity.setup.AMSetupFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.forgerock.openam.audit.context.AuditContextFilter.doFilter(
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(
    at org.apache.catalina.core.StandardWrapperValve.invoke(
    at org.apache.catalina.core.StandardContextValve.invoke(
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
    at org.apache.catalina.core.StandardHostValve.invoke(
    at org.apache.catalina.valves.ErrorReportValve.invoke(
    at org.apache.catalina.valves.AbstractAccessLogValve.invoke(
    at org.apache.catalina.core.StandardEngineValve.invoke(
    at org.apache.catalina.connector.CoyoteAdapter.service(
    at org.apache.coyote.http11.Http11Processor.service(
    at org.apache.coyote.AbstractProcessorLight.process(
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$ Source)
    at org.apache.tomcat.util.threads.TaskThread$
    at Source)
    Caused by: com.sun.identity.plugin.session.SessionException: Login failed with unknown reason.
    at com.sun.identity.plugin.session.impl.FMSessionProvider.createSession(
    at com.sun.identity.saml2.profile.SPACSUtils.processResponse(
    … 38 more

    libSAML:11/24/2016 06:33:02:747 PM MEZ: Thread[http-nio-80-exec-6,5,main]: TransactionId[789fc740-325b-4bc2-805c-0027e0dad637-13211]
    SAMLUtils.sendError: error page/saml2/jsp/saml2error.jsp

    Best regards,
    Yathursan Theva


    Hi there,

    I’m using OpenAM as SP and I have use email as the user ID (email). However I recently encountered an issue where duplicate multiple UIDs are been created for the same user ID (email). As a result of this these users are now unable to login using SP. Error stack trace is as follows;

    libSAML2:03/03/2017 03:24:53:758 PM EST: Thread[http-apr-8082-exec-22,5,main]
    ERROR: TestSPAccountMapper.getIdentity(Assertion): DataStoreProviderException
    com.sun.identity.plugin.datastore.DataStoreProviderException: Multiple matching users found.
    at com.sun.identity.plugin.datastore.impl.IdRepoDataStoreProvider.getUserID(
    at com.Test.identity.saml2.plugins.TestSPAccountMapper.getIdentity(
    at com.sun.identity.saml2.profile.SPACSUtils.processResponse(

    Could you please let me know how to fix this?


    • This reply was modified 5 years, 6 months ago by jasoninmel.
     Peter Major

    Just a wild guess, but maybe your custom TestSPAccountMapper is at fault?


    Hi Peter,

    The issue happens only for few users and few times. Looking at the UID creation time in LDAP I can see the duplicates are been created within a few seconds apart (or some occasions at the same time accurate to the second) I recently restarted Tomcat which has made the problem to disappear. Would it be possible a bug in OpenAM make multiple calls to Account Mapper?

    • This reply was modified 5 years, 6 months ago by jasoninmel.
     Peter Major

    The account mappers are only invoked once for each assertion (and having it called multiple times wouldn’t result in having the same account multiple times in the directory).
    Are you using dynamic user profile mode? Do you have more than one user data store configured?


    There is only one data store configured but running on a LDAP cluster consist of 4 LDAP servers behind a load balancer. All of them are running on multi-master replication. Just to clarify what I meant by duplicate, it is the same email (user id) with multiple UUIDs. In the account mapper the UUID is generated using following code snippet;

    String uid = UUID.randomUUID().toString();

    However the search for user is retriving the user ID as follows;

    IF assertion.getSubject().getNameID().getFormat() = SAML2Constants.NAMEID_TRANSIENT_FORMAT
    Search user in LDAP using hostEntityID IF found return user ID.
    ELSE IF auto federation enabled

    Not sure if this makes any seance but thought of including it to see if there is any clue in it.

    We have enabled auto-fed and User’s profile attribute is set to email.

     Peter Major

    Are those multiple matches essentially replication conflicts, or do you just have lots of entries with different UUID and the same e-mail account?

    Do you always create a new user in case auto federation enabled, or are you at least attempting to find an existing entry with the same e-mail address before creating the new account?


    I’m not sure if they are conflicts. Most of them have started having multiple UUIDs in LDAP against the same email. Logic ensure the it checks if the email already exist before creating a new entry with a new UUID. Let me check if they are conflicts and provide an update.

    • This reply was modified 5 years, 6 months ago by jasoninmel.

    I had a look at LDAP records belong to a single user with this particular issue. However the LDAP did not show having replication conflicts those records. Also ran a full search for records with conflicts and did not show a single record. Therefore LDAP is in good condition.

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?