WAS v8.5 > Secure applications > Authenticate users > SAML web single sign-on

SAML single sign-on scenarios

1. User accesses a front end web application, which redirects user to SAML 2.0 Identity Provider (IdP).

2. User authenticates to IdP.

3. IdP redirects user to Assertion Consumer Service (ACS) in SP by sending SAML response over HTTP POST inside a hidden form.

4. SAML Service Provider (SP) processes SAML response and creates WebSphere security context.
5. SP adds LTPA cookie to HTTP response and redirects request to web resource or business application.

6. WAS intercepts request, and maps LTPA cookie to security context and authorizes user access to the requested web resource.

7. WAS sends HTTP response back to user.

The following images shows the SAML SSO flow:

The WebSphere SAML service provider supports...

• Single sign-on with multiple identity providers.
• Options for identity assertion and mapping the assertion identity to the user registry of the service provider.
• Mapping or asserting SAML token attributes to the realm, principal, unique Id, and group into the service provider security context.
• A plug point to allow for customized identity mapping.
• An option to retrieve the group membership of the identity from the registry of the service provider and populate the security context.
• An IdP selection filter to route the request back to the proper IdP if the request did not come from the IdP.
• BSA-SHA1 and RSA-SHA256 signature algorithms.
• Preserving the SAML token in the subject of the service provider for access by the application, and makes it available for a downstream authenticated EJB or Web Service call.
• Allowing a business application URL to act as an AssertionConsumerService URL, so the IdP can send a SAMLResponse directly to the business application URL.

The WebSphere SAML TAI allows auditing of key SAML assertions, including Issuer and NameID.

Assertion Consumer Service (ACS) servlet

The Assertion Consumer Service (ACS) servlet in the WebSphere SAML service provider accepts a SAML protocol message, and establishes the security context. An ACS URL has a predefined ContextRoot as samlsps, and a URL has the following format:

https://host:port/samlsps/<any uri pattern>

The SAMLResponse received by the ACS will be intercepted by the TAI, and upon successful validation, redirected to the target application service.

Any business service that implements the POST method can act as an ACS. Using a target business servlet as an ACS is preferred, as it reduces one round trip between the browser and the service provider server.

An ACS servlet is generally deployed in the same application security domain as the business application.

Multiple single sign-on partners

The WebSphere SAML TAI supports multiple ACS servlet and IdP single sign-on (SingleSignOnService) partners. One SSO partner is defined as one ACS URL, and multiple SingleSignOnServices. With the existence of multiple SSO partners, each SSO partnership is uniquely identified by an ACS URL.

Each SSO partner can have its own validation rules, mapping rule from assertion to subject, or a rule to start the SSO with its own IdP. For example, one SSO partner can handle ID assertion, which consists of generating a WebSphere platform subject without calling into the user registry. Another SSO partner can perform a local user registry lookup. Another example is that one SSO partner handles SSO with one IdP, and another SSO partner handles SSO with a different IdP.

Bookmark style SSO and TAI filter

Consider a bookmark style SSO which traditionally fits into an SP-initiated SSO. The user accesses the business application without authenticating to the IdP first. The WebSphere SAML TAI can be configured to initiate an SSO. Each SSO partner configuration contains an IdP login application and a routing filter. Each filter defines a list of selection rules that represent conditions that are matched against the HTTP request to determine whether or not the HTTP request is selected for an SSO partner. The filter rule is a combination of HTTP request header, referrer data, and target application name. The WebSphere SAML TAI runtime environment checks the user request against all filter rules to uniquely identify the SSO partner, and redirects the request to the selected IdP login application. The TAI filter allows an IdP-initiated SSO to provide similar functionality as the combination of an SP-initiated SSO and an IdP discovery service.

WebSphere SAML TAI identity mapping

Identity assertion

Map the SAML assertion to the WebSphere platform subject without a local registry. Typical ID assertion scenarios include:

• Default: use NameID as principal, issuer as realm, selected attribute as group members.
• Customized: configure SAML attribute as principal, realm, accessID, and group members.

Map NameID from the IdP against the user registry of the service provider

Builds the subject from the registry.

The following scenarios are supported:

• Directly map the SAML NameId to the local registry.
• Plugin point for custom mapping, followed using a new user to build the subject.
• Map NameID to the user registry, and fall back to ID assertion.

Combination of ID assertion and local registry

TAI searches parent groups of the asserted groups in the user registry of the service provider, and includes the parent groups into the subject. For example, authorization is granted to parent groups, but the identity provider does not know the parent group names.

WAS supports IdP initiated SAML web SSO only.

The following specifications or scenarios are out of scope:

• Enhanced Client or Proxy (ECP) Profile
• Identity Provider Discovery Profile
• Single Logout Profile
• Name Identifier Management Profile
• Artifact Resolution Profile
• Assertion Query/Request Profile
• Name Identifier Mapping Profile
• SAML Attribute Profiles

ACS servlet and target business application in different security domains

If the ACS servlet and target business application (RelayState) are in different security domains, the following are some recommended options:

• Process the SAMLResponse in the security domain of the ACS.
• Reconfigure the ACS servlet to have the same domain as the business application.
• Use the target business service as the ACS.

Related information:
Step by step guide to implement SAML 2.0 for Portal 8.5
Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0
Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0
Assertions and Protocols for the OASIS SAML V2.0

+

Search Tips   |   Advanced Search