The DETER Federation Architecture (DFA)

This is a basic overview of the DETER federation system. More details on this implementation and configuration are in later documents. You can also read these academic papers that capture the evolution of the design to this point.

DFA is a system that allows a researcher to construct experiments that span testbeds by dynamically acquiring resources from other testbeds and configuring them into a single experiment. As closely as possible that experiment will mimic a single DETER/Emulab experiment.

Though the experiment appears to be a cohesive whole, the testbeds that loan the resources retain control of those resources. Because testbeds retain this control, each testbed may issue credential necessary for manipulating the federated resources. For example, a testbed that has loaned nodes to an experiment may require the experimenter to present a credential issued by that testbed (e.g., an SSH key or SSL certificate) to reboot those nodes. The system acquires those credentials on behalf of experimenters and distributes them on behalf of testbeds.

Testbed administrators may use the system to establish regular policies between testbeds to share resources across many users of a testbed. Similarly, a single user with accounts on multiple testbeds can use the same interfaces to coordinate experiments that share his testbed resource, assuming sharing those resources does not violate the policy of any of the constituent testbeds.

Fedd: The DETER Federation Daemon

Fedd is the daemon process responsible for:

• Creating and terminating federated experiments
• Requesting access to remote resources on an experimenter's behalf
• Granting access to local resources based on the testbed's policy

Generally fedd is configured by the testbed's administration to allow controlled sharing of the resources, though the same software and interfaces can be used by single users to coordinate federated resources.

Creating a federated experiment consists of breaking an annotated experiment into sub-experiments, gaining access to testbeds that can host those experiments, and coordinating the creation and connection of those sub-experiments. Fedd insulates the user from the various complexities of creating sub-experiments and dealing with cleanup and partial failures. Once an experiment is created, fedd returns credentials necessary to administer the experiment.

On termination, fedd cleans up the various sub-experiments and deallocates any dynamic resources or credentials.

Access Control

This section describes the basic model of access control that fedd implements. We start by explaining how users are represented between fedds and then describe the process of acquiring and releasing access to a testbed's resources.

This section documents the current access control system of fedd. It is undergoing development.

Global Identifiers: Fedids

In order to avoid collisions between local user names the DFA defines a global set of names called DETER federation IDs, or more concisely fedids. A fedid has two properties:

• An entity claiming to be named by a fedid can prove it interactively
• Two entities referring to the same fedid can be sure that they are referring to the same entity

An example implementation of a fedid is an RSA public key. An entity claiming to be identified by a given public key can prove it by responding correctly to a challenge encrypted by that key. For a large enough key size, collisions are rare enough that the second property holds probabilistically.

We adopt public keys as the basis for DFA fedids, but rather than tie ourselves to one public key format, we use subject key identifiers as derived using method (1) in RFC3280. That is, we use the 160 bit SHA-1 hash of the public key. While this allows a slightly higher chance of collisions than using the key itself, the advantage of a single representation in databases and configuration files outweighs the increase in risk for this application.

Global Identifiers: Three-level Names

In Emulab, projects are created by users within projects and those attributes determine what resources can be accessed. We generalized this idea into a testbed, project, user triple that is used for access control decisions. A requester identified as ("DETER", "proj1", "faber") is a user from the DETER testbed, proj1 project, user faber. Testbeds contain projects and users, projects contain users, and users do not contain anything.

Parts of the triple can be left blank: ( , ,"faber") is a user named faber without a testbed or project affiliation.

Though the examples used above are simple strings, the outermost non-blank field of a name must be a fedid to be valid, and are treated as the entity asserting the name. Contained fields can either be fedids or local names. This allows a testbed to continue to manage its namespace locally.

If DETER has fedid:1234 then the name (fedid:1234, "proj1", "faber") refers to the DETER user faber in proj1, if and only if the requester can prove they are identified by fedid:1234. Note that by making decisions on the local names a testbed receiving a request is trusting the requesting testbed about the membership of those projects and names of users.

Testbeds make decisions about access based on these three level names. For example, any user in the "emulab-ops" project of a trusted testbed may be granted access to federated resources. It may also be the case that any user from a trusted testbed is granted some access, but that users from the emulab-ops project of that testbed are granted access to more kinds of resources.

These three level names are used only for testbed access control. All other entities in the system are identified by a single fedid.

Granting Access: Emulab Projects

Once a fedd has decided to grant a researcher access to resources, it implements that decision by granting the researcher access to an Emulab project with relevant permissions on the local testbed. The terminology is somewhat unfortunate in that the fedd is configured to grant access based on the global three-level name that includes project and user components and implements that decision by granting access to a local Emulab project and Emulab user.

The Emulab project to which the fedd grants access may exist and contain static users and resource rights, may exist but be dynamically configured by fedd with additional resource rights and access keys, or may be created completely by fedd. Completely static projects are primarily used when a user wants to tie together his or her accounts on multiple testbeds that do not bar that behavior, but do not run fedd.

Whether to dynamically modify or dynamically create files depends significantly on testbed administration policy and how widespread and often federation is conducted. In Emulabs projects are intended as long-term entities, and creating and destroying them on a per-experiment basis may not appeal to some users. However, static projects require some administrator investment per-project.

Experiments

A federated experiment exports a master testbed's runtime environment into the other testbeds. The resulting experiment exports the shared file space of the home testbed, though a different filesystem, SMB, is used to export it. Emulab events can be sent to nodes throughout the federated experiment, though some naming slight-of-hand may be required. Users who want to reboot nodes or links in federated testbeds will need to access those testbeds directly using the credentials provided by fedd.

Currently experiments are described in the same ns2 syntax that DETER and Emulab use, except that additional annotations for the testbed on which to place each node have been ad dded. (The extension is set-node-testbed, and described elsewhere.) The testbed name here is a local string meaningful to the experimenter. Each fedd knows some set of such strings, and experimenters can also inform fedd of the appropriate mapping between local testbed name and fedd address to contact.

An experimenter creates an experiment by presenting it to a fedd that knows him or her - usually the fedd on their local testbed - along with the master testbed name, local Emulab project to export and local mappings. That fedd will map the local user into the global (testbed, project, user) namespace and acquire and configure resources to create the experiment. A fedd may try different mappings of the experimenter into the global namespace in order to acquire all the resources. For example a local experimenter may be a member of several local Emulab projects that map into different global testbed-scoped projects.

Once created the user receives the various keys under which he or she can access the sub-experiment services and a local and global name by which the experiment can be referenced. (Experiments are identified by fedids). The local name is mnemonic and can be used locally to access information about the experiment and to terminate it. The experimenter can suggest a name when requesting experiment creation.

In order to create a fedid, a key pair is created. The public and private keys for the fedid representing the experiment are returned in an encrypted channel from fedd to the requesting experimenter. The experimenter can use this key pair as a capability to grant access to the experiment to other users.

While an experiment exists, experimenters can access the nodes directly using the credentials passed back and can acquire information about the experiment's topology from fedd. Only the experimenter who created it or one given the capability to manipulate it can get this information.

Finally, fedd will terminate an experiment on behalf of the experimenter who created it, or one who has been granted control of it. Fedd is responsible for deallocating the running experiments and telling the testbeds that this experimenter is done with their access.

Interfaces to fedd

The fedd interfaces are completely specified in WDSL and SOAP bindings. For simplicity and backward compatibility, fedd can export the same interfaces over XMLRPC, where the message formats are trivial translations.

All fedd accesses are through HTTP over SSL. Fedd can support traditional SSL CA chaining for access control, but the intention is to use self-signed certificates representing fedids. The fedid semantics are always enforced.

There are also several internal interfaces also specified in WSDL/SOAP and accessible through XMLRPC used to simplify the distributed implementation of fedd. You can read about those in the development section.