About SAML 2.0 SSO and Federation
The IG federation component implements SAML 2.0, to validate users and log them in to protected applications.
The SAML 2.0 standard describes the messages that providers exchange, and how they exchange them. SAML 2.0 enables web single sign-on (SSO), for example, where the service managing the user's identity does not belong to the same organization and does not use the same software as the service that the user wants to access.
The following terms are used in SAML and federation:
Identity Provider (IDP): The service that manages the user identity.
Service Provider (SP): The service that a user wants to access. IG acts as a SAML 2.0 SP for SSO, providing users with an interface to applications that don't support SAML 2.0.
Circle of trust (CoT): An IDP and SP that participate in the federation.
When an IDP and an SP participate in a federation, they agree on what security information to exchange, and mutually configure access to each other's services.
After an IDP authenticates a user, it provides the SP with SAML assertions that attest to which user is authenticated, when the authentication succeeded, how long the assertion is valid, and so on. The SP uses the SAML assertions to make authorization decisions, for example, to let an authenticated user complete a purchase that gets charged to the user's account at the IDP.
The IDP and SP usually communicate about a user identified by a name identifier. In SP-initiated SSO and IDP-initiated SSO, the NameID format can be any format supported by the IDP. For more information, see "Using a Non-Transient NameID Format".
SAML assertions can be signed and encrypted. ForgeRock recommends using *SHA-256 variants (rsa-sha256 or ecdsa-sha256).
SAML assertions can contain configurable attribute values, such as user meta-information or anything else provided by the IDP. The attributes of a SAML assertion can contain one or more values, made available as a list of strings. Even if an attribute contains a single value, it is made available as a list of strings.
About SP-Initiated SSO
SP-initiated SSO occurs when a user attempts to access a protected application directly through the SP. Because the user's federated identity is managed by the IDP, the SP sends a SAML authentication request to the IDP. After the IDP authenticates the user, it provides the SP with a SAML assertion for the user.
The following sequence diagram shows the flow of information in SP-initiated SSO, when IG acts as a SAML 2.0 SP:
About IDP-Initiated SSO
IDP-initiated SSO occurs when a user attempts to access a protected application, using the IDP for authentication. The IDP sends an unsolicited authentication statement to the SP.
Before IDP-initiated SSO can occur:
The user must access a link on the IDP that refers to the remote SP.
The user must authenticate to the IDP.
The IDP must be configured with links that refer to the SP.
The following sequence diagram shows the flow of information in IDP-initiated SSO when IG acts as a SAML 2.0 SP:
