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. Each identifiable task of each phase of each type of experiment could be a role, and a user need only have certain privileges when acting in a given role.

A longer term goal is to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders and using RBAC's administrative functions. Once a project was defined and a Project Leader assigned to it, that Project Leader would be able to add ORBIT users and add project members and assign them roles within the project as he or she sees fit.

Because ORBIT is designed to be operated as a service available to the research community, no one experiment should affect a future one, and each project must be protected from other projects.

One rationale for using dynamic instead of static separation of duty is to not impose overburdensome restrictions on the roles allowed for the few users on a small project. There are many small ORBIT projects. A given user might be an Adminstrator on one project and just a User on two others. Dynamic separation of duty allows a user to act in two conflicting roles on a single project at two different times.

Adopting dynamic separation of duty implies the use possible less but perhaps more care assigning roles, but it also gives rise to the need log accesses to resources of concern and to check those logs as regularly as required by the cause of the concern.

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.

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

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 resouces, it is possible that access to some resources (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?