wiki:Internal/Rbac/OrbitRbacDesign

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

—

Table of Contents

    1. Role-Based Access Control
    1. RBAC Reference Model
    1. ORBIT RBAC Design
      1. Background
      2. Implementation Issues
      3. Design Issues
        1. ORBIT Design Goals and Threats
        1. Auditing Tools
        1. Consistency Checking
        1. NIST RBAC Software
        1. Solaris RBAC Software
        1. OASIS RBAC
        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

Background

Siswati Swami's Requirements Specifications for ORBIT Access Control ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06 Requirements Specifications for ORBIT Access Control. Technical report, Rutgers University, New Brunswick, New Jersey USA, June 2006. ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.doc in MS Word format has analyzed the roles that ORBIT users might assume and produced a role versus resource matrix

Implementation Issues

In ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/i01-kluwer01-jpark.pdf PAS01 Park, Ahn and Sandhu write "Park and Sandhu identified 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 classified 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."

Design Issues

This design assumes that user authentication will be handled separately and will be reliable. It also assumes that ORBIT users will protect their passwords and not intentionally loan them to others. These two assumptions allow a person to be related to a user id.

It is assumed that access control is only related to scheduling in so far as respecting time limits for access to the grid or sandboxes.

It is assumed that access control will not need to interact with cost accounting. It is assumed that any denial of access to overdrawn users will be enforced by user authentication.

If it is required to enforce project-level denial of access due to cost considerations it might be possible to enforce it when an already authorized user attempts to select that project or when he or she accesses an object with a cost associated with it.

Does hierarchical RBAC solve the seeming need to have per-project instances of each role for per-project resources like its results files?

Note: See TracWiki for help on using the wiki.