SAML 2.0 Web Browser Single-Sign-On

SAML Web Browser Single-Sign-On (SSO) enables web applications to delegate user authentication to a SAML identity provider instead of a configured user registry.

Security Assertion Markup Language (SAML) is an OASIS open standard for representing and exchanging user identity, authentication, and attribute information. A SAML assertion is an XML formatted token that is used to transfer user identity and attribute information from the identity provider of a user to a trusted service provider as part of the completion of a single sign-on request. A SAML assertion provides a vendor neutral means of transferring information between federation business partners. Using SAML, an enterprise service provider can contact a separate enterprise identity provider to authenticate users who are trying to access secure content.

The WebSphere® Application Server Liberty supports the SAML web browser single sign-on profile with HTTP Post bindings, and acts as a SAML service provider. A web user authenticates to a SAML identity provider, which produces a SAML assertion, and the WebSphere SAML service provider uses the SAML assertion to establish a security context for the web user.

The SAML web SSO flow includes three actors: the end user, the identity provider (IdP), and the service provider (SP). The user always authenticates to the IdP, and the SP relies on IdP assertion to identify the user.

Figure 1. Key Concepts in Web Single-Sign-On

SSO flowchart
In the previous figure:
  1. The user requests a service from the service provider (SP).
  2. The SP requests a user identity (SAML) from the identity provider (IdP) via redirect.
  3. If this user is not already authenticated, IdP asks the user to sign in.
  4. SP obtains SAML.
  5. SP makes an access control decision non the basis of the SAML assertion.

Liberty SAML Web Browser SSO Scenarios

Figure 2. Scenario 1: SP-Initiated solicited Web SSO (End user starting at SP)
SP-Initiated solicited Web SSO (End user starting at SP)
  1. The end user visits the SP.
  2. The SP redirects the user to the IdP.
  3. The end user authenticates to the IdP.
  4. The IdP sends the SAML response and assertion to the SP.
  5. The SP verifies the SAML response and authorizes the user request.
Figure 3. Scenario 2: IdP-Initiated unsolicited Web SSO (End user starting at IdP)
IdP-Initiated unsolicited Web SSO (End user starting at IdP)
  1. The user agent accesses the SAML IdP.
  2. The IdP authenticates the user, and issues a SAML assertion.
  3. The IdP redirects the user to the SP with a SAMLResponse
  4. The SP verifies the SAML response and authorizes the user's request.
Figure 4. Scenario 3: OpenID Connect provider and SAML service provider
OpenID Connect provider and SAML service provider
  1. The end user visits the OpenID Connect Relying Party (RP).
  2. The RP redirects the end user to the OpenID Connect Provider (OP).
  3. The OP (also SAML SP) redirects the end user to the SAML IdP.
  4. The end user authenticates to the SAML IdP.
  5. The IdP redirects the end user to the OP or SP with a SAMLResponse.
  6. The OP/SP verifies SAML, and sends authorization code to the RP.
  7. The RP exchanges code for the id_token and access_token.
  8. The RP verifies the id_token, and authorizes the end user.