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. Slice manager add or configure slice resources from components/aggregates under direction of the researcher. (slice manager checks researcher authorization for operation, components check experiment authorization to resources).