WebLogic server integration with SAML 2.0

WebLogic server integration with SAML - SP initiated and IDP initiated Single sign on

This post will cover the two scenarios of SSO in SAML Federation, the SP-initiated SSO flow and IdP-initiated SSO flow. Both these flows are part of the SAML Web SSO and valid for various integrations with WebLogic server, PingFederate or Okta.

There are two models for Web SSO - SP-initiated and IdP-initiated.

SP-initiated and IdP-initiated models

The above diagram shows the two models for Web SSO flow. Since there are two options, the first choice is to decide your use case of where the user will start the process of the Web SSO.

The SP-initiated SSO flow is described first and followed by IdP-initiated SSO flow.

SP-initiated SSO flow

In this use case, the user is provided with a published URL which the user accesses via their browser which takes them directly to the Service Provider (SP) Application URL/resource. However since the user is not logged in at the SP, the user request is redirected to the IdP (Identity Provider) to authenticate, before the user request is permitted to access the Protected URL. The IdP builds an assertion representing the user's authentication at the IdP and then sends the user back to the SP with the assertion which contains the details of the authenticated user, time of authentication with a time stamp. The SP receives the assertion and is able to decrypt the contents of the assertion and verify it was indeed sent by the IdP. If the user request is valid the SP grants the user access to the resource. This was a summary of how SP-initiated SSO flow works and is also the common scenario in Web SSO.

IdP-initiated SSO flow

In an IdP-initiated SSO flow, the user is visiting an IdP to begin with and where they are already authenticated and they click on a link to a partner SP. The IdP builds an assertion representing the user's authentication state at the IdP and sends the user's browser over to the SP, specifically the assertion consumer service at SP. The SP receives the assertion, processes the assertion and creates a local security context for the user at the SP. This approach is useful in certain environments, but requires the IdP to be configured with inter-site transfer links to the SP's site. Sometimes a binding-specific field called RelayState is used to coordinate messages and actions of IdPs and SPs, for example, to allow an IdP (with which SSO was initiated) to indicate the URL of a desired resource when communicating with an SP.

Now that we have covered both SP-initiated and IdP-initiated SSO flows, we will describe both the scenarios with diagram and each of the steps in the flow.

                            SP-initiated diagram

Above is flow of user authentication request in WebLogic server with SP initiated Single sign on

                           IdP-initiated diagram

Above is user authentication flow with Identity Provider initiated Single sign on

Flow with steps for SP initiated Single sign on

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 Provider's 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 user's browser. The HTTP POST message is then sent to the Identity Provider's Single Sign-On Service.

HTTP Artifact - The Service Provider sends an HTTP redirect message that includes a SAML artifact to the user's browser. The SAML artifact contains a pointer to the authentication request message, which is maintained by the Service Provider's Artifact Resolution Service (ARS). When the Identity Provider receives the HTTP redirect message, it sends an artifact resolution request to the Service Provider's ARS to obtain the authentication request message.

HTTP Redirect - The Service Provider sends an HTTP redirect message to the user's browser, which sends an HTTP GET message to the Identity Provider's 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 Provider's Assertion Consumer Service (ACS).

The Identity Provider can be configured to use the following bindings:

HTTP POST - The Identity Provider sends the authentication response, which contains the assertion, to the user's 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 user's browser. The SAML artifact contains a pointer to the assertion, which is handled by the Identity Provider's 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 Provider's 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.

Flow with steps for Identity Provider initiated Single sign on

1)The user is presented with a login web application hosted by an Identity Provider that authenticates the user. The Identity Provider challenges the user for his or her credentials.
2)The user provides his or her username and password to the Identity Provider, which completes the authentication process.
The user issues a request on a resource that is hosted by a Service Provider.
3)The Single Sign-On Service hosted by the Identity Provider sends an unsolicited authentication response to the Service Provider to the Service Provider's Assertion Consumer Service (ACS).
Regardless of how the SSO session is initiated, the Identity Provider uses the same bindings as described in Service Provider Initiated Single Sign-On.
4)The ACS validates the assertion, extracts the identity information, and maps that identity to a subject in the local security realm. 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.
5)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.


Note: WebLogic may require Active Directory or another LDAP directory as an authentication provider. Refer to this blog for key settings in integrating WebLogic server with Active Directory.
Reference: Oracle WebLogic Server (WLS) and SAML integration
https://docs.oracle.com/cd/E23943_01/web.1111/e13710/archtect.htm#SCOVR245
Service Provider initiated SSO with WebLogic server
http://oamoim.blogspot.com/2017/05/service-provider-initiated-sso-on.html

Another good reference is this WebLogic configuration as SP and ADFS as the IDP. Although the IDP here is ADFS the steps are relevant for any other IDP provider such as PingFederate.
When using PingFederate as an IDP with WebLogic use this reference with Okta as an example IDP. This blog is relevant when doing integration between PingFederate and WebLogic. Here the use case is WebLogic hosting application as the Service Provider and PingFederate being the IDP/Identity Provider. WebLogic settings have to be done for Active Directory as the Authentication Provider, here WebLogic queries to verify the user attributes which are returned in a SAML Assertion.