IT Shop Components and Workflows

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.

IT Shop Workflows

When 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 Workflow

When 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.

As seen in the above image, 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:

1. Upon starting, the workflow logic flows to the SetAssignments activity. This activity simply retrieves the identity of the person initiating the workflow, gathers each requested Application Role and the details about those requests, including time constraints and whether manager pre-approval is required.

2. Based on whether manager approval is required, the process flows to either the Manager Pre-Approval activity or the SetApprovedAssignment activity.

3. If manager approval is required, the workflow notifies the manager and goes into an idle state, awaiting the manager’s decision. After the manager submits their decision, the logic flows to the SetApprovedAssignment activity, which adds all pre-approved roles as target assignments.

4. Regardless of whether manager pre-approval is required, the next stage of the workflow is to evaluate whether potential SoD Violations need to be checked. If the answer is yes, then the logic flows to the Check for SoD Violations activity.

5. The Check for SoD Violations activity checks each potential role assignment against current Separation of Duties policies to determine whether adding the role assignment would trigger a violation. If violations would occur, the workflow routes all violating assignments to risk owners for approval and goes into an idle state pending the risk owner’s decision. After the risk owner submits their decision, the logic flows to the SetSODConfirmation activity, which adds all approved roles as target assignments.

6. Lastly, the logic flows to the Update RBAC Assignments activity, which either updates the role memberships of the user or routes those requests for final operational approval, depending on the delegations of the person initiating the workflow. If the initiator of the workflow does not have the delegations needed to update role membership, the request is routed to all users with the delegations to do so, such as role owners. Once final approval is granted, the updates are committed to the system.

Update Person Business Roles Workflow

When 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 evaluate 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:

1. Upon starting, the workflow logic flows to the systemCodeActivity1 activity. This activity simply retrieves the identity of the person initiating the workflow, gathers each requested Business Role and the details about those requests, including whether the request involves adding or removing roles and whether manager pre-approval is required.

2. Based on whether manager approval is required, the process flows to either the Manager Pre-Approval activity or the ruleDecisionActivity1 activity.

3. If manager approval is required, the workflow notifies the manager and goes into an idle state, awaiting the manager’s decision. After the manager submits their decision(s), the logic flows to the ruleDecisionActivity1 activity, which contains operation activities for adding and removing Business Roles to and from people.

4. If the Business Role is being added to a person, the logic flows to the Assign Operation activity. If the Business Role is being removed from the person, the logic flows to the Unassign Operation Activity. Each operation activity checks to see if the current person in the process has the delegation to assign or unassign the Business Role to and from the target person. If the delegations are present, the role is added to or removed from the person.

5. If the delegations are not present, the operations are routed for approval and the workflow idles. Once approval is granted the workflow resumes and invokes the Apply Provisioning Policies activity, which executes any provisioning policies related to the adding or removing of the role to and from the person.

Workflow Parameters

Each 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:

• DisableManagerPreApproval – Common to both workflows, this parameter is a Boolean used to specify whether pre-approval by the manager of the workflow’s target person is required. If the parameter is set to false for a workflow, pre-approval is required. When this is the case, that workflow invokes the Manager Pre-Approval activity and goes into an idle state pending the manager’s decision. If the parameter is set to true, pre-approval is not required, and the workflow bypasses the Manager Pre-Approval activity and continues to the next activity.

• CheckForSODViolation – This is a Boolean parameter is configured for the Update Person Direct Assignments workflow. If the parameter is set to true, the workflow executes the CheckForSoDViolations activity, which checks each potential Application Role assignment against current Separation of Duties policies to determine whether adding the role assignment to the target person would trigger a violation. If true, the workflow routes all potential violating assignments to risk owners for approval and goes into an idle state pending their decision. If set to false, the workflow bypasses the CheckForSoDViolations activity and continues to the next activity.

• CheckSAPSOD – This is a Boolean parameter that is configured for the Update Person Direct Assignments workflow. If the parameter is set to true, the workflow checks each potential Application Role assignment against current Separation of Duties policies to determine whether adding the role assignment to the target person would trigger a violation in SAP. If true, the workflow routes all potential violating assignments to risk owners for approval and goes into an idle state pending their decision. If set to false, the workflow bypasses the check and continues to the next activity.