ORBIT Design Goals and Threats

The primary motivation for using role-based access control with the ORBIT Testbed is to insure that every user has sufficient access to each and every ORBIT resource that he or she needs to perform each phase of an experiment without giving each user root privileges. The privileges needed to execute each identifiable task of each phase of each type of ORBIT experiment have been considered, and a set of roles was defined to cover each of these situations consistent with the principle of least privilege ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06.

A longer term goal, also considered in ​http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/Specs2.pdf Swa06 is use RBAC's administrative functions to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders. Once a project is defined and a project leader assigned to it, that project leader would be able to add ORBIT users and add project members to his or her project and assign them roles within that project as he or she saw fit.

It is expected that over the next few years there could be a thousand or more ORBIT users with many hundreds of ORBIT projects. Many of these projects will have just a few members. Some may have many members. The membership of a project may well change over its lifetime. Some members might be removed from a project intentionally, and, when that happens, access to the project's resources should no longer be granted to that former member, despite any user-level access privileges granted by the operating system.

Implementing dynamic instead of static separation of duty should eliminate the possiblity of overburdensome restrictions on the roles allowed for the few members of a small project and on users that are members of more than one project. A given member might be an Administrator on one project and just a User on two others. Dynamic separation of duty allows a user to act in two conflicting roles at two different times.

The use of dynamic separation of duty should diminish the care that needs to be taken when assigning roles and it should also eliminate any formal checking for conflicts after role assignments, but it also strengthens the requirement to log accesses and to check those logs regularly. Project administrators would check for project-level issues and system administrators for cross-project issues.

Because ORBIT is designed to be operated as a service available to the research community each project must be protected from other projects. Experimental scripts, data and results must be private to the project.

ORBIT is designed so that no one experiment should affect a future one. This goal must not be compromised.

Nothing should affect the integrity of experimental results nor any project member's ability to properly interpret those results.

A list of possible threats:

• intentional or unintentional disruption of experiments by nonproject members due to interference with ORBIT resources.
• intentional or unintentional disruption of experiments by project members due to interference with ORBIT resources or project resources.
• unintended read access to a user's or a project's experimental scripts or locally developed components or data results by other users or projects.
• intentional or unintentional modification or deletion of a user's or a project's scripts or own components or data results by nonproject members.
• unauthorized access to ORBIT system code, esp., device driver source or controller scripts.

One reason to limit access for a user to various resources is one of the compentency or accreditation of the user in order to limit damage to or misuse of resources.

Who (what role on the project) is allowed to change data, i.e., remove outliers, otherwise filter data, or delete data sets?

Is it possible that user- or project-developed components may have hidden dependencies on its own or other component's history?

Does the full support of real-time measurement require dedication of some resources above and beyond normal experiments, e.g., impairing other's access?

Does the preferred use of web access to ORBIT services (as an ORBIT policy) have any access control implications?

Are there any requirements related to version control? Is it safe to assume that each project will keep track of it?

Although it does not seem likely with the current ORBIT resources, it is possible that access to some resources, e.g., special instruments, might be limited to protect them from overuse or damage or just to keep the in calibration.

Are there any other threats that might require the use of RBAC with ORBIT?

How are each of these goals affected by or depend upon

• Separation of Duty (SoD),
• the Principle of Least Privilege, and
• Timely Revocation of Trust?

This design assumes that user authentication will be handled separately from access control 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 will not modify scheduling that is currently based on users not projects.

It is assumed that access control will not need to interface 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.

It is probably a good idea to maintain Unicode compatibility (UTF-8 encoding) with user and project names for international use.