SAP BusinessObjects Access Control delivers a comprehensive set of access controls that identify and prevent access and authorization risks in cross-enterprise systems. I’ll provide an introduction to Enterprise Role Management (ERM) so you’ll understand the main concepts of the application and learn how to use it for role design in your enterprise. I’ll start by explaining the idea of methodology processes and how ERM fits into your system landscape and your role testing approach in your development and quality assurance business systems. I’ll continue with Role Designer, which guides you through ERM customizing prior to productive use of the application. Then I’ll take you through the steps of the default methodology process delivered with the software using the creation of an SAP single role for an SAP ERP back-end system as an example. At the end I will provide an overview of ERM’s reporting capabilities.

Methodology Processes

In ERM, all role design happens within methodology processes. A methodology process is a sequence of steps, which always starts with the role definition step. In the process, you specify role type, target system landscape, role name, role description, and role attributes such as business process and subprocess. The following steps are available:

1. Role definition
2. Define authorization
3. Derive roles
4. Risk analysis
5. Approval
6. Role generation
7. Testing

ERM comes with a pre-defined default methodology process containing all these steps in this exact order. I’ll explain all these steps with an example later. You can define additional methodology processes and use them to design different types of roles. For example, you could define a methodology process for designing roles used for emergency access or super users and leave out the risk analysis step. Or, you could define a methodology process for non-SAP roles and skip the role generation step, which is technically only supported for SAP back-end systems. It is possible to rename these steps so they appear differently in the application, but they always contain one of the above-listed actions. ERM identifies the appropriate methodology process to route a new role after the role definition step where the following role details are specified:

• Role type
• Role name
• System type
• Business process
• Subprocess
• Project/release information
• Functional area
• Custom fields

Each step in a methodology process is protected within the security concept of ERM by a User Management Engine (UME) action, which is part of the SAP NetWeaver Application Server Java 7.0 hosting the application. This means that a methodology process can involve different stakeholders such as role owner, business process owner, IT security, and tester with each step.

System Landscapes

Let’s discuss how ERM fits into your back-end system landscape and role testing approach. In the example shown in Figure 1 I use ERM to design roles for two different SAP back-end system landscapes: SAP ERP and SAP Customer Relationship Management (SAP CRM). Each one consists of a development, quality assurance, and productive instance used for unit testing, integration testing, and productive use of roles, respectively. Before roles are available for testing in your back-end instances, they are designed in ERM via a methodology process.

Figure 1

The two SAP landscapes ERP and CRM consist of development, quality assurance, and productive instances

The system landscapes ERP and CRM are defined in ERM as well. In addition, you need to create system connectors to the back-end systems you want to use for role generation and risk analysis. In most cases, ERM generates roles in the development instances of your back-end system landscapes. In this example, ERM generates roles in the systems ERD and CRD. Here, roles are unit-tested before they are transported to the quality assurance instances ERQ and CRQ, respectively, to perform integration tests. Finally, the tested roles are transported to production and become available to your end users.

Risk analysis is a different story. Technically, ERM calls the risk analysis service in Risk Analysis and Remediation (RAR). RAR executes the risk analysis based on the risks defined in there and reports the results back to ERM. In RAR, the risks are in most cases defined for productive systems (e.g., ERP and CRP). For that reason, you need to create system connectors in ERM to ERD and CRD for role generation and to ERP and CRP for risk analysis. You then assign them to the system landscapes ERP and CRM, respectively. Note that ERM does not connect to your productive back-end systems for risk analysis, but uses the respective system connector names only for reference in the service calls to RAR.

ERM Customizing

Before you can start using ERM, you need to customize it. Role Designer guides you through the customizing process in a number of steps (Figure 2). You start the Role Designer in ERM via Role Management > Role Designer.

Figure 2

Role Designer helps you through the ERM customizing

Step 1. Choose role attributes. It is important to choose well-tailored role attributes because they are used to map the appropriate methodology process to a role and identify the role approver via approval criteria. If you are using the Compliant User Provisioning (CUP) capability, then you can synchronize CUP’s role database with ERM. Then the role attributes can also control request approvals in CUP and become visible for end users during role selection in their access request. In CUP customizing, you also need to maintain role attributes. If you are synchronizing your roles in CUP with ERM, role attributes in CUP and ERM must be identical. You can define custom role attributes, but you also need to enter values for the following pre-defined role attributes: business process, subprocess, functional area, and project/release.

Step 2. Define additional methodology processes, if needed. If the pre-defined default methodology process does not suit your needs, you can define additional methodology processes. You can also define when to apply them via condition groups containing a combination of values for role attributes.

Step 3. Set naming conventions. Naming conventions can be either suggested or enforced during role creation. You can define naming conventions per system landscape for single roles, derived roles, composite roles, and profiles. Role attribute IDs are available as variables when defining a naming convention. This means you can concatenate several variables representing role attribute IDs, text strings, and free text. When creating a new role in the role definition step, the selected role attributes replace the variables with their IDs (Figure 3).

Figure 3

A naming convention example

Step 4. Define organizational value mappings, if needed. This may simplify deriving roles in certain instances. If organizational levels come with hierarchical dependencies, then you can map values for subordinate organizational levels to values of a primary organizational level. For example, you can map a number of specific plants to a particular company code. When creating derived roles, the selection of that particular company code then also populates the respective values for the organizational level plant.

Step 5. Define approval criteria. When you create a new role, ERM can automatically assign role approvers to it, if the role attributes of the new role match approval criteria. You can maintain approval criteria in Configuration > Workflow > Approval Criteria. Simply map a combination of role attribute values to approver IDs that have to exist as users in UME.

Step 6. Analyze transaction usage for roles. This report provides information about how often each of your back-end users (assigned to a particular role) executes a particular transaction. The report is useful when defining or modifying roles, because it helps identify which transactions users execute. Note that the transaction usage report is only available and up to date in ERM if the Alert Generation batch job in RAR has run recently. It should be scheduled in RAR to run periodically, such as once per day.

Best Practice Example: Creation of a Single Role in SAP ERP

Now that you know the main concepts of ERM and how to customize it, let’s go through an example. You will see how a new single role is designed and finally generated in an SAP ERP back-end system employing the default methodology process involving multiple different stakeholders (Figure 4). Note that you can also choose the stakeholders in each step differently according to the requirements of your organization.

Figure 4

Role creation according to the default methodology process

Role Definition

In this example, the role owner, Fox Wilson, initiates the creation of the new role in the role definition step (Figure 5). He selects the system landscape, role type, business process, subprocess, project/release, and role status. ERM uses these attribute values and starts building the role name according to the naming convention for single roles in system landscape ERP. Fox then only has to add the free text string (VENDORMASTERMAINT, in my example) and a role description. Fox completes the role definition by adding a detailed description, selecting a functional area and, if defined during customizing, values for custom attributes in the respective tabs in the lower part of the screen. ERM adds the approver upon save if approval criteria matching this role was defined during the customizing.

Figure 5

Role definition

Define Authorization

Calvin Klein, a member of the SAP security team, takes over and defines the authorization data for this role following the instructions he received from Fox. He takes advantage of the functions available in RAR’s rule architect and chooses the function PR01 containing a whole package of transactions for tasks around vendor master maintenance that surely won’t come with risk violations. However, Fox also requested that transaction ME21 be added to the role (Figure 6). You use this transaction to create purchase orders. Creating purchase orders and maintaining vender master data — isn’t that a risky combination?

Figure 6

Authorization definition with transaction ME21 added to the role

Now, Calvin has to maintain org levels and authorization objects for his selection of transactions. He changes to the Objects By Class tab (Figure 7). He could maintain the authorization data in ERM as well, but after so many years in SAP security he prefers doing this directly in the development system using Profile Generator (transaction PFCG). He starts it by clicking the Maintain in PFCG button (1) and logging on to the backend system (2). When he completes authorization maintenance in Profile Generator (3), in ERM he clicks Synchronize Authorization Data (4) and all data is pulled from transaction PFCG into ERM.

Figure 7

Maintenance of authorization objects in Profile Generator in a back-end SAP ERP system (development instance) and synchronization of authorization data in ERM

Derive Roles

In the same way as Profile Generator, ERM also supports role derivation. After the authorization data has been maintained for the master role, Fox can start creating derived roles that represent different flavors of the master role with respect to values for organizational levels such as company code, purchasing organization, and plant (Figure 8). First he specifies the primary organizational level values and the name and description of first derived roles. Then he maintains the values of other organizational levels, saves, and returns to the role derivation screen. All other data, such as transactions and remaining authorization field values, is inherited from the master role to avoid repeated maintenance of the same data.

Figure 8

Derive roles

Risk Analysis

The next step is risk analysis. Unfortunately Fox finds quite a few risk violations in his new role (Figure 9). A closer look tells him that all risks are caused by transaction ME21 (create purchase order), which in combination with any of the transactions for vendor master maintenance can open the door for fraud. He has to ask Calvin to remove this transaction from the role. Otherwise it would not be approved by Mae Wong, the business process owner, who always acts very accurately when it comes to compliance issues.

Figure 9

Risk analysis shows transaction ME21 causes risk violations

ERM also allows for risk mitigation. If you click any of the risks in the Risk ID column, a window opens up and you can assign a mitigation control for the selected risk (Figure 10). However, it is not a good practice to mitigate risks already on role level. Usually risks are mitigated as a last resort on user assignment level, where organizational constraints leave no other option.

Figure 10

Assignment of a mitigation control to a risk detected during risk analysis

Approval

Before the role can be generated in the development system of the SAP ERP system landscape, it needs to be approved by the business process owner (Mae). Fox clicks the Approval button (Figure 11). This immediately turns the role into display-only mode and creates an approval request in Mae’s inbox in CUP.

Figure 11

Create a role approval request in CUP

Mae receives an email notification and logs on to CUP to check the approval request for the new role. Clicking the request number in her inbox in CUP opens the request (Figure 12). All role data is available within the request. The role name is a hyperlink. Clicking it displays the role in ERM with all details such as its content in terms of transactions and authorizations as well as the list of derived roles created so far. However, the most critical role data such as detailed description, functional area, approvers, custom attributes, organizational levels, and the risk violations is available in a number of tabs in the approval request itself. Figure 12 displays the request for two different cases:

• Case 1: Role comes with risk violations because transaction ME21 wasn’t removed from the role before requesting approval. Mae is likely to reject the request.
• Case 2: Role is clean and doesn’t contain any risk violations. Mae will approve the request.

Figure 12

Role data with and without risk violations

Role Generation

After the role is approved, Calvin can trigger role generation in ERM. This creates the derived roles in the back-end system and generates profiles for master and derived roles. The result is displayed in a summary (Figure 13).

Figure 13

ERM connects to the back-end system and generates master and derived roles and displays in ERM this summary

Testing

Now, the role can be unit- and integration-tested in the development and quality assurance systems, respectively. Brian Law, the role tester, can document the testing process in ERM (Figure 14). He provides date and time of test completion, name of the role tester, and all test cases with its result descriptions. This completes the role design process for a single role in the SAP ERP system landscape. Documentation for each step the role has undergone — from its definition to the completion of all test cases — and a complete audit trail are available in your ERM role repository. If a role needs a change, the methodology process is applied again, including risk analysis, role approval, and role generation. ERM comes with a change log and can also access the SAP back-end system’s change log where the role is generated so that a complete trail of all role changes is available as well.

Figure 14

Role testing completes the default methodology process

Reporting Capabilities

ERM comes with a role library and a number of analytical reports. The role library provides statistical data in pie and bar charts on the number of roles created in ERM in total or for a particular system type, system landscape, role approver, or business process and allows for drilling down to list the selected roles (Figure 15).

Figure 15

Role library with drill-down capability

Beside the role library, the following analytical reports are available in ERM:

• Transaction Usage lists the transaction usage by roles and user. You can view the last transaction execution data and the number of times the transaction is executed in a specific time period for SAP systems.
• Master to Derived Role Relationship lists the relationship between master and derived roles including the organizational level at which the derivation is made
• Single to Composite Role Relationship lists the relationship between single and composite roles
• Role by Date of Generation lists the roles by date of generation
• List Transactions in Roles provides a list of transactions in roles
• Compare Transactions in Menu and Authorizations looks at the transactions in the role menu and authorizations to identify any discrepancies
• Count Authorizations in Roles counts the number of authorizations by role
• Count Authorizations for Users counts the authorizations for users for SAP systems
• Compare User Roles compares roles assigned to two users or personnel numbers for SAP systems
• User to Role Relationship lists users and their assigned roles
• Role Relationship to Users and Groups lists the roles assigned to the user or the user group

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.