The GENI Clearinghouse is the name we give to a collection of related services supporting federation among experimenters, aggregates and the GMOC.

Federation Services. The Clearinghouse represents a trust anchor for all software entities (tools, aggregates, services) in the GENI Federation. Anything trusted by the GENI Federation is trusted by any member of the GENI federation. Being trusted by the GENI Federation means having credentials signed by GENI’s PKI private keys testifying to particular attributes for that entity. The installation of the GENI certificate as a trust root at any GENI service allows for federated trust across all users, aggregates and services. In this way, we do not need each entity to explicitly trust each other entity to allow for federation-wide trust: we only need each entity to trust GENI. Thus, we reduce the number of trust relationships from O(N2) to O(N).

The Clearinghouse provides a series of services for managing and asserting the credentials of entities trusted by GENI.

  • An Identity Provider (IdP) provides certificates and PKI key materials to human users, registering them with the GENI federation as GENI users.
  • A Project Authority asserts the existence of projects and the roles of members (e.g. PI, Experimenter).
  • A Slice Authority provides experimenters with slice credentials by which to invoke AM (Aggregate Manger) API calls on federation aggregates.
  • A Service Registry provides experimenters with a ‘yellow pages’ of URL’s of all trusted services of different kinds. In particular, the list of all available aggregate managers trusted by GENI (possibly satisfying particular criteria) are provided.
  • A Single-Sign-on Portal, which provides web-based authentication and access to the authorized Clearinghouse services and other GENI user tools.

Authorization Services. The Clearinghouse provides services to determine whether particular actions (within the Clearinghouse or with respect to a particular Aggregate) are permitted by federation policy.

There are two essential types of authorization policy we consider: Trust Policy and Resource Allocation Policy.

Trust Policy is a statement or sequence of statements from which allowable actions may be inferred from the attributes of a principal. The GENI software architecture recognizes two types of credentials:

  • ABAC (Attribute-based Access Control) provides a representation for trust delegation statements and a reasoning engine that proves that a given entity is trusted to take a particular action based on the set of ABAC statements provided.
  • SFA (Slice Federation Architecture) credentials use a table-driven mechanism to map attributes into allowable actions.

Resource Allocation Policy is a statement limiting the resource allocations or allocation behaviors associated with a given project, slice or experimenter. For example, we may wish to limit the number of compute nodes (computers or VM’s) allocated to a given project at any given time.

The Clearinghouse Authorization Service determines whether a given action is permitted by policy. It contains a series of guards, each of which may veto a given action (i.e. an act is authorized if and only if it is not prohibited by any guard). Version 1 of the GENI Federation Clearinghouse will include a trust guard and a resource allocation guard. Other instances of the GENI software architecture may have a different set of guards.

The Clearinghouse provides a Credential Store that provides authorized read/write access to all credentials for all GENI-trusted entities. This store allows for federation or local authorization services or other policy decision or enforcement points to have access to the appropriate credentials without needing to carry or compute these at the time of each customer request. The Credential Store allows for mapping a known user certificate or other unique identifier to a list of signed credentials associated with that individual. By keeping authorization credentials separate from authentication certificates and by imposing short time outs on credentials, it is possible to modify credentials and have the effects of these modifications take effect in a reliable and timely manner throughout the federation.

Accountability Services. The Clearinghouse provides services that log transactions (successful or failed) between user tools and aggregates to support real-time and post-facto forensics analytics. By maintaining logs and databases of transaction callers and arguments, of projects and their slices and slivers, the GMOC can have critical timely trace back to find the identities of possibly misbehaving users or responsible project leads. They can then, depending on the situation, contact the project lead, shut down all or some slivers associated with a misbehaving aggregate or user or some combination thereof.

The Logging Service provided by the Clearinghouse fronts a store for writing and querying data associated with transactions, allowing for determining what entity made what requests and got what results.

The Logging Service provides the traceability between slivers and slices. The Slice Authority provides the link of slices to projects, while the Project Authority provides the link of projects to investigators. Together, these provide the ability to find the responsible party to contact in case of problematic behavior on the part of an experimenter.

APIs The Clearinghouse follows a set of common APIs.

Implementation An implementation of these apis and services has been developed, with code and bug tracking here.

Last modified 7 years ago Last modified on 06/22/15 15:09:56