ABAC Authorization Control Illustrative Example

ABAC is an attribute-based trust management 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 behind it (the provenance)
  • Supports multiple authentication frameworks as entry points into the attribute space

The reasoner is tuned for ABAC's logic and is more efficient than a general reasoning engine.

This page outlines these features using a scenario-driven tutorial approach. We describe the model in more detail elsewhere and there are  several papers about ABAC as well. This page is intended to sketch the power of ABAC.


Consider the ACM using GENI to run a contest like the University of Santa Barbara's  International Capture the Flag Contest on a larger scale. Security experts from several universities acting under ACM auspices will configure a large network of machines as a playground for intrusion testers. They will create a slice 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 or the world - are granted access to the slice and a scavenger hunt ensues. The team that most completely audits the security of the network, by capturing the most sensitive data (taken either way), 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 contestant 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.

We assume that an empty slice has been created by a GENI principal, and the ability to configure (add, remove, modify resources) the slice and access it are controlled by different attributes issued by that principal. For simplicity of exposition we assume that these GENI attributes are sufficient to acquire the resources being added to the slice.

In this example, we will describe the assignment of ABAC attributes to facilitate this scenario, how those attributes are translated into credentials and how those credentials are exchanged to negotiate access.

The TIED Attribute Explorer

The TIED attribute explorer is an application that represents the ABAC attribute interrelationships graphically. Users can create attributes and rules from various principals and see how those credentials interact. There is a graphical query engine that allows one to see which prinicpals have a given attribute and how they can prove it.

The explorer can generate credentials for a principal if it has that principal's key (in some format). Credentials are used directly by ABAC's negotiation protocols to secure access. While this function makes the explorer useful as a simple attribute configuration tool, we do not suggest that it is reasonable to use for large scale attribute administration. It is primarily a tool for visualizing fairly simple relationships.

Throughout this example we will make use of screenshots from the program to illustrate points. The program is itself is available via a  Web Start/JLNP link. Clicking on that link will start the program on your desktop if your machine is configured to use Web Start. Instructions for that configuration are  available on the web. Feel free to follow along.

NB: These screenshots are a little out of date. Updated soon

ABAC Notions: Principals and Attributes

At its core, ABAC assigns attributes to principals. A principal represents an actor in the system: a researcher, a component manager, etc. Attributes about a principal determine what an pricipal is authorized to do. A principal that can prove they have a given attribute can carry out a given action. In the simplest case a principal has an attribute because another principal asserts it (principals can also assert attributes reflexively, but this is not common). We will see how more complex assignments of attributes occur throughout the demo.

In the attribute explorer, principals are ovals and attributes are boxes. The direct assignment of an attribute is conveyed through an arrow.

Attributes for Slice Control

First we consider the attributes used to control the contest slice. The GENI principal will have created these with the slice, and much of the ABAC configuration that follows is delegating the authority to assign other principals those attributes. We name them GENI.CTFaccess and GENI.CFTadmin for the abilities to access and administrate the slice respectively.

An attribute name encodes the controller of that attribute and the attribute name being granted. The controller is a principal (identified by a unique identifier/key that the explorer maps to a readable string) and the attribute name is a string. Prinicpals using each others attributes agree on the semantics of the names. The GENI.CTFaccess attribute is controlled by the GENI principal and is named CTFaccess.

Assigning Attributes to Principals Directly (local GENI administrator)

In order to assign that attribute to a principal using the explorer, one connects the principal representation (an ellipse with that prinicpal's name in it) to the attribute in question. The following shows the BBNAdmin principal being assigned the GENI.CTFadmin attribute.

Every arrow we draw in the explorer represents the creation of a credential (though some arrows will appear later without being drawn that do not represent credentials). A credential is a statement about either a principal having an attribute (as in this case) or the relationship between a attributes as we see below. The credential is always issued by the controller of the attribute at the head of the arrow (GENI, in this case) and contains enough information to recreate the edge and nodes in the graph. In this case a credential saying "the BBNAdmin principal has the GENI.CTFadmin attribute, signed the GENI principal" is created.

The BBNAdmin can now configure the contest slice.

Surprisingly, that administrator does not possess the GENI.CTFaccess attribute. While we could assume that the administrator privilege subsumes access rights, that makes queries about users who have asserted access rights more difficult as the query engine needs to understand the semantics of access. Rather than do that, the GENI principal connects the two attributes by drawing an arrow from the GENI.CTFadmin attribute to the GENI.CTFaccess attribute.

Drawing that line creates a credential that says "Any principal that has the GENI.CTFadmin attribute has the GENI.CTFaccess attribute, signed GENI". More colloquially it says "the GENI principal asserts that CTFadminsitrators can access the CTF slice." Notice that only the GENI principal can create such a credential and have it be accepted as valid: GENI controls the GENI.CTFaccess attribute, and any assignment of that attribute signed by a different principal is invalid on its face.

Any attribute reachable by following edges from principal to attribute is possessed by that principal. Now the BBNAdmin principal has both the GENI.CTFadmin and GENI.CTFaccess attributes.

Delegating Administration to ACM

At this point the GENI principal has placed a principal in a position to configure and access the contest slice in case of trouble, but the rest of the access control is to be the business of the ACM principal. Delegating this authority is again expressed by relating two attributes, one controlled by the GENI principal and one by the ACM principal.

In the explorer the GENI user creates an attribute named ACM.CTFofficial and draws an arrow from it to GENI.CFTaccess. Note that the GENI user cannot draw lines into the ACM.CTFofficial attribute, because that attribute is controlled by ACM, but it can delegate control of its own GENI.CFTadmin attribute.

Like all drawn arrows, this represents a credential; that credential says "any principal having the ACM.CTFofficial attribute has the GENI.CTFadmin attribute, signed the GENI principal." Because the GENI principal cannot control how the ACM.CTFofficial is administered by the ACM principal (or even that such an attribute exists) this is a delegation of power.

Once the delegation has been made (and this does assume an out of band communication between the delegator and delegee, but there's an implication of trust there that makes this communcation reasonable) the ACM principal can begin authorizing officials who will have the right to administer the contest slice.

We show this by opening a new attribute domain associated with the ACM principal, creating the ACM.CTFofficial attribute and connecting some principals to it as before.

Now we have two prinicpals granting credentials that grant attributes to principals across domains. Following the inter-principal connections can be confusing, so the explorer allows users to search the space from a global view. This shows what authorizations are possible, given the attributes that the explorer knows about. To activate this feature, the user types an attribute to track in the query window, and the explorer tracks relevant changes. A sample window showing the results of a query for GENI.CTFadmin appears below.

The query window shows all nodes reachable from the query attibute in a graph with all the arrows' directions reversed, and keeps the display up to date so the user can see the results of changes to the graph.

Delegating for Contestants

In granting contestants access we have several goals:

  • The ACM principal wants some control in authorizing contestants
  • The ACM principal does not want the overhead of vetting each contestant
  • Universities and other institutions want a role in deciding who to allow into the game

In order to meet these goals, an intuitive system is for the ACM to designate certain representatives who can designate contestants on the ACM's behalf. These representatives can choose contestants however they like. By granting this power the ACM gives these entities the control they want, and minimizes its direct involvement.

In ABAC, this is represented as a linked attribute. In the explorer, one can create such a linked attribute in a way similar to creating a standard attribute. Here the GENI principal creates such a rule that allows ACM representatives to designate contestants, all of whom will be granted the CTFaccess attribute.

The wording for the credential is a little complex, but it says "Any principal that has a P.CTFcontestant attribute where P that has the ACM.gamerep attribute has the GENI.CTFaccess attribute, signed GENI". More simply, the ACM principal can designate representatives by giving them the ACM.gamerep attribute; when those representatives give another principal their .CTFcontestant attribute, the principal with that attribute is given the GENI.CFTaccess attribute. ACM representatives can grant access to the slice.

An advantage of this is that it creates a new administrative group - ACM's game representatives - that can be useful in other contexts. For example, this same group of representatives can designate contestants for other competitions or other attributes relevant to the capture the flag contest without further changes by the ACM. Delegating through individual ACM attributes would require continuing work by the ACM.

The ACM principal designates representatives by creating the ACM.gamerep attribute and connecting principals to it. The screenshot above includes that a change in the ACM worldview.

Independent Contestent Administration

This section shows how ABAC supports independent selection of contestants by the principals above. Each demonstrates different policies taken by the representatives.

Direct Nomination

The USC principal designates individual contestants directly. In the explorer we create a scope for the USC principal and create the following attributes, principals, and connections:

Looking at the GENI.CTFaccess query, we see this subgraph representing the new policies:

Of particular interest is the dashed blue line connection the (ACM.gamerep).CTFcontestant attribute and the USC.CTFcontestant attribute boxes. Unlike the other arrows in the graph, this connection is deduced from credentials rather than being specifically represented by one. The text overlaying the snapshot shows the connection between the rules and credentials as well as the implied edge.

Again, a principal has all the attributes it can reach via edges (implied or explicit) in the graph.

This direct nomination is the simplest way to had out credenitals.

More Complex Delegations

All the delegation mechanisms discussed so far work within the delegated principals. So one can directly delegate directly by

Which allows all students to participate

Or indirectly by

Which allows Mike, an ACM officer to select participants.


A query for principals with the GENI.CTFaccess query, given the setup above looks like:

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 seeking authorization to access the slice requires proving that faber has the GENI.CTFaccess credential. The slice has the following relevant credentials:



And faber holds:

The simplest exchange is that faber requests access, the slice builds a graph of all the credentials that might be part of a path from principal to credential, and sends them to faber. That message contains credentials that represent this graph:

While it sounds complex to say that the credentials represent the graph, the process of assembling the graph is trivial. Each credential fits to the others in only one way.

When faber receives the candidate graph, it can check the signatures of all the credentials and satisfy itself that the graph is well formed. (It may need to find GENI's or ACM's public key, or the slice may have included them.) Faber's only credential fits on the graph and establishes a path from faber to the GENI.CTFaccess credential. Faber adds the credential to the message and returns it to the slice. Once the slice confirms the signature, the two parties agree that faber can have access.

The completed graph in that message looks like:

The collaborative process is completely characterized by adding nodes to a graph in a simple manner. Though the policies experessed by the system are complex, the process of validating any given prinicpal posses an attribute is very simple.

Furthermore, both the rules and attributes are distributes throughout the network. The slide will be ignorant of the fairly complex rules that the UCLA principal has instituted until a principal from that university authorizes itself. Note that credentials are simply signed statements (perhaps with a validity time). So the slice can keep local rules from various domains and send larger initial graphs if it chooses to.

If the environment is open, the GENI principal can simply publish the relevant credentials encoding its rules for CTF slice 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.


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.