When logging in to Reftab via SSO, you may see the error, “User authenticated, but email not in Reftab and attribute mapping failed“. This article will show you how to handle this.
This means your account wasn’t able to login because your SAML token doesn’t expose any of the attributes that you have saved in your Reftab account’s just-in-time provisioning rules .
How to fix attribute mapping failed when using single sign-on
How to fix attribute mapping failed when using just-in-time provisioning
How to override Just-in-time rules
How to fix “attribute mapping failed” when using single sign-on
When setting up SSO with Reftab, when trying to login via SSO you may see an error that indicates that attribute mapping has failed. Reftab will show you an output on screen of the attributes that were exposed. You will need to use that screen to find the attribute that denotes email address.
- Log into Reftab as an administrator and click “Settings” > “SAML SSO Settings“.
- Then, click “Edit” next to your domain.
- On the screen that appears, check what value you have for “Email Attribute“. This is likely incorrect.
3. If you’re using MS Entra ID (previously named Azure) you likely can use the email attribute of: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
4. Once you enter the value listed in step 3 above, click “Save SAML Settings“
Now, try logging into Reftab with SSO again. If you still get the same error message, Reftab will show you an output on screen of the attributes that were exposed. You will need to use that screen to find the attribute that your identity provide has sent that denotes email address. (You may need to contact your administrator in your identity team and have them assist.)
How to fix attribute mapping failed when using just-in-time provisioning
You will need to verify the exposed attribute and values being sent from your identity provider’s SAML token.
To do this, download the Google Chrome extension called, “SAML Chrome Panel”. Go to Reftab.com/login and open the browser’s dev tools by right clicking anywhere on the page and click “Inspect“
Then click the tab, “SAML”. Then login via SSO.
In the screenshot above, I can see the SAML token passed to Reftab.
For example, I’ve highlighted that I have an attribute called “userType” and a value of “student”. This is sent from the identity provider to Reftab.
In my just-in-time settings, I have a role that maps the attribute for “userType” with a value of “student” into the role, “New York – Portal Access”
If my SAML token does not expose the attribute for userType with a value of student for the user logging in, then the error, “User authenticated, but email not in Reftab and attribute mapping failed” will appear. To fix this, expose the additional attributes on your SAML token, or update your just-in-time provisioning rules or, enable “role lock” on the Reftab account.
You can refer to this link to both edit and add new claims to your SAML tokens for MS Azure. https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization
Override JIT Rules
If you enable role lock on any account, JIT rules are ignored and the user is logged in to whatever role they are locked into.
Determining if Just-In-Time is Necessary
Every user user logging into Reftab must belong to an access role. Reftab needs to know if the user is an administrator, editor, viewer etc. or some other custom role you’ve created…
If you are adding users manually you don’t need just-in-time rules. You manually add users to a Reftab access role prior to them logging in for the first time.
If you don’t want to manually create users you have two options:
- Use just-in-time rules so that users are created on-the-fly the first time they login.
- Create users via a SCIM integration: Click here to setup SCIM with Azure
If you’re both manually creating users and using just-in-time provisioning, you’ll want to turn on ‘role lock’ for the users you’re creating manually so that they are locked into their access role.