wiki:Internal/Rbac/OrbitRbacDesign

Version 148 (modified by hedinger, 18 years ago) ( diff )

—

Table of Contents

    1. Role-Based Access Control
    1. RBAC Reference Model
    1. ORBIT RBAC Design
      1. Previous Work
      2. Design Issues
        1. ORBIT Design Goals and Threats
    5. Error: Page [wiki:Internal/Rbac/OrbitRbacDesign/ImplementationResearch Research for Implementation] does not exist
        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. LDAP client / server implementation on ORBIT and WINLAB
    2. LDAP Resources
    3. LDAP References
    1. RBAC Resources
    2. RBAC References

ORBIT RBAC Design

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, 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.

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 RBAC Software from NIST, Solaris Implementation of RBAC, OASIS Implementation of RBAC, and xoRBAC pages cover the four major implementation choices that were identified during Research for Implementation.

The Logging and Auditing Tools and Consistency Checking Tools pages cover design and implementation issues related to auditing and 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 progressed open issues were noted on the Open Issues page.

Note: See TracWiki for help on using the wiki.