| | 57 | |
| | 58 | A user identifies themselves to the testbed API by proving that they hold a specific public/private keypair. An initial such keypair is issued when the user is created, and a user can acquire another valid pair at any time by proving they know their password. Generally those pairs are short-lived to guard against loss or theft, but the password is administered using local testbed policies. |
| | 59 | |
| | 60 | ==== Projects ==== |
| | 61 | |
| | 62 | Projects are groups of users. They are used to confer rights to groups of users, identify groups of users, and control how resources are configured when experiments are realized on the testbed. This is a more general use of projects than an Emulab testbed. |
| | 63 | |
| | 64 | A project always has an owner, the user responsible for its creation. Ownership can be changed, but only by the owner. |
| | 65 | |
| | 66 | When a user is added to a project, their rights are also defined within that project. The rights are: |
| | 67 | |
| | 68 | * Can add other users or projects to the project |
| | 69 | * Can remove users or projects from the project |
| | 70 | * Can realize experiments under this project (granting members of the project access to the resources in use) |
| | 71 | |
| | 72 | When a project is added to another project, the rights of the project are given to each member of the group. |
| | 73 | |
| | 74 | Projects can also have attributes attached to them. The most important of these is the '''vetting''' attribute. A vetting project (one with the vetting attirbute) can allow users to have access to testbed resources. Until a user is a member of a vetting project, minimal testbed resources are allocated to them and they cannot perform any useful actions, except attempting to create one vetting project. DETER testbeds can be configured to alert staff when a vetting project is requested and require authorization from an administrator. |
| | 75 | |
| | 76 | Vetting projects solve the problem of distributed user management on a large testbed. DETERlab has thousands of users and a small staff. The staff needs to make sure that users meet certain criteria. Having the staff review each user application is unreasonable, reviewing the creation of a comparatively smaller set of vetting projects is not. |
| | 77 | |
| | 78 | When a researcher wants to start a project on DETERlab, the researcher creates a user and requests a vetting project. The vetting project is reviewed, and if valid created with the user as owner. The user is then added to the vetting project with the right to add others. Now that user is responsible for managing new people in their project. A new person creates a user that has no power until a researcher with a vetting account adds them to that project. |
| | 79 | |
| | 80 | Though the testbed API sees this as two steps, the user interface presented by a web page would roll these two steps together. A user sees it as a single application page. |
| | 81 | |
| | 82 | A testbed with looser constraints on the vetting process can skip or remove the review process. |
| | 83 | |
| | 84 | If a user is removed from all vetting projects, they return to a powerless state. |
