SAP BusinessObjects Access Control 5.3 can connect to the SAP NetWeaver Portal for automated user provisioning. Requesters can use the Compliant User Provisioning (CUP) product capability to request access to SAP NetWeaver Portal and select group memberships, portal roles, and User Management Engine (UME) roles. During the approval process, you can execute a risk analysis on the level of iViews and UME actions included in the requested roles to ensure Sarbanes-Oxley compliance with respect to the Web applications accessible through SAP NetWeaver Portal.
Key Concept
SAP NetWeaver Portal runs on SAP NetWeaver Application Server Java (SAP NetWeaver AS Java). Its user administration component is called User Management Engine (UME) and does not come with its own repository for user master data. It is connected to user data sources of the following types: Lightweight Direct Access Protocol (LDAP) directories, the SAP NetWeaver AS Java database, or the user management of SAP NetWeaver AS ABAP. The UME also has UME roles containing UME Actions, which represent access privileges to the SAP NetWeaver AS Java system administration or Web Dynpro business applications running on that server. The user interface of the UME is used to manage users, groups, and roles – including the allocation of portal roles to users or groups.
The Compliant User Provisioning (CUP) capability of SAP BusinessObjects Access Control 5.3 provides a workflow engine for requesting and approving access requests. It can execute auto-provisioning to a variety of systems connected to CUP through agents. The Enterprise Portal Real-Time-Agent (EPRTA) can be installed on an SAP NetWeaver Portal to provide connectivity to CUP for provisioning. Through internal service calls, CUP interfaces with the Risk Analysis and Remediation (RAR) capability of SAP BusinessObjects Access Control and allows for the execution of a risk analysis and allocation of mitigation controls to reported risk violations during request approval.
I’ll present an example of requesting and approving access to SAP NetWeaver Portal, including role and group assignments. Then, I’ll discuss the portal-specific part of the required configuration in CUP to set it up. Before you read this article, you should read my first article on EPRTAs, “Optimize Application Integration by Running Risk Analysis and Remediation for SAP NetWeaver Portal.”
Requesting Access for SAP NetWeaver Portal
The example in Figure 1 shows the request form that requesters view when they log on to CUP and choose the Change Account request type. In the Applications section, add one for SAP NetWeaver Portal (EP2 in this example) and provide any missing user information. Then click the Select Role button.

Figure 1
Request access to SAP NetWeaver Portal
This displays the Select Roles/Groups screen (Figure 2). The upper part of the screen provides various selection criteria to search for groups or roles:
- System
- Select the Type of Access: Groups or Roles
- Application Area
- Business Process
- Sub-Process
- Role/Profile/Group Name
- Role/Profile/Group Description
- Functional Area
- Company
For the type of access, select Groups from the drop-down list if you’re requesting a group membership. Otherwise, select Roles.

Figure 2
Select group memberships in the portal within the access request
In the example shown in Figure 2, when you search for groups in SAP NetWeaver Portal that belong to the Internal Control business process, the system returns one result: the Riskmanager group. The search criteria refer to group and role attributes that are maintained with the group and role master data stored in CUP. Select the group and click the Add button to include it in the request. You can continue selecting additional groups or roles for the portal until you submit the request for approval.
It is also possible to automatically include portal roles into the request, taking advantage of the role mapping feature. This feature simplifies requesting access for the portal considerably. For more information, see the sidebar, “Role Mapping.”
Approving Access for the Portal
During request approval in CUP, the approvers can execute a risk analysis that takes the groups and roles already assigned to the user as well as requested groups and roles into account. In the example shown in Figure 3, the risk analysis detects violations of the critical action risk EP03 – UME Critical Actions caused by the super_admin portal role included in the request. Depending on the detailed stage configuration, the approver has the following options to react to the detected risks:
- Risk mitigation: The approver can mitigate the risk if a mitigation control has been defined for the risk in RAR’s control library (Figure 4)
- Simulation: The approver can temporarily remove a role from the request and click the Simulate button to view the effect on the risk analysis
- Role removal: The approver can remove some of the roles from the request permanently and approve the remainder of the request
- Request rejection: The approver can reject the entire request

Figure 3
Approvers conduct a risk analysis during request approval

Figure 4
Assign a mitigation control to mitigate risks found during request approval
Once the request is in the final approval stage of the workflow, the user is automatically created in the portal’s User Management Engine (UME) user source and role assignments and group memberships are provisioned, if CUP’s auto-provisioning settings are configured accordingly.
All actions taken on a given request during its lifetime from submission through the approval stages to auto-provisioning and closure are captured in audit trails that are accessible any time to your auditors or internal control team (Figure 5).

Figure 5
Detailed and complete audit trail available on all requests
Required Configuration in CUP
CUP requires the EPRTA installed on your SAP NetWeaver Portal in the same way as RAR shown in my previous article. Then, in CUP > Configuration > Connectors you need to create a connector for your portal (Figure 6). In it, include the connection data and parameters shown in Table 1. Test the connector by clicking the Test Connection button.

Figure 6
Create a connector for SAP NetWeaver Portal
Name
|
Identical to the system in the RAR connector
|
Short Description
|
20 characters of free text
|
Description
|
Free text
|
Web Services URI
|
https://:/spml/spmlservice
|
User ID
|
Portal user with super_admin role
|
Password
|
Password of above user
|
System Language
|
System language of the portal
|
Connector Category
|
Production, Non-Production, or Other
|
ASSIGN_GROUPS:OC
|
sapgroup
|
ASSIGN_ROLES:OC
|
saprole
|
CHANGE_USER:OC
|
sapuser
|
CREATE_USER:OC
|
sapuser
|
CREATE_USER:password
|
password
|
DELETE_USER:OC
|
sapuser
|
LOCK_USER:OC
|
sapuser
|
LOCK_USER:islocked
|
true
|
RESET_PASSWORD:OC
|
sapuser
|
RESET_PASSWORD:password
|
password
|
ROLESEARCH_URI
|
https://:/
UserRoleSearchForAEService_5_3/
Config1?wsdl&style=document
|
ROLESEARCH_URI_PASSWORD
|
portal user with super_admin role
|
ROLESEARCH_URI_USERNAME
|
Password of above user
|
ROLE_DATA_SOURCE
|
ROLE.UME_ROLE_PERSISTENCE.un:
|
SCHEMA_ID
|
SAPprincipals
|
UNLOCK_USER:OC
|
sapuser
|
UNLOCK_USER:islocked
|
false
|
USER_DATA_SOURCE
|
USER.R3_DATASOURCE.un:
(USER.PRIVATE_DATASOURCE.un:)
(USER. CORP_LDAP.un:)
|
|
Table 1 |
Connection data and parameters for creation of a portal connector in CUP |
Next, maintain the field mapping for user attributes in CUP and UME according to your requirements in CUP > Configuration > Field Mapping > Provisioning. Drop-down lists containing the attribute names in CUP and UME facilitate the field mapping considerably (Figure 7).

Figure 7
In CUP, define field mappings for SAP NetWeaver Portal
Finally, you need to import roles and groups from SAP NetWeaver Portal into CUP and assign role attributes to them that are later available as search criteria to requesters. You do this the same way for portal roles, UME roles, and groups. The quickest way to do it is to first create all role and group attributes in CUP > Configuration > Roles > Attributes and then import the roles and groups from CUP > Configuration > Roles > Import Roles.
Once they are imported, you can search them in CUP > Configuration > Search Role. Delete the roles that were imported but aren’t needed in CUP for access requests. Then click the Export button to export all the remaining roles and groups into a spreadsheet. The spreadsheet also contains empty columns for attributes that only exist in CUP, but not in the portal and therefore still have to be assigned to the roles and groups.
Assign the attributes you have created previously in CUP to your roles and groups. Also assign role approvers to the roles in groups in the spreadsheet. Once you are done, import the spreadsheet in CUP > Configuration > Roles > Import Roles with the Overwrite Existing Roles option checked. As a result of this procedure, you have all the roles and groups relevant for CUP available, including proper attribute and role approver assignments.
Role Mapping
Portal roles that contain iViews pointing to an SAP application often also need an ABAP authorization roles granted to the same user in an SAP back-end system to fully authorize the user for the SAP application. The authorization concept in the SAP back end is more granular than in SAP NetWeaver Portal. Users who require different authorization roles in the back end representing different organizational levels (e.g., company code or plant) often share the same portal role. Such situations establish a 1-to-n relationship between portal roles and the required authorization roles in the back end. Ordinary user administration processes often struggle with these dependencies between authorization roles and portal roles.
CUP provides an easy-to-set-up and automated solution for this. The Role Mapping feature available in CUP > Configuration > Roles allows you to map to a main role a number of dependent roles from different target systems. If a requester selects the main role in his request, CUP adds the mapped dependent roles automatically to the request. The mapped roles can belong to different systems than the role originally selected by the requester. For example, you can map each one of your authorization roles with different organizational levels in your SAP back end to the same portal role. The different authorization roles act as main roles and the portal role as a dependent role mapped to each one of the authorization roles (e.g., n mappings to the same portal role). The requester selects the correct authorization role and CUP automatically adds the respective portal role to the request. For this to work, the user must have the same ID in both the portal and the SAP back-end system.
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.