SAML single sign-on summary
Business flow
The WebSphere SAML service provider supports identity provider initiated SSO by leveraging a SAML2 Trust Association Interceptor (TAI).
- User accesses a front end web application, which redirects user to an IdP such as IBM Security Identity Manager or ForgeRock.
- User authenticates to the identity provider.
- The identity provider redirects user to the Assertion Consumer Service (ACS) in the WebSphere service provider by sending SAML response over HTTP POST inside a hidden form.
- Service provider processes SAML response and creates a WebSphere security context.
- Service provider adds LTPA cookie to HTTP response and redirects request to web resource or business application.
- WAS intercepts request, and maps LTPA cookie to security context and authorizes user access to the requested web resource.
- WAS sends HTTP response back to user which redirects user to the front end web application.
Flow...
WebSphere SAML service provider
- Maps assertion identity to the service provider's user registry.
- Maps SAML token attributes to realms, principals, unique Ids, and groups
- Sets attributes into the service provider security context
- Retrieves group membership of the identity from the registry of the service provider
- Provides selection filter to route requests back to the IdP if the request did not come from the IdP
- Provides RSA-SHA1 and RSA-SHA256 signature algorithms
- Preserves the SAML token in the subject, for access by downstream Web Service calls
- Allows URLs to act as AssertionConsumerService URLs, so the IdP sends a SAMLResponse directly
- The trust association interceptor allows auditing of SAML assertions, including Issuer and NameID
Assertion Consumer Services
The Assertion Consumer Service (ACS) servlet is deployed to an application security domain, accepting SAML protocol messages (SAMLResponse) for a TAI. Upon successful validation a security context is established and the request is redirected to the target business application.
The ACS URL has a predefined ContextRoot of /samlsps...
- https://host name:port/samlsps/any uri pattern
Multiple security domain support
An ACS is deployed in an application security domain, and it is expected that the ACS reside in the same security domain as the business application. If the ACS 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 to have the same domain as the business application.
- Use the target business service as the ACS.
Multiple single sign-on partners
The WebSphere SAML TAI supports multiple ACS and IdP single sign-on (SingleSignOnService) partners. One SSO partner is defined as one ACS URL, and can have multiple SingleSignOnService objects. 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
- User access a business application.
- The WebSphere SAML TAI initiates single sign-on to an SSO partner
- The SSO partner hosts an IdP login application with a routing filter
- Routing filter selection rules match against the HTTP request...
- HTTP request header
- referrer data
- 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.
Identity mapping and security context management
The WebSphere SAML TAI provides:
- 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 identity provideragainst the user registry of the service provider, and build the subject from the registry.
The following scenarios are supported:
- Directly map the SAML NameId to the local registry.
- Provide a plugin point for custom mapping, and then use 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
In addition to ID assertion, 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
See also