Kerberos and WebLogic Server - decisions, decisions

I've been away from the blog for a while - I took some vacation time and I've been working on a customer that I can't really talk about. Have you missed me?

No? I didn't think so.

I got a call yesterday asking me to help a customer trying to get SPNEGO/Kerberos working between Windows desktops and WebLogic server. Yes, Kerberos again. After talking through what they're trying to accomplish today I found that they may have started out on the wrong foot to begin with.

Here's (more or less) what they told me they're trying to accomplish:

We have an app deployed in WebLogic and we want users that are in the domain to be able to access that app without being prompted for credentials.

That's it.

There are three ways that I can think of right away to address that requirement:

1. Use WebLogic's SPNEGO Identity Asserter to have WebLogic verify the Kerberos ticket
2. Use IIS to do the Kerberos bits and then use a simple HTTP header Identity Asserter to get the identity into WebLogic
3. Use Oracle Access Manager

Each of the solutions have their own plusses and minuses. The point of this post is to try to get them written down to help you (or someone else) make a sensible decision about which one to pick.

Before I get into it let me just say that Kerberos/SPNEGO is one of those technologies that when it works it's awesome, and when it doesn't it's incredibly frustrating to figure out what's gone wrong. Add to the mix the fact that so much of what's happening is automatic and so few people actually understand what's really happening under the covers/on the wire and you have a recipe for pain, frustration, annoyance and lots of hair being pulled out.

With that said...

WLS + SPNEGO Identity Asserter

WebLogic includes an the necessary bits that allow WebLogic to verify a Kerberos ticket if you want. I've blogged about it before and there are official docs as well as oodles of threads on Oracle forums where people are struggling to get it working. It definitely works and it has gotten easier over the years, but it's still harder than flipping a switch and being done.

The requirements basically amount to getting a Kerberos service principal registered, getting the necessary secret key onto the box running WebLogic and then getting WebLogic and IE to agree to do SPNEGO. Each of those steps is manual and it's easy to make a mistake.

Plusses: baked into WebLogic so there are no dependencies on any other software, Kerberos ticket is verified inside WebLogic itself and is thus about as secure as possible.

Minuses: can be difficult to setup & troubleshoot

Use IIS to do the hard stuff

One of the great things about Microsoft embracing Kerberos is that some very difficult, very complicated things have been reduced to a checkbox. To enable Kerberos in IIS you add the web server to the domain, then you go into the IIS console, edit the Security properties of a directory or of the server and check one box - "Integrated Windows Authentication". Windows and IIS do all the hard stuff for you including setting up the Kerberos principal.

Yes, I'm glossing over a few things, but not many.

Once you've got IE and IIS doing the Kerberos/SPNEGO dance two things remain: (1) getting IIS to proxy requests over to WebLogic and (2) getting WebLogic to trust IIS' say so on the user's identity. The former is address by the IIS WebLogic Plug-in. The latter is a simple Identity Asserter like the one I discussed back in January (I really need to put that code up somewhere on the Internets!).

Plusses: One checkbox to enable Kerberos in IIS

Minuses: You have to deploy Windows & IIS in front of every WebLogic server. The security issues I mention in my older post

Use OAM

OAM provides two relevant things - SSO across web sites and access control to those web sites. The former is all we're interested in here; when a user accesses the web server OAM will detect that they haven't authenticated yet and kick them into a process to do that. The latter allows you to decide who gets access to what parts of the protected web sites; it's not something we care about in this case but it can be very useful.

The upside to using OAM in this case is that you only need one or two IIS web servers somewhere in your environment to get Kerberos working. Each of the OAM WebGates plugged into your protected web servers will redirect users to one of those machines to figure out who the user is and then back to the protected web server. This works regardless of which flavor of web server you use - OHS, Apache, IIS, or Sun One. I've seen customers do this sort of thing with as little as one IIS server, but for redundancy you want a pair of IIS boxes somewhere in your environment and probably a second pair in a disaster recovery environment as well.

Plusses: Few Windows/IIS servers needed.

Minuses: Requires additional software (OAM WebGate) to be installed

In this particular customer's case they'd tried the first option already and had run into some issues. Because of those issues and because their requirements were still in flux I suggested that they try the second option (IIS doing Kerberos along with a username Identity Asserter). Your mileage may vary and you should probably ask a knowledgable person for advice before picking one of these options, but that's (part of) what we're here for.

I'm interested in what you think. Let me know in the comments!

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.

Prerequisites
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 www.acme.com

2) Create a www.acme.com host identifier

3) In the www.acme.com policy domain, create the following protected resources
/owc_wiki/user/login.jz
/owc_wiki/adfauthentication
/integration/worklistapp
/workflow/sdpmessagingsca-ui-worklist/faces/adf.task-flow
/workflow/webcenterworklistdetail/faces/adf.task-flow
/workflow/sdpmessagingsca-ui-worklist
/rss/rssservlet
/owc_discussions/login%21withredirect.jspa
/owc_discussions/login%21default.jspa
/owc_discussions/login.jspa
/owc_discussions/admin
/webcenter/adfauthentication

4) Create the following resources that we will make unprotected, public resources
/webcenter
/owc_wiki
/owc_discussions
/rss
/workflow

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 www.acme.com 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: www.acme.com
Access Gate Password:
Access Gate Name: www.acme.com_AG
Primary Access Server: a.acme.com:6021
SSO Header Name: OAM_REMOTE_USER

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: http://download.oracle.com/docs/cd/E12839_01/web.1111/e13707/atn.htm#SECMG172

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 setDomainEnv.sh script located in your WebCenter domain
(/user_projects/domains/workshop_domain/bin/setDomainEnv.sh)
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

Testing
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.