The overall goal of Compliant Access Delivery is to reduce the need for end-users to request additional access, aka also known as “exceptions.” Access not granted by a person’s roles is considered an exception and must go through a controlled yet easy-to-use process before being granted. By implementing a well-defined role model driven by changes in authoritative systems and enhanced by Role Mining and optimization, we expect requests for exceptional access to remain under 20% of a user’s total access. Exceptions represent an additional risk and create manual work for their processing and approval and extra audit work 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, Compliant Access Delivery in EmpowerID includes the following components:
IT Shop
Eligibility
IT Shop
EmpowerID provides a central location called the "IT Shop" from which users can request access to the Application Roles and Business Roles IT resources your organization makes available. To request a roleresources, users navigate to the IT Shop, where they can see their current roles 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 simply 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 simply 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 IT 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 simply remove that role.
...
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 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. 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 the those members may see and request in the IT Shop. Policies also apply to the role itself as a possible IT 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 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 application example for a multinational company would be a Field Sales employee in Austria that should not see the same requestable items as a Developer in Brazil. Their 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 to provide a pleasant user experience and 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 the following:
...
Figure 2: Eligibility Policy applied to a person
Approvals and Approval Routing
Being built on a workflow paradigm, 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 if a request requires approval and if so, how many approval steps and to whom should the tasks be assigned at each step. 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 an , approval for a requested item may require many not be required or it could require multiple levels of approval and an additional SoD approval by the a risk owner or skip the approval process entirely. .
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.
...