= ABAC access control for Fedd =

The [http://www.isso.sparta.com/research_projects/security_infrastructure/abac_overview.html ABAC] access control system, developed at Stanford and realized by a group in Trusted Information Systems that later moved to SPARTA, is a formal, flexible, scalable access control system based on formal derivation of user attributes, attested by other trusted users.  We have been [http://groups.geni.net/geni/wiki/TIEDABACModel planning] to integrate it into fedd for some time.  We have recently implemented ABAC in a [http://abac.deterlab/net portable library] and this implementation has been integrated into fedd.  Under our associated TIED project, we have completed a similar [http://groups.geni.net/geni/attachment/wiki/TIED/ABAC_GENIAPIv1.2.pdf integration] with GENI's [http://trac.gpolab.bbn.com/gcf reference aggregate manager], part of their developing [http://groups.geni.net/geni/wiki/GeniApi GENI API].

This page describes the use of ABAC with fedd, concentrating on using the transition tools to create initial ABAC credential stores from which to run fedd.  In order to get the most from this page, you should be familiar with

 * [http://groups.geni.net/geni/wiki/TIEDABACModel The ABAC model] as it is used by DETER.
  * There is a [http://groups.geni.net/geni/wiki/TIEDABACDemo worked example] that can be helpful here
 * The existing [FeddDatabases fedd access databases]


== Storing Credentials ==

Users and servers (fedd instances) now both have credential stores to maintain.  When using ABAC credentials to enforce the same kinds of access control as [FeddAbout#GlobalIdentifiers:Three-levelNames three-names] neither users nor servers will see much change.  Credentials will be managed transparently.

By default a user will maintain a credential store in a directory named {{{.abac}}}. Any credentials in the users abac directory will be passed as parameters when requests are made to fedd.  The user can limit the credentials passed by specifying a directory with only a subset of the credentials.

Similarly, a running fedd instantiation will be configured to use a specific abac directory in which its credentials are kept.  As the instance learns more credentials they are aslo stored in this directory.

Unlike a user, the fedd directory contains metadata beyond the credential lists.  This directory is populated using the {{{access_to__abac.py}}} command for access controllers and the {{{fedd_to_abac.py}}} command for experiment controllers.

== Operation of Experiment Controller ==

The experiment controller can operate in two modes, as an experiment controller dedicated to use by a single user, or as a service on behalf of multiple users.  In the first case the controller acts as the same principal as the user commands.  Essentially the experiment controller is a command run by the single user.  In the second case a common piece of infrastructure acts as an experiment controller for many users.  Because this fedd acts as a distinct principal, some additional delegation is required to make the access control reasonable.

When the experiment controller is run as a service, it acts as a separate principal for the purposes of experiment creation, and the user and the controller negotiate what principal the controller will act as when making resource allocations from access controllers.  This allows a user to delegate a subset of attributes to the experiment principal and then allow the experiment controller to act as that principal.  (The experiment principal may have attributes delegated by multiple principals, if needed).  This extra principal is required to prevent the experiment controller from combining rights from multiple principals that did not intend it.