Changes between Version 31 and Version 32 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

Timestamp:

Oct 6, 2006, 4:13:38 PM (18 years ago)

Author:

anonymous

Comment:

—

Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

@@ -3 +3 @@
 The primary motivation for using role-based access control with the ORBIT Testbed is to insure that every user has sufficient access to each and every ORBIT resource that he or she needs to perform each phase of an experiment without giving each user root privileges.  The privileges needed to execute each identifiable task of each phase of each type of ORBIT experiment have been considered, and a set of roles was defined to cover each of these situations consistent with the principle of least privilege [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]].
 
-A longer term goal, also considered in [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]] is use RBAC's administrative functions to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders.  Once a project is defined and a project leader assigned to it, that project leader would be able to add ORBIT users and add project members to his or her project and assign them roles within that project as he or she saw fit.
+Appropriately limiting access to resources will protect one project from interfering with any other project and minimize the occurrence of some potential problems within projects. 
+
+Another goal, also considered in [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]] is use RBAC's administrative functions to simplify the administration of ORBIT projects and project members by delegating project administration to each project's Principal Investigator (PI).  Once a project is defined and a PI assigned to it, that PI would be able to add ORBIT users and assign ORBIT users to roles within the project as he or she saw fit.
 
 It is expected that over the next few years there could be a thousand or more ORBIT users with many hundreds of ORBIT projects.  Many of these projects will have just a few members.  Some may have many members.  The membership of a project may well change over its lifetime.  Some members might be removed from a project intentionally, and, when that happens, access to the project's resources should no longer be granted to that former member, despite any user-level access privileges granted by the operating system.
@@ -26 +28 @@
 One reason to limit access for a user to various resources is one of the compentency or accreditation of the user in order to limit damage to or misuse of resources. 
 
-Who (what role on the project) is allowed to change data, i.e., remove outliers, otherwise filter data, or delete data sets?
+Should only the Principal Investigator on a project be allowed to change data, i.e., remove outliers, otherwise filter data, or delete data sets?
 
 Is it possible that user- or project-developed components may have hidden dependencies on its own or other component's history?