| 58 | | === Projects === |
| 59 | | |
| 60 | | 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. |
| 61 | | |
| 62 | | A project always has an owner, the user responsible for its creation. Ownership can be changed, but only by the owner. |
| | 60 | === Grouping Users: Projects and Circles === |
| | 61 | |
| | 62 | DETER groups users for two main reasons: to distribute the time costs of administration and to facilitate collaborative use of DETER's resources. The first is accomplished through the Project abstraction and the second through the Circle abstraction. |
| | 63 | |
| | 64 | ==== Projects ==== |
| | 65 | |
| | 66 | Projects are groups of users who can access testbed resources. They correspond to such real-world groups as classes or research projects. Each project has an owner, vetted by DETER staff, who can then add users to the project at their discretion. Such users have access to the DETER testbed. This is close in spirit to an Emulab project, but shorn of its access control implications. |
| | 67 | |
| | 68 | |
| | 69 | A project always has an owner, the user vetted by DETER staff. Ownership can be changed, but only by the owner. |
| 66 | | * Can add other users or projects to the project |
| 67 | | * Can remove users or projects from the project |
| 68 | | * Can realize experiments under this project (granting members of the project access to the resources in use) |
| 69 | | |
| 70 | | When a project is added to another project, the rights of the project are given to each member of the group. |
| 71 | | |
| 72 | | 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. |
| 73 | | |
| 74 | | 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. |
| 75 | | |
| 76 | | 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. |
| 77 | | |
| 78 | | 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. |
| 79 | | |
| 80 | | A testbed with looser constraints on the vetting process can skip or remove the review process. |
| 81 | | |
| 82 | | If a user is removed from all vetting projects, they return to a powerless state. |
| | 73 | * Can add other users to the project |
| | 74 | * Can remove users from the project |
| | 75 | * Can realize create circles in the project's name space (see below) |
| | 76 | |
| | 77 | Each project has a profile attached to it, as a user does, and that profile can be expanded to include other attributes. |
| | 78 | |
| | 79 | When a researcher wants to start a project on DETERlab, the researcher creates a user and requests a project. 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. |
| | 80 | |
| | 81 | The project is created but unapproved and cannot do anything. When the group responsible for vetting projects approves the project, its state is changed (to approved) and the owner can now add other users and use testbed resources. (Each project has a circle linked to it that controls project members access to testbed resources.) |
| | 82 | |
| | 83 | When a new user applies to join the testbed, a user is created that can only set its password or apply to create or join a project. When a user applies to join a project, all project members who can add that user are notified. Any one of them can accept the user and set their permissions. By accepting that user the project takes some responsibility for them. If that user misbehaves, the project owner will be contacted as well as the user. |
| | 84 | |
| | 85 | If a user is removed from all projects, they return to a powerless state. |
| | 86 | |
| | 87 | ==== Circles ==== |
| | 88 | |
| | 89 | Circles 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. Circles are intended to be lightweight and encourage collaboration inside a project or across projects. This is a more general use of grouping than an Emulab testbed. |
| | 90 | |
| | 91 | A circle always has an owner, the user responsible for its creation. Ownership can be changed, but only by the owner. |
| | 92 | |
| | 93 | Circle names are scoped one of two ways, by prefixing them with either the uid of the user that created it, or a project that the creating user is a member of. The right to create circles with the project's prefix is controlled by a user's permissions in the project. Because uids and project names are unique across the testbed, circle names are unique when prefixed. The names written as prefix:circle. |
| | 94 | |
| | 95 | When a user is added to a circle, their rights are also defined within that circle. The rights are: |
| | 96 | |
| | 97 | * Can add other users to the circle |
| | 98 | * Can remove users from the circle |
| | 99 | * Can realize experiments under this circle (granting members of the circle access to the resources in use) |
| | 100 | |
| | 101 | Each circle has a profile attached to it, as a user does, and that circle can be expanded to include other attributes. |
| | 102 | |
| | 103 | Each user in an approved project is a member of at least two circles: a circle attached to the project (created and owned by the owner of the project in the project's name space) and a single-user circle owned (and created by) the uid. A user bob in project newclass will be a member of the circle bob:bob and newclass:newclass. |
| | 104 | |
| | 105 | Bob will have the right to realize experiments in the bob:bob circle - that is bob cab create experiments that only bob can access. Bob will also have whatever rights the owner of the newclass project gave bob when he joined. If bob created the newstuff project, bob will have all rights in the newstuff:newstuff project. No user has the right to add or remove users from their single-user circle. |
| | 106 | |
| | 107 | Circles are used to control sharing as well. If bob and alice are made a team in newclass, the owner of that project, e.g., their instructor or teaching assistant, can make them a circle under the project's namespace. bob and alice may be made members of newclass:team1. Now experiments realized in that circle will be accessible to bob and alice. |
| | 108 | |
| | 109 | A user can create circles at will, but can only add users to a circle with their consent. Because circles enable users to share resources (e.g., local files) the desire to share must be mutual. |
| | 110 | |
| | 111 | The circle linked to a project is manipulated through the project, not as a circle. Users added or removed to a project are added to or removed from its linked circle. Permissions are also manipulated through the project interface. A simple project may never need to create additional circles. |
