Changes between Version 143 and Version 144 of Internal/Rbac/OrbitRbacDesign

Timestamp:

Sep 20, 2006, 4:37:24 PM (18 years ago)

Author:

hedinger

Comment:

—

Internal/Rbac/OrbitRbacDesign

@@ -4 +4 @@
 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]], and the specification contains a permissions matrix with access granted or not granted for each role and resource combination.
 === 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.
 
-Does hierarchical RBAC solve the seeming need to have per-project instances of each role for per-project resources like its results files?
+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 RBAC Software from NIST], [wiki:Internal/Rbac/OrbitRbacDesign/SolarisRbac Solaris Implementation of RBAC], [wiki:Internal/Rbac/OrbitRbacDesign/OasisRbac OASIS Implementation of RBAC], and [wiki:Internal/Rbac/OrbitRbacDesign/xoRbac xoRBAC] pages cover the four major implementation choices.
+
+The [wiki:Internal/Rbac/OrbitRbacDesign/AuditingTools Logging and Auditing Tools for ORBIT] and [wiki:Internal/Rbac/OrbitRbacDesign/ConsistencyChecking Consistency Checking Tools for ORBIT] pages cover auditing and checking tools.
+
+The [wiki:Internal/Rbac/OrbitRbacDesign/DesignByWiki Issues on 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 progressed open issues were noted on the [wiki:Internal/Rbac/OrbitRbacDesign/OpenIssues Open Issues in the RBAC Design for ORBIT]
+ page.
 
  * [wiki:Internal/Rbac/OrbitRbacDesign/ThreatAnalysis ORBIT Design Goals and Threats]