Changes between Initial Version and Version 1 of OldFeddAbout

Timestamp:

Dec 10, 2008 1:34:45 PM (16 years ago)

Author:

faber

Comment:

--

OldFeddAbout

@@ +1 @@
+= 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.
+
+== 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 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.