Skip to end of metadata
Go to start of metadata
A set of pre-defined roles can be assigned to users to give them particular privileges.

Policy and Roles

  • The User Account represents an individual human user and stores their preferences and settings. One of these settings is their Name, which is they can edit themselves and is primarily used for human to human communications, e.g., if one operator needs to call another. OOINet users do not need a special OOINet User ID (login name) or password, since the login process is handled through the institution of their choice.
  • A Policy is a set of rules defining what actions someone is allowed to perform on a particular Resource.
  • A Role is a name for a set of Policies. This is a convenience that takes advantage of common patterns of use to make Policy assignments and management easier.

In R2, the system will provide a set of built-in Roles and internal Policies to support them.

Gaining and Managing Access

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.

Allowable Activities by User Role

The grid below shows the allowable activities indicated by a check mark under the role.

Activity Guest
Facility Data
Browse & view OOINet resources
Download Data
Enroll to be a member of a Facility

Subscribe to events associated with OOINet resources  
Request Role within the Facility, including another role
Request access permission to access a specific data product
within the Facility
Post events and add attachments related to individual Data Products      
Post events and add attachments related to Facility assets        
Can delete attachments they have added      
Create Data Products      

Can delete any attachments within their Facility            
Request access permission to operate a specific
instrument within the Facility

Execute Instrument and Driver Commands once access permission granted

Execute Agent Commands and gain Direct Access to an Instrument once
exclusive access is requested and granted

Operate (execute all commands) on any Device (Platform, Instrument)
within the Facility without needing access or exclusive access
Change lifecycle states to PLANNED and DEVELOPED
of Facility devices with access permission granted
Change lifecycle states of Facility resources          
Make changes to the Facility configuration, including creating and
modifying Sites and Deployments and designating assets as primary
Create Site, Deployment and Agent Definition resources within a facility          

Create Instrument, Platform and Agent Instance resources within a facility
Editing of Resource metadata and information        
Activate and Suspend persistence of a Data Product          
Authority to confer Roles to users and granting access
permission to a particular user for an instrument or platform.
Includes ability to view participant information and facility requests.

Additional Details

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.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.