Skip to content
English
Contact Support
  • There are no suggestions because the search field is empty.

Single Sign-On (SSO) FAQs

Get answers to frequently asked questions related to single sign-on.

 

Can I use custom registration questions with SSO?

Yes, you can use custom registration questions with SSO.

  • In the IDP-initiated scenario, you can set custom registration questions to appear on registration, first activity, and incentive completion.  These questions will be manually answered by the user. The ability to automatically send extra information about the user on login is in development.

  • In the SP-initiated scenario, you can have custom registration questions manually answered by the user, or you can make use of pass through URLs.

Can I turn SP-initiated SSO off?

SP-initiated SSO can be enabled or disabled for any identity provider.

If I have multiple identity providers set up, will I be able to turn off SP-initiated SSO for a particular identity provider for a specific program?

No, at this time you can not pick and choose at the program level.

Is there a public URL where the Foundry SAML metadata can be accessed?

Yes, that URL is: https://admin.fifoundry.net/{org-slug}/saml/metadata.xml where {org-slug} is your organization’s slug. If you are running the legacy SAML model, then the URL is https://admin.fifoundry.net/saml/metadata.xml.

Note that at this time, Foundry does not support automatic updates of the Foundry service provider in your identity provider. See SAML Single Sign-On System Requirements for details.

When I look at the users in my organization in Foundry, I am not seeing the SSO ID field. Where is this? How does it become visible?

Your account needs to have SAML SSO enabled by EVERFI. To check whether your account has this feature enabled, log in to the customer admin portal. In the navigate menu, look for an option called Settings and within that menu option, a link for Single sign-on. If you don’t have that link, then check with your EVERFI contact.

In my organization’s IdP, can we specify a URL in the relay state to automatically redirect a user to that URL upon successful login during IDP-initiated SSO?

Yes, if you specify a particular URL in the default relay state of your IdP, then upon successful login during an IdP-initiated SSO, EVERFI will redirect the user to the relay state URL your IdP specifies. This will not occur during SP-initiated SSO; in this scenario, the user will navigate to their intended URL. Note that this setup needs to occur in your organization’s IdP configuration, if that feature is supported by your IdP; this is not a configuration setting in the EVERFI IdP setup.

If a learner who is already in Foundry has a name change that updates their email and the user authenticates by using their new email during the portal log in, will Foundry map and update their new email to the account?

If the user’s SAML NameID value in the identity management system is not an email address, then yes, assuming correct setup. But if the user’s NameID is an email address, and that email address changed in the identity management system, then the next time that user attempts to SSO into Foundry, Foundry will not be able to identity that user because in Foundry, the User’s SSO ID will contain the value of the older email address.

But if the user’s NameID hasn’t changed, then when the user SSO’s in to Foundry, the user will be able to authenticate because the NameID and SSO ID are the same. If the SAML Response has a mapped Attribute for email address, then upon successful SSO, Foundry will update the User’s email address to the Attribute’s value. Foundry can similarly update the user’s first name, last name and location based on mapped SAML Attributes if they are provided in the SAML Response.

This scenario illustrates why we recommend using a persist non-changing value for NameID, such as a ID, Student ID, Employe ID, etc. If you use a property like email address that changes, then if that changes in the identity management system, then you need to ensure you have a routine to update the user’s SSO ID in Foundry at the same time. You can do this either manually or via an API integration.

I see that when Foundry sends a SAML Authentication Request during SP-initiated login, the signature is in the SAML AuthnRequestbody. Is it possible to have the signature in a querystring parameter instead?

Although the SAML specification permits a signature in either the URL or the AuthnRequest XML, Foundry always includes the signature in the XML and it is not possible to change it to the URL.

Can the user match for NameID to SSO ID be case insensitive?

Some of our users have a NameID like Bob.Smith@acme.com (mixed case) and others are like sam.jones@acme.com (lowercase). In some cases, the value in their Foundry User SSO ID might not match the case of the NameID in our identity provider. Can the user match for NameID to SSO ID be made case insensitive?

EVERFI recognizes that casing issues between the SAML NameID and the Foundry User SSO ID can present issues for some organizations. During single sign-on, when Foundry attempts to match a user in Foundry with the user who is performing single sign-on, the matching criteria for NameID and User SSO ID is case sensitive because the SAML V 2.0 specification requires it (see Section 2.1. Excerpt: “NameID definition explicitly requires case-sensitive handling”).

The NameID‘s base type is string. Per the SAML V2.0 specification:

Section 1.3.1 String Values
“Unless otherwise noted in this specification or particular profiles, all elements in SAML documents that have the XML Schema xs:string type, or a type derived from that, MUST be compared using an exact binary comparison. In particular, SAML implementations and deployments MUST NOT depend on case-insensitive string comparisons, normalization or trimming of whitespace, or conversion of locale-specific formats such as numbers or currency. This requirement is intended to conform to the W3C working-draft Requirements for String Identity, Matching, and String Indexing [W3C-CHAR].”

To minimize user matching problems with casing, ensure that the Foundry User SSO ID values exactly match the NameID values in your identity provider. If your source user data has inconsistent casing and it’s not practical to standardize the values at the source, then one possible solution is the following:

  1. In the service provider definition for Foundry, for the NameID property/attribute/claim, lowercase the value. Many identity provider products have a way to transform the value upon generating the SAML Response.

  2. In Foundry, when adding/updating users, ensure the User SSO ID is also lowercased.

Why is the Foundry x509 certificate date range three years? Can you make it longer so we don’t have to perform a certificate rotation every 3 years?

EVERFI believes that replacing a certificate every three years is a security best practice that ensures EVERFI protects your sensitive data with the latest technology in the rapidly evolving realm of cryptology. For a more detailed explanation of why this is a best practice, read The Long Life Certificate – Why It Doesn’t Exist | CA Security Council.

EVERFI recognizes that some customers would prefer a certificate with a longer lifespan so that certificate rotation can happen less frequently. We also have many other customers using our SAML integration with more stringent compliance requirements on their end about how long a connected service provider’s certificate may be valid for and we try to respect that as well. With a 3-year certificate period, we strive to strike a balance between convenience and the security requirements of our customers and EVERFI’s own need to ensure we do not stay locked in to supporting very old certificates created with dated technology.

 

What is the login flow when using single sign-on?

When a learner clicks on a Foundry link in a Foundry email for an invitation or training reminder, if that user has a SSO ID in Foundry, then upon clicking the link, Foundry sends the user right to the identity provider to log in, rather than taking the user to the customer login page where the learner has to click the login button. Essentially, Foundry initiates SP-initiated SSO right then and there.

If the learner happens to be logged in already to the IDP, then when Foundry sends the user right to the identity provider to log in, the user will get boomeranged right back to Foundry without needing to log in again to the IDP, because they are already logged in.

If the learner does NOT have a SSO ID, then clicking the Foundry link takes the user to the standard customer login page.

Foundry does this to simplify and accelerate the login experience. The assumption is that if the user has a SSO ID, then it was intended that they login via SSO.