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:
- Grammar to express very fine-grained access control policies.
- Rules containing variables captured from subjects and resources. Facts such as location, time and date included.
- Adjudication when rules combine or clash.
- 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.
iamfortress 
Hi,
I think you are missing the point. First of all ABAC is not a buzzword. It has been around for quite some time. Only recently has it been formalized by NIST through their 2012 and 2013 ABAC workshops which led to an ABAC report – the first step in a standardization process. Much like NIST standardized RBAC, NIST will eventually achieve the same with ABAC.
You mention that there are not formal specifications for ABAC. I beg to argue otherwise. The NIST special publication 800-162 on ABAC is an excellent foundation towards formal specifications.
Furthermore, when you state that “Blurring the lines, supposedly XACML implements ABAC, because attributes combine with decisions.”, this could not be further from the truth. XACML does implement ABAC (and it implements RBAC too). the 800-162 publication points, as a matter of fact, to XACML as a means to implement ABAC. Both XACML and ABAC use the same terms because both are about the same topic: fine-grained, extensible authorization (or dynamic authorization as you called it – and as Kuppinger Cole calls it).
Both XACML and ABAC use attributes as the basic building block. Attributes, in both cases, are key-value pairs e.g. role == manager. Attributes can describe a subject, an action, an object or contextual information. Both XACML and ABAC put forward the same architecture with the notion of a PDP, PAP, PIP, PEP, and so on. These terms pre-date XACML and ABAC by decades. They are standard architectural components. Both ABAC and XACML, lastly, promote policy-based access control whereby policies are used to bind together attributes to define authorization logic. ABAC stops there. XACML continues on to define the specifics of the policy grammar. XACML, for instance, defines the notions of PolicySet, Policy, and Rule. In other words, XACML is a technical implementation of a soon-to-be standard, ABAC. If anything, XACML helps sharpen the picture and gives practical advice on how to proceed.
Keep in mind that both ABAC and XACML were carefully defined and thought through by experts in the field (Vincent Hu from NIST in the case of ABAC as well as participants from Veterans Affairs, Axiomatics, Bank of America, Boeing, and more in the case of XACML).
What do I think about XACML? Well, I’m biased. I work in the field. All I can say is that we are getting an ever increasing number of requests from around the world.
Note: you mispelled the standard. It should be eXtensible… not xTensible. And regarding the “dead” blog post. It was written by an analyst who never looked into the standard and wanted to make a name for himself. If you want information on XACML, ask those who know.
LikeLike
As for the functional specs, any news?
LikeLike
Not that I know of Welkson.
LikeLiked by 1 person
David,
We can agree that NIST has provided a working definition of ABAC which is a (first) step toward standardization.
Click to access NIST.sp.800-162.pdf
A working definition is not functional specs so we still have a ways to go don’t we?
Your comments on the finer nuances of XACML & ABAC have yet to point me in the right direction (where are the specs?) though I’m still hoping that somebody can. 🙂
For a good example of functional specs, take a look at ANSI RBAC INCITS 359.
Regarding the XACML is dead post. The analyst didn’t look into the standard – really? Has he recanted? Why is that article still published? Are you suggesting there isn’t a controversy surrounding the viability of XACML as an enterprise authorization mechanism?
Keep in mind controversy isn’t necessarily a bad thing. It challenges our core beliefs and provides the opportunity to improve.
Thanks for bringing up the spelling error.
LikeLike
He hasn’t recanted nor looked into the standard any further. Let’s let sleeping dogs lie 🙂 There are great new initiatives such as OpenAZ and the ATT XACML implementation all moving to Apache as well as the Axiomatics ALFA language being donated to OASIS. We’re seeing more and more Fortune 500 companies adopt XACML and ABAC. Recently Gartner announced that 70% businesses would adopt ABAC by 2020.
LikeLiked by 1 person
That’s good info David – thanks.
LikeLike
[…] ABAC – Where are the Functional Specs? […]
LikeLike