Table of Contents
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?
Who owns ORBIT data?