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.
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.
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.