TIED / ABAC Architecture and Applications

We discuss the general architecture for applying ​Attribute Based Access Control to the TIED/GENI system. We lay out the general architecture of the authorization system and then provide worked examples how the system can be configured to implement several access control systems, including the DETER Federation Architecture (DFA)'s level naming system, a centralized (but fairly scalable) GENI certification system, and the several Slice Based Architecture scenarios discussed in the ​PlanetLab GENI SFA design document. We also describe how the ABAC realization of these policies is more expressive than the existing proposals.

ABAC proves attributes about principals scalably, expressively, according to well-defined semantics. We have described the ​basic operation of ABAC. This document outlines the ABAC principals, how they relate to GENI actors and illustrates the flow of operations and authentication information in slice manipulation.

We talk of the ABAC authorization negotiations as happening outside the simple request-response paradigm of the various GENI SBA interfaces. We believe this is correct for two reasons:

• Though many authorization decisions will be as simple as checking credentials supplied by the requester, some authorization decisions will be more complex and require actors to gather information from other sources or provide more information about one another before releasing all information - all of which is supported by ABAC. By separating these interactions from the simple SBA operations, we allow room for more complex interactions when we need them, while keeping simple interactions simple.

• We expect that other GENI systems and subsystems will find these operations useful - for example granting access to the measurement subsystems or OMIS data. Separating the authorization system insulates the concerns of an authorization system from the operative system.

TIED Authorization Architecture

The TIED authorization architecture brings together the GENI actors who participate in slice allocation and a set of ABAC prinicpals and attributes and rule. The attributes and rules vary with policy (and some policies require more principals than the simple ones), but the core principals in the exchanges remain the same. The GENI actors are:

• A researcher who wants to create a slice
• A slice manager that will coordinate creation of a slice
• The slice to which resources will be attached
• The various resource contollers - aggregates and components

One can blur the line between the slice manager and the researcher, but it somewhat aids the intuition and mapping to the existing models to make it explicit.

Each of these is also an ABAC principal. It is pretty obvious that most of these are principals who take part in the authorization decisions. It may be surprising that the slice is a principal; it is helpful to have that principal available as a delegation point. An ABAC principal is the object of an assertion or a delegation, and it is helpful to have a principal to which the researcher and other authorization players can delegate, rather than vesting all slices a researcher is creating with the researcher's full credentials or vesting the slice manager with the union of all the principals' credentials (that they choose to delegate to slices) that it manages slices for. This should be clearer as we walk through the operation below.

Flow of operations

The basic operations in using a slice or running an experiment are:

1. Create an empty slice from the slice manager (slice manager checks researcher credentials)
2. Researcher delegates attributes to the slice
3. Researcher requests operation on slice (slice manager checks researcher credentials)
4. Slice manager operates on various aggregates to carry out operation (aggregates check slice credentials)

As a researcher may perform many operations on a slice - creating it, expanding it, configuring it, restarting it - steps 3 and 4 will cycle.

The Slice Principal and Delegation

The appearance of the slice as principal facilitates three properties of the system that we argue are useful: it allows researchers to control what authority possessed by the researcher can be exerted on bahalf of the slice, it allows researchers to combine or transfer slice authority, and finally it constrains the amount of authority that the slice manager can exert on its own behalf.

A given researcher is likely to have a range of authority/attributes available to him or her, but probably wants to constrain individual experiments to only exert some of that authority. The possessor of a security clearance will want to perform unclassified experiments. Delegating authority explicitly to the slice ensures that a given slice can only exercise that authority not the full authority of either the reseracher or the slice authority. The slice prinicpal provides an entity to which those attributes can be delegated.

That delegation is functionally distinct from the operation of the slice manager. The researcher can issue certificates delegating whatever authority/attributes it chooses to without the slice manager needing to understand the semantics or format of them. (For sensitive attributes, a slightly more involved delegation procedure is required.) This frees the slice manager from dealing with these credentials beyond loading them into its ABAC negotiator for when it acts on behalf of the slice. If the researcher is willing to publish the credentials, it need not pass them to the slice manager at all.

This separation of delegation has another significant benefit. Researchers can combine or transfer slice authority. A long lived slice may change owners as the graduate student responsible for it graduates or a programmer changes jobs. ABAC allows the slice to exert the attributes of the new "owner" by delegating a subset of that new owner's attributes to the slice (and allowing the old attribute delegations to time out). If configuration of existing resources (and perhaps maintaining control of those resources) requires different attributes, a professor or higher ranking authority can create a slice, then pass control of it to a student or subordinate who has authority to maintain and configure the resources, but not grow the slice.

In addition to simple delegation of slice control, ABAC allows a slice to be imbued with attributes from more than one principal, directly. A slice can be given delegated power to carry out operations that neither principal can do alone.

Examples

To demonstrate the expressive power of ABAC in GENI terms, we lay out several example policies as ABAC configurations. Notation follows the ABAC papers:

P1.attr <-- P2

Principal P1 assigns attribute P1.attr to P2. "P1 says P2 is attr."

P1.attr1 <-- P2.attr2

Principal P1 assigns attribute P1.attr1 to all principals that P2 has assigned P2.attr2, that is all principals with attribute P2.attr2. "P1 says any principal that P2 says is attr2 is attr1." Note that the attr1 and attr2 strings may be the same. "GENI.researcher <-- DETER.researcher" encodes the policy that GENI recognizes all DETER researchers as GENI researchers.

P1.attr1 <-- (P2.link_attr).attr2

Principal P1 assigns attribute P1.attr1 to any principal that has attribute P2.link_attr asserts has attr2 in that principal's name space. For example if P3 has the P2.link_attr attribute and P3 assigns P4 the P3.attr2 attribute, P1 has assigned it the P1.attr1 attribute. All principals with the P2.link_attr attribute have been granted authority to assign the P1.attr1 attribute by assigning their local attr2 attribute. "GENI.researcher <-- (NSF.funded).researcher" encodes the policy that GENI recognizes all researchers funded by NSF (and issued an NSF.funded credential) as GENI researchers.

Conjunctions of attributes may also be used

P3.attr3 <-- P2.attr2 and P1.attr1

Printicpal P3 assigns attribute P3.attr3 to any principal possessing both P2.attr2 and P1.attr1.

Three Level Names

The initial fedd three-level name system of authentication allowed testbeds to make access control decisions based on the user and project identifiers that a testbed asserted about a requesting user. The request was made on behalf of that user by fedd, with later requests made on behalf of the allocation created above. The fedd representing a testbed was identified by its fedid, which anchored the attributes, assserted as a triple.

The acces control database section gives examples of how to express and configure access control based on these options. Three relevant examples are:

(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, <any>) -> (TIED, duser, <same>)
(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, <any>, faber) -> (TIED, faber, <same>)
(fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, Deter, faber) -> (TIEDadmin, faber, <same>)

An access controller on an emulab based testbed that was configured with those lines would grant any user that testbed fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea (let's call it deterlab.net) asserted was in the Deter project access to the local testbed and map it to the local TIED project with the duser (ignore the second username for now). If that same testbed asserted that the requesting username was faber in any project the local testbed would allow access and map that user into the local TIED project with username faber. If the testbed asserted that the requesting project was Deter and the requesting username was faber, access would be permitted and the user mapped to the local TIEDadmin project with local username faber. The most specific match wins and others are not allowed access.

On the experiment controller side, lines like the following configure assignment of attributes to users:

fedid:1234567890abcdef1234567890abcdef12345678 -> faber
fedid:fedcba0987654321fedcba0987654321fedcba09 -> (Deter, faber)

These lines map the first user (with the ascending fedid) to the faber username and the second (with the descending one) to both the faber username and the Deter project. This file controls which attributes are certified by an experiment controller.

If the experiment controller with fedid ce90957dd5b7d20f9c3890c4599313b7f1cf31ea is configured as above, when it contacts a testbed access controller configured as above on behalf of the ascending fedid, that user would be mapped to project TIED, user faber. Similarly, the descending one is mapped to project TIEDadmin, user faber.

Three Level Names in ABAC

In order to assign local privleges to a user under ABAC, the local access controller binds ABAC attributes to local resource controls and uses ABAC to prove that a principal requesting resources has those attributes. For example, an access controller of an Emulab-based testbeds would assign ABAC attributes to project/user pairs and prove that requesting experiments had those attributes. The assignment of attributes by the experiment conroller (or another testbed) would be controlled by that testbed, but the reasoning about those attributes is controlled by the local access controller.

A simple way to encode these permissions is to map each local project, user tuple into an ABAC attribute. For example, the local TIED, faber pair could be encoded as the ABAC principal fedid ce90957dd5b7d20f9c3890c4599313b7f1cf31ea:TIED_faber. Because it is easier to think of setting up separate rules for usernames and projects, that attribute (denoting the pair) would probably be derived from a rule of the form:

fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.TIED_faber <-- fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea:TIED and fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.faber

Now consider the derivation of a project attribute for a local testbed with fedid:1111111111111111111111111111111111111111. The rules above (that pretain to projects) become the following ABAC rules:

fedid:1111111111111111111111111111111111111111:TIED <--- (fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.DETER).actfor
fedid:1111111111111111111111111111111111111111:TIED <--- (fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.faber).actfor
fedid:1111111111111111111111111111111111111111:TIEDadmin <--- (fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.DETER).actfor and (fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.faber).actfor 

As we mention above, requests for resources are made by an experiment principal. If that experiment principal has been delegated the actfor attribute by a prinicpal in the DETER project from the testbed with fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea, it may be given access to the TIED group locally. Similarly a user who both had the faber (username) and DETER (project) attributes from that testbed can be given access to the TIEDadmin group locally. (The username and projectname semantics are by convention. If the namespaces collide, or if this is unclear, conventions can be made to make those semantics explicit.)

On the testbed that is granting the credentials - the one with fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea in this case - usernames and projects are assigned as ABAC credentials. Using the same ascending and descending fedids as above, the ABAC looks like:

fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.faber <-- fedid:1234567890abcdef1234567890abcdef12345678
fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.DETER <-- fedid:fedcba0987654321fedcba0987654321fedcba09
fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.faber <-- fedid:fedcba0987654321fedcba0987654321fedcba09

ABAC credentials must also be issued to allow the user to create an experiment with the experiment controller:

fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.create <-- fedid:1234567890abcdef1234567890abcdef12345678
fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.create <-- fedid:fedcba0987654321fedcba0987654321fedcba09

Now to create a resource and allocate resources to it, an experimenter (fedid:fedcba0987654321fedcba0987654321fedcba09) contacts the experiment controller (fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea) and is allowed to create an experiment because the experimenter has the fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea.create credential. The experiment controller replies with the fedid of the new experiment (e.g. fedid:eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee). The experimenter now delegates their attributes to the experiment bi issuing the following credential:

fedid:fedcba0987654321fedcba0987654321fedcba09.actfor <-- fedid:eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

Now the experimenter requests resources from the experiment contoller (including the new credential in the request), who acts as the experiment principal and makes the resource request from the testbed access controller (potentially including the credentials). The access controller is able to prove that this experiment has the fedid:1111111111111111111111111111111111111111:TIEDadmin_faber attribute and can use the project/username pair TIEDadmin, faber.

That proof looks like this (in the notation introduced in our ​earlier description of the model, with Home substituted for the home testbed principal, local for the access controller's principal, User as the experimenter's principal and experiment as the experiments's, rather than the fedids):

All the credentials above the red line (and therefore the rules for mapping attributes into local control) are controlled by the testbed granting resources. All those below are controlled by the home testbed or the experimenter.

ABAC grants some freedom in where credentials are stored, but for the three-level naming system, passing all credentials with each request is simple and effective.

Note that although the example assumes that the experiment controller is co-located and administered by the home testbed, there is no requirement to do so. For example, the experiment controller could run on a particular experimenter's desktop. The experimenter can still provide the credentials from the home testbed meaning that the same decisions will be made, but the administration of the experiments is no longer bound to the testbed issuing those credentials.

Central GENI Authority

An alternative authorization system would be to have a central GENI authority either directly authorize users, or to allow principals that GENI authorizes to do so. For scalability, we assume that a GENI authority (principal) will certify other principals to assign attributes to its users that will be understood by all participating GENI resource providers. For this example, we'll assume that GENI hands certifies institutions at one of three levels (Gold, Silver, Bronze) and that individual providers map those classes into their local access control policies as they see fit.

On the local testbed/GENI side, this situation parallels the ​capture the flag example we have already worked out. GENI grants institutions either the GENI.gold, GENI.silver or GENI.bronze attribute and local testbeds hand out credentials indicating who their users are.