Version 25 (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
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.
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. 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 would prove it.
The explorer can generate credentials for a principal if it has that principal's key (in some format). Credentials are changes 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.
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". Notice that only the GENI principal can create such a credential: it controls the GENI.CTFaccess attribute, and any assignment of that attribute must be done by the controlling prinicpal.
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 roles, a natural 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 comples, 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.CTFrep 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. Below is an example designating the UCLA, USC, and MIT principals as representatives.
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:
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)
- 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