An example attribute would be "employee is currently located in the US" and is trying to access a document that requires the person to be accessing the document in US territory.


Simple google search would give you the answer to this question.

Vendors like Axiomatics are more than willing to answer the question.

The US Government also has an opinion

You might have missed 1 Raindrop unless you follow the field, but I think it answers your question nicely:

It seems to me that the value of XACML and ABAC is really in the use cases that they enable. It's outward focused, and unlocks value through new kinds of services. . . .

The summary is that ABAC permits you to express a rich, complex access control policy more simply. Most access control policies (I'm looking at you RBAC) rely on ''someone'' somewhere updating a policy as employees move from job to job or responsibility to responsibility. People get added for temporary needs, and never removed. There is a huge back end to implementing the policy.

The simplest and coolest example I can cite is from a real world example. Turns out that the bouncers/bartenders at a bar were checking ID and were memorizing/copying the information from cute women. Then they would either stalk the women, or wait till the women had had enough to drink that their judgement was impaired and offer them a drive home. This is an opportunity for a bad thing to happen. The bar implemented an ABAC solution. When the women entered they submitted their ID to a machine that either issued a wristlet or tagged the credit card as over/under 21. The only information the bartender had was whether the person was legitimate to receive alcohol; access control (to alcohol) was decided based on a single attribute (over/under 21), without revealing any additional information.

ABAC, if implemented as part of an identity infrastructure means that when Mark Wallace moves from the developers group to the project manager's group, his access control rights will be updated because he changed supervisor, workstation, and job title, not because someone remembered that he had admin permissions and took time to update a configuration file somewhere. The HR department feels that it is very important to keep track of who my supervisor is, and they have a vested interest in keeping that information up to date; my permissions flow from those kind of organic decisions.

Disadvantages? There aren't a lot of deployments because it is still kind of new, and because you only get the full benefits when you deploy sufficient infrastructure. Vendors are still playing with the right implementation of the right protocols. There is a lot left to be worked out.

  • 2
    so... how did the system verify that the women looked like their id? what's to prevent someone from simply inserting a stolen id. – xenoterracide Oct 4 '15 at 16:45
  • 2
    Also seems like some of the complaints, sounds a lot like a problem I've described that people aren't doing RBAC right. When you change group/jobs, your roles should change. I've often noticed that most RBAC does no kind of "active role" and no kind of SoD, heck most of it doesn't even do "roles can have roles", or "roles have permissions". I don't think most RBAC is actually RBAC. – xenoterracide Oct 4 '15 at 16:51
  • While you bartender story is nice, there is nothing in there that could not be implemented using various other access control models; removing the need for a bartender to see an ID is hardly requires ABAC (it could even be implemented without even implementing an access control model). – Jacco Apr 14 '16 at 7:05
  • 1
    Also, while ABAC is solving some of the issue in RBAC (most notably the 'role explosion' issue), it also introduces new ones. To try and eliminate the new issues introduced with ABAC (most notably the 'attribute explosion' issue and, maybe more importantly, the lack of audibility), there is a NIST initiative, by Kuhn et al, to unify and standardize various RBAC extensions by integrating roles with attributes, thereby combining the benefits of RBAC and ABAC to synergize the advantages of each. In short: ABAC is not the silver bullet it is sometimes suggested to be. – Jacco Apr 14 '16 at 7:52

As an extension to the previous answer I want to add that there are definitely disadvantages ([philosophically] there is nothing without). I see the following:

  • Effort to define policies: You need to invest in the identification of the attributes that are relevant to make AuthZ decisions and mint policies from them. This might be considerable harder that just defining roles.
  • User training: Everyone might become an administrator in an ABAC solution, at least for his own data. There is not only a dedicated admin staff which takes care of AuthZ issues.
  • Technical implementation efforts. You cannot buy an install and run ABAC solution. Existing approaches like LDAP (ideally) do not require custom coding in your software or COTS. This is different with ABAC because the every PEP needs to ask a PDP and I know of no existing software which supports this, not even with standards like XACML.
  • What you are writing is simply not true. Past experience shows that it is cheaper and more efficient to externalize authorization be it with ABAC or with a framework e.g. Spring Security. It is more expensive to let developers write code than it is to define policies externally. Also, there are COTS available that require zero customization e.g. Axiomatics, Oracle, IBM, etc... Lastly, it is not true all users need to become administrators. Much like any other security product, there's a team behind the administration of the solution & a large number of users that aren't aware it's there. – David Brossard Apr 29 '14 at 21:27
  • It is more expensive to let developers write code, true. However, in the well known RBAC model, creating permissions and assigning permissions to roles is not a developer activity; they are defined externally, just as with ABAC. – Jacco Apr 14 '16 at 7:43

Mark C. Wallace in the other answer has given an excellent explanation. Here, I would try to give some of my personal (and philosophical) perspective on it.

  • Elimination of Human from the loop: Although not completely, ABAC eliminates (more accurately reduces) human from the access control loop by binding user attributes directly with policy towards permissions. In RBAC, we always need an administrative user to add/remove regular users from roles. This administrative overhead is possibly the highest penalty we pay while adapting RBAC.

  • Establishment of the missing link: Although RBAC did not talk about them, an implicit notion of attributes are still there. Changes of attributes are the reason behind the changes in role assignment. In RBAC, administrators manually maintains these changes while assigning or unassigning users to or from a role. ABAC recognizes these attributes as the missing link and highlights its presence in access control decision. Thus, ABAC provide more transparency while reasoning about access control. A philosophical perspective of ABAC

  • None of the standard models for RBAC (RBAC96, NIST-RBAC, Sandhu et al., Role-Graph model) have implicit attributes. There are various non-formalized extension that explore the use of attributes or parameters; some of these models require attribute administration, while others don not and instead rely on implicit or explicit subject or environment attribute and attribute values. – Jacco Apr 14 '16 at 7:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.