What are Access Levels?

Access Levels in EmpowerID are bundles of operations and/or native system rights specific to a resource type (such as Exchange mailboxes or user accounts). When assigned to users, these Access Levels grant them the ability to access IT resources in the manner specified by the Access Level. Each resource type has its own set of Access Levels defined with different combinations of EmpowerID operations and rights to ensure consistency in access levels for the type and assignment.

For example, the Contribute Access Level for Microsoft SharePoint in EmpowerID is defined with the same rights as Contribute permissions in the native application, allowing users to add, edit, and delete items in existing SharePoint lists and document libraries. EmpowerID allows Access Levels like these to be defined for every type of resource it manages so that those levels of access are codified and enforced for each assignment of an Access Level to a user.

This centralization of resource-specific role definitions ensures consistency and auditability of permissions, enabling organizations to migrate existing user permissions in resources to Access Levels, which can then be mapped to their corresponding EmpowerID Person identities. Although many Access Levels can exist per Access Level Definition (for example, 50 assignments of the Reader In Outlook Access Level to 50 different users), role bloat is avoided since each Access Level is managed by one Access Level Definition per resource type.

Granting the abilities of an Access Level Definition is achieved through assigning an Access Level based on that definition. For instance, let's take the Reader In Outlook Access Level Definition as an example. This Access Level Definition has one right assigned to it, Read Permission. Any Access Levels created based on this definition and assigned to users grant those users native Read permissions for each mailbox against which the assignment is made. These assignments can be as broad as to include every mailbox within an organization or as limited as to include only a single mailbox.

In the following scenario, the Reader In Outlook Access Level Definition is defined with the Read Permission right for Exchange Mailboxes. This one Access Level Definition can be used as the basis for assigning the corresponding Reader In Outlook Access Level to any number of users for any number of mailboxes. Each assignment of the Reader In Outlook Access Level will always provide the same functional access to mailboxes (unless the rights and operations of the Access Level Definition are changed). Users can only access the mailboxes for which the assignment of the Access Level occurs. In our example, we have assigned the Reader In Outlook Access Level to one user, Sally, for one mailbox, Mailbox A. Since Sally does not have a Reader In Outlook Access Level assignment for Mailbox B, she cannot read that mailbox in EmpowerID (unless she has another Access Level that grants that right).

Open

EmpowerID comes with a large number of pre-configured Access Level Definitions for each resource type it protects, including all objects within the EmpowerID system itself. These Access Level Definitions are ready-to-use, featuring unique combinations of EmpowerID Operations and/or native system rights that can be immediately employed for managing and delegating resources via Access Level assignments. You can use these Access Level Definitions or create your own with custom rights and operations.

Access Level Definitions qualify assignments of operations in the following ways:

1. Allowed – Adding an operation to an Access Level Definition as "Allowed" grants Access Level assignees the ability to perform the task for which the operation pertains.

2. Denied – Adding an operation to an Access Level Definition as "Denied" explicitly denies Access Level assignees the ability to perform the task for which the operation pertains. This option should be chosen carefully, as selecting it overrides any similar operations that the assignee may be allowed in another Access Level Definition. For instance, if an assignee has an "Administrator" Access Level that allows an operation, but is also assigned an "Editor" Access Level that denies the same operation, the operation will be denied, even though the Administrator Access Level authorizes it. A "Deny" always overrides an "Allow."

3. Unassigned – The operation is neither allowed nor explicitly denied. This option should be selected to avoid canceling out any similar operations that have been granted to the user in other Access Level assignments. By choosing "Unassigned," you ensure that the Access Level Definition neither grants nor denies the operation, allowing other assigned Access Levels to dictate the user's permissions for that specific operation.

Delegating Resources

In EmpowerID, RBAC delegations are achieved through the assignment of Access Levels. Access Levels can be assigned directly to one of the Actor types or to Management Role Definitions and their child Management Roles, to which Actors are then assigned.

When designing a delegation model, it is crucial to consider the projection and enforcement process that EmpowerID employs to manage the security of your resources. Delegations can be done by selecting people, accounts, groups, Business Roles and Locations, or SetGroups, and granting them access directly, by location, or via a Management Role. The access type chosen in the delegation will impact the number of domain local groups created later for the Access Levels that get enforced. Keep these considerations in mind when deciding your approach:

1. As a best practice, use Management Roles whenever possible. Management Roles are more generic and can group many delegations to protected resources, creating only one EmpowerID Access Level Group in each domain for all members of the Management Role. This is opposed to the creation of a domain local group (EmpowerID Access Level Group) that occurs for each direct assignment. Additionally, using Management Roles provides an extra layer of abstraction between the actor and the delegation, making management easier and reporting and auditing more transparent.

2. Location delegations are also a good choice, resulting in a single group per domain. However, you may potentially have more groups than you would be using Management Roles alone.

3. Direct assignments are the least recommended method for delegating access to resources and should only be used to cover the delegation "exceptions" that cannot be met by one of the other methods mentioned above. This approach should be used sparingly because it can become cumbersome when managing a large number of Access Levels, as each direct assignment results in the creation of a separate domain local group for enforcement in the external system.

Access Levels and RBAC Operations

Access Levels and RBAC Operations in EmpowerID allow you to take advantage of RBAC to manage the access of various users to different resources. Assignees of Access Levels with RBAC Operations can manage the Access Level assignments of other EmpowerID Actors for specific resource objects. Examples of these RBAC Operations include "AddPersonToViewer" and "RemovePersonFromViewer", which enable users to grant or remove the "Viewer" Access Level for specific resources.

For instance, in the given example, Bethany needs to manage access to an Absence Report for Jacques. She is assigned two Access Levels: one with the "AddPersonToViewer" operation allowed for the Absence Report and another with the same operation allowed for Jacques. This enables her to grant Jacques the Viewer Access Level for the Absence Report. Both Access Levels are needed for Bethany to complete the assignment, and if one is missing, the delegation will route to another person with the ability to approve the assignment.

Open

Assigning Access Levels in a granular manner allows for precise control over user capabilities in managing Access Level assignments. Bethany's example demonstrates that she has limited capabilities due to her Access Levels, each with a single RBAC Operation allowed, scoped to one report and one person. This restricts her actions, such as granting the Viewer Access Level for the Absence Report to other users or granting Jacques additional abilities.

In most organizations, a high level of granularity may not be necessary. Instead, they often have a select group of users responsible for managing Access Level assignments for a set of resources. EmpowerID offers ready-made Access Level Definitions to address this need.

Returning to our example above, if we decided that we wanted to broaden Bethany's delegation responsibilities for the Absence Report so that not only could she grant Jacques the ability to view the report, but she could also grant members of the HR Group the ability to both view and edit the report as well as grant another user named "Michael" the ability to delete the report, we could simply grant her a direct assignment to the Access Level Assigner Access Level for each of the objects. Because the Access Level Assigner Access Level Definition contains all the operations needed for delegations, granting Bethany one Access Level for all three objects will enable her to make these assignments without requiring any approval.