SAML NameID And Everfi SSO ID
Learn how SAML NameID and Everfi SSO ID are connected in the context of single sign-on
Matching Users During Single Sign-on
This page explains how the SAML NameID and EVERFI User SSO ID and email address interrelate in the context of single sign-on.
Additionally, this page explains how a new Foundry user can be created during SAML SSO, and an existing Foundry user can be updated during SSO.
Quick Summary
The quick summary is: for a user to single sign-on into Foundry, the identity provider’s SAML Response must have a NameID value that matches with a Foundry User’s SSO ID. The match criteria is case sensitive; JaneDoe will not match with janedoe. If the user can be found, then they are logged in. Otherwise, the user will get an error saying “Sorry, we were not able to connect to your account with <Organization Name>”.
Setting the NameID in the Everfi Service Provider Configuration in your Identity Provider
When you configure Everfi as a Service Provider or Application in your identity provider (IdP), your IdP will likely let you choose which user attribute to send in the SAML Assertion’s NameID field. This field may be labeled differently depending on the IdP—for example, it might appear as application username in Okta, Unique User Identifier in Azure, or a Claim with a NameID format in Microsoft AD FS.
Regardless of the label, this value becomes the NameID in the SAML Assertion sent to Everfi.
The NameID is critical because it links a user in your IdP to the same user in Everfi’s platform. It must be a unique identifier within your IdP. This value can be a username, email address, numeric ID, GUID, student or employee ID, or any other value—as long as it’s unique, always present, and tied to a user account. Everfi doesn’t require a specific format for the NameID, but we strongly recommend using a value that is both unique and unchanging. For example, avoid using email addresses if they might change (such as when someone changes their name).
The NameID value must match the user’s Foundry SSO ID exactly, including case. For instance, Jeff.McDaniel@testorg will not match jeff.mcdaniel@testorg.
While the SAML response may include a NameID format, Everfi’s platform (Foundry) does not use or rely on that format.
How Foundry Finds a User during SSO
Below is the detailed logic Foundry uses to find or create a user based on the properties in the SAML Response.
-
First Match Attempt: SAML NameID to Foundry User SSO ID
When a user tries to access EVERFI and is authenticated by your identity provider (IdP), the IdP sends a SAML Assertion that includes the user’s NameID. EVERFI first tries to match this NameID to a user in your organization whose Foundry SSO ID matches the NameID exactly. This comparison is case-sensitive—for example, a NameID ofJDoewill not match a Foundry SSO ID ofjdoe. -
Second Match Attempt: Email Attribute to Everfi User Email
If no match is found using the NameID, Everfi checks the email attribute in the SAML Assertion (if one is included). It looks for a user in your organization who:
- Does not already have a Foundry SSO ID, and
- Has an email address that matches the email attribute in the SAML Assertion.
If such a user is found, Everfi sends a verification email to that address. The user must click the link in the email to confirm their identity. Once verified, Foundry assigns the SSO ID using the NameID value (which may or may not be an email address) and logs the user in.
- Creating a New User (Just-In-Time Provisioning)
If neither of the above methods finds a match, EVERFI will create a new user only if the “allow registration during SSO” checkbox is enabled in the IdP configuration.
The new user will have:
- An SSO ID set to the NameID value, and
- Other properties (like email, first name, last name) populated from the SAML attributes or default values set in the Foundry IdP configuration.
If the “allow registration during SSO” option is not enabled, the user will see an error message explaining why they couldn’t be logged in.
Additional Details on User Matching
- Everfi does not attempt to match a user on first and last name, since these values can result in a false match (common names like John Smith) or mismatches (Robert or Bob).
- While you can use an Email attribute as a “backup” way to match users as described above in #2, we do not recommend relying on this. The most reliable way for single sign-on to work is to ensure your users’ IDP NameID and Foundry user SSO ID values are in sync.
What Happens if a User's NameID Changes?
Suppose your SAML NameID uses email address, and a person’s email address changes in the identity provider. Then the next time that user attempts to single sign-in to Foundry, then as far as Foundry is concerned, this is a brand new user. Therefore, if a user’s NameID value changes, then you must manually or programmatically update the Foundry User’s SSO ID accordingly as described in the next section.
Setting the User SSO ID in Foundry
You can set a user’s SSO ID in several ways when adding or updating users:
-
Add Users – A customer admin in your organization can upload a spreadsheet to add new users. This spreadsheet can include SSO ID values for each user.
-
User Upload to Update – Similar to adding users, you can download a spreadsheet of existing users, enter or update their SSO ID values, and upload the file to apply the changes.
-
Edit a User in the Customer Portal – You can manually set or update a user’s SSO ID one at a time through the portal. However, an admin cannot update their own SSO ID.
-
API – You can update a user’s SSO ID by setting the
sso_idproperty in aPATCHrequest to theadmin/registration_setsendpoint.
Provisioning New Users During Single Sign-On
As an option, you can configure your identity provider in Foundry to create new users during single sign-on if the user doesn’t already exist in Foundry.