wiki:TIEDABACDemo

Version 18 (modified by faber@isi.edu, 10 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

ABAC facilitates authorization decisions by providing rules under which actors in the system, called principals, prove that they have certain attributes necessary for accessing resources. Which attributes are required for a given resource is a matter of policy outside the system. ABAC can represent delegation of various forms in scalable and separable ways that can be reasoned about formally. This section sketches the ideas behind ABAC. More information is available in the literature .

In ABAC, principals 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 a property of a principal created by the assertion of another princppal. 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, that is if USC asserts Ted Faber is staff, that is one attribute, if ISI also asserts that Ted Faber is staff that is a second attribute. Assertions are represented as a digitally signed statement, called a credential.

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.

Each of these delegations is expressed as 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 following 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.

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 arrow toward the attribute, indicating that the principal is in the group. The presence of such an arrow 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 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.

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

No image "Linked.png" attached to TIEDABACDemo

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.

No image "LinkedCreds.png" attached to TIEDABACDemo

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 credentials 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:

No image "Proto1.png" attached to TIEDABACDemo

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.

No image "Proto2.png" attached to TIEDABACDemo

During the negotiation, the GPO controller will need to get access to material to confirm ISI's signature on its credential, but it can presumably get that information from the NSF. The GPO controller knows NSF well enough to delegate authority to it, so it presmably has keying information for the NSF. If the keying information is public, Ted can pass along ISI's identifier/key as well.

The basic protocol action is to present the other side with part of a graph and reply by extending the graph as much as possible toward the goal. How that exchange pans out depends considerably on what the participants know beforehand and the access control policies they place on their credentials.

In an open environment, the GPO may publish its credential broadly. This means that requesters can start with enough information in their possession to create the entire authorization graph and include it in their request, reducing the number of exchanges. Conversely, a tight lipped requester may only disclose its NSF funding status to an requester that has some NSF credential. Such a requester would reply to the initial request with nodes indicating that the controller needs to prove a subordinate credential to the requester. On receipt of that proof, the requester would sahre the NSF.funding credential. Such an exchange continues as long as either side is able and willing to extend a graph and the initial request path has not been established.

This simple operation - building graphs collaboratively from validated credentials - can result in a broad range of negotiation strategies. It can be used to facilitate disconnected operation (by bounding the necessary interactions) or to maintain control over sensitive information.

Rich Auditing Information

The graphs generated by the authorization negotiation also act as detailed logs of what was allowed and why. A log entry containing the credentials and identifiers/keys used to validate them provides the complete set of information that led to the access control decision. Such logging is of significant use in assessing intrusions or demonstrating that an entity has adhered to a resource control policy. Such adherence may be important if a resource control policy is mandated by a funder or other contract.

Authentication and entering the ABAC system

A key aspect of ABAC's power is that its reasoning system makes few demands on the systems used to establish principals in the system. Principals need to have three properties:

  • An entity claiming to be a given principal can prove it interactively
  • Two entities referring to the same principal must be sure that they are referring to the same entity
  • A principal must be able to sign assertions

Any authentication system that establishes a public key meets these requirements, modulo a system to map various key types into a single identifier, e.g. hashing the bits of the keys in a common format. PGP keys and X.509 certificates directly meet those requirements (even self-signed X.509 certificates will do). Systems that attest user attributes, like Shibboleth can attest a public key/principal as an attribute. Such systems have the added utility that they can act as external credential stores as well.

Some principals never attest attributes, e.g., end users. Such users that are only identifiable by something like an InCommon eduPersonPrincipalName or kerberos name can be converted to the same principal identifier space by hashing the name along with the namespace (Kerberos, InCommon, etc.) into the same hash space as the public-key based systems. Some care must be taken with functions and hashspace sizes, but collisions can be made arbitrarily unlikely.

When possible binding to a public-key-based identifier is infinitely preferred.

An Example

Scenario

Consider the ACM using GENI to run a contest like the University of Santa Barbara International Capture the Flag Contest on a larger scale. The plan is for security experts from several universities to configure a large network of machines as a playground for intrusion testers. A slice will be created containing many (virtual) machines that will be configured with a variety of known shortcomings. Signed data is hidden in various places on the machines. Then players from many universities - in fact many players from across the country - are granted access to the slice and a scavenger hunt ensues. The team that most completely audits the security of the network, by capturning the most sensitive data, wins. There may be other scoring.

There are two classes of princpals that will be requesting access to GENI resources for this contest. There will be a comparatively small number of officials that will need allocation and configuration rights to the slice in order to set up and administer the game. There will also be the thousands or more contestants who will need access to the slice, but not configuration rights. Because of the large number of contestants, the ACM does not want to be directly in charge of vetting each one. Individual universities (and perhaps other sites) will be able to decide on the criteria to admit players from their institutions independently. Should anything go amiss - or any kind of cheating be detected - officials will want to know where the contestent came from and how they were admitted.

ACM is deliberately vague about qualifications for participation. Some universities may choose to make the contest open to any student at the university, or to any student in the local chapter of the ACM. Others may restrict participation to students enrolled in a prerequisite class. ACM delegates this decision by designating authorizers at each university.

ABAC Encoding (simple delegation)

For the purposes of the example, we assume that there is a GENI principal that has allocated an empty slice for the contest. That slice will be expanded and configured by principals with the GENI.adminCTF attribute and accessible by players with the GENI.accessCTF attribute. We now lay out the attribute policies for allocating these two attributes.

Because the set of officials is small, the ACM chooses to administer them directly. To support this the GENI principal delegates the adminCTF attribute to the ACM principal:

And the ACM principal authorizes principals by making them officials.

The ACM principal can add or delete officials independently, and those officials have admin rights to the slice automatically.

Of course, both the ACM and GENI will be assigning other attributes unrelated to this project, so their attribute space may be large enough that we provide a tool to maintain these spaces and their ramifications. Most of the images in this section are screenshots from that application. The image below is the result of a query for all users with the GENI.CTFadmin attributes from a set of attributes that includes those above. The two above are only the local attribute spaces of the two principals, below is a summary of both. (Principals who have the attribute are flagged by the bold red border, though all principals in this case have the rights).

ABAC Encoding (linked roles)

Because there are many more contestants than officials and the qualifying requirements are locally decided, the access rights to the contest slice are administered more loosely. This time GENI delegates access to the principals that ACM's CTFreps designate as contestants.

ACM now selects principals at each participating university that can authorize contestants (CTFreps).

The USC principal selects students individually:

The MIT principal opens the contest to all MIT students:

And the UCLA principal further delegates the authority to its local ACM officers:

Those officers then select individual students:

These local decisions make for a rich global attribute derivation graph. As before determining which principals can access the graph is done by a depth first search through the graph.

Negotiating Access

While the global graph is somewhat daunting in its complexity, it is important to realize that any single access decision requires the construction of only one path from principal to attribute. The two endpoints construct a graph together from their credentials, each of which represents an edge in the visualization above. For example, the case where faber is authenticating to the slice requires proving that faber has the GENI.CTFadmin credential. The slice has the following relevant credential:

And faber holds:

The simplest exchange is that faber requests access, the slice sends its relevant credential as a starting graph and faber responds with the completed graph:

Each side can check all the credentials to make sure the reasoning is sound. The credentials only fit together one way so they agree on the proof. At that point the authorization is complete.

If the environment is open, the GENI principal can simply publish the relevant credential for CTF slice admin (and general) access. Because each requester now knows the beginning of the graph, they are likely to be able to include the whole proof in their first request, removing a round trip time.

In addition, the completed graph completely reflects the decisions made to grant or deny access. These can be logged as expressive audit trials covering both the decisions and the reasons for those decisions.

Conclusions

This example has illustrated some of the key features of ABAC that make it scalable to operate and decentralized to administer while being practical to negotiate access.

Attachments (30)

Download all attachments as: .zip