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.