ABAC – Where are the Functional Specs?

As a security architect I have long-awaited the means to express authorization policies using dynamic constraints – in a standard way. Over the years there have not been many models to choose from.

First came A Resource Access Decision Service, which had promise, but departed with CORBA.

Next came eXtensible Access Control Markup Language (XACML). Some believe it dead, and there are those who continue to promote. The jury is out.

What do you think about XACML?

Now the buzz is Attribute-Based Access Control (ABAC).

Blurring the lines, supposedly XACML implements ABAC, because attributes combine with decisions.

There are commonalities across the three models:

1. Grammar to express very fine-grained access control policies.

2. Rules containing variables captured from subjects and resources. Facts such as location, time and date included.

3. Adjudication when rules combine or clash.

4. Separation into multiple components, e.g. Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP).

The promise is reuse.

So where are the functional specs? I must understand and share.

“Despite the clear guidance to implement contextual (risk adaptive) role or attribute based access control ABAC, to date there has not been a comprehensive effort to formally define or guide the implementation of ABAC” NIST – ATTRIBUTE BASED ACCESS CONTROL (ABAC)

Ruh roh.

Until formal specifications are drafted, ABAC is useless because it’s non-standard and/or proprietary.

Back to square one – awaiting an industry standard dynamic authorization model.