5-10 Understanding Security for Oracle WebLogic Server
users to remote SAML source sites for authentication based on the particular URL they tried to access.
The following sections detail how WebLogic Server is used as a SAML destination in the POST and Artifact profiles.
5.2.1.2.1 POST Profile In a typical SSO scenario, the POST profile works as follows:
1.
The user accesses the web site for example, http:www.weblogic.comsamlitsits
for the SAML source site.
2.
The SAML source site authenticates the user, generates an assertion, and returns a POST form containing the assertion in a signed SAML response to the users
browser.
3.
The users browser posts the POST form to the ACS at the SAML destination site. The ACS looks for an asserting party ID APID as a form parameter of the
incoming request, and uses this to look up the configuration before performing any other processing.
4.
Upon receiving a POST form from the SAML source site, the SAML destination site extracts the embedded SAML response from the POST form and verifies trust
in the certificate used to sign the response. An optional recipient check may be performed depending on the configuration.
5.
The SAML Authentication filter also ensures that this assertion has not been previously used. If the one-use check is configured, the filter checks to see if the
assertion has already been used. If so, the filter returns an error. If not, the filter persists the assertion to enable future checks.
6.
One of the following then occurs:
■
If the one-use check or any other validitytrust check fails, the login fails and WebLogic Server returns a 403 Forbidden.
■
If the one-use check and any other 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.1.2.2 Artifact Profile The Artifact profile works as follows:
1.
The user accesses the web site for example, http:www.weblogic.comsamlitsits
for the SAML source site.
2.
The request is redirected to the SAML ITS service.
3.
The SAML source site authenticates user.
4.
After the user is authenticated, the SAML ITS generates an assertion and then generates a base-64 encoded artifact that contains the assertion ID and the source
ID of the SAML ITS.
5.
The SAML ITS redirects the user to the Assertion Consumer Service ACS of the SAML destination site, passing the artifact as a query parameter on the redirect
URL. The ACS looks for an asserting party ID APID as a query parameter of the incoming request, and uses this to look up the configuration before performing
any other processing. The ACS gets the artifact by looking for the query parameter.
6.
The SAML authentication filter base64-decodes the artifact to determine the source ID of the SAML source site and the assertion ID. The source ID is used to look up
the Assertion Retrieval URL for that source site. The filter then makes a SOAP
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.
