.. _role_based_access:

Role Based Access
-----------------

The system implements role-based access control by means of the following components:

* Hierarchy
* User Role

All users that are added to the the system are added at a hierarchy level.
Such a user then only has visibility of, and access to, system resources that are
available to users at that hierarchy level.

On the interface, this means that the user has no visibility of nodes outside of
the sub-tree starting at the parent hierarchy. The user may change to a level of the
hierarchy below the the parent hierarchy.

The following diagram shows that a user at VS-Corp has no visibility of GenCorp and InGen.

|hierarchy-VS-Corp|

From the context of the hierarchy level that a user was created at, role-based
access is implemented. When users are added to the system at a hierarchy level,
a User Role can be assigned to them.

The User Role is a combination of:

* The rules that apply to the role. In particular, the hierarchy
types that apply to the role. This means that the role is
only available to a user at a hierarchy level that belongs to
a hierarchy type associated with the role. For example, a Site
Administrator role may have a rule that associates it with Site
and Building hierarchy types, but not Customer hierarchy types.
In this way a Site Administrator role cannot be associated with
a user created at a Customer hierarchy level. A hierarchy rule
is therefore enforced by the role.
* System permissions to resources from that hierarchy.
* Access Profiles associated with a User Role that
determine access specific operations supported
by different models and/or on miscellaneous permissions.
* The visibility of resource attributes.
* The look and feel of the interface.
* Default values of resource attributes.

|rbac|