WebLogic Security Service Architecture 5-11
request to the Artifact Retrieval Service ARS at the SAML source site, sending the artifact and requesting the corresponding assertion.
7.
The SAML source site returns an assertion.
8.
The SAML authentication filter calls the PrincipalValidator to assert the users identity.
9.
One of the following then occurs:
■
If any validitytrust check fails, the login fails and WebLogic Server returns a 403 Forbidden
.
■
If all validitytrust checks are successful, the user is logged in by the assertIdentity
call. The SAML authentication filter creates a session for the user and redirects the now authenticated user to the requested target
URL.
5.2.2 Single Sign-On and SAML 2.0
The SAML 2.0 Web Single Sign-On SSO profile supported by WebLogic Server implements the Authentication Request Protocol in conjunction with the HTTP
Redirect, HTTP POST, and HTTP Artifact bindings. The following sections describe the flow of execution in both ways of that this profile can be initiated, showing the
interaction among the SAML 2.0 services provided in WebLogic Server and the WebLogic Security Service:
■
Section 5.2.2.1, Service Provider Initiated Single Sign-On
■
Section 5.2.2.2, Identity Provider Initiated Single Sign-On
5.2.2.1 Service Provider Initiated Single Sign-On
In a typical Service Provider initiated SSO scenario, an unauthenticated user tries to access a protected resource on a Service Provider site. In response, the Service Provider
initiates a Web SSO session by identifying the appropriate Identity Provider partner and sending or redirecting an authentication request to that partner. The Identity
Provider then authenticates the user, typically via a login web application, generates a SAML assertion containing that users identity information, and returns the assertion
to the Service Provider in the form of an authentication response.
When the Service Provider receives the authentication response, the Service Provider extracts the identity information from the assertion contained in the response and
verifies the users identity by mapping it to a Subject in the local security realm. If the users identity is successfully mapped, the Service Provider can consequently
authorize the users access to the protected resource.
Figure 5–9 shows the flow of execution in an example of a Service Provider initiated
Web single sign-on session.
5-12 Understanding Security for Oracle WebLogic Server
Figure 5–9 Service Provider Initiated Single Sign-On
Note the following callouts in Figure 5–9
showing the flow of execution:
1.
From a web browser, a user attempts to access a protected resource running in a WebLogic container that is hosted by a Service Provider.
2.
The WebLogic container invokes the WebLogic Security Service to determine if the user is authenticated.
3.
Because the user is not authenticated, the Service Provider generates an authentication request that contains information about the unauthenticated user
and sends it to the Identity Provider, using the endpoint of the Identity Providers Single Sign-On Service.
The Service Provider can be configured to use one of the following bindings for transmitting the authentication request:
■
HTTP POST - When using the HTTP POST binding, the Service Provider sends an HTTP POST message containing the authentication request to the
users browser. The HTTP POST message is then sent to the Identity Providers Single Sign-On Service.
■
HTTP Artifact - The Service Provider sends an HTTP redirect message that includes a SAML artifact to the users browser. The SAML artifact contains a
pointer to the authentication request message, which is maintained by the Service Providers Artifact Resolution Service ARS. When the Identity
Provider receives the HTTP redirect message, it sends an artifact resolution request to the Service Providers ARS to obtain the authentication request
message.
■
HTTP Redirect - The Service Provider sends an HTTP redirect message to the users browser, which sends an HTTP GET message to the Identity Providers
Single Sign-On Service.
4.
The user is presented with a login web application hosted by an Identity Provider that is capable of authenticating that user. The Identity Provider challenges the
user for his or her credentials.
5.
The user provides his or her username and password to the Identity Provider, which completes the authentication operation.
6.
The Single Sign-On Service hosted by the Identity Provider generates an assertion for the user and returns an authentication response to the Service Providers
Assertion Consumer Service ACS.
The Identity Provider can be configured to use the following bindings:
WebLogic Security Service Architecture 5-13
■
HTTP POST - The Identity Provider sends the authentication response, which contains the assertion, to the users browser. The authentication response is
transmitted to the Service Provider via an HTTP POST message.
■
HTTP Artifact - The Identity Provider sends an authentication response, which contains a SAML artifact, to the users browser. The SAML artifact contains a
pointer to the assertion, which is handled by the Identity Providers Artifact Resolution Service ARS. The authentication response is transmitted to the
Service Provider via an HTTP redirect message.When the Service Provider receives the response, it sends an artifact resolution request to the Identity
Providers ARS to obtain the assertion.
The ACS validates the assertion, extracts the identity information from that assertion, and maps that identity to a subject in the local security realm.
7.
The ACS sends an HTTP redirect message to the browser, passing a cookie containing a session ID and enabling the browser to access the requested resource.
The WebLogic Security Service performs an authorization check to determine whether the browser may access the requested resource. If the authorization check
succeeds, access to the resource is granted.
5.2.2.2 Identity Provider Initiated Single Sign-On
