Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Clearinghousedesc


ProtoGeni ClearingHouse

ProtoGeni ClearingHouse


We currently have a simple clearinghouse running at Utah. This clearinghouse is/will be shared by all members of our federation. The clearinghouse is the central location for looking up information about component mangers, users, slices, etc., and plays a central role in trust formation and the dissemination of certificate revocation lists.


The ProtoGENI clearinghouse has two roles:

  • To help resource providers (component managers) and resource users (researchers) to find each other through registries (see API documentation below)
  • To establish trust within a federation by acting as a central point of trust, through which all members of the federation exchange root certificates and certificate revocation lists.

This role is illustrated in the following figure:



In general, the certificates that researchers use to authenticate themselves to the ProtoGeni servers come from their "home" testbeds. A user of any of the federated testbeds may request a certificate from their local Emulab installation. Thus, user management (creating user accounts, etc.) is handled by the Emulab software at each federate. See the document describing the trust model for more information, but in brief, all entities wishing to access an XML-RPC server must have an x509 key pair, where the private part of the key is used to initiate the SSL session and the public part is their Geni Identifier (GID).

Note that in rest of this document, when I say a credential is signed by a GID (certificate), I of course mean the private key for that certificate.

In the case of the clearinghouse though, mere users do not generally talk to the clearinghouse. Rather, known Slice Authorities and Component Managers are the only ones that can register and delete entries, as well as resolve records. Authorities can get a credential to access the clearinghouse in one of two ways;

  • Request a credential via XML-RPC (see below). The credential is signed using the clearinghouse's GID (certificate).
  • Generate a self-signed credential. In this case, the authority uses its own certificate (GID) to sign the credential. This is the same certificate that the authority then uses to establish the SSL connection. The credential is accepted because the signature is valid, and because clearinghouse has that GID in its database.

Operational Notes

The Geni architecture specifies the tasks that the clearinghouse should perform. The ProtoGeni clearinghouse does not attempt to implement all of those functions. Operationally, the Utah clearinghouse does a limited set of tasks:

  • Allows registration, deletion, and resolution of various principle objects. Currently limited to slices, users, slice authorities, component managers, and components.
  • Provides a list of all known component managers. The information returned includes the URL a client can contact to get a list of currently available resources.
  • Exports a centralized "emergency shutdown" facility that can be used to terminate a misbehaving slice.
  • Assists in the registration of new federates as they come on-line.
  • Collects and distributes Certificate Revocation Lists from all of the federates. These CRL's are generated periodically by the federates so that others in the federation can be made aware of users that have been terminated or who have had to generate a new certificate (GID).

Other items of note:

  • Only one instance of the clearinghouse is in operation. While the architecture eventually calls for multiple clearinghouses, there is no support in the current code for federating multiple clearinghouses together.
  • Everything is stored in a mysql database.
  • The location (URL) of the clearinghouse is hardwired, in the sense that the initialization script that federates run, downloads the GID (certificate) of the clearinghouse from Utah. Inside that certificate is a URL (in the Subject Alternative Name of the certificate).
  • Most operations are restricted to known Authorities (SA,CM); mere users cannot access the clearinghouse, except where noted below.

The current implementation of the clearinghouse is highly dependent on the Emulab source code. A number of Emulab libraries and support systems are used by the clearinghouse, but in general it is not really necessary to have an actual Emulab testbed running in order to run an instance of the clearinghouse. A future project is to provide an installation target for the Emulab code that would install the bare minimum needed to run a clearinghouse.

API Documentation

The clearinghouse is accessed through XML-RPC over SSL. Clients supply a client certificate as part of SSL connection establishment. This certificate must be signed by an authority known to the clearinghouse (these authorities correspond to the federates). The clearinghouse's URL is:

Each modification of our prototype API is labeled with a revision number. Descriptions for the following revisions are available:

Future Work

The Clearinghouse is somewhat simple at this point, mostly because the size of the federation is small, as are its needs. Items that need to be addressed are:

  • There is no web interface to see what is in the Clearinghouse. Admin people must use mysql commands to look at the tables.
  • There is no up to date view of slices that are instantiated (slivers).
  • No global view of what resources are currently available.
  • No expiration of registry entries and no renew.