I am configuring a new installation of AM using CDM. I have all the authentication working fine using the usenrmae attribute but I need to be able to support both userName or mail for the login attribute. Is there a way in the AM datastore configuration to list multiple attributes for authentication or in the journey for the username collector / datastore decision node to use mail and username? I would prefer not to use the ldap decision node with the additional configuration and use the OOTB datastore decision / flow.
Thanks
Nick
@nick.hunt you should add 2 nodes as the first steps of your journey to replace your username node:
1/ an attribute collector node with these parameters : Attributes to collect = mail & Identity Attribute = userName,
2/ an IdentifyExistingUser node with these parameters : Identifier = userName & identityAttribute = mail.
https://backstage.forgerock.com/docs/auth-node-ref/7.4/auth-node-identify-existing-user.html
Cheers,
Steph
1 Like
Stephanie
Thanks for the reply. Yeah, i was doing that initially to identify the user, but as you move through the journey there are search parameters based on the username which can cause issues if you rename / use different formats. So, was looking for a way to update the AM datastore search to include both uid and mail if possible for the search so technically ‘userName’ could be mail or uid.
Nick
Nick,
Rather than reconfiguring the mail identity attribute, or messing with the Platform username node, you can use the Attribute Collector Node to collect any/all identity attributes on a user (you can actually see this being done in the default password reset and registration journeys) and then validate based on different unique attributes using the Identify Existing User Node.
Now - you’ll note that I mention unique here - the Identify Existing User node is expecting to return one identity, so if your email or username is not unique you’ll need to identify the user another way in order to log in the appropriate person. This could be the usernameless/passwordless flow that I mentioned before (e.g. using a second factor device like biometric/push/otp/etc), or validating the user with some additional information (e.g. a policy number).
In your UI scenario here, in which you are letting the user enter their username or their email into the same field, you’ll likely need to use a Scripted Decision Node in which you query for the username and/or the email address (and potentially some other information) as you’re referencing multiple fields in one input. This would also likely include a reference to the organization/brand the user is a part of to help differentiate them (let’s say they have two accounts in two brands both with the same email). The script would likely hit IDM (identity manager) directly, but you can always validate this strategy with an API call:
{{host}}/openidm/managed/alpha_user?_queryFilter=(memberOfOrgIDs+co+‘orgID’)+and+((userName+eq+‘usernameOrEmail’)+or+(mail+eq+‘usernameOrEmail’))
The above example searches for a user whose email or username matches and is within a particular org.
1 Like