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

SAML SSO System Requirements

Learn all you need to know about SAML system requirements.

This page outlines the system requirements to use Foundry Single Sign-On and Single Logout (optionally) with your organization. In this arrangement, your organization will operate as a SAML identity provider and Foundry will operate as a SAML service provider. This document outlines general system requirements. 

Definitions

Identity Asset Management (IAM) solution – the solution that manages your organization’s users and their access to 3rd party systems

Identity Provider (IDP) – a system entity that creates, maintains, and manages identity information for principals while providing authentication services to relying applications within a federation or distributed network. Identity providers offer user authentication as a service. (Wikipedia)

Service Provider (SP) – a system like Foundry that needs to authenticate users against your IDP

SAML 2.0 – Security Assertion Markup Language – a security protocol that allows a SP to authenticate a user against an IDP

System Requirements

SAML 2.0 Protocol

Your identity asset management system observes the SAML 2.0 protocol.


Single Sign-On

Your identity asset management system can operate as an identity provider that can perform either or both of these operations:

  • For SSO initiated by Foundry (service provider): Receive a SAML AuthnRequest (authentication request) from Foundry (service provider) and reply with a SAML Response
  • For SSO initiated by your identity provider: send a SAML Response to Foundry
  • Foundry can have only one signing certificate from your identity provider. Therefore if your identity provider is in a certificate rotation window, where you have two supported signing certificates and you are trying to rotate your service providers from the old certificate to the newer replacement certificate, you must switch your organization’s signing certificate in both the Foundry IDP configuration setting, and in your identity provider, at the same time in order for SSO to operate without interruption.

Service Provider AuthnRequest

If you wish to support SSO initiated by Foundry (the service provider), then your identity provider must have a SSO URL that can accept a HTTP GET from Foundry. This request from Foundry to your identity provider will have an encoded SAML AuthnRequest as a querystring parameter. It is not possible for Foundry to send an AuthnRequest as a HTTP POST.

The AuthnRequest is signed with Foundry’s x509 certificate and consequently has a long querystring parameter because the encoded public certificate text is included. Therefore your system must be able to accept a long querystring. Some systems may limit the number of characters it can accept in a querystring and you may need to increase that limit. Note that browsers generally do not have a limitation on querystring length, only certain servers and other networking systems.

Foundry signs its AuthnRequest using either the SHA-256 or SHA-1 algorithms. If you want your identity provider to verify the signature (recommended) then your identity provider must be able to support SHA-256 (preferred) or SHA-1. 


Identity Provider SAML Response

  • The SAML Response your identity provider sends to Foundry must be digitally signed using your identity provider’s certificate. Foundry will verify the signature using your certificate stored in the identity provider settings in Foundry.
  • The Assertion in the SAML Response must be digitally signed with the identity provider’s certificate. Foundry will verify the signature using your certificate stored in the identity provider settings in Foundry.
  • The Assertion must contain a Subject with a NameID. Although a NameID can have one of several format types, Foundry disregards the format; you may use unspecified or any other type other than transient. Foundry uses the NameID value to identify the user in Foundry via the SSO ID field; the NameID value is case sensitive. Because the NameID is used to match to a Foundry User, a transient value will not work with Foundry.
  • The Assertion should be encrypted but this is not required. If you choose to encrypt then use Foundry’s x509 certificate.
  • The Assertion does not need anyAttributes unless you want for new users to get created during single sign-on if they don’t already exist. In that case, you must provide Attributes for first name, last name, email and you may provide attributes for location, user type and role (e.g. supervisor or non-supervisor) in case you need to override default values.
  • The Response may include NotBefore and/or NotOnOrAfter conditions in the Assertion’s Subject’s SubjectConfirmationData and/or the Assertion’s Conditions. Foundry will enforce these restrictions if they are passed. To avoid problems where the identity provider’s clock and Foundry’s clock get out of sync, Foundry pads 2 seconds of grace period on the Before and After conditions. For example, if the Response has a NotBefore condition of 22:19:15.100 (hh:mm:ss.000) , and Foundry’s clock is at 22:19:14.400, then normally this condition would not be allowed because the Response is received 0.7 seconds before the NotBefore condition. But Foundry will relax this by 2 seconds, meaning that as long as Foundry’s clock is not before 22:19:13.100, then the Response will be allowed. The same grace period is applied in the same manner to the NotOnOrAfter condition in the opposite direction. Foundry’s clock is synched with Network Time Protocol.


Single Logout

Foundry can implement Single Logout  as an option.


Identity Provider-Initiated SLO

If you implement SLO with Foundry, then your identity provider must send a LogoutRequest  to Foundry to initiate single logout from the identity provider. Expect a LogoutResponse from Foundry.


Service Provider-Initiated SLO

If a user logs out of Foundry, then Foundry will send a SAML LogoutRequest message via HTTP REDIRECT to your identity provider that includes the session ID and the user’s NameID. Foundry signs the message in a querystring parameter. Your identity provider must respond back to Foundry via HTTP POST with a SAML LogoutResponse message. The LogoutResponse must provide the session ID sent by Foundry in the originating LogoutRequest in the InResponseTo attribute of the LogoutResponse. Foundry will not log the user out of Foundry until the LogoutResponse , with a status of Success, is received from the identity provider. When SP-initiated SLO concludes successfully, the user remains in Foundry on the customer login page, in a logged-out state.

Exclusions


Alternative Login

If the Foundry organization has the Alternative Login capability enabled, which enables users to have a username but no email address, then single sign-on is supported, but the ability to have new users created during SSO is not supported. All users who need to SSO must already exist in Foundry. The “Use SSO Exclusively” feature is not supported if the organization has the alternative login capability enabled.


Automatic Updates for your Identity Provider

Although Foundry can read your IDP’s metadata URL one time when you add or update the identity provider configuration in Foundry when manually entering your settings in the customer admin portal, Foundry is not able to monitor your identity provider SAML metadata URL to automatically update the SAML settings for your identity provider in Foundry. Therefore, if your IDP settings changes, such as adding a new signing certificate, you must manually update the IDP configuration in Foundry when this occurs.


Automatic Updates for Foundry Service Provider

Many identity providers can monitor a service providers SAML metadata URL and automatically the service provider when changes occur.

EVERFI does not recommend that you add an automatic monitor to your identity provider to automatically update the Foundry service provider in your identity provider.

The EVERFI SAML metadata is intended to be used for starting new single sign-on implementation and not for automatic updates.

Advanced Configurations


Multiple Identity Providers for an Organization

The same organization in Foundry can have multiple identity providers to authenticate users, as long as each identity provider has a unique EntityID. A user can authenticate to either identity provider, so long as the user’s NameID is identical (case sensitive) in each identity provider. Since a Foundry user has only one SSO ID, it is not possible for a user to have one SSO ID for one identity provider, and a different SSO ID for another identity provider.


Same Identity Provider for Multiple Foundry Organizations

If your institution has two or more Foundry organizations (aka accounts) that are all served by the same common identity provider, this is supported. Each of your two (or more) organizations can be set up with an Identity Provider with the same EntityID (or different EntityIDs, if your identity provider creates a different EntityID for each service provider). Should you have some learners who are in both (or more) organizations with the same email and same SSO ID (or different email and/or SSO ID), that is supported. Most identity provider products should support this configuration; each Foundry organization will have a distinct EntityID, so even though both Foundry organizations are in the same system (Foundry), from the standpoint of the identity provider, they are two totally separate service providers.