An essential step before implementing compliant user provisioning (CUP) in SAP BusinessObjects Access Control is understanding if your authorization concept is compliant and sufficiently mature for getting the most out of CUP’s features. CUP was designed to involve business users during the change management of roles or users and during the periodic reaffirmation of privileges. It was intended to improve awareness of business process ownership (BPO) during user change management. To achieve this goal, follow these 10 tips, which are a mix of business oriented and technically oriented instructions.

Tip 1: Use a Composite Role Approach

A composite role approach provides you with the opportunity to define a small number of roles over the total single roles defined, in order to better maintain the governance. With a small number of composite role templates, the business can avoid deciphering a long list of job role names. With a composite role approach you can produce clear business-oriented documentation. Furthermore, the business itself knows if a job role is named Buyer instead of Create a Purchase Order type ZC on plant IT10. Single roles and derived roles are used to achieve the goal to define a small number of composite roles related to the company size. By using a single role you can define the list of all single roles’ elementary activities; by using derived roles you can constrain these activities on certain data (e.g., create a material master data only on company IT10). Create material master data represents the activity: the SAP transaction. IT10 represents the domain data where this role can write or read).

Tip 2: Involve All Departments to Define Your Job Role Authorization Concept

When you define and design all job roles with the involvement of the business process owner, the IT department, and the security team, you ensure that your authorization concept is shared, that all departments accept it, and that all departments are aware of what the job role contains. Involving the HR department is also a good approach because it can help define all the company’s job roles.

Designing job roles without involvement of these three departments can be a risk during CUP maintenance (Figure 1). For example, if the IT department designs a job role alone without staying in touch with the BPO, the role may not be aligned to the business need and thus would be difficult to manage.

Figure 1

Departments involved working together

Tip 3: Define the CUP Role Attribute

CUP fills some gaps of the profile generator (transaction PFCG). When you use this classical transaction, it is not possible to insert a specific field to add an attribute (e.g., functional area, business process, or subprocess) when defining the role, you can only insert a description. (Description fields in transaction PFCG are not designed for defining structured information.) Role attribute features in CUP can enhance the documentation of all roles available and loaded into this capability. You can find role attribute features on the Configuration tab and then selecting Roles > Attributes on the left (Figure 2). This brings up the options on the right. You can also find the CUP role details on the Configuration tab and by following Roles > Create Role on the left and selecting the appropriate options on the right (Figure 3).

Figure 2

The CUP Role Attribute page

Figure 3

The CUP Role Details page

Before creating or importing roles in CUP, you need to load these roles from a back end — SAP ERP Central Component (SAP ECC) or enterprise role management (ERM) in SAP BusinessObjects Access Control, for example. After you define a role attribute in CUP, you can load or create the roles from the back end with a spreadsheet that links all roles and attributes previously defined in CUP.

Keep in mind that CUP uses only the roles that you decide to insert or load into CUP. Some important attributes are:

• Detailed role description: It is essential to involve and clearly define the BPO at each job role that you load into CUP (Table 1). When you load a job role, the technical name cannot easily be understood by the business, so it is important to load a complete, detailed description in order to clarify what the job role can do.
• Role approver: An essential attribute if you decide to use the role approver feature during your approval workflow
• System: Defines the system where the role is defined
• Business process
• Business subprocess

Table 1

The CUP role attribute helps a business to better understand the role’s content and purpose

Tip 4: Design Your Job Role Free of SoD Conflicts

SAP best practices suggest that you define all your roles free of segregation of duties (SoD) conflicts. If you have some roles with embedded risks, they are still present when the roles are assigned at the user level. If you ensure that all roles are free of SoD conflicts, you can focus only on risks present at the user level — for example, risks could be present owing to the sum of more than one role to the same user ID. Defining roles free of SoD conflicts ensures that the only conflicts with roles that can arise are during the user maintenance (e.g., a user with several job roles), but it is the first step toward reaching a conflict-free solution. With CUP you can easily intercept and manage all risks generated during user maintenance according to your SoD rules. CUP can be useful to check SoD compliance in real time, but setting up the risk analysis is mandatory in your workflow stage. Approvers must be able to allow (by creating a mitigation control) or reject this job role request.

Tip 5: Plan Your CUP Deployment Step by Step

One way to introduce and deploy CUP in your company is to use a wave-based approach (i.e., starting with a subset of processes or users involved). You can adopt a process-oriented deployment (e.g., finance, procurement, or sales area) or a department approach. Another possible way to deploy CUP is to start using CUP with a subset of all users and departments involved and then, if all workflow and processes defined work well, expand it across your company. The wave-based approach is recommended to ensure business continuity. The step-by-step approach also allows for feedback so that you can enhance and improve the workflow if necessary.

Tip 6: Define Rule Sets for CUP

Rule sets defined in the RAR component of SAP BusinessObjects Access Control represent all rules used by RAR to detect if an object (e.g., user, role, or profile) has a risk. There are three different types of risk:

• SoD risk: When two (to the maximum number of five in SAP BusinessObjects Access Control) functions are in conflict (e.g., maintain a sales order and at the same time maintain sales price conditions)
• Critical action: When an action is considered critical (e.g., delete an SAP client or perform a mass update)
• Critical permission: When an authorization object itself can allow a critical functionality into a production system to represent a risk issue. An example is that the S_DEVELOP object is usually used only in a development system by developers.

RAR provides you the opportunity to define several rule sets. For example, you can define a rule set to stay in compliance with your national laws and define another rule set to stay in compliance with your internal policy.

In all these cases, remember that CUP can only use the default rule set defined in RAR (this is true in SAP BusinessObjects Access Control 5.3, but not in SAP BusinessObjects Access Control 10.0). You can set the default rule set into RAR on Configuration tab and by following Risk Analysis > Default Values on the left (Figure 4). Then set the drop-down box for the Default rule set for Risk Analysis option to Global. 

Figure 4

Default rule set in RAR

Tip 7: Define and Assign Mitigation Controls in RAR and CUP

You can define mitigation controls in RAR only, but you can assign mitigation controls to users during the request for approval in CUP. However, there are different ways to manage the mitigation: at risk ID level, action rule, and permission rule (see SAP Note 1542565) against roles, users, or profiles. 

During user change management, CUP can get all the previously defined mitigated controls into RAR, to not show risks previously mitigated. Otherwise you can create a new mitigated control during a CUP request. Furthermore, you can define a CUP workflow with an approval step performed by an SoD Approver. This user (SoD Approver) is allowed to define a new mitigation control if necessary. With CUP, you can define a workflow where the SoD Approver is dynamically determined based on the CUP request attribute. The SoD Approver could be useful when a risk arises and it is necessary to make a decision to resolve this conflict. The available choices are to remove the requested access (or reject the request) or set up a mitigation control. This SoD Approver should have the necessary knowledge (from a point of view of process and department involved) to create a mitigation control or reject the request. 

Tip 8: Review and Customize the CUP Request Form

Each activity in CUP starts with a request formed by one or more actions. For example, two actions form a standard Create User request: CREATE_USER and ASSIGN_ROLES. Figure 5 shows where in CUP you configure the request, by going to the Configuration tab and on the left selecting Request Configuration > Request Type.

Figure 5

Default request type in CUP

Actions embedded into a request type are shown in Figure 6. In this example, two actions — CREATE_USER and ASSIGN_ROLES — are embedded into the standard request type NEW_HIRE. You cannot create a new action, but you can change the action content in a request type.

Figure 6

Action in a request

CUP provides a standard request form that does not always fit with user requirements. However, you can customize the form to add a custom request or remove some fields that are not necessary. Figure 7 shows the Request Form Customization page, which you can reach by going to the Configuration tab and selecting End User Personalization on the left.

Figure 7

Request Form Customization page in CUP

Tip 9: Define a CUP Object’s Naming Convention

CUP does not have a standard naming convention for all define CUP workflow objects. During the definition of a CUP object, you can insert text into the definition box as follows:

• Initiator length of 40 characters for ID field
• Stage length of 15 characters for ID field
• Path length of 20 characters for ID field

For the three objects in the preceding bulleted list, 28 characters are used for a short description and 100 for a long description. During troubleshooting or an audit trail inquiry, it can be useful to identify all objects used in a specific workflow, knowing at first the object’s ID coding you can quickly find a possible error or workflow lock. Follow a naming convention for each object that composes a workflow. Consider your company’s complexity before defining a naming convention. In some cases with several workflow objects and several international workers, the CUP administrator team needs to define strict rules. Otherwise, in a small landscape you can define a more simple naming convention (Tables 2, 3, and 4).

Table 2

Example of naming for initiator IC01_01 (7 char)

Table 3

Example of stage naming S01_0124 (8 char)

Table 4

Example of path naming P01_02_ IC01_01 (14 char)

Although it is possible to create an easily understood naming convention (e.g., initiator) CREATE_USER is not suggested because it is not a structure and is subjective. If there are several teams (also cross country) that work on CUP configuration and maintenance without using a well-defined naming convention an overlapping may occur.

The approach suggested can seem cryptic at first. If I write P01_02_IC01_01 it is not easily understood what this workflow does. So, deciding on a naming convention is part of a design phase taken before implementing your workflow. However, a common pitfall is start to implementing your workflow without designing it first. During the design phase, I suggest you use a spreadsheet template or a Microsoft Visio diagram.

Tip 10: Assign an Indirect Role Through an Organizational Structure

You can manage roles and users using an organizational structure. Organizational structures belong to SAP ERP HCM. Although not all companies have deployed or use SAP ERP HCM, it is possible to use it to manage roles and users. Each SAP ERP system contains this basic HR component without any particular customization.

CUP can manage fully organizational structure integrations only if SAP ERP HCM is deployed. If you want to exploit these features it is essential to have a unique organizational structure that contains HR data and security data. CUP, with an SAP ERP HCM structure deployed together with a security structure, can assign a role to a position, whereas an HR department assigns or moves a user to positions. CUP triggers and manages these changes (adding or moving users) by HR department. You can configure this CUP behavior with a functionality named HR Trigger in the CUP configuration tab (Figure 8). Otherwise, if CUP is deployed using only a security-oriented structure, you can through CUP only assign a role to a position, but you cannot assign or move a user to a position by using CUP.

Figure 8

HR trigger functionality in CUP