EmpowerID provides a central location called the "IT Shop" from which users can request access to the Application Roles and Business Roles your organization makes available. To request a role, users navigate to the IT Shop, where they can see their current roles 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.
Figure 1 and Figure 2 below show shows the main flow that occurs for users shopping for roles in the IT Shop, as well as the user interface in which the flow occurs.
Figure 1: IT 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 requestThe date and time of the approval or denialor denied the request
The date and time of the approval or denial
Self-Service and Eligibility
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 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 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 catalog of requestable roles and resources should be different to provide a pleasant user experience and ensure that unwarranted access requests are not generated, creating unnecessary approval tasks.
Eligibility Exclusion rules would be created as a protective measure to enforce regulatory restrictions and ensure that specific classes of users are not accidentally given the ability to request items that they should not. If a user is excluded (either directly or indirectly by virtue of belonging to a group or role that is excluded), the exclusion takes priority over inclusion.
There are three types of eligibility in EmpowerID.
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
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 item may require many levels of approval and an additional SoD approval by the 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.
Architecture of the IT Shop Microservice application
The EmpowerID IT Shop microservice is an EmpowerID application that is predefined with numerous protected application subcomponents—termed “subcomponents” from this point forward—out of the box. These subcomponents provide functional access to the microservice for users in that they make up the individual pages and controls users with which user interact. Each subcomponent is itself an application, which means access to these individual pages and controls can be added to and removed from users through Access Level assignments. Additionally, this architecture makes the microservice customizable. Subcomponents can be added to and removed from the application directly in the EmpowerID Web interface.
Subcomponents configured with the default IT Shop microservice include those listed in the below table.
Subcomponent | Description |
---|---|
Business Roles Advanced Search Control (IT Shop) | Control that lets the user run the Advanced Search on Business Roles. |
Management Roles Page (ITShop) | Page where management roles can be viewed, searched for and requested. |
Target System Control (IT Shop) | Control that lets the user filter the application roles by a specific target system |
All ITShop WebServices | All web services for ITShop |
Application Processes Control (IT Shop) | Control that lets the user search for application roles against a specific application process |
Application Roles Advanced Search Control (IT Shop) | Control that lets the user run the Advanced Search on Application Roles. |
Application Roles High Level Classification Attribute Control (IT Shop) | Control that lets the user see the high-level classification of the application role. |
Application Roles Name Attribute Control (IT Shop) | Control that lets the user see the name of the application role. |
Application Roles Owners Attribute Control (IT Shop) | Control that lets the user see the owners of the application role. |
Application Roles Page (ITShop) | Page where application roles can be viewed, searched for and requested. |
Application Roles Resource System Attribute Control (IT Shop) | Control that lets the user see the resource system of the application role. |
Application Roles TCode Control (IT Shop) | Control that lets the user search application roles via TCode. |
Business Domains Control (IT Shop) | Control that lets the user search for business roles against a specific business domain. |
Business Functions Control (IT Shop) | Control that lets the user search for business roles against a specific business function. |
Business Roles High Level Classification Attribute Control (IT Shop) | Control that lets the user see the high-level classification of the business role. |
Business Roles Name Attribute Control (IT Shop) | Control that lets the user see the name of the business role. |
Business Roles Owners Attribute Control (IT Shop) | Control that lets the user see the owners of the business role. |
Business Roles Page (ITShop) | Page where business roles can be viewed, searched for and requested. |
Business Roles Parent Business Role Attribute Control (IT Shop) | Control that lets the user see the parent business role of the business role. |
Business Roles Role Approvers Attribute Control (IT Shop) | Control that lets the user see the role approvers of the business role. |
Business Roles TCode Control (IT Shop) | Control that lets the user search business roles via TCode. |
Management Roles Advanced Search Control (IT Shop) | Control that lets the user run the Advanced Search on Management Roles. |
Management Roles Name Attribute Control (IT Shop) | Control that lets the user see the name of the management role. |
Management Roles Owners Attribute Control (IT Shop) | Control that lets the user see the owners of the management role. |
Management Roles Type Friendly Name Attribute Control (IT Shop) | Control that lets the user see the type friendly name of the management role. |
Shop for Target Person Control (IT Shop) | Control that lets the user select another user for whom to do assignments of requestable resources. |
Management Roles Advanced Search Control (IT Shop) | Control that lets the user run the Advanced Search on Management Roles. |
Management Roles Name Attribute Control (IT Shop) | Control that lets the user see the name of the management role. |
Management Roles Owners Attribute Control (IT Shop) | Control that lets the user see the owners of the management role. |
Management Roles Type Friendly Name Attribute Control (IT Shop) | Control that lets the user see the type friendly name of the management role. |
Shop for Target Person Control (IT Shop) | Control which lets the user select another user for whom to do assignments of requestable resources. |
Suggested Application Roles Control (IT Shop) | Control that lets the user see the suggested application roles. |
...
...
Next Steps
Page Properties | ||
---|---|---|
| ||
T Shop WorkflowsWhen users interact with the IT Shop and submit requests for groups and Business Roles, they are calling the EmpowerID API to execute a workflow. Depending on the requested role type, EmpowerID processes requests with one of two workflows: The Update Person Direct Assignments workflow for Groups; and, the Update Person Business Roles for Business Roles workflow for Business Roles. Update Person Direct Assignments WorkflowWhen a person submits a request for membership in one or more groups, their action initiates the UpdatePersonDirectAssignments workflow. The workflow contains a number of activities and line rules that are invoked to evaluate and process each request submitted by the user. Figure 3: UpdatePersonDirectAssignments Workflow As seen in Figure 3, the workflow contains six activities and several line rules (depicted by the orange and blue) that direct how the process flows. From a high-level, the process flow is as follows:
Update Person Business Roles WorkflowWhen a person submits a request for membership in one or more Business Roles, their action initiates the UpdatePersonBusinessRoles workflow. Like UpdatePersonDirectAssignments, this workflow contains a number of activities and line rules that are invoked to evaulate and process each request submitted by the user. As shown in Figure 4, the workflow contains six activities and several line rules (depicted by the orange and blue lines) that direct the flow. From a high-level, the process flows as follows:
Workflow ParametersEach EmpowerID workflow is represented to users by a special object known as a request workflow. Request workflows control who may initiate a workflow in EmpowerID and are used to store general settings that determine how the workflow runs. One of these settings is the Parameters setting. Parameters are name value pairs that are used for passing data to a workflow when it is initialized, and when a workflow is configured to expect parameters, that data must be supplied to the workflow or an error will occur. In the case of the Update Person Direct Assignments workflow, the workflow is configured with three parameters, while the Update Person Business Roles workflow is configured with just one. These parameters are as follows:
|