Role-based Access¶
The system implements role-based access control through:
Hierarchies and user roles
Authorized Admin Hierarchies, Authorized Admin Hierarchy roles and roles
Hierarchies¶
Users are added to the system at a specific hierarchy level and can then only view system resources available to users at that hierarchy.
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 parent hierarchy.
The diagram shows that a user at VS-Corp has no visibility of GenCorp and InGen.
For users at site level and with a self-service role, an Authorized Admin Hierarchy instance can be assigned that in turn contains an admin role. Such a user is then a multi-role user. For details, see: Authorized Admin Hierarchy.
User Roles¶
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 directly.
Note
The created roles can also be selected and added to an Authorized Admin Hierarchy.
A user role is a combination of:
Rules applying to the role, specifically, the hierarchy types applying to the role. A 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.
Related Topics