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?