Skip to content
English
  • 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 for using Foundry Single Sign-On (SSO) and, optionally, Single Logout (SLO) with your organization. In this setup, your organization acts as the SAML Identity Provider (IdP), and Foundry acts as the SAML Service Provider (SP). The information below covers the general system requirements for this configuration.


Definitions

  • Identity Asset Management (IAM) solution – The system that manages your organization’s users and their access to third-party systems.

  • Identity Provider (IdP) – A system that creates, maintains, and manages identity information for users (principals) and provides authentication services to applications. Identity providers offer user authentication as a service. (Source: Wikipedia)

  • Service Provider (SP) – A system like Foundry that relies on your IdP to authenticate users.

  • SAML 2.0 – Security Assertion Markup Language, a protocol that allows a service provider to authenticate a user via an identity provider.


System Requirements

SAML 2.0 Protocol

Your IAM system must support the SAML 2.0 protocol.


Single Sign-On

Your IAM system must be able to act as an identity provider that supports one or both of the following:

  • SP-initiated SSO: Accept a SAML AuthnRequest from Foundry and respond with a SAML Response.
  • IdP-initiated SSO: Send a SAML Response directly to Foundry

Important: Foundry supports only one signing certificate from your IdP. If your IdP is rotating certificates (e.g., using both an old and new certificate during a transition), you must update the signing certificate in both Foundry and your IdP at the same time to avoid SSO disruptions.

 

Service Provider AuthnRequest

To support SP-initiated SSO, your IdP must have an SSO URL that accepts HTTP GET requests from Foundry. These requests include an encoded SAML AuthnRequest as a query string parameter. Foundry does not support sending AuthnRequest via HTTP POST.

Because the AuthnRequest is signed with Foundry’s x509 certificate, the query string will be long. Your system must be able to handle long query strings. While browsers typically don’t limit query string length, some servers or network devices might. You may need to increase the character limit on your system.

Foundry signs AuthnRequest messages using either SHA-256 (preferred) or SHA-1. If your IdP is configured to verify signatures (recommended), it must support one of these algorithms.


Identity Provider SAML Response

  • Your IdP’s SAML Response to Foundry must meet the following requirements:

    • The Response must be digitally signed using your IdP’s certificate. Foundry will verify the signature using the certificate stored in its IdP configuration.

    • The Assertion within the Response must also be digitally signed using the same certificate.

    • The Assertion must include a Subject with a NameID. Foundry does not use the NameID format, so you may use any format except transient. The NameID value is used to match the user in Foundry via the SSO ID field and is case-sensitive.

    • The Assertion can be encrypted, but encryption is optional. If you choose to encrypt, use Foundry’s x509 certificate.

    • The Assertion does not need to include Attributes unless you want to enable just-in-time user creation. In that case, include attributes for:

      • First name
      • Last name
      • Email

Optional attributes include:

      • Location
      • User type
      • Role (e.g., supervisor or non-supervisor)
    • The Response may include NotBefore and/or NotOnOrAfter conditions in the Assertion’s SubjectConfirmationData or Conditions. Foundry enforces these conditions but includes a 2-second grace period to account for clock drift. Foundry’s clock is synchronized using Network Time Protocol (NTP).

 

Single Logout

Foundry can implement Single Logout  as an option.

Identity Provider-Initiated SLO

If your IdP initiates logout, it must send a LogoutRequest to Foundry. Foundry will respond with a LogoutResponse.


Service Provider-Initiated SLO

If a user logs out of Foundry, Foundry sends a SAML LogoutRequest via HTTP Redirect to your IdP. This request includes the session ID and the user’s NameID, and is signed in the query string.

Your IdP must respond with a SAML LogoutResponse via HTTP POST. The response must include the session ID in the InResponseTo attribute and have a status of Success. Foundry will not complete the logout process until this response is received.

After a successful SP-initiated logout, the user is returned to the Foundry login page in a logged-out state.


 

Exclusions

Alternative Login

If your Foundry organization uses the Alternative Login feature (which allows usernames without email addresses), SSO is supported, but just-in-time user creation is not. All users must already exist in Foundry. The “Use SSO Exclusively” setting is not supported with Alternative Login enabled.


Automatic Updates for your Identity Provider

Foundry can read your IdP’s metadata URL once when you manually configure or update the IdP settings in the admin portal. However, Foundry does not support automatic monitoring of your IdP’s metadata URL. If your IdP settings change (e.g., a new signing certificate is added), you must manually update the configuration in Foundry.


Automatic Updates for Foundry Service Provider

Some IdPs can monitor a service provider’s metadata URL and automatically update their configuration when changes occur.

Note: Everfi does not recommend enabling automatic updates for Foundry’s metadata in your IdP. The Everfi SAML metadata is intended for initial setup only, not for ongoing automatic updates.


 

Advanced Configurations


Multiple Identity Providers for an Organization

A single Foundry organization can support multiple IdPs, as long as each IdP has a unique EntityID. Users can authenticate through any configured IdP, but their NameID must be identical (case-sensitive) across all IdPs. Since each Foundry user has only one SSO ID, users cannot have different SSO IDs across different IdPs.


Same Identity Provider for Multiple Foundry Organizations

A single Foundry organization can support multiple IdPs, as long as each IdP has a unique EntityID. Users can authenticate through any configured IdP, but their NameID must be identical (case-sensitive) across all IdPs. Since each Foundry user has only one SSO ID, users cannot have different SSO IDs across different IdPs.