Resources and Roles

Roles are defined by the set of methods presented by services controlling resources to which users active in a role will be granted permission to access. The roles defined for ORBIT will apply uniformly to each ORBIT project. There will be no custom roles for specific projects, i.e., it is a completely orthogonal design.

Is it not anticipated that there will be any project-specific resources. Any future project-specific resource first would have to integrated into ORBIT as a service so that access to the methods of using it as an ORBIT resource can be controlled. Second, all ORBIT roles would have to be modified, perhaps trivially, to grant or not grant access to each of the service's methods.

The design of the ORBIT RBAC resources and roles needs to be as extenisble as possible regarding adding resources.

As much effort as possible in the time available has gone into identifying all of ORBIT's resources and defining ORBIT roles. It is posible though that experience with projects and role-based access control in ORBIT or future uses of ORBIT will require changes to ORBIT roles. An extensible design regarding redefinition of roles is not an explcit goal of this design.

A key decision is what pairs of roles will be mutually exclusive for purposes of dynamic separation of duty, i.e., no user will be allowed to be active in both roles at the same time.

The list of ORBIT Resources below is adapted from the table of resources and roles on page 12 of ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06. It has been revised to focus on the methods presented to users by ORBIT services that control the ORBIT hardware and software resources ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/orbit-software-architecture-v2-1.pdf OvSS05. For database methods see "An introduction to MySQL permissions" ​http://www.databasejournal.com/features/mysql/article.php/10897_3311731_2 Gil04 or Chapter 5 "Database Administration" in the MySQL 3.23, 4.0, 4.1 Reference Manual ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/konquerorh9E2Ta.1-en.pdf MyS06a.

ORBIT Resources

1. ORBIT Measurement Service (OML): Initialize database for measurement collection, collect measurements, move results to external database.
2. Chassis Manager Service (CMC): power on, reset, and power off nodes, one at a time or all at once; careful thinking needed.
3. Frisbee: install and save images.
4. Application Repository: supply registered applications; common and project-owned?
   1. Internal Servers: create, rename, delete, read and update.
   2. internal databases: create, rename, delete, read, and update.
   3. external databases: delete and read for Experimenters; create, rename, and update for ORBIT Administrator (maybe).
5. Linux File System: create, rename, delete, read, write, and execute for Linux directories and files.
   1. files hold Experiment Descriptions [EDs], Application Descriptions [ADs], OML schemas, application code.
6. Grid: console and node(s) in conjunction with scheduler.
7. SandBoxes: console and node(s) in conjunction with scheduler.
8. Aruba Sniffer Service: ORBIT Administrator only.
9. Noise Generator Access: read and write.
10. Remote Data Acquisition: future.

ORBIT Roles

1. ORBIT Administrator: browse, add, modify and delete ORBIT users; browse, add, modify and delete ORBIT projects; browse, add, modify and delete Project Leaders and Project Administrators; set logging options and audit ORBIT logs; can delegate to Designated ORBIT Administrator; cardinality = 1.
2. Designated ORBIT Administrator: same privileges as ORBIT Administrator except cannot delegate role; cardinality = 1.
3. Principal Investigator: can modify or delete results of any of the project's experiments; has complete access to any project-specific resources; can delegate to Designated Principal Investigator; can appoint Project Administrator; inherits Project Administrator role, i.e., can perform all Project Administrator functions; cardinality = 1 per project.
4. Designated Principal Investigator: same privileges as Project Leader except cannot delegate; cardinality = 1 per project.
5. Project Administrator: browse selected fields of and add ORBIT users; add and delete users to and from roles in his or her project; can delegate role to Designated Project Administrator; cardinality = 1 per project.
6. Designated Project Administrator: same privileges as Project Administrator except cannot delegate; cardinality = 1 per project.
7. Experimenter: all privileges to run an ORBIT experiment and analyze results, but not modify or delete results.
8. Analyst: can only analyze results of an ORBIT experiment, not run one.
9. Developer: not sure what the scope of a developer's privileges should be. Does a developer need to become an Experimenter to run a test?

If we can identify substantially different types of ORBIT experiments, we may want more than one Experimenter role.

Might consider a separate ORBIT database administrator role too to backup and restore stuff and clean out and maybe archive stuff.

The members of a project would be the union of all the members of a project's roles.

Who owns the Experimental Descriptions [EDs] and Application Descriptions [ADs], Matlab scripts, prototypes, applications, builds, etc. How would they be shared among projects once role-based access control is in effect? Does a common area for some of these things make sense? Do projects own certain applications?

Is there any classified work or company-confidential work on ORBIT? What are the implications?

Is there any need for ORBIT cost accounting? If so, how does role-based access control interface to it?