Changes between Version 3 and Version 4 of Internal/Rbac/OrbitRbacDesign/WorkToDo

Timestamp:

Oct 10, 2006, 2:25:01 PM (18 years ago)

Author:

anonymous

Comment:

—

Internal/Rbac/OrbitRbacDesign/WorkToDo

@@ -19 +19 @@
 Assuming most users will work on a single project with one or more nonconflicting roles, it is possible to activate all those roles in that one project when the user logs in.  It might be best though to require an explicit GUI or command-line command to pick a project and activate roles in it. In any case, assuming that some mutually exclusive roles within a project are identified, the GUI and command-line commands need to be written.
 
-For each ORBIT RBAC resource, create methods to establish project ownership of it and control access to it.  This work includes temporal ownership and probably would involve an interface to or modification of the ORBIT scheduler.
+For each ORBIT RBAC resource, create methods or modify existing ones to assign project ownership of it and control access to it.  This work includes temporal ownership and probably would involve an interface to or modification of the ORBIT scheduler.
 
-Integrate access control code for each resource with the NIST RBAC/Web code.
+Integrate access control code for each resource with the NIST RBAC/Web code as modifed for the ORBIT RBAC roles.
 
 Create a GUI interface for the ORBIT Administrator to 1) browse, add, modify and delete ORBIT users;  2) browse, add, modify and delete ORBIT projects;  3) browse, add, modify and delete Project Leaders and Project Administrators; set logging options, configure audit options; and assign a user to the Designated ORBIT Administrator role.  Note that each Project Administrator's GUI would be similar to ORBIT Administrator except for a single project and with restrictions on some functions.