The SoD Review uses the Risk Analysis and Remediation (RAR) and Compliant User Provisioning (CUP) capabilities of SAP BusinessObjects Access Control. On a high level, you can divide its configuration into the following tasks:

• Verification of SAP BusinessObjects Access Control 5.3 post-installation steps
• Configuration of user review options
• Setup of the approval workflow
• Maintenance of rejection reasons
• Maintenance of coordinator-to-reviewer relationships

The following sections explain each of these tasks in more detail.

Verification of SAP BusinessObjects Access Control 5.3 Post-Installation Steps

The post-installation phase refers to a bundle of rather technical configuration steps required in both product capabilities before you can start customizing your specific use cases. You need to perform the post-installation immediately after installation of the SAP BusinessObjects Access Control software on an SAP NetWeaver Application Server Java 7.0 and the required Real Time Agents (RTAs) on the back-end systems. For details of the post-installation steps, refer to the SAP BusinessObjects Access Control 5.3 Configuration Guide and my earlier articles mentioned at the beginning of the first part of this article. I’ll assume for the following that post-installation has been executed correctly in your SAP BusinessObjects Access Control system, but verify that you have performed the prerequisite actions on the following items:

• Initial data file for the SoD Review: The AE_init_append_data_ForSODUARReview.xml file has to be uploaded in menu path CUP > Configuration > Initial System Data. This .xml file comes with the software, and Support Packages may deliver updated versions. The initial data file adds a request type SOD_REVIEW and a priority SOD_HIGH, which you can verify in menu path CUP > Configuration > Request Configuration.
• Workflow type SOD_REVIEW: The initial data file also adds the workflow type SOD_REVIEW to menu path CUP > Configuration > Miscellaneous. Ensure that it is activated and that the exit URI, user name, and password are maintained as well.
• User details data source for manager information: If you opt for the user’s manager as the reviewer, then make sure that your user details data source is correctly set up and contains correct and up-to-date manager information. If you’re using an LDAP server, then verify that the attribute containing the manager of a given user is correctly mapped in menu path CUP > Configuration > Field Mapping > LDAP Mapping.
• Security lead: Maintain your security lead information in menu path CUP > Configuration > Approvers > Security Lead. You do this because the security stage is mandatory for the SoD Review.
• SMTP server: Sending notifications and reminders via email to users, reviewers, and approvers requires the configuration of an SMTP server in menu path CUP > Configuration > Workflow > SMTP Server. Also, check whether the Email Dispatcher and Email Reminder tasks are scheduled in CUP as recurring background jobs. If they are not, email notification won’t be sent out.
• Number range: Ensure there is an active number range in CUP. The number range is applicable to all CUP requests and is not specific to any request types. Go to Configuration > Number Ranges to maintain number ranges.
• Connectors: Make sure that connectors have been created in CUP and RAR for each back-end system in scope for SOD Review — all having the same name. This is required for generation of role usage information.
• UME security: With Support Package 6, new UME actions for rejecting and managing the rejected users were shipped and must be assigned to administrators and reviewers. These actions were provided in the initial data files as of Support Package 6. 

Configuration of User Review Options

In CUP > Configuration > User Review > Options, go to the SoD Review frame and specify important options for your SoD Review scenario (Figure 1). These are:

• Admin. review required before sending tasks to reviewers: The preferred setting is Yes because it gives the administrator the opportunity to check if all requests are going to be sent to the correct reviewers and make corrections where needed. Administrators can also delete requests during the review. If there are users without manager information in the user detail data source, then you must enable the administrator review to generate requests.
• Who are the reviewers?: Specify if managers or risk owners are going to be the reviewers. In general, managers acting as reviewers have a more realistic picture of the degree to which access can be removed and assigned to other users and where mitigation controls are the only option to deal with SoD violations.
• Number of Line Items per Request: If more line items need to be sent to the same reviewer, CUP creates additional requests.
• Default Request Type: The only request type available is SoD Review. It has been uploaded with the initial data file.
• Default Priority: The only priority available is SoD High.
• Enter the URL for SoD review instructions: If an HTML page with detailed instructions for reviewers (Figure 6 in part 1) was created to supplement any instruction in the email notification, enter the URL of that page. You can save that page to a local directory of your choice on your internal server.

Figure 1

User review options for SoD Review

Setup of the Approval Workflow

A workflow in CUP always consists of an initiator, one or multiple stages, and a path linking a sequence of stages together. This allows for a flexible configuration of workflows for SoD Review according to your organization’s requirements. For this reason, the example I’ll present is a very common one, but not the only way of doing it.

The workflow contains the following features:

• The first stage of the workflow is the review stage
• If line items in a request are marked for removal by the reviewer, then the request is sent to a security stage
• If all line items of a given request are mitigated, then the request is closed without being sent to the security stage
• The security administrator only sees the line items of each request that was marked for removal by the reviewers
• The security administrator only has permission to change the request content in terms of approvals and removals

To implement this workflow, you need to define the following:

• Initiator
• Review stage
• Security stage
• Primary path containing the review stage
• Detour path containing the security stage
• Detour linking the two paths together

You can define the initiator in menu path CUP > Configuration > Workflow > Initiator, and it’s straightforward. Make sure that you select SoD Review as the workflow type first. You’ll also need to select this workflow type for all other workflow elements (e.g., stages, paths, and detours). For this example, I’m just adding as a condition the attribute Request Type with the value SoD Review to the initiator. However, for the workflow type SoD Review, you also have the attributes Application and SoD Review Risk available to build more complex Boolean conditions to support multiple workflow paths in parallel for your SoD Review scenario.

In menu path CUP > Configuration > Workflow > Stage, define the review stage and select Reviewer as the approver determinator. You can define a request wait time and an escalation configuration, which defines which type of escalation action is made, if the SoD request isn’t submitted in this stage during the request wait time. The following options are available:

• Forward to next stage
• Forward to administrator
• Deactivate; Forward to next stage: The role assignments for users on the request are deactivated with the validity date set to the current date, and the request is forwarded to the next stage.
• Deactivate; Lock, Forward to next stage: The users on the request are locked, in addition to the measures taken in the previous option.
• Lock, Forward to next stage: Only the users on the request are locked, and the request is forwarded to the next stage.

Then configure the notification options in the same way you would for any other stage in CUP. In the additional Configuration pane, you can choose from a number of parameters available (Figure 2). Some of them are of specific interest for the SoD workflow:

• Change Request Content: Controls whether the approver is permitted to change the request content in terms of Mitigate or Removal of SoD line items
• Reject Users: Requires, in the reviewer stage, the ability to reject users if the reviewers were configured to be the user’s managers
• Approval Type: Determines whether all line items of the request or only items marked for removal are visible to the approver of this stage

Figure 2

Additional configuration section during definition of the review stage

The security stage is defined in the same way as the review stage. Select Security as the approver determinator. You should also apply the same Additional Configuration settings as for the review stage (Figure 2), with the exceptions of Reject Users (set to No) and Approval Type (set to Only Remove Items).

Define the primary path, including the review stage, in menu path CUP > Configuration > Workflow > Path (Figure 3). Select the initiator and the review stage previously created, and select the Active check box.

Figure 2

Creation of the primary path for the SoD Review workflow containing the review stage

In this example, I only want those requests to be sent through the workflow to the security stage that contains line items for removal, so I need to use the more advanced Detour feature in CUP. Detours are standalone workflows that are engaged through a primary workflow if certain conditions are encountered at a particular stage of the primary workflow. For this reason, you need to create a second path with no initiator included, but with the detour option checked and the security stage selected as a single stage. Then follow menu path CUP > Configuration > Workflow > Detour/Fork and make the selections as shown in Figure 4. The condition Items With Remove Action controls whether a request is routed into the Detour Path, or closed after the SoD_Review stage.

Figure 4

Detour definition

Maintenance of Rejection Reasons

Managers acting as reviewers in the review stage need to select a reason from a drop-down list when rejecting users. During configuration, you need to upload a list of reasons in menu path CUP > Configuration > User Review > Reason for Rejection. The required spreadsheet template can be downloaded from there, filled with data, and then uploaded again (Figure 5).

Figure 5

Uploading reasons for rejection

Maintenance of Coordinator-to-Reviewer Relationships

You identify a coordinator for each reviewer, regardless of whether the reviewer is a user’s manager or a risk owner. SAP BusinessObjects Access Control uses the coordinator information to generate reports that you can use while managing the review process. If you are not using Administrator Review, then you must have a coordinator associated with the reviewer to generate requests for SoD. You associate coordinators with reviewers in menu path CUP > Configuration > User Review > Coordinators. You have to click Search before you reach the maintenance screen (Figure 6). You enter this data either manually or by downloading the template, maintain the data in the spreadsheet, and upload it again when completed.

Figure 6

Associating coordinators with reviewers

Frank Rambo, PhD

Frank Rambo, PhD, is managing a team within SAP’s Customer Solution Adoption (CSA) organization working with customers in the SAP analytics area with the objective to drive adoption of new, innovative solutions. Prior to this position, he worked eight years for SAP Germany as a senior consultant focusing on SAP security and identity management. Before he joined SAP in 1999, Frank worked as a physicist in an international research team. He lives in Hamburg, Germany.

You may contact the author at frank.rambo@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.