|A set of pre-defined roles can be assigned to users to give them particular privileges.|
In R2, the system will provide a set of built-in Roles and internal Policies to support them.
There are two ways in which a user can be granted a Role: they can request to be granted a Role (see how to gain roles & access), or the Facility Administrator can offer them a Role (see how to manage roles & access). In either case, one party initiates the request/offer, the other party is notified that the request/offer has been extended, and can then Accept or Decline. This is a familiar hand-shaking model used in Google Drive and many mailing list systems. The key is that anyone can make a request and no one can be forced into a role.
The grid below shows the allowable activities indicated by a check mark under the role.
Note that these Role definitions and their supporting Policies are common to all Facilities (RSN, CG, EA), and the permissions are granted to entire classes of resources across a Facility. In other words, if a user is granted the role of Facility Operator for RSN, they will have permission to request access to, and then operate, any Instrument or Platform in the RSN Facility. (If a user needs to operate equipment in two different Facilities, they would be granted the Facility Operator role in each.)
Note that while Facility Managers and Facility Administrators have the ability to command any instrument at any time without needing to get access or exclusive access to the instrument they are not expected or encourage to do this. They will not be able to get exclusive access to an instrument and therefore anything they try to do with an instrument can be interrupted and overridden by a Facility Operator who has acquired access to the instrument.
Roles are merely definitions of sets of access permissions, and can be assigned to any number of users. There can be as many Administrators or Managers as needed. And one user can assume as many Roles as needed (both within and across Facilities). If a user has multiple roles within a facility the role with the highest level will be used when checking policy for the user. The system initially will have higher level roles be inclusive of the lower level permissions. Though the system is fully capable of future enhancements that allow for the definition of additional roles that play on permutations (e.g., admin+operator, admin-operator) if that is needed with higher level roles inclusive or exclusive of lower level permissions. Over the course of R2, CI will work with the marine IOs to revise and refine roles as needed.