wiki:Internal/Rbac/OrbitRbacDesign/OpenIssues

Version 10 (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

Open Issues

Access control has to center on projects. Resources like sets of measurements belong to projects not users. Roles would be role types expressed in the context of a given project. Controlling access might involve not granting access to a user that once was a member of a project, and in fact ran the experiment that created the measurements in question, but no longer is a member. Controlling access also could be a way to limit or stop work on a project if need be.

It is assumed that all members of a given project can see all of that project's scripts, programs and data, but not all scripts, programs and data belonging to each member of the project.

The privileges of users and of projects has to be made more explicit on the ORBIT system. One complication is that scripts and programs are often shared across projects. Such shared resources could be considered objects common to ORBIT, but some might want to restrict the projects among which they are shared.

How do ORBIT objects retain user, group and project ownership?

An ORBIT user would have to set or select a project and a role within that project after logging in. Might default to the last project selected or only one the user is a member of. Similarly for roles, default to last one or only role available for this project. Such commands would have to be implemented in command-line and gui applications that checked an LDAP database.

What role is allowed to cleanup (delete) a project's measurements in the OML?

How is access controlled for each ORBIT object?

Use a user-pull architecture where the user pulls his or her roles from a role server and presents them to web servers or use a server-pull architecture where each web server pulls user's roles and uses them for RBAC? See Figures 2 and 3 in ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/p37-park.pdf PSA01. LDAP can be used with either architecture, see ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/i01-kluwer01-jpark.pdf PAS01 for its use in user-pull and ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/p37-park.pdf PSA01 for its use with SSL between.

Who owns ORBIT data?

Note: See TracWiki for help on using the wiki.