Virtual Users in OIF, Weblogic and OWSM

Introduction

One of the main strengths of SAML is the ability to communicate identity information across security domains that do not necessarily share the same user base. In other words, the authenticated user in one security domain does not necessarily exist in the target security domain providing the service.

Such concept is supported in all major Oracle products that consume SAML tokens: OIF, Weblogic Server and OWSM. The sole purpose of this post is to show how to configure it in these products. Setting up SAML services as a whole involves more than what’s showed here and I recommend the official product documentation for detailed steps.

I hope this can be helpful to someone out there.

Main Article

OIF (Oracle Identity Federation)

OIF enables federated single sign on for users behind a web browser.

It calls the aforementioned concept “Transient Federation” and enables it via a checkbox (that should be unchecked) in Enterprise Manager OIF’s Console. Notice it also supports the concept of a "Mapped Federation", where the incoming identity is mapped to some generic user in the local identity store. But here I am talking about the case where there's no mapping. The user in the SAML assertion is simply trusted.

In order to enable a Transient Federation in OIF, simply make sure “Map Assertion to User Account” checkbox is unchecked in the Service Provider Common tab.

Weblogic Server

Weblogic server provides SAML services that can be leveraged by Web SSO as well web services.
Weblogic calls the concept Virtual Users and implements it in its SAML2IdentityAsserter along with the SAMLAuthenticator.

First, you need to enable your server as a SAML Service Provider. Notice this is done at the server level. Go to Environment –> servers –> <Pick server from list> to get into the screen below:

Then add a SAML2IdentityAsserter to the authentication providers list and add an Identity Provider (who does not need to be another Weblogic server) Partner to SAML2IdentityAsserter. Notice that you can add either a Web SSO partner provider or a Web service partner provider. In the case of Web SSO, Weblogic Console will ask you for the partner metadata file.

In SAML2IdentityAsserter’s Management tab, click the Identity Provider partner link just created and check the “Virtual User” check box:

You also need to add a SAMLAuthenticator provider after the SAML2IdentityAsserter and set its control flag to SUFFICIENT. Also make sure to set the control flag of subsequent authentication providers to SUFFICIENT.

End result is that the SAMLAuthenticator will instantiate a Java Subject populated with a user principal (weblogic.security.principal.WLSUserImpl) from the SAML Subject asserted by SAML2IdentityProvider.

OWSM (Oracle Web Services Manager)

OWSM protects SOAP web services via agents connected to web services providers as well as web services clients. The agent behavior is determined by the policies that get attached to the provider and the client. A client policy typically adds a token to the outgoing SOAP message while the server policy processes it, usually by authenticating and/or authorizing the user (in the case of a security policy).

First of all, a SAML-based security policy needs to be attached to the web service provider. The policy will at some point try to authenticate the subject in the incoming SAML assertion.

OWSM delegates authentication to OPSS (Oracle Platform Security Services). When asserting the SAML Subject to the container, OWSM leverages the SAML Login Module, defined in jps-config.xml and configured via EM (Enterprise Manager).

In other to enable virtual users in this scenario, set the property oracle.security.jps.assert.saml.identity to true for the SAML (or SAML2) Login Module. In EM, click the Weblogic Domain drop-down menu, pick Security –> Security Provider Configuration, click the login module row and then the Edit button. Scroll down to the bottom of the page and the add the property mentioned above to the list of Custom Properties.

In order to propagate the change, restart the Admin server as well as the managed server running the web service.

Once this is done, whether or nor the SAML Subject exists in the identity store used by OPSS is irrelevant. It is going to be asserted and a Java Subject containing a user principal is going to be instantiated in the container.