Integrating Oracle Access Manager with Kerberos authentication with fallback to an HTML form

Seems like it's the month of Kerberos.

We often see customers wanting authenticate users to Oracle Access Manager (OAM) with Kerberos, and fall back to HTML forms if the Kerberos authentication fails. There's an easy way to set this up, but it's not obvious how to do it.

I'm just going to describe the flow here, but that should be enough to help you figure out how to do the actual knob turning yourself. If you run into trouble feel free to ask a question here.

1. user accesses http://somemachine.mydomain.com/protected/
   
2. OAM redirects the user to http://trustedmachine.mydomain.com/oamauthenticator/
   
3. on trustedmachine the virtual directory /oamauthenticator/ is protected by IIS' built in Kerberos functionality, and only Kerberos. In other words you should uncheck the Basic, Digest and Anonymous checkboxes in the IIS console.
   If the user's workstation is in the domain and they are signed in then their identity will be passed to IIS via Kerberos. If the user's worksation is not in the domain or something goes wrong they will be presented with the 401 error page (see below)
   
4. the OAM WebGate will consume the identity from IIS and pass that identity to the Access Server
   
5. the OAM Access Server will search LDAP for the user
   
6. once the user's OAM session has been established they will be redirected back to http://somemachine.mydomain.com/protected/ along with the ObSSO cookie.
   

alternative flow for workstations not in a domain or if Kerberos fails:
In step 3 if the Kerberos authentication fails IIS will send the HTML file configured as the 401 page

You can create a plain HTML page that

• contains a conventional OAM login form - prompting the user for their username and password.
  
• submits to an URL on trustedmachine
  
• that URL will be associated with a conventional OAM HTML forms login authentication scheme
  

When the user fills in the form and hits submit:

1. the credentials will be passed to the Access Server
   
2. the Access Server will search LDAP for the user and bind to the directory to authenticate them
   
3. if the credentials are correct the user will get an OAM session cookie
   
4. the user will be redirected back to the original resource as in the normal flow above.
   

The only real trick here is using the custom error page in IIS. Remember that you have to use a plain HTML file for that file - you can't use an ASP/ASPX. That also means that you have to do anything dynamic in JavaScript.

Update: I fleshed this out some more in a newer post.

The Worlds Most Dangerous WebLogic Identity Asserter

...or how Josh stole my idea for a post in one paragraph.

In a recent post Josh said

There is another approach that, unfortunately, is rather common - use a Web Gate in front of WebLogic Server and use a very weak identity asserter or no SSPI connector at all.

I'd started writing this post before Josh wrote that and figured I'd post this anyway in hopes that my longer and more detailed write up is helpful to someone unfamiliar with what all of the terms and acronyms mean.

WebLogic Server includes a great security framework that provides five services - authentication, role mapping, authorization, auditing, credential mapping. There's also a sixth service called adjudication that kicks in if you have more than one authorization provider, but that's a story for another day. Out of the box WebLogic ships with a bunch of providers for each of those services.

The authentication service/interface does exactly what you'd think - takes a set of credentials, verifies them, and allows WebLogic to create a JAAS subject and principals for the user. Out of the box credentials are things like username and password against an LDAP directory. The ability to assert a user's identity without having their actual password, for example via a certificate, is also supported; in that case the authenticator is called an Identity Asserter.

So what is the worlds most dangerous identity asserter?

To answer that you have to understand the typical WebLogic deployment architecture. The recommended way to deploy WebLogic is to deploy a load balancer, two or more web servers (Apache, OHS, IIS) with the WebLogic plug-in, and then two or more WebLogic servers. Here's a diagram:

This architecture allows you to do a bunch of very useful things - gracefully handling single component failure, load balance across the components, scale up more or less linearly by adding additional WLS servers, and more.

Enterprise deployments also typically involve integrating with web single sign-on solutions like Oracle Access Manager (OAM), SiteMinder, or even Microsoft's Kerberos implementation included in Windows.

When you do the authentication at the web tier you need to convey the user's identity over to WebLogic and install in an Identity Asserter to populate the JAAS subject and principals. When you're doing authentication on the web server the most obvious way to write an Identity Asserter is to just consume the username HTTP header - after all the web server already did the authentication why bother doing anything more?

Why? Because if anyone manages to sneak by your web server they can impersonate any user in your user directory. Combine that with the commonly quoted statistic that two-thirds of security breaches are internal rather than from a hacker on the outside.

Let the implications of that sink in for a second...

Assuming you did everything else right in your app and environment your biggest risk is a bad guy inside your network. If you write an Identity Asserter that just blindly trusts an HTTP header you'd better be sure to do something to protect the WebLogic server.

I recently encountered a customer that wanted to authenticate their users with Kerberos authentication at IIS rather than inside WebLogic. They could have done the authentication in WebLogic with the SPNEGO authenticator but, for a variety of reasons, doing the authentication in IIS was a better fit for their environment. We wrote a very simple Identity Asserter that consumed the Proxy-Remote-User HTTP header, stripped off the Windows domain name and asserted the remainder as the username.

How do you protect the WebLogic Server in this architecture?

There are really two options:

1. two-way SSL between the web server and WebLogic Server
2. firewalling

Two-way SSL between the web server and WebLogic Server both protects the data sent by encrypting it but also prevents access to the WebLogic Server from any client that doesn't have an appropriate client certificate. The actual steps are covered in the documentation for the ISAPI plug-in for IIS and for the Apache module. Using SSL requires certificates and imparts a performance impact, the magnitude of the impact depends on the environment so we always recommend testing.

An alternative to using two-way SSL is to use a firewall to protect the WebLogic Server. You can use a network based firewall, the traffic filtering functionality built into your host Operating System, or WebLogic Network Connection Filters. No matter which of these you opt to use the objective is to insure that any HTTP traffic coming into the WLS server orignated at one of the Web Servers and not from somewhere else in your environment.


Update November 2010: Due to popular demand the source code to this Identity Asserter is available at https://sample-identity-asserters.samplecode.oracle.com/

OES discovery mode

How do you enable Discovery Mode in Oracle Entitlements Server?

from the documentation:

The ASI Authorization and ASI Role Mapping providers support a Discovery mode that helps make this task easier. Typically, these providers answer questions about security, but when in Discovery mode, the providers record information about those questions to build your policy (for example, what privileges and resources must be granted to view a particular web page).

To use Discovery mode, you must modify the command line that starts your Security Service Module by adding the following system properties:

com.bea.security.providers.authorization.asi.AuthorizationProviderImpl.discoverymode=true
com.bea.security.providers.authorization.asi.RoleProviderImpl.discoverymode=true

More information about discovery mode is in the ALES 3.0 documentation

Topic of 2010: Policy Lifecycle Management

2009 was the year of “security for the cloud”. No doubt people will keep beating that horse well into this decade. If you are looking for some very good and practical thoughts on the subject, Josh wrote a very good post on Fusion Middleware Security, multi-tenancy, and a WLS based platform as a service. You can find it here: http://fusionsecurity.blogspot.com/2009/11/cloud-security-for-paas-and-saas-use.html.

So, with that being said I’m here to declare to you that “Policy Lifecycle Management” is the security topic for 2010. So, what exactly do I mean?

Application are increasingly externalizing more and more of their security related functionality away from application code and into specialized tools and the middleware platforms they are built on. In general this is a great trend with many benefits. However, this has led to the proliferation of a whole set of various security policies in an applications platform that have to be maintained and kept in sync with the application itself as the application changes and migrates through its own lifecycle.

For applications built on Fusion Middleware you potentially have:

1) JSF Policies (JAVA security)
2) OAM Policies (web access)
3) OWSM and/or WLS WS Policies (web services security)
4) OES Policies (entitlements and authorization)
5) OAAM Policies (authentication and fraud detection)

This is just off the top of my head, I’m sure there might be more.

All these policies have to stay in sync with the applications they are supporting as the applications move through their own lifecycle of being built, being changed, being tested, moving through different deployment environments (Dev, QA, staging, production) etc.
Increasingly this is an area of challenge that the largest and best shops are dealing with. So, if that includes you, don’t feel bad, you’re in good company :)

Integrating Oracle Access Manager (OAM) with WebLogic Server (WLS) - Different Versions and Architectures

A very common decision confronted by customer is how to integrate WebLogic Server with their Oracle Access Manager (OAM). The main question here is "Identity Assertion vs. Authentication". An identity can be established in WebLogic Server two ways - by providing credentials (authentication) or by providing a token (identity assertion). If you're authenticating with OAM via WLS directly, then you don't need to install a WebGate in a WebServer protecting WebLogic Server (or have a Web Server at all). If you're doing Identity Assertion, then you do need a Web Gate in a Web Server, since that component will generate the ObSSO cookie that will be consumed (asserted) inside of WebLogic Server.

The specifics of the each of these scenarios varies slightly between Oracle Access Manager 10.1.4.2 and 10.1.4.3. In OAM 10.1.4.2, the authentication scenario is referred to as Authentication for Mixed Web and Non-Web Resources. This some what confusing name does underscore an important point. WebLogic Server has a single set of providers for all resource types, so if you have other clients (ejb/rmi) that need to authenticate, their credentials will also be validated against OAM. It's also worth noting that in 10.1.4.2, the user will get an OBSSOCookie which can be used to perform SSO with other OAM WebGates. In the 10.1.4.3 OAM+WLS integration, called Configuring Single Sign-On in Oracle Fusion Middleware - Deploying the Oracle Access Management Solution, the user will get only a JSESSIONID cookie - the WebLogic Server cookie.

The identity assertion scenarios are also slightly different. In 10.1.4.2, the Identity Assertion scenario called Authentication for Web Only Resources, the OAM SSPI authentication provider is used to retrieve the groups from LDAP. This is a call from WLS to the access server and then from the access server to LDAP. In 10.1.4.3, Configuring the Oracle Access Manager Identity Asserter for Single Sign On, you can use any WLS Authentication Provider to work with the assertion (OBSSOCookie) from OAM. The most common configuration is to pair the OAMIdentityAsserter with the OID Authentication Provider. The difference here is that the call to validate the user and retrieve their groups goes from WLS to LDAP directly - not through OAM. There are pros and cons to both. The advantage of the 10.1.4.2 architecture is that the connectivity to LDAP is funneled through OAM, so WLS instances can share LDAP more efficiently. The downside is that this requires an extra network hop, and extra configuration.

There is another approach that, unfortunately, is rather common - use a Web Gate in front of WebLogic Server and use a very weak identity asserter or no SSPI connector at all. In this model, applications or the identity asserter is most likely directly reading the REMOTE_USER header. Its definitely not a best practice to trust a clear-text username to establish identity. The exposure is that someone with knowledge of the solution can easily impersonate the identity of any user if they know their username. There are a number of ways to mitigate this risk like using a WebLogic Server connection filter or running WLS on the same machine as the WebGate and only configuring WebLogic server to listen on the loopback address. This approach may not make sense if the whole purpose of the web-server is to provide defense in depth by moving WLS behind a firewall.

Finally, in the analysis of which approach and which version of OAM SSPI connector to use, its worth noting that 10.1.4.3 is all Java, and runs on "All Weblogic Application Server 10.3.1.x supported platforms". My basic approach is that the 10.1.4.3 integration is simpler and more aligned with the way that most customers use WLS and OAM together. I would look at 10.1.4.3, IdentityAssertion with the WebGate as the 1st best option.