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

Timestamp:

Oct 25, 2006, 7:15:28 PM (18 years ago)

Author:

anonymous

Comment:

—

Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

@@ -9 +9 @@
 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.
 
-Implementing dynamic instead of static separation of duty should eliminate the possiblity of overburdensome restrictions on the roles allowed for the few members of a small project and on users that are members of more than one project.  A given member might be an Administrator on one project and just a User on two others.  Dynamic separation of duty allows a user to act in two conflicting roles at two different times.
+Implementing dynamic instead of static separation of duty should eliminate the possibility of overburdensome restrictions on the roles allowed for the few members of a small project and on users that are members of more than one project.  A given member might be an Administrator on one project and just a User on two others.  Dynamic separation of duty allows a user to act in two conflicting roles at two different times.
 
 The use of dynamic separation of duty should diminish the care that needs to be taken when assigning roles and it should also eliminate any formal checking for conflicts after role assignments, but it also strengthens the requirement to log accesses and to check those logs regularly.  Project administrators would check for project-level issues and system administrators for cross-project issues.