| | 141 | |
| | 142 | All the credentials above the red line (and therefore the rules for mapping attributes into local control) are controlled by the testbed granting resources. All those below are controlled by the home testbed or the experimenter. |
| | 143 | |
| | 144 | ABAC grants some freedom in where credentials are stored, but for the three-level naming system, passing all credentials with each request is simple and effective. |
| | 145 | |
| | 146 | Note that although the example assumes that the experiment controller is co-located and administered by the home testbed, there is no requirement to do so. For example, the experiment controller could run on a particular experimenter's desktop. The experimenter can still provide the credentials from the home testbed meaning that the same decisions will be made, but the administration of the experiments is no longer bound to the testbed issuing those credentials. |
| | 147 | |
| | 148 | === Central GENI Authority === |
| | 149 | |
| | 150 | An alternative authorization system would be to have a central GENI authority either directly authorize users, or to allow principals that GENI authorizes to do so. For scalability, we assume that a GENI authority (principal) will certify other principals to assign attributes to its users that will be understood by all participating GENI resource providers. For this example, we'll assume that GENI hands certifies institutions at one of three levels (Gold, Silver, Bronze) and that individual providers map those classes into their local access control policies as they see fit. |
| | 151 | |
| | 152 | On the local testbed/GENI side, this situation parallels the [http://groups.geni.net/geni/wiki/TIEDABACDemo capture the flag example] we have already worked out. GENI grants institutions either the GENI.gold, GENI.silver or GENI.bronze attribute and local testbeds hand out credentials indicating who their users are. |
