Platform Selector

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. See Single Sign-On for documentation on specific features and setup.


See SAML Glossary for an expanded list.

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

If you’re not familiar with the format of a SAML Response or AuthnRequest, see OneLogin’s SAML Development Tools page for examples.

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

Identity Provider SAML Response
  • The SAML Response your identity provider sends to Foundry must be digitally signed using your identity provider’s certificate.
  • The Assertion in the SAML Response must be digitally signed.
  • 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. See SAML NameID and EVERFI SSO ID for recommendations on NameID.
  • 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 locationuser 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.


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.

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.