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.
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:
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:
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 operation for 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.
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:
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.