Changes between Version 11 and Version 12 of NewAPI


Ignore:
Timestamp:
Aug 12, 2013 10:30:18 AM (7 years ago)
Author:
faber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NewAPI

    v11 v12  
    1010  researchers
    1111 Projects::
    12   groups of related users, used to manage what users can see and do to other testbed resources
     12  groups of related users used to control what users have access to the testbed as a whole and to provide real-world accountability in the case of misbehavior.
     13 Circles::
     14   groups of related users used to manage what users can see and do to other testbed resources
    1315 Resources::
    1416  building blocks for realizing experiments: computers, disk images, external access
     
    5658A 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.
    5759
    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
     62DETER 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
     66Projects 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
     69A project always has an owner, the user vetted by DETER staff.  Ownership can be changed, but only by the owner.
    6370
    6471When a user is added to a project, their rights are also defined within that project.  The rights are:
    6572
    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
     77Each project has a profile attached to it, as a user does, and that profile can be expanded to include other attributes.
     78
     79When 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
     81The 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
     83When 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
     85If a user is removed from all projects, they return to a powerless state.
     86
     87==== Circles ====
     88
     89Circles 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
     91A circle always has an owner, the user responsible for its creation.  Ownership can be changed, but only by the owner.
     92
     93Circle 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
     95When 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
     101Each circle has a profile attached to it, as a user does, and that circle can be expanded to include other attributes.
     102
     103Each 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
     105Bob 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
     107Circles 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
     109A 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
     111The 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.
    83112
    84113=== Resources ===