wiki:Internal/Rbac/OrbitRbacDesign/ResourcesRoles

Version 13 (modified by (none), 18 years ago) ( diff )

—

Table of Contents

    1. Role-Based Access Control
    1. RBAC Reference Model
      1. Previous Work
      2. Design Issues
        1. ORBIT Design Goals and Threats
        1. Resources and Roles
        1. Research for Implementation
        1. Auditing Tools
        1. Consistency Checking
        1. NIST RBAC Software
        1. Solaris RBAC Software
        1. OASIS RBAC
        1. xoRBAC
        1. Designing Using Wiki
        1. Open Issues
      1. Work To Do
    1. LDAP client / server implementation on ORBIT and WINLAB
    2. LDAP Resources
    3. LDAP References
    1. RBAC Resources
    2. RBAC References

Resources and Roles

Roles are defined by the set of methods of using 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 it as an ORBIT resource could 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/methods 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 ORBIT services and methods 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
  2. Chassis Manager Service: complete access to it or just partial? Careful thinking needed.
  3. Internal Servers: create, rename, delete, read and update
  4. internal databases: create, rename, delete, read, and update
  5. external databases: delete and read for Experimenters; create, rename, and update for ORBIT Administrator maybe
  6. Linux File System: create, rename, delete, read, write, and execute Linux directories and files.
  7. Aruba Sniffer Service: ORBIT Administrator only
  8. Noise Generator Access: read and write
  9. Remote Data Acquisition: future
  10. Registered Applications: where?
  11. SandBoxes: console and node(s)
  12. Grid: in conjunction with scheduler

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 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?

Note: See TracWiki for help on using the wiki.