SOA Security - ADT or Crocodile Filled Moat?

I'm sitting here in the middle of the Moscone center as OpenWorld 2008 comes to an end. It's been a long week, but I wanted to take some time to capture some thoughts on my first open world presentation.

This morning, Eric Leach and I presented to an enthusiastic group on securing WebLogic applications with Oracle Access Management. As the "technical guy", I put together a demo of Oracle Access Manager, Web Logic Server, Oracle Entitlements Server and Oracle Web Services Manager all working together in a "best practice" architecture.

The demo covered a fairly common scenario: end-to-end security in a SOA. For example, the customer already has an investment in OAM, and they need to extend that security capabilities down to the rest of the architecture - applications, services and data.

In the past, I think that the temptation would be to use OAM. Prior to the emergence of the entitlements market, WAM was the only COTS solution for externalizing authorization. WAM products are most successfully deployed when focused on the problem of web SSO. Authorization and the centralized management of security policy is better handled by Oracle Entitlements Server - OES.

I used OES to provide authorization for JEE resources, JSP pages, and Web Services. Both OES and OAM used a common directory - Oracle Internet Directory - as a system of record for users, user attributes and group memberships. This information fed the policies enforced by OES.

In order to have these policies enforced correctly, the various enforcement points need to have the correct user identity. The problem of propagating identity across an SOA is not a simple one. In the course of the demo, I actually had to use multiple mechanisms. The identity from OAM to WLS is passed via OAM Session cookie. WLS then generates a SAML Assertion and passes it in the WS-Security Envelope to a OWSM. OWSM in making the very fine grained access control checks to OES uses a simple USERID_TOKEN (username). In theory, I could have used SAML for all of these interactions, but in many cases the full on SAML is too much.

Like most everything in security, there is no "correct" answer - no perfect solution. The solution that I demonstrated using OAM, WLS, OES and OWSM is an attempt at a reasonable 80% case - something which most customers could use as a jumping off point for defining their own solution.
I think a good analogy in information security to "How much security is enough security?" is "What alarm system should I buy for my house?". I like to think of the solution I outlined in the OOW session as the "ADT Starter Package" of solutions - pretty good for most single family residences. Most houses don't need a moat or guard dogs, but a military base needs more than a "Keep Out" sign...you get my point :)

Thanks again to everyone who attended the session and all of the questions. I gave out quite a few business cards, so I hope to hear from all of you. For those who didn't attend, once I get home, I'll add the relevant links form the session, and hope to drive some discussion around the solution.

Oracle Entitlements Server 10.1.4.3 Now Available

I'm glad to announce that we have released Oracle Entitlements Server (OES) 10.1.4.3 this week. OES came to Oracle via the BEA acquisition (where it was called AquaLogic Enterprise Security).

OES is a fine grained entitlements management product that allows you establish policies for how users can interact with and access things inside your applications and services. We call it "fine grained" entitlements because OES can protect anything inside an application; user interface elements, server-side transactions, database columns and rows, even "business" things like Reports, and Accounts.

OES 10.1.4.3 (or 10gR3 for short) is the result of several years of refining this product based upon tons of customer feedback. This release (aside from now having a new name and Oracle logo) has a couple of stand-out features:

1. Support for large policy sets and easy Delegated Administration. In OES we can now separate massive policy stores across multiple organizations and applications. Many OES (ALES) customers are setting up enterprise-wide authorization service layers and need a central place to manage policies for multiple LOB applications without everything in the same namespace. OES now has this ability to partition policies according to use and placement in the organization.

2. SharePoint protection. OES now ships a Policy Enforcement Point (PEP) that plugs into a MOSS 2007 environment to perform fine grained entitlements for web pages, web parts, lists, documents and other SharePoint "stuff".

3. Policy Simulation. The OES administration console now has a powerful simulation tool that lets a policy admin try out various scenarios and test policies without having to write an actual application to use them.

You can try out OES by downloading it from OTN here.

Also there is more information on OES here.