Role-based Access#

Overview#

The system implements role-based access control through:

  • Hierarchies and user roles

  • Authorized Admin Hierarchies, Authorized Admin Hierarchy roles, and roles

Related Topics

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.

../../_images/hierarchy-VS-Corp.png

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:

    • Hierarchy Type applied 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.

    • Hierarchies Allowed one or more selected from a list and applied to the role. By default, the selection matches Hierarchy Type.

  • 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.

../../_images/rbac.png

Related Topics