| 7 | | This is the most complex of the accessdbs. Its purpose is to configure how an access control component maps a [FeddAbout#GlobalIdentifiers:Three-levelNames three level name] to a local testbed user and project, as well as the rights the project must possess (the node types it can access). It also includes information about which kinds of nodes are restricted and allows a testbed owner to supply additional attributes used in accessing the testbed. |
| | 7 | == AccessDBs == |
| | 8 | |
| | 9 | The primary role of the various `fedd` accessDBs is to assign attributes to the [FeddAbout#GlobalIdentifiers:Fedids fedid]s or [FeddAbout#GlobalIdentifiers:Three-levelNames three-level name]s that a requester may assert. Those attributes control the access to services. A requester with the proper attribute may access the service, one without is denied. The access component and experiment control component accessDBs assign the attributes necessary for their services implicitly in conjunction with specifying mapping information inherent to the function. The other components' accessDBs are simple attribute assignments. |
| | 10 | |
| | 11 | === Global AccessDB === |
| | 12 | |
| | 13 | The global accessDB is the simplest format of the DBs and does the simple funtion of mapping [FeddAbout#GlobalIdentifiers:Fedids fedid] to attributes. The format is a single line per fedid listing the fedid and a comma separated list of attributes. |
| | 14 | |
| | 15 | {{{ |
| | 16 | fedid:xxx attr[,attr] |
| | 17 | }}} |
| | 18 | |
| | 19 | Lines are additive, so: |
| | 20 | |
| | 21 | {{{ |
| | 22 | fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea split,allocate |
| | 23 | }}} |
| | 24 | |
| | 25 | and |
| | 26 | |
| | 27 | {{{ |
| | 28 | fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea allocate |
| | 29 | fedid:ce90957dd5b7d20f9c3890c4599313b7f1cf31ea split |
| | 30 | }}} |
| | 31 | |
| | 32 | are equivalent. |
| | 33 | |
| | 34 | Relevant attributes include: |
| | 35 | |
| | 36 | '''access''':: |
| | 37 | The right to access resources on this testbed. Without an mapping to local resources in the access component's accessDB, this attribute is useless. It is specified implicitly by inclusion in that DB. |
| | 38 | '''allocate''':: |
| | 39 | The right to allocate local resources through the internal remote interface. A `fedd` running on boss to allocate resources based on the decisions of a `fedd` running on users would grant the users `fedd` this attribute. |
| | 40 | '''create''':: |
| | 41 | The right to create an experiment on this `fedd`. Assigning this without an entry in the experiment control component's accessDB is not useful. Having the right without specifying a mapping to three-level name fill cause the creation to fail. |
| | 42 | '''split''':: |
| | 43 | The right to run the experiment splitter program on this `fedd`. Because the service at !http://users.isi.deterlab.net:23235 is open to anyone, this attribute is rarely allocated. |
| | 44 | |
| | 45 | The accessDB options in the [splitter] and [allocate] sections of the configuration file allow the databases containing the '''allocate''' and '''split''' attributes to be specified in separate DBs. When the DB is specified in the [allocate] section, only the '''allocate''' attribute is recognized, and similarly with the [splitter] section. When specified in [globals] any attribute is respected. |
| | 46 | |
| | 47 | The utility program [FeddCommands fedid.py] is useful in creating global accessDBs. |
| | 48 | |
| | 49 | === Access Component AccessDB === |
| | 50 | |
| | 51 | This is the most complex of the accessDBs. Its purpose is to configure how an access control component maps a [FeddAbout#GlobalIdentifiers:Three-levelNames three level name] to a local testbed user and project, as well as the rights the project must possess (the node types it can access). It also includes information about which kinds of nodes are restricted and allows a testbed owner to supply additional attributes used in accessing the testbed. |
| | 145 | |
| | 146 | === Experiment Control Component AccessDB === |
| | 147 | |
| | 148 | Like the access component accessDB, the experiment control component accessDB performs double duty - it both determines what [FeddAbout#GlobalIentifiers:fedids fedids] can be used to create experiments, and it determines what [FeddAbout:GlobalIdentifiers:Three-levelNames three-level name]s a `fedd` will assert on behalf of that user when acquiring access to other testbeds. |
| | 149 | |
| | 150 | Lines in the accessDB have the following format: |
| | 151 | |
| | 152 | {{{ |
| | 153 | fedid:xxx -> user |
| | 154 | fedid:xxx -> (project, user) |
| | 155 | }}} |
| | 156 | |
| | 157 | The top line says that the given fedid should be mapped to (`this_testbed`, , `user`), and the second line says that the given fedid should be mapped to (`this_testbed`, `project`, `user`), where `this_testbed` is the fedid of this `fedd`. |
| | 158 | |
| | 159 | If the same fedid appears on more than one line, any of the three-level name may be used on behalf of that requester. Currently `fedd` tries them all in an arbitrary order until one is granted access at each testbed. During an embedding a requester may be granted access to different testbeds under different three-level names. |
| | 160 | |
| | 161 | Any fedid not appearing in this databses is denied access to the experiment control facility; that is, a fedid in this DB is granted the '''create''' attribute. When an experiment is created, access to it is controlled independently of this database, so a fedid in this database does not automatically possess the right to terminate or interrogate an experiment they did not create. These rights are controlled by non-string attributes that are not specified in the databases. |
| | 162 | |
| | 163 | To simplify creating this database, the fedd package supplies a utility script, [FeddCommands exp_access_db.py]. |
| | 164 | |
| | 165 | == Experiment Name Mapping DB == |
| | 166 | |
