Authorization Decisions - To Pre-Cache or Not to Pre-Cache, That is the Question

There is a common pattern of entitlements solutions which "require" authorization decisions to be pre-cached. What I mean by pre-cached is that at startup, all of the authorization decisions for all of the users for all of the resources are loaded into an in memory cache. This in-memory cache can be either local to the application or in a central location(s). There are a few reasons why to do this. The most obvious is performance - finding a entry in a HashMap should be very very fast (sub microsecond). The other reason I've heard is a high availability requirement. The in-memory cache is also backed-up onto disk (securely) so that in the case that the user can authenticate to the system but the systems that the PDP needed information from (PIPs) are not available, a decision can be returned.

To be fair, I'm not sure that this pattern is common across all customers, but I have seen it many times in Financial Services. This makes a lot of sense...very fast, very available authorization solution - fits well with things like front-office trading systems. So, what's the problem?

So there seems to be a couple of issues with this model.

• Issue 1 - Update latency. If there is a change, how long does it take to get that change to be enforced in an application? Well, it depends on the scope of the change...for example, if a country changes the rules on what constitutes an adult or what constitutes legally married, then you may have to re-calculate the entire cache, and this can take a long time...hours, days? If its a more isolated change, like a privilege on an account, then the change is more isolated, but this touches on the second issue
• Issue 2 - Cache consistency. Since this model is really for very fast, very available solutions, you're not going to have one instance of the cache. So, now you need to make sure that you've updated all the copies of these records, and probably need to make sure that its done transactionally...don't want different behavior based on which server in the cluster you hit. These first two issues can be solved with a really advanced distributed cache, but, the third issue and the one that seems to be the "killer" for pre-caching
• Issue 3 - Context based authorization. Simply, "What if the authorization decision depends on some information I don't know until request time?"

Sorry, for the long preamble, but what I really wanted to talk about is this third issue of context based authorizations working in conjunction with pre-cached authorization data/entitlements. By definition, since it can be known before hand, the information is static - groups the user has, accounts the user has access to, organizations the user belongs etc. Maybe as an alternative to pre-caching, get this information once, at authentication time and store it....where?

The simple answer would be in the application session, but what I've done on a number of occasions, and has worked very nicely is stored it in side of the Subject as Principal objects. This approach covers most of the same HA use cases as pre-caching with disk back-up, except in this solution if those systems are down when you try to authenticate you won't be able to login - depending on how you set the JAAS control flags. Also, this lends itself very nicely, in the case of OES, to the creation of a custom authentication provider - basically a JAAS Login Module. Its purpose is to go fetch the static information and hold onto for the duration of the JAAS Subject. This is effectively the same as the session. This approach also adds "no time", since most authorization requirements don't include authentication. The business requirement is that transactions are processed quickly - sub ms - and they will be since all of the information is stored inside of the JAAS Subject, in memory. Also, the latency of change goes way down...the user gets new entitlements every time they log out.

Now that I've re-factored the static data into the JAAS Subject adding context based authorization is pretty straight forward. The new "policy combining algorithm" is in most cases allow if the static entitlements are granted and if there are context based authorization policies, those policies must evaluate to "grant". In OES, this can be done by:

DENY (//priv/all, //sgrp/foo/allusers, //app/foo) if not static_entitlements_granted()

In this model all of the logic is burried inside of the custom evaluation function, but I could have used attribute retrievers to parse the Principal objects in the Subject and exposed more of the logic into the policy.

DENY (//priv/all, //sgrp/foo/allusers, //app/foo) if not "ent1" in [user_entitlements]

So now that the existing rules are in place, just go add some new context based authorization

GRANT (//priv/read, //sgrp/foo/allusers, //app/foo/sensitive_materials) if authentication_method = "strong"

Context could include network, authentication method, user limits, historical patterns (OAAM), time of day etc.

In order for this type of model to be a true replacement for pre-caching, it assumes that the underlying authorization engine is fast...that it can do authorizations in the sub-ms range. I can't disclose any confidential information in this forum, so you'll have to draw your own conclusions about the performance of OES. I can say I've built solutions like this with a number of customers, and they've been very pleased with the result.

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.