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.

Data Security and XACML

XACML is the key standard for fine-grained access control. I'm a big fan of the request/response model and how everything is normalized down to attributes. I also think that the XACML interaction model (PDP/PEP/PIP/PAP) has been very useful in discussing authorization architecture with customers. Good stuff!

One issue that I have with XACML is that there is no obvious way to address the most common customer authorization problem - data security. Most of the customers that I've met with over the past three years who were in the market for a fine-grained entitlements solution, were looking to address this issue. Basically, they had a large number of resources - customers, accounts, deals, documents etc. and they wanted to externalize the authorization.

XACML answers "Can this user perform this action on this resource?". Customers want to know "What resources can a user perform this action on?".

Why externalize to something like XACML in the first place? Don't the systems of record of these objects have access control? Of course they do, but there are a number of reasons why customers aren't using the OOTB authorization.

• Granularity - RBAC models are not fine grained enough to meet the business requirements
• Heterogeneity - In many cases there isn't a single SOR for the data. The data is virtualized so externalization is essential to consistency.
• System Accounts - Many of the access control models are tied to the user accessing the data source. In many cases, an application uses a single system account, so the OOTB authorization would be tied to that user. This means you can define the behavior per application, not per user (I guess this is a variation of granularity)

For resource counts which are relatively small, the PEP can simply call the PDP N times. This works if the PEP knows the list of possible resources a head of time (i.e. menu items or some list of accounts from another SOR) and that number is small - 10s or 100s or 1000s could be OK depending on the performance of the PDP - OES can do 1000s of authorizations at sub-millisecond latency. But there are definitely cases where the number of resources is in the millions or 10s of millions and this approach will not work.

Oracle VPD (Virtual Private Database) and the RLS (Row Level Security) package uses an approach which I think can be used as a model for solving these types of use cases. Essentially when configured, the RLS returns a WHERE clause which the database then applies to the query.

Generically, the model is as follows:

1. Data Access Object (DAO) receives request (getCustomers for Josh)
2. DAO PEP intercepts the request and calls the PDP (can Josh getCustomers?)
3. PDP evaluates policies and returns response ( Yes, but only in dept 1234)
4. DAO PEP enforces the decision by modify the search criteria (getCustomers WHERE dept=1234)
5. Query is processed by SOR and result is returned

The "Only in dept 1234" seems to fit very nicely into XACML Obligations. There are some challenges in how to combine obligations - is the behavior AND or OR? I'm not saying that this is a perfect solution - only the best use of the current today.

Conceptually, the authorization system is returning a list of filters (attribute-operator-value) and delegating the responsibility of applying those filters to the data source. The PEP can then translate the filters into an appropriate language specific (SQL, LDAP, XPath, XQuery) expression.

Do you think this approach can work with XACML as is or is there a need for XACML to do something different?

Where have all the PEP's gone?

I've been having a lot of conversations which customers lately around integrating security services - mostly authentication and authorization - into their enterprise. They've been asking basically the same question - "Where are the Policy Enforcement Points (PEP)?"

First of all, I think this is more than a simple product road map question. For the record - Oracle Access Manager (OAM) supports a large number of Web Server/Operating System platforms. Oracle Entitlement Server (OES) has a Security Module (SM) for a number of Web Servers, WLS + layered products, IBM WebSphere, Oracle VPD support and even Microsoft SharePoint.

Product Management can correct me, but this seems like a pretty good list. So what is the issue?

I think the issue is that many of the customers that I talk to are using a number of application frameworks to build their applications (Struts, JSF, Spring, Hibernate, ADF etc). This means that they want an application framework specific PEP and not a generic Java, JACC, JEE or even Application Server specific PEP. Even though these frameworks are built on these standards, implementing a policy enforcement point at those levels means that the access control policies are going to be based on resources like Java Permissions, Java Servlets or Enterprise JavaBeans. If the goal is to author access control policies which are closely aligned to the business, then securing these lower level resources, especially in the context of an application framework, is practically a non-starter.

So, why not just create PEPs for these application frameworks?

Easier said than done! Not every application framework has a tidy way of wedging an external PEP into the request flow, or reusing the application framework's PEP to call out to a 3rd party PDP. In most cases, externalizing authentication is pretty straight forward, but if you want 3rd party authorization, especially around framework specific objects (Struts Action, JSF UIComponent etc), it will get messy!

Oracle's Application Developer Framework (ADF) and Spring with SpringSecurity (ACEGI) both have the ability to externalize authorization built in, though ADF is based on standard Java security and ACEGI isn't.

In other cases, where there's a will, there's a way. I've pulled together a catalog of some approaches for integrating into various containers. Take a look. I've used these types approaches in the field to integrate various PDPs.

So, what do you think?

- Is dependency injection (aspect oriented) a reasonable way to add this type of fine grained authorization?
- For Struts, is creating a custom RequestProcessor a workable solution? It would allow for authorization at the Struts Action level.
-Is there something short of a custom Render Kit which would meet the requirements for JSF?
-Is a generic approach like JSP tag libraries best?