Changes between Version 8 and Version 9 of Internal/Rbac/OrbitRbacDesign/ResourcesRoles

Timestamp:

Oct 5, 2006, 4:12:24 PM (18 years ago)

Author:

anonymous

Comment:

—

Internal/Rbac/OrbitRbacDesign/ResourcesRoles

@@ -1 +1 @@
 [[TOC(Internal/Rbac, Internal/Rbac/OrbitRbacLevels, Internal/Rbac/OrbitRbacDesign, Internal/Rbac/OrbitRbacDesign/ThreatAnalysis, Internal/Rbac/OrbitRbacDesign/ResourcesRoles, Internal/Rbac/OrbitRbacDesign/ImplementationResearch, Internal/Rbac/OrbitRbacDesign/AuditingTools, Internal/Rbac/OrbitRbacDesign/ConsistencyChecking, Internal/Rbac/OrbitRbacDesign/NistRbacSoftware, Internal/Rbac/OrbitRbacDesign/SolarisRbac, Internal/Rbac/OrbitRbacDesign/OasisRbac, Internal/Rbac/OrbitRbacDesign/xoRbac, Internal/Rbac/OrbitRbacDesign/DesignByWiki, Internal/Rbac/OrbitRbacDesign/OpenIssues, Internal/Rbac/OrbitRbacDesign/WorkToDo, Internal/Rbac/LdapResources, Internal/Rbac/RbacResources)]]
 ==== 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.
+Roles are defined by the set of pairs of resources and methods of access to them to which users active in a role will be granted permission (or not).  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 currently 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, then all ORBIT roles would have to be modified, perhaps trivially, to grant or not grant access to each of the service's methods.
 
-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 design of the ORBIT RBAC resources and roles needs to be as extenisble as possible regarding adding resources.
 
-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]].
+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 ORBIT services that control the ORBIT hardware and software resources.  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. internal databases:  create, rename, delete, read and update
- 1. 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]].
- 1. Linux File System:  create, rename, delete, read from, write to, and execute Linux files.
- 1. Chassis Manager Service: complete access to it
- 1. Aruba Sniffer:  complete access to it or just use of captured packets
- 1. Noise Generator Access:  complete access to  it or just use of it
- 1. Grid Authentication:  
+ 1. ORBIT Measurement Service:  OML
+ 1. Chassis Manager Service: complete access to it or just partial?  Careful thinking needed.
  1. Internal Servers:  create, rename, delete, read and update
- 1. Remote Data Acquisition:  
- 1. Applications:  where?
- 1. !SandBoxes:  complete access or component-by-component access?
- 1. Grid:  via scheduler
- 1. Network Devices:  
+ 1. internal databases:  create, rename, delete, read, and update
+ 1. external databases:  delete and read for Experimenters; create, rename, and update for ORBIT Administrator maybe
+ 1. Linux File System:  create, rename, delete, read, write, and execute Linux directories and files.
+ 1. Aruba Sniffer Service:  ORBIT Administrator only
+ 1. Noise Generator Access:  read and write
+ 1. Remote Data Acquisition:  future
+ 1. Registered Applications:  where?
+ 1. !SandBoxes:  console and node(s)
+ 1. Grid:  in conjunction with scheduler
 
-Is it expected that there will be any project-specific resources?
 
 ORBIT Roles