The goal for EmpowerID's self-service access requests in EmpowerID is to deliver compliant access and reduce access feature streamlines the process of granting authorized access to IT resources, removing 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 exception 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 by delivering compliant access, Compliant Access Delivery in EmpowerID includes the following components:
IAM Shop
Eligibility
Approvals and Approval Routing
IAM Shop
EmpowerID provides a central location called the "IAM Shop," from which users can request access to the IT resources your organization makes available. To request resources, users navigate to the IAM Shop, where they can see their current resources and request access to more. Depending on their job function, users may also request roles for other users. To shop for or request membership access to a role, they select the role type and search for the specific roles belonging to that type. Once they have found the role, 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 close the drawer to discontinue. Once a requested role is added to a user’s cart, it stays there until the user either checks out (submits the cart) or removes it. By keeping roles in the cart, users can navigate away from the IAM Shop as needed without losing the contents of their carts. When ready to submit their access requests, users review the roles in their cart, add a reason for requesting those roles and then submit them to the Identity and Access Management platform (EmpowerID). If they decide they don’t want to request a role that is in their cart, they can remove that role.
Figure 1 below shows the main flow that occurs for users shopping for roles in the IAM Shop, as well as the user interface in which the flow occurs.
...
Figure 1: IAM Shop Flow and User Interface
If users have the delegations needed to add themselves or another to the requested role(s) without requiring approval, EmpowerID grants them immediate membership; otherwise, EmpowerID routes request for approval. When approval is required, the process can involve multiple levels of approval depending on the type of resource requested, the user’s existing resources and the parameters applied to the workflows responsible for processing the requests. Approval may first be required from the user’s manager before those requests can be further processed. When such approval is required and the manager rejects a request, no updates occur. If, however, manager approval is not required, the process continues to the next level, which in the case of Business Roles is submission to the RBAC engine for final approval by role owners or other delegated users (when required). For groups the process requires the same final approval. However, before reaching that stage, the workflow determines whether it needs to check each requested role assignment for potential Separation of Duties (SoD) violations. If true, each request is evaluated by the Separation of Duties (SoD) engine to determine whether the resulting role assignment would trigger a violation of current SoD policies. If any potential violations is detected, the workflow routes each violating request to a corresponding risk owner, who must either approve or reject those requests. If there are no SoD violations—or a risk owner approves violations—the requests are then submitted to the RBAC engine for final operational approval in the same way as Business Role requests. In the same manner, if the workflow does not require SoD evaluation, requests are submitted for final operational approval. At any time, rejection by anyone in the approval pipeline stops the assignment. In all cases, EmpowerID maintains a complete record of the business process, including:
Who made the request
The requested role
From where the request originated (IP)
The date and time of the request
Whether the request was approved or denied
Who approved or denied the request
The date and time of the approval or denial
Eligibility
The critical aspect of providing a simple end-user experience for access requests and to ensure that only compliant access can be requested is controlling which items different types of users see and may request. Suppose all end users are presented with the same catalog of requestable items. In that case, the user experience quickly becomes overwhelming and confusing as users must filter through large amounts of data to find the access they are looking for that would be relevant for them to request. Exposing unnecessary data also creates a severe security vulnerability as external users or potentially malicious actors may browse the entire catalog of the organization’s most sensitive roles and resources. Also crucial for regulatory compliance is to blacklist or explicitly deny the ability of certain groups of users ever to see or request specific roles and resources to enforce country-specific restrictions such as the International Traffic in Arms Regulations (ITAR).
Eligibility Policies
EmpowerID offers a powerful policy engine to control which users may see and request which roles and resources in the IAM 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. To further ease the administrative burden, Eligibility policies can be applied to all requestable items of a type by location in addition to one-by-one. This allows policies to be broader, granting or excluding eligibility using the EmpowerID Location tree. For roles, eligibility policies can be applied to their members to control what those members may see and request in the IAM Shop. Policies also apply to the role itself as a possible IAM Shop item to control who may see and request it.
Eligibility policies can be defined as either inclusion rules or exclusion rules. Inclusion rules define the items a user is requests beyond a user's assigned responsibilities. To maintain compliance and ensure security, access requests exceeding standard roles undergo a user-friendly, monitored approval process. EmpowerID manages these requests, emphasizing appropriate justification, traceability, manageability, and temporary access when required. The self-service access system consists of three components: IAM Shop, Eligibility, and Approvals & Approval Routing, which work together to provide compliant access.
IAM Shop
The IAM Shop, a microservice provided by EmpowerID, allows users to request access to IT resources. Users can view their current resources and request additional access based on their job functions. They can search for specific roles, request access, and even set time constraints for their requests. Requests are stored in the user's cart until they are submitted or removed. Users can review the resources in their cart, provide a justification, and submit the request for approval.
Eligibility
To ensure a seamless end-user experience and prevent non-compliant access requests, it is crucial to control the resources that different users can view and request. EmpowerID offers a powerful policy engine called "Eligibility" to manage which users can view and request these items in the IAM Shop. Eligibility policies can be applied to users based on various criteria and can be classified as inclusion rules or exclusion rules.
Inclusion rules specify the resources that users are authorized to see and request in the IAM Shop and to ensure these are only the ones that would make sense for them to request. An application example could be 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 ensure that unwarranted access requests are not generated, creating unnecessary approval tasks. Additionally, inclusion and exclusion rules help organizations provide employees a more pleasant user shopping experience as they are shielded from Inclusion rules include that inappropriate items are not requested, which can result in unnecessary approval tasks. For example, rules can be formulated to filter the resources available to employees with different roles, such as sales employees or developers, to ensure that each type of employee sees a different catalog of requestable resources. Inclusion and exclusion rules provide a more user-friendly shopping experience by removing irrelevant options and shielding employees from requesting unwanted or non-compliant items.
Inclusion rules consist of the following:
Eligible – Users can request items in the IAM request items in the IAM Shop, and and the request will go be sent for approval unless the requesting person has the RBAC delegations needed to grant the access requester has the RBAC delegations required to satisfy the access being requested.
Pre-Approved – Users assigned Users who are assigned the policies are pre-approved for the items that are applicable to which the policy is applicable. When the IAM an IAM Shop user later subsequently requests access, it will not require there is no need for an approval step before being fulfilled. Suggested – The IAM Shop item will show a “Suggested” additional item they may request because of their existing roles or in to be implemented before the fulfillment of the request.
Suggested – In the context of a role they users are currently requesting . The or their existing roles, the IAM Shop item will display a "Suggested" additional item that they can request. The item will still follow standard approval routing rules. be subject to the standard approval routing rules.
By applying appropriate Eligibility policies and using inclusion rules, EmpowerID ensures that users can easily request compliant access and that unnecessary approval tasks are minimized to provide a better user experience.
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's approval routing engine is a powerful tool that ensures that only authorized users have access to sensitive resources. As mentioned earlier, Eligibility policies are considered taken into account when calculating determining if a request requires approval and, if so, how many the number of approval steps and to whom should the tasks be assigned at the assignees for each step. Determination of the The approval process is dynamic and considers the roles of the requestordynamically calculated, considering the requester's roles, the sensitivity of the requested items being requested, and an organization’s the organization's risk and Segregation of Duties (SoD) policies. Based Depending on these factors, approval for a requested item may not be required require approval, or it could require necessitate multiple levels of approval and an additional SoD approval by from a risk owner.
Approvers are notified via receive configurable and localized email notifications with reminder emails that are localized to ensure they have relevant information to make informed decisions. Reminder emails can be configured based on flexible policies . All decisions at each step in the process are to ensure that the approval process is completed efficiently. To ensure accountability, every decision made in the approval process is logged and traceable up through to and including the final fulfillment of access.
Insert excerpt
| Macrosuite divider macro | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|