This article relates to Single Sign-On (SSO) in Foundry.

User Registration in Single Sign-On

When a user attempts to single sign-on into Foundry, if the user already exists in Foundry, then the user get signed in as that user; see SAML NameID and EVERFI SSO ID for details. If the user does not exist, then you have two options:

  1. The user will see an error message
  2. The user will get created immediately in Foundry, and is then signed in as that newly-created user

The first option is the default behavior in Foundry. The second option you can enable for your identity provider by checking the “allow registration during SSO” checkbox as described in SAML Identity Provider Setup. As described in the linked page, the new user’s properties will be set based on the values the SAML Response provides in different Attributes.

Matching or Creating a User

Below is the detailed logic flow on how Foundry attempts to find or create a user based on the properties in the SAML Response.

  1. First Match Attempt: SAML NameID to Foundry User SSO ID
    • When a user who attempts to access EVERFI is authenticated by your IDP, your IDP sends to EVERFI a SAML assertion containing the authenticated user’s NameID. EVERFI attempts to find this user by first matching a user in your organization with a SSO ID containing the provided NameID. If found, this user is then logged in. The match comparison is case sensitive; a NameID of JDoe will not match with a Foundry User SSO ID of jdoe.
  2. Second Match Attempt: Email Attribute value to EVERFI User Email
    • If a user with the NameID cannot be found, EVERFI will use the email attribute in the SAML assertion, if there is one, to search for a user in your organization who does not already have a SSO ID and whose email address matches the mapped email attribute (if any) in the SAML assertion. If a user can be found, then EVERFI will send a verification email to that email address, asking the recipient to click a link in the email to verify their identity. Once the recipient clicks the link in the verification email, Foundry will update that user to have the SSO ID of the provided NameID (which may or may not be an email address) and log the user in.
  3. Creating a Non-Matched User
    • If the searches above fail to find a matching user, then EVERFI will create a new user if the “allow registration during SSO” checkbox is checked on the IdP configuration.
    • The newly created user will have the SSO ID set to that of the NameID value, with other user properties being set by corresponding assertion attributes (email, first name, last name, etc.) and by default values entered in the identity provider configuration in Foundry.
    • If the “allow registration during SSO” checkbox is not checked on the IdP configuration, then the user will see an error message saying explaining why they could not be logged in.
  4. 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).

FAQ on Creation of New Users During SSO

These FAQ relate to the “Allow user registration during SSO” checkbox in the SSO setup.

Q: When a new user gets created during SSO, is it possible for the SAML Assertion Attributes to include categories and labels?

A: No. Categories and labels cannot be created for a user during SSO user creation. For NEXT partners only, you can include custom demographics in a SAML assertion and have those get set into Foundry user custom demographics.

Q: What options are there for setting the User Type and Role during SAML SSO User Creation?

A: For SAML SSO user creation, the default User Type can be overridden by providing an Attribute Mapping for that property in the identity provider configuration in Foundry.

The Foundry IDP setting also sets a default User Role within the selected default User Type. For example, the default User Type might be Faculty/Staff Learner and default User Role could be Non-Supervisor. If you override the default user type, then the Assertion must also provide a role override that belongs to the provided user type.

Q: What would happen for an Organization that has two user types, for example both Faculty/Staff and Higher Education learners? How could they create new users via SAML SSO for both user types?

A: In the Assertion, send an Attribute for user type along with an Attribute for the role to specify the properties for each user.

Q: When is it advantageous to create new users via SAML SSO?

A: Generally, if you have a relatively fixed and known user base and you know who your users are, then it makes sense to create them in Foundry in advance and then assign them courses. Therefore, there isn’t a strong use case to have these users get auto-created during SAML SSO. If you are not directly assigning course to people and have viewers who register on the fly to watch your content, then it makes sense to allow for users to get created on the fly in Foundry via SAML SSO.