Thursday, December 10, 2009

Oracle Access Manager (OAM) and Oracle WebCenter Suite

I’ve seen a lot of customer activity recently around integrating Oracle Access Manager (OAM) and WebCenter. By integration, I mean protecting WebCenter with OAM so that specific WebCenter access can be governed by OAM policies and single sign-on between WebCenter and other OAM protected web applications is enabled.

Derick Leo recently created a very good tutorial on this integration (specifically OAM and WebCenter Spaces) for Oracle employees. In this post I’d like to walk you through a condensed version of what Derick laid out and add some commentary.

The first thing to realize is that this integration is 95% the same as integrating with any JAVA web application running in Web Logic Server (WLS). You need to install and configure an OAM WebGate on the web server fronting the app server, you need to install and configure the OAM identity asserter on Web Logic, you need to configure policies in OAM to protected the various parts of the application, and you need to configure an appropriate authentication provider in WLS to populate the (JAAS) principals.

The only WebCenter specific parts of the integration are: 1) Setting a flag in the WebCenter startup script that tells WebCenter that it is being fronted by OAM and 2) Understanding the use of JPS (Java Platform Security – A component of OPSS) by WebCenter and the relation between JPS and the Web Logic SSPI.

We begin by assuming you have installed and working instances of an LDAP directory (OID), OAM, Web Logic Server, and WebCenter Spaces itself.

We will also assume that you have Web Logic integrated with an HTTP web server of your choosing with an OAM WebGate installed on that web server. Here we will specifically assume you are using OHS with the OAM WebGate for OHS and the WLS plug-in for OHS.

OAM Policy Configuration
For purposes of illustration, I will be assuming that you are installing WebCenter Spaces to run under host www.acme .com.

1) Create a policy domain

2) Create a host identifier

3) In the policy domain, create the following protected resources

4) Create the following resources that we will make unprotected, public resources

5) Create a policy called “Public_URI_Policy” with the following specifics:
Resource Type: http
Resource Operation: Check GET and POST
Resource: Select all resources that you want to unprotect, listed above in step 4.

Under Authentication Rule tab, create a rule with the name Anonymous and authentication scheme OraDefaultAnonAuthNScheme

6) Back under the main policy domain configuration, under the Default Rules tab and the Authentication Rule subtab, create a rule with the name Default_SSO and authentication scheme OraDefaultFormAuthNScheme.

Configure the OID Authentication Provider for Web Logic

Create a new authentication provider called “OIDAuthProvider” of type OracleInternetDirectoryAuthenticator. Set the control flag to “SUFFICIENT” (more on this later).

Fill out the rest of the LDAP specific data under the “provider specific” tab. This is pretty straight forward and no different than a non-OAM WLS configuration that uses an LDAP authentication provider.

Configure the OAM Identity Assserter for Web Logic

Create a new authentication provider called “OAM Asserter” of type OAMIdentityAsserter. Set the control flag to “REQUIRED”.

Ensure that the obssocookie in the “Chosen” column under “Active Types”, then click save.

Next you must click on the provider specific tag of the OAM Asserter and fill out all the required OAM WebGate connection information. This is required because the OAM Id Asserter uses the OAM WebGate API to call the access server to validate the OBSSO token. The values for these should be consistent with the values for the WebGate protecting OHS. Example values are:

Transport: open
Application Domain:
Access Gate Password:
Access Gate Name: www.acme.com_AG
Primary Access Server:

Reorder WLS Providers

The order of the authentication providers in WLS is doubly important here.

First, authentication provider order is something that trips people up very often. It is important to understand the impact of ordering and the relationship between the order and the control flag assigned to each provider (REQUIRED, SUFFICIENT, or OPTIONAL). The WLS doc goes into this subject pretty well so I’ll just refer you to it:

The second less obvious impact of the authentication provider order is that it has an impact on WebCenter operations. At times WebCenter needs to query the user store and it does this through the Oracle JPS API and it appears that by default JPS picks up the user store information from the first authenticator in the list in the WebCenter domain. Now, this nuance can be explicitly overridden in the JPS configuration (jps-config.xml). However, it is definitely something to keep in mind.

So with that in mind, reorder the providers so that the OAM ID Asserter is first, followed by the OID Authenticator, and then by the default asserters and authenticators.

Configure WebCenter Spaces for OAM

Lastly, we must make a small tweak to tell WebCenter that it is behind OAM. The most obvious effect of this change is that a different landing/login page is displayed.

To perform the tweak:

1) Shutdown Web Logic
2) Open up the script located in your WebCenter domain
3) Add EXTRA_JAVA_PROPERTIES="-Doracle.webcenter.spaces.osso=true ${EXTRA_JAVA_PROPERTIES}"
export EXTRA_JAVA_PROPERTIES in an appropriate place in the file in amongst the other similar lines.

4) Restart Web Logic

When you go to the WebCenter Spaces landing/login page you should now see a login button in the upper right portion of the page rather than the login page itself that you see by default.

The login button will take you to the OAM login form and after providing valid credentials for a Spaces user, you should be able to use the application as before. You should also now be able to sing sign-on between WebCenter and other OAM protected applications, even apps running in containers other than WLS.

1 comment:

Note: Only a member of this blog may post a comment.