This article relates to Single Sign-On (SSO) in Foundry.
This document 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 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 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 change that limit.
Identity Provider SAML Response
- The SAML Response your identity provider sends to Foundry must be digitally signed.
- The Assertion in the SAML Response must be digitally signed.
- The Response‘s 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. 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 may or may not be encrypted. If you encrypt it, then Foundry will use the X.509 certificate that is entered in the identity provider configuration in Foundry to decrypt it, using the algorithm entered in Foundry.
- The Assertion does not need any Attributes 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 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.
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. 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 is received from the identity provider.
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.