[[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)]] === Previous Work === Siswati Swami's recent "Requirements Specifications for ORBIT Access Control" [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06]] contains an analysis of each of the roles in which an ORBIT user might act when working on an ORBIT project. The analysis is based on use cases [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/IC_TECH_REPORT_200131.pdf NW01]] and [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/fernandez97determining.pdf FH97]]. The specification contains a permissions matrix with access granted or not granted for each combination of an identified role and an ORBIT resource. === Design Issues === Role-based access control for ORBIT has to allow roles to be expressed in a project context. That is, a specific project would be constraint on Project Leader and Project Member roles for example. The primary resources are project-owned data. In [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/i01-kluwer01-jpark.pdf PAS01]] Park, Ahn and Sandhu write "Park and Sandhu identify and describe two different approaches for obtaining a user's attributes on the Web: user-pull and server-pull architectures [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/smart-certificates-extending-x-1.pdf PS99b]] . They classify these architectures based on "Who pulls the user's attributes?" In the user-pull architecture, the user pulls her attributes from the attribute server then presents them to the Web servers, which use those attributes for their purposes. In the server-pull architecture, each Web server pulls user's attributes from the attribute server as needed and uses them for its purposes." LDAP may be used in either approach [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/i01-kluwer01-jpark.pdf PAS01]]. It seems to be a good idea to choose the server-pull architecture because of temporal constraints and to avoid certificate revocation issues. Other design issues and decisions are discussed on the [wiki:Internal/Rbac/OrbitRbacDesign/ThreatAnalysis ORBIT Design Goals and Threats] page. Primary among them is the choice of dynamic separation of duty. The [wiki:Internal/Rbac/OrbitRbacDesign/NistRbacSoftware NIST RBAC Software], [wiki:Internal/Rbac/OrbitRbacDesign/SolarisRbac Solaris RBAC Software], [wiki:Internal/Rbac/OrbitRbacDesign/OasisRbac OASIS RBAC], and [wiki:Internal/Rbac/OrbitRbacDesign/xoRbac xoRBAC] pages cover the four major implementation choices that were identified during [wiki:Internal/Rbac/OrbitRbacDesign/ImplementationResearch Research for Implementation]. The NIST RBAC software was chosen as a starting point for the implementation of ORBIT RBAC support because it is web-oriented, has a server-pull architecture, supports dynamic separation of duty, is Unix-based, and is most likely to be reliable and maintainable. It also should be fairly efficient as it is written in C and Perl with one Java module. The initial design decisions for ORBIT RBAC are identifying and choosing the [wiki:Internal/Rbac/OrbitRbacDesign/ResourcesRoles Resources and Roles] for ORBIT. The [wiki:Internal/Rbac/OrbitRbacDesign/AuditingTools Logging and Auditing] and [wiki:Internal/Rbac/OrbitRbacDesign/ConsistencyChecking Consistency Checking] pages cover design and implementation issues related to logging, auditing and role-assignment consistency checking tools. The [wiki:Internal/Rbac/OrbitRbacDesign/DesignByWiki Design Using Wiki] page notes issues that arose when using a wiki to document work on this project. As work on the ORBIT RBAC project progresses open issues are noted on the [wiki:Internal/Rbac/OrbitRbacDesign/OpenIssues Open Issues] page and removed as they are resolved. A list of the work items that have been identified and are yet to be done on the ORBIT RBAC project are on [wiki:Internal/Rbac/OrbitRbacDesign/WorkToDo Work To Do].