Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

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.

share|improve this answer
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 at 16:45
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 at 16:51

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.
share|improve this answer
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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