The User Access Review (UAR) feature enables companies to conduct a streamlined internal control process on a periodic basis that includes collaboration among line managers, internal control, and information security teams. UAR improves visibility of access granted to business systems and improves overall information security. The key features of UAR in SAP BusinessObjects Access Control 5.3 are:

• An automated request- and workflow-based process for review and approval
• A decentralized review of user access conducted by responsible line managers or role owners
• Role usage information facilitates decision taking for the reviewers
• Automatic role de-provisioning, if desired by the user
• Status and history reports to assist in monitoring the review progress
• Audit trail and reports for supporting internal and external audits
• Support for back-end systems integrated with SAP BusinessObjects Access Control through Real Time Agents (RTA) as well as legacy systems

Roles and Detailed Process Flow

The UAR process includes the following roles:

• Administrator: This user has the AE_Admin UME role assigned for CUP. He or she can perform all CUP administrator tasks in addition to UAR-specific administrator tasks that I’ll explain later.
• Reviewer: This term refers to the approver in the first stage of the UAR workflow. Per configuration, the reviewer may be either the user’s manager or the owners of the assigned roles. Approvers of later stages (e.g., security team members) are simply referred to by the more general term approvers.
• Manager: The direct line manager of a user as defined in the User Details Data Source
• Role Owner: The role owner specified in the role master data in CUP
• Coordinator: The coordinator, defined in CUP master data, is assigned one or multiple reviewers. He or she monitors the UAR process and coordinates activities with reviewers to ensure the process is completed in a timely manner.

The high-level process for UAR is as follows (Figure 1).

1. Initialization: The administrator performs a number of actions in the SAP BusinessObjects Access Control system to initiate the UAR process and trigger request generation
2. Administrator review (optional): The administrator reviews requests and checks correct assignment of reviewers before the actual workflow tasks are sent to the reviewers
3. Generation of workflow tasks: The administrator schedules a background job, which generates the workflow tasks for the reviewers
4. Review stage: Requests are reviewed and actions are noted by the reviewers
5. Additional workflow stages (optional): You can add approval stages (e.g., a security stage) to the workflow path by configuration
6. Automatic de-provisioning: If the user desires, SAP BusinessObjects Access Control can automatically de-provision roles marked for removal by the reviewers from the back-end system
7. Management of rejected users: If the reviewers are the users’ direct managers, then they can reject users for whom they’re not responsible during the review. The administrator has to follow up rejected users and regenerate requests to be sent to corrected managers.
8. Reporting and audit trails: A status report, history report, and a detailed audit trail complete UAR

Figure 1

High-level view of the UAR process

I’ll discuss each of these in more detail in the following subsections.

Initialization

The initialization process step contains the following tasks that the administrator executes (Figure 2):

Figure 2

Details of initialization process step

• Verify master data
• Prepare role usage information
• Schedule the task UAR review load data as background job in CUP

You also need to verify the following master data conditions:

• If managers are configured to be reviewers: Managers and manager-user relations are both stored in the user details data source. If this data isn’t up to date, the system sends requests to the wrong managers.
• You need to import roles that will be included on the UAR requests into CUP so role descriptions are available in requests and CUP can support drilling down to the actions included in the roles. You can import roles from a back-end system supported by an RTA or from a spreadsheet file. For more details refer to the standard documentation.
• If role owners are configured to be reviewers: The role master data in CUP also contains a Role Approver tab, which lists the role owners. Make sure that this information is up to date. Otherwise, the system sends requests to the wrong role owners.

The requests sent to reviewers also contain information on how often transactions from a particular role assigned to the user were actually executed in the back-end system during the chosen review period of typically the last six or 12 months. The preparation of the role usage information requires several tasks executed in multiple product capabilities of SAP BusinessObjects Access Control:

• Alert generation job: Schedule the alert generation job in RAR > Configuration > Background Job with all options selected
• Purge usage information: If more transaction usage information is stored in RAR than is desired for UAR requests, then you should archive the data. For example, if your UAR process states that the prior 12 months’ usage information should be provided in UAR requests and RAR has 15 months available, then you should purge the oldest three months’ information in RAR via menu path Configuration > Utilities > Purge Action Usage. It is important to note that usage information purged in RAR is still accessible to RAR from the flat file that is produced but is not accessible by ERM or CUP.
• Retrieve role usage information: For back-end systems with RTA, follow menu path ERM > Configuration > Background Jobs to schedule the task Role Usage Synchronization or upload Role Usage Information via flat file for legacy systems without RTA. For details about the upload procedure and required file formats, refer to the standard documentation.

To complete the initialization process step, the administrator schedules the task UAR Review Load Data as a background job in CUP. This creates the requests, but does not yet create the workflow tasks nor the notification emails that are sent to reviewers. The system does not create requests for users that are locked in the back-end systems. Consider unlocking locked users before you start the UAR process, if you want to include them.

Administrator Review

The administrator review is an optional process step that, if you choose to take it, you need to activate during configuration of the UAR scenario. Its purpose is to have the administrator checking the completeness and accuracy of the generated requests with respect to the reviewers prior to generation of workflow tasks and notification emails. You can start the administrator review by following menu path CUP > Configuration > User Review > Request Review. The system displays to the administrator the list of all requests generated for the current UAR cycle. He can take action on each request in one of the following ways (Figure 3):

Figure 3

Details of the administrator review process step

• Manually assign reviewers to requests having no reviewer assigned due to missing manager data in the user details source or role approvers in CUP’s role master data. You can do this by selecting the request and clicking the change button on the bottom of the Request Review page to produce the screen shown in Figure 4. This assignment won’t update the user details source or the role master data, but only apply for the given request.
• Cancel requests and mark them for user rejection (Figure 5). You can apply this option to requests with missing reviewers in the case where the administrator would like to permanently update the manager or role approver information in the user details source or role master data, respectively. The administrator can regenerate requests for these users later in the Management of Rejected Users process step. Completely cancel requests. They will be excluded from the current UAR cycle until a new UAR cycle is initiated via execution of the UAR Review Load Data job.

Figure 4

Manually assign reviewers to requests without reviewers

Figure 5

Administrator Review – Cancellation of requests

Generation of Workflow Tasks

The administrator schedules the task UAR Review Update Workflow as a background job in CUP. The system sends email notifications to reviewers with the next execution of the periodic Email Dispatcher job in CUP.

Review Stage

The requests are first sent to the reviewers. You can provide detailed instructions for reviewers to supplement the content of the notification emails. The level of instruction for approval of periodic access reviews might be more extensive because it is an infrequent process and may involve reviewers who do not perform routine approval of requests to create or change accounts. The Instructions area of the UAR requests is an HTML viewer. An example of a UAR request with an HTML page provided in the request is shown in Figure 6.

Figure 6

Instructions for reviewers

During configuration you can select whether reviewers are the managers of the users or role owners. Managers have the additional option to reject users for whom they don’t feel responsible (Figure 7). They can mark the users in the User pane for rejection, select from one of the preconfigured rejection reasons, and provide a comment as shown in Figure 8. These users then enter the Management of Rejected Users process step.

Figure 7

Details of the Review stage process step

Figure 8

Managers rejecting users who aren’t reporting to them anymore

All reviewers can find multiple line items per request (Figure 9) in the User Access tab of each request (Figure 6). The number of line items per request is configurable. Each line item represents a role assigned to a particular user in a particular system and can be marked for approval or removal by the reviewer. The role name is displayed as a hyperlink that you can use to view the details of the role. Next to the role name is a role usage counter. It tells the reviewer how often transactions from the role were executed by the user during the review period. This information facilitates decision making for the reviewer considerably. The line items in a request can belong to multiple users and multiple systems. A reviewer can receive multiple requests including all user-to-role assignments within the responsibility of the reviewer.

Figure 9

Approval and removal of roles from users supported by role usage information

The reviewer may choose to save the request multiple times to ensure work is saved in the request. The request is not forwarded to the next workflow stage until the reviewer completes all line items of the request and clicks the Submit button.

Additional Workflow Stages

Users can add additional workflow stages to the UAR workflow. It is better to add a security stage prior to de-provisioning. This ensures that security experts check the actions taken by the reviewers an additional time to detect undesired side effects before removing the roles marked for removal.

However, there are more options for additional workflow stages available. You can derive approvers using a Custom Approver Determinator (CAD). The attributes available in the UAR CAD differ from those available in CUP’s standard CADs. The following attributes are available:

• Application
• Request type
• UAR review role (roles being reviewed)
• Priority

For more details on the use of CADs, refer to the Configuration Guide.

You can configure each stage to display in requests only roles previously marked for removal to focus the attention of the additional approvers on these roles only. Another configuration option is to allow or disallow changes to the request content. If changes aren’t allowed for a stage, then the buttons Approve and Propose Removal aren’t available to the approvers in this stage. If changes to the request content aren’t allowed, approvers can only suggest changes to the request content per comment and forward the request to the reviewer in the previous stage (Figure 10). The reviewer would then take the decision, change the request content accordingly, and resubmit the request. If the stage configuration allows for changes, approvers can turn approvals into the removals and vice versa before they submit the request.

Figure 10

Details of additional workflow stages process step

Automatic De-provisioning

You can define whether roles approved for removal are de-provisioned from the user manually or automatically. The configuration setting for auto-provisioning is a global setting for all request types that you can configure for each system connected via RTA to CUP individually. See the SAP BusinessObjects Access Control 5.3 Configuration Guide for more instructions on configuring auto-provisioning.

If you opt for manual de-provisioning, then a security stage is mandatory. Security receives the requests and manually removes the roles as indicated in the target systems before it submits the request to close it.

Management of Rejected Users

Administrators and managers can reject users during the administrator review and the review stage process steps. Users typically are rejected because the user-to-manager relation isn’t up to date or not maintained at all in the user details data source. Administrators can correct the manager data in there and regenerate requests for the rejected users (Figure 11). Administrators can search for rejected users in Configuration > User Review > Manage Rejections. The system then displays the resulting list of rejected users, including the original request number and the reason for the rejection, in the lower section of the screen (Figure 12).

Figure 11

Details of management of rejected users process step

Figure 12

Manage rejected users screen

The status column contains the current status of each user. The following statuses are possible:

• New: These are requests submitted by the reviewer
• To Generate: The user is marked for regeneration, but the generation background job has not started. You can click Cancel Generation to cancel the request generation.
• In Process: The background generation job has started but has completed. Requests with this status cannot be cancelled, because the background job has started.
• Error: The generation background job has encountered an error
• Completed: The generation background job has completed. The new request number is updated in the New Request column.

The administrator selects the users for whom he wants to generate new requests and clicks the Generate Requests button (Figure 12). This only marks the users. For the actual request generation the administrator has to schedule the task UAR Review Process Rejected as background job in CUP. The new requests then re-enter the administrator review process step before the corresponding workflow tasks are generated and sent to the correct managers for review.

Reporting and Audit Trails

The following UAR-specific reporting features are available:

• UAR status report
• UAR history report
• UAR audit trail

The user review status report allows for monitoring UAR requests to ensure that the process is completed in a timely manner. This report is useful to coordinators or other persons overseeing the review process. You can reach it by following menu path Informer > Analysis View > Analytical Reports > User Review Status Report (Figure 13). You can see the current stage, the number of items completed in the request, reviewer, and other helpful information. You can use the hyperlinks to display the details of the respective object.

Figure 13

Example of a UAR status report

The UAR history report shows the approval decisions taken for each item in UAR requests. This report is helpful after a portion of the review process or the entire review process is complete. It displays actions indicated by the approvers for each line item representing a user-role assignment in a specific system (Figure 14). These actions can be set to Approved, Removal, or Rejection — the latter refers to rejected users.

Figure 14

Example of a UAR history report

You can view the UAR audit trail of a particular request to see the detailed activity during the lifetime of the request. Navigate to My Work > Request Audit Trail and enter your selection criteria for the request for which you are searching. The audit trail shows the history of the report from request creation to closure (Figure 15). You can print or download it and send it to internal or external auditors.

Figure 15

Example of a UAR audit trail

Overview of Configuration of the UAR Scenario

The UAR scenario uses the RAR, ERM, and CUP capabilities of SAP BusinessObjects Access Control. On a high level, you can think of its configuration in 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 relations

I’ll explain each of these tasks in the following subsections.

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 each product capability before users can start customizing their specific use cases. The post-installation is performed right after installation of the SAP BusinessObjects Access Control software on an SAP NetWeaver Application Server Java 7.0 and the required RTAs on the back-end systems. For all details of the post-installation steps, refer to the SAP BusinessObjects Access Control 5.3 Configuration Guide and my articles mentioned at the beginning 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 the following prerequisites are met from a post-installation perspective:

• Initial data file for UAR uploaded: You need to upload the AE_init_append_data_ForSODUARReview.xml file in 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 UAR_REVIEW and a priority UAR_HIGH, which you can verify by following menu path CUP > Configuration > Request Configuration.
• Workflow type UAR_REVIEW: The initial data file also adds the workflow type UAR_REVIEW to CUP > Configuration > Miscellaneous. Ensure it is activated and 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 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, verify that the attribute containing the manager of a given user is correctly mapped in CUP > Configuration > Field Mapping > LDAP Mapping.
• Role data in CUP: Verify that the administrator has imported into CUP all roles to be approved or removed during the UAR so that role descriptions are available in UAR requests and to support drilling down to the actions included in the roles. You may import roles from a back-end system supported by an RTA or from a spreadsheet file. Ensure that each role is assigned a role owner, if role owners act as reviewers or approvers in an additional workflow stage during your UAR.
• Security lead: If you plan to involve your security team in the UAR workflow, maintain your security lead information by following menu path CUP > Configuration > Approvers > Security Lead
• SMTP server: Sending notifications and reminders per email to users, reviewers, and approvers requires the configuration of a SMTP server. Follow 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. Otherwise, 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 type. Follow Configuration > Number Ranges to maintain number ranges.
• Connectors: Make sure that connectors (that all have the same name) have been created in CUP, RAR, and ERM for each back-end system in scope for UAR. This is required for generation of role usage information.
• Auto-provisioning: If you want to de-provision roles automatically from the back-end systems that were marked for removal by the approvers, then you need to configure auto-provisioning. You can do this by following menu path CUP > Configuration > Workflow > Auto Provisioning choosing either globally in the Global tab or per system in the By System tab, if you want to activate auto-provisioning only for a subset of your systems.
• UME security: With Support Package 6, you can assign to administrators and reviewers new UME actions for rejecting and managing the rejected users as well as for accessing the UAR reports. These actions are provided in the initial data files.

Configuration of User Review Options

Follow menu path CUP > Configuration > User Review > Options and specify important options for your UAR scenario (Figure 16). The options to set are:

Figure 16

User review options

• Admin. review required before sending tasks to reviewers: The preferred setting for this 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 source, then you must enable the administrator review in order to generate requests.
• Who are the reviewers?: You can specify if the Manager or Role Owner should be the reviewer
• Number of Line Items per Request: Enter the appropriate number. If CUP needs to include more line items into the request, then it creates additional requests and sends them to the same reviewer.
• Default Request Type: The only request type available is User Access Review. It has been uploaded with the initial data file.
• Default Priority: The only priority available here is UAR high
• Enter URL for UAR review instructions: If an HTML page with detailed instructions for reviewers (such as the page shown in Figure 6) was created to supplement any instruction in the email notification, enter the URL of that page. You can save the page to a local directory of your choice on your internal server.

Workflow

A workflow in CUP always consists of an initiator, one or multiple stages, and a path linking the sequence of stages together. This allows for a very flexible configuration of UAR workflows 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 the reviewer marks line items in a request for removal, then the request is sent to a security stage
• If all line items of a given request are approved, then the request is closed without being sent to the security stage
• The security administrator sees all line items of the request, not only those marked for removal
• The security administrator has permission to change the request content in terms of approvals and removals
• After the security administrator requests submission, de-provisioning of marked roles happens automatically

To implement this workflow, you have to define the following characteristics:

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

Follow menu path CUP > Configuration > Workflow > Initiator to define an initiator. Make sure that you select User Access Review as the workflow type first. You’ll need to select this workflow type for all other workflow elements such as stages, paths, and detours. For this example, it is sufficient to add the attribute Request Type with value User Access Review to the initiator. However, for the workflow type User Access Review, you also have the attributes Application and UAR Review Role available to build more complex Boolean conditions to support multiple workflow paths in parallel for your UAR scenario.

Follow menu path CUP > Configuration > Workflow > Stage to define the review stage. Select Reviewer as the approver determinator. You can define a request wait time and an escalation configuration, which defines which type of escalation action should be taken if the UAR 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: The users on the request are only locked and the request is forwarded to the next stage

Then, configure the notification options similar as for any other stage in CUP. In the additional Configuration pane, you can configure a number of parameters (Figure 17). Some of them are of specific interest for the UAR workflow:

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

Figure 17

Additional Configuration section during definition of the review stage

You can define the security stage in the same way as the review stage. Select Security as the approver determinator. Then apply the same Additional Configuration settings as for the review stage with the exception of Reject Users to be set to No (Figure 17).

Follow CUP > Configuration > Workflow > Path to define the primary path, including the review stage (Figure 18). Select the initiator and the review stage previously created and check the Active check box.

Figure 18

Create the primary path for the UAR workflow containing the review stage

Because I only want those requests to be sent through the workflow to the security stage that contains line items for removal, 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, I need to create a second path that has no initiator included, but the detour flag checked and the security stage selected as the single stage. Then, follow menu path CUP > Configuration > Workflow > Detour/Fork and make the selections shown in Figure 19.

Figure 19

Detour definition

Rejection Reasons

Managers acting as reviewers in the review stage need to select a reason from a drop-down list when rejecting users. These reasons have to be uploaded in the menu path CUP > Configuration > User Review > Reason for Rejection. You can download the required spreadsheet template from there, fill it with data, and then upload it again (Figure 20).

Figure 20

Uploading reasons for rejection

Coordinators

You identify a coordinator for each reviewer, regardless of whether the reviewer is a user’s manager or a role 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 get a UAR request generated. 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 21). You enter this data either manually or download the template, maintain the data in the spreadsheet, and upload it again when completed.

Figure 21

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.