[[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)]]
=== Work To Do ===
Identify all ORBIT resources and modes of accessing each one.

Agree on ORBIT roles.

Agree on mutually exclusive roles within a project for which any given user cannot be active in both at the same time.

Generate a project implementation plan including a test plan.

Generate an LDAP schema for projects and a create-project.pl script.

Decide whether to keep NIST RBAC/Web structures for roles or to use LDAP.  Except for ORBIT Administrator and Delegated ORBIT Administrator, roles are assigned within a project.  Should include a way to add new roles in the future or at least add new resources to existing roles.  The same role in different projects would grant access to the same resources with the constraint that some resources like sets of measurements are owned by a project.

Implement LDAP projects, roles and permissions for persistent storage and modify NIST RBAC/Web roles monitor code to work in a project context.

Decide if there is any point to extending NIST RBAC/Web scripts that check for conflicts to check across projects.

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 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 as modified 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.

Each Project Administrator's GUI would be similar to the ORBIT Administrator's except it will be for a single project and have restrictions on some functions.

Decide if command-line ORBIT Administrator and Project Administrator commands are needed.

Write and put code in place to log as much access-control information as possible with ways to filter it.

Write auditing code for the ORBIT Administrator and Project Leaders.

Create user documentation for ORBIT Administrator, Project Leader, Project Administrator, Experimenter, Analyst, etc.

Review NIST RBAC/Web C and Perl code (written in 1998 and before) for security issues.

Is a project report required or just an update to the wiki pages?