Resources and Roles

The specific ORBIT roles are defined mainly by the ORBIT resources to which they will be granted permission (or not). Any errors or misunderstandings in the list of ORBIT resources may well result in missing possible ORBIT roles that might require changes later on.

A key decision is what roles will be mutually exclusive for 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.

ORBIT Resources

1. internal databases: create, rename, delete, read and update
2. external databases: create, rename, delete, read and update; 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.
3. Linux File System: create, rename, delete, read from, write to, and execute Linux files.
4. Chassis Manager Service: complete access to it
5. Aruba Sniffer: complete access to it or just use of captured packets
6. Noise Generator Access: complete access to it or just use of it
7. Grid Authentication:
8. Internal Servers: create, rename, delete, read and update
9. Remote Data Acquisition:
10. Applications: where?
11. SandBoxes: complete access or component-by-component access?
12. Grid: via scheduler
13. Network Devices:

Is it expected that there will be any project-specific resources?

ORBIT Roles

• 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.
• Designated ORBIT Administrator: same privileges as ORBIT Administrator except cannot delegate role; cardinality = 1.
• Experimenter: all privileges to run an ORBIT experiment and analyze results, but not modify or delete results.
• Analyst: can only analyze results of an ORBIT experiment, not run one.
• 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.
• Designated Project Administrator: same privileges as Project Administrator except cannot delegate; cardinality = 1 per project.
• Project Leader: can modify or delete results of any of the project's experiments; complete access to any project-specific resources; can delegate to Designated Project Leader; cardinality = 1 per project.
• Designated Project Leader: same privileges as Project Leader except cannot delegate; cardinality = 1 per project.
• Developer: not sure what the scope of a developer's privileges should be. Does a developer become and Experimenter to run a test?

If there are different types of ORBIT experiments, may want more than one Experimenter role.

Might consider an 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?