Version 8 (modified by 15 years ago) (diff) | ,
---|
ABAC Authorization Control Illustrative Example
ABAC is an attribute-based authorization system that combines attributes using a simple reasoning system to provide authorization that
- Expresses delegation and other authorization models efficiently and scalably
- Allows access requesters and granters to control how much information they reveal
- Provides auditing information that includes both the decision and reasoning
- Supports multiple authentication frameworks as entry points into the attribute space
ABAC Model
In ABAC, principals are created by authenticating to the system. A principal can be an individual (researcher, user) or larger authority (GPO, university). Prinicpals can use a range of systems to authenticate themselves. A principal can be the subject of authorization decisions and have attributes asserted about it by other principals.
An attribute is an assertion by one principal that another has a given property. The University of Southern California (a principal) may assert that Ted Faber (a principal) is a staff member (attribute). The attributes are scoped by prinicpal. This is represented as a digitally signed assertion.
A given prinicpal may also assert rules about how attributes relate. The GPO may assert that all USC GENI staff are also GPO prototypers. That delegates authority to USC add to GPO prototypers. In this case the delegated attribute (GPO prototypers) is given to prinicpals who also possess the delegating attribute (ISI GENI).
Finally, a principal may delegate at one remove. The GPO may assert that any NSF PI (any principal that the NSF has asserted a PI attribute about) can designate a principal as a GENI user and that user will be a GPO GENI user. The NSF can affect GPO GENI users by creating or deleting PIs; that is, by adding or removing assertions that a particular principal is a PI. Individual PIs can also directly designate local GENI users that are also GPO GENI users as above.
In this case, the delegated attribute (GPO GENI user) is delegated to principals who possess a one (or more) of a set of attributes (P GENI user for many P). That set is defined in terms of an authorizer attribute (NSF PI). Any principal with the authorizer attribute can assign the delegated attribute by assigning their local version of the delegating attribute (P GENI user where P has the NSF PI attribute). This links the authorizer attribute to the delegating attributes, and is often called a linked attribute.
It also points out that each of these delegations maps into an ABAC credential: an a signed assertion that can be used in a proof. Because each of these is a signed assertion of a fact or delegation of authority, connecting them in followinf the rules above corresponds to collecting those signed credentials, which establishes a trust relationship. ABAC credentials allow principals to negotiate directly about what they consider adequate proof. Below we show a simple visualization that represents constructing that proof as finding a path between two nodes in a graph; the actual negotiation protocol can be similarly simple.
Until an authorization decision needs to be made, all of these credentials can be kept locally and brought together to make the decision. Principals can also pass them around so they are available when needed. For example, when the NSF designates a PI, it may send that PI the signed attribute so that the PI can use it in authorization requests.
Visualizing ABAC Attributes
In TIED's attribute browser, we use some graphical conventions that may make these ideas easier to follow.
Principals are represented as circles. Our principals are labeled with simple, human-readable names, but in reality the assertions being made are being made about their globally unique identifiers. Those IDs are essentially a public key that identifies the principal (though some systems like Kerberos may have a more intricate implementation). Tools, including ours, represent principals using a readable name, but that's to help users of those tools.
Attributes are a rectangle containing the principal that asserts the attribute and the attribute name in dotted notation. The ISI.GENI attribute means that the ISI principal is asserting a GENI attribute. Again, ISI is shorthand for that principal's unique identifier, but the attribute names are simple strings.
The arrow connecting an attribute to a principal indicates that the principal has the attribute. We point the arror toward the attribute, indicating that the principal is in the group. The presence of such an arror indicates that the principal controlling the attribute has issued a signed assertion that the other principal has the given attribute. In the example ISI has issued an assertion that Ted is in ISI.GENI.
The image above shows a simple delegation. The GPO prinicpal has delegated the power to grant principals the GPO.demo attribute to USC by asserting that any principal with the ISI.GENI attribute also has the GPO.demo attribute. We now show how to demonstrate that a given principal has a delegated attribute.
The image above shows how to walk the chain of attribute assignments and delegations to prove a principal has a given attribute. In this case, it shows that Ted has the GOP.demo attribute. Proving a principal has an attribute is equivalent to finding a path from principal to attribute in the graph induced above. The edges all represent credentials that the GPO or Ted are in possesion of that can be combined to demonstrate that Ted possesses the GPO.demo attribute.
We use this representation in our configuration and visualization tool to help administrators.
A linked role is specified by a different attribute that links the authorizing attribute (in parens) to the delegating attribute by a dot, and the arrow completes the delegation. The following shows the graphical representation of walking a chain of credentials that inclides a linked credential showing that Ted has the GPO.demo attribute.
This introduces two kind of links to the graph. The first is a link that represents a linked role, the link from the red box to the GPO.demo attribute represents a new kind of credential - one that defines conditions for delegation (a linked role) rather than a direct delegation. The presence of that credential, and the credential indicating that the NSF asserts that ISI is NSF.funded creates the blue dotted edge. No single credential represents that edge; the presence of both a credential defining the authorizing set for GPO.demo and one showing that ISI is in the authorizing set creates the edge.
Once the edge is present, again, showing that Ted has the GPO.demo attribute is a matter of showing the path.
Distributed Authorization
In the examples above, creating the paths from principal to attribute that constitute a proof are all done assuming total information in the hands of the prover. ABAC does not require a prover to hold all such information initally and provides a negotiation protocol to gather it. We sketch that protocol here.
Getting access from an ABAC controller consists of constructing a proof that the requesting principal has a given attribute. The two endpoints provide parts of the graph to one another until they have constructed a graph using the rules above that contains such a path. Because edges define node-edge-node sequences in graphs, the building of graphs is an exchange of credentials.
As a simple case, consider creating a graph for the linked role example above. Initially TED has two credentials one signed by ISI indicating that TED has the ISI.GENI attribute and one signed by NSF indicating that ISI has the NSF.funded attribute. The GPO has a single credential signed by itself stating that principals who have the NSF.funded attribute are delegated the power to assign the GPO.demo attribute by assigning their local GENI attribute.
Ted asks for a resource from the GPO. The GPO's ABAC controller responds telling Ted that it is trying to prove that Ted has the GPO.demo attribute, and giving the relevant credential. Ted checks the credential and finds that it forms the following graph:
Ted now assesses its credentials and sees what edges it can add to the graph. In this specific case, its two credentials create an implied link that completes a path to Ted. Ted responds by sending those credentials to the GPO which checks the signatures and agrees that the valid graph allows access.
Attachments (30)
- example6.png (11.0 KB) - added by 15 years ago.
- example8.png (16.1 KB) - added by 15 years ago.
- example9.png (9.0 KB) - added by 15 years ago.
- example7.png (15.2 KB) - added by 15 years ago.
- example12.png (7.4 KB) - added by 15 years ago.
- example0.png (6.3 KB) - added by 15 years ago.
- example2.png (10.9 KB) - added by 15 years ago.
- example3.png (18.4 KB) - added by 15 years ago.
- example5.png (10.5 KB) - added by 15 years ago.
- example14.png (44.2 KB) - added by 15 years ago.
- example10.png (67.4 KB) - added by 15 years ago.
- explorer3.png (16.8 KB) - added by 15 years ago.
- example17.png (10.0 KB) - added by 15 years ago.
- explorer1.png (8.3 KB) - added by 15 years ago.
- explorer2.png (10.3 KB) - added by 15 years ago.
- explorer4.png (12.5 KB) - added by 15 years ago.
- explorer5.png (21.5 KB) - added by 15 years ago.
- explorer6.png (28.9 KB) - added by 15 years ago.
- explorer7.png (38.6 KB) - added by 15 years ago.
- explorer8.png (50.5 KB) - added by 15 years ago.
- explorer10.png (54.6 KB) - added by 15 years ago.
- explorer11.png (63.4 KB) - added by 15 years ago.
- explorer12.png (89.8 KB) - added by 15 years ago.
- example1.png (3.2 KB) - added by 15 years ago.
- example4.png (3.5 KB) - added by 15 years ago.
- example13.png (3.4 KB) - added by 15 years ago.
- example11.png (3.2 KB) - added by 15 years ago.
- example15.png (8.6 KB) - added by 15 years ago.
- example16.png (10.5 KB) - added by 15 years ago.
- explorer9.png (20.4 KB) - added by 15 years ago.
Download all attachments as: .zip