| 135 | | = Fedd: The DETER Federation Daemon = |
| 136 | | |
| 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. |
| 138 | | |
| 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. |
| 143 | | |
| 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. |
| 151 | | |
| 152 | | On termination, fedd cleans up the various sub-experiments and |
| 153 | | deallocates any dynamic resources or credentials. |
| 154 | | |
| 155 | | = Access Control = |
| 156 | | |
| 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. |
| 161 | | |
| 162 | | This section documents the current access control system of fedd. It is |
| 163 | | undergoing development. |
| 164 | | |
| 165 | | == Global Identifiers: Fedids == |
| 166 | | |
| 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: |
| 170 | | |
| 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 |
| 173 | | |
| 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. |
| 179 | | |
| 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. |
| 187 | | |
| 188 | | == Global Identifiers: Three-level Names == |
| 189 | | |
| 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. |
| 197 | | |
| 198 | | Parts of the triple can be left blank: ( , ,"faber") is a user named faber |
| 199 | | without a testbed or project affiliation. |
| 200 | | |
| 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. |
| 206 | | |
| 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. |
| 213 | | |
| 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. |
| 220 | | |
| 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. |
| 223 | | |
| 224 | | == Granting Access == |
| 225 | | |
| 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 [http://www.protogeni.net/trac/protogeni ProtoGENI] certificate. As other plugins are added other mappings will appear |
| 228 | | |
| 229 | | === Emulab Projects === |
| 230 | | |
| 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. |
| 238 | | |
| 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. |
| 245 | | |
| 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. |
| 252 | | |
| 253 | | === Certificate Systems: DRAGON and ProtoGENI === |
| 254 | | |
| 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. |
