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
SAML 2.0 Protocol
Your identity asset management system observes the SAML 2.0 protocol.
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
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.
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
Responseyour identity provider sends to Foundry must be digitally signed using your identity provider’s certificate.
Assertionin the SAML
Responsemust be digitally signed.
Assertionmust contain a
NameID. Although a
NameIDcan have one of several
formattypes, Foundry disregards the
format; you may use
unspecifiedor any other type other than
transient. Foundry uses the
NameIDvalue to identify the user in Foundry via the SSO ID field; the
NameIDvalue is case sensitive. Because the
NameIDis used to match to a Foundry User, a
transientvalue will not work with Foundry. See SAML NameID and EVERFI SSO ID for recommendations on
Assertionshould be encrypted but this is not required. If you choose to encrypt then use Foundry’s x509 certificate.
Assertiondoes not need any
Attributesunless 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
NotOnOrAfterconditions in the Assertion’s Subject’s
SubjectConfirmationDataand/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
NotBeforecondition 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
NotBeforecondition. 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
NotOnOrAftercondition in the opposite direction. Foundry’s clock is synched with Network Time Protocol.
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.
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.