wiki:Internal/Rbac/OrbitRbacDesign

Version 167 (modified by (none), 18 years ago) ( diff )

—

Table of Contents

    1. Role-Based Access Control
    1. RBAC Reference Model
      1. Previous Work
      2. Design Issues
        1. ORBIT Design Goals and Threats
        1. Resources and Roles
        1. Research for Implementation
        1. Auditing Tools
        1. Consistency Checking
        1. NIST RBAC Software
        1. Solaris RBAC Software
        1. OASIS RBAC
        1. xoRBAC
        1. Designing Using Wiki
        1. Open Issues
      1. Work To Do
    1. LDAP client / server implementation on ORBIT and WINLAB
    2. LDAP Resources
    3. LDAP References
    1. RBAC Resources
    2. RBAC References

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 ORBIT Design Goals and Threats page. Primary among them is the choice of dynamic separation of duty.

The NIST RBAC Software, Solaris RBAC Software, OASIS RBAC, and xoRBAC pages cover the four major implementation choices that were identified during 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 Resources and Roles for ORBIT.

The Logging and Auditing and Consistency Checking pages cover design and implementation issues related to logging, auditing and role-assignment consistency checking tools.

The 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 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 Work To Do.

Note: See TracWiki for help on using the wiki.