Changes between Version 11 and Version 12 of FeddAbout

Mar 19, 2014 11:30:19 AM (7 years ago)



  • FeddAbout

    v11 v12  
    133133[FeddAccessController Access Controllers] are more deeply documented.
    135 = Fedd: The DETER Federation Daemon =
    137 Fedd is the name for the codebase that supports both the access controller and experiment controller function.  Generally any instance of fedd will be acting as either an experiment controller or an access controller.  We continue to move toward reflecting the distinction in function in the codebase, but this is not complete.
    139 Generally fedd is configured by the testbed's administration to allow
    140 controlled sharing of the resources, though the same software and
    141 interfaces can be used by single users to coordinate federated
    142 resources.
    144 Creating a federated experiment consists of breaking an annotated
    145 experiment into sub-experiments, gaining access to testbeds that can
    146 host those experiments, and coordinating the creation and connection of
    147 those sub-experiments.  Fedd insulates the user from the various
    148 complexities of creating sub-experiments and dealing with cleanup and
    149 partial failures.  Once an experiment is created, fedd returns
    150 credentials necessary to administer the experiment.
    152 On termination, fedd cleans up the various sub-experiments and
    153 deallocates any dynamic resources or credentials.
    155 = Access Control =
    157 This section describes the basic model of access control that fedd
    158 implements.  We start by explaining how users are represented between
    159 fedds and then describe the process of acquiring and releasing access to
    160 a testbed's resources.
    162 This section documents the current access control system of fedd.  It is
    163 undergoing development.
    165 == Global Identifiers: Fedids ==
    167 In order to avoid collisions between local user names the DFA defines a
    168 global set of names called DETER federation IDs, or more concisely
    169 fedids.  A fedid has two properties:
    171  * An entity claiming to be named by a fedid can prove it interactively
    172  * Two entities referring to the same fedid can be sure that they are referring to the same entity
    174 An example implementation of a fedid is an RSA public key.  An entity
    175 claiming to be identified by a given public key can prove it by
    176 responding correctly to a challenge encrypted by that key.  For a large
    177 enough key size, collisions are rare enough that the second property
    178 holds probabilistically.
    180 We adopt public keys as the basis for DFA fedids, but rather than tie
    181 ourselves to one public key format, we use subject key identifiers as
    182 derived using method (1) in RFC3280.  That is, we use the 160 bit SHA-1
    183 hash of the public key.  While this allows a slightly higher chance of
    184 collisions than using the key itself, the advantage of a single
    185 representation in databases and configuration files outweighs the
    186 increase in risk for this application.
    188 == Global Identifiers: Three-level Names ==
    190 In Emulab, projects are created by users within projects and those
    191 attributes determine what resources can be accessed.  We generalized
    192 this idea into a testbed, project, user triple that is used for access
    193 control decisions.  A requester identified as ("DETER", "proj1",
    194 "faber") is a user from the DETER testbed, proj1 project, user faber.
    195 Testbeds contain projects and users, projects contain users, and users
    196 do not contain anything.
    198 Parts of the triple can be left blank: ( , ,"faber") is a user named faber
    199 without a testbed or project affiliation.
    201 Though the examples used above are simple strings, the outermost (i.e., leftmost) non-blank field
    202 of a name must be a fedid to be valid, and are treated as the entity
    203 asserting the name.  Contained fields can either be fedids or local
    204 names.  This allows a testbed to continue to manage its namespace
    205 locally.
    207 If DETER has fedid:1234 then the name (fedid:1234, "proj1", "faber")
    208 refers to the DETER user faber in proj1, if and only if the requester
    209 can prove they are identified by fedid:1234.  Note that by making
    210 decisions on the local names a testbed receiving a request is trusting
    211 the requesting testbed about the membership of those projects and names
    212 of users.
    214 Testbeds make decisions about access based on these three level names.
    215 For example, any user in the "emulab-ops" project of a trusted testbed may
    216 be granted access to federated resources.  It may also be the case that
    217 any user from a trusted testbed is granted some access, but that users
    218 from the emulab-ops project of that testbed are granted access to more
    219 kinds of resources.
    221 These three level names are used only for testbed access control.  All
    222 other entities in the system are identified by a single fedid.
    224 == Granting Access ==
    226 An access controller is responsible for mapping from the global identifier space into the local access control of the testbed
    227 This may mean mapping a request into a local Emulab project and user, a local DRAGON certificate, or a local [ ProtoGENI] certificate.  As other plugins are added other mappings will appear
    229 === Emulab Projects ===
    231 Once an access controller managing an Emulab has decided to grant a researcher access to resources, it
    232 implements that decision by granting the researcher access to an Emulab
    233 project with relevant permissions on the local testbed.  The terminology
    234 is somewhat unfortunate in that the access controller is configured to grant access
    235 based on the global three-level name that includes project and user
    236 components and implements that decision by granting access to a local
    237 Emulab project and Emulab user.
    239 The Emulab project to which the fedd grants access may exist and contain
    240 static users and resource rights, may exist but be dynamically
    241 configured by fedd with additional resource rights and access keys, or
    242 may be created completely by fedd.  Completely static projects are
    243 primarily used when a user wants to tie together his or her accounts on
    244 multiple testbeds that do not bar that behavior, but do not run fedd.
    246 Whether to dynamically modify or dynamically create files depends
    247 significantly on testbed administration policy and how widespread and
    248 often federation is conducted.  In Emulabs projects are intended as
    249 long-term entities, and creating and destroying them on a per-experiment
    250 basis may not appeal to some users.  However, static projects require
    251 some administrator investment per-project.
    253 === Certificate Systems: DRAGON and ProtoGENI ===
    255 Access controllers on these systems map the request into a flat space of X.509 certificates and keys that provide the identity for these identity based systems.  Unlike the self-signed certificates representing [FeddAbout#GlobalIdentifiers:Fedids fedids], these are full X.509 certificates used to establish a chain of trust.  Different global users are mapped into certificates and keyes that match the access level intended.
    257136= Experiments =