Page Comparison

...

Direct

Direct assignments scope access to a single resource of a specific resource type, giving the actor receiving the assignment the ability to perform the operations and rights of the Access Level against that resource. An example would be assigning the Help Desk Access Level for the user account owned by "Ruth" to an EmpowerID Person named "Bob." In this example, user account is the resource type, the user account owned by Ruth is the resource, and the EmpowerID Person Bob is the actor. With this type of Access Level assignment, Bob can perform Help Desk operations against Ruth's user account, but not another.

By Location

By-Location assignments scope access to all resources of a specific resource type in a designated location, giving the actor receiving the assignment the ability to perform the operations and rights of the Access Level against those particular resources. An example would be assigning the Help Desk Access Level for all user accounts in Toronto to the Toronto Help Desk group. In this example, user account is the resource type, the user accounts in Toronto are the resources, and the Toronto Help Desk group is the actor. With this type of Access Level assignment, all members of the group can perform Help Desk operations against all the user accounts in Toronto (as well as in any locations for which Toronto is the parent), but not in any other locations.

Relative

Relative assignments scope access to all resources of a specific type that belong to the same location as the actor receiving the assignment. An example would be assigning the Help Desk Access Level for all user accounts in Bob's location to Bob. In this example, user account is the resource type, the user accounts in Bob's location are the resources, and the EmpowerID Person Bob is the actor. With this type of Access Level assignment, Bob can perform Help Desk operations against all the user accounts in his location (as well as in any locations for which his location is the parent), but not in any other locations.

Design Considerations

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. As mentioned above, these delegations can be done by selecting one or more EmpowerID actor types and granting them access directly, by location, or via a role assignment. 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 roles whenever possible. Roles are more generic and can group a large number of delegations to protected resources, creating only one EmpowerID Access Level Group in each domain for all members of the role as opposed to the creation of a domain local group (EmpowerID Access Level Group) that occurs for each direct assignment. In addition, using 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 by using Management Roles.

• The least recommended method for delegating access to resources is using direct assignments. Direct assignments should only be used to cover the delegation "exceptions" that cannot be met by using roles or location delegations. 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.

The goal for self-service access requests in EmpowerID is to deliver compliant access and reduce the need for end-users to request additional access beyond what is granted by their roles. Access requested by a person that is not granted by that person’s roles should be considered an exception and go through a controlled yet easy-to-use approval process before being granted. Exceptions represent an additional risk and create extra work to be processed and approved, as well as audited during compliance recertifications. EmpowerID’s best practice approach to exceptions management ensures that exceptions are always based on proper justification, traceable and auditable, manageable, and temporary whenever possible. To help organizations achieve the best possible outcome delivering compliant access, EmpowerID includes the following components:

• IT Shop

• Eligibility

• Approvals and Approval Routing

IT Shop

The "IT Shop" is a microservice from which users can search for and request access to IT resources your organization makes available to them. To do so, users navigate to the IT Shop, where they can see their current resources and shop for more. Depending on their job function, users may also request resources for other users. To shop for a role or other resource, they simply select the resource type and search for the specific resource item belonging to that type. Once they have found the desired item, they request access, which opens a drawer. From the drawer, users can optionally place time constraints on the request and add it to their carts or simply close the drawer to discontinue. Once a resource is added to a user’s cart, it stays there until the user either checks out (submits the cart) or removes it. By keeping resources in the cart, users can navigate away from the IT Shop as needed without losing the contents of their carts. When ready to submit their requests, users review the items in their cart and when ready submit them to the Identity and Access Management platform (EmpowerID). If they decide they don’t want to request an item that is in their cart, they can simply remove it.

Figure 1 below shows the main flow that occurs for users shopping for roles in the IT Shop, as well as the IT Shop user interface.

...

Eligibility Policies

EmpowerID offers a powerful policy engine to control which users may see and request which resources in the IT Shop. These policies are known as “Eligibility.” Eligibility policies may apply to users by attribute query, role, group, or other criteria, making it easy to target who receives which policies and have the assignment automated and maintained throughout their lifecycle.

Eligibility policies can be defined as either inclusion rules or exclusion rules. Inclusion rules define the items a user is authorized to see and request in the IT Shop and ensure these are only the ones that would make sense for them to request. An example could be eligibility policies with rules that filter resources available for Field Sales employees and developers. The catalog of requestable roles and resources available to each of those employees should be different to ensure that unwarranted access requests and unnecessary approval tasks are not generated. Additionally, inclusion and exclusion rules help organizations provide employees a more pleasant user shopping experience as they are shielded from viewing the organization's entire catalog of IT resources.

Inclusion rules include the following:

• Eligible – Users can request items in the IT Shop, and the request will go for approval unless the requesting person has the RBAC delegations needed to grant the access being requested.

• Pre-Approved – Users assigned the policies are pre-approved for the items to which the policy is applicable. When the IT Shop user later requests access, it will not require an approval step before being fulfilled. 

• Suggested – The IT Shop item will show a “Suggested” additional item they may request because of their existing roles or in the context of a role they are currently requesting. The item will still follow standard approval routing rules. 

...

Figure 2: Eligibility Policy applied to a person

Approvals and Approval Routing

EmpowerID includes a powerful approval routing engine and friendly end-user interfaces for task tracking and decisions. As discussed above, Eligibility policies are considered when calculating whether a user’s request requires approval and if so, how many approval steps are required and to whom should the approval tasks be assigned. Determination of the approval process is dynamic and considers the roles of the requestor, the sensitivity of the items being requested, and an organization’s risk and Segregation of Duties (SoD) policies. Based on these factors, approval for a requested item may not be required or it could require multiple levels of approval and an additional SoD approval by a risk owner.

Approvers are notified via configurable and localized email notifications with reminder emails configured based on flexible policies. All decisions at each step in the process are logged and traceable up to and including the final fulfillment of access.