/wiki/spaces/E2D/pages/29982926 / Authorization RBAC / ABAC / Access Levels Overview

Access Levels are bundles of EmpowerID operations and/or native system rights specific to a resource type (such as Exchange mailboxes or user accounts) that when assigned to users give those users 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 (where applicable) to ensure that the level of access to the resources remains consistent for the type and the assignment. For example, one of the Access Levels in EmpowerID is the Contribute Access Level for Microsoft SharePoint. In the native application, Contribute permissions convey a specific level of access in SharePoint, such as allowing for the adding, editing, and deleting of items in existing SharePoint lists and document libraries. The Contribute Access Level for each appropriate SharePoint resource type (SharePoint Document, SharePoint Folder, SharePoint List, and SharePoint Web Site) is defined with these same rights so that the meaning of Contribute in EmpowerID is exactly the same as it is in SharePoint. EmpowerID allows Access Levels like these to be defined for every type of resource managed by EmpowerID so that those levels of access are codified and enforced for each assignment of a Access Level to a user. In this way, a "Contributor" in SharePoint (or a "Reader" in Exchange or an "Initiator" for an EmpowerID workflow) always has the same capabilities against those resources. This centralization of resource-specific role definitions ensures consistency and auditability of permissions and allows organizations to migrate existing user permissions in resources to Access Levels, which can then be mapped to those users' corresponding EmpowerID Person identities. And although many Access Levels can exist per Access Level Definition (for example, if you have 50 assignments of the above Reader In Outlook Access Level to 50 different users, you have 50 Access Levels), Role bloat is avoided because each Access Level is managed by one Access Level Definition per resource type.

Rights are native permissions used by the application or operating system to manage security for the resource type in question. Granting these rights enables capabilities for users in that system, apart from EmpowerID. Being granted rights does not grant the user any abilities within EmpowerID nor does it make the user a potential approver for any operations. EmpowerID provides the ability to inventory these rights and their assignments to users as well as the capability to assign or push these rights into and remove them from native systems through the enforcement process.

Granting the "abilities" of an Access Level Definition occurs through the assignment of an Access Level based on that definition. As an example of this relationship, let's consider the Reader In Outlook Access Level Definition. This Access Level Definition has one right assigned to it, ReadPermission. Any Access Levels based on this definition assigned to users grants 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 image, the Reader In Outlook Access Level Definition is defined with the ReadPermission 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 and each assignment of the Reader In Outlook Access Level will always provide the same functional access to mailboxes (unless you change the rights and operations of the Access Level Definition). 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, George, for one mailbox, Mailbox A. Because George does not have a Reader In Outlook Access Level assignment for Mailbox B, he cannot read that mailbox in EmpowerID (unless he has another Access Level that grants that right).

EmpowerID ships with a large number of default Access Level Definitions for each resource type protected by EmpowerID, including all of the objects of the EmpowerID system itself. Each of these Access Level Definitions are in working order, with unique combinations of EmpowerID Operations and/or native system rights that can be used immediately for managing and delegating resources via Access Level assignments. You can use these Access Level Definitions as well as create your own with custom rights and operations. Access Level Definitions are qualified with assignments of operations in the following way:

Allowed — Adding an operation to a Access Level Definition as "Allowed" grants Access Level assignees the ability to perform the task for which the operation pertains.
Denied — Adding an operation to a 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 with care as selecting it overrides any similar operations that the assignee may be allowed in another Access Level Definition. For example, if an assignee is assigned to an "Administrator" Access Level that allows an operation, but is also assigned to an "Editor" Access Level that denies the same operation, then the operation will be denied, even though the Administrator Access Level authorizes the operation. A "Deny" always overrides any "Allow."
Unassigned — The operation is not allowed, nor is it explicitly denied. You should choose this option to avoid canceling out any similar operations that have been granted to the user in other Access Level assignments.

Delegating Resources

RBAC delegations are achieved in EmpowerID 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 important to consider the projection and enforcement process that EmpowerID uses to manage the security of your resources. These 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. Here are few things to consider when deciding your course of action:

As a best practice, you should use Management Roles whenever possible. Management Roles are more generic and can group a large amount of delegations to protected resources, creating only one EmpowerID Access Level Group in each domain for all members of the Management Role as opposed to the creation of a domain local group (EmpowerID Access Level Group) that occurs for each direct assignment. In addition, using Management Roles provides an extra layer of abstraction between the actor and the delegation, making management easier and reporting and auditing more clear.
Location delegations are also a good choice and they will also result in a single group per domain; however, you can potentially have more groups than you would simply using Management Roles.
The least recommended method for delegating access to resources is using direct assignments and should only be used to cover the delegation "exceptions" that cannot be met by one of the methods mentioned above. The reason this approach should be used sparingly is that it can become cumbersome if you are managing a large number of Access Levels because each direct assignment results in the creation of a separate domain local group for enforcement to the external system.

Access Levels and RBAC Operations

Each resource type protected by EmpowerID has a number of RBAC Operations that can be added to Access Level Definitions to help you leverage the power of RBAC to manage RBAC. This simply means that assignees of Access Levels with RBAC Operations allowed have the ability to manage the Access Level assignments of other EmpowerID Actors against given resource objects. Some examples of these RBAC Operations include the "AddPersonToViewer" operation and the "RemovePersonFromViewer" operation. These operations are available for all resource types and give assignees of the Access Level the ability to grant or remove the "Viewer" Access Level for specific resource objects to or from other users, as long as the assignees of the Access Level have another Access Level with those same operations allowed for the people in question. This is because the action being performed is against two different types of protected resources: the resource object itself and the people being assigned to the object. So for example, if you have an Absence Report, a user named "Bethany" who needs to manage access to the report, a user named "Jacques" who needs to see the report, assigning Bethany a Access Level with the "AddPersonToViewer" operation allowed for the report as well as an Access Level with the "AddPersonToViewer" operation allowed for Jacques will enable her to grant the Viewer Access Level to Jacques so that Jacques can view the report in EmpowerID.

In the following image, Bethany has two Access Levels: One with the AddPersonToViewer operation allowed for an Absence Report and one with the AddPersonToViewer operation allowed for Jacques. These Access Levels allow Bethany to assign the Viewer Access Level for the Absence Report to Jacques, and both are needed for Bethany to complete the assignment. If one or the other is missing, Bethany will not be able to complete the assignment and the delegation she is attempting will route to another person with the ability to approve the assignment. (Approvers are designated people in EmpowerID who have Access Levels with the necessary operations to allow them to perform delegations for others lacking those operations.)

Assigning Access Levels to users in this way allows you to be very granular when distributing Access Level management capabilities to other users, if desired. Notice that Bethany has two Access Level assignments, each with only one RBAC Operation allowed, the AddPersonToViewer operation, that is scoped to only one report and one person. This limits what Bethany can do. She cannot grant the Viewer Access Level for the Absence Report to any other users, nor can she grant Jacques any other abilities for the report (such as editing it). Bethany also cannot remove Jacques from the Viewer Access Level because that operation is not allowed in the Access Levels she has. If it is decided at some point that Jacques should no longer be able to view the report, Bethany will need to be granted the RemovePersonFromViewer operationfor both objects before she can remove him. If these operations are not granted to her, then another user with the appropriate Access Levels will need to perform the task.

Although it is possible to create Access Level Definitions with a single RBAC Operation allowed for each resource type such as this, most organizations will not need that level of granularity, typically having a select group of users responsible for managing the assignment of all Access Levels for a given set of resources. When this is the case, EmpowerID provides several Access Level Definition ready-made for this: the EmpowerID Administrator, Administrator, and Access Level Assigner Access Level Definitions. Each of these Access Level Definitions have the necessary RBAC Operations allowed to give any assignee of those Access Levels full delegation capabilities against the resources for which the definitions apply and within the scope of the assignment. And of these three, the Access Level Assigner Access Level Definition is the best option where delegating the responsibility for resource delegations is the only concern. (The EmpowerID Administrator and Administrator Access Level Definitions contain additional operations that allow for the state of resource objects to be altered, such as deleting those objects.) EmpowerID automatically creates this definition for each resource type, adding to it all RBAC Operations necessary to grant assignees of the Access Level the ability to fully manage who can do what a resource type resource object.

Because the EmpowerID Administrator and Administrator Access Level Definitions contain operations that can alter the state of resource objects, EmpowerID does not recommend assigning these Access Levels to users with delegation responsibilities only. For those situations, the Access Level Assigner Access Level Definition is the best choice because its definition includes all the necessary RBAC Operations while excluding those operations that allow changes to be made to resource state.

Each instance of the Access Level Assigner Access Level Definition has the same common core of RBAC Operations allowed to ensure a consistent meaning for the Access Level in EmpowerID. These RBAC Operations are as follows:

List — This operation grants the actor assigned the operation the ability to view an object in EmpowerID.
ManageAnyResourceRole — This operation grants the actor assigned the operation the ability to assign or unassign any EmpowerID Access Levels for the resource type resource object, such as the Viewer Access Level for a specific computer object, to any other EmpowerID Actor type. This operation is needed to grant or revoke direct assignments of Access Levels for a particular resource object to users.
ManageAnyResourceRoleAssignmentByLocation — This operation grants the actor assigned the operation the ability to assign Access Levels by location for the resource type resource object. This operation is needed to grant or revoke assignments of Access Levels, such as theViewerAccess Level, to another EmpowerID Actor type, for resource objectsby location, meaning the actor needs to have this operation allowedat or below _the location for which they are making a _by locationAccess Level assignment; otherwise, the operation will route for approval. By location operations, such as this, affect all objects in or below the location for which the operation is approved. For example, if you grant this operation to an actor for thesecurity groupresource type, that actor has the ability to grant any Access Level for all security groups in or below the location for which the operation is allowed. Thus, if you have 12 groups in a location named "Switzerland" and 12 groups in a location named “United Kingdom,” and you grant this operation for groups in Switzerland, but not for groups in United Kingdom, to a user named "Bob," then Bob can in turn grant theViewerAccess Level (or theEditorAccess Level or any other Access Level that may exist for groups) to any other EmpowerID Actor type against those groups at the Switzerland location or at any child locations of the Switzerland location, such as Zurich. This type of by location assignment at Switzerland would grant the Access Level for all 12 groups in Switzerland simultaneously — including any groups in locations below Switzerland. Bob, however, would not be able to grant any Access Level assignments against groups in the United Kingdom because he does not have the operation allowed for the United Kingdom location. If Bob attempted to make such an assignment, the operation would route for approval.

The Access Level Definitions for EmpowerID Actor resource types have additional RBAC Operations that allow users to manage Access Levels for those resource types as both targets and actors. So for example, if you assign a user the Access Level Assigner Access Level for an EmpowerID Actor, like a security group, you are giving the user the ability to assign a Access Level, like the Viewer Access Level, for an object, like a report, to the group as well as giving the user the ability to assign the Viewer Access Level for the group to another EmpowerID Actor, like a person, so that that person can see the group. As mentioned above, these types of operations are against two different kinds of resources, so the user must have Access Levels with the appropriate RBAC Operations against both objects. Assigning the Access Level Assigner Access Level for both resource types grants all the necessary privileges.

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, 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 the one Access Level for all three objects will enable her to make these assignments without requiring any approval.

Notice that although Bethany has the ability to manage Access Level assignments for the Absence Report, she cannot access the report. Assignees of any Access Levels that grant them the ability to delegate access to resources cannot delegate to themselves that access. For Bethany to access the report, another user with the appropriate Access Levels must grant that ability to her.

For a list of the operations associated with each Access Level Definition, see Default Access Level Definitions.

Browser not supported