Style | ||
---|---|---|
| ||
Div | ||
---|---|---|
| ||
/wiki/spaces/E2D/pages/29982926 / Authorization RBAC / ABAC / Current: 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.
Info |
---|
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).
...
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.
Info |
---|
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.
Info |
---|
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.
Info |
---|
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. |
Info |
---|
For a list of the operations associated with each Access Level Definition, see Default Access Level Definitions. |
...