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.


Definitions

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 the Foundry SP, then your identity provider must have a SSO URL that can accept a HTTP GET from Foundry. This request 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 codes, 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 condition’s 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 GET 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

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.