Version 4 (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.

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.

Until an authorization decision needs to be made, all of these attributes (signed assertions) can be kept locally and brogght 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.

No image "Basic.png" attached to TIEDABACDemo

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.

No image "Simple.png" attached to TIEDABACDemo

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 USC.GENI principal also has the GPO.demo attribute. Ted has the GPO.demo attribute because he is a USC.GENI principal and all USC.GENI principals are GPO.demo prinicpals. The arrow between ISI.GENI and Ted is the familiar assertion by a principal assigning another principal the attribute; The arrow between GPO.demo and ISI.GENI represents a signed assertion about the two attributes. That attribute is signed by the GPO principal.

No image "Creds.png" attached to TIEDABACDemo

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. It also points out that each arrow maps into an ABAC credential: an element that can be used in a proof. Because each of these is a signed assertion of a fact or delegation of authority, walking the arrows to an attribute corresponds to collecting those signed credentials, which establishes a trust relationship. ABAC credentials allow principals to negotiate directly about what they consider adequate proof.

Attachments (30)

Download all attachments as: .zip