Platform Selector

Can I use custom registration questions with SSO?

Yes, you can use custom registration questions with SSO and Fin Ed if you are in the Financial Capability Network.

  • 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?

In the Financial Capability Network,  you can turn off SP-initiated SSO for any program.

For other networks, 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 in the Financial Capability Network.

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

Yes, that URL is:{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

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.

Authentication Request and Signature Location

Q. 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?

A: 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?

Q: Some of our users have a NameID like (mixed case) and others are like (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 this comparison for single sign-on be made case insensitive?

A: 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”). To minimize user matching problems with casing, ensure that the Foundry User SSO ID values exactly match the NameID values in your identity provider.

Why does Foundry require the SAML Response and Assertion to both be signed?

A: Our rationale for requiring both the Response and Assertion to be signed is explained in the SAML specification, section 5:

SAML and XML Signature Syntax and Processing: SAML assertions and SAML protocol request and response messages may be signed, with the following benefits. An assertion signed by the asserting party supports assertion integrity, authentication of the asserting party to a SAML relying party, and, if the signature is based on the SAML authority’s public private key pair, non-repudiation of origin. A SAML protocol request or response message signed by the message originator supports message integrity, authentication of message origin to a destination, and, if the signature is based on the originator’s public-private key pair, non-repudiation of origin.

We also chose to follow the recommendation of Ping Identity:

Signing a SAML Response or SAML assertion ensures message integrity when the the response/assertion is delivered to the relying party(SP). The most secure is to sign both Response and Assertion.

Most identity providers sign both the Response and Assertion by default. Depending on your identity provider, there is usually a way to ensure both are properly signed with your signing certificate.

Why is the Foundry x509 certificate date range two years?

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

A: EVERFI believes that replacing a certificate every two 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 2-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.

EVERFI is working to make certificate management as simple and automated as possible. For the next round of certificate rotation, tentatively scheduled for summer of 2022, EVERFI expects to support automated monitoring and updating via the Foundry SAML service provider metadata URL, if your identity provider supports that feature; we know that Microsoft ADFS and Shibboleth support this, as well as many other identity provider products. If your identity provider can support automatic updates, then as soon as EVERFI releases its next certificate and updates the Foundry metadata URL, then your identity provider can automatically update the service provider entry for Foundry to rotate the certificate.  If your identity provider supports the ability to have two or more signing certificates, then this automatic update can be done with no disruption to single sign-on.

Login flow with 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.