Vous êtes sur la page 1sur 397

Configuration Guide

SAP GRC Access Control 5.3


Target Audience System administrators Technology consultants

Document Version 3.17 August 2010

SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf Germany T +49/18 05/34 34 34 F +49/18 05/34 34 20 www.sap.com

Copyright 2010 SAP AG, All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Disclaimer Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java Source Code delivered with this product is only to be used

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

by SAPs Support Services and may not be modified or altered in any way.

Documentation in the SAP Service Marketplace You can find this documentation at the following Internet address:

service.sap.com/instguides

Typographic Conventions Type Style Example text Represents Emphasized words or phrases in body text, titles of graphics, and tables. Words or characters that appear on the screen, including field names, screen titles, checkboxes, and radio buttons. Menu names, paths, and options. Cross-references to other documentation. Screen output, including file and directory names and their paths, messages, names of variables and parameters, source code. Names of installation, upgrade, and database tools. Exact user entriesthat is, words or characters that you enter in the system exactly as they appear in the documentation. Quick links (not part of a URL.) Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries. Keys on the keyboard, such as function keys (F2) or the ENTER key.

Icons Icon Meaning Caution Example Note Recommendation Syntax

Example Text

Example text

Example text

<Example text>

EXAMPLE TEXT

Configuration Guide Access Control

Document History
This guide is regularly updated on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3 Make sure you have the latest version of this guide by checking SAP Service Marketplace before starting the installation. The following table provides an overview of the most important changes that were made in the latest versions. Version 1.00 2.00 2.10 2.11 2.12 3.00 Date March 2008 June 2008 September 2008 November 2008 December 2008 September 2009 Changes Ramp-up release of GRC Access Control 5.3. Release to customers of GRC Access Control 5.3. Quality update revision Defining connectors for SAP Enterprise Portal New background for SoD/UAR requests. Feature changes and updates per SP05, SP06, and SP09. Incorporated information from SAP Note # 1282351 and 1292484. 3.10 December 2009 Added prerequisite to the Configuring Risk Analysis Integration with RAR section of the ERM chapter. Added Action Usage File to the Miscellaneous section of the RAR chapter. Added clarification note to the Roles Frequently Asked Questions section of the CUP chapter. Added note to CUP Role Creation and Role Search. Clarified groups are for existing UME and LDAP groups. Per SP10, added Enable Data Mart Job to the RAR chapter, Additional Options section. Access and Identity Management Add description for functionalArea input parameter. CUP Configuration Tasks Added Portal parameter values for ROLE_DATA_SOURCE and USER_DATA_SOURCE. Custom Reports (Data Mart) Corrected prerequisite Single Launchpad to Common Launchpad.

3.15 3.16

December 2009 February 2010

August 2010

Configuration Guide Access Control

Version 3.17

Date August 2010

Changes Defining Adaptive RFC Connectors Options Removed recommendation for using Adaptive RFC for first 21 connectors Manage Deletion Utility Added Delete System and Delete All Rules features to RAR utilities ERM Roles Status Added configuration parameter Synchronize ERM roles to synchronize ERM and CUP ERM Role Mass Maintenance Added configuration parameter Enable role methodology Custom Reports Data Mart Removed requirement to create an additional data source in Visual Admin

August 2010

Getting Started

Table of Contents 1. Getting Started.................................................................................................. 18 2. GRC Access Control Integration .................................................................... 21 Security and Master Data Configuration ........................................................... 21 3. Risk Analysis and Remediation ..................................................................... 23 Risk Analysis Configuration ............................................................................... 24
Default Values ................................................................................................................ 24 Performance Tuning........................................................................................................ 25 Additional Options ........................................................................................................... 26 Mitigating Controls .......................................................................................................... 27

Workflow Integration with Compliant User Provisioning ................................... 27


Workflow Configuration in Risk Analysis and Remediation ............................................... 28 Workflow Configuration in Compliant User Provisioning ................................................... 29

Miscellaneous ..................................................................................................... 34 Management of Internal Controls ...................................................................... 34


MIC Destinations in the MIC System ............................................................................... 35 MIC User Mappings ........................................................................................................ 36 MIC Risk Mappings ......................................................................................................... 37

Defining Connectors for Risk Analysis and Remediation ................................. 37


Configuring JCO Connectors ........................................................................................... 38 Configuring SAP JCO Connectors ................................................................................... 39 Verifying JCO Connectors ............................................................................................... 39 Configuring Connectors for an Oracle, PEOPLESOFT, or JD Edwards System using JDBC .............................................................................................................................. 40 Configuring Connectors for a Legacy system................................................................... 40 Configuring Connectors for a Portal using a Web Service ................................................ 41

Logical Systems ................................................................................................. 42


Creating a Logical System............................................................................................... 43 Loading Rules against a Logical System ......................................................................... 43

Cross Systems ................................................................................................... 44


Creating a Cross System ................................................................................................ 44 Data Extraction ............................................................................................................... 45

Deleting a System .............................................................................................. 48 Deleting All Rules ............................................................................................... 48 Master User Source ........................................................................................... 49

August 2010

Table of Contents

User Mapping ..................................................................................................... 50 Custom User Groups ......................................................................................... 50 Upload Objects ................................................................................................... 51
Uploading Static Text ...................................................................................................... 51 Uploading Authorization Objects ..................................................................................... 52

Rule Upload ........................................................................................................ 52


Uploading a Business Process Text File .......................................................................... 53 Uploading Function Text Files ......................................................................................... 53 Uploading Function Authorization Text Files .................................................................... 54 Uploading a Rule Set Text File ........................................................................................ 54 Uploading Risk Text Files ................................................................................................ 54 Scheduling Rule Generation ............................................................................................ 55

Back-end Synchronization (with Management of Internal Controls) ................ 56


Synchronizing Mitigation ................................................................................................. 56 Synchronizing Rule ......................................................................................................... 56

Background Jobs ............................................................................................... 57


Scheduling a Synchronization Job ................................................................................... 57 Scheduling Batch Risk Analysis ...................................................................................... 58 Excluding Objects from Batch Risk Analysis .................................................................... 58 Scheduling Management Report Generation ................................................................... 60 DataMart Job .................................................................................................................. 60 Scheduling Alert Generation ............................................................................................ 61

Organizational User Mapping ............................................................................ 62


Maintaining User Organizational Information ................................................................... 62

Custom Tabs ...................................................................................................... 63


Adding a Custom Tab ..................................................................................................... 63

SAP Adapter ....................................................................................................... 63 Utilities ................................................................................................................ 63


Export Utility.................................................................................................................... 63 Import Utility .................................................................................................................... 64 Purge Action Usage Utility............................................................................................... 64 Manage Deletion Utilty .................................................................................................... 65

Configuration Change History............................................................................ 66


Procedure ....................................................................................................................... 67

Risk Terminator .................................................................................................. 69


Configuring Risk Terminator Parameters ......................................................................... 70

August 2010

Getting Started

Additional Configuration Options ....................................................................... 71


Administration for RTA Supported Systems ..................................................................... 71 Administration for Non-RTA Supported Systems ............................................................. 71 Analyze and Create Rules ............................................................................................... 77 Add Action to Function .................................................................................................... 77 Scheduling Batch Risk Analysis ...................................................................................... 78

Additional Tabs................................................................................................... 78
Informer Tab ................................................................................................................... 78 Rule Architect Tab........................................................................................................... 79 Mitigation Tab ................................................................................................................. 80 Alert Monitor Tab ............................................................................................................ 80

4. Superuser Privilege Management .................................................................. 81 Initial Configuration in the Back-end ABAP System ......................................... 81
Remote Function Calls .................................................................................................... 81 Defining the Background Job for Log Reports.................................................................. 82 Configuration Parameters................................................................................................ 83 Configuring SAPconnect Administration (SCOT) ............................................................. 87 Configuring Users for E-mails .......................................................................................... 87 Reason Codes ................................................................................................................ 87

Defining Connectors for Superuser Privilege Management ............................. 88


Creating a Connector to View Reports............................................................................. 89 Deleting a Connector ...................................................................................................... 89 Editing a Connector......................................................................................................... 90 Searching for a Connector............................................................................................... 90

Archived Data for Log Reports .......................................................................... 91


Archiving the Log Report ................................................................................................. 92 Automatic Archiving the Log Report ........................................................................... 92

5. Compliant User Provisioning.......................................................................... 93 Prior to Configuration ......................................................................................... 93 Basic Functionality ............................................................................................. 94 Key Concepts ..................................................................................................... 95 Users .................................................................................................................. 96 Administration Tasks .......................................................................................... 97 Preconfiguration Tasks ...................................................................................... 97
Initializing System Data - Initial Logon ............................................................................. 99 Initializing System Data - Required User Management Engine Roles/Permissions ........... 99

August 2010

Table of Contents

Initialization System Data.................................................................................100 Configuration Tasks .........................................................................................101


Integrating with the System Landscape Directory (SLD) ................................................ 101 Defining Connectors for Compliant User Provisioning .................................................... 101 Defining Connectors for SAP ......................................................................................... 102 Defining Connectors for SAP Enterprise Portal .............................................................. 104 Defining Connectors for Oracle Applications, JD Edwards, PeopleSoft, and Others ....... 107 Defining Connectors for LDAP....................................................................................... 108 Defining Connectors for Verification/Training System .................................................... 109 Viewing and Maintaining Available Connectors .............................................................. 110

User Data Source Definition ............................................................................111


Configuring the User Data Source ................................................................................. 112

Field Mapping ...................................................................................................114


Field Mapping for Provisioning ...................................................................................... 114 Field Mapping for SAP Enterprise Portal........................................................................ 115 LDAP Mapping.............................................................................................................. 116

Integrating CUP and RAR ................................................................................118 Request Configuration .....................................................................................119


Request Type Configuration .......................................................................................... 119

Request Priority Configuration .........................................................................123


Creating a Request Priority ........................................................................................... 123 Changing or Deleting a Request Priority ........................................................................ 124

Application Configuration .................................................................................124


Configuring an Application............................................................................................. 125 Changing an Application Configuration .......................................................................... 125

Employee Type Configuration .........................................................................125


Configuring an Employee Type ..................................................................................... 126 Changing an Employee Type ........................................................................................ 126

Number Ranges ............................................................................................... 126


Configuring Number Ranges ......................................................................................... 127 Changing Number Ranges ............................................................................................ 127

Authentication Source for Requestors.............................................................127


Defining Authentication ................................................................................................. 128 Defining Multiple LDAP Authentication .......................................................................... 128

Risk Analysis ....................................................................................................129


Configuring Risk Analysis .............................................................................................. 129

August 2010

Getting Started

Frequently Asked Questions ......................................................................................... 130

Mitigation ..........................................................................................................130
Configuring Mitigation ................................................................................................... 130

End User Personalization ................................................................................131


Frequently Asked Questions ......................................................................................... 139

Technical Support Contact Identification .........................................................140


Defining Contact Information ......................................................................................... 140 Defining Support Screen information ............................................................................. 141

Available Request Attributes............................................................................141


Configuring Attributes.................................................................................................... 141

Custom Fields ..................................................................................................141


Creating Custom Fields ................................................................................................. 142 Changing or Deleting a Custom Field ............................................................................ 143

Service Level ....................................................................................................143


Configuring a Service Level........................................................................................... 143 Changing a Service Level ............................................................................................. 144

Workflow Management ....................................................................................144


About Workflows ........................................................................................................... 144 Workflow Components .................................................................................................. 144 Workflow Creation ......................................................................................................... 146 Sample Workflows ........................................................................................................ 147 Basic Workflows............................................................................................................ 147 Workflow-Specific Configuration Tasks .......................................................................... 150 Initiators ........................................................................................................................ 153 Custom Approver Determinators ................................................................................... 156 Creating a Custom Approver Determinator .................................................................... 157 Stages .......................................................................................................................... 158 Paths ............................................................................................................................ 165 Detour Paths ................................................................................................................. 166 Forked Workflows ......................................................................................................... 168

Email Reminder and Email Notification Setup ................................................170


Setting Up Email Notifications ....................................................................................... 170 Procedure ..................................................................................................................... 170 Setting Up Email Reminders ......................................................................................... 171 Configuring Password Reset Emails .............................................................................. 172 Escape Route ............................................................................................................... 173

10

August 2010

Table of Contents

SMTP Server Identification ..............................................................................175


Configuring the SMTP Server ........................................................................................ 175 Configuring Generic E-mail Sender Account.................................................................. 175

CUA System Setting Configuration .................................................................175


Configuring the CUA System Setting ............................................................................. 176

Provisioning ......................................................................................................181
Configuring Provisioning for SAP UME User Groups, UME Roles, and SAP EP Roles ... 181 Configuring Provisioning for LDAP User Groups to Users .............................................. 183

Auto Provisioning .............................................................................................185


Configuring Global Settings for Auto Provisioning .......................................................... 185 Configuring Auto Provisioning by System ...................................................................... 187

Approvers .........................................................................................................188
Security Leads .............................................................................................................. 189 Point of Contact ............................................................................................................ 189 Application Approvers ................................................................................................... 190 Distribution Group ...................................................................................................... 190 DL Approvers .............................................................................................................. 191

Stale Requests .................................................................................................192 Request Administration ....................................................................................192


Approver Delegation ..................................................................................................... 192 Administration ............................................................................................................... 192 Archive ......................................................................................................................... 192

User Review .....................................................................................................194


Performing User Access Reviews .............................................................................. 195 Performing SoD Reviews ............................................................................................ 210 Options ......................................................................................................................... 229 Creating the SoD and UAR Review Instruction Page ..................................................... 229 Coordinator ................................................................................................................... 229 Request Review ............................................................................................................ 231 Manage Rejections ....................................................................................................... 231 Reason for Rejection ..................................................................................................... 234 UAR Load Data Tasks................................................................................................... 234

Change Log ......................................................................................................237


Change Log Configuration............................................................................................. 237 Search Change Log ...................................................................................................... 237

Roles .................................................................................................................238

August 2010

11

Getting Started

Importing Roles ............................................................................................................. 239 Configuring Role Synchronization Integration with ERM ................................................ 240 Role Import/Export Template Details ............................................................................. 241 Changing Existing Roles with the Export/Import Spreadsheet ........................................ 245 Role Creation ................................................................................................................ 245 Role Search .................................................................................................................. 247 Role Exporting .............................................................................................................. 248 Role Selection ............................................................................................................... 249 Default Roles Configuration........................................................................................... 250 Role Mapping................................................................................................................ 252 Role Attributes .............................................................................................................. 254

Role Reaffirmation ...........................................................................................262


Configuring an Email Reminder for Role Reaffirm.......................................................... 263

Background Jobs .............................................................................................264


Configuring Background Jobs........................................................................................ 265

User Default Management ...............................................................................266


Configuring User Defaults ............................................................................................. 266 Setting User Default Mapping ........................................................................................ 267 Selecting a User Default System ................................................................................... 268 Changing User Defaults ................................................................................................ 268 Deleting User Default Mapping ...................................................................................... 268

Attachments......................................................................................................269 System Log Monitoring ....................................................................................269


Viewing the System Log ................................................................................................ 269 Viewing the Application Log .......................................................................................... 270

HR Trigger ........................................................................................................270
Creating Field Mappings ............................................................................................... 272 Configuring Workflows .................................................................................................. 272 Creating Actions............................................................................................................ 272 Creating Rules .............................................................................................................. 274 Changing a Rule ........................................................................................................... 275 Deleting a Rule ............................................................................................................. 275 Configuring Provisioning ............................................................................................... 275 Schedule HR Trigger Background Jobs ......................................................................... 276 View Process Log ......................................................................................................... 276

Password Self Service .....................................................................................276


Selecting Specific Systems for Password Self Service ................................................... 277

12

August 2010

Table of Contents

Password Self Service for SAP HR and PeopleSoft HR ................................................. 277 Defining Password Self-Service for Challenge Response .............................................. 278 Disabling Verification ..................................................................................................... 279 Disabling Password Self Service ................................................................................... 279 Configuring Separate Password Self Service Page ....................................................... 279 User Registration .......................................................................................................... 280

Miscellaneous Configuration............................................................................280
Language Configuration ................................................................................................ 280 Log Level Configuration ................................................................................................ 281 Cache Job Interval Configuration................................................................................... 281 Configure Workflow Types ............................................................................................ 281 Configure the Background Job Interval .......................................................................... 282

6. Enterprise Role Management .......................................................................283 Configuring Enterprise Role Management ......................................................283 Initial Logon to Enterprise Role Management .................................................283 Initial System Data Importation ........................................................................284
Importing Initial System Data ......................................................................................... 284 Initial Background Job ................................................................................................... 284

Managing Background Jobs ............................................................................285


Creating a Static Background Job ................................................................................. 286 Editing a Background Job ............................................................................................. 286 Deleting a Background Job ........................................................................................... 287 Activating/Deactivating a Background Job ..................................................................... 287 Searching for a Background Job ................................................................................... 287 Viewing the History of a Background Job....................................................................... 287

Configuring Risk Analysis Integration with RAR .............................................288 Configuring Workflow Integration with CUP ....................................................289
Configuring CUP Workflow for Enterprise Role Management......................................... 289 Configuring ERM Web Services for Compliant User Provisioning .................................. 291

System Landscape Definition ..........................................................................292 Defining Connectors for Enterprise Role Management. .................................293
Configuring a Connector for SAP................................................................................... 293 Configuring a Connector for Enterprise, Non-SAP, or SAP EP....................................... 294 Creating the Landscape ................................................................................................ 294

Role Designer ...................................................................................................297


Managing Role Attributes .............................................................................................. 297

August 2010

13

Getting Started

Managing Business Processes...................................................................................... 298

Role Status .......................................................................................................306 Managing Condition Groups ............................................................................307


Creating a Condition Group ........................................................................................... 307 Changing a Condition Group ......................................................................................... 308 Deleting a Condition Group ........................................................................................... 308

Role Creation Methodology Setup...................................................................308 Managing the Workflow ...................................................................................313


Creating Approval Criteria for a Workflow ...................................................................... 313 Changing Approval Criteria for a Workflow .................................................................... 314 Deleting Approval Criteria for a Workflow ...................................................................... 315

Managing Naming Conventions ......................................................................315


Creating a Naming Convention...................................................................................... 315 Changing a Naming Convention .................................................................................... 316 Deleting a Naming Convention ...................................................................................... 317

Managing Organizational Value Mapping .......................................................317


Creating an Organizational Value Mapping .................................................................... 317 Changing an Organizational Value Mapping .................................................................. 318 Deleting an Organizational Value Mapping .................................................................... 319 Importing an Organizational Value Mapping .................................................................. 319 Exporting an Organizational Value Mapping .................................................................. 319

System Logs .....................................................................................................320 Transaction Import ...........................................................................................320


Importing Mass Roles ................................................................................................... 320 Role Usage Synchronization ......................................................................................... 323

Approving Roles During Mass Maintenance ...................................................324 Importing and Exporting Configuration Settings .............................................324
Exporting Configuration Settings ................................................................................... 325 Importing Configuration Settings ................................................................................... 325

Miscellaneous ...................................................................................................326 Mass Role Import .............................................................................................328 Role Usage Synchronization ...........................................................................329
Language Configuration for Enterprise Role Management ............................................. 329

7. Custom Reports (Data Mart) .........................................................................331


Aborted and Errored-out Data Mart Synchronization Jobs ............................................. 332

14

August 2010

Table of Contents

8. Access Control and Identity Manager Integration .....................................333 Calling Web Services .......................................................................................334 Access Control and IdM System Integration Architecture ..............................337
Available Web Services................................................................................................. 338

Technical Definitions for Access Control IdM Web Services..........................341


Select Applications (SAPGRC_AC_IDM_SELECTAPPLICATION) ................................ 341 Search Role (SAPGRC_AC_IDM_SEARCHROLES)..................................................... 342 Role Details (SAPGRC_AC_IDM_ROLEDETAILS)........................................................ 344 Role Details (SAPGRC_AC_IDM_ROLEDETAILS_V1_1) ............................................. 346 Function/Method ........................................................................................................... 346 Input Parameters .......................................................................................................... 346 Output Parameters ........................................................................................................ 346 Request Details (SAPGRC_AC_IDM_REQUESTDETAILS) .......................................... 347 Function/Method ........................................................................................................... 347 Input Parameters .......................................................................................................... 347 Output Parameters ........................................................................................................ 347 Submit Request (to Access Control) (SAPGRC_AC_IDM_SUBMITREQUEST) ............. 349 Risk Analysis (SAPGRC_AC_IDM_RISKANALYSIS) .................................................... 354 Audit Trail (SAPGRC_AC_IDM_AUDITTRAIL) .............................................................. 356 Request Status (SAPGRC_AC_IDM_REQUESTSTATUS) ............................................ 358

Integrating with an Identity Management Solution ..........................................359 Defining Connectors for IdM Systems .............................................................360
Setting the Field Mapping .............................................................................................. 361 Importing Roles ............................................................................................................. 362

Sending Provisioning Request to an IdM System ...........................................363 Provisioning to Other Target Systems with SPML SOAP Compliant Call .....366
Defining a Connector for Target Systems other than IdM ............................................... 367 Setting the Field Mapping .............................................................................................. 368 Importing Roles ............................................................................................................. 368

Integration with SAP NetWeaver Identity Manager ........................................370


Provisioning Operations ................................................................................................ 370

Search Operations ...........................................................................................374


Checking the Result of Update Operation ...................................................................... 374 Returned Entry.............................................................................................................. 374 Obtaining Entry Information ........................................................................................... 376 Detailed Search on Single Person ................................................................................. 376

August 2010

15

Getting Started

9. Appendix A: Rule File Templates .................................................................378 Business Process Template ............................................................................378 Function Template ...........................................................................................378 Function-Business Process Relationship Template .......................................378 Function-Action Relationship Template...........................................................379 Function-Permission Relationship Template ..................................................379 Rule Set Template ...........................................................................................379 Risk Definition Template ..................................................................................380 Risk Description Template ...............................................................................380 Risk to Rule Set Relationship Template ..........................................................381 10. Appendix B: Data Mapping Templates for Non-RTA Systems ............382

User File Template ...........................................................................................382 User Action File Template................................................................................383 User Permission File Template .......................................................................383 Role File Template ...........................................................................................385 Role Action File Template ................................................................................385 Role Permission File Template ........................................................................386 Profile File Template ........................................................................................387 Profile Action File Template .............................................................................387 Profile Permission File Template .....................................................................387 Action Permission Objects Template ..............................................................388 Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File) .............................................................................388
Action Template ............................................................................................................ 389 Permission Template .................................................................................................... 389 Field Template .............................................................................................................. 390 Value Template ............................................................................................................. 391

11.

Appendix C: Configuring RAR for SAP Enterprise Portal ..................392

Creating an iView .............................................................................................392 Creating an iView Role ....................................................................................392 Assigning an iView to a Role ...........................................................................393 Retrieving Master Data ....................................................................................393 Verifying Portal RTA.........................................................................................394 Creating a Function in RAR for iView ..............................................................394

16

August 2010

Table of Contents

Creating a Function in RAR for UME Actions .................................................395

August 2010

17

Getting Started Security and Master Data Configuration

1. Getting Started
SAP Governance, Risk, and Compliance (GRC) Access Control provides end-to-end automation for documenting, detecting, remediating, mitigating, and preventing access and authorization risk enterprise wide, resulting in proper segregation of duties, lower costs, reduced risk, and better business performance. Access Control includes the following capabilities: Risk Analysis and Remediation, which supports real-time compliance to detect, remove, and prevent access and authorization risks by preventing security and control violations before they occur. Compliant User Provisioning, which automates provisioning, tests for segregation of duties (SoD) risks, and streamlines approvals by the appropriate business approvers to unburden IT staff and provide a complete history of user access. Enterprise Role Management, which standardizes and centralizes role creation and maintenance. Superuser Privilege Management, which enables users to perform emergency activities outside their roles as privileged users in a controlled and auditable environment.

Access Control helps companies comply with the Sarbanes-Oxley Act and other regulatory mandates by enabling organizations to rapidly identify and remove authorization risks from IT systems. It also allows preventive controls to be embedded in business processes to identify and prevent SoD violations from being introduced without proper approval and mitigation.

About this Document


This guide describes how to integrate and configure each of the Access Control capabilities. For more information, see the following sections: GRC Access Control Integration Enterprise Role Management Compliant User Provisioning Risk Analysis and Remediation

Superuser Privilege Management You can find the most current information about the implementation of SAP GRC Access Control on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3. We recommend that you use the documents available there, since the guides are regularly updated.

18

August 2010

Getting Started

Related Information
This section describes topics for planning. Links to reference documentation found on SAP Service Marketplace are also provided.

Planning Information
For information about planning topics not covered in this guide, see the following content on SAP Service Marketplace:

Content Latest versions of installation and upgrade guides SAP Business Maps general information about applications, solutions and business scenarios Sizing, calculation of hardware requirements such as CPU, disk and memory resource Released platforms and technology-related topics such as maintenance strategies and language support Network security High Availability Performance Information about Support Package Stacks, latest software versions and patch level requirements Information about Unicode technology

Location on SAP Service Marketplace service.sap.com/instguides service.sap.com/businessmaps

service.sap.com/sizing service.sap.com/platforms To access the Platform Availability Matrix directly, enter service.sap.com/pam. service.sap.com/securityguide service.sap.com/ha service.sap.com/performance service.sap.com/sp-stacks

service.sap.com/unicode@sap

SAP Service Marketplace Links


The following table lists further links on SAP Service Marketplace:

Content Information about creating error messages SAP Notes search SAP Software Distribution Center (software download and ordering of software) SAP Online Knowledge Products (OKPs) role-specific Learning Maps

Location on SAP Service Marketplace service.sap.com/messages service.sap.com/notes service.sap.com/swdc service.sap.com/rkt

August 2010

19

Getting Started

Important SAP Notes


To obtain the latest technical information, read the following SAP Notes before you start installation. These notes also contain updates and correction to the installation documentation. For more information, see the SAP BusinessObjects GRC Access Control 5.3 Master Guide on Service Marketplace at http://service.sap.com/instguides -> SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3.

GRC Access Control Documentation


You can find documentation, including this guide, on SAP Service Marketplace at http://service.sap.com and SAP Help Portal at http://help.sap.com Title Configuration Guide Master Guide Installation Guide Upgrade Guide Security Guide Operations Guide Release Notes Application Help Location http://service.sap.com/instguides http://service.sap.com/instguides http://service.sap.com/instguides http://service.sap.com/instguides http://service.sap.com/securityguide http://service.sap.com/instguides http://service.sap.com/releasenotes http://help.sap.com

20

August 2010

GRC Access Control Integration Security and Master Data Configuration

2. GRC Access Control Integration


To provide a complete end-to-end process for managing user access, the capabilities of Access Control are integrated for risk analysis, mitigation, workflow approval, and role synchronization. Integration is achieved through Web services or Enterprise Java Bean (EJB) services for role risk analysis when Risk Analysis and Remediation is installed on the same server as Compliant User Provisioning. Access authorization is achieved through a centralized Web user account, which has the required administration rights in the User Management Engine (UME). This Web user must have administration rights for the capabilities Compliant User Provisioning (CUP), Risk Analysis and Remediation (RAR), and Enterprise Role Management (ERM). Integration of each of the above capabilities is imperative for the following functionality: Approval workflow in Compliant User Provisioning: In Risk Analysis and Remediation, approval workflow is required for: - Risk maintenance - Mitigating control maintenance - Mitigating control assignment changes to users, roles, or profiles In Enterprise Role Management, approval workflow is required for: - Role maintenance Risk analysis and mitigation in Risk Analysis and Remediation: In Compliant User Provisioning, risk analysis and mitigation is required for: - Provisioning risk analysis and mitigation - Risk analysis results for SOD Review In Enterprise Role Management, risk analysis and mitigation is required for: Role risk analysis

- Function selection for authorization data Role data synchronization in Enterprise Role Management: In Compliant User Provisioning, role data synchronization is required for: Roles for provisioning Role definition, assignment and usage information for User Access Review requests.

For more information about integration, see the sections for each capability.

Security and Master Data Configuration


When integrating Access Control capabilities, you should plan security and master data proactively to ensure consistent data across the application. Some master data normalization is necessary for the functionality to be effectively integrated. In the section below, this data type is marked as Required. All other data types are best practice recommendations to ensure seamless integration.

Security and System Data:


Connectors - Create the same connector Name, User ID, and Password for each system in all capabilities. - Use the same connector User ID and Password for Web user creation.

August 2010

21

GRC Access Control Integration Security and Master Data Configuration

If CUP is connected to one or more CU systems, the connector name must match the back-end SAP system logical name. Web User This user facilitates communication between the capabilities via Web services. It has to be configured in each capability. - Use the same User ID and Password information from the connector. - Create a common Web user in the User Management Engine for all capabilities. This user is used for all Web service configurations across the capabilities (Required).

This is not the user ID configured in the back-end system connectors; this user ID is configured with the individual Web services for each capability. For information about the authorizations required for your Web user, see the SAP GRC Access Control 5.3 Security Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3. Remote Function Call (RFC) User This user communicates between front-end Java applications and SAP target systems. 1. Create the RFC user with User Type Communications Data in the target system(s) and assign administration authorizations for all applications. 2. Assign appropriate RFC authorization. For information about the authorizations required for your RFC, see the SAP GRC Access Control 5.3 Security Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3.

Master Data:
You must define the following role attribute master data and assign matching names in Enterprise Role Management and Compliant User Provisioning (Required). Functional Area (Functional Area ID field in ERM must exactly match the Functional Area Name field in CUP) Business Process (Business Process ID field in ERM must exactly match the Business Process Name field in CUP) Subprocess (Subprocess ID field in ERM must exactly match the Subprocess Name field in CUP) Role owner in ERM should be the same as role approver in CUP Other key fields are not used by the applications as key integration fields to synchronize data. To avoid confusion for business users, however, create them with consistent descriptions.

22

August 2010

Risk Analysis and Remediation Security and Master Data Configuration

3. Risk Analysis and Remediation


Risk Analysis and Remediation is a Web-based, automated security audit and segregation of duties (SoD) analysis application. It uses custom tables to store SoD data. You use Risk Analysis and Remediation to identify, analyze, and resolve all SoD and audit issues relating to regulatory compliance. You can perform risk analysis to identify risks associated with a user, role, profile, or human resources (HR) object. For risks that cannot be eliminated, you define mitigating controls. You also define monitors and approvers, assign them to specific controls, and create business units to categorize the controls. This section describes how to configure Risk Analysis and Remediation (a front-end tool), as well as Risk Terminator (a back-end tool). Configuration is required: After a new installation of Risk Analysis and Remediation After an upgrade of Risk Analysis and Remediation To conduct routine administrative tasks

The Configuration tab provides controls, which allow you to define and manage Risk Analysis and Remediation. Since this tab is displayed only for users with administration permissions, the information in this section is not relevant for all users. Note The Configuration tab does not provide settings for Risk Terminator. Configuration impacts the behavior of many Risk Analysis and Remediation functions and features. Therefore, you must work closely with security and user administrators, as well as business process owners to determine the required settings and definitions. You can use Risk Analysis and Remediation configuration to: Specify default settings for users who perform risk analysis with the Informer tab Tune the system to optimize your usage and network environments Determine how data is used in Risk Analysis and Remediation reports Access the functions of the Configuration tab through its navigation menu.

For more information, see the following sections: Risk Analysis Mitigating Controls Workflow Miscellaneous MIC User Mapping MIC Risk Mapping Connectors Logical Systems Cross Systems Master User Source User Mapping

August 2010

23

Risk Analysis and Remediation Risk Analysis Configuration Custom User Groups Upload Objects Rule Upload Backend Synchronization Background Jobs Organizational User Mapping Custom Tabs SAP Adapter Utilities

Risk Analysis Configuration


This section describes the options available under Risk Analysis on the Configuration tabs navigation bar.

Default Values
Parameter / Purpose Default Report Type This option determines the default report type populated when executing a Risk Analysis. Options Default Risk Level This option determines the default risk level populated when executing a Risk Analysis. Default User Type This option determines the default user type included when executing a Risk Analysis. Action Level Permission Level (default) Critical Actions Critical Roles/Profiles Mitigation Controls All (default) Critical High Medium Low All Dialog (default) System Communication Service Reference

24

August 2010

Risk Analysis and Remediation Risk Analysis Configuration

Parameter / Purpose Default Rule Set This option determines the rule set defaulted as selection criteria when executing a Risk Analysis from RAR. The default rule set is used for risk analysis initiated from CUP, ERM and Risk Terminator. This option determines the default rule set for risk analyses and is used by all capabilities. You can modify it for risk analyses performed within RAR. You cannot modify it when the risk analysis is initiated from CUP, ERM or Risk Terminator. Exclude Locked Users This option specifies whether locked users are excluded when executing a Risk Analysis. For information on the lock codes or user flags and how to include or exclude certain values, see SAP Note 1013217. Exclude Expired Users This option specifies whether expired users are excluded when executing a Risk Analysis. Exclude Mitigated Risks This option specifies whether risks with assigned mitigating controls are excluded when executing a Risk Analysis.

Options All defined rule sets are available

Yes (default) No

Yes (default) No Yes (default) No

Performance Tuning
Parameter Batch Size for User Synchronization Purpose This setting specifies the number of users to synchronize at once or in one batch. To improve performance, increase the value. Be aware, however, that increasing the value too much can cause timeouts to occur during synchronization. Number of Web Services Worker Threads This setting specifies the number of server threads to dedicate to Web service calls, such as calls from the Risk Analysis Engine. If you experience risk analysis performance issues, consider increasing this thread allocation. Number of Background Job Worker This setting specifies the number of server threads to Threads dedicate for background jobs. If background job operations slow performance, consider increasing this thread allocation. If you schedule multiple background job processes to run simultaneously, these operations might be delayed until another background job completes.

August 2010

25

Risk Analysis and Remediation Risk Analysis Configuration

Parameter RFC Time-out for Web Services / Background Job Worker Threads

Purpose This setting specifies in minutes the timeout value for remote function calls. The amount of data you process and the number of threads you allocate can affect whether you experience RFC timeouts during Web service or background job operations.

Additional Options
Parameter Ignore Critical Roles and Profiles Purpose This setting determines whether roles and profiles maintained in the Critical Roles and Profiles tables are ignored when user risk analysis is performed. The default is No. Show Composite Role in User Analysis Use SoD Supplementary Table for Analysis This setting determines whether composite role names are displayed when risk analysis is performed. This setting determines whether the SoD supplementary table is checked when risk analysis is performed. If no supplementary rules are maintained, this parameter must be set to No to avoid incorrect results in Risk Analysis. Include Role/Profile Mitigating Controls in User Analysis This setting determines whether role-based or profile-based mitigating controls are included in user-based Risk Analysis reports. The risk analysis includes user-level mitigating control IDs, if they exist. If not, the report displays either the role-based or profile-based mitigating control ID (in that order). If you set this option to Yes, the mitigation flows to the risks mitigated at the role/profile level (regardless of whether the user has the risk from that role or from additional roles). The default value is No. Enable Offline Risk Analysis This setting allows Risk Analysis to be performed without real-time communication with a back-end system and uses data from the Batch Risk Analysis for reporting. Enabling offline analysis results in faster response times for Risk Analysis reports. Consider Organizational Rules This setting determines whether to consider organizational rules when updating the Management Reports of the Informer tab and during the Risk Analysis Web service call. If no organizational rules are maintained, this parameter must be set to No to avoid incorrect results in the Risk Analysis. The default value is No.

26

August 2010

Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

Parameter Convert Users, Roles and Profiles to Upper Case

Purpose This setting determines whether names of users, roles and profiles are converted to upper case. Recommendation This setting is recommended for SAP systems to facilitate searches.

Include Reference User when doing User Analysis

This setting determines whether access gained through assignment of a reference user to a user ID is included in Risk Analysis for users. Reference users are templates, which give predefined access to individual user IDs. If reference user security is considered in Risk Analysis, the report rows related to access gained from reference user assignment are displayed in a different color than the rows resulting from access gained by direct assignment.

Show all objects in Risk Analysis

This setting determines whether all objects in the selection criteria range are shown in the report, whether or not they have associated risks. For example, user-level Risk Analysis shows User A has risks and User B has no risks. Setting this value to Yes returns Users A and B in the results, whereas setting this value to No returns only User A.

Enable monitor notification

This setting enables email notification to the specified monitor. This occurs when the monitor is assigned to or removed from a mitigation control.

Show Selection Criteria

This setting determines whether to show selection criteria in Risk Analysis reports. The default value is Yes.

Enable Data Mart Job

You use this option to enable data mart reporting. The default is No.

Mitigating Controls
You can specify the default expiration time (in days) for a mitigating control. The validity period starts when the mitigation is assigned to a risk. Every mitigating control needs a validity period. If you do not assign a validity period during risk mitigation, the system assigns a default validity period.

Workflow Integration with Compliant User Provisioning


Risk Analysis and Remediation integrates with Compliant User Provisioning for: Approval of risk updates Approval of mitigation control updates Approval of mitigating control assignments

August 2010

27

Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

Workflow Configuration in Risk Analysis and Remediation


Workflow configuration allows you to specify the conditions under which workflows are triggered. Risk Analysis and Remediation supports Compliant User Provisioning workflows only. The table below lists the workflow parameters and their purpose:

Parameter Risk Maintenance

Purpose If you set this option to Yes, creating a new risk and changing or deleting an existing risk triggers workflow. The default value is No. During risk creation or maintenance, icon nomenclature indicates whether workflow has been enabled: If the Submit option appears, workflow for Risk Maintenance is enabled. The system notifies the risk owner through a workflow task and, on approval, saves the risk changes and generates the rules. No manual rule update is required. If the Save option appears, workflow for Risk Maintenance is disabled. The change is immediate and rules are generated at once.

Mitigation Control Maintenance

If you set this option to Yes, editing a mitigating control triggers workflow. The default value is No. When a mitigating control is created or changed, icon nomenclature indicates whether workflow has been enabled. If the Submit option appears, workflow for Mitigation Control Maintenance is enabled. The system notifies the risk owner through a workflow task and, on approval, saves the risk changes and generates the rules. Until the control is approved, it is not available for assignment. If the Save option appears, workflow for Mitigation Control Maintenance is disabled. The change is immediate, and the control is available for assignment.

Mitigation

If you set this option to Yes, mitigating, changing, or removing risks for users, roles, profiles, or HR objects triggers workflow. The default value is No. When a mitigating control is assigned or changed, icon nomenclature indicates whether workflow has been enabled. If the Submit option appears, workflow for Mitigation is enabled. The system sends the workflow task based on master data in Compliant User Provisioning. The change takes effect on approval. If the Save option appears, workflow for Mitigation is disabled. The change is immediate.

28

August 2010

Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

Parameter Workflow Service URL

Purpose Enter the URL for submitting workflow requests to Compliant User Provisioning.

Workflow Configuration in Compliant User Provisioning


To configure Compliant User Provisioning for approval workflow, you must upload the append files from installation of Risk Analysis and Remediation. Procedure To configure for approval workflow: 1. Upload append file. The append file for Compliant User Provisioning is provided with Risk Analysis and Remediation installation or can be found in SAP Service Marketplace. Copy the file AE_init_append_data_cc.xml. The append file is not build-dependent. Note If the XML files have already been loaded, this step is not needed. Verify they have been loaded by reviewing the Request Type and Priority screen in Compliant User Provisionings Request Configuration. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Initial System Data. c. Enter the file name of the append file and select Append.

d. Click Import. The append file loads the following information for Risk Analysis and Remediation in Compliant User Provisioning: Workflow Types: o o o Mitigating Control (MITICTRL) Mitigation Object (MITIOBJ) Risk (RISK)

You can view these objects in Compliant User Provisioning, by going to Configuration tab > Miscellaneous Request Types: o o o Delete, Create, and Update Mitigating Control Delete, Create, and Update Mitigation Object Delete, Create, and Update Risk MC_HIGH Mitigating Control MO_HIGH Mitigation Object RS_HIGH - Risk

Priorities: o o o

2. Configure request types for Risk Analysis and Compliant User Provisioning integration. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Request Type

August 2010

29

Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning c. Select a request type and click Change. The Create Request Type screen appears.

d. Select Active. e. Click Save. The table below lists the request types that are available: Request Types MITICTRLC MITICTRLD MITICTRLU MITIOBJC MITIOBJD MITIOBJU RISKC RISKD RISKU Description Create Mitigating Control Delete Mitigating Control Update Mitigating Control Create Mitigation Object Delete Mitigation Object Update Mitigation Object Create Risk Delete Risk Update Risk

Note Create Mitigation Object means assigning a mitigating control. Delete Mitigation Object means removing the assignment of a mitigating control. Update Mitigation Object means modifying a mitigating control assignment.

3. Configure request priority. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Priority c. Select a priority and click Change. The Modify Priority screen appears.

d. Enter or modify the priority description as appropriate. e. Click Save. The table below lists the request types that are available: Request Priorities MC_HIGH MO_HIGH RS_HIGH Description High Priority for Mitigating Control High Priority for Mitigation Object (Assignment) High Priority for Risk Changes

4. Configure request attributes. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Attributes. The Attributes screen appears. c. Select Enable for the appropriate request attributes.

d. Click Save. The table below lists the request attributes that are available:

30

August 2010

Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

Request Attribute Name Priority Priority Priority Request Type Request Type Request Type

Workflow Type Mitigation Control Mitigation Object Risk Mitigation Control Mitigation Object Risk

5. Verify custom fields. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Custom Fields. The Available Custom Fields table displays the pre-delivered custom fields with Compliant User Provisioning for workflow integration with Risk Analysis and Remediation. c. Verify that the custom field names are relevant for the workflow integration. The workflow checkboxes are enabled automatically.

Ensure that the workflow indicator is selected for each of these custom fields.

The table below lists the custom fields that are pre-delivered with Compliant User Provisioning for workflow integration with Risk Analysis and Remediation. The integration enables risk analysis and mitigation functions. Custom Field Name RSRISKID BUSPROCID OBJTYPE MOMITREFNO MITREFNO APPROVERID Field Lable Risk ID Business Process ID Object Type Mitigation Control ID Mitigation Control ID Approver ID Workflow Type Risk Risk Mitigation Object Mitigation Object Mitigation Control Mitigation Control

6. Configure workflow initiators. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Workflow > Initiator. For detailed information on how to create an initiator, see the section Initiators. c. Create an initiator for the following workflow types:

Initator Name CC_MITCTLRL_INT

Description For mitigating control changes, configure the initiator CC_MITCTRL_INT. When mitigating controls are created, updated or deleted, a request is sent from Risk Analysis and

August 2010

31

Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning Remediation to Compliant User Provisioning via a Web service to trigger workflow approval of the change. CC_MITOBJ_INT For changes to mitigating control assignments, configure the initiator CC_MITOBJ_INT. When mitigating control assignments are created, updated or deleted, a request is sent from Risk Analysis and Remediation to Compliant User Provisioning via a Web service to trigger workflow approval of the assignment. CC_RISK_INT For changes to risk definitions, configure the initiator CC_RISK_INT. When risks are maintained, a request is sent from Risk Analysis and Remediation to Compliant User Provisioning via a Web service to trigger workflow approval of the change to the risk.

7. Configure custom approver determinators. Custom approver determinators (CADs) determine the path for routing the approval request. You must create a CAD for each Risk Analysis and Remediation workflow type. Compliant User Provisioning does not require a CAD for a workflow within itself, but you must create one for Risk Analysis and Remediation workflow integration. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Workflow > Custom Approver Determinators. c. For Risk Analysis and Remediation workflow integration, create a CAD for mitigating control assignment approval. This CAD is used for users, roles, and profiles mitigation change approver. Use the following parameter values: Name (example) CC_MITOBJ_CAD CAD Type Attribute Workflow Type Mitigation Control Assignment

Select the appropriate attributes for the custom approver determination. You can select additional attributes to differentiate approvers for different processes. For example, you can assign different approvers for each Request Type. d. Create another CAD for Risk Analysis and Remediation. This is for the mitigating control maintenance approver. Name (example) CC_MITCTRL_CAD CAD Type Attribute Workflow Type Mitigation Control

Select the appropriate attributes for the custom approver determination. You can select additional attributes to differentiate approvers for different processes. For example, you can assign different approvers for each Request Type. e. Create another CAD for Risk Analysis and Remediation risk maintenance approver. Name (example) CC_RISK_CAD

32

August 2010

Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning CAD Type Attribute Workflow Type Risk

Select the appropriate attributes for the custom approver determination. You can select additional attributes to differentiate approvers for different processes. For example, you can assign different approvers for each Request Type. f. In the Select Attributes pane, identify the characteristics of the request or the users that determines the approver to receive the workflow request. For example, Business Process is used to segregate approvals between different business process owners.

g. In the Select Role Attributes pane, identify the characteristics of the role(s) on the request that determines the approver to receive the workflow request. For example, the criticality of the role is used to require additional approval for high sensitivity roles. h. Select the Approvers option to identify the primary approver and the alternate approver for each Request Type. 8. Configure workflow stage. You can create workflow stages for the following workflow types: Mitigation Control Assignment Mitigation Control

Risk Maintenance For more information, see the section Workflow Creation Process. 9. Configure workflow paths. The workflow paths must be configured for all Risk Analysis and Remediation workflows. A path defines the steps that are followed when a workflow is triggered for the initiators that were configured in the previous step. Create each path with Number of Stages equal to one (1) and the paths in Active status. Name CC_MITCTRL CC_MITOBJ CC_RISK Workflow Type Mitigation Control Mitigation Control Assignment Risk Initiator CC_MITCTRL_INT CC_MITOBJ_INT CC_RISK_INT Stage 1 CC_MITCTROL CC_MITOBJ CC_RISK

For more information, see the section Creating Main Paths. 10. Configure exit URI for all integration workflow types. You must configure Exit URIs for all integration workflow types. All workflow types have the same functionality. a. Log on to Compliant User Provisioning > Configuration tab > Miscellaneous. The Miscellaneous Configuration screen appears. b. In the Workflow Types pane, add the Exit URI for the appropriate capabilities in the Name field.

August 2010

33

Risk Analysis and Remediation Miscellaneous For Risk Analysis and Remediation using mitigating control, mitigating object, and risk, add the exit URI: http://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?w sdl&style=document Example: http://iwdfvm2363:51000/VirsaCCWFExitService5_2Service/Config1 ?wsdl&style=document c. Enter the User Name and Password.

d. Select Active.

Miscellaneous
Use Miscellaneous settings to specify: How often to invoke the background job daemon (in seconds). The default value is 60 seconds. How many lines to display in a print preview window. The default value is 500. The spool files location for background jobs. No default value is provided. Action Usage File Location You specify the location the application stores the action usage purged data files. Whether to keep a change history of all changes made to risks. The default value is Yes. To view change log information for a risk, navigate to Rule Architect > Risks > Search to locate the risk. Click Change History. Whether to keep a change history of all additions and deletions of functions. The default value is Yes. To view change log information for a function, navigate to Rule Architect > Functions > Search to locate the function, and click Change History. Whether counts are conducted at the risk or permission level for management reports. The default value is Permission. The logger to be used. The default is SAP Logger. The report directory on the SAP Enterprise Resource Planning (ERP) application servers. This is the temporary storage location for security reports generated by background jobs. Virtual directories delivered in the ERP system, such as DIR_HOME and DIR_TMP, are supported. These directories are viewed with SAP ERP transaction, AL11. The same directory name is used for all SAP back-end systems. The receiving location on the Access Control server for FTP of spool files from the back-end server, as well as the user name, and password used for FTP.

Management of Internal Controls


You can integrate Risk Analysis and Remediation with SAP Management of Internal Controls (MIC). SAP MIC supports the implementation and documentation of regulatory processes and controls, as well as the assessment of internal controls performed by Risk Analysis and Remediation. The path mappings related to the SAP MIC controls can also be accessed through the Configuration tab.

34

August 2010

Risk Analysis and Remediation Management of Internal Controls

MIC Destinations in the MIC System


Configuration for Destinations in MIC is not available on the Access Control Configuration tab. To enable Risk Analysis and Remediation to work with SAP MIC, you must configure the Exchange Infrastructure (XI) communication system and connect it to the system where MIC is located. You must then perform the following steps on the system where MIC is running: 1. Create HTTP destination for master data query: Transaction SM59 RFC Destination <MICMasterDataQuery> VIRSAQUERY Type G Target Host <HostNameofXiSystem> ld0141.wdf.sap.corp Service No <PortNumberOfXiSystem> 54100 Path Prefix /XISOAPAdapter/MessageServlet?version=3.0&channel=:<ServiceName>: <ChannelName> /XISOAPAdapter/MessageServlet?version=3.0&channel=:mic_test: SENDER_REQUEST Use basic authentication with User ID and Password (xiappluser, xipass) 2. Create the HTTP destination for test logs: Transaction SM59 RFC Destination <MICTestLog> VIRSALOG Type G Target Host <HostNameofXiSystem> ld0141.wdf.sap.corp Service No <PortNumberOfXiSystem> 54100 Path Prefix: /XISOAPAdapter/MessageServlet?version=3.0&channel=:<ServiceName>: <ChannelName> /XISOAPAdapter/MessageServlet?version=3.0&channel=:mic_test: SENDER_NOTIFICATION Use basic authentication with User ID and Password (xiappluser, xipass) 3. Create default logical port for master data query proxy. Transaction lpconfig

August 2010

35

Risk Analysis and Remediation Management of Internal Controls lpquery for /VIRSA/CO_MPXINTERNAL_CONTROL Check the default option Point to HTTP destination created in step 1 - VIRSAQUERY 4. Create default logical port for test proxy. Transaction lpconfig lplog for /VIRSA/CO_MPXINTERNAL_CONTROL1 Check the default option Point to HTTP destination created in step 2 - VIRSALOG 5. Create Risk Analysis and Remediation parameters. 60 - MIC RE Post Result for Orgs with no issue (Yes/No) Yes 61 - MIC Interface RFC System ID (if Interface and Risk Analysis and Remediation are in different systems VIRSAXIPROXY 62 MIC Printer ID (for PDF creation) LP01 6. Create RFC destination for Web as 640 / 700 (in case of different systems). Transaction SM59 VIRSAXIPROXY Create RFC destination type 3 with same name as parameter 61 of step 5. 7. Create user map. Transaction /VIRSA/MICCONFIG 8. Create risk map. Transaction /VIRSA/MICCONFIG 9. Schedule job or execute program for automated test. Schedule job for program /VIRSA/MICTESTEX. 10. Schedule job or execute program. /VIRSA/MICDATASYNC

MIC User Mappings


MIC user mappings map MIC controls to Risk Analysis and Remediation objects. This integrates operations with MIC systems that you want to include in your compliance analysis. You can manually map remote MIC object data or import MIC user mapping information. To manually map remote MIC object data: 1. Navigate to Configuration > MIC User Mappings > Create. 2. Specify the system that contains the user information. 3. Specify the MIC Org ID, Process ID, and Control ID that you want to map. 4. Specify the Risk Analysis and Remediation object type that you want to map to (User, User Group, Org Level, or HR Org). 5. Specify the Map Value. 6. Click Save. 7. To import MIC user mapping information:

36

August 2010

Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation Navigate to Configuration > MIC User Mappings > Create. 8. Click Import. Use the MIC User Mapping search to verify that the user map was successfully imported.

MIC Risk Mappings


MIC risk mappings map MIC controls to Risk Analysis and Remediation objects. This integrates operations with MIC systems that you want to include in your compliance analysis. You can manually map remote MIC control IDs or import MIC user mapping information. To manually map remote MIC object data: 1. Navigate to Configuration > MIC User Mappings > Create. 2. Specify the system that contains the Control ID. 3. Specify the Control ID that you want to map. 4. Specify the Risk ID that you want to map to the Control ID. 5. Click Save. 6. To import MIC user mapping information: Navigate to Configuration > MIC User Mappings > Create. 7. Click Import. 8. Use the MIC User Mapping search to verify that the user map was successfully imported. To ensure that Risk Analysis and Remediation is synchronized with the back-end system, schedule a periodic job to update this information.

Defining Connectors for Risk Analysis and Remediation


When you have installed Risk Analysis and Remediation, you must enable integration with SAP applications by defining connectors. Each back-end ABAP system/client combination to be supported by Risk Analysis and Remediation requires a connector. You can connect to an SAP system or non-SAP system by using the appropriate connection type. The table below displays the mapping of system types to connection types.

System Type SAP

Connection Type(s) SAP JCO Web Service Adaptive RFC File Local File - FTP JDBC JDBC SLD Web Service File Local

Oracle

Legacy

August 2010

37

Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation

System Type

Connection Type(s) File - FTP JDBC JDBC SLD Web Service JDBC JDBC SLD Web Service Web Service

PEOPLESOFT

JD Edwards

Portal

Access Control communicates with multiple systems. SAP recommends using HTTPS communication protocol for secure communication. SAP GRC Access Control 5.3 gives you the option of setting up SAP JCO connections instead of Adaptive RFC connections.

To complete the Create Connectors screen, obtain the information from your network administrator.

Configuring JCO Connectors


Procedure To create a JCO connector: 1. In the SAP GRC Risk Analysis and Remediation window, click the Configuration tab. 2. Navigate to Connectors > Create. The Create Connector window appears. 3. Enter the System ID for the backend system you want to connect to. The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA.

4. Enter the System Name for that backend system. 5. Leave the System Type dropdown menu on its default setting: SAP. 6. Leave the Connection Type dropdown menu on its default setting: AdaptiveRFC. 7. From the JCO Destination dropdown menu, select the connector (the JCO destination you created during installation) for the backend system that you want to connect to. 8. Click Save. 9. Refresh your web browser window.

38

August 2010

Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation

Perform steps 3 through 9 for each backend system to which you configured a JCO destination.

Configuring SAP JCO Connectors


Procedure To create an SAP JCO connector: 1. Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. 2. In the System ID field, enter the system ID of the new system to which you are connecting. Note The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 3. In the System Type dropdown menu, select SAP for the system. 4. In the Connection Type dropdown menu, select SAP JCO. The screen selections change according to the selected connection type. For SAP JCO, a new configuration screen appears with additional fields. Note You can create additional JCO connectors to connect multiple SAP systems to a single Risk Analysis and Remediation landscape. 5. In the Host Name field, enter the host name of the system. 6. In the User ID field, enter the SAP user name. 7. In the Client ID field, enter the SAP client ID number. 8. In the System Number field, enter the number in the SAP system log. 9. In the Language field, enter the system language. 10. In the Logon Group field, enter the group name associated with the user ID. 11. In the SAP Gateway field, enter the back-end systems gateway name for each instance or group of application servers of the SAP ERP system. Note The gateway is defined by Basis in the server architecture. 12. In the Report Name field, create a unique external program name, such as GRCRTTOCC5X. 13. Select the Outbound Connection Flag checkbox to enable the connector for Risk Terminator. 14. Select the Unicode System Flag checkbox to designate that the back-end SAP ERP system is a Unicode system. 15. Click Save.

Verifying JCO Connectors


When you have created JCO connectors, test each one to verify the connection.

August 2010

39

Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation Procedure 1. Go to http://<host_name>:5<instance number>00/. 2. Use an assigned User Management Engine role with WebDynpro administrative actions to log on. 3. Select Content Administrator. 4. Select Check SLD Connection. 5. For Check Connection to the SLD, select Test Connection. Maximize the main window so you can view the status message that appears at the bottom of the window. 6. On the Content Administrator screen, select Maintain JCO Destinations. Verify that you have created proper JCO destinations for each SAP target system and for the associated SAP client. 7. Click Test to test each Java connection. A message appears at the bottom of the screen indicating the test was successful.

Configuring Connectors for an Oracle, PEOPLESOFT, or JD Edwards System using JDBC


To complete the Create Connectors screen, obtain the information from your network administrator. Procedure 1. Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. 2. In the System field, enter the system ID of the new system to which you are connecting. 3. In the System Name field, enter the name of the new system to which you are connecting. The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 4. In the System Type dropdown menu, select Oracle. 5. In the Connection Type dropdown menu, select JDBC connection. 6. In the Driver Name field, enter the name of the JDBC driver. 7. In the URL field, enter the directory path of the WSDL. 8. In the User ID field, enter the user ID for the Oracle system. 9. In the Password field, enter the password associated with the User ID. 10. Click Save.

Configuring Connectors for a Legacy system


Obtain information from your network administrator and complete the Create Connectors screen. Procedure 1. Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. 2. In the System field, enter the system ID of the system to which you are connecting.

40

August 2010

Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation 3. In the System Name field, enter the name of the new system to which you are connecting. The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 4. In the System Type dropdown menu, select Legacy. 5. In the Connection Type dropdown menu, select one of the following: File-FTP connection. In the FTP URL field, enter the directory path of the file transfer protocol location. File-Local connection In the Location field, enter the directory path of where the files will be stored. For data extraction, there are three folders that are needed in the directory: IN, OUT and EXP. The connector path should reference the OUT folder. The location where the files are stored must be in a directory that the application is mounted. We recommend you store the files directly on the applicationserver that hosts the Access Control Application. 6. In the User ID field, enter the user ID for the Legacy system. 7. In the Password field, enter the password associated with the User ID. 8. Click Save.

Configuring Connectors for a Portal using a Web Service


To complete the Create Connectors screen, obtain the information from your network administrator. Procedure 1. Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. 2. In the System field, enter the system ID of the new system to which you are connecting. 3. In the System Name field, enter the name of the new system to which you are connecting. The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 4. In the System Type dropdown menu, select Portal . 5. In the Connection Type dropdown menu, select the Web Service. 6. In the URL field, enter the URL link for the wsdl file, CCRTAWS. Enter the following address into your Web browser: http//<server_name>:<instance>/CCRTAWS/Config1?wsdl&style=document server_name is the name of your J2EE system instance is the instance of your J2EE engine

August 2010

41

Risk Analysis and Remediation Logical Systems Example: http://p168081.wdf.sap.corp:51000/CCRTAWS/Config1?wsdl&style=document or http://10.66.162.120:5100/CCRTAWS/Config1?wsdl&style=document The server name is where the Portal RTA is installed. You may need to specify the IP address of the server name if the server name is not supported for a specific J2EE engine. 7. In the User ID field, enter the user ID of the system administrator. 8. In the Password field, enter the password for the User you entered in the previous step. 9. In the Server Name field, enter the IP address of the server. 10. In the Port Number field, enter the port number for the server. 11. Click Save. For more information on configuring Risk Analysis and Remediation for the SAP Enterprise Portal, see Appendix C, Configuring Risk Analysis and Remediation for Enterprise Portal.

Logical Systems
A logical system is two or more physical systems grouped together to allow you to maintain rules against one system grouping instead of each physical system. Logical systems reduce the time and system resources required to maintain rule sets by avoiding identical rule sets for multiple systems. Physical systems take precedence over logical systems. If a physical system grouped within a logical system holds rules specific to that system, the physical system rules are checked first. Physical systems, logical systems, and cross systems share the following relationships: You can link one physical system to one or more logical systems You can link one physical system to one or more cross systems

When you create functions in Rule Architect, you can create or delete an action or permission and assign it to a specific system. You can define a function action against a logical system and a physical system. When you define or modify a logical system, you must regenerate rules for all the risks of that logical system so that the rules specific to each physical system are updated in the database. You generate rules on the Logical Systems > Generate Rules screen. Updating a particular risk only requires updating the rules for that risk and, therefore, does not require access to the Configuration tab. Example The following example describe the relationship between physical systems and logical systems, when rules or functions are applied separately to both. You define a logical system, PROD consisting of physical system, PR1 and physical system, PR2, where the two instances are SAP ERP systems. You can update the two physical systems with transaction codes which make up the rules.

42

August 2010

Risk Analysis and Remediation Logical Systems For instances, you can update PR1 and PR2 with the transaction code FB01 with the same permission by specifying the logical system, PROD. In another instances, the transaction code, ZFB01 has an extra permission that you want to add in PR1. You can specify the physical system PR2 so that only the physical system is updated with ZFB01 and the permission. In this case, the logical system is not updated with ZFB01.

Defining a logical system streamlines the rule definition process. For this reason, you see logical systems you have created from within Rule Architect, but you do not see these logical systems when running Risk Analysis. Physical systems take precedence over logical systems. If a physical system grouped within a logical system holds one or more rules specific to that system, the system checks the physical system rule first.

Creating a Logical System


Procedure To create a logical system: 1. On the Configuration tab, navigate to Logical Systems > Create. 2. Create a logical system, and assign its physical systems. 3. Use Rule Upload to upload function_actions and function_permissions for the logical system. For more information, see Appendix A, Rule File Templates. 4. Generate rules by navigating to Logical Systems > Generate Rules on the Configuration tab. You must load permission and text data for at least one physical system by navigating to Configuration > Upload Objects. If you define a logical system and load text for multiple physical systems, the logical systems text and authorizations are used when updating function data. Text loaded for the first system listed in the logical system definition is used as the logical system text. You use the permission and text data when you manually update functions. Use the text data to populate the descriptions in the analysis reports.

Loading Rules against a Logical System


1. After creating a logical system, load rules against the logical system. For more information, see the section Uploading the Function Authorization Text Files. 2. When uploading the files, select the logical system as the system name. 3. After uploading the data, generate the rules for the logical system by navigating to Logical Systems > Generate Rules on the Configuration tab. When generating rules for the logical system, you do not see rules for the individual physical systems within the logical system. The rules are created at the logical system level only.

August 2010

43

Risk Analysis and Remediation Cross Systems Example You load the global rules against physical system A and generate all the rules. You then create a logical system that contains both physical system A and physical system B. You then reload all of the actions/permissions against the logical system and generate the rules. The system generates the rules for the logical system, but since you also have the rules for physical system A, those rules also still exist. If a system is contained within a logical system but has rules built against the physical and logical systems, the physical system takes precedence.

Cross Systems
A cross system is two or more physical systems grouped together so you can perform user analysis operations across multiple systems. You can select and view cross systems when you generate and view Informer Management Reports or perform Risk Analysis. Physical systems, logical systems, and cross systems share the following relationships: You can link one physical system to one or more logical systems. You can link one physical system to one or more cross systems.

You can perform risk analysis against one system or all systems. To do so, you must define two or more systems as a cross system. With a subset of systems defined as a cross system and available in the System dropdown list, you can perform analysis operations against one physical system, all physical systems, or a selected cross system. When you define or modify a cross system, you must regenerate the rules for all the risks, so the system-specific rules can be updated in the database. You generate rules by navigating to Cross Systems > Generate Rules. Updating a particular risk only requires updating the rules for that risk and, subsequently, does not require access to the Configuration tab. Example You define a cross system ID, XFINANCE consisting of physical system, ERP1 and physical system, ORA2, where the two instances are an SAP ERP system and an Oracle application server, respectively. The ERP1 system is solely used for buying services from vendors, whereas ORA2 system is for paying vendors. The two systems can use different transaction codes. You can perform risk analysis in a cross system, where risk analysis determines access in each system defined in a cross-system risk to determine if the risk exists.

Creating a Cross System


Procedure 1. Navigate to Configuration Cross Systems > Create. 2. Create a cross system, and assign its physical systems. 3. Generate rules by navigating to Configuration Cross Systems > Generate Rules.

44

August 2010

Risk Analysis and Remediation Cross Systems

Data Extraction
The data extraction function uploads user, role, and profile data from legacy systems and reconciles and unifies that data in Risk Analysis and Remediation format.

For legacy systems, you must extract the data to a file first, then use Risk Analysis and Remediation to upload it. For more information, see the following sections: Appendix B: Data Mapping Templates for Non-RTA Support Systems Running the Comparison Utility Configuring Connectors for a Legacy System Administration for Non-RTA Supported Systems

Creating a Data Extractor


Procedure 1. Go to Risk Analysis and Remediation > Configuration tab > Data Extraction > Create. The Create Data Extractor screen appears. 2. In the System dropdown list, select the legacy system for which you intend to import data files. 3. In the Object dropdown list, select the object data you want to import. You must repeat these steps for each object: User, Role, and Profile. When you select an object, that object name appears on the first tab. The dropdown lists available on all three tabs are customized to display the options that apply to your selection. For example, when you select the Role object, the title of the first tab is Role. The Target Fields are associated with the Role object. 4. In the Data Extraction dropdown list, select Flat File. Only the Flat File mode is supported. 5. On the User, Actions, or Permissions tab, enter the file name in the File Name field. This file contains the data you want to import to GRC Access Control. For example, the file for user objects. The location (application server path) where these files are stored must be defined in the Connector. 6. In the File Type dropdown menu, select Delimited. 7. In the Delimiter field, enter \t. This specifies a tab-delimited output file. 8. (Optional) If you must add more field names for the Target Field and Source Field, highlight the field where you want the new field and select the icon. To remove a field in the Target Field and Source Field, highlight the field and click the icon. In the Source Field column, enter the output file number to specify the field order of the extracted output. For example, if you entered 5 as the Source Field value for the USERID, Risk Analysis and Remediation uploads the data in column 5 from your text file as the USERID. The Data Extractor order must exactly match the order of the data in your extracted flat file.

August 2010

45

Risk Analysis and Remediation Cross Systems 9. Click Save.

Extracting User and Role Data in a Background Job


Use the Extract Background mode to load the data into Risk Analysis and Remediation. You want to load each file (user, roles, and permissions) separately. Procedure 1. Go to Risk Analysis and Remediation > Configuration tab > Data Extraction > Search. The Search Extractor screen appears. 2. In the System field, enter your legacy system. 3. In the Object dropdown list, select the object data you want. 4. Click Search. 5. In the Systems and Data Extractors screen, select a data extractor, and click Change. 6. In the Change Data Extractor screen, accept all of the defaults, and select Extract Background. 7. The Upload Extractor Data screen appears. Select the checkboxes for User, Actions, or Permissions. If the system contains permission-level records that you want to extract, select Permissions. 8. Select Upload. 9. In the Schedule Background Job screen, enter a Job Name. 10. Click either Immediate Start or Delayed Start. For an Immediate Start, the start date and time is grayed out. For Delayed Start, enter the desired start date and time. 11. To schedule this job to run periodically, click Schedule Periodically. 12. Select either Daily, Weekly, or Monthly and enter the number of times you want the job to run for that period. 13. In the End Date field, enter a date to end the job. You can use the Calendar icon to set the date. 14. Click Schedule. Read the status line message underneath the navigation bar to verify that the job is scheduled.

Running the Comparison Utility


Use this information to compare and load changes from your non-RTA system. The security environment constantly changes due to adding, modifying, and deleting users. Therefore, it is recommended to frequently re-extract data from your legacy system and reload it into Risk Analysis and Remediation. When re-extracting and reloading the definition files, ensure that the file names remain the same. Save these new files into the IN folder. For more information, see the following sections: Configuring Connectors for a Legacy System Administration for Non-RTA Supported Systems

46

August 2010

Risk Analysis and Remediation Cross Systems Procedure The Comparison Utility takes data files from the IN folder, compares it to data in the Risk Analysis and Remediation database, and places the incremental added, deleted, or changed data files in the OUT folder for Data Extraction loading. When the system completes this process, the Comparison Utility deletes data files from the IN folder. The system also updates the EXP folder with the changed data files along with exceptions and statistical information, such as how many users were changed and processed. 1. Go to Risk Analysis and Remediation > Configuration tab > Data Extraction > Comparison Utility. 2. In the System field, enter a system ID or use the Search option to find the system ID. 3. For the second System field, select a system ID by using the Search option or a range of systems that you want to compare. 4. In the Object dropdown list, select ALL. You can run the Comparison Utility for one or more systems and for one or all objects. You must place the extracted new user and role data files in the IN folder. 5. Click Foreground or Background depending on how you want to process the utility. A successful comparison results in a confirmation on the Status line. 6. After the Comparison Utility finishes, run the Data Extractor in the background to load the new information into the system. The Comparison Utility only generates a delta file. The data in Risk Analysis and Remediation is not updated until the Data Extractor is executed again. For more information, see the section Extracting User and Role Data in a Background Job.

August 2010

47

Risk Analysis and Remediation Deleting a System

Deleting a System
The Delete Systems feature allows you to delete an obsolete system and its related data from the RAR application. Using this feature affects the following components: All alerts All user management reports System-specific role and profile management reports All user violations and system-specific role and profile violations Data extraction data (if the connector is a legacy system connector) Function actions for selected systems Function permissions for selected systems Rules for the selected systems Selected systems (from the physical connector definition as well as the logical and cross-system definitions User mapping

Caution Back-up the application data before executing Delete Systems. Use the Delete Systems feature in a pre-production environment only. All users must be logged off of the application while the deletion function is running because any locks on the database tables will prevent the deletion function from completing. Delete Systems will delete all users and their corresponding violations from the database, without regard to the system where a user account exists. This is necessary because RAR always treats a user as a single item, even if the user exists in multiple systems. Procedure To delete a system: 1. Go to Configuration > Utilities > Manage Delete screen. 2. Select Delete Systems and press Submit. A list displays of the systems available in the application. A warning pop-up displays stating that this action will permanently delete all rules 3. Select the systems you want to delete, and press Next. A list of the systems that will be deleted displays. 4. Press Yes and the jobs that you chose to delete are scheduled.

Deleting All Rules


The Delete All Rules feature allows you to delete all the rules defined in the RAR application. This feature will delete all of the data present in the application, except for configuration and message data. The following components are affected by this feature: All alerts All management reports

48

August 2010

Risk Analysis and Remediation

All violations Business processes Critical roles Critical profiles

Caution Back-up the application data before executing Delete All Rules. Use the Delete Systems feature in a pre-production environment only. All users must be logged off of the application while the deletion function is running because any locks on the database tables will prevent the deletion function from completing. Before performing any operation after executing the Delete All Rules feature, recreate the rules, perform full user, role, and profile synchronization, and run full sync Batch Risk Analysis with Management report. Otherwise, Risk Analysis and Remediation may not function properly. Procedure To delete all rules: 1. Go to Configuration > Utilities > Manage Delete screen. 2. Select Delete All Rules and press Submit. A list displays of the components that will be deleted. Before performing the next step, note that this action will permanently delete all rules. 3. Press Yes, and the rules that you specified are scheduled for deletion. Two UME permissions are used with the Delete All Rules feature: ManageDeletionSystemRules for Delete Systems ManageDeletionAllRules for Delete All Rules

Master User Source


As part of the post-installation process, you define a Master User Source to specify the primary system where Risk Analysis and Remediation obtains user data. Not all users must be defined in the Master User Source. The Master User Source is the initial source for retrieving basic user information, such as name and user group. If the search cannot find a user ID in the Master User Source, it searches the remaining systems with connectors until it finds the user ID. In this case, it obtains the user information from a system other than the Master User Source. Change the Master User Source setting only to change the primary system for user data. If you change the Master User Source setting, verify and update any previous custom user mapping and perform a back-end User Sync. Only systems for which you have created a connector appear in the Select System dropdown list.

August 2010

49

Risk Analysis and Remediation User Mapping

User Mapping
If you are analyzing multiple systems and a user ID does not represent the same individual in each system, you must maintain the user mapping. User Mapping links the accounts of the user, so the system can recognize all of the IDs of a user. This ensures that risk analysis produces accurate results for each user. Example User Mapping allows you to create one user ID mapping to multiple different user IDs for the same user in several systems. You can define a user ID as the Master User ID and associate the system name and the user ID for that system. You can define the same Master User ID to other systems, such as an SAP, non-SAP, LDAP, and the like. For instance, in an SAP system you set the Master User ID as CPERKINS along with the same system user ID. You then can set the same Master User ID (CPERKINS) for a non-SAP with the system user ID of calvin.perkins. And also map an LDAP directory with the same Master User ID with the system user ID of perkins. You then can have a rule that states that CPERKINS has permission for an SAP, non-SAP, and LDAP system. When you perform a risk analysis on ALL systems for user ID CPERKINS, any systems that do not have the use mapping will result as a risk violation. Procedure To link user IDs to systems by user mapping: 1. Go to Configuration > User Mapping > Create screen. 2. In the Master User ID field, enter the user ID, which is the ID to be used to identify this user in generated reports. 3. In the System dropdown menu, select the system name on which the secondary account resides. 4. In the System User ID field, enter the secondary account for that user. 5. Click Save. If a single user ID always represents the same user, regardless of the source system, you do not need to map users.

Custom User Groups


Custom user groups are definable groups that associate user accounts, so they can be processed together. You can specify these custom user groups as selection criteria when you perform user-level risk analysis. Activities Use the Create Custom User Group screen to specify user groups or to import user groups. To create a custom user group, navigate to Configuration > Custom User Group > Create. Enter a name for the custom group and a list of user IDs. Click Save. You can import custom user groups using either exported files from another instance of Risk Analysis and Remediation or any tab-delimited text file in the following format:

50

August 2010

Risk Analysis and Remediation Upload Objects

CUSTOM_GROUP_A CUSTOM_GROUP_A CUSTOM_GROUP_A CUSTOM_GROUP_A CUSTOM_GROUP_A CUSTOM_GROUP_B CUSTOM_GROUP_B CUSTOM_GROUP_B CUSTOM_GROUP_B

JSMITH TMSMITH RSMITH JJOHNSON BJOHNSON GLOPEZ MWASHINGTON KCHOW ADESALVO

Upload Objects
You load descriptive (static) text and authorization objects for each Access Control capability. For SAP systems, descriptive text comes from various text tables, and the authorization object is SU24/USOBT_C data. You use the Upload Object option to upload objects for different physical systems or for one or more logical systems. The system uses the descriptive text to complete the report output and provide the text descriptions for technical objects, such as transactions, objects, fields, and values. The authorization object data provides default objects, fields, and values for the rule architect. If you create a function, the permissions for each action default to the data in the last authorization object file upload. These default permissions are also included if you add an action to an existing function. To ensure that Risk Analysis and Remediation is synchronized with the back-end system, schedule a periodic job to upload the object files.

Uploading Static Text


Procedure 1. From your SAP server (backend system), enter transaction code SE38. The ABAP Editor: Initial screen appears. 2. In the Program field, enter /VIRSA/ZCC_DOWNLOAD_DESC, and click Execute. 3. In the Local File field, enter a path and the name for the static text file. The suggested name for this file is SAPtext.txt. Use the Search button located to the right of the Local File field to navigate to the desired directory, and name the file. For easy access, store the file on your desktop and name it SAPText.txt. 4. Click Execute. 5. Return to Risk Analysis and Remediation, select the Configuration tab, and navigate to Upload Objects > Text Objects. 6. Complete the following fields: System ID

August 2010

51

Risk Analysis and Remediation Rule Upload

If you have connected to multiple SAP systems, enter a single system ID, and repeat the steps above for each SAP system. Local File Enter the path to (or browse to) SAPText.txt. 7. Click the appropriate button to execute this process in the background or foreground. To execute this job in the background, the SAPText.txt file must be stored on an application server. If the text must be in multiple languages, the user must log on to the back-end ABAP system using the language under which the file should be exported. Run the program as described above for each language that you want to load into Risk Analysis and Remediation, and upload each file as described above.

Uploading Authorization Objects


Procedure 1. From your SAP server (backend system), enter transaction code SE38. The ABAP Editor: Initial screen appears. 2. In the Program field, enter /VIRSA/ZCC_DOWNLOAD_SAPOBJ, and click Execute. 3. In the Local File field, enter the path to and the name of the authorization object file. The suggested name for this file is SAPAuthObj.txt. Use the Search button located to the right of the Local File field to navigate to the desired directory, and then name the file. For easy access, store the file on your desktop, and name it SAPAuthObj.txt. 4. Click Execute. 5. Return to Risk Analysis and Remediation, and navigate to Configuration > Upload Objects > Authorization Objects. 6. In the Local File field, enter the specified path (or browse to the location), and specify SAPAuthObj.txt. 7. Click the button to execute this process in the background or foreground. To execute this job in the background, the text file must be stored on an application server. For more information, see the following sections: Uploading Static Text Uploading Authorization Objects

Rule Upload
Risk Analysis and Remediation is delivered with text files for uploading default action and permission rules for SAP ERP, APO, CRM, and SRM systems and EC-CS. You can load HR and BASIS rules for SAP ERP systems independently, if desired. Action rules are included for selected non-SAP applications as well.

52

August 2010

Risk Analysis and Remediation Rule Upload

Recommendation Upload rules only once for new installations. If you are upgrading, do not reload the rule set. If you do, the rules might overwrite any customizing you have done. Rules are specific to each system in your deployment. You must create and configure system connectors before you can upload rules to systems. For example, if you want a specific CRM system to be analyzed for SoDs and critical access, you must establish the connector to that system before you can upload rules for that CRM system. Similarly, to monitor a Business Intelligence (BI) system for BASIS activities, you must establish the connector to that system before you can upload the BASIS rules for that BI system. You can also create custom rules and rules for legacy systems. Format the rules according to the standard formats. For more information, see Appendix A, Rule File Templates. Save all of the delivered text files to the same directory. Load the text files in the same order as the tree structure. You can expand the Rule Upload submenu to display these available options: Business Process Function Function Authorization Rule Set Risk Generate Rules

For more information, see the following sections: Uploading a Business Process Text File Uploading the Function Text Files Uploading the Function Authorization Text Files Uploading a Rule Set Text File Uploading the Risk Text Files Scheduling Rule Generation

Uploading a Business Process Text File


Procedure 1. On the Configuration tab, navigate to Rule Upload > Business Process. 2. In the File Location field, browse for the file ALL_business processes.txt. 3. Click Open. 4. Click Upload.

Uploading Function Text Files


Procedure 1. On the Configuration tab, navigate to Rule Upload > Function. 2. In the Function field, browse for the file ALL_function.txt. 3. Click Open.

August 2010

53

Risk Analysis and Remediation Rule Upload 4. In the Function BP field, browse for the file ALL_function_BP.txt. 5. Click Open. 6. Click Upload.

Uploading Function Authorization Text Files


Note When uploading multiple system rules, upload the file for SAP ERP first. When the SAP ERP rules are loaded against a system, the SAP BASIS and HR files are not loaded since their rules are included in the overall SAP ERP file. Load SAP BASIS and HR files only on systems that do not have the full SAP ERP rules loaded. Procedure To upload function authorization files: 1. On the Configuration tab, navigate to Rule Upload > Function Authorization. 2. From the System dropdown list, select the system for which you want to load the functions 3. In the Function Action field, browse for the file [SYSTEM]_function_action.txt. 4. Click Open. 5. In the Function Permission field, browse for the file [SYSTEM]_function_permission.txt. 6. Click Open. 7. Click Upload. 8. Repeat this procedure for each system that requires loaded rules.

Uploading a Rule Set Text File


Procedure To upload a rule set text file: 1. On the Configuration tab, navigate to Rule Upload > Rule Set. 2. In the File Location field, browse for the file [ALL]_Ruleset.txt. 3. Click Open. 4. Click Upload.

Uploading Risk Text Files


Procedure To upload the risk text files: 1. On the Configuration tab, navigate to Rule Upload > Risk. 2. In the Risk field, browse for the file [SYSTEM]_Risk.txt. 3. Click Open. 4. In the Risk Description field, browse for the file [SYSTEM]_Risk_desc.txt. 5. Click Open. 6. In the Rule Set Mapping field, browse for the file [SYSTEM]_Risk_RuleSet.txt.

54

August 2010

Risk Analysis and Remediation Rule Upload 7. Click Open. 8. Click Upload. 9. Repeat this procedure for each system that requires loaded rules.

Scheduling Rule Generation


Procedure To schedule a job to generate rules: 1. On the Configuration tab, navigate to Rule Upload > Generate Rules. 2. To schedule this job for the first time, click Background. 3. Click Upload. Note You can regenerate a rule.

August 2010

55

Risk Analysis and Remediation Back-end Synchronization (with Management of Internal Controls)

Back-end Synchronization (with Management of Internal Controls)


When you integrate SAPs Management of Internal Controls (MIC) application with Risk Analysis and Remediation, you must perform a back-end synchronization with MIC. Doing this transfers the mitigation and rule information from Risk Analysis and Remediation to the back-end ABAP stack where the MIC application resides. When defining mitigation information in Risk Analysis and Remediation, you can import the information to the destination system, which is an SAP back-end system where MIC resides. This concept is the same for the rule synchronization, where you define the system rule set in Risk Analysis and Remediation and then import that information to the destination system. Synchronization in the foreground is an immediate import of the mitigation or rule set information, whereas synchronization in the background is a scheduled job that happens at a defined timeframe. Activities You can perform mitigation synchronization and rule synchronization to the back end.

Synchronizing Mitigation
Procedure To perform mitigation synchronization with the backend: 1. On the Configuration tab, navigate to back-end Sync > Mitigation Sync. 2. Select a Source System from the dropdown list. 3. Select a Destination System from the dropdown list. 4. Select Foreground or Background to synchronize the mitigation with MIC.

Synchronizing Rule
Procedure To perform rule synchronization with the backend: 1. On the Configuration tab, navigate to back-end Sync > Rules Sync. 2. Select a System Rule Set from the dropdown list. 3. Select a Destination System from the dropdown list. 4. Select Foreground or Background to synchronize the rules with MIC.

56

August 2010

Risk Analysis and Remediation Background Jobs

Background Jobs
Use Background Jobs to schedule synchronization with back-end systems, batch risk analyses, generation of management reports, and generation of alerts. You can also use the DataMart background job to extract data to to be accessed by custom reports. When you schedule a synchronization background job, you can synchronize in Full mode or Incremental mode. Full mode is the synchronization of all user, role, or profile information. Incremental mode updates only the information about the user, role, or profile that has changed since the last synchronization. Risk Analysis and Remediation tracks the execution date and time of all synchronization jobs. Therefore, when you want to synchronize in Incremental mode, Risk Analysis and Remediation knows when the last update occurred and synchronizes only the information that has changed.

You can schedule the update of risk analysis results by using the Batch Risk Analysis operation.

Scheduling a Synchronization Job


Procedure 1. Log on to Risk Analysis and Remediation. 2. In the Configuration tab, select Background Job > Schedule Job. 3. In the User/Role/Profile Synchronization pane, select Sync Mode, and choose Full Sync or Incremental. After the initial synchronization, schedule a nightly job to perform an incremental synchronization. Perform a full synchronization periodically as well to ensure data integrity. 4. Select the desired synchronization: User Synchronization Role Synchronization Profile Synchronization 5. Select System or enter the wildcard (*) value to perform synchronization for all connected systems. 6. Click Schedule. The Schedule Background Job screen appears. 7. In the Job Name field, enter a name for the job. 8. Select Immediate Start, or select Delayed Start and indicate the date and time to begin. If you want the job to be performed multiple times, select Schedule Periodically, and indicate the frequency as well as the End Date past which no jobs will execute. 9. Click Schedule to accept your input or Reset to begin again. When the job is successfully scheduled, the following message is displayed: Background job scheduled successfully, Job ID: XX.

August 2010

57

Risk Analysis and Remediation Background Jobs

Scheduling Batch Risk Analysis


You can schedule the update of risk analysis results by using the Batch Risk Analysis operation.

Incremental batch risk analysis evaluates only users, roles, and profiles that have changed in the back-end system. Any changes in the front-end system, such as changes to rules or mitigation, are not included. Therefore, SAP recommends that you also run a monthly full batch risk analysis to reflect any front-end changes. Procedure 1. On the Configuration tab, navigate to Background Job > Schedule Job. 2. Enter the required information. 3. In the Batch Risk Analysis pane, for non-SAP systems, select Full Sync, and if needed, specify a rule set to apply for batch analysis. 4. For Report Typ, choose either Action Level Analysis or Permission Level Analysis. 5. Select one or more of the following risk analysis types: User Analysis Select the Systems, Users, and User Groups for analysis. Role Analysis Select the Systems and Roles for analysis. Profile Analysis Select the Systems and Profiles for analysis. Critical Action and Role/Profile Analysis Select the System, Users, and User Groups for analysis. 6. Select Schedule. The Schedule Background Job screen appears. 7. Select Immediate Start, or select Delayed Start and indicate the date and time to begin. If you want to perform the job multiple times, select Schedule Periodically, and indicate the frequency as well as the End Date past which no jobs will execute. 8. Select Schedule to accept your input or Reset to begin again.

Excluding Objects from Batch Risk Analysis


You can use the Exclude Objects feature to exclude users, user groups, roles, and profiles from the batch risk analysis. This is recommended for objects with a large number of violations that are monitored, or for which monitoring is not appropriate. For example, the profile SAP_ALL is identified as a critical profile and monitored through critical role/profile analysis. Also, when testing in a development environment where some users violate a large number of risks, you may exclude the relevant user groups so that you are analyzing accounts with access similar to that of a productive environment.

Recommendation Always run the batch risk analysis for * and use Exclude Objects to exclude unnecessary roles/users/profiles. The management report reflects the number of users/roles/profiles

58

August 2010

Risk Analysis and Remediation Background Jobs analyzed: (Total number of users synchronized - Excluded users/roles/profiles). Example The following example illustrates the effect of exclusion objects on the batch risk analysis report. There are 100 total roles in the system. You exclude a total of 30 roles. You select a total of 80 roles for risk analysis.

The resulting management report displays 70 roles analyzed (the 80 roles entered less the 10 roles identified as excluded roles). The 30 excluded roles are considered no risk and are not included in the analysis even if they are entered in the selection criteria for the analysis.

Note When specifying a user, user groups, roles or profile to be excluded from batch risk analysis, all existing violation data in the offline analysis and management report database tables will be removed for that object.

Recommendation Deletion of large volumes of risk violation information for newly identified Exclusion Objects may cause the job to time out. If you included objects with significant risk violations in the previous batch risk analysis, we recommend you identify one or a few of those objects at a time and perform batch risk analysis after each update of the Exclusion Objects.

Process 1. Create, change, or delete an exclusion object. 2. Select a batch risk analysis report. 3. Schedule the report. Procedure 1. Log on to RAR -> Background Job -> Schedule Job. The Schedule Job screen appears. 2. Select Exclude Objects. The Object Exclusion screen appears. 3. Choose to add, change, or delete excluded objects. To delete an object, select it and choose Delete. To add exclusion objects, choose Add. The Create Exclusion Objects screen appears. Enter the required information and choose Save. Note For object types User Group and User, the System is automatically set to All.

August 2010

59

Risk Analysis and Remediation Background Jobs To change an exclusion object, choose Change. The Change Excluded Object screen appears. Edit the object and choose Save.

Scheduling Management Report Generation


Procedure To schedule generation of the management reports: 1. On the Configuration tab, navigate to Background Job > Schedule Job. 2. In the Management Report section, select the Management Reports checkbox. 3. Click Schedule. The Schedule Background Job screen appears. 4. In the Job Name field, enter a name for this job. 5. Select Immediate Start, or select Delayed Start and indicate the date and time to begin. If you want to perform the job multiple times, select Schedule Periodically, and indicate the frequency as well as the End Date past which no jobs will execute. 6. Click Schedule to accept your input or Reset to begin again. When the job is successfully schedled, the following message is displayed: Background job scheduled successfully, Job ID: XX.

DataMart Job
You use the DataMart Job to extract data from the RAR and CUP tables. The data is transported to the data mart where you can integrate it with your reporting tool for custom reporting. Features The data entities available in data mart for reporting are as follows: Risk violations Mitigating controls Rule Architect CUP Request information Approver and approver delegation

Procedure On the Configuration tab, navigate to Background Job > DataMart Job. The Schedule Data Mart Job screen appears. In the Data Mart Extraction section, choose the data type. Master Data The DataMart Job always performs a full synchronization of master data.

60

August 2010

Risk Analysis and Remediation Background Jobs Transactional Data You can choose to perform a full or incremental synchronization of transactional data. Recommendation We recommend performing a full synchronization before performing any incremental synchronizations. CUP By default, the background job extracts RAR data. Choose this option to include CUP data in the extraction.

Click Schedule. The Schedule Data Mart Synch Batch Background Job screen appears. In the Job Name field, enter a name for this job. Select Immediate Start, or select Delayed Start and indicate the date and time to begin. If you want to perform the job multiple times, select Schedule Periodically, and indicate the frequency as well as the End Date past which no jobs will execute.

Click Schedule to accept your input or Reset to begin again.

Scheduling Alert Generation


When you generate an action log, the data is loaded to a local table in Risk Analysis and Remediation. You can generate alerts based on the following alert types: Conflicting Actions This alert type is an action level analysis, where any violation generates an alert. Critical Actions This alert type is an action level analysis, where any violation generates an alert. Control Monitoring This alert type is a mitigation level analysis, which generates mitigation alerts.

During the generation of alerts, the user and transaction information is passed to the risk analysis. If you select the Consider Mitigated Users option, alerts are generated on user who are associated with a mitigated risk. The generation of these alert types are useful for transaction usage in Segregation of Duties (SoD) Review and User Access Review (UAR). You can also set up a background job for sending alert notification via email based on the alert type. By selecting Conflicting Actions and/or Critical Actions alert types, notifications are sent to Risk Owners. Selecting Control Monitoring alert type sends notification to the Management Approver of the Mitigating Control. Procedure 1. On the Configuration tab, navigate to Background Job > Alert Generation. 2. In the Action Monitoring section, select Generate Action Log. 3. Select the SAP single or cross systems for which to generate alerts. Only SAP servers that have connectors created appear in the dropdown list. 4. Select one or more types of alerts to include in the action log. 5. Select the Risk IDs and Risk Level. Indicate whether to Consider Mitigated Users.

August 2010

61

Risk Analysis and Remediation Organizational User Mapping

By default, Consider Mitigated Users is not checked, and the mitigated risks for a particular user do not display in the alerts. Check this option if you want mitigated risks to show up in the alerts. 6. Select the Mitigating Control IDs. In the Alert Notification screen, select the items for which email notifications will be sent. Conflicting Action or Critical Action notifications are sent to the Risk Owner. Control Monitoring notifications are sent to the Management Approver of the Mitigating Control. 7. Click Schedule. 8. Select Immediate Start or Select Delayed Start and indicate the date and time to begin. If the job must be performed multiple times, select Schedule Periodically and indicate the frequency as well as the End Date.

Maintain the alert log file name and location as described in the Miscellaneous configuration section. For troubleshooting tips, see SAP Note 1015921 Collective note for Alerts Log Not Capturing Data.

Organizational User Mapping


You can perform a risk analysis to identify users who have display or update activity permissions for an organizational level. This type of analysis is dependent on organizational level data for users maintained in Risk Analysis and Remediation. Use Organizational User Mapping to extract and maintain this organizational level data from the back-end source system. By mapping users to organizational level, you create an organizational user mapping table that is used for filtering the user for organizational level analysis. You can then apply organizational rules that filters for certain conditions during analysis. For instance, you have a organizational rule for company code and during the organizational level analysis, only users that have permission to access the company code are considered.

Maintaining User Organizational Information


Procedure To add or update user information: 1. On the Configuration tab, navigate to Organizational User Mapping. 2. In the System ID dropdown list, select the system that contains the user data you want updated within Risk Analysis and Remediation. 3. In the User selection fields, enter a user range to maintain. 4. To update organizational-level data for all users in the selected system: a. Click Search. Enter the first listed user in the User field. Enter the last listed user in the To field. To perform: A one-time update of a small data set, click Foreground. Periodic synchronization or one-time maintenance for a large data set, click Background to schedule the job(s).

62

August 2010

Risk Analysis and Remediation Custom Tabs

Custom Tabs
Use the Custom Tabs menu item to add up to three customer-specific tabs to the Risk Analysis and Remediation menu. The custom tabs appear to the right of the Configuration tab after definition of the custom screens URL.

Adding a Custom Tab


Procedure To add a custom tab: 1. On the Configuration tab, navigate to Custom Tabs. 2. To edit Custom Tab1, specify a Tab Name. For example, to add a tab for the User Management tool, you might enter User. 3. In the Tab URL field, enter the URL for the Web page or Web service. For example, to provide a URL for the User Management tool, you might enter: http://<server_name>:<port_number>/useradmin 4. Click Enable. 5. Click Save. The following message appears at the bottom of the navigation bar: Custom Tab details updated successfully. The system adds the new tabs to the right of the Configuration tab. Refresh your Web browser view to see the changes take effect. 6. Repeat this procedure for each custom tab desired. Custom tabs are visible by all users of the application. It is not possible to make the tabs user-specific.

SAP Adapter
The SAP Adapter is a continuously running interface between Risk Analysis and Remediation and the SAP back-end system where the SAP Adapter is defined. The SAP Adapter enables real-time analysis in the Risk Terminator. Whenever Risk Terminator is triggered in the SAP back-end system, data is transmitted to the SAP Adapter and, subsequently, to Risk Analysis and Remediation. The SAP Adapter performs the risk analysis and sends the results back to the Risk Terminator. The SAP Adapter item on the Configuration tab displays a list of all SAP Adapter servers. The information displayed includes the SAP system ID, host name, gateway, and program ID.

Utilities
The Utilities options include Export, Import, Purge Action Usage, and Manage Deletion utilities.

Export Utility
You can export configuration information for Risk Analysis and Remediation that is defined in one system (source) to another system (destination). The Export utility allows you to select

August 2010

63

Risk Analysis and Remediation Utilities one or many types of data components and transfer them to a define system ID. The functionality of the Export utility is similar to the export tool found in the Rule Architect tab and Mitigation tab, but with different data extract files. The Export utility exports many types of data, including: Configuration Data Connectors MIC User Mappings MIC Risk Mappings Logical Systems Cross Systems Data Extraction User Mapping Custom User Groups

One exported file is generated for each execution of the Export utility. The export file begins by identifying the source system of the exported records. A metadata record follows the source system and identifies the technical table and field names of the exported data. Data records follow the metadata record. If more than one type of data was exported, there are additional sections, each with a metadata record followed by data records. When you export rules, mitigation, or configuration, dependent tables are included, even if you do not manually select them. Example You want to download User Mitigation. User mitigation entries require a Control ID and Monitor, so those tables are also included in the exported data. Select Get Configuration to generate the data and provide the option to open or save the generated file. Save this file to a location for upload into another system.

Import Utility
The Import utility imports files exported from other Risk Analysis and Remediation instances. The data format from the exported file is used during the data import. When importing files into another Access Control system, the Import utility loads all tables included in the export. The Import utility does not append these records to existing records; it overwrites all existing entries. As a precaution, if configuration or mitigation records exist in the system to which you are importing new data, export all configuration or mitigation entries from that system as a backup. The system notifies you at the time of loading the data that this process will overwrite all existing entries. The Import utility overwrites all existing entries; it does not append records. If configuration or mitigation records exist in the system where you are importing new data, export all configuration or mitigation entries from that system prior to importing other data. The system notifies you at the time of loading the data that existing entries are overwritten.

Purge Action Usage Utility


The Purge Action Usage utility archives records from time periods that are no longer of interest. This utility reduces the size of large databases or files. You specify the location the system stores the file in Miscellaneous.

64

August 2010

Risk Analysis and Remediation Utilities Purging action usage records affects the SoD Review and User Access Review reports of other capabilities, since they use the database tables. Purging action usage does not impact Risk Analysis and Remediation reports, since they access the archived files in addition to the action usage tables. During configuration, specify the date when you want to retain action usage data and the maximum records allowed in each file. If you schedule a foreground job, a message confirms the date. If you purge the actions in the background, you can schedule a job and determine how frequently to execute it. When you purge data, the system purges the action usage data in the Alert file location specified during configuration. Follow change management procedures prior to purging action logs. Procedure To purge action usage logs: 1. On the Configuration tab, navigate to Utilities > Purge Action usage. 2. In the Purge Records Older Than field, enter the first day for action logs to be retained. For example, if you want to purge files for the prior calendar year, enter January 1 of the current year. 3. Specify the Max. Records per File. 4. Select Foreground or Background execution. Successful foreground execution results in a message that the purge action usage completed successfully.

Manage Deletion Utilty


The Manage Deletion utility is used to obsolete systems and rules and the data associated with them. It includes the Delete Systems and Delete All Rules features.

Delete Systems
The Delete Systems feature allows you to delete an obsolete system and its related data from the RAR application. Using this feature affects the following entities: All alerts All user management reports and system-specific role and profile management reports All user violations and system-specific role and profile violations Data extraction data (if the connector is a legacy system connector) Function actions for selected systems Function permissions for selected systems Rules for the selected systems Selected systems (from the physical connector definition as well as logical and crosssystem definitions) User mapping

August 2010

65

Risk Analysis and Remediation Configuration Change History Caution Back-up the application data before executing Delete Systems. Use the Delete Systems feature in a pre-production environment only. All users must be logged off of the application while the deletion function is running because any locks on the database tables will prevent the deletion function from completing. Delete Systems will delete all users and their corresponding violations from the database, without regard to the system where a user account exists. This is necessary because RAR always treats a user as a single item, even if the user exists in multiple systems.

Delete All Rules


The Delete All Rules feature allows you to delete all the rules defined in the RAR application. This feature will delete all of the data present in the application, except for configuration and message data. The following entities are affected by this feature: All Alerts All Systems/Connectors (including physical systems, logical systemsand cross systems) All management reports All violations All users, roles, and profiles All variants Business processes Change history Critical roles Critical profiles

Caution Back-up the application data before executing Delete All Rules. Use the Delete Systems feature in a pre-production environment only. All users must be logged off of the application while the deletion function is running because any locks on the database tables will prevent the deletion function from completing. Before performing any operation after executing the Delete All Rules feature, do the following: Recreate the rules Perform full user, role, and profile synchronization Run full sync Batch Risk Analysis with Management report. Otherwise, Risk Analysis and Remediation may not function properly.

Configuration Change History


RAR tracks configuration changes. You can use Configuration Change History to search for the change history for specific areas.

66

August 2010

Risk Analysis and Remediation Configuration Change History

Procedure
1. Log on to RAR. Select the Configuration tab. In the left navigation pane, select Configuration Change History -> Search. The Configuration Change History screen appears. The following search fields are available:. Area: The configuration area, such as Risk Analysis, Mitigation Controls, Workflow, and so on. Field: Values in the Field drop down list display based on the Area. Object ID, Job ID, or System: There will be a field called Object ID which will be used to filter based on a particular object instance. e.g. for Area Connectors and Field Connection Type we can further filter based on Object ID QF6CLNT400 which is the actual connector id. Same is the case with Data Extractor. Object ID will support ranges and wildcards. Use Start Date End Date 2. Select your search parameters and choose Execute. The Configuration Change History Results screen appears. The following table lists the area and available values:

Area Risk Analysis

Field < Select Value> All Batch Size for User Synchronization Consider Org Rules Convert users, roles and profiles to upper case Default report type for risk analysis Default risk level for risk analysis Default rule set for risk analysis Default user type for risk analysis Enable Offline Risk Analysis Exclude Expired Users Exclude Locked Users Exclude Mitigated Risks Ignore Critical Roles & Profiles Include Reference User when doing User Analysis Include Role/Profile Mitigating Controls in User Analysis Number of Background Job Worker Threads Number of Web Service Worker Threads RFC Timeout for Web Services / Background Job Worker Threads (Minutes) Send email notification to the monitor of the updated mitigated object Show All Objects in Risk Analysis Show Composite Role in User Analysis Show Selection Criteria

August 2010

67

Risk Analysis and Remediation Configuration Change History

Mitigating Controls Workflow

Miscellaneous

Connectors

Logical Systems

Use SoD Supplementary Table for Analysis <Select Value> Mitigating Controls <Select Value > All Mitigating Control Maintenance Risk Maintenance Workflow Service URL <Select Value> All Alert Log File Name and Location Background Job Spool File Location Default Logger Parameter Default Management Report Violation Count Enable Function Change Log Enable Risk Change Log Frequency in seconds of Background Job Daemon FTP Site Location FTP Site Password FTP Site User Name Maximum Display Lines For Print Preview SAP Application Server Location <Select Value> All Connection Type JCO Destination Outbound Connection Report Name SAP Gateway System System Name System Type Unicode System <Select Value> All Logical System Description System <Select Value> All Cross System Description System <Select Value> System

Cross Systems

Master User Source

68

August 2010

Risk Analysis and Remediation

Rule Upload

Background Job

Utilities

Data Extractor

<Select Value> All Business Process File Location Function Function BP Risk Risk Description Rule Set File Location Rule Set Mapping System & Function Action System & Function Permission <Select Value> All Comment Object Type Object Value From Object Value To Status System <Select Value> All Export Import File Location Purge Records Older Than Max. Records per File <Select Value> All Object Data Extraction Mode File Name File Type Delimiter

Risk Terminator
Risk Terminator is a service that resides in the back-end SAP ERP system to notify you when a risk violation occurs. Risk Terminator options are disabled by default. To enable them, configure Risk Terminator according to your requirements. You can configure Risk Terminator to take action when risk violations occur while: Adding transactions to a role with PFCG Assigning user roles with PFCG Assigning roles or profiles with SU01 Assigning roles or profiles with SU10

August 2010

69

Risk Analysis and Remediation Risk Terminator Risk Terminator performs risk analysis using the default rule set defined in Risk Analysis and Remediation configuration. Activities Determine which SAP operations to analyze with Risk Terminator. Proceed with configuring Risk Terminator.

Configuring Risk Terminator Parameters


Procedure To set the Risk Terminator configuration parameters: 1. Log on to the back-end ABAP system where security administration is to take place. 2. Start transaction SM59, and create a TCP/IP RFC connection for the RFC Destination of your system. For Connection Type, enter T for Start an external program with TCP/IP. For Activation Type, enter Registration. For Registration Program ID, enter GRCRTTOCC5X. For Security Options SNC, enter Inactive.

3. Save the RFC Destination. You can perform a test to confirm that the adapter was successfully enabled by logging into the back-end system and executing transaction SM59. Double-click the TCP/IP Connection created, and click Test Connection. 4. Start transaction /VIRSA/ZRTCNFG, and use the following table to set the parameters. Risk Terminator Configuration Parameters Parameter Select the CC release to be used RFC destination for release CC5.X PFCG Plug in Purpose Tells Risk Terminator what version of Risk Analysis and Remediation is used for the SoD rules. References the RFC connection. Determines behavior at role creation or change with PFCG. Determines behavior at role assignment with PFCG. Determines behavior at role assignment with SU01. Determines behavior at role assignment to multiple users with SU10. Setting Set to CC5.X

Enter the name of the RFC destination created previously in transaction SM59. To have Risk Terminator checked when creating or changing roles with PFCG, set this parameter to Yes. To have Risk Terminator checked when assigning a role to a user with PFCG, set this parameter to Yes. To have Risk Terminator checked when assigning a role to a user with SU01, set this parameter to Yes. To have Risk Terminator checked when assigning roles to multiple users with SU10, set this parameter to Yes.

PFCG User Assignment Plug-In SU01 Role Assignment Plug-In SU10 Multiple User Role Assignment

70

August 2010

Risk Analysis and Remediation Additional Configuration Options

Risk Terminator Configuration Parameters Parameter Stop Generation Comments are Required Purpose Stops generation if service detects that a violation exists. Determines whether comments are required when the service detects a violation. Setting To allow role generation and user assignments with SoD violations, set this parameter to No. To force the system to prompt you to enter comments for any SoD violations found when you use transactions PFCG, SU01, or SU10 to generate roles or to make user assignments, set this parameter to Yes. To view comments, see the Log Report. Send Notification Determines whether to send notification when service detects a violation. Sending notification from Risk Terminator is only valid in the 4.0 release; the function is not used in SAP GRC Access Control 5.3. Therefore, set this option to No. Background: In SAP GRC Access Control 5.3 we expect that companies will send notifications from Compliant User Provisioning and Enterprise Role Management rather than from Risk Terminator.

Default Analysis Level

Specifies the type of analysis Risk Terminator performs when you click the Change Authorization Data button on the PFCG Authorizations tab.

This setting determines the level of SoD violations to be reported by Risk Terminator. If you select Object Level Analysis, Risk Terminator reports object (permission)level violations. The report form includes an option to perform action-level analysis and an option to toggle the analysis-level setting each time you generate a report.

Additional Configuration Options


Administration for RTA Supported Systems
Real Time Agents (RTAs) are required for real-time communication between Access Control and the back-end system. RTAs are also provided for some non-SAP systems. Agents are available from the GRC software download area of SAP Service Marketplace. To request access to them, open a CSS message. Installation guides for these agents are packaged with the software.

Administration for Non-RTA Supported Systems


You can load user and role data from non-RTA supported (legacy) systems into Risk Analysis and Remediation and include it in risk analysis. To do this, you must export the data from the legacy system and upload it to Risk Analysis and Remediation. You can create or update functions by using the Rule Architect feature in Risk Analysis and Remediation with the legacy actions. These functions are for monitoring rules, which includes legacy actions.

August 2010

71

Risk Analysis and Remediation Additional Configuration Options

Before extracting data from your legacy system, read SAP Note 1131003, which includes tips on using a control file to facilitate the loading of multiple files, how to calculate for extracted files, loading of data files, and using the Comparison Utility tool. Perform these tasks only to include legacy systems in analysis operations. Tasks include creating extractor definitions, user and role mapping, and scheduling background jobs. To have data included in the analysis, you must extract data from the relevant systems and it must be in tab-delimited text files in the format specified in Appendix B: Data Mapping Templates. After creation, and then periodically thereafter, place the files on an application server in a specific folder structure for uploading to Risk Analysis and Remediation. For more information, see the section Initial Setup for Non-RTA Supported Systems. Since many systems do not store deleted users or dates of last change, a utility compares the new data files against records in Access Control. It determines users and roles that were added, deleted, or updated since the last file extract. After the comparison utility job is complete, it creates a new file, which contains only incremental changes. For more information, see the following sections: Initial Setup Create a Connector for a non-RTA System Analyze and Create Rules Data Extraction Schedule Batch Risk Analysis

Initial Setup for Non-RTA Supported Systems


Use this information to create extractor definitions to upload user and role data from systems not supported by RTAs. You can perform Risk Analysis against users and roles for these systems. Procedure 1. Create files as defined in the Appendix B: Data Mapping Templates. 2. Identify tables and fields in the legacy system that provide the information required for completing Risk Analysis. 3. Create spreadsheets of the data to be uploaded into Risk Analysis and Remediation. 4. Follow the templates exactly. 5. Create three folders for each legacy system on the file server, and name them IN, OUT, and EXP. The Comparison Utility background job requires these folders. Example \\servername\legacysystemfoldername\IN\ \\servername\legacysystemfoldername\OUT\ \\servername\legacysystemfoldername\EXP\ 6. Log on to Risk Analysis and Remediation as an administrator. 7. Create a connector for each legacy system. 8. Define the connector path as the path of the OUT folder created above. 9. Extract data from the legacy system.

72

August 2010

Risk Analysis and Remediation Additional Configuration Options 10. Analyze and create system-specific rules. 11. Run Data Extractor to upload initial data. 12. After loading the initial data, periodically run the Comparison Utility to load changes. 13. Schedule Batch Risk Analysis to populate management reports. Do not include legacy systems when executing the User/Role/Profile Synchronization. Only include systems that are connected to systems with an RTA in the User/Role/Profile Synchronization.

Create a Connector for a Non-RTA Systems


Use this information to create a connector for a system not supported by RTAs. You must create a connector for each non-RTA system. Procedure To create a connector for non-RTA supported systems: Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. The Create Connector screen appears. 1. In the System field, enter an identifier of the non-RTA system. 2. In the System Name field, enter the name of the system. 3. In the System Type dropdown menu, select Legacy. 4. In the Connection Type dropdown menu, select File-Local. 5. In the Location field, enter the full path of where the definition files are stored and reference the OUT folder. Verify there is a backlash (\) at the end of the file name. 6. In the User ID and Password fields, enter your logon credentials. 7. Click Save.

Extracting Data from the Legacy System


The file integration method requires you to generate and create files from systems not supported by RTAs (legacy systems) with the user and role authorization data. Before doing this, understand the legacy system methodology and map it to the security model of the SAP system. In SAP, you define roles to contain transactions and authorization objects for actions. You then assign roles to users. You can then map it to the layout required in Risk Analysis and Remediation. The following table maps the methodology of a legacy system to that of SAP. This mapping ensures that the data loading is in an accurate format. Risk Analysis and Remediation Name User Action Permission Field Role Profile SAP Name User ID Transaction Authorization Object Auth Object Field Role Profile Legacy Name (non-RTA system) User ID Screen Variable Not Used Grouping Not Used

August 2010

73

Risk Analysis and Remediation Additional Configuration Options After completing the mapping, extract the definition files from your legacy system in the proper format. These files contain information about user IDs and their associated roles. Extracting data from your legacy system can be a difficult process because you need correct data from the security structure. You may need to create a custom program in your legacy system to extract the data. The extraction process is not a one-time process but rather a periodic one. Make sure that you can repeat the extraction process for updating Risk Analysis and Remediation.

Data Mapping for Non-RTA Supported Systems


Extract six to eleven key files from your legacy system for analysis. The actual number of files depends on the security structure of your legacy system. When extracting these definition files; store them in the OUT folder you created for the connector. The following definition file information is based on the Data Mapping Template: File Name Target Definition User File (Required) Description This file includes user master information such as ID, name, email address, department, and user group. This file contains a list of user IDs and the corresponding actions that they access in the legacy system. It is important that you map the actions that you extract to your defined rules. Otherwise, Risk Analysis and Remediation will not report results correctly. User Permission File (Optional) This file contains data similar to the authorization objects in SAP. It is optional because the file depends on the security structure of your legacy system. If there is no permission concept associated with the actions in the legacy application, there is no reason to load this data. However, this file is required if permissions do exist and your rules include permission checks. Role File Target Definition (Optional) This file contains role IDs and names. A role is a grouping of actions. In some cases, actions are assigned to users with no concept of roles in the legacy application. If so, then there is no reason to create this file. However, if the legacy application groups the actions into a repository, then you must load these roles. Role Action File Target Definition This file identifies the actions for each role. The role ID in this file must be consistent with the role ID in the User Action File. The actions in this file must also match the action IDs that are used in creating roles. Role Permission File (Optional) This file is similar to the User Permission File. If your legacy system does not use permissions, this file is not required.

Target Definition User Action File (Required)

74

August 2010

Risk Analysis and Remediation Additional Configuration Options

Profile File Target Definition (Optional)

This file contains the Profile ID and user name. A profile is a grouping of actions. In some legacy applications, there are no profiles. Instead, actions are directly assigned to users. In this is the case, then this file is not required.

Profile Action File Target Definition (Optional) Profile Permission File (Optional)

This file identifies the actions for each profile. Like the Role Permission File, if your legacy system does not have permissions, this file is not required. However, if you do use it, make sure that you translate your legacy system security model to SAP terminology. This table contains the relationship of actions to permissions. Risk Analysis and Remediation uses this data when new actions are loaded into rules or when simulation analysis occurs. Depending on how often your master data changes, you should reload this data. This table is comparable to transaction SU24 (Table USOBT_C) in SAP.

Action Permission Objects

Description File for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File)

This table contains data for action and permission descriptions. It is comparable to table, TSTCT. Depending on how often your master data changes, you can reload this data.

For the Action Permission Objects file and Description File for Action, Permission Fields, and Values file, you need to upload the text to Risk Analysis and Remediation. This step must be completed before building your rules.

Upload Objects to Risk Analysis and Remediation


Use this information to upload objects from Action Permission Objects file and Description File for Action and Permission Fields, and Values. These are tables that contain action and permission objects from your legacy system that you need before building your rules in Risk Analysis and Remediation. For Action Permission File, upload the objects using Auth Objects mode, whereas for Description File for Action, Permission Fields, and Values use the Text Objects mode. In the steps below, the Text Objects mode is used as an example; however the procedure is similar for the Auth Objects mode. Procedure To upload objects: 1. Go to Risk Analysis and Remediation > Configuration tab > Upload Objects > Text Objects. The Text Objects Upload screen appears. 2. In the System field, enter the identifier of the non-RTA system. For this, use the system ID you created for the connector.

August 2010

75

Risk Analysis and Remediation Additional Configuration Options 3. In the Local File field, enter the full path of the text file or click Browse to navigate to the file location. 4. In the Server File field, enter the full path of the text file, if necessary. Use either the Local File or the Server File, but do not use both.

5. If you want the object to be loaded in the foreground, click Foreground. Otherwise, click Background for the object to be loaded in the background.

Only legacy systems where authorizations are controlled down to a permission level require all nine files listed. Systems that have security controlled at an action level can skip the user permission, role permission, and profile permission files (files 3, 6, and 9). For more information about the referenced files, see Appendix B: Data Mapping Templates for Non-RTA Supported Systems.

Technical Requirements
This section provides the technical requirements for file generation from legacy systems for integration with Risk Analysis and Remediation. This information is based on the eleven files in the Data Mapping Template. You must ensure that your files meet the following criteria: No duplicate records. No blank fields or records at the end of the files. Follow the sorting instructions in the mapping document closely, since they can affect the loading. The column separator in all the files must be either a tab or a comma. Multiple user IDs must not exist in the user file for one system, although they can exist in the multiple systems. Some operating systems have file size limits, and data can be missed from the upload. For example, if your operating system limits file size to 2GB, SAP recommends that you store a maximum of 60,000 records in a file. If the data exceeds 60,000 records, create a control file and multiple load files. You can use the Data Extractor to manage all files in the control file for data upload. The Control file contains the creation date in the first line. List all the individual file names, starting on the second line. In the data extractor, if you provide the control file name as the tab-delimited file name, Access Control uses the control file to retrieve each file by uploading them one-by-one. (This is an information record only. You can leave it blank.)

The USERID field in file 2 (Target Definition User Action file) and the ROLE field in file 5 (Role Action File Target Definition) can have multiple values. However, the combination of USERID, ROLE, ACTIONFROM, and ACTIONTO fields must be unique. For more information about the referenced files, see Appendix B: Data Mapping Templates for Non-RTA Supported Systems. The data extractor must generate the PRMGRP field in numerical sequence by USERID or ROLE and PERMISSION. The system does not allow duplicates of this combination.

76

August 2010

Risk Analysis and Remediation Additional Configuration Options

Analyze and Create Rules


Prerequisite Understand the security methodology of your legacy system before you begin creating rules. If you already have Risk Analysis and Remediation deployed in your organization, you have probably defined the functions and risks during the implementation. Therefore, you are not required to create new functions or risks, but rather add the security data from your legacy system to the existing functions. To ensure a complete analysis of your security methodology, evaluate all actions used in production by end users. Determine which actions allow the end user to perform functions that are defined in Risk Analysis and Remediation. Once an action is associated with a function, you can then add this action to the function with a reference to your legacy system.

Add Action to Function


Use this information to modify an existing function by adding an action with a reference to your legacy system. Procedure To search and modify a function: 1. Go to Risk Analysis and Remediation > Rule Architect tab > Search. The Search Functions screen appears. 2. Use the fields in this screen to filter your results. Click Search. Restrict your search with filters or search terms, otherwise the search returns all existing functions. All functions that meet your search criteria appear in the Search Results pane. Select the function to modify. 3. Click Change. The Change Functions screen appears. There is an Actions tab and Permissions tab. 4. In the Scope of Analysis field, make sure that the function has the correct setting. This setting affects how rules are built for risks with that function. You can only set Single System or Cross System at the functional level and not at the risk level. A function with a scope analysis of Single System indicates that any rule that you create is only for a single system. For example, you can have 10 systems under a function, but the function can still be a single system function. A function with a scope analysis of Cross System allows this function to be used in cross system risks and cross system rules to be built where applicable. If you set a function to Cross System, then the system generates rules across other systems for all risks that have that associated function. Only set a function to Cross System when there are conflicting actions across the systems. Risk Analysis and Remediation limits the risks to 46,656 total rules. If you have a function with thousands of actions, and it is set to Cross System, the number of rules created for that risk can be very large.

5. In the Actions tab, click the

icon. A new row appears in the table.

6. In the System column, use the menu to select the connector created for the non-RTA system. 7. In the Action column, enter the action name from your legacy system.

August 2010

77

Risk Analysis and Remediation Additional Tabs 8. Make sure that the action has the status of Enable. 9. Click Save.

Scheduling Batch Risk Analysis


Updating management reports for a legacy system is similar to updating reports for a connected system. The major difference is that management reports are based on the data uploaded and are not dependent on a connection to a legacy system. With a legacy system, you cannot run a synchronization job, which is required for a connected system. The data extraction is performing the data synchronization. Also, since the data extraction overwrites the data in the database, there are no dates that show changes. The data is overwritten. For this reason, only perform full batch risk analysis. Do not run incremental batch risk analysis for a system that has data loaded through Data Extraction. Procedure To schedule batch risk analysis: 1. Go to Risk Analysis and Remediation > Configuration tab > Background Job > Schedule Analysis. The User/Role/Profile Synchronization and Batch Risk Analysis screen appears. 2. From the Batch Risk Analysis pane, select Full Sync in the Batch Mode dropdown menu. 3. Enable the User Analysis checkbox. 4. In the Systems field, enter Legacy. 5. Enable the Management Reports checkbox. Schedule individual jobs for User Analysis, Role Analysis, and Profile Analysis (as opposed to doing them all at one time). Select the Management Report checkbox for each job.

6. Click Schedule. The Schedule Risk Analysis Background Job screen appears. 7. In the Job Name field, enter the name for this job. 8. Click either Immediate Start or Delayed Start. For Delayed Start, enter the desired start date and time. 9. To schedule this job to run periodically, click Schedule Periodically. 10. Choose either Daily, Weekly, or Monthly and enter the number of times you want the job to run for that period. 11. In the End Date field, enter a date to end the job. You can use the Calendar icon to enter the date. 12. Click Schedule. Otherwise, click Reset.

Additional Tabs
Informer Tab
Risk Analysis and Remediation provides detailed compliance analysis and enforcement for companies of all sizes. It allows you to examine your ERP system and to implement internal controls. The data gathered in each analysis is made available for viewing in a range of predefined and customizable reports. You can access these reports through the Informer tab.

78

August 2010

Risk Analysis and Remediation Additional Tabs You can generate reports for users, user groups, roles, profiles, HR objects, and organizational levels. Each option on the Informer tabs navigation bar represents a different report. Informer tab report types include: Management View: Summarized results with interactive displays. Risk Analysis: Risk analysis of users, roles, profiles, HR objects, and users at an organizational level. Analyzes where risks are contained, assigned, and mitigated. Audit Reports: Query rules, critical actions, critical roles/profiles, and mitigating controls. Security Reports: Query security information for users, roles, profiles, and action usage. Background Job: Reports generated by background jobs.

For more information, see the SAP GRC Access Control 5.3 Application Help on the SAP Help Portal at http://help.sap.com/grc/ ->Access Control -> SAP GRC Access Control 5.3.

Rule Architect Tab


The Rule Architect tab defines the rules that drive Risk Analysis and Remediation. It provides utilities to import and export definitions, view changes to functions or risks, and define and view: Rules Business Processes Rule Sets Functions Risks Critical Roles Critical Profiles Organizational Rules Supplementary Rules

August 2010

79

Risk Analysis and Remediation Additional Tabs

Importing Rules
You use the Import Rules utility to import rules. Navigate to Rule Architect -> Import Rules. You have two radio button options: Replace rule by system If you choose this option, then all rule data are deleted and replaced by the imported data Importing rules by system is common for customers who want to import system-specific data, one at a time. Replace rules for all systems If you choose this option, then the system-specific data are replaced for systems specified in the import. This includes Actions or Permissions, Critical Role, Critical Profile, Supplemental Rule, and Action and Permission Rules. The system-independent data are also replaced: Rule Set, Risks, Business Process, Functions, and Organization Rule. For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/grc/ -> Access Control -> SAP GRC Access Control 5.3.

Mitigation Tab
The Mitigation tab mitigates risks that cannot be removed by modifying access. This includes maintaining the following types of data manually or with export/import utilities and using the data to mitigate users, roles, profiles, HR Objects, or users at organizational levels. Mitigating Controls Administrators Business Units Control Monitors

For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Alert Monitor Tab


The Alert Monitor tab defines how alerts are generated and cleared for: Conflicting Actions Critical Actions Controls

For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

80

August 2010

Superuser Privilege Management Initial Configuration in the Back-end ABAP System

4. Superuser Privilege Management


Initial Configuration in the Back-end ABAP System
To set up Superuser Privilege Management, you must perform the following initial configuration steps in the back-end ABAP system before you execute the log report: Define a remote function call (RFC). An RFC is required each time a Firefighter ID logs on and creates a new session. Schedule a background job. The background job monitors the use of Firefighter IDs and records logon events and transaction use. Set configuration parameters. Configuration parameters define role-based and ID-based activities, mail preferences, and report preferences. For more information, see the following sections: Remote Function Calls Defining the Background Job for Log Reports Configuration Parameters To prevent users from logging on to Firefighter IDs directly, follow the instructions in SAP Note 992200 Firefighter User Exit. For more information about the delivered SPM roles and authorizations, see the SAP BusinessObjects Access Control 5.3 Security Guide.

Remote Function Calls


You configure a remote function call (RFC) destination to call an RFC-enabled function module. Superuser Privilege Management uses this RFC each time a Firefighter ID logs on and creates a new session. Recommendation SAP recommends that you use the three-character SAP system ID as the default RFC destination. If you create a new RFC destination, make sure that the name is basic and does not contain user or security information. Procedure To define and configure the RFC in the SAP backend system: 1. Use transaction SM59 or work with your BASIS administrator. 2. Click ABAP Connection. 3. Click on the Create icon or F8. 4. In the RFC Destination field, enter the system ID. 5. Click the Save icon or control S.

August 2010

81

Superuser Privilege Management Initial Configuration in the Back-end ABAP System 6. When you have created the RFC, enter the RFC name in the Configuration Parameter table and save it. The RFC name must be all upper case letters. For more information, see the section Configuration Parameters.

Default Roles for ABAP


Superuser Privilege Management is delivered with user roles as defined in the SAP GRC Security Guide. There is a delivered, default role (/VIRSA/FF_DEFAULT_ROLE) for the system ID that performs background jobs in the ABAP system. You can use the default role as provided. If you choose to customize the role, ensure that it has the following authorization values: ABAP Objects and Authorization Values Object S_RFC Definition Authorization check for RFC access ACTVT Authorization Values ACTVT = 16 RFC_NAME/VIRSA/FF_UTIL_RPT /VIRSA/ZVFAT, BAPT RFC1 SDIF SDIFRUNTIME, SDTX SUSR SUUS SU_USER SYST SYSU RFC_TYPE = FUGR 16 * *

S_DEVELOP

ZVFAT_0001 ACTVT ZVFAT_0002 /VIRSA/FAT

For more information about the delivered SPM roles such asVFAT_ROLE_CONTROLLER, and others, see the SAP BusinessObjects Access Control 5.3 Security Guide.

Assigning Default Role to Firefighter ID


In order for a user to access the capabilities of Superuser Privilege Management, you must assign the default role, /VIRSA/Z_VFAT_FIREFIGHTER to the Firefighter ID. Procedure To assign a default role to a Firefighter ID: 1. Run transaction SU01. 2. Enter the user ID you wish to assign the role. 3. In the Maintain User screen, click on the Role tab. 4. Enter the role, /VIRSA/Z_VFAT_FIREFIGHTER. 5. Enter dates in the Valid From and Valid To fields for validity of the assigned role. 6. Click the Save icon or control S.

Defining the Background Job for Log Reports


1. Run transaction SM36. 2. Enter a job name. For example: /VIRSA/ZVFATBAK

82

August 2010

Superuser Privilege Management Initial Configuration in the Back-end ABAP System 3. Enter a job Class. SAP recommends the highest priority setting. 4. Specify a Target Server (optional). 5. Click Start Condition. 6. Click Immediate. 7. Select Periodic Job. 8. Select Period Values, and specify a time interval. SAP recommends running this background job hourly. 9. Click Save. 10. Click Step. 11. Select the ABAP application. 12. Run /VIRSA/ZVFATBAK. 13. Enter a Variant if you are scheduling a job with a time period that differs from hourly. 14. Click Save. 15. Click Save again to save the background job. The default variant time period is one hour and two minutes. If you schedule the job to run hourly, it gathers data from the last hour and two minutes to ensure that the job logs are complete If you schedule the job to run in a period other than hourly, you must create a variant with the same period to ensure that the logs are complete

For more information about defining background jobs and troubleshooting, see SAP Note 1039144.

You may also need to provide additional authorizations for the users allowed to use the Firefighter IDs. For more information, see SAP Note 1319031.

Configuration Parameters
The configuration parameters specify the handling or behavior of log information, critical transactions, roles, and IDs. The following table describes each parameter. Configuration Parameter Behavior Parameter Name Remote Function Call Definition Superuser Privilege Management requires an RFC destination to log on. Behavior Enter the RFC destination that you created with transaction SM59.

August 2010

83

Superuser Privilege Management Initial Configuration in the Back-end ABAP System

Configuration Parameter Behavior Parameter Name Retrieve Change Log Definition Specifies the amount of change log information you capture when the background job executes. Superuser Privilege Management captures two log levels: a transaction log and the SAP change log. It captures the transaction level information from the STAT Data and the change log information from the CDHDR/CDPOS tables. Superuser Privilege Management reports critical transaction use in the log for the following cases: - You are using Risk Analysis and Remediation to maintain critical transactions there, and - Risk Analysis and Remediation and Superuser Privilege Management reside on the same server. If both these conditions are met, you can configure Superuser Privilege Management to use the Risk Analysis and Remediation data rather than duplicate maintenance. Assign FF Roles Instead of FF IDs This parameter switches the interface from Firefighter IDbased administration to Firefighter role-based administration. This parameter is in effect only when the Assign FF Roles Instead of FF IDs parameter is set to Yes. It determines the assignment length, in days, of Firefighter roles, but it can be over-ridden at the time of role assignment. To use Firefighter IDs, set this parameter to No (default). To use Firefighter roles, set this parameter to Yes. If a From date is specified in the Firefighter dashboard, the To date is incremented by this number of days. If you do not specify a From date, it defaults to the current date. The To date increments by this number of days. If you assign valid From and To dates to a Firefighter, these dates override the dates in this parameter. Behavior To capture the transaction and the change log information, set this parameter to Yes. To capture only the transaction log information, set this parameter to No.

Critical Transaction Table from Compliance Calibrator (VRAT)

To use the critical transactions defined in Risk Analysis and Remediation, set this parameter to Yes. To use the critical transaction defined in Superuser Privilege Management, set this parameter to No.

Default Role Expiration in Days

84

August 2010

Superuser Privilege Management Initial Configuration in the Back-end ABAP System

Configuration Parameter Behavior Parameter Name Auto Archive Location Firefighter Owner Additional Authorization Definition Use this parameter to specify a folder for the Auto Archive feature. Each Superuser Privilege Management has a defined owner. This parameter overrides the defined owner privileges. Behavior Specify the folder location where archive files are stored. To allow only the defined owner of a Firefighter ID to view and assign the Firefighter ID, set this parameter to Yes. To allow any owner to view and assign that Firefighter ID, set this parameter to No. To make a comment mandatory, set this parameter to Yes. To make a comment optional, set this parameter to No.

Configuration Change Comment Required

This parameter makes a comment mandatory for changes to configuration. The comment will be provided in the Configuration Change Log Report. This parameter provides additional authorization to a controller.

Firefighter Controller Additional Authorization

To allow users to maintain controllers for those Firefighter IDs for which they are the owner or administrator, set this parameter to Yes. To allow any user to maintain controllers, set this parameter to No. To send a log report that contains only critical transactions to controllers, set this parameter to Yes. To send a log report that contains all transactions to controllers, set this parameter to No. To send an email to a controller with Firefighter log information, set this parameter to Yes. To send no log information to the controller, set this parameter to No.

Send Log Report with Critical Transactions Only

Use this parameter to send log reports with critical transactions to the controller as an email attachment.

Send Log Report Execution Notification

This parameter specifies whether log reports that contain information about Firefighter activity are emailed to controllers.

August 2010

85

Superuser Privilege Management Initial Configuration in the Back-end ABAP System

Configuration Parameter Behavior Parameter Name Send Log Report Execution Notification Immediately Definition This option specifies whether the log reports are sent to the controllers as soon as the background job (/VIRSA/ZVFATBAK) is executed or at a predefined date and time. If you want the job to run at different intervals, you must use an external scheduling tool. To enable this parameter, set the Send Log Report Execution Notification to Yes. Send Firefighter ID Logon Notification This option specifies whether to send a logon notification email to controllers with information about when a Firefighter session was started and by which user. To send an email to a controller with Firefighter logon information, set this parameter to Yes. To send no email with Firefighter logon information to a controller, set this parameter to No. To send an email to a controller with Firefighter ID logon information after each logon session, set this parameter to Yes. To schedule the /VIRSA/ZVFAT_LOG_NOTIFICAT ION report at regular intervals, set this parameter to No. Behavior To send log report email notifications to the controller inboxes as soon as the /VIRSA/ZVFATBAK job runs, set this parameter to Yes. If you plan to receive the job at regular intervals, schedule the job /VIRSA/ZVFAT_LOG_REPORT at regular intervals, and set this parameter to No.

Send Firefighter Login Notification Immediately

This option specifies whether the logon notifications are emailed to the controllers as soon as they are run or when they are scheduled.

Connector ID for Risk Analysis

This option checks for SoD violations for Risk Analysis and Remediation.

Enter the connector ID of the Risk Analysis and Remediation capability. See the section, Defining Connectors for Risk Analysis and Remediation for connector ID information.

Configuring a Parameter
The administrator must configure and maintain configuration parameters. Superuser Privilege Management is not shipped with configured parameters. Procedure To configure the parameters:

86

August 2010

Superuser Privilege Management Initial Configuration in the Back-end ABAP System 1. On the dashboard, click the Configuration tab. 2. If the Parameter table is empty, click the SAP List icon to see a list of parameters. 3. Select a parameter. 4. Use the information in the Configuration Parameters section, and enter a value in the Configuration Parameter Value list.

Configuring SAPconnect Administration (SCOT)


You must configure the SMTP node in the transaction SCOT to enable SPM to send emails to firefighter users. 1. Logon to the application back-end.

2. Open transaction SCOT. 3. Click Create. 4. Follow the prompts and enter the information for your mail server. For more information, see the SAP Library for SAP NetWeaver 7.0 on the SAP Help Portal at http://help.sap.com.

Configuring Users for E-mails


You configure email messages the same way for both ID-based and role-based administration. To enable a user for email, set the following configuration parameters for email notifications on the Configuration tab. Send Firefighter ID Logon Notification Send Firefighter Login Notification Immediately Send Log Report Execution Notification Send Log Report Execution Notification Immediately

You must also set the controller's Usage Flag Information field in the Controllers table to Email or Workflow. To receive log email messages, ensure that you run the /VIRSA/ZVFATBAK report before you submit the /VIRSA/ZVFAT_LOG_REPORT.

Reason Codes
Reason codes describe each task that a Firefighter expects to perform. For example, a reason code might be a technical support case number. The reason code must be clear so that the Firefighter understands the task that it represents. To enable users to search or filter the Reason and Activity report, or the Log Report by reason code, the reason code status must be set to active. Activities Both administrators and users use reason codes: The Superuser Privilege Management administrator defines reason codes in a table. The user selects a reason code from a dropdown list on the dashboard.

August 2010

87

Superuser Privilege Management Defining Connectors for Superuser Privilege Management

Creating a Reason Code


Procedure To create a reason code: 1. Click the Reason Code tab on the administrator's dashboard tool bar. The reason code table appears. 2. Click New Entries. 3. In the Reason Code column, enter the reason code. This code relates to the description. For example, if the description is a technical support issue, the reason code might be the case number for this issue. 4. To describe the reason code, enter text in the Description field. A good description supplements the reason code and helps avoid misunderstandings 5. Click Save.

Defining Connectors for Superuser Privilege Management


You use the Superuser Privilege Management connector to access web-based reports. To do this, you must first create a URL using the following format: http://<servername>:<port>/webdynpro/dispatcher/sapgrc/ffappcomp/Fir efighter This allows you to create a connector to the relevant back-end SAP system. You must create a connector for each SAP system where you want to enable web-based reporting. Access Control communicates with multiple systems. SAP recommends using HTTPS communication protocol for secure communication. To interface with other Access Control capabilities, ensure that the connector names are the same in each capability.

You must also create a connector to establish a connection between Superuser Privilege Management and Risk Analysis and Remediation when both capabilities are not installed on the same system. For Superuser Privilege Management to interface properly with Risk Analysis and Remediation, follow the instructions in SAP Note 1055976 - Firefighter 5.2 - Unable to run the SoD analysis report. To ensure that the connector works properly, verify that you have the following authorizations for S_RFC and SVFAT_0001. The BASIS Security Administrator creates a role using the authorization objects in this table. The role is assigned to a user ID, which is used when creating a connector. Make sure that the authorization objects fields and values are configured appropriately. See the SAP GRC Access Control 5.3 Security Guide in SAP Service Marketplace for more information. Authorizations for S_RFC Field Value

88

August 2010

Superuser Privilege Management Defining Connectors for Superuser Privilege Management

Authorizations for S_RFC Field ACTVT RFC_NAME Value 16 /VIRSA/*FF*, BAPT, RFC1, SDIF, SDTX, SUSR, SUUS, SU_USER, SYST, SYSU, SDIFRUNTIME

RFC_TYPE FUGR

Authorizations for ZFAT_0001 Field ACTVT Value *

Creating a Connector to View Reports


Procedure To create a connector to view reports: 1. Using the URL supplied by your administrator, log on to Superuser Privilege Management end user toolbox. 2. Click the Configuration tab. 3. Select Create. The Create Connector form appears. 4. In the Connector ID field, enter the name of the connector. 5. In the Description field, enter a detailed description of the system. 6. In the Application Server field, enter the host name or IP address of the SAP server where Superuser Privilege Management is installed and the system you are connecting to. You can obtain this information from the SAPGUI logon pad. 7. In the System Number field, enter the number that identifies the system. 8. In the Client field, enter the number that identifies the client. This information can be obtained from the SAPGUI logon pad. 9. In the User ID field, enter the user ID used to log on to the SAP server. 10. In the Password field, enter the SAP User ID password. 11. Click Create. If you receive an error when you save the connector, verify that your password contains eight characters.

Deleting a Connector
Procedure To delete a connector: 1. Using the URL supplied by your administrator, log on to the Superuser Privilege Management administration dashboard. 2. Navigate to Configuration > Connectors. 3. On the Connector screen, click Search.

August 2010

89

Superuser Privilege Management Defining Connectors for Superuser Privilege Management 4. On the Search Connectors screen, enter the Connector ID and Description. 5. Click Search. If you click Search and do not enter a connector ID or description, a complete list of all available connectors displays. 6. Highlight the connector you want to delete, and click Delete.

Editing a Connector
Procedure To edit a connector: 1. Using the URL supplied by your administrator, log on to the Superuser Privilege Management front-end toolbox. 2. Navigate to Configuration > Connectors. 3. On the Connector screen, click Search. 4. On the Search Connectors screen, enter the Connector ID and Description. 5. Click Search. If you click Search and do not enter a connector ID or a description, a list of all available connectors appears. 6. Highlight the connector you want to edit and click Change. 7. On the Change Connector screen, enter new information in the fields, as needed. 8. Click Save.

Searching for a Connector


Procedure To search for a connector: 1. Using the URL supplied by your administrator, log on to the Superuser Privilege Management toolbox. 2. Click the Connector tab. 3. In the left navigation bar, click Search. 4. On the Search Connectors form, enter the Connector ID and Description. 5. Click Search. The Search Results screen displays the following results: Connector Field Connector ID Connector Description Application Server Description Name of the connector. Description for the connector. The host name or IP address of the SAP server where Superuser Privilege Management is installed and the system you are connecting to. You obtain this information from the SAPGUI Logon pad.

90

August 2010

Superuser Privilege Management Archived Data for Log Reports

Connector Field System Number Client

Description The system identification number. The number that identifies the client. You obtain this number from the SAPGUI Logon screen.

Archived Data for Log Reports


This section describes actions that are performed through your back-end system. You can use the Archive menu to view both the ID-based and role-based log reports as a download or as an archive. Superuser Privilege Management saves data in three text files, each of which archive different log data: Session log (SLOG) files Transaction log (TLOG) files Change log (CLOG) files

You can customize the log report by deleting data. You can also upload reports that you have previously downloaded. The Download button on the ID-based log report downloads the SLOG, TLOG, and CLOG files as one consolidated file. You must perform any changes to the downloaded file manually.

SLOG Files
Files that end with SLOG store Firefighter ID logon events. Each row in the spreadsheet records a Firefighter ID logon event. The column headings are: Firefighter ID, Firefighter, Session Date, Session Time, Reason, and Activity. SLOG files display the Session Time column as a number. To display the value as clock time, format the column in a time format. SLOG files are not available in the role-based report.

TLOG Files
Files that end with TLOG store transaction type records. Each row in the spreadsheet is the Transaction Type record for the corresponding row in the SLOG table. The column headings are: Firefighter ID, Transaction Date, Transaction Time, Server Name, Transaction Code, Report Name, and Report Title. TLOG files display the Transaction Time column as a number. To display the value as clock time, format the column in a time format.

CLOG Files
Files that end with CLOG store transaction change records. The column headings are: Firefighter ID, Firefighter, Session Date, Session Time, Object ID, Transaction Data, Transaction Time, Transaction Code, Table Name, Field Name, Field Description, Change Indicator, Old Value, New Value, and Change Document Number.

August 2010

91

Superuser Privilege Management Archived Data for Log Reports

The CLOG file displays the Transaction Time column as a number. To display the value as clock time, format the column in a time format.

Archiving the Log Report


Procedure To download the log report: 1. On the Administration navigation bar, navigate to Archive > Delete/Download Log. 2. To download a specified section or duration for the report, enter a date range or a range of Firefighter IDs. If you leave these text fields blank, Superuser Privilege Management downloads all logon events in the report. 3. Select the Download checkbox. 4. Click Execute. 5. In the confirmation dialog box, click Yes.

Automatic Archiving the Log Report


You can schedule a background job to automatically archive the Session Log, Transaction Log, and Change Log in Superuser Privilege Management from the SAP backend system. Procedure To automatically archive log reports: 1. Log on to your SAP back-end system. 2. Start transaction /VIRSA/FFARCHIVE. The Superuser Privilege Management Log Data Archive screen appears. The Application Server File field is automatically populated with a location. You can enter a different location if desired. 3. On the Archive Log Data tab, select one of the following options: Archive Log Data If you select this option, all the session, transaction, and change logs are archived. Delete Log Data after Archive If you select this option, the three logs are deleted from Superuser Privilege Management after they have been archived. Upload Log Data If you select this option, archived log data is uploaded to Superuser Privilege Management. 4. Define how you want to perform the archiving: If you click Background Job, the background job scheduler appears and you can define the date and time you want to schedule the job. If you click F8 or Execute, the archiving runs in the foreground.

92

August 2010

Compliant User Provisioning Prior to Configuration

5. Compliant User Provisioning


Compliant User Provisioning simplifies the provisioning of access to system users. You can use it to assign user roles to new users and to change role assignments for existing users. Fundamentally, Compliant User Provisioning executes workflows to collect the information and approvals necessary to grant access to system users. Once deployed, the workflows manage each provisioning requests by tracking its progress through the different stages and by gathering the necessary approvals. At the end of the workflow, the request has all the approvals required to provision access for a user. Compliant User Provisioning then passes the collected information to the user or department responsible for the provisioning, or automatically uses a remote function call to launch the actual provisioning process.

Prior to Configuration
Before you configure Compliant User Provisioning, you must complete the installation process. This includes the software installation and certain one-time configuration procedures, such as creating the initial administrative user and importing roles. For more information, see the SAP GRC Access Control 5.3 Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3. Integration To ensure that your installation is complete: Ensure that you have applied all real time agents (RTAs) have been applied to all Compliant User Provisioning systems. Choose the authentication system and ensure that all necessary user accounts exist. Verify that all directories have the correct permissions.

Activities When you have configured Compliant User Provisioning, you are ready to begin modeling your provisioning processes. Compliant User Provisioning uses workflows to replicate or model the provisioning process, and to collect the information necessary to carry out a provisioning request. The process for creating workflows is straightforward if you know in advance: What steps a specific provisioning process contains Who is required to approve that access

It is easier to create the workflow if you know the provisioning process you want to reflect before you create the workflow. For more information, see the section Managing Workflows. Preparing to create workflows requires some research. Typically, you build a profile or spreadsheet of each provisioning process for which you want to create a workflow. After you have completed a profile that details each step of the process, you can create and deploy a workflow that implements that process. The information in a provisioning process includes:

Provisioning Process Information

August 2010

93

Compliant User Provisioning Basic Functionality

Provisioning Process Information What specific condition initiates the request?

Description Each workflow follows a different path, specific to the role(s) requested. To ensure that the request process follows the correct path, each workflow begins with a unique and specific condition. The condition often depends on the roles requested but might also depend on the department, the business unit to which the user belongs, or other criteria. You must identify the details of the condition that calls each workflow.

How many levels of approval Each organization has unique requirements for how many people must approve a user access request. In addition, some does the request require? user roles might require only one or two approvers, while others might require three or more. This typically depends on the nature and sensitivity of the requested user role. For each of your provisioning processes, make a note of how many levels of approval are required. For each level of approval, For each step in the process, determine who is responsible for who is authorized to approve approving or denying a request. This can be an individual user the request? or, in some cases, any one of a group of users. What happens if any of the Determine what action must be taken if a designated approver assigned approvers chooses denies the request. This can include steps to mitigate risk, to provision only the approved portion of the request, or to abort to deny the request? the provisioning process entirely. What happens if any of the assigned approvers fail to respond to the request within a specified period of time? Is a partial approval acceptable for the request? In the event that the request is ultimately approved, should Compliant User Provisioning automatically initiate provisioning? To expedite the provisioning process, set a limit for how long an approver has to approve or deny a request. You must also decide what must happen to the request if an approver does not act within the specified period. If a request includes more than one user role, it is possible that one role in the request could be approved and another denied. Define what must happen in that situation. Compliant User Provisioning does not actually perform the provisioning process. Completing a workflow assembles the information and approvals necessary for provisioning. However, you can set a workflow to start the provisioning process. Depending on how your organization prefers to conduct provisioning, you might need to determine whether or not to automatically begin provisioning when a request is approved.

You should capture all profile information for each provisioning process. Although this can be time-consuming, preparing provisioning profiles helps you avoid creating conflicts and simplifies the process of creating workflows.

Basic Functionality
You can classify functionality into three basic categories: Creating requests Performing risk analysis Approving/denying requests

94

August 2010

Compliant User Provisioning Key Concepts Administration

Creating requests and approving/denying requests are requestor/approver functions. Compliant User Provisioning supports these functions by providing a Web-based interface for requestors and interacting with approvers through email. This guide describes administration functions that enable you to create and deploy the workflows that manage the provisioning request process. Requestors and approvers follow predefined paths to assign user permissions. Administrators define those paths. As an administrator, you configure Compliant User Provisioning and use it to create and deploy workflows.

Key Concepts
To understand better the descriptions and procedures in this section, familiarize yourself with the following keys concepts, which are intrinsic to Compliant User Provisioning: Compliant User Provisioning Key Concepts Key Concept Description Provisioning Access When you provision access for a user, you enable that user to connect to a specific business module. That is, you allow a specific user account and password combination to log on to that module. In most cases, the access you grant to the user is restricted to the tasks that user must perform. It can also be restricted to certain systems or applications. Additionally, you use the provisioning process to change or remove a users access. In Compliant User Provisioning, the terms provisioning or provisioning access refer to the process of defining the modules and systems to which a user has access. Roles and Role Assignment Compliant User Provisioning supports provisioning for ERP systems in which user access is role-based. A role is a predefined set of access permissions. Access is not granted to individual users but rather to roles. If, for example, you want to provision access to a financial application for a user, you must assign that user a role that has access to the application. If the user has the required role, he or she automatically has access to the application. Since different users may need to access the same module or application but might also require different levels of access, there are typically multiple roles that include some form of access to any given application. The roles assigned to a user define which applications the user can access and the level of access the user has. Role assignment is the fundamental starting point for the provisioning process. A request defines a user and the role(s) to be assigned to the user. Risk Analysis The identification and mitigation of risk is a key element of provisioning. A and Mitigation risk is a conflict between roles assigned to a user. In most organizations, for example, the roles Receiving, Inventory, and Accounts Payable are mutually exclusive. To prevent the risk of fraud, a user responsible for cataloging deliveries cannot also have the ability to catalog inventory, nor can that user have the power to authorize payment for a delivery. Compliant User Provisioning lets you automatically review and evaluate, whether or not a request poses a risk of conflicting roles. This is risk analysis.

August 2010

95

Compliant User Provisioning Users

If analysis determines that a provisioning request poses a risk, you have several ways to mitigate the risk. Risk mitigation refers to the actions you take to lessen or remove an identified risk. When you define the provisioning process for a role, you can include risk mitigation options for some of your approvers. The approvers can then choose to take action to mitigate a risk or to deny the provisioning request. Workflow A workflow defines the steps required to approve the assignment of one or more roles to a specific user. The workflow catalogs the steps of the process and identifies the people required to approve the request. Workflows are intended to model the business processes your organization already has in place to authorize access. In practice, you may want to rethink your approval processes as you create your workflows (preferably beforehand). When you have created and deployed a workflow, other Compliant User Provisioning requestors and approvers use it to request access for other users. Request and Approval Administrators are responsible for creating workflows, but other users usually use the workflows. They do so by either making requests or by granting or denying approval. In Compliant User Provisioning, a request is an official message asking for access for a user (referred to as initiating a request), and the user who does this is the initiating requestor or requestor. A requestor is any authenticated user who initiates a request on their own behalf or on behalf of another user. Depending on your organization, you may be able to configure which types of access a person can request or whether or not they can select specific access types at all. After a user initiates a request, it must be approved. Request workflows are made up of one or more stages. At each stage, the request requires the approval of the user (approver) designated in the workflow for that stage.

Users
There are three types of user, each corresponding to a basic Compliant User Provisioning function: Compliant User Provisioning User Types User Requestor Description Requestors create provisioning requests, which ask for a specific user to be assigned to one or more user roles. Each request initiates a workflow, a process requesting approval of the role assignment from designated approvers. Approvers either approve or deny provisioning requests. Compliant User Provisioning interacts with approvers through email. At each stage of a workflow, users are designated as the approvers for that stage, and those users receive an approval email generated by Compliant User Provisioning. The email includes two links, one to approve the request, and one to deny it. The approver clicks the link to either approve or deny.

Approver

96

August 2010

Compliant User Provisioning Administration Tasks

Compliant User Provisioning User Types User Description

Administrator Administrators create and deploy workflows. These workflows are designed to follow the organizational path for assigning roles to a user. Administrators are responsible for ensuring that the workflows they create accurately reflect the correct process, designating the correct approvers, and achieving the correct provisioning result. Each of these users must be assigned the appropriate role(s) in the User Management Engine (UME), and the roles determine who has the authority to act in which capacity. For example, only users with the requestor role can create new requests; only users with the administrator role can create and deploy workflows.

Administration Tasks
When you are sure that Compliant User Provisioning is correctly installed and you document the business processes your organization follows to provision user access, you are ready to perform administration tasks. These tasks fall into two categories: Configuring Compliant User Provisioning in preparation for creating and deploying workflows Workflow management, including creating, validating, modifying, deploying, and deleting workflows

The primary administration task is creating the workflows that implement the processes. As an administrator, you define the workflows used by the requestors and approvers. Workflows incorporate a great deal of information. Among other details, you can: Identify the request condition that initiates a specific workflow. Determine the approvers, the roles, and the permissions associated with each role. Define these details for each workflow as you create it.

It is more efficient, and your roles and permissions will be more consistent, if you define the details before you begin creating workflows. Prerequisites When you configure Compliant User Provisioning, you define the details that are the building blocks for workflows. Before you begin configuring or creating workflows, however, complete your preconfiguration responsibilities: Work with your business process owners to capture and record the approval requirements for each user role. Complete the preconfiguration tasks described in the next section.

Once you have completed these tasks, you can begin the configuration process setup.

Preconfiguration Tasks
Setting up Compliant User Provisioning involves configuring or defining connectors, data sources, security settings, Web services, and many other objects that you use when you create workflows.

August 2010

97

Compliant User Provisioning Preconfiguration Tasks Activities Complete the following configuration tasks prior to setting up your workflows. Step 1: Pre-Workflow Configuration Before using Compliant User Provisioning, you must create an environment for requestors and approvers. As an administrator, you must configure Compliant User Provisioning so it meets your business requirements. Gather all essential information prior to setting up Compliant User Provisioning. Complete the pre-workflow configuration tasks in the order listed below. After configuring the initial workflow, you can make additional changes in any order. Initializing System Data Defining Connectors Request Configuration Number Ranges Authentication Source for Requestors Defining Authentication Defining Multiple LDAP Authentication Configuring Risk Analysis Configuring Mitigation Defining End User Personalization Defining Support Screen information Defining Role Attributes Configuring Application Approvers Defining SMTP Server Identification

Step 2: Workflow Configuration Complete the workflow configuration tasks in the following order. Creating an Initiator Defining a Stage Creating Main Paths Adding Detours to a Main Path Defining Auto Provisioning

Step 3: Post-Workflow Configuration Complete the post-workflow configuration tasks in any order. Configuring a Service Level Configuring User Defaults Defining Password Self Service Setting Up Background Jobs Creating Custom Fields

98

August 2010

Compliant User Provisioning Preconfiguration Tasks Compliant User Provisioning modifies your configuration to reflect your current business model. However, it is important that you correctly configure it before using it in a production environment.

Initializing System Data - Initial Logon


After installing Compliant User Provisioning, use a Web browser to log on and access the application. To do so, enter either of the following URLs in your browser: The GRC Access Control launch pad works for approvers and administrators. When selecting Compliant User Provisioning from the launch pad, you bypass the Request Access screens and display the main screen within Compliant User Provisioning. The structure of the Access Control launchpad is:

http://<server_name>:<port_number>/webdynpro/dispatcher/sap.com/g rc~acappcomp/AC For any user who enters requests, use the direct Compliant User Provisioning URL:

http://<server_name>:<port number>/AE The server_name is the name of the application server on which SAP GRC Access Control resides, and the port_number is the assigned port number of the application server. (Contact your system administrator for the correct URL on your system.) When using the specified Compliant User Provisioning URL, the Compliant User Provisioning home screen is displayed. On this home screen, there are four options: Request Access

This option allows you to enter/submit access requests. When you select this option, the system displays the access request types configured for your system. When you select an access request type, the system prompts you to enter your user ID and password. Request Status

This option displays the list of open access requests you have submitted. Support This option displays your companys support Web site. User Logon

This option prompts you to log on to Compliant User Provisioning as an approver or an administrator to gain access to the My Work tab, the Informer reporting tab, and/or the Configuration tab. The access you gain to Compliant User Provisioning depends on the User Management Engine (UME) roles/permissions granted by your system administrator. All Compliant User Provisioning roles are defined in the UME. UME administration rights are required to assign Compliant User Provisioning roles.

Initializing System Data - Required User Management Engine Roles/Permissions


To gain access to Compliant User Provisioning, you must make role assignments in the User Management Engine (UME). The UME is the SAP Security tool for managing access to SAP NetWeaver applications.

August 2010

99

Compliant User Provisioning Initialization System Data When defining Compliant User Provisioning roles, define the UME roles with the permissions that you would like each user to have. Approvers may have different permissions based on their responsibilities. For example, some approvers can create mitigating controls from within Compliant User Provisioning, but some cannot. Requestors do not need specific UME permissions to create a request, although depending on the configuration settings, they may need to exist in the Authentication System. For more information, see the section Authentication Source for Requestors. All other users (approvers and administration users) must be assigned specific UME permissions to access Compliant User Provisioning through the User Logon option. On the SAP NetWeaver Server Index Screen, click User Management to create roles and assign them to users. The following are the roles that Compliant User Provisioning provides: AEAdmin AEApprover AESecurity

Roles are provided with the installation files and must be uploaded into the User Management Engine during the installation process. For more information, see the SAP GRC 5.3 Access Control Security Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3.

Initialization System Data


Before you begin configuring Compliant User Provisioning, you must import initial system data. This data is the default system data that is prepackaged with the system. It is the minimum set of data required for the application to function properly and is imported directly from the application itself. Import initial data only if it was not done during the post-installation phase of the SAP GRC Access Control installation process. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides > SAP BusinessObjects -> I -> Access Control -> SAP GRC Access Control 5.3.

Procedure 1. On the Configuration tab, navigate to Initial System Data. The Initialize DB screen appears. 2. Click Browse. 3. Navigate to the directory containing the Compliant User Provisioning installation files. 4. In the Browse window, double-click the appropriate XML file. There are three options for import. Each delivered initial load file will specify how to load. Insert

100

August 2010

Compliant User Provisioning Configuration Tasks Append Clean and Insert AE_init_append_data.xml Select append. You must import this file if you configured CUP to use RAR. AE_init_append_data_ForSODUARReview.xml Select append. AE_init_clean_and_insert_data.xml Select clean and insert.

5. The files you import are:

This step is required only for new installations or if you want to reload the default data originally shipped with Compliant User Provisioning.

6. Click Import.

Configuration Tasks
Integrating with the System Landscape Directory (SLD)
Integration with SLD allows for scenarios where the SAP back-end system and the Access Control server are on different networks. Connection data is maintained only once in SLD and can be shared across Compliant User Provisioning, Superuser Privilege Management, and Enterprise Role Management. When the information changes, it is changed only once in SLD and not multiple times in each capability. SLD integration also allows for Secure Network Communication (SNC). Using the SNC interface and the SAP cryptographic library, all connector communication can be encrypted. This enables you to protect password transmission from Compliant User Provisioning to SAP back-end systems. For more information about SLD, see the SAP Help Portal at http://help.sap.com.

Defining Connectors for Compliant User Provisioning


After installing Compliant User Provisioning, you must configure the interactions with the appropriate back-end systems via connectors. This is essential to provision approved users to the back-end systems. Compliant User Provisioning supports several connector types for the back-end systems. Access Control communicates with multiple systems. SAP recommends using HTTPS communication protocol for secure communication. For more information about configuring a connector for an identity management (IDM) system, see section Integrating with an Identity Management Solution. Features Connectors facilitate the transfer of data between Compliant User Provisioning and SAP systems, non-SAP systems, SAP Enterprise Portal, LDAP, and other systems. By configuring

August 2010

101

Compliant User Provisioning Configuration Tasks the connectors, you specify how Compliant User Provisioning communicates with these backend systems. Compliant User Provisioning supports multiple data sources where you can define data sources including their sequence order for extracting data. The supported multiple data source includes the following system types: SAP SAPHR LDAP JDE (JD Edwards) SAPEP (SAP Enterprise Portal) ORAAPPS (Oracle Applications) PEOPLESOFT

For more information on multiple data source, see the section User Data Source Definition. For multiple LDAPs, Compliant User Provisioning supports: Microsoft Active Directory Sun Microsystems SunOne Novell E-Directory IBM Tivoli Any other LDAP supported in NetWeaver

Defining Connectors for SAP


Procedure To define connectors for SAP systems: 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select SAP. Any field name denoted with an asterisk (*) is required. To complete the Connectors screen, obtain the connection information from your network administrator and BASIS administrator. 3. In the Name field, enter a name for the connector. The connector names are important when integrating with other GRC products and the CUA. Make sure that the connector name for Access Control is the same as the one configured for CUA. 4. In the User ID field, enter the user ID you are configuring to have access to the backend system. The user ID must have the security access to perform the tasks required. If provisioning is configured for this connector, this user ID must have authorization access to maintain users in the SAP system. If provisioning is

102

August 2010

Compliant User Provisioning Configuration Tasks configured, this user ID appears on each change record on the SU01 user master record. For more information on user ID authorization, see the SAP GRC 5.3 Access Control Security Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3. See also the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/grc/ ->Access Control -> SAP GRC Access Control 5.3. Ensure that the user ID associated with this name has the access to view and maintain the SU01 user records. 5. In the Password field, enter the specified password for the SAP user ID. 6. In the System Language field, enter the language for the system. The BASIS administrator provides this information. 7. In the Message Server Name, enter the name of the message server, which is used for load balancing of your SAP clustered environment. 8. In the Message Server Group, enter the Logon Group name to which the message server belongs. Your BASIS administrator provides this information. 9. In the Message Server Host, enter the host name of your message server. Your BASIS administrator provides this information. 10. In the SAP Version dropdown menu, select the appropriate SAP version. Compliant User Provisioning supports SAP 4.6C, 4.7, and ECC 6.0. In the HR System dropdown menu, select Yes or No to indicate if an SAP HR system is used or not. An HR system flag indicates whether the SAPHR module is installed on this connector, not necessarily whether you are using the SAPHR module. If the system is an HR system, the appropriate HR RTAs must be installed. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3. 11. In the SLD Connector checkbox, select this checkbox to enable the Standard Landscape Directory. For more information, see Integrating with System Landscape Directory. 12. In the Connector Category dropdown menu, select the category to which the connector belongs. Possible values are Production, Non-Production, or Other. This selection is used to classify the servers into categories on the Access Request forms. 13. In the Role dropdown menu, select whether or not role information comes from Enterprise Role Management or the SAP backend. 14. In the HR Manager Path dropdown menu, do the following: a. If you are using SAPHR as the user details data source and want the Manager field value to be automatically populated from the users HR record, set this field to (B012) Managers. b. If you want the Reports to line value to be automatically populated from the users HR record, set this field to (A002) Reports (line) to (for organizational units).

August 2010

103

Compliant User Provisioning Configuration Tasks

SAP HR provides an organizational structure view that contains the object, relationships, and attributes. The organizational structure view contains the relationship types, B012-Managers and A002- Reports to. 15. In the Password Self-service dropdown menu, select whether or not the password self-service feature is enabled for the connector. 16. Click Create. 17. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector.

Defining Connectors for SAP Enterprise Portal


Before you begin configuring for the SAP Enterprise Portal connector, check that the Service Provisioning Markup Language (SPML) service on SAP Enterprise Portal is configured on the portal server. Use the following URL in the browser: http://<server-name>:<port>/spml/spmlservice Make sure that the Web browser shows a page with the following message: SPML Provider successfully installed and configured Prerequisites for Provisioning SAP UME User Groups, UME Roles, AND SAP EP Roles You have a technical installation of SAP Enterprise Portal on the SAP NetWeaver instance of the UME system. You have installed AC 5.3 SAP Enterprise Portal RTA on the SAP NetWeaver instance of the UME system. Note SAP Enterprise Portal configuration is not required. Procedure To define connectors for SAP Enterprise Portal systems: 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select SAP EP. The Connectors screen appears. Any field name denoted with an asterisk (*) is required. To complete the Connectors screen, obtain the connection information from your network administrator and BASIS administrator. 3. Enter all required information. 4. In the Web Service URI field, enter the URI address of the Web service of the application server.

104

August 2010

Compliant User Provisioning Configuration Tasks

Obtain the Web service URI address during the installation process of the RTA for the specific application server. The Web service must be exposed in the application server side to establish communication links with Access Control. 5. In the User ID field, enter the user ID of a portal RTA user for this connection. This user must have the appropriate role to perform this technical configuration. Assign the role, pcd:portal_content/administrator/super_admin/super_admin_role to the RTA user. 6. In the System Language field, enter the native system language for the application server. For example, use En_US for US. 7. In the Connector Category dropdown menu, select Production, Non-Production, or Other connector type. This selection helps classify the servers into the appropriate categories in the Access Request forms. 8. In the Password Self-service dropdown menu, select whether or not the password self-service feature is enabled for the connector. 9. In the Parameter pane, a table appears for you to map Parameter Names to Parameter Values. The parameter value pair mapping is specific to the application server. Parameter Names ASSIGN_GROUPS:OC ASSIGN_ROLES:OC CHANGE_USER:OC CREATE_USER:OC CREATE_USER:password DELETE_USER:OC LOCK_USER:OC LOCK_USER:islocked RESET_PASSWORD:OC RESET_PASSWORD:password ROLESEARCH_URI ROLESEARCH_URI_USERNAME ROLESEARCH_URI_PASSWORD ROLE_DATA_SOURCE SCHEMA_ID UNLOCK_USER:OC UNLOCK_USER:islocked Parameter Values sapgroup saprole sapuser sapuser password sapuser sapuser true sapuser password http://<server>:<port>/UserRoleSearchForAESe rvice_5_3/Config1?wsdl&style=document username password ROLE.UME_ROLE_PERSISTENCE.un: SAPprincipals Sapuser false

August 2010

105

Compliant User Provisioning Configuration Tasks

Parameter Names USER_DATA_SOURCE

Parameter Values Portal UME connected to R/3: USER_DATA_USER.R3_DATASOURCE. Portal UME connected to LDAP: USER.CORP_LDAP. Portal using local UME: USER.PRIVATE_DATASOURCE.un:

Note: For the parameters above, the periods (.) and colons (:) are part of the values and are mandatory. 10. Click the Add icon to add more parameter value pair mapping.

Note You must include the following parameters and values. If they are not present, add them:

Recommendation For asynchronous requests to an IDM system, map the parameter value pair in the connector definition: PROV_CALL = async. When mapping parameter value pairs, you may have to define the user name and password for role search service in the provisioning action. This mapping is different from the user ID and password that you set in the Connectors screen. 11. Click Create. 12. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector. If your connector does not have a RTA installed, you do not need to test the connection, because the connection occurs between the two systems through Compliant User Provisioning. For information about configuring provisioning for SAP UME user groups, UME roles, and SAP Enterprise Portal roles, see Field Mapping for SAP Enterprise Portal.

106

August 2010

Compliant User Provisioning Configuration Tasks

Defining Connectors for Oracle Applications, JD Edwards, PeopleSoft, and Others


Procedure The following steps are applicable for Oracle Applications, JD Edwards, PeopleSoft, and Others with the following exceptions: For RTA information for Oracle Applications, JD Edwards, and PeopleSoft, see the Greenlight Adapter documentation. For Others connector type, you can connect to a system that supports SPML 1.0 or not. 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select either ORAAPPS, JD Edwards, PEOPLESOFT, or Others. The Connectors screen appears. Any field name denoted with an asterisk (*) is a mandatory field. To complete the Connectors screen, obtain the connection information from your network administrator and ERP Security administrator. 3. In the Name field, enter the application server connector name. 4. In the Short Description field, enter a short description of the connector. 5. In the Description field, enter a description of the new application server connector. 6. In the Web Service URI field, enter the URI address of the Web service of the application server. For more information on RTA information for specific application servers, see the Greenlight Adapter documentation. 7. In the User ID field, enter the user name to access this connection. 8. In the Password field, enter the password to access this connection. 9. In the System Language field, enter the native system language for the application server. For example, use En_US for US. 10. In the Connector Category dropdown menu, select Production, Non-Production, or Other connector type. This selection helps classify the servers into the appropriate categories in the Access Request forms. 11. In the Password Self-service dropdown menu, select whether or not the password self-service feature is enabled for the connector. 12. In the Parameter pane, a table to map Parameter Names to Parameter Values appears. The parameter value pair mapping is specific to the application server. The mapping of parameter values is the actual Web service for the provisioning action. To complete the mapping of parameter value pairs, obtain the connection information from your network administrator and ERP Security administrator. During the mapping of parameter value pairs, you may have to define the user name and password for role search service in the provisioning action. This mapping is different from the user ID and password that you set on the Connectors screen. 13. Click the Add icon to add more parameter value pair mappings.

August 2010

107

Compliant User Provisioning Configuration Tasks Recommendation For more information on ERP-specific connection parameters, see the Greenlight Adapter documentation. 14. Click Create. 15. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector. If your connector does not have a RTA installed, you do not need to test the connection. It is not needed because the connection occurs between the two systems through Compliant User Provisioning. In general, the Others connector type is used in the following cases: The other system, such as a legacy system, is used to manually provision user access (no auto-provisioning). In this case, the legacy system does not have an RTA installed; therefore, you do not test the connection. The other system supports SPML 1.0, which allows auto-provisioning. You must test the connection.

Defining Connectors for LDAP


The steps below are generic for LDAP connectors. For information on configuring connectors for Microsoft Active Directory, SUN Microsystems SUNONE, Novell EDirectory, and IBM Tivoli see Configuring LDAP Connector in Compliant User Provisioning of GRC Access Control on SAP Community Network at http://sdn.sap.com. Procedure To define connectors for LDAP systems: 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select LDAP. The Connectors LDAP screen appears. Any field name denoted with an asterisk (*) is a mandatory field. To complete the LDAP Connectors screen, obtain the connection information from your network administrator and BASIS administrator. 3. In the Name field, enter the LDAP connector name. This LDAP name appears in Compliant User Provisioning. It is a virtual name for your system. The connector names are very important when integrating to other GRC products. The system names for all connectors must be the same. 4. In the Short Description field, enter a short description of the connector. This description appears for the users to select. 5. In the Description field, enter the description of the new LDAP connector. 6. In the Server Name field, enter the name of the LDAP server.

108

August 2010

Compliant User Provisioning Configuration Tasks 7. In the Domain field, enter the location of the LDAP root. The LDAP root is where Compliant User Provisioning binds to. 8. In the Port field, enter the number of the LDAP port. 9. In the User Principle Name field, enter user name to access this connection. Ensure that the user ID associated with this name has the access to view the LDAP user directory. 10. In the Password field, enter the password to access this connection. 11. In the User Path field, enter the directory path specific for the user. 12. In the Group Path, enter the directory path specific for the group. 13. In the LDAP Type dropdown menu, select the appropriate LDAP type. 14. In the Password Encryption dropdown menu, select the type of encryption to apply to the connector password. 15. In the Connector Category dropdown menu, select a Production or Non-Production type. This selection is used to help classify the servers into the appropriate categories in the Access Request forms. 16. Click Create. 17. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector. If your connector does not have a RTA installed, you do not need to test the connection, because the connection occurs between the two systems through Compliant User Provisioning.

Defining Connectors for Verification/Training System


You can connect to your training system to implement and verify that users have completed the required training program before requesting roles, privileges, and the like. In general, you select the Verification/Training System connector type when your organization requires users to participate in a training program. Once the user completes the training program, you can verify that the user has successfully performed the prescribed tasks. For example, before assigning a role to a user, you can verify that the user is competent in creating an access request. Procedure To define connectors for verification/training systems: 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select Verification/Training System. The Connectors screen appears. Any field name denoted with an asterisk (*) is a mandatory field. To complete the Connectors screen, obtain the connection information from your network administrator and system administrator. 3. In the Name field, enter the application server connector name.

August 2010

109

Compliant User Provisioning Configuration Tasks 4. In the Short Description field, enter a short description of the connector. 5. In the Description field, enter a description of the new application server connector. 6. In the Web Service URI field, enter the URI address of the Web service of the application server. For an SAP system, you obtain the Web service URI address by going to SAP NetWeaver Web Application Server. Perform the following: a. Go to SAP NetWeaver Web Application Server Start Page > Web Service Navigator. Example: http://<server>:<port>/index.html b. Expand the appropriate Web Service folder. c. Click Document. d. Under the WSDL heading, right click on the URI address to copy as a shortcut. e. Paste this URI address in the Web Service URI field. For other systems, make sure that the WSDL format is supported by Access Control. The Web service must be exposed to establish communications with Access Control. 7. In the User ID field, enter the user name to access this connection. 8. In the Password field, enter the password to access this connection. 9. In the System Language field, enter the native system language for the application server. For example, use En_US for US. 10. In the Connector Category dropdown menu, select Production, Non-Production, or Other connector type. This selection helps classify the servers into the appropriate categories in the Access Request forms. 11. In the Parameter pane, a table appears for you to map Parameter Names to Parameter Values. The parameter value pair mapping is specific to the application server. To complete the mapping of parameter value pairs, obtain the connection information from your network administrator and system administrator. However, most training systems do not require parameter value pair mapping. 12. Click the Add icon to add more parameter value pair mapping. 13. Click Create. 14. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector. If your connector does not have a RTA installed, you do not need to test the connection, because the connection occurs between the two systems through Compliant User Provisioning.

Viewing and Maintaining Available Connectors


You can view a list of the connectors configured to connect to back-end systems and change or delete them. To do this, select a connector name and click Change or Delete.

110

August 2010

Compliant User Provisioning User Data Source Definition If you select Change, the Connectors screen appears. You can edit and save any changes in the field values. If you select Delete, the system deletes the selected connection.

To ensure that the entered values are valid in establishing the successful connection, click Test Connection.

User Data Source Definition


Use the User Data Source option to increase the scope of SAP back-end systems that you configured in the Connectors screen. You define the primary source for extracting user data on the User Data Source screen. Mapping the data source allows Compliant User Provisioning to search for all users, managers, and approvers. However, keep in mind that this is not an authorization mechanism to check for existing users and managers. The data source that you map (such as LDAP, SAPHR, SAP, or SAPUME) also determines how certain types of data are handled through the assigned protocols and from specific systems. Therefore, once you select a user data source, you do not need to perform any additional configuration for mapping the user ID. Using UME as the User Data Source: The SAP UME is the most common data source to find user and approver data in an enterprise portal environment. UME is also used a data source by NetWeaver for other applications that are integrated into the SAP system. UME is a central management repository for retrieving user data on SAP through Compliant User Provisioning. Using LDAP as the User Data Source: Using LDAP as the user data source is highly preferable, because LDAP is normally the first point of entry for users accessing the enterprise system. LDAPs generally contain as much information about the user as the SAP business system. If you set the User Detail Data Source to LDAP, the users manager listed on the LDAP record can automatically populate the request during the request creation. Using Multiple Data Sources as the User Details Data Source: When you select Multiple DataSources, the Multiple Datasources screen appears, and you can select the systems involved with the search. You can also order the sequence in which the data sources should be searched. The system searches the systems in the specified order until it finds the user ID and retrieves the users details from that system. For example, all employee user information can be fetched from SAP HR. However, part-time and contract personnel detail information exists in an LDAP system. In this case, you can configure Multiple Datasources with SAP HR and LDAP systems that fetch detail information for both employees and contractors.

Integration Compliant User Provisioning uses the Search Data Source group to extract data from the data source to return user-related search queries. The User Details Data Source group is used to get additional information about the user.

August 2010

111

Compliant User Provisioning User Data Source Definition

Configuring the User Data Source


Procedure To configure the user data source: 1. On the Configuration tab, navigate to User Data Source. The User Data Source screen appears. Each setting on this screen has its own save option. The Search Data Source and the Users Details Data Source do not have to be the same data source. The Search Data Source contains user-related information such as the user ID. The User Details Data Source contains additional user data such as phone number, e-mail address, manager, etc. 2. From the Data Source Type dropdown list, select a data source. Several possible data source types are available, including SAP, SAPHR, SAP UME, LDAP, SAP EP, as well as all of the non-SAP connectors, if an RTA is installed. 3. From the System Name dropdown list, select the system. 4. Click Save. 5. From the Details Source Type dropdown list, select the data source type. Several possible data source types are available, including SAP, SAPHR, SAP UME, LDAP, SAP EP, as well as all of the non-SAP connectors, if an RTA is installed, including a Multiple Data Source option. 6. From the System Name dropdown list, select the system. 7. Click Save. 8. From the Function Template dropdown list, select a custom or standard template. When you use SAP or SAPHR as the User Data Source, the additional field Function Template appears. If you select Custom from the Function Template dropdown list, the Function Template Name field appears. Enter a name for the custom template. Using SAP User Management Engine as the User Data Source: The User Management Engine is the most common data source to find user and approver data in an enterprise portal environment or when User Management Engine is used by SAP NetWeaver for other applications that are integrated into the SAP system. The User Management Engine is the central management repository for retrieving user data in SAP through Compliant User Provisioning. Using LDAP as the User Data Source: Using LDAP as the user data source is highly preferable, because LDAP is normally the first point of entry for users accessing the enterprise system. LDAPs generally contain as much information about the user as the SAP business system. If you set the User Detail Data Source to LDAP, the users manager listed on the LDAP record can automatically populate the request during the request creation. Using multiple data sources as the User Data Source: When you select Multiple Datasources, the Multiple Datasources screen appears. You can then select the systems to be searched and the order in which

112

August 2010

Compliant User Provisioning User Data Source Definition they are searched. The system searches the systems until it finds the user ID and retrieves the users details.

August 2010

113

Compliant User Provisioning Field Mapping

Field Mapping
You can map data fields in CUP to data fields in your ERP system.

Example You can map fields using Requestor FName from Access Request screen to the field Manager Fist Name in the SAP User Master Record screen in the SAP ERP system. The following standard fields are provided by Compliant User Provisioning and are used in the Create Request screen. These fields can be mapped to the SAP User Master Record screen in the back-end system: Accounting Number Business Area Company Cost Center Department Email Address Functional Area Job Location Manager Email Manager FName Manager ID Manager LName ManagerTelephone Org. Unit Personnel Number Position Request Category Request Reason Requestor Email Requestor FName Requestor ID Requestor LName Requestor Telephone SNC Telephone Number Unsecured SNC Logon User End Valid Date User FName User ID User LName User Start Valid Date

The field mapping you defined for the SAP, Enterprise Portal, and non-SAP systems are specific to the systems that you configured in the User Data Source option. The User Data Source option is where you configure one or many data source for searching and retrieving user detail information. For more information, see User Data Source Definition.

Communication Method is a custom field that is available for provisioning. You must create it as a custom field and map the field for provisioning. For more information, see Custom Fields and Field Mapping for Provisioning.

Field Mapping for Provisioning


Field mapping for provisioning is required if you create custom fields and want to pull from or push to a specific SAP User Master Record (using transaction SU01) field that is not delivered standard.

114

August 2010

Compliant User Provisioning Field Mapping Procedure 1. On the Configuration tab, navigate to Field Mapping > Provisioning The Field Mapping screen appears. 2. Enter all required information in the fields. 3. In the Default System pane, indicate if this system is a default by selecting the button. 4. Click Continue. In the AC Field pane, you can click the menu button to display the list of standard and custom attributes. In the Application Field pane, you can click the menu button to display the list of field names associated with the SAP User Master Record (using transaction, SU01). You can click the plus icon to add another attribute field. Otherwise, click the minus icon to remove an attribute. 5. Click Save.

Field Mapping for SAP Enterprise Portal


You use this procedure to enable provisioning for SAP UME user groups, UME roles, and SAP Enterprise Portal roles. Prerequisite You have configured the connector for the SAP Enterprise Portal. Procedure 1. Go to Compliant User Provisioning > Configuration tab > Field Mapping > Provisioning. The Field Mapping screen appears. 2. Click Create. 3. Enter all required information. 4. Select Connector Type field and choose SAP EP. 5. Click the Add icon to activate the dropdown menu for the Application field. Select the desired application connector defined for enterprise portal (EP). 6. Choose the Default System radio button if this is the default connector. 7. Click Continue. The field-mapping screen for AC Fields and Application Fields appears. 8. Add the following AC Fields and Applications fields: AC Field Email Address STANDARD Telephone Number STANDARD User FName STANDARD User ID STANDARD User LName - STANDARD 9. Click Save. Application Field email mobile firstname logonname lastname

August 2010

115

Compliant User Provisioning Field Mapping To import SAP UME groups, UME roles, and SAP EP roles, see Importing Roles. To provision for SAP UME groups, UME roles, and SAP EP roles, see the Access Control 5.3 Application Help.

LDAP Mapping
The LDAP Mapping option maps fields to corresponding fields in an LDAP database. In addition, you can add fields and then map them to attributes that already exist in your enterprises LDAP database by selecting those attributes on the Additional Fields screen.

The field mapping you defined for the LDAP directory is specific to the LDAP systems that you configured in the User Data Source option. The User Data Source option is where you configure one or many LDAP data source for searching and retrieving user detail information.

For more information about configuring user data source, see the section User Data Resource Definition.

The following standard fields are provided by Compliant User Provisioning and can be mapped to fields used in an LDAP directory: Manager Email Company Valid From Organization Employee Type Position Example You can map fields in an LDAP table using F_Field to the field FirstName_Field. Manager ID Administration Group Manager Last Name Functional Area Company Address LBL_SAP_User_ID Org. Unit Valid To Job Date Format Manager Last Name LBL_Locale

Creating Additional Fields for LDAP Mapping


To create additional fields for LDAP mapping: 1. Click the icon at the bottom of the Additional Fields screen.

2. A dropdown list and field becomes active in the AE Fields and LDAP Fields columns. 3. From the dropdown list in the AE Fields column, select a field name. 4. In the selected field in the LDAP Fields column, enter the name of the LDAP attribute to which you want to map. 5. Click Save.

Mapping an LDAP System


1. On the Configuration tab, navigate to LDAP Mapping.

116

August 2010

Compliant User Provisioning Field Mapping The LDAP Mapping screen appears. 2. From the System dropdown list, select the appropriate LDAP system. 3. Enter all required information. 4. For the following fields, enter information for the user on the LDAP system. This is the user you want to map with on the LDAP system. Employee ID First Name Last Name Email Department Telephone Object Class Location Location Country Manager

5. Click Save.

August 2010

117

Compliant User Provisioning Integrating CUP and RAR

Integrating CUP and RAR


You integrate Compliant User Provisioning with Risk Analysis and Remediation to enable risk analysis, mitigation, transaction usage, and other Risk Analysis and Remediation functions. Procedure To integrate for risk analysis and mitigation: 1. Retrieve URI for Risk Analysis Web service configuration. a. Go to SAP NetWeaver Web Application Server Start Page > Web Service Navigator. Example: http://<server>:<port>/index.html b. Expand VirsaCCRiskAnalysisService Web service. c. Click Document.

d. Right click on the URI address under the WSDL heading to copy as a shortcut. 2. Go to Compliant User Provisioning > Configuration tab > Risk Analysis. The Risk Analysis screen appears. 3. In the Select Analysis and Remediation Version pane, select 5.3 Web Service in the Version dropdown menu. 4. In the URI field, enter the Risk Analysis URI. You can paste in the copied shortcut you obtained in Step 1. 5. Enter a User Name and Password. 6. Click Save. 7. Configuring for Mitigation Integration. To do so, obtain the URI information for the following: Mitigation Risk Search Org. Rule Search Function Search

To obtain the URI information, perform the following steps for each Web service: a. Go to SAP NetWeaver Web Application Server Start Page > Web Service Navigator. Example: http://<server>:<port>/index.html b. Expand the following Web services to extract their respective URI: VisaCCMitigation5_0Service VirsaCCRisk5_0Service VirsaCCOrgRules5_3Service VirsaCCFunction5_0Service c. Click Document.

d. Right click on the URI address under the WSDL heading to copy as a shortcut. 8. Go to Compliant User Provisioning > Configuration tab > Mitigation. The Mitigation screen appears. 9. Select the Allow Approvers to Approve Access Despite any Conflicts checkbox.

118

August 2010

Compliant User Provisioning Request Configuration 10. In the Default Duration (Days) for the Mitigation Control, enter a number of days you want for the default duration. 11. In the Mitigation URI field, enter the address for the mitigation Web service. For example: http:// <server>:<port>/VirsaCCMitigation5_0Service/Config1?wsdl&style=document 12. In the Risk Search URI field, enter the address for the risk search Web service. For example: http:// <server>:<port>/VirsaCCRisk5_0Service/Config1?wsdl&style=document 13. In the Org. Rule Search URI field, enter the address for the organization rule search Web service. For example: http:// <server>:<port>/VirsaCCOrgRules5_3Service/Config1?wsdl&style=document 14. In the Function Search URI field, enter the address for the function search Web service. For example: http:// <server>:<port>/ VirsaCCFunction5_0Service/Config1?style=document 15. Click Save.

Request Configuration
The Request Configuration option customizes the Request screen. This means defining the fields that you want to appear. You can customize Request Types, create a new Request Category or Request Reason, and provide a range of values that appear when a user makes a new request. The Request Configuration screen provides Configuration tabs for request creations that you must define to meet the range of request cases in your system. These configuration values depend on your business requirements. The Request Configuration screen includes: Configuring Request Types Configuring Request Priorities Configuring Applications Configuring Employee Types

Request Type Configuration


The Request Type tab configures the request type(s) that a requestor chooses during the request process. The Request Type configuration specifies what actions are performed on the processing of that request. Features Request types determine the actions to be performed. Request types can be reference points for initializing a workflow. Compliant User Provisioning provides a standard set of request types. These standard request types represent actions that occur in the SAP back-end systems. You can modify and configure these standard request types during configuration. You can also create your own custom request types for your business needs. Request types can also be used as an attribute in the initiator/workflow selection process. The standard request types are: New Change Delete Lock

August 2010

119

Compliant User Provisioning Request Configuration Unlock

Example If the request type is New, it relates to the creation of a new account in the SAP backend system. The standard set of request types are loaded during the installation process from an XML basic configuration file. You can configure the Request Type for the request during the End User Personalization configuration. Configure this field with a default value and indicate whether it is mandatory, editable, and visible. You can also create your own custom request types, instead of using any of the delivered request types. Customized request types allows you to define the sequence of provisioning actions for a request. The following are examples of customized request types: Create, Assign Roles, and Lock Change and Lock Change and Unlock Example If you create a customized request type as Create and Lock, it relates to the creation of a new account in the SAP backend system with their role assignment and locking the account for a go-live scenario. You then can use the customized request type as an attribute in the Initiator/Workflow selection process.

Creating Request Types


Procedure 1. On the Configuration tab, navigate to Request Configuration > Request Type. The Request Configuration Request Type screen appears. 2. Click Create. The Create Request Type screen appears below the Request Type screen. Any field name with an asterisk (*) is required. 3. In the Type column, enter the request type. 4. In the Short Description field, enter a short description of the request type. The information in the Short Description field appears on dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. In the Description field, enter the full description of the new request type. 6. In the Sequence field, enter the sequence number. Assigning a sequence order value to request types defines the order in which request types appear on the Request Access screen.

120

August 2010

Compliant User Provisioning Request Configuration

If you assign the value 0, the request type does not appear on the Request Access screen. However, if the request type is active, it appears on the Request Type dropdown lists throughout Compliant User Provisioning. 7. From the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation and/or Enterprise Role Management and you have enabled the Workflow Types on the Miscellaneous screen. 8. To make the request type active, select the Active checkbox. 9. In the End User Description field, enter a description of the request type. The information you enter appears on the Request Access main screen, so requestors can select a specific request type. This description should contain information that is helpful to them when deciding which request type to use. 10. In the Select Actions window, select the actions to be performed during provisioning of this request type. On the left side of the screen, the Assigned Actions appear. These are the actions to be performed during provisioning. On the right side of the screen, the Available Actions appear. These are the actions that are available to be performed during provisioning. 11. When searching for Available Actions, enter the name of the action and click Go, or click Go for the entire list of actions. Available actions include: Create User create the user record during provisioning Change User change the user record during provisioning Delete User delete the user from the target system during provisioning Lock User lock the user in the target system during provisioning Unlock User unlock the user in the target system during provisioning Assign Roles assign roles to the user during provisioning Superuser Access give superuser access to the user during provisioning User Defaults action to apply user defaults to the user during provisioning These actions can be used in combination. 1. Select the desired action(s) to be performed, clicking the checkbox to the right of the desired action. 2. Click the left arrow (<) button to move the Available Action to the Assigned Action table. To remove an item from the Assigned Action table Click the right arrow (>) button, which adds it back to the Available Action table. 3. Click Save. Example If you select Create User, Lock User, and Assign Roles, the system creates the user in the target system, immediately locks the user ID, and assigns all approved roles

August 2010

121

Compliant User Provisioning Request Configuration listed in the request. If you select only Create User, the system creates the user ID in the target system and does not assign any roles. If you select User Defaults, the system applies the user defaults defined during the user default mapping process. If you do not select User Defaults, the system does not provision the defined user defaults. Customizing Request Types with Associated Actions Procedure To create a customized request type, use the same procedures as discussed in Creating Request Types. The following preconfigured actions are used to create a customized request type: Create User action to create New User without User Default Change User action to change user detail except User Default Delete User action to delete existing user Lock User action to lock existing user Unlock User action to unlock locked user Role Assignment action to assign and/or remove roles Superuser Access action to assign and/or remove superuser access User Defaults action to apply user defaults to the user during provisioning Example You can create a customized request type by using Create User and Lock User actions. In this case, the name of the custom request type is Create_Lock. This request type is for scenarios where you create a user, then lock the user account until a future event, such as a go-live launch or training class start date. At such time, the user must be unlocked by using the Unlock User request. Configuring with Superuser Access Action The Superuser Access action type allows users to create a Firefighter ID (FFID) in Superuser Privilege Management from Compliant User Provisioning. As a prerequisite, you must set up a connection between Compliant User Provisioning and an SAP system with Superuser Privilege Management. Specifically, ensure that the Firefighter Owners and Firefighter IDs are set up in the connected SAP back-end system before provisioning. For more information, see the section Configuring Connectors for SAP.

There are standard approver determinators for assigning the request to controllers and owners. You can use these approver determinators when configuring the stages of a workflow. In addition to user provisioning, you can also provision the appropriate firefighter role by configuring the default role for the Superuser Access request type. Risk analysis for Superuser Access is done during the creation of the Firefighter ID in Superuser Privilege Management. No risk analysis is done when processing a request for user access from Compliant User Provisioning.

122

August 2010

Compliant User Provisioning Request Priority Configuration Procedure To create a Firefighter ID (FFID) in Superuser Privilege Management from Compliant User Provisioning, use the same procedures as discussed in Creating Request Types. However, when selecting actions, use Superuser Access action type. 1. In the Available Actions, click Go. A list of actions appear. 2. Select Superuser Access action type. 3. Click the left arrow (<) button to move the Available Action to the Assigned Action table. 4. Click Save.

Changing a Request Type


Procedure 1. On the Request Configuration screen, select the request type you want to change. 2. Click Change to modify the selected request type. All the available, editable fields become active. 3. Make your modifications. The Request Type and Workflow Type fields are not editable. All other fields and values are editable. 4. Click Save.

Request Priority Configuration


You can create a priority for a request to determine how quickly a request is approved. Activities On the Priority tab, you can create and maintain priorities for request creation. The Priority option allows managers to oversee the processing functions of a specific organizational team responsible for requests and approvals. You can also use the priority as an attribute in the Initiator/Workflow selection process. When configuring the Priority attribute, remember it is a required field, which the requestor uses when defining the request. Therefore, this priority attribute affects the workflow by determining the time rate for the approval process. You can also use the Priority attribute to route a request to a group of approvers. Priority is configurable on the request through the End User Personalization configuration. Configure this field with a default value and whether it is mandatory, editable, and visible.

Creating a Request Priority


Procedure To create a request priority: 1. On the Configuration tab, navigate to Request Configuration > Priority. The Request Configuration Priority screen appears. 2. Click Create.

August 2010

123

Compliant User Provisioning Application Configuration The Create Priority screen appears below the Priority screen. Any field name denoted with an asterisk (*) indicates that it is required. 3. In the Priority field, enter the name of the new priority. 4. From the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with the Risk Analysis and Remediation and/or Enterprise Role Management capabilities and you have enabled the Workflow Types on the Miscellaneous screen. 5. In the Short Description field, enter a short description of the new priority. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a description for the new priority. 7. Click Save.

Changing or Deleting a Request Priority


Procedure To change a Request Priority: 1. On the Priority screen, select the priority you want to change. Click Change. The Modify Priority screen appears. All of the available, editable fields become active. 2. Make your modifications. The Priority and Workflow Type fields are not editable. All other fields and values are editable. 3. Click Save. Procedure To delete a Request Priority: 1. On the Priority screen, select the priority you want to delete, and then click Delete. Only priorities that have not been used in a request can be deleted. 2. Click Save.

Application Configuration
On the Application Configuration screen you can add selection options for non-connected systems, which appear as part of the Access Request approval process. The screen also lists all systems for which connectors have been defined (in a read-only mode). When you define an application, the requestor sees the application name and description when using the Search function to find available applications. Then, by selecting the application, the requestor can submit a request for a non-connected system. Provisioning for a non-SAP system is a manual process. Manual intervention is required in some approval stage of a workflow in order to fulfill the request. For example, when

124

August 2010

Compliant User Provisioning Employee Type Configuration requesting access to a non-SAP system, there can be an approval stage where the requestor needs network access. After the approver approves the request, the system administrator must physically create a network user ID for the requestor before the request can be closed.

Configuring an Application
Procedure To configure an application: 1. On the Configuration tab, navigate to Request Configuration > Application Configuration. The Request Configuration Application Configuration screen appears. 2. Click Create. The Create Application screen appears below the Application Configuration screen. Any field name denoted with an asterisk (*) is required. 3. In the Application field, enter the name of the new application. 4. In the Short Description field, enter a short description of the new application. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. In the Description field, enter a description for the new application. 6. In the System ID field, enter the system identification for the application. 7. In the Client field, enter the client ID for the application. 8. Click Save.

Changing an Application Configuration


Procedure 1. On the Application Configuration screen, select the application you want to change. 2. Click Change to modify the selected application. The Modify Application screen appears below the Application Configuration screen. 3. Make your changes. 4. Click Save.

Employee Type Configuration


The Employee Type Configuration tab defines an employment status for an end user. Features This feature sets up business rules that differentiate between employee types, such as fulltime and part-time employees or employees of Division A and Division B. You can also use the Employee Type field as an attribute in the Initiator/Workflow selection process. Another use of the Employee Type attribute is to track which end users are requesting access.

August 2010

125

Compliant User Provisioning Number Ranges After you configure an Employee Type, the name appears on a dropdown list on the Access Request screen. Employee Type is configurable on the request through the End User Personalization configuration. Configure this field with a default value and indicate whether it is mandatory, editable, and visible.

Configuring an Employee Type


Procedure To configure an employee type: 1. On the Configuration tab, navigate to Request Configuration > Employee Type Configuration. The Request Configuration Employee Type Configuration screen appears. 2. Click Create. 3. The Create Employee Type screen appears. 4. In the Employee Type field, enter the name of the new employee type. 5. In the Short Description field, enter a short description of the employee type. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a description for the new employee type. 7. Click Save.

Changing an Employee Type


Procedure 1. On the Employee Type Configuration screen, select the employee type you want to change. 2. Click Change to modify the selected employee type. 3. Make your changes. 4. Click Save.

Number Ranges
Requests in Compliant User Provisioning are identified through a system of distinct numbers. You use the Number Ranges option to define a range of unique request numbers. Compliant User Provisioning uses these numbers for invoices and identification. For example, you can configure a number range to reflect the month of April by setting your number range to 0401 to 0430.

126

August 2010

Compliant User Provisioning Authentication Source for Requestors

It is important to create multiple number ranges that correspond to your business requirements. However, make sure that individual ranges do not overlap. For example, do not have a number range of 1001000 and another number range of 500 2000. Only one number range can be active at a time. The system does not activate the number ranges automatically. You must activate the number range after it reaches its last invoice number.

Configuring Number Ranges


Procedure To configure the number ranges: 1. On the Configuration tab, navigate to Number Ranges. The Number Ranges screen appears. 2. Click Create. Two empty fields appear below the From Number and To Number columns. 3. In the From Number field, enter the starting number. 4. In the To Number field, enter the ending number. 5. Click Save. 6. Click the Match icon to activate the new number range. The next request number appears in the Current Number field.

Changing Number Ranges


Procedure 1. On the Number Ranges screen, select the range of numbers you want to change. 2. Click Change to modify the number range. The From Number and To Number fields become editable. 3. Make any changes to the number ranges. 4. Click Save.

Authentication Source for Requestors


The Authentication option verifies the requestors identity from the selected system. After you configure the Connectors and Authentication attributes, Compliant User Provisioning confirms the user ID and password the requestor uses during logon. The approver is always authenticated and authorized using SAP NetWeaver User Management Engine (UME). For users other than approvers, authentication and authorization system can be any system such as LDAP, SAPHR, SAP, and non-SAP systems. Do not confuse the authentication system with a user data source. Although the authentication system can be the same system as the user data source, each has separate functionality.

August 2010

127

Compliant User Provisioning Authentication Source for Requestors

For more information on user data source, see the section, User Data Source Definition in the guide.

Defining Authentication
Procedure The requestor of a request does not need any permission; therefore, requestors can be authenticated against any connection. To define authentication: 1. On the Configuration tab, navigate to Authentication. The Authentication System screen appears. 2. In the Authentication System field, select the authentication system from the dropdown list. The options include Multiple LDAP, SAP, SAP UME, JDE, SAP EP, LDAP, SAPHR, PEOPLESOFT, and ORAAPPS. 3. In the System Name field, select the system name from the dropdown list. These are the systems configured as Connectors. 4. Select the End User Verification Required checkbox to make the verification required. The End User Verification Required option is available for any non-SAP system (including LDAP authentication systems). It allows the requestor to log on without a password, if that requestors user ID is defined in the LDAP. 5. Click Save.

Defining Multiple LDAP Authentication


Procedure To define multiple-LDAP authentication: 1. On the Configuration tab, navigate to Authentication. The Authentication System screen appears. 2. From the Authentication System dropdown list, select MULTIPLE LDAP. Order the sequence of the LDAPs you want authenticated by clicking on the dropdown list and selecting a number from 1 to 9, where 1 is the highest, 9 is the lowest, and 0 deselects the LDAP. Compliant User Provisioning searches for LDAPs in the specified order to find the user ID and password. The search stops after it finds the first user ID match. Select the End User Verification Required checkbox to enable the verification of a user ID without requiring the user to enter a password. The system only verifies that the user ID exists in the data source. 3. Click Save.

128

August 2010

Compliant User Provisioning Risk Analysis

Risk Analysis
The Risk Analysis option selects the options for performing the actual risk analysis. You can identify the level of risk analysis and specify the Risk Analysis and Remediation version for processing risks.

Configuring Risk Analysis


Procedure 1. On the Configuration tab, navigate to Risk Analysis. The Risk Analysis screen appears. 2. Under Select Options, select the Default Analysis Type from the dropdown list. Use Transaction Level to find SoD conflicts at the action (transaction code) level. Use Object Level to find SoD conflicts at the permission level. 3. Select the Consider Mitigation Controls option to consider the mitigating controls while performing risk analysis. 4. Click Save. 5. Under Select Risk Analysis and Remediation Version, select the Version of Compliant User Provisioning used from the dropdown list. If you select 5.0 Web Service or later, three additional fields appear: URI, User Name, and Password. o For URI, identify the correct Web service URL by: a) Open a new browser session and navigate to the Web Application Server (http://<server>:50000/index.html) b) Click Web Services Navigator. The Web Services Navigator screen appears. c) Expand the VirsaCCRiskAnalysisService folder, and then click Document. The Web service URL is listed below the WSDL (Web Services Description Language) heading. d) Right-click Web Service URL and select Copy Shortcut from the context menu. e) Return to CUP Configuration Tab > Risk Analysis and paste the URL into the URI field. o For User Name and Password, enter the User Name and Password of your Web user that has been defined for communication between the Access Control capabilities. If you select 4.0, there is no need to connect to a URI address.

6. Select Perform Org Rule Analysis to perform organizational rule analysis at risk analysis time. This is only applicable if you have configured organizational rules in Risk Analysis and Remediation. If you have not configured organizational rules, do not choose this option. 7. Click Save. 8. Under Risk Analysis On Request Submission, select Yes or No from the Perform Risk Analysis On Request dropdown list to enable or disable the ability to perform risk analysis on submission of a request. 9. Click Save.

August 2010

129

Compliant User Provisioning Mitigation

Frequently Asked Questions


Question Can you choose the rule set to perform the risk analysis from Compliant User Provisioning? Can you identify which SoD risk criticality levels have been assessed for a request access? How does Compliant User Provisioning perform a risk analysis? Answer No. The default rule set is always used to perform risk analysis from Compliant User Provisioning. No. All risk levels are included in the risk analysis from Compliant User Provisioning. Compliant User Provisioning performs a risk analysis by using an EJB call or Web services. It first uses an EJB service call. If that fails, a Web service call is made. A successful EJB call is executed only when Compliant User Provisioning and Risk Analysis and Remediation are installed on the same server. If the EJB call fails, the Web service is called. For more information about how to troubleshoot issues with risk analysis, see the SAP Notes 1136379, 1049058, 1145700, 1234807, 1085586, 1061088, 1003239, and 1166368.

What steps need to be taken if a risk analysis fails?

Mitigation
The Mitigation option allows approvers to approve requests when SoD violations are found during risk analysis. If this option is not enabled, the approver cannot approve the request when role conflicts are discovered. In that case, the approver can either reject some roles and perform risk analysis again to check for violations or mitigate the existing violations to proceed.

Configuring Mitigation
Procedure To configure mitigation: 1. On the Configuration tab, navigate to Mitigation. The Mitigation, Select Options screen appears. 2. Decide how you want to configure the Allow Approvers to approve access despite conflicts checkbox. This option is a global setting, but it can be configured during the workflow stage configuration. To allow approvers to approve their requests with unmitigated SoD conflicts, select the checkbox. When the approver executes the risk analysis, the resulting SoD conflicts are displayed.

130

August 2010

Compliant User Provisioning End User Personalization To require approvers to address the SoD conflicts during the access request processing, deselect the checkbox. This requires the approver to remove or mitigate the SoD conflict before they can approve.

3. In the Default Duration (in days) for the Mitigation Control field, enter the number of days you want the mitigating control to be active. 4. In the next four fields, identify the Web service URL/URI for obtaining the mitigation information from Risk Analysis and Remediation: a. Open a new browser session and navigate to the Web Application Server (http://<server>:50000/index.html). b. Click Web Services Navigator. The Web Services Navigator screen appears. c. Expand the folder that corresponds to the Web service: For Mitigation URI, expand the VirsaCCMitigation5_0Service folder For Risk Search URI, expand the VirsaCCRisk5_0Service folder For Org. Rule Search URI, expand the VirsaCCOrgRules5_3Service folder For Function Search URI, expand the VirsaCCFunction5_0Service folder

d. Click Document. The Web service URL is listed below the WSDL (Web Services Description Language) heading. Right-click Web Service URL and select Copy Shortcut from the context menu. Return to CUP Configuration tab > Mitigation and paste the correct URL into the corresponding URI fields.

e. Repeat the previous step for each Web service URL required. 5. Configure Mitigation of critical access risks required before approving the request. If this is selected, the application checks if the request has any unmitigated risks and requires the risks be mitigated before proceeding. 6. Click Save.

End User Personalization


The End User Personalization screen allows you to set the parameters that define the behavior of the fields and buttons on the Request Access screen. These parameters affect only the Request Access screen. They do not affect the Create Request and Copy Request screens when you log on as an Approver. Default Values The values defined in this field appear (pre-populated) when the end user opens the Access Request screen. Mandatory Setting this parameter to Yes requires the end user to enter a value in the selected field in order to submit a request. Editable Setting this parameter to Yes allows the end user to edit the value in the selected field. If the parameter is set to No, then the value in the field is displayed as read-only. Visible Setting this parameter to Yes makes the field visible to the end user on the Access Request screen.

August 2010

131

Compliant User Provisioning End User Personalization

These parameter settings apply to every access request submitted. You cannot customize some parameters, because they default to either Yes or No based on the nature of the field. For example, a mandatory field must be visible on the Request Access screen. Therefore, the Visible parameter has a default value of Yes.

The following table lists the fields and buttons that make up the Request Access screen. The fields are arranged by their logical grouping for conceptual context and accessibility to configuration information.

Field Action Group Attachments

Description

Personalized Values Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Default Value - N/A Mandatory N/A Editable N/A Visible Yes/No

The Attachments button allows users to select files and attach them to a request. The Cancel button allows users to cancel a request.

Cancel

Password Self Service

This is a hyperlink to the Password Self Service option, which allows users to reset their passwords in the SAP back-end system without involving the SAP Help Desk or the SAP Security Group.

Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Setting Visible to Yes makes the hyperlink available in the Request Access screen. Setting Visible to No hides the hyperlink in the Request Access screen. Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Setting Visible to Yes allows the end user to submit requests for others. Default Value N/A Mandatory Yes/No Editable N/A Visible Yes/No Setting Mandatory to Yes requires the end user to select roles before submitting a request. Setting Visible to Yes enables the Select Roles button, which allows end users to select roles for a request.

Requesting for Other User

This checkbox appears on the logon page to access the Request Access screen. Selecting it enables the User Information Lookup (search feature). This field enables users to add roles to a request.

Roles

132

August 2010

Compliant User Provisioning End User Personalization

Field Action Group Submit

Description

Personalized Values Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Setting Visible to Yes allows end users to submit requests from the Request Access screen. Otherwise, they must use the Select Roles screen to do that. Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Setting Visible to Yes makes the Select SuperUserAccess button visible. This button is disabled if the provisioning action SUPER_USER_ACCESS is not associated with the selected request type. Default Value Yes, you can select a value. Mandatory N/A Editable Yes/No Visible N/A Since users cannot submit requests without this information, the Mandatory and Visible parameters default to Yes. You cannot change these settings. Default Value Yes, you can select a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can select a value. Mandatory N/A Editable Yes/No Visible N/A Users cannot submit requests without this information. Default Value Yes, you can enter a reason. Mandatory N/A

This button allows users to submit a request.

Super Access

The Superuser Access action type allows users to request a Firefighter ID (FFID) in Superuser Privilege Management from Compliant User Provisioning.

Request Info Group Application (list of systems) This is the name of the application server(s) in which the requested action is performed.

Functional Area

This is an organizational category associated with the users role or profile.

Priority

This value determines how quickly a request is approved.

Request Reason

This field allows users to enter the reason for requesting access.

August 2010

133

Compliant User Provisioning End User Personalization

Field Action Group

Description

Personalized Values Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/No Visible N/A

Request Type

Request types determine the actions to perform. They are reference points for initializing a workflow, such as New, Change, Delete, Lock, and Unlock. This is the requestors email address.

Requestor Email

Requestor Name

This is the requestors name.

Requestor Telephone

This is the requestors telephone number.

Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Default Value N/A Mandatory N/A Editable N/A Visible Yes/No

Manager Info Group Manager Email This is the managers email address. Default Value N/A Mandatory Yes/No Editable Yes/Yes if data missing/No Visible Yes/No If the Editable parameter is set to Yes, if data missing, the field is editable only if the value is missing from the data source. Default Value N/A Mandatory N/A Editable N/A Visible Yes/Yes if data missing/No If the Visible parameter is set to Yes, if data missing, and the manager information is not associated with the user ID in the data source, then the search icon is displayed. Default Value N/A Mandatory Yes/No Editable Yes/Yes if data missing/No Visible Yes/No Default Value N/A Mandatory Yes/No Editable Yes/No

Manager Information Lookup

This is the search icon (magnifying glass) used to launch the search feature for manager information.

Manager Name

This is the managers name.

Manager Telephone

This is the managers telephone number.

134

August 2010

Compliant User Provisioning End User Personalization

Field Action Group

Description

Personalized Values Visible Yes/No Default Value Yes, you can select a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can select a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can select a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/No Visible N/A Default Value N/A Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a default value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/No Visible N/A Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Default Value N/A Mandatory N/A

User Info Group Accounting Number It will populate the accounting number field in the Logon Data tab of the User Master Record. This is the company name associated with the user requesting access.

Company

Department

This is the name of the department associated with the user requesting access.

Employee Type

This is the status of the employee in the company.

Location

This is the location name associated with the user requesting access.

User Email Address

This is the email ID of the person for whom the user is requesting access. This is the first name of the person for whom the user is requesting access. It will populate the User Group for Authorization Check field in the Logon Data tab of the User Master Record. This is the unique ID of the person for whom you are requesting access. This is the search icon (magnifying glass) used to launch the search feature for user information. This is the last name of the

User First Name

User Group

User ID

User Information Lookup

User Last Name

August 2010

135

Compliant User Provisioning End User Personalization

Field Action Group

Description person for whom the user is requesting access.

Personalized Values Editable Yes/No Visible N/A Default Value N/A Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a default value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a default value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/Yes, if data missing/No Visible N/A Default Value N/A Mandatory Yes/No Editable Yes/Yes if data is missing/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/Yes if data is missing/No Visible N/A Default Value N/A Mandatory N/A Editable N/A Visible Yes/Yes if data is missing/No Default Value N/A Mandatory N/A Editable Yes/Yes if data is missing/No Visible N/A

User Telephone

This is the telephone number of the user for whom the user is requesting access. This field indicates the validity start date for a user.

User Valid From

User Valid To

This field indicates the validity end date for a user.

Self User Info Group Self User Email Address This is the email address of the user submitting a request.

Self User First Name

This is the first name of the user submitting a request.

Self User ID

This is the user ID of the user submitting a request.

Self User Information Lookup

This is the search icon (magnifying glass) used to launch the search feature for self user information. This is the last name of the user submitting a request.

Self User Last Name

SNC Info Group SNC Name This field contains the name of the Secure Network Communication (SNC). You use the SNC value for Single Sign-On to systems Default Value Yes, you can enter a value. Mandatory Yes/No Editable Yes/No Visible Yes/No

136

August 2010

Compliant User Provisioning End User Personalization

Field Action Group

Description that run in an ABAP environment and use SAP GUI as the front-end client.

Personalized Values

For more information, see SAP Note 1177556 Compliance User Provisioning SNC Parameters. Default Value Yes, you can select a value of Yes or No. Mandatory Yes/No Editable Yes/No Visible Yes/No

Unsecure Logon Allowed (SNC)

If this field is set to Yes, the user can log on without having a default SNC name for authentication.

Validation Group Approve Reject Own Requests You can set Compliant User Provisioning to allow users to approve or reject their own access request. For compliance purposes, the default behavior prevents users from approving or rejecting their own requests. This allows you to restrict users to no more than one request submission for an application. Default Value N/A Mandatory N/A Editable N/A Visible Yes/No If Visible is set to Yes, this allows end users who are also approvers to approve/reject the request during the approval process. Default Value N/A Mandatory Yes/No Editable N/A Visible N/A

One User per Request per System

Setting Mandatory to Yes allows the end user to submit only one request per system. All open requests in the approval process must be completed before another request can be submitted to the same system. Setting Mandatory to No allows the end user to submit multiple requests per system.

Procedure To change the settings for a particular user: 1. On the Configuration tab, navigate to End User Personalization. The End User Personalization screen appears. 2. Select the name of the field you want to change, and click Change. A Change screen appears at the bottom of the screen.

August 2010

137

Compliant User Provisioning End User Personalization

You can select only one field to change at a time. 3. From the Mandatory dropdown list, select Yes to require users to complete the field during Access Request submission or No to make the field not required. 4. From the Editable dropdown list, select Yes to allow users to edit the field during Access Request submission or No to make the field not editable. 5. From the Visible dropdown list, select Yes to allow users to see the field during Access Request submission or No to make the field invisible. 6. Click Save.

138

August 2010

Compliant User Provisioning End User Personalization

Frequently Asked Questions


Question Where does Compliant User Provisioning obtain a users manager information? Answer The Access Request screen. The managers first name, last name, and email address can be entered with: Free form text entry fields. There is no validation of the field contents. The user search function in the Manager field on the Access Request. This uses the system configured for searching for the selected user. The search (magnifying glass) icon, entered manually and mapped from the LDAP or SAPHR system. However, to import the manager's information, the user data sources must be set to the LDAP or SAPHR system. If you are using the CUA as the user data source, encourage the requestors to use the search dropdown capabilities for accuracy.

How do I set up End User Personalization so Ensure that the LDAP and SAPHR connectors that searching for manager information is are correctly set up in Access Control and verify that the appropriate connector is from the correct data source? configured as the user details source so that the manager information is retrieved. For more information on configuring connectors as user details source, see the section User Data Source Definition. In the End User Personalization screen, set the Manager Name, Manager Email, Manager Information Lookup, and Manager Telephone fields with the Editable parameter set to Yes if data is missing. Ensure that the Manager Information Lookup field is set with the Visible parameter to Yes. How do I prevent users from entering fake user IDs in the request form and only allow them to select a user ID using the search feature? On the End User Personalization screen, set the User ID, User Email, User Last Name, and User First Name fields with the Editable value to No. Ensure that User Information Lookup is visible. When users log on and make a request for others, they cannot enter data in the user information fields. They are then obliged to use the Search (magnifying glass) icon to query for a user ID.

August 2010

139

Compliant User Provisioning Technical Support Contact Identification

Question How do I allow users to enter information in fields left empty because the search results did not return information for that particular field?

Answer If you know that user information is missing or does not exist if the user does a search, you can make the field editable and allow entry of the information. For example, if the email address is missing for a user, you can set the User Email field as Editable with Yes if data is missing. This allows the user to enter the email address in the Request Access Form. This is the same for missing information for User ID, User Name, and User Last Name.

What are the differences between the Self To activate the Self User Information User Information configuration and Request (magnifying glass) search icon, select the Requesting for Other User checkbox when for Others Information configuration? entering your logon credentials. After logging on, you can search for user information (via the Search feature) for which you are requesting access. If you do not select the Requesting for Other User checkbox, the Self User Information fields, (which include Self User Email, Self User First Name, Self User ID, and Self User Last Name) are automatically pre-populated. To make the Self User Information Lookup (search icon) visible, set the Visible value to Yes.

Technical Support Contact Identification


The Support option defines a primary contact for Compliant User Provisioning, including email and phone information.

Defining Contact Information


Procedure To define contact information: 1. On the Configuration tab, navigate to Support. The Support screen appears. 2. In the System Administrator field of the Contact Information section, enter in the user ID of the primary contact. This user is usually a system administrator for Access Control. 3. In the Email Address field, enter the email address of the contact. 4. In the Phone field, enter the phone number of contact. 5. Click Save.

140

August 2010

Compliant User Provisioning Available Request Attributes

Defining Support Screen information


The Support screen is viewable by requestors from the Access Request screen by clicking Support. To define the Support screen information: 1. In the File Name field, enter the name of the HTML file containing the support information to be displayed when a requestor selects Support from the initial Access Request screen. Compliant User Provisioning provides a default Support page. However, you can create your own Support page and point to it by clicking Browse. Otherwise, click Restore Default to restore the original support page.

2. Click Import.

Available Request Attributes


The Attributes screen provides a standard list of attributes that the requestor can select as part of the access request process. Use the Attributes option to select attributes to appear on the Access Request screen (listed in the dropdown list or text field). Attributes allow the users to input valid information when requesting access. The standard list of attributes is basic in every business model. Do not disable an attribute unless you are certain it will never be used as part of the configuration. Disabling an attribute means that the attribute will not be an available option when defining your initiator or custom approver determinator.

Configuring Attributes
Procedure To configure a company attribute: 1. On the Configuration tab, navigate to Attributes. The Attribute screen appears. 2. Enable or disable each attribute. 3. Click Save.

Custom Fields
The Custom Fields option creates customized fields that are required for additional information or security. You can use custom fields to determine the workflow of the request or to extend the current attributes for the organizations requirements. Custom fields appear in the More Options section of the Access Request screen. For more information, see the sections Creating a Custom Field and Changing or Deleting a Custom Field.

August 2010

141

Compliant User Provisioning Custom Fields

Creating Custom Fields


Procedure To create a custom field: 1. On the Configuration tab, navigate to Custom Fields. The Custom Fields screen appears. 2. Click Create. 3. Enter all required information. 4. From the Workflow dropdown list, select Yes for this field to appear on a dropdown list, or select No to prevent this field from appearing on a dropdown list. 5. From the Mandatory dropdown list, select Yes to require the end user to enter information into this field, or select No to indicate that the end user is not required to enter information into this field. 6. From the Applicable To dropdown list, select whether this field is applicable to a role or request. 7. From the Workflow Type dropdown list, select the workflow to which you want this field to apply. 8. From the Field Type dropdown list, select Dropdown or Text. If you select Dropdown, a Data Source dropdown list appears. Select a data source. If you select SAP, you will be prompted to enter the following information: Source System - Select the SAP system for which the custom field will be applicable. Table Name Enter the SAP table from which to pull the custom field options. This field is case-sensitive. Field Name Enter the field from the SAP table above from which to pull the custom field options. This field is case-sensitive.

If you select AE, a table of custom value fields appears. Use the and icons to add or delete fields. Enter the valid field values for your custom field.

If you select Text, a Data Type dropdown appears as well as a Data Length text field. If you select Date, you are not required to enter a data length. If you select Numeric, enter a data length for the numeric character requirements. If you select Varchar2, enter a data length for the numeric character requirements.

9. Click Save.

To provision custom fields, you use Field Mapping for Provisioning. For more information, see Field Mapping for Provisioning.

142

August 2010

Compliant User Provisioning Service Level

Changing or Deleting a Custom Field


Procedure 1. On the Custom Fields screen, select the custom field name you want to change. 2. Click Change. The Change Custom Fields screen appears. 3. Make any modifications. 4. Click Save.

Service Level
The Service Level option sets the time frame for a task to be completed. Service level agreements can be between departments in an organization or between external users. Service levels are defined by the attributes on the submitted request. Service levels are useful data points for generating performance reports (Service Level for Requests report). Example You create a service level where the workflow type is CUP and the number of days for a request to be approved to 10 (days). This service level is also configured for attributes of Request Type and Priority with values of the following:

Request Type New Change

Priority High Medium

Condition Condition 1 Condition 2

If a request is submitted on 10/21/08 and the approval due date is 10/31/08, but it is actually approved on 11/05/08, the latter date is marked to indicate that a service level agreement for this request has been broken.

Configuring a Service Level


Procedure 1. On the Configuration tab, navigate to Service Level. The Service Levels screen appears. 2. Click Create. The Create Service Level screen appears. 3. Enter all required information.

August 2010

143

Compliant User Provisioning Workflow Management The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you enable Workflow Types on the Miscellaneous screen. 4. Add attributes. You must add each attribute individually. Click Add Attribute to add additional attributes.

Changing a Service Level


Procedure 1. On the Service Level screen, select the service level you want to change. 2. Click Change. The Days and Hours fields become active. 3. Make any modifications. 4. Click Save.

Workflow Management
Workflow management includes creating, modifying, deploying, activating, deactivating, and deleting workflows. Each workflow should replicate one of your organizations existing provisioning approval processes.

About Workflows
A workflow defines the required steps to approve the assignment of one or more roles to a specific user. Each access request specifies a distinct condition. When a request comes in, it triggers the specific workflow designed to manage requests with that particular condition. Although neither the requestor nor the approvers ever see the actual workflow, the workflow determines the approval process. Features Compliant User Provisioning uses workflows to automate the collection of approvals, and it can automate the provisioning process as well. Activities Every company has established processes for requesting and granting access to users, both for new employees and for existing employees whose role in the company changes. Each process requires two basic tasks: Obtaining all of the required approvals for role assignments Carrying out the actual provisioning process within SAP

Workflow Components
Each workflow is called by a initiator and contains one or more stages. When you create a workflow, you define elements. These elements are described in the following table.

144

August 2010

Compliant User Provisioning Workflow Management

Workflow Component Elements Element Initiators Description An initiator is an object that defines a precise request condition, and identifies the single, unique workflow designed to handle that type of request. Initiators and workflows function as matched pairs. Each initiator can call only one workflow, and each workflow can be called by one initiator. A stage is a decision point in a workflow. At each stage, one or more approvers must approve or deny the request. The stage defines who must approve the request. It also determines what happens next, based on the decision of the approver. At each stage of the request process, the system sends an email message to the user designated to approve or deny the request. The request process cannot continue until the approver responds by approving or rejecting the request. A path defines the sequence of stages in a workflow. When you create a workflow, you begin by creating each of its stages. By themselves, the stages serve no purpose. Each stage is an independent entity, unrelated to any other stage. When you create a path, you define the order in which the workflow calls its stages.

Stages

Paths

August 2010

145

Compliant User Provisioning Workflow Management

Workflow Creation
Creating a workflow involves both planning and execution. In most cases, planning a workflow is far more time-consuming than creating it. Creating a workflow is a straightforward process of creating or selecting the necessary capabilities and then defining a path to bind them. It is the planningdetermining how you want the workflow to functionthat requires some consideration. Prerequisites When you create a workflow, you establish your organizations policy for approving a specific type of access request. You identify the condition (the specific attributes of the request) that calls the workflow, determine the number of approvals required and who the approvers are, and specify the sequence for those approvals. Procedure When you have finished planning the workflow, you define it. The basic steps are: 1. Create the necessary initiator to call your workflow. The initiator determines which requests use the workflow. Only requests that have the same attributes as those you assign to the initiator can call the workflow. 2. Create any new stages you need for your workflow. The stages in a workflow define the approvers for the request. If you need a stage that does not exist, you must create it. Since you can use the same stage in several different workflows, you only create a new stage if it does not already exist. Your first step is to evaluate your existing stages to if you want to use any of them in your workflow. Then create the stages you need that do not yet exist. You can create an additional stage, even if the approver determinator is the same but the stage configuration details are different. For example, one role approver stage might have risk analysis required and another role approver stage might not require the risk analysis. 3. Create and activate the path. The path is the structure and framework of the workflow. It binds the various capabilities into a cohesive process. When you define the path, you create an association among the workflow, the approvers, and its initiator, and you identify the workflows stages and the sequence in which they are called. Result When you save and activate the workflow, it becomes effective immediately. Any subsequent request that matches its initiator calls the workflow, which then manages the approval process.

146

August 2010

Compliant User Provisioning Workflow Management

Workflows manage the approval process behind the scenes. Users who initiate requests do not see the workflow. Approvers who enter requests to approve them do see the workflow, but not until the second screen of the approval process. They can see the path, stages, and approvers listed at the top of the Search Request screen. When you first begin creating and saving workflows, review them before you activate them. You can delete a workflow only if no access request has ever called it. When a workflow has managed a request, you cannot delete it. Do not activate a workflow until you are certain it reflects its intended approval path.

Sample Workflows
Compliant User Provisioning supports several variations of workflows: You can create a single initiator for multiple roles. While many enterprises choose to create their workflows so that each one defines the approval process for a single role, this is not required. If you have two roles that are always assigned to a user in tandem, you can create an initiator using a Boolean and operator, so that any request that includes both roles triggers the workflow. More commonly, a single workflow approves several different roles. You can create an initiator that uses a Boolean or operator. Any request that includes any of the roles defined in the initiator then triggers the workflow.

Workflows must define what happens if an approver denies a request. It is natural to think of a workflow as a series of approvers granting access, but there are times when the requested roles conflict, or are inappropriate for the user. When that occurs, it is the responsibility of the designated approver to deny the request. Once the request is denied, you must determine how Compliant User Provisioning should handle the request. Do you want to abort the request or do you want to pass the request to security for analysis? If only part of the request has been denied, do you want to proceed with the remainder of the request? You can design detour workflows that trigger when an approver denies part of a request, or an escape route that aborts it. You can create a single initiator for multiple roles.

To configure provisioning for your enterprise, you must understand these workflow variations described in the following sections.

Basic Workflows
The typical workflow is a path leading from a request for user access to the provisioning of that access. This kind of workflow is the main workflow. It defines request approval as a linear process, starting with the initiator and ending with approval at the final stage. The following figure illustrates this basic path.

August 2010

147

Compliant User Provisioning Workflow Management Basic Workflow with Three Stages

148

August 2010

Compliant User Provisioning Workflow Management This diagram shows the sequence of stages and identifies the designated approver at each stage. This type of path is typical, because its initiator is triggered by a request. The request condition that satisfies the initiator can include multiple attributes. The basic workflow is triggered by an initiator, which is configured with a workflow type. The standard workflow types are: CUP This is a workflow type for Compliant User Provisioning. Mitigation Control This is workflow type is for mitigating control definitions in RAR. Mitigation Control Assignment This is workflow type is used when mitigating control assignments are maintained. ERM This is a workflow type for role approval. Risk This workflow type is used for changes to risk definitions in RAR. SOD Review This workflow type is for requests created by the Segregation of Duties review process. User Access Review This workflow type is for requests created by the User Access Review process.

Workflow types are associated with certain attributes that are relevant to the request. The attributes define the workflow logic and determine how the request is processed through the designated path. The CUP workflow type provides the following attributes: Application Employee Type Request Type Business Process Functional Area Company Request Priority

The ERM workflow type provides the following attributes: Request Type Priority

The SOD Review workflow type provides the following attributes: Application SoD Review Risk Priority Request Type

The User Access Review workflow type provides the following attributes: Application UAR Review Role Priority Request Type

The workflow types of Mitigation Control, Mitigation Control Assignment, and Risk do not have associated attributes.

Most of the workflows you create are main workflows. For more information, see the section Creating New Workflows.

Parallel Workflows
It is possible for a single request to call multiple initiators and trigger multiple workflows. When this occurs, Compliant User Provisioning processes all of the triggered workflows simultaneously (in parallel).

August 2010

149

Compliant User Provisioning Workflow Management

Parallel workflows work only when initiators are created at the role level. A request is split by roles into the parallel workflows. When the requestor submits the request and two initiators are satisfied, the system initiates two or more workflows. These workflows contain the same request number, and the Search Request screen displays the various paths. Although each path moves through its workflow individually, if multiple paths arrive at the same stage and same approver at the same time, the approver can approve once for the request and satisfy both (or all) paths. Example If the initiators are defined by roles and a user submits a request with two different roles that satisfy two different initiators, the system establishes a parallel workflow. If both paths call for the manager to be the first approver, the manager needs to approve the request only once for both workflow paths. Since the manager turns out to be the same user in both paths, Compliant User Provisioning sends only one approval email to that user, who needs to make only a single decision. Assuming the approver approves the request, Compliant User Provisioning proceeds to the next stage for each workflow. Since the two workflows have two different stages, it generates two different emails, one for each identified approver. It then waits for the approvers to take action. When both approvers approve their stages, Compliant User Provisioning moves on to the next stage. Since security is the next stage in both workflows, security has the ability to approve both requests with one approval, if both workflows arrive in the security stage at the same time, or security might approve each workflow individually.

Detour Workflows
Detours are stand alone workflows that assume the management of the request if specific conditions are met. If the conditioners are met, the request will actual change workflow paths and continue down the detour instead of the main path are determined by the initiator. For more information, see the section Detour Paths.

Forked Paths
Forked paths allow the request to split off of a single initiator based on the SAP or non-SAP applications selected on the request. For more information, see the section Forked Workflows.

Workflow-Specific Configuration Tasks


The configuration tasks described in this section relate to the creation of workflows. You must complete these tasks before migrating your provisioning processes into Compliant User Provisioning. These workflow-specific configuration tasks are explained in the following table.

150

August 2010

Compliant User Provisioning Workflow Management

Workflow-Specific Configuration Tasks Workflow-Specific Configuration Task Custom Approver Determinators Description Compliant User Provisioning uses approver determinators to identify approvers at workflow runtime. However, the delivered approver determinators might not be sufficient for your requirements, because your enterprise might also need custom combinations of attributes as approver determinators. In that case, you can create your own custom approver determinators before you create your workflows. For more information about how to define custom approver determinators, see the section Custom Approver Determinators. Approvers You can define approvers in several different places, based on the workflow approver choices. The Approvers option allows you to define a user ID as an approver as well as a distribution list of approvers. For more information about approvers, see the section Approvers. Custom Fields The Custom Fields option allows you to create customized fields that are required for additional information or security. You can use custom fields to determine the workflow of the request or to extend the current attributes for the organizations requirements. For more information about creating custom fields, see the section Custom Fields. Setting Up Email Reminders Since Compliant User Provisioning processes a request through a workflow path, it sends approval emails to the approvers at each stage. However, it is not only approvers who have a vested interest in the process. Each user involved in the provisioning process needs to know when the request has been submitted and when the request has been approved. Along with the necessary approval emails, the system generates email notifications to all approvers at the time of submission and at the time of final approval. You can also configure Compliant User Provisioning to automatically send email reminders to approvers who have failed to act on requests within a specified time period. This action can help to ensure that the approval process does not get sidetracked. For more information, see the section Email Reminder Setup.

August 2010

151

Compliant User Provisioning Workflow Management

Workflow-Specific Configuration Tasks Workflow-Specific Configuration Task Auto Provisioning Description Compliant User Provisioning automates the process of collecting approvals for provisioning requests, ensuring that the correct supervisors approve or deny all requests in a timely fashion. You can also configure it to launch the provisioning request. This action streamlines the provisioning process from start to finish, so that it becomes an automated cycle. Users are only required to submit requests. Approvers are only required to click a link to approve or deny the requests. Compliant User Provisioning manages the rest of the process. For more information, see the section Auto Provisioning. Configuring the CUA System Setting Many enterprise environments use a single host system to manage users. Such a system is typically referred to as the Central User Administration (CUA) system or host. Since Compliant User Provisioning manages the provisioning process and must authenticate the users with whom it interacts, Compliant User Provisioning communicates directly with the CUA. Therefore, if your enterprise uses a CUA, you must define the CUA in Compliant User Provisioning before you can begin creating workflows. For more information, see the section Configuring the CUA System Setting. Identifying the SMTP Server Compliant User Provisioning interacts with approvers and, if configured to do so, other interested parties. For this reason, you must identify the SMTP server that it uses. For more information, see the section SMTP Server Identification. Each workflow defines how Compliant User Provisioning manages the approval process for a specific access request. To create a workflow, you must create a path, name it, determine its initiator and stages, and then activate it. If the initiator and stages you need already exist in Compliant User Provisioning, it simplifies the process. Prerequisites Ensure that the initiators and stages you require exist. In some cases, you might be able to use default Compliant User Provisioning objects to construct workflows, but you must create your own custom stages, and you need to define your initiators. Initiators and stages are the building blocks to construct workflows, and you must define them before you define a path. Before you create the initiators and stages to use in your workflows, you must identify them. Do this by planning your workflows outside Compliant User Provisioning before creating them inside. For more information, see the section About Workflows.

152

August 2010

Compliant User Provisioning Workflow Management

Before you begin creating initiators, stages, and paths, plan not only individual workflows, but also a comprehensive approval strategy. Only when you have an idea of the stages and initiators should you begin creating these objects. Activities When you are familiar with the Compliant User Provisioning workflow concepts and you have created a strategy on which to base your workflows, you can begin the definition process. You start by identifying the initiators you require and then creating them in Compliant User Provisioning. For more information on creating initiators, see the section Create Initiator. Next, you create the stages for your workflows. Identify these stages in your strategy before you create them in Compliant User Provisioning. Some of the stages you require probably exist as default objects. Compare the stages you need with the stages available to you, and create any additional stages. For more information, see the section Defining a Stage. If you prefer, you can create your stages before you create your initiators. It is often easier to create the initiators first, but it is unnecessary. However, you need to create both your initiators and your stages before you can create your paths. When you have defined the necessary initiators and stages, you are ready to create your workflow paths. For more information on creating a path, see the section Creating Main Paths. You can use these procedures to create all your main workflows. When you have done this, you can add escape routes to your workflows and create multi-path workflows, based on the applications included in the access request. For more information, see the sections Escape Route and Forked Workflow Creation. For more information about the concepts underlying escape routes and forked workflows, see the section About Workflows.

Initiators
Initiators are collections of request attributes that act as templates. When a user submits a request, the system compares the attributes of that request to all active initiators. If the attributes of the request match the attributes of an initiator, it uses the initiator to trigger a workflow. However, be careful not to create multiple initiators with the same attributes. This may cause the workflow logic to find multiple combinations and throw an error message. For example, if you create an initiator with the attributes Request Type and Priority, and then you create another initiator with the attribute Priority, the workflow logic finds the two combinations of attributes and throws an error message due to the multiple initiators. Similarly, if the workflow logic does not find an initiator, an error message is also thrown. Each initiator must have a unique combination of attributes. Every submitted request should match one initiator, and it should be impossible for a request to match more than one initiator. If a request is submitted that somehow satisfies multiple initiators, the request creation will fail.

August 2010

153

Compliant User Provisioning Workflow Management

Creating an Initiator
Procedure To create an initiator: 1. On the Configuration tab, navigate to Workflow > Initiators. The Initiators screen appears. 2. Click Create. The Create Initiator screen appears. 3. In the appropriate fields of the Initiator area, give the new initiator a name, short description, and long description. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 4. From the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled the workflow types on the Miscellaneous screen. 5. From the Attribute dropdown list, select an attribute to apply to the initiator. The attributes available are based on the workflow type you select. Each initiator must have at least one attribute and typically have two or more. Select attributes that, when combined, match all requests that trigger this initiator and, at the same time, exclude requests that trigger a different initiator. 6. Select a Value and a Condition for the attribute. The value defines how this attribute must match the same attribute in a request. For example, if the attribute you select is Functional Area, you might give the attribute a value of Finance. In that case, for a request to match this initiator, the user for whom the request is made must work in the Finance functional area. The condition you select is a Boolean operator. If you select AND, you specify that in order to match this initiator, a request must match not only this attribute (for example, Functional Area = Finance) but also other attributes that you specify (for example, Request Type = New). If you select OR, a request needs to match either this attribute or any other attribute that you specify, but not necessarily both, to match the initiator. The third option is NOT. In a NOT condition, the request cannot equal the choose attribute.

154

August 2010

Compliant User Provisioning Workflow Management

Example You can have multiple attributes defined in your initiator. When defining the attributes make sure that the Boolean operators (AND, OR, NOT) are used correctly in order for all attributes to be considered. For instance, you want the initiator to consider two attributes. The two attributes are Functional Area = Finance and Request Type = New. By using the condition, AND, the two attributes are considered. Using the condition, OR, only one attribute is considered. The initiator configuration below shows two attributes with two conditions, but the workflow logic reads this configuration as Functional Area and Request Type. The OR condition is not considered. Condition OR AND Attribute Functional Area Request Type Value Finance New

Adding a third attribute, Company= SAP with the condition, OR, as the last attribute in the configuration is then considered by the workflow logic. Condition OR AND OR Attribute Functional Area Request Type Company Value Finance New SAP

The initiator configuration takes the attributes of Functional Area and Request Type or Company. Either Request Type or Company is used to match the request. 7. Click Add Attributes to add the attribute and its value and condition to the initiator. 8. Continue to add attributes until the initiator meets your requirements: The initiator must match all of its intended requests. The initiator must not match any requests intended for other initiators. 9. Click Save. The new initiator is saved and the message Initiator Successfully Saved appears. Note For Superuser Access, you can create an initiator with the Super User Access request type and use it to drive a specific workflow.

August 2010

155

Compliant User Provisioning Workflow Management

Configuring Role Removal Workflow


You can use the initiator feature to configure a separate path for the roles marked for removal. Note This feature is only available for the CUP workflow type.

1. Create an initiator. For more information, see the Creating an Initiator section. 2. Choose the CUP workflow type. 3. From the Attribute dropdown list, choose Action of Role. 4. Select a Value. The available values are ADD, REMOVE, and KEEP. 5. Click Add Attribute. The attribute is added to the table. 6. Click Save.

Custom Approver Determinators


Each stage of a workflow specifies an approver. You configure the approver when you create the stage. However, you cannot identify an actual user to be the approver for a stage. Instead, you configure a determinator, which is used to identify the approver. This determinator includes the attributes of the user who can approve the request at this stage, typically based on the attributes of the request and is considered a Custom Approver Determinator (CAD). Example You create a stage named Application Approval, which is based on two attributes, Request Type and Priority. You also create a CAD named, App_Approver, which is configured with the same attributes. You set up the approvers for this CAD with the following: Request Type Priority Approver Name New New New High Medium Low FWilson BLaw MWong

When a request is submitted to the Application Approval stage with the attributes of Request Type and Priority, the appropriate approver is then determined. An email notification is then sent to the appropriate approver. For instance, a request is submitted with the Request Type of New and Priority of High. Therefore, the custom approver is then determined to be FWilson. Example A user requesting access in New York must be approved by the manager in New York. The submitted request includes the information, both department and location, but there is no default determinator that combines these two attributes. To create the Manager stage, you must also create a custom determinator that enables Compliant User Provisioning to derive who is the correct approver based on the request.

156

August 2010

Compliant User Provisioning Workflow Management

Creating a Custom Approver Determinator


Whether you need a custom approver determinator depends on your business needs. They are optional. However, many enterprises require custom approver determinators to make proper use of Compliant User Provisioning. Evaluate your existing approval processes and create a strategy for recreating them. Determining who approves requests at each stage is a fundamental part of the strategy. Only when you have established the approvers can you determine whether you must create custom determinators. Procedure To create a custom approver determinator: 1. On the Configuration tab, navigate to Workflow > Custom Approver Determinators. The Approver Determinator screen appears. 2. Click Create. The Create Approver Determinator screen appears. 3. In the appropriate fields, enter a name, short description, and long description for the new determinator. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 4. From the CAD Type dropdown list, select the custom approver determinator type. Depending on the type of workflow you select, different attributes appear. If you select Attribute, you choose the attributes that the approver is based on at runtime. Additional fields may appear, such as Workflow Type, depending on the attributes chosen. o Select Attributes are listed for selection. These are the attributes that appear on a request. For example, you might want a particular type of employee, such as contractors, to be approved by the same person. Role Attributes are listed for selection. These are attributes assigned to the roles chosen for provisioning. For example, you might decide that all roles that belong to the Procure to Pay process get approved by the same person.

If you select Web Service, the fields where you can enter Web Service details such as URL, user name, and password appear. The Web service is called from Enterprise Role Management and retrieves a list of approvers. For example, if the Web service gets 20 approver names from Enterprise Management, an email notification is sent to all 20 approvers.

5. Select the attributes or type in the Web Service details. 6. Click Save. A success message appears. 7. Click Approver. The Approver Determinator Values screen appears. Depending on the attributes you have selected, this screen displays the attributes in the table column.

August 2010

157

Compliant User Provisioning Workflow Management 8. Click Add. The Approver Determinator Value pop-up screen appears. Use this screen to assign values to the attributes and operator. For the approver and alternative approver, click the arrow icon to search for approver and alternative approvers. Click the Add icon to search and select the approver and alternate approver. 9. Click Add. 10. Click Import. The File Import screen appears. 11. In the File Name field, enter the path and name of the file. Otherwise, click Browse to navigate to the file. 12. Optionally, select the Overwrite Existing Data to overwrite the existing import file. 13. Click Download Template to download a text file to mass update your custom approver determinator configuration. Use the template by adding more values to your selected attributes, operators, approvers and alternative approvers. You can also export the modified file to mass update custom approver determinators in other systems by clicking Export.

Stages
There are two activities for creating a stage: Defining the stage:

The primary purpose of any stage is to pass a request to an approver. When you create a stage, you define the user who must approve or deny a request when the request reaches that stage. When you define a stage, you specify the approver for that stage. The term approver determinator defines the approvers for the request and how to identify the approver(s) of the stage. Configuring the stage:

There are various optional configurations you can add to a stage to specify notifications, require risk analysis, and manage security. When you configure a stage, you determine which options apply.

Defining a Stage
Procedure 1. On the Configuration tab, navigate to Workflow > Stages. The Workflow Stages screen appears. 2. Click Create. The Stage Configuration screen appears. 3. In the Stage Details area of the Stage Configuration screen, enter a name, short description, and description for the new stage in the appropriate fields. The name you enter for the stage must be unique.

158

August 2010

Compliant User Provisioning Workflow Management

The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 4. From the Workflow Type dropdown list, select a workflow type for the stage. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled the workflow types on the Miscellaneous screen. 5. From the Approver Determinator dropdown list, select the approver determinator for the stage (that is, how to identify the approver(s) of the stage). It is important to select the correct approver determinator. The approver determinator is used at runtime to derive the approver for the stage. If you select No Stage, the system automatically approves requests for the users and roles going through this stage. For example, you can provision users with certain basic roles with no approval required. If you select Superuser Access Coordinator, the system gets the configured controller from the SAP system where the Superuser Privilege Management is installed and assigns the request to that approver. If you select Superuser Access Owner, the system fetches the configured owner from the SAP system where the Superuser Privilege Management is installed and assigns the request to that approver.

6. In the Request Wait Time fields, enter the amount of time (days and/or hours) you want Compliant User Provisioning to wait at this stage for an approver to respond to a request before escalating the request. You need to do this only if you plan to configure the stage to escalate if the approver does not respond. If you do not plan to define an escalation action, you can ignore these fields. 7. From the Escalation Configuration dropdown list, select how to handle a request when an approver fails to respond within the time allotted during stage definition: No Escalation (default setting): Compliant User Provisioning waits for the approvers response, even after the specified wait time passes, and does not take any steps to resolve the stalled request. The approver approves or rejects the request. An administrator can manually resolve the problem by approving on behalf of the assigned approver, forwarding the request to another approver, or rerouting the request. For more information, see the section Request Administration. Forward to Next Stage: Compliant User Provisioning ignores the expected approval at this stage and proceeds to the next stage in the path. If you select this option, even if the designated approver does not respond to the request, it does not prevent the request from being approved. Use caution with this option since it allows the request to bypass the defined approvers. Forward to Alternate Approver: Provides a fallback option if the designated approver does not respond within the time allotted. Compliant User Provisioning reassigns the approver. Alternate approvers must be maintained for the approver determinator of the stage where this option is set. Escalation to an alternate approver happens only once; there is no alternate approver for the alternate. After the system escalates the

August 2010

159

Compliant User Provisioning Workflow Management approval for the stage to the alternative approver, the original approver no longer has access to approve or reject the request. Forward to Administrator: If the approver fails to respond within the allotted time, Compliant User Provisioning forwards the request to the administrator. The administrators information must be maintained on the Configuration Support screen for this option to work.

At this point, the required configuration for the stage is complete. 8. Click Save to save or continue with the stage configuration. If you save the stage, the system accepts the default values for the rest of the configuration options and applies them to the stage. A Workflow Stage Successfully Created message appears. At this point, the stage exists, and you can include it in one or more workflows, if you choose. When you return to the Workflow Stages screen, it displays the new stage. You can now configure the stage. There are three configuration areas: Notification Configuration Additional Configuration Additional Security Configuration (Approval Reaffirm)

Configuring a Stage
Procedure 1. In the Workflow Stages screen, click the name of the stage to configure. The Stage Configuration screen for that stage appears. 2. In the Notification Configuration section, define the notifications for the system to generate at this stage. Select which users receive emails for each possible action, and compose the message to accompany the notification. 3. In the Additional Configuration section, define any additional functionality required at this stage. 4. In the Additional Security Configuration screen, define whether or not the approver needs to reaffirm their actions by entering their password. Actions that can be configured to require password reaffirmation are: Approve Reject Create User (automatic creation of a new user record)

5. Click Save.

160

August 2010

Compliant User Provisioning Workflow Management

Configuring Notifications
The Notification Configuration screen configures email notifications for a stage to determine whether and to whom the system sends notifications about the actions taken at this stage. There are four possible actions: Approved: The system sends the email notification configured on the Approved tab when the approver approves the request. Rejected: The system sends the email notification configured on the Rejected tab when the approver rejects or denies the request. Escalation: The system sends the email notification configured on the Escalation tab when the approver fails to respond to the request within the allotted wait time and an escalation has occurred. Next Approver: The system sends the email notification to the approver(s) of the stage when the request enters this stage. The next approver is the approver of the current stage.

The users you select next to each possible action are the users who are notified when that action takes place. You must schedule the Email Dispatcher background job to automatically send these notifications. For the next approver, there is no way to turn this feature off or add additional users to receive the emails. The background job automatically sends the next approver emails to each approver of the stage. To determine who receives these emails, select the appropriate users when the corresponding action occurs. In each email notification, a link allows the recipient to access Compliant User Provisioning in display mode of the request. The next approvers email link takes the recipient into approver mode of the request. All other links go to the display mode of the request. Use caution when determining which email notifications to send to which users. Too many email notifications can annoy the recipients. Configure email notifications for users only if it is necessary for those users to receive notifications at this stage or action of the request. Remember that you can also send submission and closing emails. User: Sends email notification to the user listed on the request. Requestor: Sends email notification to the requestor listed on the request. Manager: Sends email notification to the manager listed on the request. If no manager is listed, no email is sent. (This does not cause an error.) Other Approvers: Sends email notification to all approvers that have been involved in the request up to and including this stage. If the user, requestor and/or approvers are the same, each receives multiple email notifications. When sending an email notification to the user and the requestor, if the user is the requestor, the system sends two email notifications. If the requestor and the manager are the same user, that person receives two emails.

Select these email notification options with caution. If users receive too many email notifications, they get used to ignoring them or get frustrated due to the amount of unnecessary email they are receiving. In addition, you can compose a different rich text or HTML message for each action you select to accompany the notification. Click the tab that corresponds with the notification action you select, and enter your message in the field provided.

August 2010

161

Compliant User Provisioning Workflow Management Select the appropriate Email Arguments from the dropdown list when configuring your notification. Email arguments allow you to include specific information in the email. You can change these arguments or cut and paste them into the subject line. If the email content for the next approver is not configured, the approvers of this stage receive a blank email with only a link to this request in Compliant User Provisioning when requests enter this stage. Email content is limited to 2000 characters.

Additional Configuration
The Additional Configuration screen refines the behavior of a stage. The options available depend on the workflow type you select when you initially define your stage. Decide what functions you need, and select the appropriate option from each dropdown list. Several of these settings work in conjunction with each other. When you make a selection, all future options are based on that selection. Some fields become available and others become unavailable. Risk Analysis Mandatory: Select Yes or No to determine whether the approver is required to perform a risk analysis before approving the request. Change Request Content: An approver has the authority to change the content of the request. Result The Add Roles field is available for selection. Select Yes or No to allow roles to be added during this stage. If Add Roles is set to No, the approver can remove roles from the request but not add additional roles. The Path Evaluation For New Roles field is available for selection. This setting determines how the roles are evaluated to see if they are on the correct path (This is necessary only if you configure your initiators by roles). Yes All Roles in Evaluation Path: All roles are re-evaluated against the initiators. New Roles Only: These new roles are analyzed against the initiators to determine if another parallel workflow mist be created for the newly added roles. None: No re-evaluation is conducted.

Setting

The user can edit the SNC data and User Group fields during request approval. No The approver cannot change, reject or remove, or add roles to the request. .

Approval Level: The approver has the authority to approve the request at the Request, Role, or System and Role levels. Request: The approver has the authority to approve all roles on the request. When they are approving all roles or when they reject, they are rejecting all roles. For

162

August 2010

Compliant User Provisioning Workflow Management example, manager and security approvers can approve or reject any role on the request. o o o Role: Approvers can only approve those roles that belong to them. This option is especially useful for role approvers. System and Role: Approvers have the ability to approve the system and roles. Reject Level: The approver has the authority to reject the request at the Request, Role, or System and Role levels. Request: The approver has the authority to reject all roles on the request. When they are approving all roles or when they reject, they are rejecting all roles. For example, manager and security approvers can approve or reject any role on the request. Role: Approvers can only reject those roles that belong to them. This option is especially useful for role approvers. System and Role: Approvers have the ability to reject the system and roles. Approval Type: Select whether any one approver can approve at this stage, or whether all approvers must approve at this stage, for the request to move on to the next stage. Email Group: A feature no longer used. It remains on the screen for backwards compatibility. Comments Mandatory: Select whether the approver is required to enter comments when approving or rejecting the request. If you set this option toYes, checkboxes appear to allow the user to specify when comments are required (on Approvals, Request Rejections, or both). Request Rejection: If you set this option to Yes, the approver is allowed to reject the entire request. The Reject button appears next to the Approve button, so the approver can reject the entire request without individually rejecting each role. If No, the approvers can reject roles on the request without the ability to reject the entire request. Re-Route: The approver has the authority to re-route the request to a previous stage as an alternative to rejecting the request entirely. Re-routing does not apply if the approver chooses to approve the request. Confirm Approval: The approver must answer an additional question, if he or she wants to confirm the approval action. Confirm Rejection: The approver must answer an additional question, if he or she wants to confirm the rejection action. Reject by Email and Approve by Email: The approver can reject or approve the request by email. If you set this option to Yes, there could be two additional links on the email when the approver gets the email notification for this stage, stating that there is a request waiting for action. One link is for the Approve Request Action, if Approve by Email specifies Yes. Another link is for Reject Request Action, if Reject by Email specifies Yes. The approver can use these buttons, and the link transfers them to Compliant User Provisioning. The approver must still be the valid approver for this stage of the request and must enter his or her user ID and password. In order for an approver to be able to reject by email, the Request Rejected field must be set to Yes. o If you set this option to No, these buttons do not appear in the email notification to the next approver.

o o

August 2010

163

Compliant User Provisioning Workflow Management o Reject by Email: The approver can reject the request by email. This setting is not an option if actions are required; for example, if risk analysis or comments are required. If you set this option to Yes, there could be an additional link on the email when the approver gets the email notification for this stage, stating that there is a request waiting for action. The approver can use this button, and the link transfers them to Compliant User Provisioning. The approver must still be the valid approver for this stage of the request and must enter his or her user ID and password. If you set this option to No, these buttons do not appear in the email notification to the next approver. Approve by Email: Options will allow the approver to approve the request by email. This setting will not be an option if actions are required for instance if Risk Analysis or Comments are required. If you set this option to Yes, there could be an additional link on the email when the approver gets the email notification for this stage, stating that there is a request waiting for action. The approver can use this button, and the link transfers them to Compliant User Provisioning. The approver must still be the valid approver for this stage of the request and must enter his or her user ID and password. If you set this option to No, these buttons do not appear in the email notification to the next approver. Forward Allowed: The approver has the authority to forward the request to someone else for approval. Approve request despite risks: If you set this option to Yes, the approver is allowed to approve this stage, even if there are SoD violations that have not been mitigated. If you set this option to No, the approver at this stage must remediate (remove) or mitigate the violation before he or she can approve the request. The approver is required to enter comments when approving or denying the request. Display Review Screen Yes: An approval screen will be shown after the request has been submitted. This selection is required if risk analysis is mandatory at the stage. This approval screen is redundant in the case of the User Access Review and SoD Review. No: The last approval screen will be bypassed after the request has been submitted. This option is not supported where risk analysis is mandatory at the stage. In the case of the User Access Review and SoD Review requests, the action has already been indicated for each line item and this review screen is redundant.

o o o

Additional Security Configuration


The Additional Security Configuration screen specifies whether the approver needs to confirm his or her identity to take an action at this stage. Approvers confirm their identities (reaffirm their decisions) by entering their password at a prompt when they take an action. The actions that can be configured to require reaffirmation are: Approve Reject Create User

164

August 2010

Compliant User Provisioning Workflow Management

Paths
After creating and configuring initiators and stages, you can create workflow paths. There are three different procedures for creating paths: Creating a Main Path Creating a Detour Path Adding a Detour to a Main Path

Creating Main Paths


Procedure To create a main path: 1. On the Configuration tab, navigate to Workflow > Path. The Workflow Paths screen appears. 2. Click Create. The Create Path area appears at the bottom of the screen. 3. Enter the details of the path in the fields provided: The name of the path must be unique. The short description appears in dropdown lists throughout Compliant User Provisioning as an option when you perform a query. This field is limited to 38 characters. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled the workflow types on the Miscellaneous screen.

4. Select the Active checkbox to make the path active when you save the path. Make sure that the Detour checkbox is not selected. If you save the path with this checkbox selected, the path becomes a detour. If it is a detour, it cannot have an initiator, and the system does not allow you to save it.

You cannot change a path after a request has been submitted on it. To deactivate a path and reuse the initiator on another path: Remove the active flag on the path. Check the Detour checkbox to make the path a detour. Remove the initiator. Now the path is deactivated, and the initiator is available to be used in another path. Any request that has started using this path will finish, even though it is now inactive. It is inactive for new requests only.

August 2010

165

Compliant User Provisioning Workflow Management

Detour Paths
Detours are standalone workflows that assume management of a request from a main workflow. Detours are not subsets or dependents of main workflows. They do not have initiators, so they cannot be triggered by a submitted request. If the state of a request meets predefined conditions, a main workflow passes control of the request to a detour workflow. The type of event that triggers a detour is typically one that prevents a main workflow from proceeding on its defined path. If something occurs that interferes with a request, the main workflow can be configured to pass the request to a detour workflow. For example, you can design a workflow to handle a single request that includes more than one role. If an approver denies one of the roles in the request, you might want the remainder of the request to proceed. Rather than aborting the request, you can have the main workflow transfer it to a detour workflow. The detour can then continue the approval process for the remaining roles. When the main workflow passes a request to a detour workflow, the request ceases to be associated with the original workflow and is managed by the detour workflow. The structure of a detour workflow is similar to the structure of a main workflow. It has a defined starting point and a sequence of one or more stages. At each stage of the detour, an approver must approve the request before it can proceed. You create a detour using the same procedures that you use to create a main workflow. For more information, see the section Creating New Workflows. For more information about how to define a jump from a main workflow to a detour, see the section Path Creation. Procedure To create a detour path: 1. On the Configuration tab, navigate to Workflow > Path. The Workflow Paths screen appears. 2. Click Create. The Create Path area appears at the bottom of the screen. 3. Enter the details of the detour path in the fields provided: a. Enter a Name. The name of the path must be unique. It might also be useful to give the detour both a name and a description that are easy for you to identify. Enter a Short Description. The short description appears in dropdown lists in different places throughout Compliant User Provisioning as an option when you perform a query. This field is limited to 38 characters. Enter a Description. The description is longer than the short description and can contain more detailed information. Select a Workflow Type. In the No. of Stages field, enter the number of stages you want to include in the detour path.

166

August 2010

Compliant User Provisioning Workflow Management Ensure that there is no value selected in the Initiator dropdown list. Select the Active checkbox to make the path active when you save the path. Select the Detour checkbox to specify that this path is a detour. When you finish entering these details, the system displays a graphical representation of the detour path. 4. Click Save. A Workflow Path Successfully Saved message appears. When you return to the Workflow Paths screen, the new path is listed.

Adding Detours to a Main Path


Procedure To add a detour to a main path: 1. On the Configuration tab, navigate to Workflow > Detour/Fork. The Workflow Stage Detour screen appears. 2. Click Create. 3. Enter the details of the connection between the main path and the detour path. Working from left to right: a. In the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled Workflow Types on the Miscellaneous screen. In the Path dropdown list, select the main path to which you want to connect the detour. In the Stage dropdown list, select the stage of the main path where you want the request to jump to the detour. In the Action dropdown list, select the action that must occur to execute the detour. In the Condition dropdown list, select the condition that must occur to execute the detour. Valid detour conditions are: SoD Violations: When the Risk Analysis is run and there are SoD risks, requests with SoD violations meet this condition, even if the risks are mitigated during the request approval process. No Role Owners: When no role approver is associated on the request. Roles with No Role Owners: When some roles on the request have role approvers and some do not, the request splits into a parallel workflow with those roles with no role approvers routed directly other than the roles with role approvers. Verification/Training Failed Request Level: When a verification/ training system has been implemented and Compliant User Provisioning is configured to verify training. Role Verification/Training Failed Role Level: When a verification/ training system has been implemented and Compliant User Provisioning is configured to verify training.

August 2010

167

Compliant User Provisioning Workflow Management NDA Not Signed For Insider Roles: Not generally used.

In the Value dropdown list, select Yes or No to specify whether the detour executes in the presence of the condition defined in the Condition field or in its absence. If you select Yes, the detour executes only when the specified condition occurs. If you select No, the detour executes only when the condition does not occur.

In the Detour Path dropdown list, select the detour path to which you want to connect the main path. 4. Click Save. A Workflow Detour Successfully Created message appears. The detour configuration is now listed on the Workflow Stage Detour screen. After a request routes to a detour, it completes the workflow on the detour path. A detour does not route back to the original path.

Forked Workflows
A forked workflow has a single initiator but two distinct paths. When called by a request, the workflow determines which path is appropriate to manage the request. A forked workflow can manage a request using either one of its paths or both, depending on the condition of the request. Forked workflows are available only when separating workflows by SAP and workflows by non-SAP applications. You can create a forked workflow to handle requests that require different approval paths, depending on the access requested. The decision point for a fork is the initiator that calls the workflow. The decision itself is based on whether the requested access is for an SAP application or for a non-SAP application. If the approval process for a user request is the same for access to SAP applications as it is for non-SAP applications, there is no reason to use a forked workflow to manage the request. Example You can create an initiator that calls a workflow to manage all user access requests where the user has the accountant_01 role and will work in the headquarters location. Any request for access for a user that has this role and works in this location matches the initiator, and the initiator triggers the workflow. In this case, the condition of the initiator does not distinguish between SAP and nonSAP applications. Regardless of the applications included in the request, submitting the request calls the same initiator. If the workflow forks, the attributes of the request determine how the workflow manages the request: If it requests access to SAP applications only, the path configured to manage SAP application approvals manages the request. If it requests access to non-SAP applications only, the path configured to manage non-SAP application approvals manages the request.

168

August 2010

Compliant User Provisioning Workflow Management If it requests access to both SAP and non-SAP applications, the request follows both paths simultaneously. Creating forked workflows is optional. If the approval process for access to non-SAP applications differs from the process for SAP applications, you can configure it in either of two ways: Create two different initiators, one for each application type, with each workflow handling requests for one of the application types. Create a single initiator that calls a forked workflow.

For more information about how to create a forked workflow, see the section Forked Workflow Creation. In most cases, the terms workflow and path are interchangeable, because the majority of workflows employ only one path, and these workflows are indistinguishable from their paths. Forked workflows are the exception. A fork is a workflow that has two distinct paths, specifically to handle requests for access to different types of applications. The distinction between these types of applications is whether or not they are native SAP applications. Compliant User Provisioning provides forked workflows to manage requests for access to both SAP and non-SAP applications. You create a workflow fork if: You create a single workflow and initiator that can be triggered by an access request for either an SAP or a non-SAP application (or both). You want to use a different path to handle access requests for SAP applications than the one it uses to handle requests for access to non-SAP applications.

You can, of course, define two initiators and two workflows, one to manage each application type. However, creating a single workflow to handle both can simplify the task of creating initiators and workflows. You create a forked workflow by joining two distinct, independent paths. At least one of these paths must be a main path, triggered by an initiator. A forked workflow begins with one path and then joins a second path to it. The first path must be a main path. The second path can be either a main path or a detour. The procedure that follows describes how to join two existing paths together to form a fork. If the fork you want to create includes paths that do not exist, you must create the paths before you can create the fork. For more information, see the section Path Creation.

Procedure To create a forked workflow: 1. On the Configuration tab, navigate to Workflow > Detour/Fork. The Work Flow Stage Detour screen appears. 2. Click the Fork Path tab. 3. Click Create. 4. Enter the details of the fork. Working from left to right: a. From the Workflow Type dropdown list, select a workflow type. From the Initiator dropdown list, select the main path on which you want to base the fork. From the Action dropdown list, select Save.

August 2010

169

Compliant User Provisioning Email Reminder and Email Notification Setup From the Condition dropdown list, select the condition that must occur to execute the forked path. From the Value dropdown list, select either Yes to specify if the workflow occurs in the presence of the condition defined in the third dropdown list, or No to specify if the workflow forks in its absence. If you select Yes, the request follows the fork only when the specified condition occurs. If you select No, the request follows the fork only when the condition does not occur. From the Fork Path dropdown list, select the alternative path you want to join to the primary path to form the fork. 5. Click Save. A success message appears. The new fork is listed on the Path Fork tab of the Work Flow Stage Detour screen.

Email Reminder and Email Notification Setup


You can configure email messages to communicate with users, requestors, managers, and approvers. You can also configure email reminders to send request progress notifications to interested parties and reminders to approvers who have failed to act within a specified time period. The configuration process is the same for both reminders and notifications. When you create a new user, the system sends an email notification to the user. The email is sent to the email address listed on the request and includes the new users ID and the list of systems they can access. The system sends the email notification automatically; you cannot choose to not send the email. For security, the system sends the email only to the user listed on the request. On the configuration screen, you can choose whether to display the password itself in the notification email or display a link to access the password.

If you are implementing SSO, SAP recommends you choose the option to display a link in the email to access the password.

Setting Up Email Notifications Procedure


1. Login to CUP. 2. On the Configuration tab, navigate to Workflow > Stages and select Create. The Stage Configuration screen appears. 3. Enter the Stage name, short description and other parameters for the stage. 4. Select the Workflow Type and approver determinator for the stage. The available workflow types are: Workflow Type CUP ERM RISK Description Workflow for Compliant User Provisioning. Workflow for Enterprise Risk Management. Workflow for Risk Analysis and Remediation.

170

August 2010

Compliant User Provisioning Email Reminder and Email Notification Setup

SoD Review User Access Review

Workflow for Segregation of Duties Review. Workflow for User Access Review.

For more information, see the Miscellaneous section of the Compliant User Provisioning chapter. 5. Enter the notification Subject and Content. The character limitation for the Content field is unlimited. We recommend verifying with your IT administrator if your e-mail server has any message size limitations. 6. Administrator saves the email notification for the application.

Setting Up Email Reminders


Procedure 1. On the Configuration tab, navigate to Workflow > Email Reminder. The Email Reminder screen appears 2. From the Workflow Type dropdown list, select the type of reminder you want to configure. The available workflow types are: Workflow Type CUP ERM RISK SoD Review User Access Review Description Workflow for Compliant User Provisioning. Workflow for Enterprise Risk Management. Workflow for Risk Analysis and Remediation. Workflow for Segregation of Duties Review. Workflow for User Access Review.

For more information, see the Miscellaneous section of the Compliant User Provisioning chapter. 3. In the Days field, enter the number of days the email reminder is active. 4. Click the tab associated with the type of email reminder you want to configure: Reminder: When a request is created, an email reminder can be sent to notify approvers. In the Notification Configuration section, select the Other Approvers checkbox. Submission: When a request is submitted, an email reminder can be sent to notify the user, the requestor, the manager and other approvers. In the Notification Configuration section, select the checkboxes. The email reminder includes a link to view the status of the request. Closing: When a request is closed, an email reminder can be sent to notify the user, the requestor, the manager and other approvers. In the Notification Configuration section, select the checkboxes.

August 2010

171

Compliant User Provisioning Email Reminder and Email Notification Setup 5. In the Subject and Content fields, enter the appropriate text. You can also add specific request data to the email reminder in the Content fields. The email argument variable can be copied into the Subject field of the email. The character limitation for the Content field is unlimited. We recommend verifying with your IT administrator if your e-mail server has any message size limitations. 6. In the Submission tab, select the role who will receive the email notifications when a request is closed. Select one or many email recipients, such as User, Requestor, and/or Manager. For the Closing tab, you can also select one or many email recipients including, Other Approvers. 7. Click Save. You can also add specific request data to the email reminder. The email argument variable can be copied into the Subject field of the email. 8. Configure the email reminder background job. a. In the left navigation pane, select Background Jobs. The Schedule Service screen appears. b. Search for email* to display the email reminder background jobs. c. Email Reminder Use this for all email reminders that are not SoD review or user access review. Email Reminder for SoD Review Use this for segregation of duty reviews. Email Reminder for User Access Review Use this for user access reviews.

Select an email reminder background job and choose OK. The Configure Email Reminder screen appears.

d. Choose the Schedule Type and Start Date, and choose Run, Activate, or Save as needed. For more information, see the Background Jobs section of the Compliant User Provisioning chapter.

Configuring Password Reset Emails


Email notifications are sent when a users password is reset. You can choose to include either a password link or an unencrypted password in the password reset email Procedure 1. On the Configuration tab, navigate to Workflow > Email Reminder. 2. Click the Closing tab. 3. Click Send password in email field and select Yes or No. If you select Yes, the email displays the unencrypted password. If you select No, the email displays a link to the password display page. The password page displays for the duration specified in the Password Display Period field. 4. From the Password Display Period (in Seconds) field, enter the number of seconds for which the password is displayed to the user when the link is clicked in the email.

172

August 2010

Compliant User Provisioning Email Reminder and Email Notification Setup Note If the user has requested for a password reset in more than one system and if Send password in mail configuration is YES than all the passwords will be sent in one single mail.

Escape Route
Workflow Escape Routes
An escape route is a mechanism you configure as part of a workflow to handle an Approver Not Found condition at the first stage. The purpose of an escape route is to prevent a request from being trapped in an irreconcilable situation by causing the request to bypass one or more stages of the workflow. If a workflow encounters an Approver Not Found condition at the first stage, it sends the request to another workflow where the approver is found. When you create an escape route, you determine how many stages the request skips or where the request is sent if an approver is not found. From there, the request follows the escape route workflow until the end of that workflow. When a request takes a path other than its intended path, there can be security consequences. Since a request bypassing approval stages presents a risk that it might not meet security requirements, one common application of escape routes is to pass the request directly to a security stage, where the request can be evaluated. After the request has been evaluated, the security user routes the request to the appropriate path and stage. There are three escape route conditions: Approver Not Found Approver Not Found at a Stage Auto Provisioning Failure

These conditions exist globally for the implementation of Compliant User Provisioning and cannot be determined by the workflow path. Only one escape route can be created and only for one of the conditions. You cannot define three escape routes, one for each condition. Use caution with escape routes for Approver Not Found conditions. Every request where the approver is not found proceeds down the same escape route. This could cause an issue if your company has several workflow paths configured.

Approver Not Found


Approver Not Found can apply only to the first stage of the path if an approver is not found on submission of the request. Approver Not Found applies to all requests submitted. It cannot be set for specific workflow paths. Approver Not Found is a very specific condition. It informs you that the workflow cannot derive the identity of the designated approver, because the attributes of the approver are either ambiguous or inadequate. If Compliant User Provisioning cannot determine who the first approver is, the email notification cannot be sent, and the system responds with an Approver Not Found message. Only in these cases will the request follow the escape route instead of the route by configured on the initiators.

August 2010

173

Compliant User Provisioning Email Reminder and Email Notification Setup

Approver Not Found at a Stage


Approver Not Found at a Stage resolves the situation when the next approver cannot be found. In this case, the request transfers to the escape route instead of displaying the error of Approver Not Found to the current approver. Approver Not Found at a Stage applies to all requests submitted on all workflows. It cannot be set for specific workflow paths or specific stages.

Auto Provisioning Failure


Auto Provisioning Failure is triggered when auto provisioning failures occur. You can establish an escape route to send the requests to security or to a Compliant User Provisioning administrator. If this escape route is not configured and an error occurs during auto provisioning, the current approver receives the error message, but cannot approve or close the request. The request waits in this approvers inbox until the provision situation has been cleared. After this approver is cleared, he or she must approve the request again, so that the request is provisioned and closed. Since an escape route is an attribute of a workflow, you must create a workflow before you can add an escape route to it.

Configuring an Escape Route


Procedure To configure an escape route: 1. On the Configuration tab, navigate to Workflow > Escape Route. The Escape Routes screen appears. 2. In the Escape Route - Conditions area, specify the details of the escape route: a. From the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with other Access Control capabilities and you have enabled the Workflow Types on the Miscellaneous screen. From the Condition dropdown list, select Approver Not Found, Approver Not Found at a Stage, or Auto Provisioning Failure. From the Path dropdown list, select the path that the request follows if the conditions are met. From the Stage dropdown list, select the stage of the specified path that the request follows if the conditions are met. 3. Click Save. 4. From the Escape Routing Enabled dropdown list, select Yes if using escape routes or No if you choose not to use them. If you select No, the system ignores any escape route, even if some are configured. 5. Click Save. A Successfully Saved Escape Route Configuration message appears.

174

August 2010

Compliant User Provisioning SMTP Server Identification

SMTP Server Identification


To send notification emails to the users, requestors, and approvers of the requests, you must configure Compliant User Provisioning to use the correct mail server. Compliant User Provisioning communicates with approvers through email messages. If the SMTP server configuration is not done properly, CUP emails to notify requestors, approvers, and administrators are not delivered and the process stops.

Configuring the SMTP Server


Procedure 1. On the Configuration tab, navigate to Workflow > SMTP Server. The SMTP Server screen appears. 2. Enter the URL to be used for hyperlinks in e-mail notifications to open the application. Application URL If you have configured SAP Enterprise Portal to display CUP, enter the applications URL here. Redirection URL If you have configured your environment to use SSO with redirection, then enter the redirection URL here.

For more information, see the SAP Enterprise Portal help on the SAP Help Portal at http://help.sapcom. The system does not automatically send e-mails, you must run the Email Dispatcher background job. For more information, see the section Setting Up Background Jobs.

Configuring Generic E-mail Sender Account


You can configure the CUP SMTP server information so that all e-mails and notifications sent from CUP have a generic account as the sender. In the SMTP Server screen, under Enter Email Notification Sender, choose System Email ID, and enter the generic email address. Note Using a system e-mail ID affects all e-mail notifications originating from CUP.

CUA System Setting Configuration


This setting applies only to SAP implementations that employ a Central User Administration (CUA) system. CUA and Compliant User Provisioning work well together, so it is not necessary to choose between the two. There are reasons to use the CUA and reasons to use Compliant User Provisioning. CUA manages users and their access in the child systems. Compliant User Provisioning provides the access request ability, audit trails for the approvers on the requests, and provisions the approved roles to the CUA.

August 2010

175

Compliant User Provisioning CUA System Setting Configuration When a request is provisioned in Compliant User Provisioning and the CUA is used, Compliant User Provisioning provisions the requested roles to the CUA. The CUA pushes those roles down to the child systems. Compliant User Provisioning allows the CUA to manage the access in the child systems. You must create connectors and install the appropriate RTAs on those systems for the CUA parent system, as well as each of the CUA client systems. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3. Compliant User Provisioning performs all inquiries and searches against the child client itself; it only completes provisioning with the CUA parent. Requestors and approvers request and approve the access to the individual applications (child system clients), but you provision the access with the CUA. The CUA system setting can be a global setting in Compliant User Provisioning, or it can be set by each individual system connector. Therefore, some of your systems can be connected to a CUA and others not connected, but both can be provisioned through Compliant User Provisioning. Since most of the activity between the requestor and approver occurs directly within the application itself, the only difference is that a CUA client is where the user and roles are provisioned. If it is a CUA child system, provisioning happens on the CUA parent, whereas a non-CUA system provisions to itself. You must load roles for the CUA child clients into Compliant User Provisioning to make them available for the requestor to select them through the Select Roles functionality. Do not load CUA child system roles assigned to the CUA parent system into Compliant User Provisioning; load them only to the child systems.

Configuring the CUA System Setting


Procedure For organizations with complex SAP landscapes consisting of many SAP systems, SAP recommends that you use CUA for user administration tasks. Using CUA enables security administrators to maintain user master records centrally from one system. Compliant User Provisioning provides the ability to perform user provisioning centrally from one system, but it does not replace CUA. Compliant User Provisioning deals mainly with compliant automated provisioning. To configure Compliant User Provisioning with CUA properly, you must: Configure connectors for the master system and child system(s) Configure the CUA master system Perform troubleshooting, if needed

Configuring Connectors for Master System and Child System Procedure To configure connectors in Compliant User Provisioning: 1. Make sure that the connector names in Compliant User Provisioning are exactly the same as the logical system names defined in the CUA master and child systems.

176

August 2010

Compliant User Provisioning CUA System Setting Configuration From your SAP server (back-end system), start transaction SCUA. The Maintain System Landscape appears. The name displayed in the Sending System field is the master system, while the child systems are listed in the Recipient column. 2. Configure the master system. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 3. In the Connector Type dropdown menu, select SAP. 4. In the Name field, enter the logical system name of the CUA master system. 5. In the User ID field, enter the user ID you are configuring to have access to the backend system. The user ID must have the appropriate security access to perform each of the tasks required. If provisioning is configured for this connector, the user ID must be authorized to maintain users in the SAP system. If provisioning is configured, this user ID appears on each change record on the SU01 user master record. For more information about user ID authorization, see the SAP GRC Access Control 5.3 Security Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3.

Ensure that the user ID associated with this name has the proper access to view/maintain the SU01 user records. 6. In the SAP Version dropdown menu, select the appropriate SAP version. Compliant User Provisioning supports SAP 4.6C, 4.7, and ECC 6.0. 7. In the HR System dropdown menu, select Yes or No to indicate if an SAP HR system is used or not. An HR system flag indicates whether the SAPHR module is installed on this connector, not necessarily whether you are using the SAPHR module. If the system is an HR system, the appropriate HR RTAs must be installed. For more information, see the SAP GRC Access Control Installation Guide. 8. In the SLD Connector checkbox, select this checkbox to enable the Standard Landscape Directory. 9. In the Connector Category dropdown menu, select the category to which the connector belongs. The choices are Production, Non-Production, or Other. This selection is used to help classify the servers into the appropriate categories in the access request forms. 10. In the Role dropdown menu, select whether or not role information comes from Enterprise Role Management or the SAP backend. 11. In the HR Manager Path dropdown menu, do the following: a. If you are using SAPHR as the user details data source and want the Manager field value to be automatically populated from the users HR record, set this field to (B012) Managers. b. If you want the Reports to line value to be automatically populated from the users HR record, set this field to (A002) Reports (line) to (for organizational units). SAP HR provides an organizational structure view that contains the object, relationships, and attributes. The organizational structure view contains the relationship types, B012-Managers and A002- Reports to.

August 2010

177

Compliant User Provisioning CUA System Setting Configuration 12. Click Create. 13. Click Test Connection.

178

August 2010

Compliant User Provisioning CUA System Setting Configuration

Configuring CUA Master System In order to provision through the CUA system, the CUA master system name needs to be set in Compliant User Provisioning. Procedure To configure Compliant User Provisioning with CUA: 1. Go to Compliant User Provisioning > Configuration tab > Workflow > CUA System. The CUA System screen appears. On the Global tab, the Systems dropdown menu displays a list of all SAP systems configured as connectors. Make sure that the master system and child system/client are created as an SAP connector.

2. On the Global tab, select the correct system as your CUA parent system. 3. Click Save. If your system does not use a CUA, the configuration is finished. If your system does use a CUA, continue with the next steps. 4. In the Function Template fields of both the CUA User Provisioning Configuration and CUA Role Provisioning Configuration areas, select either Standard or Custom. Select Standard triggers Compliant User Provisioning to use out-of-the-box programs for CUA provisioning. Select Custom if you have developed custom CUA BAPIs. If you are using custom BAPIs, contact SAP Technical Support to ensure that your BAPIs integrate correctly with Compliant User Provisioning. If your environment uses a CUA system, select the CUA host from the list of connectors. If your environment does not use a CUA system, make sure that there is no host selected. The System dropdown menu should show, --Select--.

If you select Custom in either area, the Function Template Name field appears. 5. Enter the name of your custom template. 6. Click Save. 7. On the By System tab, you can overwrite the global CUA setting for any or all system connectors. To add another system to this table, click Create. To change an existing CUA system configuration, select the system and click Change. All available fields for changing appear editable.

8. If you have selected Create, select the other system you wish to add from the System dropdown menu,. 9. In the Consider For CUA field: If the system is a child client using a CUA, select Yes. If the system is not using the CUA select No.

August 2010

179

Compliant User Provisioning CUA System Setting Configuration 10. In the CUA System field, if the system is configured as a CUA child client, select the system connector. 11. You can configure multiple CUAs. To do so, select the CUA system that is connected to the child system you are maintaining. 12. For each field, User Provisioning Function Template and Role Provisioning Function Template, select Standard or Custom. If you select Custom for either field, a Function Template Name field appears. 13. Enter the template name. 14. Click Save. Troubleshooting for CUA Provisioning You can troubleshoot any issues concerning CUA provisioning from Compliant User Provisioning. Procedure To troubleshoot CUA provisioning from Compliant User Provisioning: 1. From your SAP server (backend system), start transaction SU01. Make sure that the Compliant User Provisioning service role /VIRSA/AE_DEFAULT_ROLE delivered with the RTA, or an equivalent customized (Z) role copied from the role that you defined previously, is assigned to the service user ID in the connectors for all master and child systems. 2. If step 1 is not successful, you can also modify the application name and short description of the connectors to be the same as the connector name. Go to Compliant User Provisioning > Configuration tab > Connectors > Available Connectors. 3. Select the connector and click Change. 4. Modify the entries in the Short Description and Application fields to be the same as the Name field. 5. Click Save.

180

August 2010

Compliant User Provisioning Provisioning

Provisioning
You can provision the following roles and user groups to existing users SAP UME user groups SAP UME and SAP Portal roles LDAP user groups Process 1. Create and configure a connector. 2. Configure field mapping. 3. Import the groups and roles. 4. Provision the users in CUP.

The following sections describe the specific steps required to configure the connectors for provisioning. For more information about standard functions such as creating connectors, adding fields, and importing , see the following sections: Defining Connectors, Field Mapping, and Importing Roles.

Configuring Provisioning for SAP UME User Groups, UME Roles, and SAP EP Roles
This feature enables you to provision existing SAP UME user groups, UME roles, and SAP EP roles to existing users. Prerequisite The users to be provisioned in CUP must already exist in UME. You have completed technical installation of SAP Enterprise Portal on the NetWeaver instance of the UME system. You have installed AC 5.3 SAP Enterprise Portal RTA on the NetWeaver instance of the UME system. Note Enterprise Portal configuration is not required. Procedure 1. Create a connector. a. Click the Configuration tab. In the left navigation pane, select Connectors -> Create Connectors. b. Choose the Connector Type SAP EP. c. Add (+) the standard parameter names and parameter values. For more information, see Defining Connectors for SAP Enterprise Portal.

Make sure the following parameters and values are present. If they are not present, add them.

August 2010

181

Compliant User Provisioning Provisioning

Parameter Name ASSIGN_GROUPS:OC USER_DATA_SOURCE d. Click Create.

Parameter Value sapgroup See your UME system administrator for the value of the user data source.

e. Click Test Connection to make sure the connection is successful. 2. Configure field mapping: a. On the Configuration tab, click Field Mapping -> Provisioning. The Field Mapping screen appears. b. Click Continue and add the following AC Fields and Application Fields. AC Field Email Address STANDARD Telephone Number STANDARD User FName STANDARD User ID STANDARD User LName - STANDARD c. Click Save. 3. Import the UME groups, UME roles, and SAP EP roles and assign the required role/group attributes. For more information on importing roles and groups, see Importing Roles. Note You must assign attributes for all user groups before you can use them in the role/group selection search. 4. Provision the users. For more information, see the Access Control 5.3 Application Help. Application Field email mobile firstname logonname lastname

182

August 2010

Compliant User Provisioning Provisioning

Configuring Provisioning for LDAP User Groups to Users


You can provision existing LDAP user groups to existing users. You do this by creating a standard LDAP connector and linking the LDAP connector to the SAP EP LDAP connector. Note If you have an existing LDAP connector, and would like to provision user groups to this connector, you do not need to create a new one. You can configure the LDAP mapping in the connector to link it to the SAP EP LDAP connector.

Procedure 1. Create a standard LDAP connector. For more information, see the Defining Connectors for LDAP. 2. Configure LDAP mapping. a. Add the following Additional Fields: GROUPOBJCLASS GroupDescription GroupMember GroupName USERNGROUP validToDate group description memberOf name member accountExpires

b. Click Save.

3. Create the SAP EP LDAP connector. a. Log on to CUP -> Configuration -> connectors -> Create Connector. b. Click Connector Type and select SAP EP LDAP. c. Select the Internal LDAP and External LDAP systems. Note If you have only one LDAP, it can be used for both internal and external.

d. Add the LDAP_GROUPS parameter name and set the parameter value to YES. e. Click Create. f. Click Test Connection to make sure the connection is successful

4. Import the user groups via template. Caution Import user groups by uploading a template file. Do not import directly from the system.

August 2010

183

Compliant User Provisioning Provisioning

Note You need to add the Group_Type data to the CustomAttributes column in the template as shown below. You can specify Internal or External as values for external or internal LDAP. CustomAttributes(Custom Fields for the Role) GROUP_TYPE|INTERNAL GROUP_TYPE|EXTERNAL 5. Provision the user groups. For more information, see the Provisioning in the Access Control 5.3 Application Help. Note Make sure you select the EP LDAP for the Select Application step.

184

August 2010

Compliant User Provisioning Auto Provisioning

Auto Provisioning
Compliant User Provisioning automates the collection of approvals for access and also automatically provisions access to the target back-end system(s). Auto provisioning can be done either globally or by system. Auto provisioning is optional, but it is activated by default. If you do not want to use this functionality, select No for Auto Provisioning. Auto provisioning is only available to SAP systems and non-SAP systems supported with RTAs. Non-RTA systems, such as legacy systems, can only be provisioned manually. Auto provisioning can occur on the SAP User Master Record (transaction SU01), which is referred to as Direct Provisioning, or against the SAP HR system. If you configure an HR job or position-based security, this is called Indirect Provisioning. If you do not use SAP HR, you must use Direct provisioning. This method allows Compliant User Provisioning to directly modify the users master record, changing the users assigned permissions as defined in the request. If you use SAP HR and still assign security roles directly to the user, select Direct Provisioning. If you assign security roles based on the users HR organizational position, use InDirect provisioning. In InDirect provisioning, Compliant User Provisioning sends a request to the SAP HR module, and SAP HR performs the actual provisioning. If you do not want to launch the provisioning process, you must define this setting as Do Not Autoprovision.

All passwords for new users and changed user information are generated by Compliant User Provisioning using the auto provisioning mode or manual provisioning mode.

Configuring Global Settings for Auto Provisioning


Procedure To configure global settings for auto provisioning: 1. On the Configuration tab, navigate to Workflow > Auto Provisioning. The Auto Provisioning screen appears, displaying the Global tab. 2. Under Auto Provisioning Provisioning Type, from the Default Role Provisioning Type dropdown list, select the type: Direct: Most companies use Direct provisioning. This method allows Compliant User Provisioning to modify the users master record directly, changing the users assigned permissions as defined in the request. Indirect: If you select InDirect, you must select the type of HR object Compliant User Provisioning needs to transmit to the HR module. There are three possible object types: Position, OrgType, and Job.

August 2010

185

Compliant User Provisioning Auto Provisioning Combined: During provisioning, the system tries to use InDirect provisioning. If it fails, it tries Direct provisioning. If you select Combined, you must select the type of HR object Compliant User Provisioning needs to transmit to the HR module. There are three possible object types: Position, OrgType, and Job. These settings can also be configured by system. For more information, see the section Configuring Auto Provisioning by System. 3. Under Auto Provisioning Provisioning Options, from the Auto Provisioning Type dropdown list, select the type: Auto Provision At End of Request: Select this option to begin provisioning when all of the workflow paths in the submitted request are approved. Auto Provision At End of Each Path: Select this option to provision the access requested for each path as the path is approved. This method works only when the request splits into parallel workflows. No Auto Provision: Select this option to turn off auto provisioning 4. Under Auto Provisioning Provisioning Change Request Options, select one of the following values from the Create If User Does Not Exist dropdown list: If you want the provisioning process to automatically create the user, select Yes. If you do not want the provisioning process to automatically create the user, select No. This setting is used only for requests of type Change and only where there is no record of the user. 5. Under AccountValidation Check, choose the following: Enable Account Validation Check CUP checks if the account exists in the target system selected for access before: o o o o Processing new requests. Changing or modifying existing requests. Deleting requests. Lock or unlocking requests.

Select Warning or Error Warning displays a message and the option to continue. Error displays a message, and the error must be corrected before you can continue.

You can use account validation for delivered standard request types and custom request types. The custom request types must not contain conflicting provisioning actions. Account validation is ignored for the following conflicting provisioning actions: o o o o CREATE_USER and CHANGE_USER CREATE_USER and LOCK_USER CREATE_USER and UNLOCK_USER CREATE_USER and DELETE_USER

6. Under Provisioning Old Roles Delimit Duration, enter the length of time in the Years, Months, and Days fields for transitioning from an old position to a new position.

186

August 2010

Compliant User Provisioning Auto Provisioning Use this setting with SAPHR indirect provisioning only. 7. Under Password Expiration for ORAAPPS, select the basis on which the password expires: after a certain number of days, accesses, or not at all. If you select Days or Accesses, a field in which you can enter the number of days or accesses becomes active. 8. Under Provisioning Role Assignment, from the Provisioning Effective Immediately dropdown list, select: Yes for the provisioning to take place immediately No for the provisioning to take place at a later time If you select Yes, this runs the User Compare feature in the SAP system after provisioning. If you select No, the User Compare feature in the SAP system does not run.

Configuring Auto Provisioning by System


In this case, all the global auto provisioning features are superseded by the system settings. Procedure To configure auto provisioning by system: 1. On the Auto Provisioning screen, click the By System tab. The By System configuration screen appears. 2. Click Create. At the bottom of the screen, a number of fields appear. You can make the following choices: System: Select the system in which you want to enable specific system settings for auto provisioning. Default Role Provisioning Type: Select Direct, InDirect, or Combined. Select InDirect or Combined only if your SAP environment includes the SAP HR module and you want to use SAP HR to perform provisioning on the HR record instead of on the users master record; otherwise, select Direct. If you select Direct, the InDirect Provisioning Type dropdown list appears dimmed, and you cannot select an HR object type. If you select InDirect or Combined, you must select the type of HR object Compliant User Provisioning needs to transmit to the HR module from the Indirect Provisioning Type dropdown list. Indirect Provisioning Type: Select Jobs, Position, and OrgType. This setting is available only if you select Indirect or Combined for the previous field. Create If User Does Not Exist: Select Yes if you want the provisioning process to automatically create the user. Select No if you do not want the user automatically created. Provisioning Old Roles Delimit Duration: Enter the length of time for transitioning from an old position to a new position. Use this setting only with SAPHR indirect provisioning. Password Expiration for ORAAPPS: Select the basis on which the password expires: after a certain number of days, accesses, or not at all. If you select Days or Accesses, a field in which you can enter the number of days or accesses becomes active.

August 2010

187

Compliant User Provisioning Approvers Provisioning Effective Immediately: Select Yes if you want the provisioning process to be in effect immediately. Select No if you do not want it to start immediately. 3. Click Save.

Approvers
You can define approvers in a variety of places based on the workflow approver choices. After approver determinators are selected on a stage, the administrator must maintain those approvers by attributes in Compliant User Provisioning. The Approvers option defines a user ID as an approver. The Approver feature stores the approver information on the following attributes: Defining security lead In general, the security lead is the person(s) responsible for the security of a particular system(s). Defining point of contact (based on functional area) The contact person for a functional area is someone whose role is responsible for that particular business module. Defining application approver The application approver is based on the connector type you defined in the Application Configuration screen. This person is responsible for the application type. Defining distribution group You define the distribution group(s) in the Distribution Group option. This distribution group is associated with one or more distribution list. Defining distribution list approver You define the distribution list, which contains the names of approvers for a stage that requires approval for role assignment.

The approvers you define with this option become part of the workflow approval process. When a request needs approval at a particular stage, Compliant User Provisioning uses the defined approvers to forward the request. For example, you can define an approver and alternate approver for the standard approver (Security, Point of Contact, Application approver, and Distribution Group) or create your own approvers by configuring a Custom Approver Determinator (CAD). This CAD can be based on attributes such as functional area and company, for a workflow stage. You can manually add a user ID as an approver by using the Search feature or import a text file containing user IDs of approvers. You then select an approver and alternate approver. Defining an alternate approver ID is mainly used for the workflow escalation process. You define an alternate approver for Security, Point of Contact, and Application approver. Example When you create a workflow stage using Stage Configuration screen, you set the Workflow Type to CUP, which is a standard workflow type. You then set the Approver Determinator to Security. In the Request Wait Time (Days), enter the amount of days you want the approver to respond. Enter 1 for one day. In the Escalation Configuration field, you select Forward to Alternate Approver. You also configure a background job to send email notification for escalation. So after a day that the approver did not respond to a request, Compliant User Provisioning sends a notification email to the alternate approver that you defined in the Security Approver screen. Make sure that the user IDs for the approver and alternate approver exist in whatever search data source you have configured. The only approvers that must be defined are those that are used as approver determinators in the stages of your workflows.

188

August 2010

Compliant User Provisioning Approvers Only add alternative approvers for those approvers whose stage is set with their Approver Determinator and the stage is set for escalation to alternative approvers. If you do not use escalation to alternative approvers, there is no need to add alternative approvers.

Security Leads
The Security Lead option defines a group email address, a primary security lead (Approver ID), and alternate security lead (Alternate Approver ID). The security lead is a standard approver determinator that is available for selection during the creation of any stage.

Configuring a Security Lead


Procedure To configure a security lead: 1. On the Configuration tab, navigate to Approvers > Security Lead. The Security Lead Approvers screen appears. 2. In the Group Email Address field, enter the security group email address. Specifying the Group Email Address sends the email notification to the securitys group email address, instead of sending the email notifications to each security team member individually. 3. In the Approver ID field, enter the user ID you want to assign as the primary security lead. You can use the Search icon to query for the user ID. 4. In the Alternate Approver ID field, enter the user ID you want to assign as the alternate security lead. This field is necessary only if you are using the escalation of that stage. 5. Click Save.

Point of Contact
After you define a functional area, assign a Point of Contact (POC) Approver to this business module. The Point of Contact option maps a functional area to a user ID, designated as the primary contact and primary approver, as well as an alternate approver for escalation purposes. The Functional Area is one of the standard fields on the Access Request screen. During the request access process, when the requestor selects a Functional Area, the POC approver is automatically specified. You can assign multiple approvers to a functional area. The POC is a standard approver determinator that is available for selection during the creation of any stage. You can select from the options on the Functional Areas dropdown list on the Roles > Attribute screen.

Configuring Point of Contact Approvers


Procedure 1. On the Configuration tab, navigate to Approvers > Point of Contact. The Point of Contact, Approver Information screen appears.

August 2010

189

Compliant User Provisioning Approvers 2. Click Create. At the bottom of the Functional Area column, a dropdown list is activated and two empty fields appear under the Point of Contact and Alternate Point of Contact columns. 3. In the Functional Area column, select a functional area from the dropdown list. 4. In the Point of Contact column, enter the User ID to assign a primary POC approver. You can also enter a Group of Approvers, if desired. You can click the Search icon to query for the desired user ID. 5. In the Alternate Point of Contact column, enter the User ID to assign the alternate POC approver used for escalation. You can click the Search icon to query for the desired user ID. 6. Click Save.

Application Approvers
The Application Approvers option defines the application approver and alternates. The application approver is a standard approver determinator that is available for selection during any stage creation. Application approvers must be defined only in the determinator used in a stage. The list of options in the dropdown list is the applications configured as connectors, which are configured on the Request Configuration screen.

Configuring Application Approvers


Procedure To configure an application approver: 1. On the Configuration tab, navigate to Approvers > Application. The Application Approver, Approver Information screen appears. 2. Click Create. A dropdown list and two empty fields become active in the Application, Approver ID, and Alternate Approver ID columns. 3. From the Application dropdown list, select the desired application. 4. In the Approver ID column, click the Search icon to query for the user ID as the primary approver. You can also add a Group of Approvers. 5. In the Alternate Approver ID column, click the Search icon to query for the user ID of the secondary approver (if using escalation). 6. Click Save.

Distribution Group
The Distribution Group option allows you to define the grouping of all available distribution lists. You can have several distribution lists in a group. The distribution group can be used to categorize all distribution lists that are used in the approval workflow process.

190

August 2010

Compliant User Provisioning Approvers

You can create a distribution group for only those distribution lists that exist in your LDAP directories. For detailed information on how to configure an LDAP directory, see Defining Connectors for Compliant User Provisioning in this section. Configuring Distribution Groups Procedure To configure distribution groups: 1. On the Configuration tab, navigate to Approvers > Distribution Group. The Distribution Group screen appears. 2. Click Create. The Groups screen appears. 3. In the Group field, enter the name of the distribution group. 4. In the Short Description field, enter a brief description of the distribution group. 5. In the Description field, enter a long description of the distribution group. 6. In the Type dropdown menu, select the type of distribution group, Distribution List. 7. Click Save.

DL Approvers
The DL Approvers option allows you to add a distribution list to your distribution group. Associating the distribution list with a distribution group enables you to assign a distribution list of approvers to a workflow stage where roles are assigned. if, for example, you want approval to assign the role Z_AP_Payable to a user, you can search for this role using Search Role and configure the Role Approver by specifying a distribution group. This distribution group can have more than one distribution list. When a role stage receives the request for approval of Z_AP_Payable, the request is forwarded to all approvers in the distribution list associated in the distribution group. Configuring DL Approvers Procedure To configure distribution groups: 1. On the Configuration tab, navigate to Approvers > Distribution List. The DL Approvers screen appears. 2. In the Group dropdown menu, select the desired distribution group. 3. Click Add. The Group Approvers screen appears. The Group name is pre-populated in this first field. 4. In the Distribution List Name field, enter the name of the distribution list. 5. In the DL Connector dropdown menu, select the connector name, which is the source for the distribution list. Currently, only LDAP directories are supported as a DL connector. 6. Click Add.

August 2010

191

Compliant User Provisioning Stale Requests

Stale Requests
Compliant User Provisioning allows you to close any older request in the system that has been waiting for an approver for a long period of time. Older requests are considered Stale Requests. Stale Requests can be processed and closed after a specified number of days. 1. On the Configuration tab, navigate to Requests > Stale Requests. 2. From the Action dropdown list, select Enabled or Disabled. 3. In the Number of Days field, enter the number of days that requests must wait before the action is executed. 4. Click Save. You must schedule a background job to review all open requests against the Stale Requests settings. Any request that meets the Number of Days configuration setting is automatically closed.

Request Administration
On the Request screen, you can review and process requests on behalf of other approvers. You can also archive old requests to exclude those requests from current searches and reporting.

Approver Delegation
On the Approver Delegation screen, an administrator can delegate work on the behalf of other users. The administrator can select the following: An approver by Approver ID, first name, last name, or e-mail address. A delegated approver by ID, first name, last name, or e-mail address. Validity dates for the delegation. You can assign multiple delegates for the same user. Make sure the validity dates do not overlap The approver delegations affect only new requests. Previously created requests are not automatically forwarded to the delegate.

Administration
On the Administration screen, you can access any open request in the system to approve, reject, forward, reroute, or cancel the request. When an administrator processes a request, the audit trail records the administrators user ID and the task performed. Access to the Administration screen is controlled by User Management Engine permissions. Use caution when granting users access to the Administration screen. From this screen, a user can approve and/or reject any request in the system at any stage along any path. The result could be that a request bypasses one or more required approval stages.

Archive
Archiving Requests is a way to view only the current periods requests during normal viewing.

192

August 2010

Compliant User Provisioning Request Administration All requests for access are stored in the Compliant User Provisioning database. The system closes the requests after they are approved or rejected. The Archiving Requests functionality helps you archive the closed requests. The archived requests remain in the database but are not visible when the users run searches or reports. 1. On the Configuration tab, navigate to Archiving Requests. 2. The Last Archived Date field displays the current date, indicating when the records are archived. 3. From the Date From dropdown list, select the oldest date of the closed records you want to archive. 4. From the Date To dropdown list, select the most current date of the closed records you want to archive. 5. You can search the archive records by enabling the Archive Request flag when performing the search. The Archive Request flag is located on the Search Requests and Search Audit Trail screens, as well as on the Informer Reports.

August 2010

193

Compliant User Provisioning User Review

User Review
User review allows designated approvers to review the access assigned to a user and the segregation of duties risks violated by a user. These two procedures are referred to as User Access Review and User SoD Review. For information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/grc -> Access Control -> SAP GRC Access Control 5.3.

Features Options You configure review parameters such as reviewer, require admin review, review instructions URL, and so on. Coordinator Choose a coordinator for each reviewer. Access Control uses the coordinator information to generate reports you can use while managing the review process. Request Review Administrators can review requests, and choose to cancel them or change the coordinator and reviewer roles. Manage Rejections Authorized users can search for rejected users, and generate or cancel review requests. Reason for Rejection You configure the rejection reasons, descriptions, and reason codes. UAR Load Data Tasks Create tasks to enable selective user access reviews based on role attributes such as, criticality and names, or user attributes such as, user ID and user groups.

194

August 2010

Compliant User Provisioning User Review

Performing User Access Reviews


The User Access Review (UAR) feature provides a workflow-based review and approval process for user access requests. The periodic reviews of user access are performed by business managers or role owners, and the system automatically generates the requests based on the companys internal control policy. Features An automated process for the periodic access review. Decentralized review of user access. Workflow of requests for review and approval. Automatic role removal, if desired. Status and history reports to assist in monitoring the review process. Audit trail and reports for supporting internal and external audits. Support for back-end systems integrated with Access Control as well as legacy systems.

Use of the user UAR feature requires configuration in multiple capabilities. The information in this section provides details about the user access review feature, its process options, configuration, and use. Capability ERM RAR CUP Configuration You configure system connectors. This is required for transaction usage and for user-role assignment information. You configure connectors. This is required for alert generation to provide transaction usage information. You define connectors, configure UAR, configure workflows, and define coordinators.

Review Process This section discusses the review process. It also discusses options in the process that require you to decide how to implement the review process. The next section will discuss how you configure the system to reflect your chosen process. Process The high-level process for user access review is as follows. o o o o Access review requests are generated. E-mail notifications are sent to reviewers. Requests are reviewed and actions are noted by the reviewer. Roles marked for removal can be deprovisioned from the back-end system(s)

August 2010

195

Compliant User Provisioning User Review Roles in the UAR Process Administrator: This person has the AE_Admin UME role assigned for Access Control. They can perform general CUP administrator tasks in addition to UAR-specific administrator tasks, such as cancelling UAR requests and regenerating requests for rejected users. Users Manager: Role Owner: The direct manager of a user as defined in the User Details Data Source.

The role owner specified in CUP master data.

Reviewer: This term refers to the approver at the Reviewer stage. The Reviewer may be the users manager or the role owner. Coordinator: The Coordinator specified in CUP master data. The Coordinator is assigned to Reviewer. They monitor the UAR process and coordinate activities to ensure the process is completed in a timely manner. Process Options You choose from multiple process options to determine the approvers of the UAR requests. Admin Review

You decide whether to enable Admin Review. This configuration option provides an opportunity for the administrator to validate the request data after the requests are generated (by the UAR Load Data job) but prior to generating workflow tasks (by the UAR Update Workflow job). If the Reviewer information is incorrect or missing, the administrator can modify the data prior to generating workflow tasks and notifications. The administrator can also delete requests. Reviewer Stage You decide whether the Reviewer stage will be addressed by the Users Manager or the Role Owner. Security Stage

You decide whether to have a security stage. A security stage is mandatory if you do not have automatic provisioning enabled. The security stage may be desired even when automatic provisioning is enabled so that security personnel can ensure accurate data prior to provisioning. If a security stage will be included in your approval workflow, you must decide whether security personnel will be able to modify the direction previously noted by an Approver. For instance, a security team member may decide to retain basic roles that have been inappropriately marked for removal by an approver. Additional Approver Stage

You decide whether you will have an additional stage with the approver derived by a Custom Approver Determinator (CAD). The fields available in the UAR CAD differ from those available in the standard CUP CADs. The fields available are in the UAR CAD are: o o o Application Request type Role(s) being reviewed

Instruction for 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 since it is an infrequent process and may involve reviewers who do not perform routine approval of requests to create or change accounts.

196

August 2010

Compliant User Provisioning User Review 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 here.

Workflow Stage Configuration Now that you have decided which stages to include in your UAR workflow, you must decide on specific behavior for each stage to reflect your review process. The items to be addressed in configuration are: Email Notification Reminders Escalation

Email Notification You decide on the content of email notifications to be sent to the approvers at each stage. You determine the recipient(s), the content of the notification header and the email body. For more details, see the Email Notification section. Reminders You decide whether to send reminders to the reviewers who have not completed their portion of the request by the date specified in configuration. You can specify the interval of reminder notifications in days, the reminder notification header, and body content. For details on configuring reminders, see the E-mail Reminders section. Escalation You decide whether to escalate UAR requests in each stages details. Therefore, escalation is based on the time spent in a particular stage. If a reviewer does not complete their review of a request according to the date parameter defined in configuration, then the request is escalated. Escalation of a request will show in the requests audit trail. You also determine whether escalation will include automatically removing access that is not approved by a certain date. Automatic Provisioning You decide whether to automatically provision requests at the end of the requests workflow. If chosen, roles that are marked for removal in the User Access Review will be automatically de-provisioned in the target system. If you do not choose to automatically provision, a security stage must be placed in the workflow to allow the security team to modify access according to the review. Page 197 of 397

Compliant User Provisioning User Review Configuration and Master Data This section contains Instructions for configuring the UAR and providing the necessary master data. Alert Generation in RAR There are two methods for providing role usage information for UAR requests: You can define connectors and execute alert generation in RAR. You can define connectors only in ERM and upload role usage and role assignment information there.

Back-end Systems with RAR Connectors and RTAs Alert Generation data in Risk Analysis and Remediation provides the foundation of the usage information in the User Access Review requests for connected back-end systems. To allow the system to obtain usage information automatically, you must configure alert generation and execute the alert generation job in RAR. If there is no alert generation information obtained from RAR by the ERM Role Usage Synchronization job, you must upload role usage information in ERM or the usage column in UAR requests will contain zeroes (0). For Access Control to automatically obtain the transaction and role usage information, please ensure that the connector ID in RAR is identical to the connector ID in CUP and the system (connector) ID in ERM.

Back-end Systems without RAR Connectors and RTAs You may upload role usage information for the back-end system when you upload role assignment information in ERM. Please refer to the following section on Role Usage Synchronization. Role Usage Synchronization in ERM The Role Usage Synchronization job in ERM provides role usage information and the user to role relationship for the user access review. The usage of each role is calculated from the action usage data of the Alert Generation job in RAR and the actions defined in each role. For each back-end system to be included in the UAR review, the role assignment information must be either obtained from the back-end system using a real-time agent or uploaded manually. Either approach requires definition of a system (connector) in ERM. You define ERM connectors in Configuration > System Landscape > Systems.

198

August 2010

Compliant User Provisioning User Review

Configuration and Master Data in CUP


1. Upload Initial Data File for UAR Ensure that the AE_init_append_data_ForSODDUARReview.xml file has been uploaded in Configuration > Initial System Data. This .xml file is one of the initial data files included with Access Control. Support Packages may deliver subsequent versions of the initial data files and you must be sure that you have the data files that correspond to your AC support package level. Upload the specified initial data file in CUP using the Append option. If you are configuring a new Access control installation, then you will need to upload all initial data files. 2. Activate the UAR Workflow Type You must activate the UAR Workflow Type, which was created by the initial data files. If the workflow type is not available, you may need to upload the AE_init_append_data_ForSODDUARReview.xml file again. a. Navigate to Configuration > Miscellaneous. b. c. In the Workflow Types pane, maintain the entry UAR_REVIEW. In the Active indicator field, select the indicator to enable the connector.

Note The Exit URI, User Name, and Password fields are not required for User Access review.

3. Activate the UAR Request Type The initial data files include the UAR_HIGH request type. 1. Go to Configuration > Request Configuration > Request Type. 2. Select the UAR_REVIEW request type and select Change. 3. Maintain the descriptions. 4. Ensure that the Active indicator is selected.

4. Confirm Request Priority Confirm that the UAR_HIGH priority is present and is associated with the UAR Workflow Type. Navigate to Configuration > Request Configuration > Priority.

5. Confirm Active 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(s). Go to Configuration > Number Ranges to maintain number ranges. 6. Configure User Data Source There are multiple types of data sources in CUP. You must identify a Search Data Source to be the source of all user IDs returned when performing a search. You may also identify a User Details Data Source that will be the source of all user-to-manager relationships. Go to Configuration > User Data Source to configure both types of data sources. For more information, see the User Data Source Definition section. Page 199 of 397

Compliant User Provisioning User Review 7. Configure User Review Configuration Options Go to Configuration > User Review > Options and specify the parameters for the UAR requests to be generated in the User Review pane. Admin review required before sending tasks to reviewers Maintain this parameter based on the decision made when considering the process options. o Yes: The administrator reviews the UAR requests prior to the generation of workflow tasks. The administrator makes the required approver modifications and cancels any UAR requests that are not desired. No: The administrator does not have an opportunity to review UAR requests prior to sending the workflow notifications to reviewers.

Note: If there are user records without a manager identified in the User Detail Data Source, then you must enable Admin Review to generate requests. Who are the reviewers? o o Manager represents the manager of the user as identified in the User Detail Data Source. Role Approvers represents the role approver identified in Compliant User Provisioning master data.

8. Configure Rejection Reasons Rejection reasons are mandatory when rejecting a review request. You must upload the reason codes and descriptions using a template. Procedure 1. Go to Configuration -> User Review -> Reason for Rejection. The Reason for Rejection screen appears. 2. Under Import Rejection Reasons, click Download Template. The template opens in Excel. 3. Complete the required information and save the template. Field ReasonCode (required) Max Field Length 10 characters Recommendation All UPPER case No special characters, no spaces Have some desired value. Yes/yes/y/YES/Y No/no/n/NO/N ( When empty default value No) Letters and numbers Possible Values Letters and numbers

ReasonEnable

n/a

ShortDescription_xx ( XX language code such as EN, DE etc. )

100 characters, including spaces

Recommended to have some desired value for at least for application default language

4. Under Import Rejection Reasons, click Browse.

200

August 2010

Compliant User Provisioning User Review 5. Select the Rejection Reasons file and click Import. Note You cannot delete reason codes from the application. To deactivate a reason code, populate the ReasonEnable field with No, choose the Overwrite Existing option, and import the upload file. 9. Configure Workflow You can configure a UAR workflow based on your organizations requirements. For example, the UAR workflow may consist of a primary path with a single stage for Reviewer approval and a detour path. A common detour path has a single stage for Security approval with a detour condition for action of Marked for Removal. Process 1. Define an Initiator. Select UAR as the Request Type. For more information, see Workflow Management > Initiators. 2. Define Stages (one stage for Reviewer and another stage for Security). Compliant User Provisioning provides two standard approvers for the UAR process. The first is the Reviewer, which can be the users manager or the role owner. The second is Security. Optionally, you can define a Custom Approver Determinator (CAD) for a custom approver if an additional approver/stage is required. Caution For stages with Risk Analysis Mandatory set to Yes, then Display Review Screen must also be set to YES. Otherwise, risk analysis will be bypassed. For more information, see Workflow Management > Stages. 3. Define the review paths (the example configuration has a primary path for the Reviewer and a detour path for Security). For more information, see Workflow Management > Paths.. 4. Define a Detour with condition. Select Items with Remove Action for the Condition and choose Yes for the Value. For more information, see Workflow Management > Detour Paths. 5. (optional) Define Email Reminder You define whether notifications will be sent for UAR requests upon request submission, upon request close and as reminders. You may define the timing for reminder notifications and the content for the relevant notifications. For more information, see Workflow Management > D Email Reminder. 6. Configure Auto 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 global. If CUP is being used, then provisioning for the user access review should follow your corporate policy for autoprovisioning. For more information, see Auto Provisioning section. 10. Configure Service Level (Escalation) You may define the conditions that will cause an escalation, the action taken for the escalation and the content of the escalation email. For more information, see Service Level. 11. Configuring an SMTP Server Page 201 of 397

Compliant User Provisioning User Review CUP uses an SMTP server to send email notifications and reminders to users, requestors, and approvers of requests. Emails are not sent automatically. To send the emails, execute the Email Dispatcher background job. For more information, see Setting Up Background Jobs. If this setting is not properly configured, the entire approval process might be jeopardized. If approvers are not getting the email notifications that a request is waiting for their approval, the approvers must log on to Compliant User Provisioning and check their email. For more information, see Workflow Management > SMTP Server.

12. Configure Field Mapping If you are using an LDAP as the User Detail Data Source and UAR requests will be approved by users managers, then you must specify a field mapping for Manager so that Access Control can determine the reviewer for workflow. You define this in Configuration > Field Mapping > LDAP Mapping. If you are auto-provisioning as part of the UAR process, you must perform field mapping for provisioning. You define this in Configuration > Field Mapping > Provisioning. For more information, see the Field Mapping. 13. Configure Security Lead You can specify a group email or approver IDs to be used in the security approval stages. On the Configuration tab, go to Approvers > Security Lead to configure the security lead information. For more information, see Approvers > Security Leads. 14. Configure Coordinator You identify a Coordinator for each Reviewer, regardless of whether the reviewer is a Users Manager or a Role Owner. Access Control uses the coordinator information to generate reports that can be used while managing the review process. For more information, see User Review > Coordinator. 15. Defining Connectors For each back-end system to be included in the user access review, you must define a connector. The Connector ID in CUP must be identical to the System (connector) in ERM so that user-to-role relationship information may be transferred to CUP. It should also be identical to the system. For more information, see Configuration Tasks. 16. Import Roles Roles that will be included on the UAR requests must be imported into CUP so that role descriptions can be provided in 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.

In your development system, where you create roles to transport, there might be some roles used for testing which you do not want users to request. If you do not import these roles, they are not available for selection, approval, and provisioning.

202

August 2010

Compliant User Provisioning User Review For SAP systems: If you do not want users requesting access to SAP_ALL in your production system, do not import SAP_ALL for the production system.

For more information, see Roles > Importing Roles. 17. Configure UME Security You must assign UME actions to the appropriate individuals. UME actions are used to manage the rejected user process. These actions were provided in the initial data files.. For more information about the general security requirements for Access Control, see the Access Control 5.3 Security Guide.

UME Action ViewManageRejectionReasons ViewRejectUsers ViewManageRejections ManageRejectionsGenerationAction ManageRejectionsCancelGeneration Action

Permission Included Provides the ability to configure Rejection Reasons to be used in reviews Enables the Reject Users button in review requests Provides the ability to view the Manage Rejections functionality for UAR Provides the ability to generate new requests for rejected users Provides the ability to cancel the generation of new requests for rejected users

UAR Request Creation Identified below are the steps and jobs executed to generate requests for the periodic user access review. (Please note that generating new requests for users rejected from earlier requests is discussed in the section Managing Rejected Users) Before beginning the user review process, all supporting information for generating requests should be current to ensure accurate workflow of requests. For example, if the Reviewer is configured to be the Users Manager, then the user to manager relationships should be current in the detail data source. Note If there are users with no manager identified in the User Detail Data Source and the Reviewer is defined as the Users Manager, then Admin Review is required. This allows the administrator to maintain the missing data prior to sending workflow tasks to reviewers. 1. Purge Usage Information If more transaction usage information is stored in RAR than is desired for User Access Review or SOD Review requests, then the data should be archived. For example, if your UAR process states that the prior twelve months usage information should be provided in UAR requests and RAR has fifteen months available, then the oldest three months information should be purged (archived) in RAR. 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.

Page 203 of 397

Compliant User Provisioning User Review This requires configuration of the location for writing the purge file in RAR Configuration > Miscellaneous > Alert Log File Name and Location. For more information on purging usage information, see the Risk Analysis and Remediation > Utilities section. 2. Configure Alert Generation Ensure that the RAR Alert Generation job has been executed if your role usage information will be obtained automatically rather than being uploaded. For more information, see Risk Analysis and Remediation > Scheduling Alert Generation. 3. Configure Role Usage Synchronization Configure the role usage synchronization task to synchronize user data from ERM and CUP. For more information, see Enterprise Role Management > Role Usage Synchronization. 4. UAR Review Load Data job Execute this job to retrieve user-to-role relationship and role usage data from ERM and create User Access Review requests. You execute the job in CUP by following the path Configuration > Background Jobs and selecting the task UAR Review Load Data. You can also create custom load data tasks to retrieve usage data batches based on parameters such as role criticality, role name, and so on. For more information see, Compliant User Provisioning> User Review > UAR Load Data Tasks. 5. Performing Admin Review The administrator evaluates the requests to ensure completeness and accuracy of the request information prior to sending workflow items to reviewers. If the requests are incomplete or inaccurate, you have the following options: cancel the current UAR requests maintain user-to-manager relationships in the User Details Data Source generate new requests.

Procedure 1. On the Configuration tab, navigate to User Review > Request Review. The search screen appears. 2. Search for requests and review the data to confirm accurate reviewer information. 3. To cancel an incorrect request, select a review request number and click the Cancel Request(s) button. If you choose to cancel a request, Access Control will ask you to indicate whether the users contained in the request(s) being cancelled should be marked as rejected users. Yes: The review request is cancelled. All users in the request are considered Rejected Users and their requests are available in the Manage Rejected Users screen to be regenerated. No: The review request is cancelled. All users in the request will only be included in another UAR request upon selection in execution of UAR Review Load Data job.

Note If you mistakenly choose to cancel a request and want the request to remain, select an item in the Configuration menu to exit the current menu option. Note If you wish to evaluate the users and roles included on UAR requests, you may query the table VT_AE_RQD_UAR_ROLE.

204

August 2010

Compliant User Provisioning User Review 6. Run the UAR Review Update Workflow Job After the UAR Review Load Data job has completed and you have performed Admin Review (if appropriate), you execute the UAR Review Update Workflow job to push the workflow tasks to the reviewers. In CUP, go to Configuration > Background Jobs and select the task UAR Review Update Workflow. For more information, see Background Jobs 7. Send Notifications E-mail notifications are generated for reviewers with the next execution of the Email Dispatcher job. The UAR notification emails will contain a hyperlink to the CUP request.

UAR Request Review


Reviewer Tasks The reviewer has the following tasks: 1. Reject users. 2. Approve access or request removal of access. 3. Submit the request. 1. Rejecting Users As of Support Package 06, the users Manager may reject users for whom they are no longer responsible during UAR approver review. Once rejected, users are able to be included on new requests. Rejected users are visible in the UAR History Report and the user Review Status Report. The Reject User option is not relevant for the Reviewer stage if the Reviewer is the Role Owner. The Role Owner review screen will not include the option to reject a user, but will include options to approve or remove the access. Procedure 1. Go to My Work > Request for Approval. 2. Select a UAR request and go to the User Access tab. 3. Click the Reject User(s) button. The User pane appears and displays the list of users. 4. Click the Reject User checkbox next to the user you want to reject. 5. Click the Reason dropdown box and select a reason. 6. Click Add Comments, add a comment, and click Save. To view previous comments, go to the Comments tab. Comments are listed for each rejected user with a time stamp and a reviewer User ID. 7. On the Request Number screen, click Save. The User Access tab is displayed. On the User Access tab, all items for the rejected user are grayed and inactive, and the Action column displays Reject. You can go back to the Reject User screen and modify rejections prior to submitting the review request. Once you submit the request, the rejected items cannot be modified in a later stage. This applies even if the request is rerouted to another stage. 8. Click Submit to submit the request. Upon submission, the items marked for rejection will be visible in the Manage Rejected Users screen with the status New.

Page 205 of 397

Compliant User Provisioning User Review 2. Approving access or requesting removal of access When the approver logs in to Access Control, the UAR requests for his approval will be in the My Work tab. The User Name column will be blank for UAR requests since there may be multiple users on each request. The General Information tab of the UAR request indicates the Reviewer and the Coordinator. The Transaction Usage displays the date range of data collected by the Role Usage Synchronization job. The From date for transaction usage is determined by the last Purge Usage job executed in Risk Analysis and Remediation. The To date is determined by the last Role Usage Synchronization job execution in ERM or by the manually uploaded data. The User Access tab of the request lists the user being reviewed as well as the role and the usage information for the role. You may choose any column header to sort the request lines by that column. Note If you have selected items and decided an action, you should choose Approve or Propose Removal prior to sorting since sorting removes any selections that have not be updated in the Action column. During the review of a users access, you may view details of the role by selecting the role name in the request line item. The role details will be displayed and will include the actions currently defined in the role. Since the display of actions is real-time, the actions will not be displayed when the back-end system is unavailable. The reviewer indicates which roles shall be retained and which shall be removed by selecting rows and choosing either Approve or Propose Removal. This causes the Action column to be updated. With each update of the action to be taken, the blue triangle denotes the item(s) just updated. The reviewer may choose to Save the request multiple times to ensure work is saved in the request. The request will not be forwarded for the next action until the reviewer chooses Submit and then Approve to approve the recommendations for each request line item. 3. Submit Review When all roles on the request have been reviewed and each row has been approved or marked for removal, the reviewer chooses Submit to complete his work. The request will continue to the next stage.

Managing Rejected Users


The Manage Rejected Users process provides authorized users with the following functionality: 1. Search for rejected users . 2. Generate review requests. 3. Cancel review request generation for those requests that have not been completed. To access the screen, log on to Configuration > User Review > Manage Rejections. 1. Searching for Rejected Users You can search using the following fields: Field Rejection Date From Rejection Date To Possible Values Any date Any date Default Value Current date Current date

206

August 2010

Compliant User Provisioning User Review Note The Rejection Date is the date the rejected review request is submitted. If the reviewer rejects a request and only saves the request without submitting it, the user is not available on the screen above. For more information, see Reviewer Rejects User in Request for Approval. Workflow Type Reason Status SOD Review User Access Review All All All

Any reason code for rejecting a user. All New To Generate In Process Error Completed

The rejected users resulting from the search are displayed. The following statuses are available: New These are requests submitted by the reviewer. To Generate The user is marked for re-generation, 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 not 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.

2. Selecting Users for UAR Request Generation Select user names from the User column and click Generate Requests. This action marks the user to be included on a new UAR request when the UAR Review Process Rejected background job is executed. Recommendation Before generating requests for the rejected users, make sure the users have the correct reviewer information. This will prevent incorrect information entering the request cycle again. Example If the reviewer information is stored in an LDAP data source and is incorrect, it must be updated in the LDAP data source so that new requests are generated with the correct reviewer name. If the admin review option is set to Yes, the administrator can choose to modify the reviewer/coordinator information to correct the reviewer information. The request per user is generated for users without a manager in the data source when the Reviewer is set as the Manager. Page 207 of 397

Compliant User Provisioning User Review 3. Cancelling Request Generation To cancel the request generation, select users from the Users column and click Cancel Generation.

You can choose to cancel a request generation. You can cancel the request generation for all users whose request status is To Generate. Once the request status is In Process, the background job has started and the request cannot be cancelled.

Generating New Requests for Rejected Users 1. Go to Configuration tab > Background Jobs. The Schedule Service screen appears. 2. In the Task Name dropdown menu, select UAR Review Process Rejected. 3. In the Description field, enter a brief description. 4. In the Schedule Type dropdown menu, select the time you wish to schedule this job. The corresponding Task Occurrence or Recurrence pane appears. a. In the Monthly Task Recurrence pane, enter the Time and Start Date. b. For Immediate schedule type, click Run. Reminders Reminders are sent as determined by configuration when the UAR request reviewers do not complete the review by the time specified. No change to the request or users occurs at reminder generation. Escalation Escalation will occur when a reviewer has not completed his review by the time specified in configuration. The escalation may include deactivating a user, de-provisioning roles and/or forwarding to the next stage Administrator Actions Persons assigned the AE_Admin role can perform many actions for UAR requests. These actions include: Specify reviewers during Admin Review Modify Coordinators Cancel requests Indicate action to be taken for a user(s) on a UAR request (retain or remove access) Forward a request to a new reviewer

Managing the Review Process UAR Status Report


The User Review Status Report allows you to monitor UAR requests to ensure that the process is completed in a timely manner. This report will be very useful to coordinators or other persons overseeing the review process. You reach the User Access Review Status Report in CUP by navigating to the Informer > Analysis View > Analytical Reports > User Review Status Report.

The status report can be used to monitor the review process. It can be useful to administrators, coordinators, and management. Please note that a stage of a review is not considered complete until the reviewer has submitted the request.

208

August 2010

Compliant User Provisioning User Review Features: The report displays all requests, both complete and incomplete. The report displays the detailed status of the request by user. The report can be printed. You can filter by selection criteria. Select Workflow Type of User Access Review. You may filter results by other criteria, such as coordinator, reviewer, organization, or request status. Note Putting a 0 instead of the 9999 Hit Count will return all requests that meet your criteria.

Request Details You can use the hyperlinks for Request Number to view the request. Using the scroll bar in the User Access pane allows you to scroll through the line items of the request and view the action indicated for each line. o o If the user is rejected and the review request is saved or submitted, all the line items for the user will have Action as Reject. If the request is escalated at any stage of the workflow, all line items in the request will have Escalated as Yes.

Reviewer Details You can use the hyperlinks for Reviewer, Organization, or Coordinator to view details of the reviewer.

Audit/Reporting
The User Access Review process provides information in reports and audit trail. The User Access Review History Report shows the actions taken for requests in the user review process. The audit trail of a request shows the detail of the activity taken for the request. For more information about reports and audit trails, see the Access Control 5.3 Application Help.

Page 209 of 397

Compliant User Provisioning User Review

Performing SoD Reviews


The Segregation of Duties (SOD) Review feature automates and documents the periodic decentralized review of risk violations by business managers or risk owners. It may include SOD and critical access risk violations. It can be used during the initial Clean-up of risk violations as well as a long-term strategy to review and affirm previous mitigation assignments. Requests are generated automatically based on the companys internal control policy. It provides a workflow-based review and approval process. Features Decentralized review of risk violations Reaffirmation of mitigating control assignments Workflow-based process for reviewing and approving requests Status and history reports to assist in monitoring the review process Audit trail and reports for supporting internal and external audits Supports review for any system analyzed by Risk Analysis and Remediation

Review Process
This section discusses the review process and the implementation options. The next section will discuss how you configure the system to reflect your chosen process. Process The high-level process for SOD reviews is as follows: 1. The SOD background jobs generate SOD review requests. 2. The system sends e-mail notifications to reviewers. 3. The reviewer reviews the request and chooses the following options: Reject request items. Mitigate function risks by assigning controls. Remove access for items that violate your company policies.

For more information, see Reviewing SOD Review Requests.

210

August 2010

Compliant User Provisioning User Review

Roles in the SOD Review Process


Administrator: This person has the AE_Admin UME role assigned for Access Control. They can perform general CUP administrator tasks in addition to SOD Review-specific administrator tasks, such as cancelling SOD Review requests and regenerating requests for rejected users. Reviewer: This term refers to the approver at the Reviewer stage. For the SOD Review, the Reviewer may be the users manager or the risk owner. Users Manager: The direct manager of a user as defined in the User Details Data Source. Risk Owner: This term refers to the risk owner specified in RAR master data.

Coordinator: This term refers to the Coordinator specified in CUP master data. Coordinators are assigned to one or more Reviewers. They monitor the SOD Review process and coordinate activities to ensure the process is completed in a timely manner.

Process Options
You choose from the following process options to determine the behavior of the review process: Admin Review This configuration option provides an opportunity for the administrator to review the request data for completeness and consistency prior to sending the request to reviewers. If the manager or risk owner information is incorrect or missing, the administrator can modify the data prior to generating workflow tasks and notifications. The administrator can also cancel the requests. Reviewer Stage You decide whether the Reviewer stage will be addressed by the Users Manager or the Risk Owners. Security Stage You decide whether to have a security stage. A security stage is suggested as removal of functions from Users will have to be executed, if applicable. If a security stage will be included in your approval workflow, you must decide whether security personnel will be able to modify the actions previously noted by an Approver. Additional Approver Stage You decide whether you will have an additional stage with the approver derived by a Custom Approver Determinator (CAD). The fields available in the SOD Review CAD differ from those available in the standard Compliant User Provisioning CADs. The fields available are in the SOD Review CAD are: Application Risk Request Type Request Priority

Page 211 of 397

Compliant User Provisioning User Review Instruction for Reviewers You can provide detailed instructions for reviewers to supplement the content of the notification emails by configuring a web page to be shown in the review requests. The level of instruction for periodic risk violation reviews might be more extensive than access requests since 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 SOD Review requests is an HTML viewer. An example of a SOD Review request with an HTML page provided in the request is shown here.

Workflow Stage Configuration


Now that you have decided which stages to include in your SOD review workflow, you must decide on specific behaviors for each stage to reflect your review process. You may utilize the following: Email Notifications Reminders Escalations

Email Notification
You decide on the content of email notifications to be sent to the approvers at each stage. You determine the recipient(s), the content of the notification header and the email body. For more details, see the Setting Up Email Notification section.

Reminders
You decide whether to send reminders to the request reviewers and/or coordinators who have not completed their portion of the review by the date specified. (The email reminder to coordinators contains a status report listing all reviews for which they are responsible). You can specify the interval of reminder notifications in days, as well as the reminder notification header and body content. For details on configuring reminders, see the Setting Up E-mail Reminders section.

212

August 2010

Compliant User Provisioning User Review

Escalation
You decide whether to escalate SOD review requests in each stages details. Therefore, escalation is based on the time spent in a particular stage. If a reviewer does not complete their review of a request according to the date parameter defined in configuration, then the request is escalated. You also determine the action to be taken upon escalation of a review. Escalation of a request will show in the requests audit trail. Escalation at a particular stage bypasses detours defined for that stage. For details on configuring reminders, see the Setting Up E-mail Reminders section.

Configuration and Master Data


This section contains instructions for configuring the SOD Review process and providing the necessary master data. Process 1. Configure Batch Risk Analysis and populate master data in RAR 2. Configure SOD Review and populate Master Data in CUP 3. Provide appropriate UME authorizations to users

Configuring Batch Risk Analysis and Populating Master Data in RAR


You must complete a full Batch Risk Analysis for all systems to be included in the SOD Review process with offline analysis enabled. The risk analysis results stored for offline analysis is supplied to Compliant User Provisioning by Web Service for generation of the SOD Review requests. Process 1. Define connectors. 2. Define risks. 3. Identify the default rule set. 4. Enable offline analysis. 5. Configure exclusion of mitigated risks. 6. Configure users excluded from Batch Risk Analysis. 7. Identify Critical Roles/Profiles 8. Configure Exclusion of Critical Roles/Profiles 9. Configure and schedule Alert Generation (optional)

Page 213 of 397

Compliant User Provisioning User Review

1. Define Connectors
A connector is required for each system to be included in the review process. The Connector ID in CUP must be identical to the Connector in RAR so that the risk violation information is correctly transferred. Go to Configuration > Connectors to define the desired connectors.

2. Define Risks
You must define the risks which will be used for evaluation of user access. This requires creation of a rule set and definition of the appropriate functions and risks. You may define segregation of duties and critical access risks for use in the review process.

3. Identify the default rule set


The default rule set is used for batch risk analysis. To configure this, log on to Risk Analysis and Remediation, select the Configuration tab, and in the left navigation pane choose Risk Analysis > Default Values. For more information, see Risk Analysis and Remediation > Risk Analysis Configuration.

4. Configure exclusion of mitigated risks


You must indicate whether mitigated risks will be excluded from the batch risk analysis. To use the SOD Review process periodically and reaffirm mitigating control assignments, you must populate the offline analysis data with mitigated risks. In this case, you should not exclude mitigated risks from the batch risk analysis. To define this setting, log on to Risk Analysis and Remediation, select the Configuration tab, and in the left navigation pane choose Risk Analysis > Default Values. For more information, see Risk Analysis and Remediation > Risk Analysis Configuration.

5. Configure users excluded from Batch Risk Analysis


You can define whether locked users and expired users are excluded from batch risk analysis, and therefore, from the SOD Review process. To define this setting, log on to Risk Analysis and Remediation, select the Configuration tab, and in the left navigation pane choose Risk Analysis > Default Values. For more information, see Risk Analysis and Remediation > Risk Analysis Configuration.

6. Enable Offline Analysis


You must enable offline analysis to store the violation data which will become the source information for SOD Review requests. To enable offline analysis, log on to Risk Analysis and Remediation, select the Configuration tab, and in the left navigation pane choose Risk Analysis > Additional Options. For more information, see Risk Analysis and Remediation > Risk Analysis Configuration.

7. Configure Exclusion of Critical Roles/Profiles


You can configure exclusion of critical roles and profiles from batch risk analysis. This is suggested for roles and/or profiles that generate large numbers of risk violations and will be monitored separately. To enable this exclusion of appropriate roles and profiles, log on to Risk Analysis and Remediation, select the Configuration tab, and in the left navigation pane choose Background Jobs > Schedule Jobs.

214

August 2010

Compliant User Provisioning User Review For more information, see Risk Analysis and Remediation > Excluding Objects from Batch Risk Analysis.

8. Identify Critical Roles/Profiles


If you have enabled the exclusion of critical roles and profiles from batch risk analysis, you need to define which roles and profiles are considered critical. To identify roles and profiles as critical, log on to Risk Analysis and Remediation, select the Rule Architect tab, and in the left navigation pane choose Critical Roles and Critical Profiles. For more information, see Access Control 5.3 Application Help documentation.

9. Configure and schedule Alert Generation (optional)


If you wish to include usage information in SOD Review requests, you must configure and schedule generation of alerts. For more information on alert generation, log on to Risk Analysis and Remediation, select the Configuration tab, and in the left navigation pane choose Background Jobs > Alert Generation. For more information, see Risk Analysis and Remediation > Scheduling Alert Generation.

Configuring SOD Review and Populating Master Data in CUP


The necessary steps for utilizing the SOD Review process consists of tasks that are specific to the SOD Review and steps that apply to use of any CUP requests and workflow. Process Steps specific to the SOD Review 1. Upload initial data file for SOD review. 2. Configure the workflow type. 3. Activate the request type. 4. Configure the request priority. 5. Configure a service level for escalation (optional) 6. Configure rejection reasons. 7. Configure the SOD review options. 8. Configure workflow for SOD Review. 9. Define coordinators. Process Steps for any request type 10. Configure an active number range. 11. Configure risk analysis for CUP. 12. Configure mitigation for CUP. 13. Configure an SMTP Server. 14. Configure the user data sources.

Page 215 of 397

Compliant User Provisioning User Review 15. Configure LDAP field mapping (optional). 16. Configure the security lead. 17. Configure connectors.

1. Upload Initial Data File for SOD Review


Ensure that the AE_init_append_data_ForSODUARReview.xml file has been uploaded in Configuration > Initial System Data. This .xml file is one of the initial data files included with Access Control. Support Packages may deliver subsequent versions of the initial data files and you must be sure that you have the data files that correspond to your Access Control support package level. Upload the specified initial data file in Compliant User Provisioning using the Append option. If you are configuring a new Access control installation, then you will need to upload all initial data files.

2. Configure the Workflow Type


1. Navigate to Configuration > Miscellaneous. 2. 3. In the Workflow Types pane, maintain the entry SOD_REVIEW. In the Active indicator field, select the indicator to enable the connector. Note The Exit URI, User Name, and Password fields are not required for SOD review.

4. Activate the Request Type


The initial data files include the SOD_REVIEW request type and it must be activated. 1. Go to Configuration > Request Configuration > Request Type. 2. Select the SOD_REVIEW request type and select Change. 3. Maintain the descriptions. 4. Ensure that the Active indicator is selected.

5. Configure the Request Priority


Define a priority for the SOD Review Workflow Type. Navigate to Configuration > Request Configuration > Priority.

6. Configure Escalation
If you will be using escalation, you should define the conditions that will cause an escalation, the action taken for the escalation and the content of the escalation email notification. You configure global escalations at the service level. For more information, see Service Level.

216

August 2010

Compliant User Provisioning User Review You configure other escalations at the stage level. For more information, see Workflow Management > Stages.

7. Configure Rejection Reasons


Rejection reasons are mandatory when rejecting an SOD Review request. You must upload the reason codes and descriptions using a template. Procedure 1. Go to Configuration > User Review > Reason for Rejection. 2. Under Import Reasons for Rejection, click Download Template. The template opens in Excel. 3. Complete the required information and save the template.

Field ReasonCode (required)

Max Field Length 10 characters

Recommendation All UPPER case No special characters, no spaces Have some desired value.

Possible Values Letters and numbers

ReasonEnable

n/a

Yes/yes/y/YES/Y No/no/n/NO/N ( When empty, default value is No)

ShortDescription_xx ( XX language code like EN, DE etc. )

100 characters, including spaces

Have at least an entry for the application default language

Letters and numbers

4. Under Import Reasons for Rejection, click Browse. 5. Select the file created and click Import. Note You cannot delete reason codes from the application. To deactivate a reason code, set the ReasonEnable field as No, choose the Overwrite Existing option, and import the upload file.

8. Configure the SOD Review options


Go to Configuration > User Review > Options and specify the parameters for the SOD Review requests to be generated in the User Review pane. Admin review required before sending tasks to reviewers: Maintain this parameter based on the decision made when considering the process options.

Page 217 of 397

Compliant User Provisioning User Review o Yes: The administrator reviews the SOD Review requests prior to the generation of workflow tasks. The administrator can change the reviewer and approval roles or cancel SOD Review requests that are not desired.

Recommendation We recommend you choose Yes. This admin review provides an opportunity for the administrator to review the request data for completeness and consistency prior to sending the request to reviewers. o No: The administrator does not have an opportunity to review SOD Review requests prior to sending the workflow notifications to reviewers.

Who are the reviewers? o Manager represents the manager of the user as identified in the User Details Data Source. Risk Owner represents the risk owner as specified in the Risk Analysis and Remediation risk definition.

SOD Review Users URI o The URI of the web service to retrieve users with violations from Risk Analysis and Remediation. The address is http://<server>:<port>/VirsaCCSODViolatedUsersWS/ConfigVirsaCCSODViolate dUsersWS

SOD Review User Risks URI o The URI of the web service to retrieve risk violations from Risk Analysis and Remediation. The address is http://<server>:<port>/VirsaCCSODViolationsWS/configVirsaCCSODViolationsW S

Number of Line Items per Request o The maximum number of line items to be on an SOD Review request

Default Request Type o Enter the request type activated above: SOD_REVIEW

Default Priority o Enter the priority created for SOD Review requests

Enter URL for SOD review instructions: If an HTML page with detailed instructions for reviewers was created to supplement any instruction in the email notification, enter the URL of that page. The page can be saved to a local directory of your choice on your internal server. If the only instruction will be the email notification, then this field should be left blank.

218

August 2010

Compliant User Provisioning User Review

9. Configure workflow
You can configure an SOD review workflow based on your organizations requirements. For example, the SOD review workflow may consist of a primary path with a single stage for Reviewer approval and a detour path. A common detour path has a single stage for Security approval with a detour condition of action equal to Items with Remove Action. 1. Define an Initiator. Select SOD Review as the Request Type. For more information, see Workflow Management > Initiators. 2. Define Stages (for example, one stage for Reviewer and another stage for Security). For the Workflow Type, select SOD_Review. For each stage, you must determine: Change Request Content Reject Users whether the stage approver can indicate actions for request items whether the Reject User button will be accessible (Appropriate UME authorizations are also required to utilize the reject feature) whether the stage approver sees all request items whether the review screen is shown after submission of the request. Recommendation is No as this screen is redundant for SOD Review requests.

Approval Type Display Review Screen

For more information, see Workflow Management > Stages. Compliant User Provisioning provides two standard approvers for the review process. The first is the Reviewer, which can be the users manager or the risk owner. The second is Security. Optionally, you can define a Custom Approver Determinator (CAD) for a custom approver if an additional approver/stage is required. 3. Define the review Paths. For example, a primary path for the Reviewer and a detour path for Security. For the Workflow Type, select SOD_Review. For more information, see Workflow Management > Paths. 4. (optional) Define a Detour path with condition Select Items with Remove Action for the Condition and choose Yes for the Value. For more information, see Workflow Management > Detour Paths. 5. (optional) Define Email Reminders You define whether notifications will be sent for SOD Review requests upon request submission, upon request close and as reminders. You may define the timing for reminder notifications and the content for the relevant notifications. For more information, see Workflow Management > Email Reminder.

9. Define Coordinators
You identify a Coordinator for each Reviewer, regardless of whether the reviewer is a Users Manager or a Risk Owner. Access Control uses the coordinator information to generate reports that can be used while managing the review process.

Page 219 of 397

Compliant User Provisioning User Review For more information, see User Review > Coordinator.

10. Configure an active number range


Ensure there is an active number range in CUP. The number range is applicable to all access and review requests and is not specific to any request type. Make sure the number is sufficient to support your expected number of requests. Go to Configuration > Number Ranges to maintain number ranges.

11. Configure risk analysis for CUP


Enter information for CUP to communicate with RAR. 1. Go to Configuration > Risk Analysis. The Risk Analysis screen appears. 2. In the Select Risk Analysis and Remediation Version pane, enter the following

information:
Field
Version URI User Name Password Perform Org. Rule Analysis

Description
5.3 Web Service http://<server>:<port>/VirsaCCRiskAnalysisService/Config1?wsdl&style=document The authorized account CUP uses to log on to RAR. The authorized account CUP uses to log on to RAR. Select this if organizational rules should be used in the risk analysis

12. Configure mitigation for CUP


Go to Configuration > Mitigation. The Mitigation screen appears.

Field
Allow Approvers to approve access, despite any conflicts Default Duration (Days) for the Mitigation Control Mitigation URI Risk Search URL Org. Rule Search URI Function Search URI

Description
Select this indicator if your process allows provisioning despite the provisioning introducing risk violations. The default number of days the mitigating control assignment is effective.

http://<server>:<port>/VirsaCCMitigation5_0Service/Config1?wsdl&style=document http:// <server>:<port>/VirsaCCRisk5_0Service/Config1?wsdl&style=document http:// <server>:<port>/VirsaCCOrgRules5_3Service/Config1?wsdl&style=document http:// <server>:<port>/VirsaCCFunction5_0Service/Config1?wsdl&style=document

These are the addresses for the RAR web services.

220

August 2010

Compliant User Provisioning User Review

13. Configure an SMTP Server


CUP uses an SMTP server to send email notifications and reminders to users, requestors, and approvers of requests. Note Emails are not sent automatically. To send the emails, execute the Email Dispatcher task. For more information, see Setting Up Background Jobs.

For more information, see Workflow Management > SMTP Server.

14. Configure the user data sources


There are multiple types of data sources in CUP. You must identify a Search Data Source to be the source of all user IDs returned when performing a search. You may also identify a User Details Data Source that will be the source of all user-to-manager relationships. The User Details Data Source is required if your SOD Review process specifies the Users Manager as the Reviewer. Go to Configuration > User Data Source to configure both types of data sources.

15. Configure LDAP Field Mapping


If you are using an LDAP as the User Detail Data Source and SOD Review requests will be approved by users managers, then you must specify a field mapping for Manager so that Access Control can determine the reviewer for workflow. You define this in Configuration > Field Mapping > LDAP Mapping. For more information, see Field Mapping.

16. Configure Security Lead


You can specify a group email or approver IDs to be used in the security approval stages. On the Configuration tab, go to Approvers > Security Lead to configure the security lead information. For more information, see Approvers > Security Leads.

17. Configure Connectors


For each back-end system to be included in the SOD review, you must define a connector. The Connector ID in CUP must be identical to the Connector in RAR so that the risk violation information is correctly transferred. For more information, see Configuration Tasks.

Assigning UME Authorizations


You must assign UME actions to the appropriate individuals. UME actions are used to manage the rejected user process. The actions below are specific to the user review processes and were provided in the initial data files. For more information about the general security requirements for Access Control, see the Access Control 5.3 Security Guide.

Page 221 of 397

Compliant User Provisioning User Review

UME Action ViewManageRejectionReasons

Permission Included Provides the ability to configure Rejection Reasons to be used in reviews Enables the Reject Users button in review requests Provides the ability to view the Manage Rejections functionality Provides the ability to generate new requests for rejected users Provides the ability to cancel the generation of new requests for rejected users

ViewRejectUsers ViewManageRejections

ManageRejectionsGenerationAction

ManageRejectionsCancelGenerationAction

222

August 2010

Compliant User Provisioning User Review

SOD Request Creation


Identified below are the steps and jobs executed to generate requests for the periodic risk violation review. (Please note that generating new requests for users rejected from earlier requests is discussed in the section Managing Rejected Users) Before beginning the SOD review process, all supporting information for generating requests should be current to ensure accurate workflow of requests. For example, if the Reviewer is configured to be the Users Manager, then the user to manager relationships should be current in the detail data source. Note If there are users with no manager identified in the User Detail Data Source and the Reviewer is defined as the Users Manager, then Admin Review is required. This allows the administrator to maintain the missing data prior to sending workflow tasks to reviewers.

1.

Purge Usage Information

If more transaction usage information is stored in RAR than is desired for User Access Review or SOD Review requests, then the data should be archived. For example, if your SOD Review process states that the prior twelve months usage information should be provided in SOD Review requests and RAR has fifteen months available, then the oldest three months information should be purged (archived) in RAR. 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. This requires configuration of the location for writing the purge file in RAR Configuration > Miscellaneous > Alert Log File Name and Location. For more information on purging usage information, see the Risk Analysis and Remediation > Utilities section.

2.

Configure Alert Generation

Ensure that the RAR Alert Generation job has been executed if function usage information is desired in the SOD Review requests. For more information, see Risk Analysis and Remediation > Scheduling Alert Generation.

3.

Execute the SOD Review Load Data job

Execute the job to retrieve risk violations from Risk Analysis and Remediation. You choose the task to be executed based on your definition of the review process. 1. Go to Configuration tab > Background Jobs. The Schedule Service screen appears. 2. Search for the SOD Review Load Data without Mitigated Risks task OR the SOD Review Load Data with Mitigated Risks task. 3. Activate, schedule, and run it as needed. For more information, see Configuring Background Jobs. If you have configured the admin review option as No, skip steps 4. Performing Admin Review and 5.Run the SOD Review Update Workflow Job, and go to step 6 Send Notifications.

Page 223 of 397

Compliant User Provisioning User Review

4.

Performing Admin Review

(This step is only required you have enabled the admin review option). The administrator reviews the requests to ensure completeness and accuracy of the request information prior to sending to reviewers. Procedure 1. On the Configuration tab, navigate to User Review > Request Review. The search screen appears. 2. Search for requests and review the data to confirm accurate reviewer information. 3. To cancel an incorrect request, select a review request number and click the Cancel Request(s) button. If you choose to cancel a request, Access Control will ask you to indicate whether the users contained in the request(s) being cancelled should be marked as rejected users. Yes: The review request is cancelled. All users in the request are considered Rejected Users and their requests are available in the Manage Rejected Users screen to be regenerated. No: The review request is cancelled. All users in the request will only be included in another SOD review request upon selection in execution of SOD Review Load Data job. Note If you mistakenly choose to cancel a request and want the request to remain, select an item in the Configuration menu to exit the current menu option. Options for Processing Incomplete or Inaccurate Requests If the requests are incomplete or inaccurate, you have the following options: Option 1: If a large number of requests need correction or are not needed: Cancel all of the current SOD review requests. Choose No when asked if the users should be considered as rejected users. Maintain the source data. (Ensure you have maintained the reviewers). Generate new requests by executing the SOD Review Load Data with/without Mitigated Risks task.

Option 2: If a smaller number of requests need correction or are not needed: 1. 2. 3. 4. Cancel selected SOD review requests. Choose Yes when asked if the users should be considered as rejected users. Maintain source data.(Ensure you have maintained the reviewers). Generate new requests by executing the SOD Review Load Process Rejected task.

Option 3: If a small number of requests need identification of reviewers and/or coordinators. Manually maintain the reviewer and/or coordinator information during administrator review

224

August 2010

Compliant User Provisioning User Review

5.

Run the SOD Review Update Workflow Job

(This steps is only required if you have enabled admin review and the admin review has been completed.) Execute the SOD Review Update Workflow job to push the workflow tasks to the reviewers. In CUP, go to Configuration > Background Jobs and select the SOD Review Update Workflow task. For more information, see Background Jobs.

6.

Send Notifications

E-mail notifications are generated for reviewers with the next execution of the Email Dispatcher job. The SOD review notification emails contain a hyperlink to the SOD review request.

Reviewing SOD Review Requests


To access review requests, go to My Work > Request for Approval. You have the following options:
Reject request items that do not apply to you. Mitigate function risks by assigning controls. The system automatically assigns the mitigation control assignments after review is completed. Remove access for items that violate your company policies. Functions marked for removal are sent to security review for further action.

Rejecting Request Items


The approver may reject users or risks for which they are no longer responsible. Once rejected, you can choose to include the users on new requests. Rejected users are visible in the SOD Review History Report and the User Review Status Report. Procedure 1. Go to My Work > Request for Approval. 2. Select an SOD review request and go to the User Access tab. 3. Click the Reject User(s) button. The User pane appears and displays the list of users. 4. Click the Reject User checkbox next to the user you want to reject. 5. Click the Reason dropdown box and select a reason. 6. Click Add Comments, add a comment, and click Save. To view previous comments, go to the Comments tab. Comments are listed for each rejected user with a time stamp and a reviewer User ID.

Page 225 of 397

Compliant User Provisioning User Review 7. On the Request Number screen, click Save. The Access Control Violations tab is displayed. On the Access Control Violations tab, all items for the rejected user are grayed and inactive, and the Action column displays Reject. You can go back to the Reject User screen and modify rejections prior to submitting the review request. Once you submit the request, the rejected items cannot be modified in a later stage. This applies even if the request is rerouted to another stage. 8. Click Submit to submit the request. Upon submission, the items marked for rejection will be visible in the Manage Rejected Users screen with the status New.

Mitigating Function Risks


You can mitigate function risks by assigning a mitigation control to it. 1. Go to My Work > Request for Approval. 2. Select an SOD review request and go to the Access Control Violations tab. 3. Select an item and click Mitigate. The Assign Mitigation Control screen appears. 4. Enter information in the required fields and click Save. The system automatically assigns the mitigated function risks after review is completed. 5. On the Access Violations tab, click Submit. The request continues to the next stage. For more information, see the Access Control 5.3 Application Help documentation.

Removing Access for Functions


You can mitigate function risks by assigning a mitigation control to it. 1. Go to My Work > Request for Approval. 2. Select an SOD review request and go to the Access Control Violations tab. 3. Select an item and click Remove Access. A screen with the request details appears. 4. Select a function and click Remove. 5. On the Access Violations tab, click Submit. The request continues to the security stage. For more information, see the Access Control 5.3 Application Help documentation.

Managing Rejected Users


The Manage Rejected Users process provides authorized users with the following functionality: 1. Search for rejected users 2. View search results and sort the results by user 3. Generate review requests

226

August 2010

Compliant User Provisioning User Review 4. Cancel review request generation for those requests that have not been completed To access the screen, log on to Configuration > User Review > Manage Rejections.

1. Searching for Rejected Users


You can search using the following fields: Field Rejection Date From Possible Values Any date Default Value Current date

Rejection Date To Any date Current date Note The Rejection Date is the date the rejected review request is submitted. If the reviewer rejects a request and only saves the request without submitting it, the user is not available on the screen above. For more information, see Reviewer Rejects User in Request for Approval. Workflow Type Reason Status SOD Review User Access Review All All All

Any reason code for rejecting a user. All New To Generate In Process Error Completed

The rejected users resulting from the search are displayed. The following statuses are available: New These are requests submitted by the reviewer. To Generate The user is marked for re-generation, 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 not completed. Requests with this status cannot be cancelled, because the background job has started. Error The generation background job has encountered an error.

Page 227 of 397

Compliant User Provisioning User Review Completed The generation background job has completed. The new request number is updated.

2. Selecting Users for SOD Review Request Generation


Select user names from the User column and click Generate Requests. This action marks the user to be included on a new SOD review request when the SOD Review Process Rejected background job is executed.

3. Cancelling Request Generation


To cancel the request generation, select users from the Users column and click Cancel Generation. You can choose to cancel a request generation. You can cancel the request generation for all users whose request status is To Generate. Once the request status is In Process, the background job has started and the request cannot be cancelled.

4. Generating New Requests for Rejected Users


1. Go to Configuration tab > Background Jobs. The Schedule Service screen appears. 2. Search for SOD Review Process Rejected. 3. Activate, schedule, and run the job as needed.

228

August 2010

Compliant User Provisioning User Review

Options
You configure review parameters for both SoD and user access reviews. Option Admin. review required before sending tasks to reviewers Who are the reviewers SoD Review Users URI Description Choose whether to require admin review before request is forwarded to reviewers. Select the role to perform the review. Define the URI for the Web service that retrieves User IDs. http://<server>:<port>/VirsaCCSODViolatedUsersWS/Config VirsaCCSODViolatedUsers?wsdl&style=document SoD Review User Risks URI Define the URI for the Web service that retrieves the risks associated to User IDs. http://<server>:<port>/VirsaCCSODViolationsWS/configVirs aCCSODViolationsWS?wsdl&style=document Number of line items per request Default request type Default priority Enter URL for SoD review instructions Enter URL for UAR instructions Choose the number of items to display per request. If you have configured multiple request types, choose the type you want as default. Choose the default priority for user access reviews. Enter the URL for the location of the SoD review instructions html page. Enter the URL for the location of the UAR instructions html page.

Creating the SoD and UAR Review Instruction Page


You can include an instructions page that reviewers view when they perform SoD and user access reviews. Do the following to configure the instructions HTML page and text. 1. Create an HTML page with your instructions. Format the page as needed. Create one page for SoD Review instructions and one page for User Access Review instructions. 2. Save the page to a local directory of your choice on your internal server. 3. In CUP, click the Configuration tab -> User Review -> Options. The Selection page appears. 4. In the SOD Review section, select Enter URL for SOD Review Instructions and enter the explicit path to your SOD Review Instructions file. 5. In the User Review section, select Enter URL for UAR Review Instructions and enter the explicit path to your UAR Review Instructions file. 6. Click Save.

Coordinator
Choose a coordinator for each reviewer. Access Control uses the coordinator information to generate reports you can use while managing the review process.

Page 229 of 397

Compliant User Provisioning User Review 1. On the Configuration tab, navigate to User Review > Coordinator. The Coordinator screen appears.

Review of all SoD or User Access violations is coordinated. In addition, one coordinator might have many reviewers. 2. Search for the coordinator and reviewer by user ID or by first and last names. 3. Search on the resulting screen to determine whether the selected coordinator/reviewer pair is set to review SoD risks or user access violations. 4. (optional) You can create, change, delete, and export mapping information for coordinator/reviewer names. If necessary, you can download a template for creating mapping information of coordinator/reviewer names by clicking Download Template. Afterwards, you can import this file.

230

August 2010

Compliant User Provisioning User Review

Request Review
Administrators can review requests, and choose to cancel them or change the user-tomanager relationships. 1. On the Configuration tab, navigate to User Review > Request Review. The Search Requests screen appears. 2. Enter information in the available fields and search for available requests. The List of Requests screen appears. 3. Select a request and choose Change or Cancel Request. Option Change Description The Change Request Attributes screen appears. You can choose to change the reviewer and coordinators. Cancel Requests The Confirmation screen appears. Choose No to cancel the request with no further action. Choose Yes to cancel the request and mark the user as a rejected user for request regeneration. For more information, see Performing User Access Review.

Manage Rejections
Authorized users can do the following in Manage Rejections: Search for rejected users Select users for UAR request generation Generate review requests Cancel review requests

Log on to CUP Configuration > User Review > Manage Rejections. Searching for Rejected Users You can search using the following fields: Field Rejection Date From Possible Values Any date Default Value Current date

Rejection Date To Any date Current date Note The Rejection Date is the date the rejected review request is submitted. If the reviewer rejects a request and only saves the request without submitting it, the user is not available on the screen above. For more information, see Reviewer Rejects User in Request for Approval. Workflow Type Reason SOD Review User Access Review All All

Any reason code for rejecting a

Page 231 of 397

Compliant User Provisioning User Review user. Status All New To Generate In Process Error Completed All

The rejected users resulting from the search are displayed. The following columns are available: Column User Workflow Type Description You can sort the users by the User IDs. This column displays the related workflow type: SOD Review or User Access Review. This column displays the date the user is rejected. The following statuses are available: New These are requests submitted by the reviewer. To Generate The user is marked for re-generation, 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 not 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.

Rejection Date Status

Reason Original Request New Request

This column displays the reason a user was rejected from the request. The column displays the original request number and request status for the rejected user. The column displays the new request number and status for the rejected user.

232

August 2010

Compliant User Provisioning User Review

Selecting users for UAR request generation You can select users to be included on a new UAR request when the UAR Review Process Rejected background job is executed. 1. Search for UAR requests. 2. Select user names from the User column and click Generate Requests. Recommendation Before generating requests for the rejected users, make sure the users have the correct reviewer information. This will prevent incorrect information entering the request cycle again. Example If the reviewer information is stored in an LDAP data source and is incorrect, it must be updated in the LDAP data source so that new requests are generated with the correct reviewer name. If the admin review option is set to Yes, the administrator can choose to modify the reviewer/coordinator information to correct the reviewer information. As of SP06, a request per user is generated for users without a manager in the data source when the Reviewer is set as the Manager.

Generating Review Requests You can generate new requests for marked users. 1. Go to Configuration tab > Background Jobs. The Schedule Service screen appears. 2. In the Task Name dropdown menu, select UAR Review Process Rejected. 3. In the Description field, enter a brief description. 4. In the Schedule Type dropdown menu, select the time you wish to schedule this job. The corresponding Task Occurrence or Recurrence pane appears. 5. In the Monthly Task Recurrence pane, enter the Time and Start Date. 6. For Immediate schedule type, click Run. Cancelling Review Requests You can choose to cancel a request generation. You can cancel the request generation for all users whose request status is To Generate. Once the request status is In Process, the background job has started and the request cannot be cancelled. To cancel the request generation, select users from the Users column and click Cancel Generation.

Page 233 of 397

Compliant User Provisioning User Review

Reason for Rejection


You configure the rejection reasons, descriptions, and reason codes. Rejection reasons are mandatory when rejecting a review request. You must upload the reason codes and descriptions using a template. Procedure 1. Go to Configuration -> User Review -> Rejection Reason. The new Rejection Reason screen appears. 2. Under Import Rejection Reasons, click Download Template. The template opens in Excel. Fill in the required information and save the template. Field ReasonCode (required) Max Field Length 10 characters Recommendation All UPPER case No special characters, no spaces Have some desired value. Possible Values Letters and numbers

ReasonEnable

n/a

Yes/yes/y/YES/Y No/no/n/NO/N ( When empty default value No)

ShortDescription_xx ( XX language code like EN, DE etc )

100 characters, including spaces

Recommended to have some desired value for at least for application default language

Letters and numbers

3. Under Import Rejection Reasons, click Browse. 4. Select the Rejection Reasons file and click Import. Note You cannot delete reason codes from the application. To deactivate a reason code, set the ReasonEnable field as No, choose the Overwrite Existing option, and import the upload file.

UAR Load Data Tasks


To enable user access reviews, CUP uses background jobs to extract role usage information from ERM. The delivered background job (UAR Review Load Data) extracts data for all users. You can use the UAR Load Data Tasks to create custom tasks that enable you to choose a subset of users to review based on parameters such as critical level, role name, user group, and so on. This, in effect, enables you to create batches of users by task name for user access review, such as User access review for high criticality roles, or User access review for all users (excluding expired users). For more information, see Creating UAR Load Data Tasks. Features Create Change

234

August 2010

Compliant User Provisioning User Review Activate/Deactivate To use a task, you must select to activate it. If you choose to deactivate it, the task information is saved and not available to run as a background job. UAR Load Data Job History You can view the history for a particular custom load data task by selecting the item and choosing the UAR Load Data Job History pushbutton. It includes information about the number of users and role assignments included for the UAR Load Data Task. The UAR Load Data Job History is available only for custom UAR load data tasks. The delivered background jobs are not included in the displayed history. Note You cannot change or deactivate tasks currently running as background jobs.

Creating UAR Load Data Tasks 1. On the Create UAR Load Data Tasks screen, enter the Task Name and Task Description fields. 2. Choose or enter information for the following parameters: Parameter Role critical level Description Generate reviews for roles of a specific critical level: low, medium, high. Role critical level will include all the critical levels defined in ERM if you do not enter any values in this field. Generate reviews for these specific roles. Exclude these roles when generating reviews. Generate reviews for roles in this specific function area. Note You must ensure the function area values in ERM and CUP are consistent. Users Exclude users User group System Generate reviews for these specific users. Exclude these users when generating reviews. Generate reviews for roles of a specific SU01 logon user group. Generate reviews for roles from a specific system.

Role name Exclude roles Function area

Note The text box fields are free form. The system does not check for case sensitivity or accuracy. Enter single values. The fields do not support multiple values. 3. Select Save. 4. On the UAR Load Data Tasks screen, select the new task, and choose the Activate/Deactivate pushbutton to activate it.

Page 235 of 397

Compliant User Provisioning User Review 5. To execute the tasks, go to Configuration -> Background Jobs. For more information, see the Compliance User Provisioning > Background Jobs section. Note Deactivated tasks do not display in the available background jobs list. However, they are displayed on the background job Display Schedule screen.

236

August 2010

Compliant User Provisioning Change Log

Change Log
On the Configuration tab, you can configure a change log to capture any changes users make to configuration parameters. When a user performs configuration actions, the system logs the information in the database. You might also want to capture additional information, which you can specify on the Change Log Configuration screen. The Change Log captures the following: Change Log Item Change Log ID Object Name Object Value Description This is the log identifier. Example: Change Log ID 200 This is the object that has been changed. Example: Connector Configuration. This is the value that has been modified for the object. Example: QF8600 is a system name. This is the type of action performed for the Object Name. Example: New. This is the person responsible for making the change. Example: BLAW This is the date and time that the change was made. Example: 10/07/2008 19:17:21 This is the name of the field that was touched. Example: Is Active This is the fields old value. Example: true. This is the fields new value. Example: false This is the type of action performed in the field name. Example: Modified.

Action

Changed by

Change Log Time

Field Name Old Value New Value Action

Change Log Configuration


1. On the Configuration tab, navigate to Change Log Configuration. The Change Log Configuration screen appears. 2. Select the configuration items that you want to track. Select as few or as many items as you want. 3. Click Save.

Search Change Log


Use the Search Change Log feature to search the log information in the database for configuration changes.

Page 237 of 397

Compliant User Provisioning Roles You can specify any of the following criteria to filter your search: Change Log ID: The log ID in the log information in the database. User ID: The specific user ID of the user who made configuration changes. Object Name: Select the specific types of configuration changes you want to find. Object Value: Based on the specified object name, you can specify an object value. For example, if you select Role for Object Name, you can specify the name of the role as its value. Field Name: Each object has a specific set of fields. Based on the specified object name, the corresponding field names appear on the dropdown list, and you can select a specific field name to further refine the search. Field Value: Based on the specified field name, you can specify a field value to fine tune the search. Change Date From and Change Date To: Specify the range of dates when configuration changes you want to find were made. Maximum Number of Hits: Specify the number of configuration log records to display in the search results to narrow the search criteria.

Roles
The Roles option configures roles. A role is fundamental to users for accessing information. A role can be specific to an individual user or a group of users. The role description must match the specific tasks for accessing information or application systems. The Roles option provides the following configuration options: Import Roles Role Creation Role Search Role Exporting Role Selection Default Role Configuration Role Mapping Enablement and Removal of Role Mappings Attribute Definition Role Reaffirmation

Frequently Asked Questions Question Answer

What happens if a role has not been No. You must import the role first. imported/added to Compliant User Provisioning? Can a requestor still select that role and add it to a request?

238

August 2010

Compliant User Provisioning Roles

Question

Answer

Can a role be deleted from a user after Compliant User Provisioning can delete roles from users within a workflow that has a request type it is assigned? configured with a Change User action. But, even with a deleted role, you must import/add the role to Compliant User Provisioning prior to selecting it for deletion. If a role is updated (for example, a transaction code is added), does the role need to be re-imported? No. Compliant User Provisioning does not import role details other than names and descriptions. If required, transaction code information is obtained from the SAP system and is therefore always in sync.

If I delete a role in the SAP system, do I No. If you delete a role in the SAP system and then have to import it again to synchronize import roles into CUP, the role reference remains in Compliant User Provisioning with SAP? CUP. You must manually delete the role in CUP. Note You cannot delete roles that are tied to a request. To make the role not available for selection by users, you must remove the system identifier from the role.

Importing Roles
Compliant User Provisioning provides several methods to load roles. One method is to import the roles from an SAP business system. Another method is to import roles from a spreadsheet file. You use Enterprise Role Management to build roles. These roles can be pushed to each Access Control capability through a synchronization mechanism. For more information about role synchronization, see the section Configuration for Role Synchronization Integration with Enterprise Role Management. For import of non-SAP roles, these roles are transferred to Compliant User Provisioning using the Role Import file (a spreadsheet). Be selective when importing roles. Take into consideration which roles you need. For example, if you do not want anyone to request SAP_ALL in the production client, do not load it into the production client. Load only the roles that you need. Importing a large number of roles can result in a long list to scroll through when you must select one. In addition, deleting roles can be time consuming when thousands of roles are in one system.

Procedure
1. On the Configuration tab, navigate to Roles > Import Roles. The Import Roles screen appears. 2. From the System dropdown list, select the system that contains the roles you want to import. 3. From the Role Source dropdown list, select either the SAP back end or Enterprise Role Management. 4. In the Last Sync Date field, select a date.

Page 239 of 397

Compliant User Provisioning Roles All roles that have been changed since the specified date are selected for import. 5. Select the setting in which to import your roles from the following table. Role Import Settings Role Import Setting All Roles Description Imports all roles from the specified system, which includes all predefined roles. Use caution when importing roles. You might not need to import all roles from the back-end system into Compliant User Provisioning. The only roles you need to import are the roles you want requestors to select for provisioning. All Roles Except SAP Predefined Roles Selected Roles Imports all roles except any predefined roles in the specified SAP system. Imports individual roles. in this case, you must know the names of the roles you want to import. Enter the roles one at a time in the Role Name field, or use a wildcard option (an asterisk - *) to specify a number of similarly named roles. Use this setting to load roles from a spreadsheet file. This file can be on your local host or on another system. Use Browse to navigate to the file.

From File

In your development system, where you create roles to transport, there might be roles used for testing that you do not want users to request. If you do not import these roles, they are not available for selection, approval, and provisioning. For SAP systems: If you do not want users requesting access to SAP_ALL in your production system, do not import SAP_ALL for the production system. 6. To overwrite any existing roles of the same name as those you import or add any new roles to the system, select Overwrite Existing Roles. This option does not affect any roles that are not listed in the spreadsheet or included in the import. 7. Click Import.

Configuring Role Synchronization Integration with ERM


The integration of Compliant User Provisioning with Enterprise Role Management enables role synchronization. Enterprise Role Management is set as the system for role resource. Procedure To integrate for role synchronization: 1. Log on to Compliant User Provisioning with administrator privileges. 2. Go to Configuration tab > Roles > Import Roles 3. In the System dropdown menu, select the appropriate system. 4. In the Role Source dropdown menu, select Role Expert. 5. Select All Roles.

240

August 2010

Compliant User Provisioning Roles 6. Click Import.

Role Import/Export Template Details


To import roles, you can download a spreadsheet template to your local system. After downloading the spreadsheet, populate the fields with your own roles, and then import the information. Recommendation SAP recommends that you edit the downloaded template with your additional roles. Use the data format of the values represented in the dummy role. However, you must delete the dummy role in the template before using it. Do not modify the sheet name and header names. Business process, subprocess, functional area, company, and system must exist in Compliant User Provisioning before the roles can be successfully uploaded. If they do not exist, attempting to import them fails. These attributes are added through the Roles > Attributes screen. To download the role import template: 1. Click Download Template, and then click Save to save the template to your system. Be sure to save the template in a location where it is for you to find later. 2. Open the template, and enter values for the roles you want to import. 3. Save and close the template with the new information. Now you can import the role information. For more information, see the section Importing Roles.

Page 241 of 397

Compliant User Provisioning Roles

Role Import/Export Template Details The following table describes the items in the import template spreadsheet. Role Import Template Spreadsheet Role Import Column Description Connector Type Name of the connector type. Only one connector type is allowed. Technical name of the role. Select Single or Composite. Only one value is allowed. Date of the roles last reaffirm. Required format is MM/DD/YY. Technical name of the system in which the role resides. The system must exist as a connector. List as many systems as you want, separated by commas. User ID of the roles approvers. Several role approvers can be included, separated by commas. Alternate approvers follow the approver and are separated by a pipe symbol (|). Lead Approver designation follows the alternate approver separated by a pipe symbol (|). Format: Roleappr|alternative|Y,roleapprover|alternate Example: WONG|BLAW|Y,CPERKINS MWONG is the role approver, BLAW is MWONGs alternate approver and MWONG is the Lead Approver. CPERKINS is the second role approver, no alternate and is not the lead approver. Functional Area Functional area of the role. This is the technical name of the functional area, and it must exist in the system before the role is uploaded successfully. Several functional areas are permitted, separated by commas. Company associated with the role. This is the technical name of the company, and it must exist in the system before the role is uploaded successfully. Several companies are permitted, separated by commas Options are either Role or Profile. Yes at least one functional area is required Yes CaseMandatory Sensitive Yes Yes upper case letters Yes No MM/DD/YY Yes, upper case letters No

RoleName Type Last Reaffirm Date System

Yes Yes Yes Yes, at least one system is required No

RoleApprover

Company

Yes at Yes least one Company is required Yes No

RoleProfileIndicator

242

August 2010

Compliant User Provisioning Roles

Role Import Template Spreadsheet Role Import Column Description Responsibilityid This field is no longer used but it remains in the template for backward compatibility. It is a number used to represent the responsibility ID. Enter zero if not using this functionality. Comments Mandatory Options are Yes or No. Yes Yes use upper case letters Yes or mixed Yes. CaseMandatory Sensitive Yes use a N/A zero if not using this functionality

ParentRoleOwner

This field is no longer used as part of Compliant User Provisioning but it remains in the template for backward compatibility. Options are Yes or No. Select No, if not using this functionality.

Yes No Choose No if not using this functionality No No

Description_de

German short description. Required only if your users want to use Access Control in German.

DetailDescription_de German detailed description. Required only if your users want to use Access Control in German. Description_hu

No

No

Hungarian short description. Required only if No your users want to use Access Control in Hungarian. No

No

DetailDescription_hu Hungarian detailed description. Required only if your users want to use Access Control in Hungarian. Description_ja

No

Japanese short description. Required only if No your users want to use Access Control in Japanese. No

No

DetailDescription_ja Japanese detailed description. Required only if your users want to use Access Control in Japanese. Description_it Italian short description. Required only if your users want to use Access Control in Italian. Italian detailed description. Required only if your users want to use Access Control in Italian.

No

No

No

DetailDescription_it

No

No

Page 243 of 397

Compliant User Provisioning Roles

Role Import Template Spreadsheet Role Import Column Description Description_ es Spanish short description. Required only if your users want to use Access Control in Spanish. CaseMandatory Sensitive No No

DetailDescription_es Spanish detailed description. Required only if your users want to use Access Control in Spanish. Description_pt

No

No

Portuguese short description. Required only No if your users want to use Access Control in Portuguese. No

No

DetailDescription_pt Portuguese detailed description. Required only if your users want to use Access Control in Portuguese. Description_en English short description. Required only if your users want to use Access Control in English.

No

No

No

DetailDescription_en English detailed description. Required only if No your users want to use Access Control in English. Description_fr French short description. Required only if your users want to use Access Control in French. No

No

No

DetailDescription_fr

French detailed description. Required only if No your users want to use Access Control in French. The technical name of the business process, Yes which must exist in the system before the role is uploaded successfully. Only one business process is allowed per role. The technical name of the subprocess, which must exist in the system and be assigned to the business process listed in the Business Process column on this spreadsheet before the role is uploaded successfully. Only one subprocess is allowed per role. Yes

No

BusinessProcess

Yes use upper case letters Yes, use upper case letters

Subprocess

CriticalLevel

Options are Critical, High, Medium, and Low. Yes

No, suggest using mixed case letters as displayed in the description column

244

August 2010

Compliant User Provisioning Roles

Role Import Template Spreadsheet Role Import Column Description ReaffirmPeriod The number of months that a role needs to be reaffirmed. For example, enter a reaffirm period of one year or 12 months as 12. This column contains all custom role attributes for the role. CaseMandatory Sensitive Yes N/A enter a number N/A

Custom Attributes (Custom Fields for the Role)

No

Verification Training This column contains all system name for System your verification/training system.

No

Yes, use upper case letters

Changing Existing Roles with the Export/Import Spreadsheet


You can make mass changes to roles using a spreadsheet. Use the Search Role functionality to export the selected roles and create a spreadsheet with the existing roles and their role attributes. You can then change these attributes on the spreadsheet and import them back into the system using the Overwrite Existing Role option.

Role Creation
The Create Role option creates a role within Compliant User Provisioning. Note You cannot use this option to create roles in your SAP system. The Role Details screen displays certain fields, which are pre-configured on the Role Attributes screen. To access the Role Attributes screen, on the Configuration tab, navigate to Roles > Attributes. Then click each role attribute name to access its configuration screen. Each role configuration screen contains the following fields: Business Process Subprocess Systems Functional Area Company

Creating Roles
Procedure To create a role: 1. On the Configuration tab, navigate to Roles > Create Role. The Role Details screen appears. 2. In the Role Name field, enter the name of the new role. 3. In the Description field, enter the description of the new role. 4. In the Type dropdown list, select the type of role. The options are Single or Composite.

Page 245 of 397

Compliant User Provisioning Roles 5. From the Role/Profile/ Group dropdown list, select Role or Profile for the new role. When the role is displayed throughout Compliant User Provisioning, the standard SAP icon appears for roles and profiles. Note You can provision existing UME and LDAP user groups. We recommend you import the groups. If you choose to manually create groups in CUP, they must already exist in the UME and LDAP systems. For more information, see Configuring Provisioning for SAP UME Users Groups, UME Roles, and SAP EP Roles, and Configuring Provisioning for LDAP User Groups to Users.

6. From the Critical Level dropdown list, assign a level of criticality to the new role. The options are Critical, High, Medium, and Low. 7. In the ID field, enter a unique ID number. Enter 0, if not using this functionality. For Oracle, this is the Responsibility ID. For SAP, this field is no longer used, but it remains in the template for backward compatibility. It represents the responsibility ID. 8. From the Business Process dropdown list, select the business process to which the new role applies. 9. From the Subprocess dropdown list, select the sub-business process to which the new role applies. 10. In the Reaffirm Period field, enter the date range for reaffirming the new role. This is number of months after which you must reaffirm a role. Enter one year as 12 (months). 11. In the Last Reaffirm field, enter the date for reaffirming the new role. Enter the date in the format mm/dd/yyyy, or use the calendar icon to select a date. For more information, see the section Reaffirm Role. The Due field displays the date of the next reaffirmation. This display field is calculated based on the date of the last reaffirmation and the number of months specified for the reaffirm period. 12. From the Comments Mandatory dropdown list, select Yes or No. If Yes, select the check box for Allow Role Comments on Roles > Role Selection to make comments available when a user enters the role on a request. 13. From the Consider ParentRole Owner for ChildRole dropdown list, select Yes or No. This field is no longer used as part of the Compliant User Provisioning, but it remains in the template for backward compatibility. Select No, if you do not want to use this functionality. 14. On the System tab, click the plus icon to add the appropriate system. A dropdown list appears, from which you can select the system. To delete a system, select the row the system is in, and click the minus icon. You can set role assignment validity by role and by system by performing the following: a. Click the Check icon to set role assignment validity date. b. Set role assignment validity date. Select the system name. Set the Validity. Select one of the following: o o None Actual End Date

246

August 2010

Compliant User Provisioning Roles o c. Maximum Duration of Assignment

Set role status. Select one of the following: Enable roles you want to maintain but do not allow auto provisioning. Enable and Provision roles you want to maintain and allow auto provisioning when selected by a user. Disable roles that are disabled and are not displayed when the end user uses the Search feature to query for roles.

If you choose to use Role Mapping, the validity date of the main role applies to the dependent roles.

15. On the Detailed Description tab, enter a description of the new role. 16. On the Role Approver tab, enter the primary and alternate approvers. You can use the search icon to find approvers. You must add alternative approvers only if the stage with role as the approver determinator is configured for escalation to alternative approvers. If escalation is not configured for escalation to alternative approvers, there is no need to add alternative approvers. 17. On the Functional Area tab, click the new role. icon to add a functional area to associate with this

A dropdown list appears from which you can select the name of the functional area. 18. On the Company tab, click the icon to add the company to associate to this new role.

A dropdown list appears from which you can to select the name of the company. 19. On the Custom Attributes tab, click the icon to add custom attributes to the role.

For more information about custom attributes, see the section Custom Field Creation. 20. In the Verification/Training System tab, click the plus icon to display the dropdown menu for each field. You can use this tab to check role(s) against a verification/training system. Select the training system this role is applicable to, indicate if it is verified upon the request submission, and if the training system is active or not. 21. Click Save.

Role Search
The Search Roles option queries for roles based on the criteria you specify. You can filter your query for role name, role description, system, business process, subprocess, functional area, and role owner. After you receive the search results, you can change or delete roles, or export the search results from spreadsheet format. The export feature is not available in Compliant User Provisioning, if you are using Enterprise Role Management to create and maintain roles. In addition, from the Roles Information screen's Search Results, you can begin the role creation process, if the role you are looking for does not exist.

Page 247 of 397

Compliant User Provisioning Roles

Searching for a Role


Procedure 1. On the Configuration tab, navigate to Roles > Search Roles. The Search Roles screen appears. 2. Complete the following fields:

Field Role Name

Description Enter the role name you want to find. Enter the role name in UPPER case. Groups are UME and LDAP user groups. CUP allows you to provisioning existing UME and LDAP user groups. For more information, see Configuring Provisioning for SAP UME Users Groups, UME Roles, and SAP EP Roles, and Configuring Provisioning for LDAP User Groups to Users.

Role Description System Business Process Subprocess

Enter the role description you want to find. Enter the SAP system name where the role you want to find resides. Enter the business process associated with the role you want to find. Enter the business subprocess associated with the role you want to find.

Functional Area Enter the functional area associated with the role you want to find. Role Owner Enter the role owner associated with the role you want to find.

Alternatively, leave every field blank to view every role. 3. Click Search. The Roles Information screen displays the search results.

Role Exporting
You can download the role search results to your computer in spreadsheet format. This option make changes to the role information and then imports the file back into Compliant User Provisioning. For more information, see the section Import Roles.

Exporting Role Information


Procedure To export role information: 1. On the Roles Information, Search Results screen, click Export. A File Download dialog box appears. 2. Click Open to view the spreadsheet immediately, or click Save and select a location on your computer where you want to save the file.

248

August 2010

Compliant User Provisioning Roles

Role Selection
The Role Selection option enables you to narrow the scope of the search results for roles to a particular subset. This option is useful when you have a large number of roles to search. To optimize the search function, you can limit the search criteria to specific attributes of a role. Configuring the scope of the search reduces the amount of time necessary for approvers and access requestors when searching for the correct role during the creation of a request. All roles are imported into Compliant User Provisioning. When you search for a role as part of a request, the search is actually querying Compliant User Provisioning, not SAP. There are several role attributes used as search criteria that are not stored in SAP.

Configuring Role Selection


Procedure 1. On the Configuration tab, navigate to Roles > Role Selection. The Role Selection screen appears. 2. In the Approvers group, select one of the following settings: Allow All Roles This allows approvers to search for all roles. Keep in mind that searching a large set of roles can be time-consuming. Restrict Role Selection This allows approvers to search for a specific attribute. Use the dropdown list to select the attribute. Allow All Roles This allows access requestors to search for all roles. Keep in mind that searching a large set of roles can be time-consuming. Restrict Role Selection This allows access requestors to search for a specific attribute. Use the dropdown list to select the allowed attribute. Allow Users to Select Roles Check this box to allow users to select their own roles.

3. In the Access Requestor group, select one of the following settings:

4. In the Transaction Selection group, select one of the following settings: New Request Change Request

5. In the Role Comments group, you can enable the approver and access requestor to enter comments. You can also make comments required by selecting the appropriate checkbox. 6. In the Roles With No Approvers group, you can enable the Auto Approve Roles Without Approvers to approve roles with no defined approvers. When you enable the Approve Roles Without Approvers flag, it is applicable at any stage where the approval level is set to Role. Generally, you set the approval level to Role for those stages where the role is the approver determinator or when the stage is associated with Custom Approver Determinator (CAD) where the Role or Functional Area of Role is one of the attributes. Compliant User Provisioning then tries to determine approvers for each role. If there are no role owner defined in any of the roles of the request, then the request gives the error message, Approver not found . This exception is displayed in the previous stage when the approver approves the request.

Page 249 of 397

Compliant User Provisioning Roles Enabling this flag automatically approves these roles without defined approves. However, there must be approvers for at least one role, otherwise the same error message is displayed. Note To avoid the Approver not found error message, configure an escape route or, if the stage has a Role as the approver determinator, use one of the detailed conditions (No Role Owners or Roles with No Role Owner). For more information, see the section Detour Paths. 7. Under Display Existing Roles, choose Display Expired Roles for Existing Roles. This causes expired roles to be displayed in the Access Request. You then have the option to extend the validity date of an expired role for a user. 8. Click Save.

Default Roles Configuration


The Default Roles option configures a role for certain conditions. You configure default roles to be added to an access request depending on the attributes selected by the requestor. In addition, you can allow users to add default roles, add roles for the attributes you assign, and determine which user attributes to assign to default roles. When you configure these options, the system inserts a default role automatically into the access request, based on the value of the User Attributes field. In addition to configuring default roles, you can import default roles from another system and download a template that you can use to populate with your own default roles. Then you can import them into Compliant User Provisioning. To do so, import a spreadsheet file containing roles and role information from another system, which you can use as default roles. Finally, you can download a spreadsheet template file to your local system to use for importing default roles. After downloading the spreadsheet, populate the fields with your own default roles, and then import the information into Compliant User Provisioning. Example An example of using default roles is having an access request match the requirements that you configured using the Default Role Configuration screen, where you associate the company attribute with a role as a default. In this case, you set company name, SAP with the role, Z_AP_Payable. When a stage is set up to provision a role but only the company attribute is used in the request, the default role is determined by this association.

Configuring a Default Role


Procedure 1. On the Configuration tab, navigate to Roles > Default Roles. The Default Roles screen appears. 2. From the Consider Default Roles dropdown list, select Yes or No. 3. From the Default Role Level dropdown list, select Role or Request level. 4. From the User Attributes dropdown list, select the desired attribute. The choices you can make here depend on the default role level you select. 5. Click Save. 6. Click Create.

250

August 2010

Compliant User Provisioning Roles The Define Default Roles screen appears. 7. From the User Attributes dropdown list, select the desired attribute. 8. In the Value field, enter a value for each user attribute. 9. Click the icon in the Role column.

A field appears in the Role column, and a dropdown list appears in the System column. 10. In the Role column, enter the role name to be inserted into the request automatically when the request has a matching User Attribute, Value, and System. 11. In the System field, click the dropdown list to select the desired system name. 12. Click Save.

Importing Default Roles from an External System


Procedure Besides creating default roles from scratch, you can import a spreadsheet file containing roles and role information from another system, which you can use as default roles. To import default roles from an external system: 1. In the File Name field, enter the full path to the file, or click Browse to navigate to and select the file. 2. Click Import.

Downloading the Default Roles Template


Procedure You can download a spreadsheet template to your local system to use for importing default roles into Compliance User Provisioning. After downloading the spreadsheet, populate the fields with your own default roles and then import them. To download the default roles template: 1. Click Download Template. 2. Click Save. Be sure to save the template in a location where it is easy for you to find later. 3. Open the template. 4. Enter values for User Attribute, Roles Value, Role Profile Name, System and ID. Recommendation SAP recommends that you edit the downloaded template with your additional roles. Do not modify the sheet name and header names. When importing default roles, use upper case for the role name, since Compliant User Provisioning is case-sensitive. 5. After adding all the default role information, save the file on your local system. For more information, see the section Importing Default Roles from an External System to import this information to Compliant User Provisioning. For Superuser Access, use the Super User Access request type and configure the firefighter role as the default role.

Page 251 of 397

Compliant User Provisioning Roles

Role Mapping
You use Role Mapping to assign roles to specific systems and assign dependent roles to main roles. Role mapping makes it easier for requestors when specifying a role on a particular SAP back-end system. They are automatically granted a role when they specify a certain SAP system. Example One example of using default roles is when you want Role A to be followed by Role B. For example, Role A (accounts payable manager) is always accompanied by Role B (accounts payable display). Also, there are times when you want a default role to encompass many tasks or a single job, where one role is associated with a specific job. Procedure 1. On the Configuration tab, navigate to Roles > Role Mapping. The Role Mapping screen appears. 2. From the System dropdown list, select the desired system name. 3. From the Role Selected by User dropdown list, select the desired role name. Initially, this dropdown list is empty. You populate this list with role names that you define by adding a main role to the specified system. 4. To add a main role to a system and populate the Role Selected by User dropdown list for that system, click Add Main Role. The Select Main Role screen appears. 5. From the System dropdown list, select the desired system name. 6. Click Search. Any role names associated with the specified system name are displayed in the Search Results area. 7. Select a role name and click Add. The Role Mapping screen appears. The role name that you added now appears in the Role Selected by User field. After you finish adding main roles to the system, you can associate the main role with dependent roles that fall under the main roles umbrella. 8. In the System column, click Add. The Select Dependent Roles screen appears. 9. Make sure the system to which you want to add dependent roles appears in the System dropdown list, and then click Search. The Search Results screen appears. 10. Select one or more roles and click Add. The dependent role or roles now appear in the list below the main role. The validity date of the main role applies to all of its dependent roles.

252

August 2010

Compliant User Provisioning Roles

Importing Role Mapping


Procedure You can import files that already contain mapped roles. The files must be in spreadsheet format. In addition, Compliant User Provisioning provides a spreadsheet template that maps multiple roles and then imports the mapped roles into Compliant User Provisioning. 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Click Import. 3. Save the file to your local system. After mapping the roles, you can define the directory path to this file.

Downloading the Role Mapping Template


Procedure To download the role mapping template: 1. Click Download Template. 2. Click Save. Save the template in a location where it is easy to find later. 3. Open the template and enter values for Main System, Main Role, Dependent System, and Dependent Role. Recommendation SAP strongly recommends that you edit the downloaded template with your own role mapping information. Do not modify the sheet name and header names. When importing role mapping, use upper case for the main role name and dependent role name as Compliant User Provisioning is case-sensitive. Save the file to your local system. After using the template to create role mapping, you can define the directory path to this file, and then import the file. For more information, see the section Importing Role Mapping.

Deleting Main Roles


Procedure To delete a main role: 1. On the Configuration tab, navigate to Roles > Role Mapping. The Role Mapping screen appears. 2. From the Role Selected by User dropdown list, select the role name you want to delete. 3. Click Delete Main Role. A message appears stating that have you successfully deleted the main role.

Page 253 of 397

Compliant User Provisioning Roles

Enable and Remove Role Mappings


After you create mapped roles, you can configure role mapping to be enabled or disabled for the system and whether role maps apply to removals. Role removal relates to whether the role mappings function in reverse. Enabling this option means that when the main role is added to the request to be removed from a user, the mapped roles are also added to the request to be removed from the user. These are the same roles that would be added to the request if the main role were added. If you do not enable this setting, the main role can be removed from the user without affecting the mapped roles. The mapped roles are not added to the request as removals.

Role Attributes
Role Attributes are role categories that can be assigned to the role and or request to help the requestor find the desired roles, as well as to facilitate the workflow functionality. When the role attributes are assigned to the roles, they help the user select the roles when creating the request by filtering on these attributes. For example, if a user wants a finance role and all the finance roles have been assigned to the Finance functional area, the requestor can display roles by selecting the functional area Finance. In addition, if the user selects functional area Finance on the request header, by default, when you click the Select Roles button, only the Finance roles are displayed. The predefined attributes in the following table are included in your installation. You can also define your own attributes to support your needs by adding custom fields. Although SAP suggests some attribute definitions, you can define them to suit your business.

Predefined Attributes Attributes Company Description Suggested definition: A global organization or division. Company can be assigned to a request and a role. Functional Area Suggested definition: The business unit, such as HR or Finance. Examples: Administration Sales and Distribution Marketing Production R&D Functional areas can be assigned at the request level and at the role level.

254

August 2010

Compliant User Provisioning Roles

Predefined Attributes Attributes Description Administration Sales and Distribution Marketing Production R&D

Application Area

Suggested definition: The system that contains the application. Application area is the top of the hierarchy for business process and subprocess. Application area is not required. Application area is defined only at the role level. Suggested definition: The process of the actual work, such as accounting. Business process is required at the role level. Suggested definition: A subprocess of the actual work, such as auditing. Subprocess is required at the role level and is a subprocess associated with a particular business process. Every subprocess can be assigned to only one business process.

Business Process Business Subprocess

Functional Area The name of the approver for the organization for the combination of functional and Company area and company. Set the owner/role for the workflow stages in your approval path. This attribute is required only if one of your stages uses this option as an approver determinator. For more information, see the section Defining a Stage. The definitions of these predefined attributes are suggestions and can be defined differently for your companys requirements. For example, Functional Area might be defined as a business function for one company and a location for another. When you have defined attributes using the Attributes option, the attributes appear in the dropdown lists whenever you go to the Access Request entry screens or the Select Roles screen, depending on whether the attribute can be defined at the request and role level or only the role level. On the Select Role screen, these attributes help the requestor to find the roles by filtering the role selection.

Configuring Company Attributes


Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute selection screen appears. 2. Click Company. The Role Attribute, Company screen appears. 3. Click Create. Three empty fields appear for Company ID, Short Description, and Description. 4. In the Company ID field, enter the name of the organization.

Page 255 of 397

Compliant User Provisioning Roles 5. In the Short Description field, enter a short description of the company. The information in the Short Description field appears in dropdown lists when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a longer description of the company. 7. Click Save.

Changing a Company Attribute


Procedure 1. On the Company screen, select the Company ID you want to change. 2. Click Change. The Company ID and Company Description fields become active. 3. Make any edits. 4. Click Save.

Configuring Functional Area


Procedure To configure a functional area: 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute selection screen appears. 2. Click Functional Area. The Role Attribute, Functional Area screen appears. 3. Click Create. Three empty fields appear for Name, Short Description, and Description. 4. In the Name field, enter the name of the functional area. 5. In the Short Description field, enter a short description of the functional area. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a description of the functional area. 7. Click Save. Functional Area approvers are maintained on the Approvers > Point of Contact screen.

Changing a Functional Area


Procedure 1. On the Functional Area screen, select the functional area you want to delete or change. 2. Click Change. The Short Description and Description fields become active. 3. Make any edits.

256

August 2010

Compliant User Provisioning Roles 4. Click Save.

Configuring an Application Area


Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute selection screen appears. 2. Click Application Area. The Role Attribute, Application Area screen appears. 3. Click Create. Four empty fields appear for a Name, Short Description, Description, and System. 4. In the Name field, enter the name of the application. 5. In the Short Description field, enter a short description of the application. 6. In the Description field, enter a description of the application. 7. At the end of the System field, click the arrow icon to view a list of systems. The Select System screen appears. 8. Select a system from the list. 9. Click Select to populate the System field. 10. Click Save.

Importing Application Area Attributes


Procedure Compliant User Provisioning allows you to import files containing application area attributes. The files must be in spreadsheet format (.xls). To import application area attributes: 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Select the Overwrite Existing checkbox, if you want to overwrite existing files, 3. Click Import.

Downloading the Application Area Attributes Template


Procedure Compliant User Provisioning provides you with a spreadsheet template (.xls) to configure multiple application area attributes and then import into Compliant User Provisioning. To download the application area attributes template: 1. Click Download Template. 2. Click Save. Be sure to save the template in a location where you can find it later. 3. Open the template. 4. Enter values for Application Area, Short Description, Description, and System.

Page 257 of 397

Compliant User Provisioning Roles Recommendation It is recommended that you edit the downloaded template with your own application area attributes. Do not modify the sheet name or header names. Areas are available for a short description and long description in the following languages: en = English es = Spanish de = German fr = French pt = Portuguese ja = Japanese The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. Click Save. After using the template to add application area attributes, you can define the directory path to this file, and then import the file using the instructions in the section Importing Application Area Attributes.

Changing an Application Area


Procedure 1. On the Application Area screen, select the application area you want to delete or change. 2. Click Change. The Application Area and Description fields become active. 3. Make any edits. 4. Click Save.

Configuring Business Processes


Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute screen appears. 2. Click Business Process. The Role Attribute, Business Process screen appears. 3. Click Create. Six empty fields appear for Name, Short Description, Description, Owner/Approver, Alternate Approver, and Application Area. 4. In the Name field, enter the name of the business process. 5. In the Short Description field, enter a short description of the business process. 6. In the Description field, enter a description of the business process. 7. In the Owner/Approver field, enter the name of the primary approver. You can use the Search icon to query for the desired user ID. 8. In the Alternate Approver field, enter the name of the secondary approver.

258

August 2010

Compliant User Provisioning Roles You can use the Search icon to query for the desired user ID. 9. In the Application Area field, at the end of the System field, click the arrow icon to display a list of application areas. The Select Application Area screen appears. 10. Select an application area. 11. Click Select. 12. Click Save.

Importing Business Process Attributes


Procedure Compliant User Provisioning allows you to import files containing business process attributes. The files must be in spreadsheet format (.xls). To import business process attributes: 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Select the Overwrite Existing checkbox, if you want to overwrite existing files. 3. Click Import.

Importing a Business Process Attributes Template


Procedure Compliant User Provisioning provides you with a spreadsheet template (.xls) which you can use to configure multiple business process attributes and then import back into Compliant User Provisioning. To download the business process attributes template: 1. Click Download Template and then click Save to save the XLS template file to your system. Be sure to save the template in a location where it is easily found. 2. Open the template and then enter values for Business Process, Approver, Alternate Approver, Application Area, Short Description, and Long Description. Recommendation It is highly recommended that you edit the downloaded template with your own business process attributes. Do not modify the sheet name or header names. Areas are available for you to enter a short description and long description in the following languages: en = English es = Spanish de = German fr = French pt = Portuguese ja = Japanese The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters.

Page 259 of 397

Compliant User Provisioning Roles Save this file to your local system, where it is stored. After using the template to add application area attributes, you can define the directory path to this file, and then import the file using the instructions in the section Importing Business Process Attributes.

Changing a Business Process


Procedure 1. On the Business Process screen, select the process you want to change. 2. Click Change to modify the selected business process. The Short Description, Description, Owner/Approver, Alternate Approver, and Application Area fields become active. Make any edits. 3. Click Save.

Configuring a Business Subprocess


Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute screen appears. 2. Click Business Subprocess. The Role Attribute, Business Subprocess screen appears. 3. Click Create. Three empty fields appear for a Name, Short Description, and Description, and a dropdown list appears from which you can select a Business Process. 4. In the Name field, enter the name of the business subprocess. 5. In the Name field, enter the name of the business subprocess. 6. In the Short Description field, enter a short description of the business subprocess. 7. In the Description field, enter a description of the business subprocess. 8. In the Business Process dropdown list, select the desired business process name. 9. Click Save.

Changing a Business Subprocess


Procedure 1. In the Business Subprocess screen, select the business subprocess you want to change. 2. Click Change to modify the selected business subprocess. The Short Description and Description fields and the Business Process dropdown list become active. Make any edits. 3. Click Save.

260

August 2010

Compliant User Provisioning Roles

Configuring the Functional Area and Company Attribute


Procedure To configure the functional area and company attribute: 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attributes screen appears. 2. Click Functional Area and Company. The Role Attribute, Functional Area and Company screen appears. 3. Click the icon.

Four empty fields appear under Functional Area, Company, Owner/Approver, and Alternate Approver. 4. In the Functional Area column, click the dropdown list to select the desired functional area. 5. In the Company column, click the dropdown list to select the desired company. 6. In the Owner/Approver column, click the Arrow icon to open the Approvers for Functional Area and Company screen, where you can query for approvers. 7. Click the icon.

Two empty fields appear in the Approver and Alternate Approver columns. Use the Search icon to query for approvers. If you have more than one row of approvers, you must select a lead approver by clicking the option button at the end of the appropriate row. Lead approvers are also indicated by the Hat icon at the beginning of the row. 8. Click Save. The Owner/Approver and Alternate Approver fields are populated. 9. Click Save.

Importing Functional Area and Company Attributes


Procedure Compliant User Provisioning allows you to import files containing functional area and company attributes. The files must be in spreadsheet format (.xls). To import functional area and company attributes: 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Select the Overwrite Existing checkbox, if you want to overwrite existing files. 3. Click Import.

Downloading the Functional Area and Company Attributes Template


Procedure Compliant User Provisioning provides you with a spreadsheet template (.xls) which you can use to configure multiple functional area and company attributes and then import them into Compliant User Provisioning.

Page 261 of 397

Compliant User Provisioning

To download the functional area and company attributes template: 1. Click Download Template. 2. Click Save. Be sure to save the template in a location where it is easy for you to find later. 3. Open the template. 4. Enter values for Functional Area, Company ID, Approver ID, Alternate Approver ID, and IS Lead. Recommendation It is highly recommended that you edit the downloaded template with your own business process attributes. Do not modify the sheet name or header names. Areas are available for you to enter a short description and long description in the following languages: en = English es = Spanish de = German fr = French pt = Portuguese ja = Japanese The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. Click Save. After using the template to add application area attributes, you can define the directory path to this file and then import the file using the instructions in the section Importing Functional Area and Company Attributes.

Deleting the Functional Area and Company Attribute


Procedure To delete the functional area and company attribute: 1. On the Functional Area and Company screen, select the Functional Area you want to delete by clicking anywhere in that row, outside any of the active fields. 2. Click the icon to delete the selected functional area.

Role Reaffirmation
Compliant User Provisioning allows you to an send automatic email reminders to any role approver responsible for reaffirming a role. Use the Reaffirm Role option to configure the number of days prior to the actual reaffirm date to send the email reminder. The Role Reaffirmation option is similar to User Access Review with role approver with the exception of Role Reaffirmation entails configuring the reaffirm date on roles.. For more information on configuring role reaffirmation, see Access Control 5.3 Application Help.

262

August 2010

Compliant User Provisioning Role Reaffirmation

You must schedule and run the Email Reminders background job to determine which roles are due for reaffirmation and send the email reminders to the role approvers. Recommendation SAP recommends that you run the Email Reminders background job once daily.

Configuring an Email Reminder for Role Reaffirm


Procedure To configure the email reminder for reaffirming a role: 1. On the Configuration tab, navigate to Roles. This option expands to display Reaffirm Role. 2. Click Reaffirm Role. The Reaffirm Role screen appears. 3. In the Number of days prior to Reaffirm due date (to send email reminder) field, enter the number of days prior to the reaffirm date that you want to send the email reminder. The system sends an email notification to the approvers the specified number of days prior to the reaffirmation date set for each role. 4. Click Save. Note Remember to schedule and run the Email Reminders background job to analyze roles for reaffirmation and send the email notifications. Note When creating a role, it is required that you set the Role Reaffirmation Period (Months) in the Role Details screen. You can set a date for the last role reaffirm and based on the period, the due date is automatically calculated. You can later modify this setting, if required. For more information on configuring role reaffirmation, see the section, Role Creation in this guide.

Page 263 of 397

Compliant User Provisioning Background Jobs

Background Jobs
You use background jobs to run selected tasks. SAP delivers the following Background Jobs for Compliant User Provisioning:

Background Job Email Reminder Email Reminder for SoD Review Email Reminder for UAR Escalation HR Triggers HR Triggers Load Data Role Reaffirm Notification SoD Review Load Data with Mitigated Risks SoD Review Load Data without Mitigated Risks SoD Review Process Rejected SoD Review Update Workflow Stale Requests

Description Send reminder for all non SoD or UAR requests that are inactive for the configured number of days. Send reminder for SoD requests that are inactive for the configured number of days. Send reminder for UAR requests that are inactive for the configured number of days. Create escalation workflow for all requests that are past the configured escalation threshold days. Create requests from the HR system user data. Extract user data from HR system and load into CUP. Send notification to persons whose roles are flagged as removed. Extract data from RAR batch risk analysis data, load into CUP, and create requests. Include items with mitigated risks. Extract data from RAR batch risk analysis data, load into CUP, and create requests. Include only items without mitigated risks. Send requests that are rejected and flagged for regeneration. If Admin Review Required is mandatory, move request to next reviewer in workflow. Close all Stale requests. For more information, see Stale Requests.

UAR Review Load Data UAR Review Process Rejected UAR Review Update Workflow

Extract user and role information from ERM. Process all requests flagged as rejected. If Admin Review Required is mandatory, send all requests to next reviewer in workflow.

The background jobs screen also lists any UAR Load Data Tasks you created. For more information, see the Compliant User Provisioning > UAR Load Data Tasks section.

264

August 2010

Compliant User Provisioning Background Jobs

Configuring Background Jobs


Procedure 1. On the Configuration tab, navigate to Background Jobs. The Schedule Service screen appears. 2. In the Task Name field, use the search function to select a background job. The Background Jobs screen displays the configuration for the job. 3. Choose the Schedule Type and configure the Task Recurrence. The appropriate Task Occurrence group appears.

If you choose Immediate, the background job will run immediately. It will not display in the Display Schedule. 4. Choose Run, Activate, Save, or View Schedule. Pushbutton Run Activate Save Display Schedule Description Run the job immediately; ignore the start date. Enable the job; run it per the start date. Save the configuration information; do not activate it. Show all scheduled jobs. Note The list does not display background jobs of the type Immediate. By definition, these are run immediately, therefore are not scheduled.

Page 265 of 397

Compliant User Provisioning User Default Management

User Default Management


Managing user defaults allows you to link data fields that are automatically set for newly created users. After you configure user defaults, the data is transferred to the SAP back-end system as defaults. The User Defaults option assigns the following values: User Defaults Option Assignments Assignment Description

Selecting a User You must select an SAP back-end system to act as the default system where Default System you can get the user defaults. The list of SAP systems in the dropdown list is based on the active SAP connections on the Connectors screen. For more information, see the section Selecting a User Default System. You must select a user default system before you create user defaults. Configuring User Defaults Use this option to assign user defaults in the SAP back-end system for new users. For more information, see the sections Configuring User Defaults and Changing User Defaults. You must select a user default system before you create user defaults. For more information, see the section Selecting a User Default System. Setting User Use this option to create, change, or activate/deactivate the user default. For Default Mapping more information, see the sections Setting User Default Mapping and Deleting a User Default Mapping.

Configuring User Defaults


Procedure To configure user defaults: 1. On the Configuration tab, navigate to User Defaults > User Defaults. The User Defaults screen appears. 2. Click Create. The Create User Defaults screen appears. 3. In the Name field, enter the name for the default. 4. From the System dropdown list, select the system where you want the user defaults to be applied. You can apply multiple systems to the user default. 5. In the Short Description field, enter a short description of the default.

266

August 2010

Compliant User Provisioning User Default Management

The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a description of the default. 7. In the Start Menu field, enter an SAP-specific (SU01) start menu. 8. From the Logon Language dropdown list, select the default language to be used during logon. 9. From the Decimal Notation dropdown list, select a decimal notation style for the default. 10. From the Date Format dropdown list, select a date format for the default. 11. From the Output Device dropdown list, select an output device for the default, such as a printer. 12. From the User Group dropdown list, select a default user group. 13. Select the Output Immediately checkbox, if you want the output to be immediately sent (to a printer, for example), rather than waiting to send output collectively in a batch job. 14. Select the Delete After Output checkbox, if you want the output to be deleted instead of stored. 15. In the Parameter ID (PID) Details group, click the You can add multiple parameters. 16. Click Save. icon to add a parameter and its value.

Setting User Default Mapping


Example You can map a user default with one or many attributes (along with the associated conditions and values) so that when a submitted request meets the specified settings, the request is automatically assigned the user defaults. For instance, you map the user default to have the attributes, Request Type=New and Functional Area=Finance . Any request having these two attributes are automatically assigned the user defaults. Procedure To set user default mapping: 1. On the Configuration tab, navigate to User Defaults > User Default Mappings. The Available User Default Mapping screen appears. 2. Click Create. The Create User Default Mapping screen appears. 3. In the Name field, enter a name for the user default mapping. 4. In the Short Description field, enter a short description of the default mapping. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. In the Description field, enter the description of the default mapping. 6. From the User Defaults dropdown list, select a user default.

Page 267 of 397

Compliant User Provisioning User Default Management

The User Defaults in the dropdown list are created using the User Default option. For more information on creating these, see the section Configuring User Defaults. 7. From the Attribute dropdown list, select an attribute. This is a Compliant User Provisioning-specific attribute. 8. From the Value dropdown list, select a value. The values are automatically populated in the dropdown list based on the specified attribute. 9. From the Condition dropdown list, select a logical operator. 10. Click Add Attribute. The default mapping appears in the User Default Mapping Details screen. 11. Click Save.

Selecting a User Default System


Procedure To select a user default system: 1. On the Configuration tab, navigate to User Defaults > User Defaults System. The User Default System screen appears. 2. From the System dropdown list, select the desired SAP system. 3. Click Save.

Changing User Defaults


Procedure 1. On the User Default screen, select the user default you want to change. 2. Click Change. The Change User Defaults screen appears. 3. Make any changes. 4. Click Save.

Deleting User Default Mapping


Procedure To delete a user default mapping: 1. Select the user default mapping you want to delete from the User Default Mapping Details table. 2. Click Delete.

268

August 2010

Compliant User Provisioning Attachments

Attachments
The Attachments feature adds attachments at the request level. Attachments are not stored in Compliant User Provisioning due the amount of disk space they require. You must designate a network folder to store all attachments. Provide Folder For Request Attachments: By entering the folder in this field you are enabling the attachment feature. Leaving this field blank disables the Attachment feature and prohibits requestors from attaching external documents to the requests.

System Log Monitoring


The Monitoring option allows you to view the system log and see what applications are provisioned in Compliant User Provisioning. The Monitoring option provides access to the following logs: System Log Monitoring Access Log Monitored Description

System Log Use the System Log option to view the current log file. The system log contains such information as errors, sequence of operation, transaction flow, and exception reports. For more information, see the section Viewing the System Log. Application Log Use the Application Log option to view a users access history to applications with that users provisioning actions in Compliant User Provisioning. The application log displays the following types of actions: USER CREATE Action that indicates that a user was created in SAP by an Compliant User Provisioning approver. ROLE ADD USER LOCK USER UNLOCK ROLE DELETE USER DELETE

For more information, see the section Viewing the Application Log.

Viewing the System Log


Procedure To view the system log: 1. On the Configuration tab, navigate to Monitoring > System Log. The Application Trace screen displays the default system log file name. 2. Click Get Log. The system log appears.

Page 269 of 397

Compliant User Provisioning HR Trigger

Viewing the Application Log


Procedure To view the application log: 1. On the Configuration tab, navigate to Monitoring > Application Log. The Application Log screen appears. 2. In the User field, enter the user ID of the user who requested access to an application. 3. Click the search icon to search for a valid user ID. 4. In the Changed By field, enter the user ID of the user who changed an access request. 5. Click the Search icon to search for a valid user ID. 6. In the Roles field, enter the role associated with the access request. 7. Click the Search icon to search for a valid role. 8. In the From Date field, enter the date that the access request was first submitted. 9. Click the calendar icon to select a date from a calendar. 10. In the To Date field, enter the date that the access request was provisioned. 11. Click the calendar icon to select a date from a calendar. 12. Click Search. The search displays the Application Log screen.

HR Trigger
You use HR Triggers to create rules and actions that automatically trigger CUP workflow requests when changes occur in the SAP HR system, such as new employee hires, position changes, or personal data changes. Features Actions Select and configure specific CUP actions when a rule is triggered. Rules Configure the parameters that determine when an action is performed. Field Mapping Map SAP HR fields to CUP fields. Process Log View a record of CUP HR Trigger updates.

Prerequisites You have created connectors the SAP HR system. Process 1. Create field mapping. 2. Configure workflow.

270

August 2010

Compliant User Provisioning HR Trigger 3. Configure actions. 4. Configure rules. 5. Configure provisioning. 6. Schedule background jobs.

Page 271 of 397

Compliant User Provisioning HR Trigger

Creating Field Mappings


You use Field Mapping to map SAP HR System fields to CUP fields. 1. In CUP, select the Configuration tab. In the left navigation pane, select HR Trigger -> Field Mapping. The Field Mapping screen appears. 2. Select the SAP HR System dropdown and choose a system. 3. Select one of the following options to configure the mapping: Use the delivered standard CUP and HR mapping. Select the Load Standard Field Mapping pushbutton. This loads the standard CUP and SAP HR mapping. Customize the field mappings. Load the standard field mapping and change the field names and parameters. Add new fields. Select the plus icon and enter information for the following fields: o CE Field o Field Type o Info. Type o Sub Type o Field Name Recommendation SAP recommends you use the standard field mappings.

If you add new fields, you must set them as mandatory in End User Personalization.

Configuring Workflows
Configure the workflow for the request submitted through HR Triggers. 1. 2. 3. 4. Select the Configuration tab. In the left navigation pane, select Workflow. Create an initiator. Create a customer approver determinator. Create the required stages and add them to the path for the request.

For more information, see the Workflow Management section.

Creating Actions
You use Actions to specify the type of CUP request to be triggered when an event occurs in the SAP HR system, such as Create a user access review request when a new employee is entered in the SAP HR system. Procedure 1. Select the Configuration tab. In the left navigation pane, select HR Trigger -> Actions. The Available Actions screen appears. 2. Select the Create pushbutton. The Actions Details screen appears.

272

August 2010

Compliant User Provisioning HR Trigger 3. Enter information in the required fields. Required fields are marked with an asterisk (*). 4. Choose the Type and Priority. The Type and Priority determine the initiator for submitting the request. Choose from the following types: Change Account Change Request for Role Based Init Change Request - Rush Delete Account Information Lock Account New Account New Hire Request laptop, PC Superuser Access Telephony mobile/landline Unlock Account

Choose from the following priorities: High Medium Low

5. Select the following tabs and enter information: Tab Activity System 1. Add the system you want to update with the changes. 2. Choose the Valid From and Valid To dates. Address Choose whether you want to update the date for the following fields : Name Email Telephone The data is fetched from the HR Trigger field mapping configuration. Choose whether to update this field with changed data when the user is provisioned. Parameter Ids are fetched from CUP User Defaults. Choose whether the SU01 User Defaults is for provisioning. Values are fetched from the CUP User default. Choose whether to update the User Group field [User Group, User Group Name]. This updates the user Group tab in SU01.

Parameter ID

Default

User Group

Page 273 of 397

Compliant User Provisioning HR Trigger 6. Select Save.

Creating Rules
Procedure 1. Select the Configuration tab. In the left navigation pane, select HR Trigger -> Rules. The Available Rules screen appears. 2. Select the Create pushbutton. The Rule Details screen appears. 3. Select HR Systems, and choose the HR system you want to define a rule. You must define rules for all HR Systems individually. 4. Enter information for the required fields: Rule Id Effective from Rule Short Description

5. Choose the action: a. Select the right arrow icon. The Select HR Trigger Actions screen appears.

b. Select an action and choose the Select pushbutton. The Rule Details screen appears, and the Action Short Description field is automatically entered with the action name. 6. Define the rule you want to trigger the request: a. On the Attribute tab, select the plus b. icon. The table becomes active.

Enter information for the following fields: Info Type Sub Type Field Operator Value

The Info Type and Sub Type point to a specific field in the SAP HR system. $ is the old value of the field.

274

August 2010

Compliant User Provisioning HR Trigger

Changing a Rule
Procedure 1. On the Rules screen, select the rule name you want to change or delete. 2. Click Change. The fields under the Info Type, Sub Type, Field, Operator, Value, and And/Or/Not columns become active. 3. Make any modifications. 4. Click Save.

Deleting a Rule
Procedure 1. On the Rules screen, select the rule name you want to change or delete. 2. Click Delete.

Configuring Provisioning
You can configure HR Trigger to use direct or indirect provisioning. This section explains the auto provisioning options as it pertains to HR Trigger. Direct Provisioning for HR Triggers: o Position does not have roles associated. o HR Event triggers a CUP request. o During the workflow approval process, the approver manually adds or removes the roles. o Roles are provisioned to SU01. Indirect Provisioning for HR Triggers: o CUP fetches roles from Position for the request. o During the workflow approval process, approver can remove roles or add additional roles. Old Roles Delimit Duration The duration for which old roles are assigned to a user for a position change. o If you pick 0 years, 0 months, 0 days as the delimit duration, then the role is only assigned for todays date. o If you enter 3 in days, then the roles is delimited 3 days from the day the request was created. For HR trigger indirect provisioning, only Position type is supported Position and Personnel (User) has a one-to-one relationship. (Provisioning to Position affects only one personnel.) For more information about the auto provisioning process, see the Workflow > Auto Provisioning section.

Page 275 of 397

Compliant User Provisioning Password Self Service

Schedule HR Trigger Background Jobs


To get information from the SAP HR system to Compliant User Provisioning, you must configure the following background jobs: HR Triggers Load Data This job retrieves the data updated in SAP HR system. SAP recommends you schedule this job for every 60 seconds. HR Triggers This job triggers requests based on the updates from SAP HR system. SAP recommends you schedule this job for every 80 seconds

For more details on job scheduling, see the Background Jobs section.

View Process Log


You can view all the CUP HR Triggers processes in the Process Logs. 1. Select the Configuration tab. 2. In the left navigation pane, select HR Trigger -> Process Log. The HR Trigger Process Log screen appears. If the request number is displayed, the request is processed. If no request number is displayed, either there is an error or the request has not processed. The comments field provides a brief explanation of the request and its status.

Password Self Service


The Self Service option allows end users to reset their passwords in the SAP back-end system without having the SAP Help Desk or the SAP Security Group involved. This tool saves the SAP Security Group time and expedites the password resetting process for the end user. The Password Reset via a CUA requires that the attribute for Initial Password is set to Everywhere in the CUA central system. You can use transaction SCUM to set the attribute. There are three options for Password Self Service: SAP HR Authentication: Requires the SAP HR module to be used for personnel information and personnel numbers linked to SAP user IDs, so that the user submitting the request for the password reset can be verified against their personnel data in the SAP HR system. Challenge Response: Allows the administrator to configure questions that the users can register their answers against. When a user enters a request to reset their passwords, they are asked to answer the questions as they have pre-registered them. Only on successful answering the questions will the passwords be reset. PeopleSoft HR Authentication: Requires the PeopleSoft HR module to be used for personnel information, so that the user submitting the request for the password reset can be verified against their HR data.

When a user enters a request for a password reset, Compliant User Provisioning validates that user against the selected password self-service option. Once the user has been verified, the passwords are reset and an email is sent to the user based on the email address configured for that user.

276

August 2010

Compliant User Provisioning Password Self Service

Selecting Specific Systems for Password Self Service


You can choose to enable password self-service for specific systems. This feature is available for the following connector types: SAP SAP Enterprise Portal Oracle Applications JD Edwards PeopleSoft IdM

This feature is not available for LDAP and SAP EP LDAP type. You configure this feature in the CUP connectors screen. For more information, see Configuration Tasks and Defining Connectors for IdM Systems.

Password Self Service for SAP HR and PeopleSoft HR


You configure which infotype, field, value combination in SAP HR personnel record is verified against the user. In configuration, select the infotype and field combination. When the user enters the request to reset their passwords, the user is asked to enter information based on the infotype field configured. The information they enter is matched against the users personnel record on that specific infotype value. If there is a match, the passwords are reset and sent to the email listed on the HR personnel record. Configuration can include one or multiple infotype/field combinations. The user could be asked to enter multiple responses which will be compared to the HR record. For instance, it can be configured that the user must enter their SSN, their national insurance number as well as their birth date. Procedure 1. On the Configuration tab, navigate to Self Service. The Self Service screen appears. 2. Complete the Verification Configuration information. a. Under the Verification Configuration section, select Authentication Source, and choose SAP HR or PeopleSoft HR. b. You can choose to disable verification. Click Select Service to Disable Verification and choose from the following: None All Password Self-service Change Name Self-service For more information, see Disabling Verification. c. Select Save. 3. Complete the Verification Fields information. a. In the Verification Fields section, click Create. The fields in the Info Type, Sub Type, Field, and Description columns become active.

Page 277 of 397

Compliant User Provisioning Password Self Service CUP matches user IDs with HR personnel records using the Communication Infotype 0105 record subtype 01 b. Set the status to Active. c. Click Save.

4. Choose the verification data source. a. In the Verification Data Source section, select a system to authenticate passwords from the System dropdown list. The user must exist in the HR records. This drop down only shows the connectors that have been configured as HR connectors. CUP uses the data from this system to verify the values of fields and values entered by the user for password self service. b. Click Save. 5. Choose the default system.

a. In the Default System section, select a system.


CUP retrieves the info types from this system when configuring the SAPHR info types and fields for verification. The dropdown list shows all SAP connectors that have been configured (both R and non-HR). b. Click Save.

Defining Password Self-Service for Challenge Response


In the Challenge Response option, the administrator can enter a variety of questions the users can choose from. The number of questions that the user must enter can also be configured. In addition to the questions, the administrator decides how many wrong answers are permitted before the user ID is locked. Example As the administrator, you can create challenge questions for end users to select and answer. After creating these questions, you must activate them in order to display them when the end user accesses the Registration link from the End User Form. These questions should be generic and easy to answer. For instance, a simple challenge question may be, What is your favorite color?

Procedure To configure password self service for Challenge Response: 1. On the Configuration tab, navigate to Self-Service. The Password Self Service screen appears. 2. In the Verification Configuration section, select Authentication Source, and choose Challenge Response. 3. Enter information for the Number of Questions End User has to Register field. This is the number of questions the user must answer during self-registration. This is also the number of questions the users must answer before their user IDs are reset. 4. Enter information in the Number of Unsuccessful Attempts after which user gets locked field. This is the number of attempts the user can try and enter the correct answers before their user ID is locked. The user IDs can be unlocked via the User Registration screen.

278

August 2010

Compliant User Provisioning Password Self Service 5. Click Save. 6. Under the List of Questions section, enter a questions that users can choose from when registering their user Ids for password self-service. You must enter at least as many questions as your response to Number of Questions End User has to register: 7. Activate each question by clicking on activate icon (match stick). 8. Click Save.

Disabling Verification
Password self-service configuration includes the option for No Challenge Response. This feature enables users in the Windows NT environment to validate their passwords using Windows NT itself; allowing the SAP GRC Access Control application to skip the password self-service challenge response verification. Procedure 1. Log on to CUP -> Configuration ->Password Self-Service. The Self-Service screen displays. 2. Click Authentication Source and select Challenge Response. 3. Click Select Service to Disable Verification and select Self-Service (Password SelfService). You can also select to disable challenge response verification for other services: Change Name Self-Service All (Change Name and Password Self-Service) None Note To enable challenge response verification for all services, select None. That is, you are not choosing to disable challenge response verification for any services. 4. Click Save

Disabling Password Self Service


You can disable password self-service by removing the Self-Service link from the Request Access screen. 1. On the Configuration tab, navigate to End User Personalization. The Request Form Customization screen appears. 2. Select the Password Self-Service Link. 3. Click Change. 4. In the Visible dropdown menu, select No. 5. Click Save.

Configuring Separate Password Self Service Page


You can choose to have users go to a separate Password Self Service page, instead of the default Request Access page. This feature supports Single Sign-On.

1. Log on to the SAP Enterprise Portal administration page. 2. Create an iView page. Use this URL: http://Server IP address:Port Number/AE/index_pss.jsp

Page 279 of 397

Compliant User Provisioning Miscellaneous Configuration

User Registration
All users who have registered for Password Self-Service are available for searches and are displayed on this screen. Once searched, the users user ID, status and number of attempts to answer their challenge questions are displayed. If a user gets locked due to the number of unsuccessful attempts, the administrator must to unlock their user ID from this screen. Delete - deletes the users registration record. The user must perform self-registration again to choose and answer their challenge questions. Unlock - unlocks the user who has been locked due to unsuccessful attempts to answer the challenge questions.

This feature is controlled by a User Management Engine permission. Users must self-register to answer their challenge questions. Users are also able to reregister anytime by choosing the re-register option on the Password Self-Service screen after they have answered their challenge questions.

Miscellaneous Configuration
The Miscellaneous Configuration screen defines system-level settings not associated with other features of Compliant User Provisioning. It establishes the workflow types to be integrated with the other GRC Access Control features and capabilities. You can configure the following settings from this screen: Language Configuration Log Level Configuration Cache Job Interval Configuration Background Job Interval Configuration Configure Workflow Types

Language Configuration
When you initially log on to Compliant User Provisioning, three fields are displayed on the Welcome screen: User ID, Password, and Language. Although User ID and Password are required fields, Language is not. Set a default language in the Miscellaneous screen by selecting a language from the Language dropdown list and then clicking Save. Log off and then log back on for this change to take effect in the user interface.

If a user selects a language from the Language dropdown list on the Welcome screen that differs from the default language specified on the Miscellaneous screen, the default language is overridden and the user interface appears in the end user-selected language.

To ensure proper display of object descriptions, you must create all objects in the default language. Objects created in a non-default language display descriptions in the default language even when logged on to a different language. When users log on to Compliant User Provisioning using the default language, they can create objects such as Initiator, Stage, Path, Approver, and the like. However, if they log on using a language from the Language dropdown list on the Welcome screen that differs from the default language specified in Miscellaneous Configuration, they can only use the Change option to modify

280

August 2010

Compliant User Provisioning Miscellaneous Configuration the object settings. They cannot use the Create option to create a new object. By default, Compliant User Provisioning shows the default language description and allows the end user to modify the object with the corresponding language text.

Log Level Configuration


Each transaction that is performed generates a message and in some cases, multiple messages. Compliant User Provisioning automatically logs these messages. When you configure the log level setting, you specify which transaction messages it logs and which it ignores. There are four log levels: Debug logs all messages, regardless of type. Info logs all error, warning, and information messages. Warn logs all error and warning messages. Error logs all error messages (no warning or information messages).

To set the log level, select the level from the Log Level dropdown list, and then click Save.

Cache Job Interval Configuration


For a high standard of performance, Compliant User Provisioning maintains a store of system data in a cache. This allows access to key data without having to perform a database call. On start up, the system loads the data from its database into the cache, and it refreshes the data each time it performs a transaction. To ensure that the cached data is current, even when Compliant User Provisioning is idle, the system periodically refreshes the cache. When you configure the cache job interval, you specify the amount of time that must elapse before the system automatically refreshes the cache data. You define the interval in seconds. To set the Cache Job Time Interval, enter the number of seconds that the application must wait before refreshing the cache into the Cache Job Time Interval in Seconds text field and then click Save.

Configure Workflow Types


The Configure Workflow Types feature establishes the workflow types to be integrated with the other GRC Access Control features and capabilities. Although some of the Workflow Type configuration is delivered with the initial system data, you must configure the additional fields and URLs for your system. Name is delivered by the Initial System Data XML file loads. Description and Short Description: Although these fields come populated by the System Data load, you cannot change these descriptions. The Short Description is displayed on screens and on dropdown lists throughout Compliant User Provisioning. Exit URL: This is the URL that Compliant User Provisioning uses to connect and communicate with this capability. MITICTRL:
http://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?wsdl&style=document

MITIOBJ:
http://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?wsdl&style=document

RISK

http://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?wsdl&style=docum ent

Page 281 of 397

Compliant User Provisioning Miscellaneous Configuration RE http://<server>:<port>/AEWFExitServiceWS_5_2/Config1?wsdl&style=document User Name: This is the name of the user Compliant User Provisioning uses to access that capability. This user ID must have the appropriate User Management Engine permissions to perform the tasks that are required. Password: This is the password for the specified user name. Active: This value determines whether this workflow type is active or not for your system. If the checkbox is selected, it is active. If not, this workflow type is not active, it cannot be used in configuration, and it is not displayed in the Compliant User Provisioning screens and dropdown lists.

Configure the Background Job Interval


Compliant User Provisioning uses a daemon process to run scheduled background jobs. The daemon runs periodically and executes all background jobs scheduled to run. Setting the background job interval determines how much time must elapse before the background job daemon is executed. To set the Background Job Time Interval, in the Background Job Time Interval in Minutes field, enter the number of minutes that Compliant User Provisioning waits before running the background job daemon. Then click Save.

282

August 2010

Enterprise Role Management Configuring Enterprise Role Management

6. Enterprise Role Management


Enterprise Role Management allows you to create and maintain roles to reflect your business model and requirements. You should set up a functional environment and test it thoroughly before attempting to use it in a production environment.

Configuring Enterprise Role Management


SAP recommends that you configure certain functions before others In Enterprise Role Management. Note Changes to configuration entities (that is, activities you perform on the Configuration tab) are not captured in the ERM audit trail. Process The suggested order for configuring Enterprise Role Management is: 1. Set up initial logon to Enterprise Role Management 2. Import initial system data 3. Define system landscape 4. Configure management of role attributes 5. Configure management of condition groups 6. Set up role creation methodology 7. Configure management of naming conventions 8. Configure management of organizational value mapping 9. Configure Risk Analysis and Remediation 10. Configure workflow management 11. Configure Compliant User Provisioning

You can configure the following functions in any order: Enterprise Role Management system logs Management of background jobs Mass role import Other functions

Initial Logon to Enterprise Role Management


After installing Enterprise Role Management on a SAP NetWeaver server, use a Web browser to log on and access it. Typically the URL for Enterprise Role Management logon is: http://<server>:50000/RE/index.jsp This is where the SAP NetWeaver server, by default, runs (port number 50000). If you log on within the company firewall, the SAP system administrator can provide the server address. On the initial screen, select User Logon to display the Logon screen, and then use the REAdmin user name and password.

Page 283 of 397

Enterprise Role Management Initial System Data Importation

The REAdmin user name and password are created during the Access Control installation process. For more information, see the section Role Creation. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3.

Initial System Data Importation


Before you configure Enterprise Role Management, you must import initial system data. This data is the default system data that is pre-packaged with the system. It is the minimum set of data required for the application to function and is imported from within the application itself. Import initial system data only if it was not done during the post-installation phase of the SAP GRC Access Control installation process as described in the section Role Creation. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3.

Importing Initial System Data


Procedure To import initial Enterprise Role Management configuration data: 1. On the Configuration tab, navigate to Initial System Data. The Import Data screen appears. 2. Click Browse. 3. Navigate to the directory containing the Enterprise Role Management installation files. 4. In the Browse window, double-click the appropriate XML file. 5. In the Enterprise Role Management content screen, click Import. The files you import are: RE_init_clean_and_insert_data.xml: Select Insert. RE_init_append_data.xml: Select Append. RE_init_methodology_data.xml: Select Append. This step is required only for a new installation or if you want to reload the default data originally shipped with Enterprise Role Management. Result Initial system data is now imported, and Enterprise Role Management is now ready for further configuration.

Initial Background Job


Executing initial background jobs for Org Value Sync, Transaction/Object/Field Sync, and Activity. Org Val Sync is a prerequisite for SAP role authorization data maintenance and organizational value mapping.

284

August 2010

Enterprise Role Management Managing Background Jobs

Managing Background Jobs


You use background jobs to synchronize information in Enterprise Role Management with the SAP back-end system and to perform mass maintenance. Enterprise Role Management provides two kinds of background job: Dynamic - Dynamic background jobs are scheduled by Enterprise Role Management users through mass role import and role mass maintenance. For more information see the sections Mass Role Import and Role Mass Maintenance. The following dynamic background jobs are available: Role Generation This job sends role information from Enterprise Role Management to the SAP back-end system. You can use the Mass Generation option to schedule the background job. Risk Analysis and Role Generation This job schedules role generation for a particular role. You use the Role Maintenance screen to schedule a background job. Risk Analysis This job schedules a risk analysis for a set of roles. You use the Mass Risk Analysis option to schedule the background job. Role Import This job uploads the roles from the SAP back-end system to Enterprise Role Management. You use the Mass Role Import screen to schedule a background job. Role Usage Synchronization This job synchronizes usage data. You use the Role Usage Synchronization screen to schedule a background job. Static - Static background jobs are scheduled by the Enterprise Role Management administrator and can be run immediately or periodically to synchronize the SAP system with Enterprise Role Management. The following static background jobs are available: o o o Org Value Sync: This job synchronizes the organizational values in Enterprise Role Management with the SAP ERP back-end system. Transaction/Object/Field Sync: This job synchronizes the Transaction, Object, and Field values with the SAP back-end system. Activity Val Sync: This job synchronizes Activity field values.

Using the Enterprise Role Management background job feature, you can: Create background jobs. Search for specific background jobs. Schedule background jobs to run immediately or at a specific time in the future. Edit existing background jobs. Delete background jobs. Activate or deactivate scheduled background jobs. View a background jobs history.

You can schedule the number of background jobs you want to run concurrently by setting the count on the Miscellaneous screen. This setting allows only a fixed number of background jobs to run at one time. If the number of background jobs scheduled to run exceeds the number set on the Miscellaneous screen, the surplus jobs are queued and run in the order scheduled. For more

Page 285 of 397

Enterprise Role Management Managing Background Jobs information about scheduling the number of background jobs to run concurrently, see the section Configuring Miscellaneous Functions.

Creating a Static Background Job


Procedure To create a static background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click Create. The Schedule Service screen appears. 3. In the Job Name field, enter the name you want to give the background job. 4. From the Task Name dropdown list, select the type of task you want to run. 5. From the Schedule Type dropdown list, select when you want the background job to run. Selecting any value other than Immediate displays a scheduling screen where, depending on the schedule you selected, you can schedule: The start and end date The time for the job to run The day, month, quarter, or year for the job to run The specific date for the job to run 6. Click Schedule. The system provides a Job ID number and places it in the top position in the Search Results screen of the Background Jobs screen.

Editing a Background Job


Procedure To edit a background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click the radio button next to the Job ID of the background job you want to change. 3. Click Edit. The Schedule Service screen appears. 4. Make any changes. 5. Click Schedule.

286

August 2010

Enterprise Role Management Managing Background Jobs

Deleting a Background Job


Procedure You can only delete background jobs in the Ready State. 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click the button next the Job ID of the background job you want to delete. 3. Click Delete. 4. Click OK to confirm the deletion.

Activating/Deactivating a Background Job


Procedure You can activate or deactivate a background job only if it is active (running). 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click the button next to the Job ID of the background job you want to activate or deactivate. If a background job is active, the light bulb icon in the Active column appears as on. If the background job has been deactivated, the light bulb icon appears as off. 3. Click Activate or Deactivate.

Searching for a Background Job


Procedure To search for a background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Select your search criteria from the available dropdown lists. 3. Click Search. The results of your search appear in the Search Results screen.

Viewing the History of a Background Job


Procedure To view the history of a background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click the button next to the Job ID of the background job for which you want to view a history. 3. Click Job History. The Background Job History screen appears.

Page 287 of 397

Enterprise Role Management Configuring Risk Analysis Integration with RAR

Configuring Risk Analysis Integration with RAR


Enterprise Role Management works directly with Risk Analysis and Remediation to perform the following functions: Risk analysis Risk mitigation Authorization function search Transaction usage

Prerequisite You have performed all the RAR post-installation steps. For more information, see the SAP GRC Access Control 5.3 Installation Guide.

Procedure To configure Enterprise Role Management Web services for Risk Analysis and Remediation: 1. On the Configuration tab in Enterprise Role Management, navigate to Miscellaneous. 2. Scroll to the Web Service Info. for CC Risk Analysis section. 3. Determine if Risk Analysis and Remediation is deployed on the same SAP NetWeaver server. If it is on the same server, select Do not use Web Service and skip only the configuration for CC Risk Analysis in step 4. For this option, Enterprise Role Management integrates with Risk Analysis and Remediation using EJB service within the Web server to facilitate faster integration. Configuration for all other Web services in step 4 is still required. If it is not on the same server, select Use Web Service, and continue with step 4 to configure all Web services.

4. On the Configuration tab, identify the correct Risk Analysis and Remediation Web service URLs, and then enter each in its corresponding field on the following screens: Web Service Info. for CC Risk Analysis Web Service Info. for CC Transaction Usage Web Service Info. for Mitigation Control Web Service Info. for CC Functions

5. Enter the Web service user name and password. Obtain the Web service user name and password for the Web services from your system administrator. This user communicates across the GRC capabilities through the Web services configured in each application. Use the same user name and password information from the connector and create a common Web user in the User Management Engine (UME) for all capabilities. Using the same user for all Web service configurations across the GRC capabilities helps avoid integration issues caused by incorrect user name, password, and/or authorizations. 6. Click Save.

288

August 2010

Enterprise Role Management Configuring Workflow Integration with CUP

Identifying the correct Web Service URL


1. Open a new browser session, and navigate to the Web Application Server http://<server>:50000/. 2. In the new browser window, click Web Services Navigator to display the Web Services Navigator screen. 3. Expand the folder that corresponds to the Web service: CC Risk Analysis expands the VirsaCCRiskAnalysisService folder. CC Transaction Usage expands the VirsaCCActionUsageService folder. CC Mitigation Control expands the VirsaCCMitigation5_0Service folder. CC Functions expands the VirsaCCFunction5_0Service folder.

4. Click Document. The Web service URL is listed below the Web Services Description Language (WSDL) heading. 5. Right-click the Web service URL, and then click Copy Shortcut. 6. Return to the Configuration / Miscellaneous screen, and paste the URL into the appropriate Web service URL field. 7. Repeat for each CC Web service URL.

Configuring Workflow Integration with CUP


Enterprise Role Management integrates with Compliant User Provisioning for the role approval workflow feature. During the approval phase, the role is submitted for approval using Compliant User Provisioning approval workflow.

Configuring CUP Workflow for Enterprise Role Management


Procedure You perform the workflow configuration activities for the Enterprise Role Management approval process in Compliant User Provisioning. To configure Compliant User Provisioning for use with Enterprise Role Management, you must have Compliant User Provisioning administrator privileges. For more information on completing the following procedure, see the section Workflow under Compliant User Provisioning. 1. On the Configuration tab of Compliant User Provisioning, navigate to Initial System Data. 2. Import the initial configuration data from the file AE_init_append_data_RE.xml into Compliant User Provisioning, using Append on the Import Initial Data screen. For more information, see the Compliant User Provisioning section of this guide. Import initial system data only if it was not done during the SAP GRC Access Control installation process as described in the section Role Creation. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides - > SAP BusinessObjects -> SAP

Page 289 of 397

Enterprise Role Management Configuring Workflow Integration with CUP BusinessObjects Governance, Risk, Compliance (GRC) -> Access Control -> SAP GRC Access Control 5.3. After the initial configuration data is imported, you see RE in the dropdown list for workflow types during the following configuration steps. If you do not see the RE type, the initial data file was not imported successfully. 3. Select Request Configuration. 4. Create a Request Type for Enterprise Role Management requests. These requests are role approval requests from Enterprise Role Management. Make sure you activate the request type. The request Workflow Type must be set to RE. 5. Create a Priority for Enterprise Role Management requests. The priority Workflow Type must be set to RE. 6. Select Workflow. 7. Create an Initiator for Enterprise Role Management requests. a. Click Initiator. b. Click Create. c. Enter Initiator Name and Description

d. Set the initiator Workflow Type to RE. Select Condition And and Attribute Request Type. Select Value from the dropdown list. This should be the request type for Enterprise Role Management which you created in step 4. Click Add Attribute. Select Condition And and Attribute Priority. Select Value from the dropdown list. This should be the priority for Enterprise Role Management which you created in step 5. Click Add Attribute. Click Save. 8. Create a Custom Approver Determinator for Enterprise Role Management requests: a. Set the CAD Type to Web Service. The Workflow Type must be set to RE. Enter the Web Service URI. Enter the Web service User Name and Password. Click Save. To find the correct URI for Compliant User Provisioning, follow steps a through d in the section Configuring Enterprise Role Management Web Services for Compliant User Provisioning. Expand the AEWFCADApproversServiceWS_5_2 folder to obtain the correct Compliant User Provisioning URI. The Web service user must be the same user you created for application integration in the earlier configuration step. 9. Create the Enterprise Role Management approver stage for the approval workflow process.

290

August 2010

Enterprise Role Management Configuring Workflow Integration with CUP Depending on your approval process, you can create an additional approval stage by creating another Custom Approver Determinator by repeating step 8. Using CAD Type Attribute. The Workflow Type must be set to RE. The approver determinator you select here is the custom approver determinator you created in step 8. 10. Create a workflow path for the Enterprise Role Management approval process: a. Click Path. b. Click Create. c. Enter Path Name and Description.

d. Set the Workflow Type to RE. Enter the Number of Stages based on the number of stages you created in step 9. For example, if you created 1 stage, enter 1, etc. Select the Initiator that you created in step 7. For Path Definition in the Path section, select the stage(s) you created in step 9. Click Save. e. Select Miscellaneous to configure exit Web service for Enterprise Role Management approval workflow. f. Configure the exit Web service information for Enterprise Role Management approval workflow.

The Exit URL is the return path for role approval or rejection information from Compliant User Provisioning to Enterprise Role Management. To find the correct exit URL for Compliant User Provisioning, follow steps a through d in the section Configuring Enterprise Role Management Web Services for Compliant User Provisioning. Expand the AEWFExitServiceWS_5_2 folder to obtain the correct Compliant User Provisioning Exit Service URL. 11. Click Active.

Configuring ERM Web Services for Compliant User Provisioning


Procedure To configure Enterprise Role Management's Web services for Compliant User Provisioning: 1. On the Configuration tab in Enterprise Role Management, navigate to Miscellaneous. The Configuration screen appears. 2. Identify the correct Compliant User Provisioning Web service URL: a. Open a new browser session and navigate to the Web Application Server http://<server>:50000/. Click Web Services Navigator. The Web Services Navigator screen appears. Expand the AEWFRequestSubmissionService_5_2 folder, and then click Document. The Web service URL is listed below the WSDL (Web Services Description Language) heading. Right-click Web Service URL and select Copy Shortcut from the context menu.

Page 291 of 397

Enterprise Role Management System Landscape Definition 3. Return to Enterprise Role Management's Configuration screen, and paste the URL into the Workflow URL field in the Web Service Info. for AE Workflow section. 4. Click Save to save your selections.

System Landscape Definition


A system landscape is a configuration of systems where role definition, creation, testing, and risk analysis are performed. Prior to creating a landscape, you must define the systems, determine which system for which you plan to generate roles, and which system you plan to use for risk analysis purposes only. Then, you can create a system landscape where each system is associated with the actions to be used in the role management process. Any field name denoted with an asterisk (*) is required. If you adhere to change control procedures in your ERP application (where all roles are created in Development, then transported to Quality Assurance/Production), you should not have a production system in your landscape associated with Role Generation action. Example You have three systems (or connectors) in a landscape, in which to perform the role creation process: Test Development Production or Quality Assurance This landscape uses the test system to design, define, and test your roles. When you are comfortable with the role definition, generate the role in the development system for additional testing. When you have successfully tested it in the development system, transport the role to the quality assurance system and then to the production system, according to your existing ERP change control procedure by using ERP change control tools. For risk analysis to reflect your most realistic risk, the either the production system or the quality assurance system serves as the system of origin against which you perform risk analysis.

292

August 2010

Enterprise Role Management Defining Connectors for Enterprise Role Management

Defining Connectors for Enterprise Role Management


You can set up different types of connectors in Enterprise Role Management. These include Enterprise, non-SAP, SAP, and SAP EP connectors. The Enterprise, non-SAP, and SAP EP connectors are descriptive connectors used to document the landscape to which each role belongs. The SAP connector is a live system connector that facilitates the transfer of data between Enterprise Role Management and other SAP ABAP systems.

When setting up a landscape, you specify how you want Enterprise Role Management to communicate with the target systems by associating the connectors with predefined actions during the landscape creation process. The actions available for you to associate the connectors with are delivered with Enterprise Role Management. You cannot create your own actions. Access Control communicates with multiple systems; therefore SAP recommends using HTTPS communication protocol for secure communication.

Configuring a Connector for SAP


Your network administrator must provide information for completing the Create System screen. Procedure To create a connector for SAP ABAP systems: 1. Go to Enterprise Role Management > Configuration tab > System Landscape > Systems. The Available Systems screen appears. Until you create your first connector, the Available Systems screen is blank. 2. Click Create. The Create System screen appears. 3. In the System Type dropdown menu, select SAP. 4. Select the SLD Connector checkbox to activate the Standard Landscape Directory. 5. In the Name field, enter the target system name. This is the SAP connector name. The connector names are very important when integrating to other GRC products and the CUA. Make sure that the connector name for Access Control is the same as the one configured for CUA. 6. In the Message Server Name field, enter the name of the message server, which is used for load balancing of your SAP clustered environment. 7. In the SAP Version dropdown menu, select the appropriate SAP version. Enterprise Role Management supports SAP 4.6c and higher. 8. Click Save. When you have created the new connector, click Test Connection to ensure that the connection is valid.

Page 293 of 397

Enterprise Role Management Defining Connectors for Enterprise Role Management

Configuring a Connector for Enterprise, Non-SAP, or SAP EP


You can use the following procedure to plan and document the connection between ERM and non-ABAP systems. Note These are not live connectors, thus they cannot be utilized to communicate with the target systems from ERM. The following procedure is only for role documentation. Procedure To create a connector for Enterprise, non-SAP, or SAP EP: 1. Go to Enterprise Role Management > Configuration tab > System Landscape > Systems. The Available Systems screen appears. 2. Click Create. Your network administrator must provide information for completing the Create System screen. 3. In the System Type dropdown menu, select Non SAP. 4. In the Name field, enter the name of the system. 5. In the Description field, enter a detailed description of the system. 6. Click Save.

Creating the Landscape


A system landscape is a logical grouping of systems. A landscape contains more than one system and is populated by assigning systems and then associating them with a predefined action or actions. Associating actions with a system defines which action is performed in which system within a particular landscape. Example You can associate role risk analysis with a test system or a production system and a generation of roles to a development system. The predefined actions you can associate with a connector in a landscape are: Role risk analysis Generation of roles These predefined actions are delivered with Enterprise Role Management. You cannot create your own actions.

Setting up a landscape allows you to associate role definitions that you create in Enterprise Role Management to multiple systems. The landscape can contain SAP and non-SAP systems. You can configure certain role definitions to be associated to a specific landscape.

294

August 2010

Enterprise Role Management Defining Connectors for Enterprise Role Management Example You create a landscape that contains the system types SAP HR system, SAP FI system, and Oracle Application system (non-SAP). Each of these system types has a system for Development, Test, and Production. You name this landscape, Palo Alto Landscape. In Enterprise Role Management, go to the Role Management tab > Roles > Create to create a role definition and specify the landscape, Palo Alto Landscape. In the Role Generation phase of role creation, you can select the appropriate system (with Generation of Role action assigned) for the role generation. Automated Role Generation from Enterprise Role Management is applicable to SAP ABAP only. After completing the creation of role definitions, you must define the Web service URL that submits the role definitions to the approval workflow process in Compliant User Provisioning. Go to Configuration tab > Miscellaneous. In the Configuration screen, enter the Web service URL in the Web Service Info. for AE Workflow pane. In Compliant User Provisioning, a request is submitted to the approval workflow. This request is a RE (Role Expert) workflow type. Make sure that the RE workflow type is active by going to Compliant User Provisioning > Configuration tab > Miscellaneous. After the request is approved in the last stage in the workflow process, the role is saved to the Palo Alto Landscape.

Creating a Landscape
Procedure 1. To create a landscape: 2. On the Configuration tab, navigate to System Landscape > Landscape. The Search System Landscape screen appears. 3. Click Create. The Create Landscape screen appears. 4. In the Name field, enter a name for the landscape. 5. In the Description field, enter a brief description for the landscape. 6. From the Status dropdown list, select Enable or Disable for the landscape. If the landscape is enabled, it is visible during the role creation process. 7. From the Type dropdown list, select a system type. 8. Click Save. Now you can assign systems to the landscape. For more information, see the section Assigning Systems to the Landscape.

Page 295 of 397

Enterprise Role Management Defining Connectors for Enterprise Role Management

Assigning Systems to the Landscape


Procedure Before you can assign systems to a landscape, you must create the landscape. To assign systems to the landscape: 1. On the Configuration tab, navigate to System Landscape > Landscape. The Search System Landscape screen displays available system landscapes. Search for the landscape on the search screen, or scroll down the landscape list. 2. Select the landscape you would like to perform system assignment to by selecting the checkbox next to the landscape name. 3. Click Change. The Change Landscape screen appears. 4. Click Assign Systems. The Assign Systems to Landscape screen appears. You can assign one or more systems to a landscape, depending on the actions you want the system to perform. 5. Click Add. All systems available for this landscape type appear on a dropdown list for the user to select. 6. Select a System from the dropdown list. 7. To assign more systems to the landscape, repeat steps 5 and 6. 8. Click Save. The systems are assigned to the landscape, and you can associate the systems with predefined actions.

Associating Actions
Procedure To associate actions with systems assigned to a landscape: The actions available to associate with the systems are delivered with Enterprise Role Management. You cannot create your own actions. 1. On the Configuration tab, navigate to System Landscape > Landscape. The Search System Landscape screen displays all available system landscapes. Search for a landscape on the search screen, or scroll down the landscape list. 2. Select the landscape you would like to perform system assignment to by selecting the checkbox next to the Landscape Name. 3. Click Change. 4. From the Change Landscape screen, click Assign Systems. 5. From the Assign Systems to Landscape, click Associate Actions. 6. From the Associate Actions screen, assign systems to actions.

296

August 2010

Enterprise Role Management Role Designer To activate a dropdown list from which you can select a connector for an action, click the Add icon under the action you want to associate. 7. Click Save. An Option button appears in the Default column. 8. To set a default system for the landscape, click the Option button to the right of the action you want to set as default. The system and its associated action are automatically saved in the landscape as the default connector. If you have associated more than one system with an action, you must set a default connector for that action. For example, systems A, B and C are assigned to the action Generation of Roles. By setting connector B as the default connector for that action, the system generates all roles created in this landscape with connector B. For individual role generation, you change the default or add more systems on the Role Generation screen. For mass role generation, the default system is always used and cannot be changed, unless you change the default in your system assignment configuration.

Role Designer
Role Designer provides you with a logical, step-by-step roadmap to support configuration of role master data for your Enterprise Role Management process. Following the outlined procedure ensures that major role master data configuration steps or data to be associated with each role are not missed. Features When you select the role designer step, the system takes you directly to the configuration task to allow you to: Define role building methodology Define naming conventions Define role attributes Define organizational value mapping Define approval criteria Analyze transaction usage for roles

Managing Role Attributes


Role attributes are the details that define a role during the role definition and creation process. You determine values for each attribute during Enterprise Role Management configuration and then assign or input the defined attributes when you create a role. Role attributes you can manage include: Business Processes Business Subprocesses Functional Areas Custom Fields Projects and Releases

Page 297 of 397

Enterprise Role Management Role Designer

Managing Business Processes


A business process is a collection of related activities that produces something of value for your organization or business and is categorized according to the organizational structure of your enterprise. A business process can be managerial, operational, or supporting, and can be defined narrowly or broadly, depending on your business needs. When you create a role in Enterprise Role Management, the business process you assign to the role is one of the roles defining attributes and determines which subprocesses you can assign to that role. Any field name denoted with an asterisk (*) is required. Example Some examples of business processes are: Finance Accounts payable Policy and budget Procure to pay

Creating a Business Process


Procedure To create a business process: 1. On the Configuration tab, navigate to Role Attribute > Business Process. The Search Business Process screen appears. 2. Click Create. The Create Business Process screen appears. 3. In the Business Process ID field, enter a name for the business process. 4. In the Description field, enter a brief description for the business process. 5. In the Abbreviation field, enter an abbreviation for the business process. The abbreviation you provide is used as a bar label in the Role Library, Roles by Business Process bar graph on the Role Management tab. 6. Click Save. Your business process is saved and now appears in the list of business processes on the Search Business Process screen.

298

August 2010

Enterprise Role Management Role Designer

Changing a Business Process


Procedure To change a business process: 1. On the Search Business Process screen, select the checkbox next to the business process you want to modify. 2. Click Change. The Change Business Process screen appears with the Business Process ID dimmed, indicating that the ID itself cannot be changed. To change a business process ID, you must delete the business process and create a new one. 3. Make any changes to the description or abbreviation. 4. Click Save.

Deleting a Business Process


Procedure To delete a business process: A business process can be deleted only if it is not associated with a role, business subprocess, approval criteria, or condition group. 1. On the Search Business Process screen, select the checkbox next to the business process you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion.

Importing a Business Process


Procedure You can either maintain the business processes in Enterprise Role Management manually or mass import your data using the import feature. 1. On the Search Business Process screen, click Import. The Import Business Process screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import. The system message Business Process saved successfully indicates that the data was imported successfully.

Page 299 of 397

Enterprise Role Management Role Designer Managing Business Subprocesses A business process can be divided into several business subprocesses, each with its own attributes. A business process typically contains one or more subprocesses. Any field name denoted with an asterisk (*) is required.

Creating a Subprocess
Procedure To create a subprocess: 1. On the Configuration tab, navigate to Role Attribute > Subprocess. The Search Subprocess screen appears. 2. Click Create. The Create Subprocess screen appears. 3. In the Subprocess ID field, enter a name for the subprocess. 4. In the Description field, enter a brief description for the subprocess. 5. In the Abbreviation field, enter an abbreviation for the subprocess. 6. Click Save. Your subprocess is saved and now appears in the list of subprocesses on the Search Subprocess screen.

Deleting a Subprocess
Procedure To delete a subprocess: A subprocess can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Search Subprocess screen, select the checkbox next to the subprocess you want to delete. 2. Click Delete. Click OK to confirm the deletion.

Changing a Subprocess
Procedure To change a subprocess: 1. On the Search Subprocess screen, select the checkbox next to the subprocess you want to modify. 2. Click Change. The Change Subprocess screen appears with the Subprocess ID dimmed, indicating that the ID cannot be changed. 3. Make any changes to the description or abbreviation 4. Click Save.

300

August 2010

Enterprise Role Management Role Designer

Mapping Subprocesses to Business Processes


Procedure During the role creation process, the subprocesses available for you to select as role attributes are determined by the business process to which the subprocess is mapped. To map a subprocess to a business process: 1. On the Configuration tab, navigate to Role Attribute > Business Process. The Search Business Process screen appears. 2. Select the business process to which you would like to map a subprocess, and then select Process Mapping. The Associate Business Subprocess to Business Process screen appears. If the business process you select already has an associated subprocess, the subprocess appears in the search results area of the screen. 3. Click Add. A dropdown list appears in the Subprocess ID column. 4. Select a subprocess from the dropdown list. Only those subprocesses not already assigned to a business process appear in the dropdown list. 5. Click Save. A business process can include more than one subprocess. Repeat steps 3 through 5 to map another subprocess to the same business process. Alternatively, select another business process from the Business Process dropdown list at the top of the screen, and then repeat steps 3 through 5.

Importing Subprocesses
Procedure You can manually maintain the subprocesses within Enterprise Role Management, or you can mass import your data using the import feature. 1. On the Search Subprocess screen, click Import. The Import Subprocess screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not check this box. 4. Click Import The system message Subprocess saved successfully indicates that the data was imported successfully.

Page 301 of 397

Enterprise Role Management Role Designer Managing Functional Areas A functional area is a classification of processes for a department or business process. Within SAP, a functional area is used to organize certain activities within a department or business process. In Enterprise Role Management, a functional area is a role attribute used to categorize roles and define the approval and role maintenance processes. In addition, a functional area is used to filter the results of a role search, identifying only those roles associated with a specific functional area. Any field name denoted with an asterisk (*) is required. Example Within your business you might have the business process Procurement, which contains the functional areas of Purchasing, Administration, and Receiving. However, one or more of these functional areas might also fall under the business process Finance.

Creating a Functional Area


Procedure To create a functional area: 1. On the Configuration tab, navigate to Role Attribute > Functional Area. The Search Functional Area screen appears. 2. Click Create. The Create Functional Area screen appears. 3. In the Functional Area ID field, enter a name for the functional area. 4. In the Description field, enter a brief description for the functional area. 5. In the Abbreviation field, enter an abbreviation for the functional area. 6. Click Save.

Changing a Functional Area


Procedure To change a functional area: 1. On the Search Functional Area screen, select the checkbox next to the functional area you want to modify. 2. Click Change. The Change Functional Area screen appears with the Functional Area ID dimmed, indicating that the ID cannot be changed. 3. Make any changes to the description or abbreviation. 4. Click Save.

Deleting a Functional Area


Procedure To delete a functional area:

302

August 2010

Enterprise Role Management Role Designer

A functional area can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Search Functional Area screen, select the checkbox next to the functional area you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion.

Importing a Functional Area


Procedure You can manually maintain the functional areas within Enterprise Role Management, or you can mass import your data using the import feature. 1. On the Search Subprocess screen, click Import. The Import Functional Area screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import The system message Functional area saved successfully indicates the data was imported successfully. Managing Custom Fields Custom fields allow you to add attributes to a role that are specific to your company or organization. For example, if you want to distinguish a role by region, add a custom attribute and assign a specific region when you create the role. Any field name denoted with an asterisk (*) is required.

Creating a Custom Field


Procedure To create a custom field: 1. On the Configuration tab, navigate to Role Attribute > Custom Fields. The Custom Fields screen appears. 2. Click Create. The Create Custom Fields screen appears. 3. In the Name field, enter a name for the custom field. This name is a unique identifier for the field. 4. In the Description field, enter a brief description for the custom field.

Page 303 of 397

Enterprise Role Management Role Designer 5. In the Field Label field, enter a name for the custom field. This is the field name that appears on your Role Maintenance and Search screens. 6. From the Field Type dropdown list, select a field type. The field type can be either a dropdown list or a text field. If the field type is a dropdown list, select a data source from which to import the data for the custom field. There are two data sources: SAP and RE. o o If you select SAP, you can select a Source System and enter both a Table Name and a Field Name. If you select RE, you can enter multiple field values users can select from in the Custom Fields Values section.

If the field type is a text field, select a data type from the dropdown list. Available data types are: o o o Date Numeric Varchar2

If the data type is either Numeric or Varchar2, you must define the number of characters allowed in the custom field. Enter the data in the Data Length field. 7. Click Save. The custom field appears in the Available Custom Fields list.

Changing a Custom Field


Procedure To change a custom field: 1. On the Custom Fields screen, select the checkbox next to the custom field you want to modify. 2. Click Change. The Change Custom Fields screen appears with the name of the custom field dimmed, indicating that the name cannot be changed. 3. Make any changes. 4. Click Save.

Deleting a Custom Field


Procedure To delete a custom field: A custom field can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Custom Fields screen, select the checkbox next to the custom field you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion.

304

August 2010

Enterprise Role Management Role Designer

Importing a Custom Field


Procedure You can manually maintain the custom fields within Enterprise Role Management, or you can mass import your data using the import feature. 1. On the Custom Field screen, click Import. The Import Custom Fields screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select the Overwrite checkbox. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import. The system message Custom field saved successfully indicates that the data was imported successfully. Managing Projects and Releases The project or release can be a project name, release name, or release number that you want to associate with a particular role. The Project or Release ID field allows you to track and filter roles by project or release based on your organizations requirements. Any field name denoted with an asterisk (*) is required.

Creating a Project or Release ID


Procedure To create a project or release ID: 1. On the Configuration tab, navigate to Role Attribute > Project/Release. The Search Project/Release screen appears. 2. Click Create. The Create Project/Release screen appears. 3. In the Project/Release ID field, enter a project name, release name, or release number. 4. In the Description field, enter a description of the project or release. 5. Click Save. The project or release appears in the Project/Release ID column of Search Results area on the Search Project/Release screen.

Changing Project or Release Information


Procedure To change project or release information:

Page 305 of 397

Enterprise Role Management Role Status 1. On the Search Project/Release screen, select the checkbox next to the project or release you want to modify. 2. Click Change. The Change Project/Release screen appears with the Project/Release ID dimmed, indicating that the ID cannot be changed. 3. Make any changes in the Project/Release Description field. 4. Click Save.

Deleting a Project or Release


Procedure To delete a project or release: A project or release name or number can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Search Project/Release screen, select the checkbox next to the project or release you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion.

Importing a Project or Release


You can manually maintain the project or releases within Enterprise Role Management, or you can mass import your data using the import feature. Procedure 1. On the Project/Release screen, click Import. The Import - Project/Release screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import. The system message Project/Release saved successfully indicates the data was imported successfully.

Role Status
During the role creation process, Role Status is a required field. You can set the status of the role to Development or Production. Development indicates that the role is not ready for production usage and is usually not transported to a production environment.

306

August 2010

Enterprise Role Management Managing Condition Groups Production indicates that the role is ready for production usage and usually is transported to a production environment.

The role status is used by the system for integration with Compliant User Provisioning role synchronization, with Enterprise Role Management set as the role source. If the role status is set to Production, Enterprise Role Management synchronizes the role to Compliant User Provisioning for user provisioning. Therefore, role status is predefined and delivered with Enterprise Role Management. You can change the role status description only. The configuration parameter Synchronize ERM roles allows you to synchronize ERM roles that are in production status to Compliant User Provisioning. Synchronize only roles with the status set to Production. The default value is No. Procedure To change the role status description: 1. From the Configuration tab, navigate to Role Status. The Role Status screen appears. 2. From the Description column, enter description text for the role status. 3. Click Update. Example You create 200 roles for a development system and 100 roles for a production system. When creating these roles on the Create Role screen, you set the role status to Development or Production for identification purposes. You can then easily search for the role status Development and retrieve the 200 roles. These roles are not automatically transferred to their respective systems but rather imported by using the Mass Role Import tool.

Managing Condition Groups


You can use condition groups to control the role methodology ERM assigns to a role during its initial definition. A condition group is defined from a set of role attributes (such as a business process, subprocess, functional area, role type, or role name) and is based on role values and conditions. If the role being defined meets the criteria in the condition group, the methodology associated with that group is used. This is done only when you first define the role, and not when you change the role. Any field name denoted with an asterisk (*) is required.

Creating a Condition Group


Procedure To create a condition group: 1. From the Configuration tab, navigate to Condition Groups. The Condition Groups screen appears. 2. Click Create. The Create Condition Group screen appears.

Page 307 of 397

Enterprise Role Management Role Creation Methodology Setup 3. In the Condition Group ID field, enter a condition group ID. 4. In the Description field, enter a brief description for the condition group. 5. From the Status dropdown list, select Enable or Disable. If you select Enable, the condition group is available for association during the role methodology creation process. If you select Disable, it is not available. 6. To add role attributes to the condition group, click Add. Dropdown lists appear under Role Attributes and Condition. 7. In the Role Attributes column, select the attribute that you want to assign to the condition group. After you select a role attribute, a dropdown list or text field appears in the Value column. The values in the dropdown list are specific to the selected role attribute. 8. In the Value column, assign a value for the corresponding attribute. 9. In the Condition column, select a condition for the role attribute. 10. To add more role attributes to the condition group, repeat steps 6 through 9. 11. Click Save.

Changing a Condition Group


Procedure To change a condition group: 1. On the Condition Groups screen, select the checkbox next to the condition group you want to change. 2. Click Change. The condition group appears with the Condition Group ID dimmed, indicating that you can only change the condition groups attributes, not its name. 3. Make any changes to the condition group. 4. Click Save.

Deleting a Condition Group


Procedure To delete a condition group: 1. On the Condition Groups screen, select the checkbox next to the condition group you want to change. 2. Click Delete. 3. Click OK to confirm the deletion. A condition group can be deleted only if it is not associated with a methodology process.

Role Creation Methodology Setup


A role creation process consists of predefined methodology actions and the methodology steps associated with those actions. The steps then create a methodology process, which guides you through the process of defining, generating, and testing a role during role creation. Enterprise Role

308

August 2010

Enterprise Role Management Role Creation Methodology Setup Management is delivered with the predefined role methodology process Virsa Default Process. You can also configure your own role creation process according to your organizations requirements.

Methodology Steps
Methodology steps are the steps to create a role during the role creation process. Based on these steps, you can tell which phase of the role creation process a role is in. Enterprise Role Management allows you to create methodology steps and associate them with predefined actions provided within Enterprise Role Management. After you associate the steps with the predefined actions, you can create a role methodology process. Any field name denoted with an asterisk (*) is required.

Creating a Methodology Step


Procedure To create a methodology step: 1. On the Configuration tab, navigate to Methodology > Step. The Steps screen displays the steps configured for your application. 2. Click Create. The Create Methodology Step screen appears. 3. In the Step ID field, enter a name for the step. 4. In the Description field, enter a brief description for the step. 5. From the Status dropdown list, select Enable or Disable. If you select Enable, the step is available for inclusion in a methodology process. If you select Disable, it is not available. 6. From the Associate Action dropdown list, select an action with which to associate the step. The actions you associate with your step are predefined in Enterprise Role Management. 7. Click Save.

Changing a Methodology Step


Procedure To change a methodology step: 1. On the Steps screen, select the checkbox next to the methodology step you want to change, 2. Click Change. The methodology step appears with the Step ID dimmed, indicating that you can only change the attributes of the step, not its name. 3. Make any changes to the methodology step. 4. Click Save.

Page 309 of 397

Enterprise Role Management Role Creation Methodology Setup

Deleting a Methodology Step


Procedure To delete a methodology step: If a methodology step is already associated with a methodology process, neither the step nor the process can be deleted. 1. On the Steps screen, select the checkbox next to the methodology step you want to delete. 2. Click Delete. 3. Click OK to confirm the deletion.

Methodology Actions
Enterprise Role Management is delivered with predefined actions. Although you cannot create new actions, you can create steps to associate with the predefined actions and then use those steps to create a methodology process. Activities Clicking each action name on the Predefined Actions screen allows you to see which button triggers the associated action. To view Enterprise Role Management predefined actions, select Methodology Actions on the Configuration tab. Enterprise Role Management Predefined Actions Action Approval of a Role Description This action is associated with sending the role for approval through approval workflow.

Generation of a Role This action is triggered when you want to generate the role in the back-end ERP system. Initiating Risk Analysis Saving Role Definition This action is triggered when you want to perform risk analysis on a role. The risk analysis is based on the default analysis settings specified during configuration. This action is associated with saving the definition of a role. This excludes saving authorization data and risk analysis results.

Saving Test Results This action is triggered when you want to maintain test results after testing a role. Saving Role Authorization Data Saving Role Derivation This action is triggered when you want to maintain the authorization data for the role. This action is triggered when you want to maintain the role derivation data.

310

August 2010

Enterprise Role Management Role Creation Methodology Setup

Methodology Process
A methodology process consists of multiple steps and defines the order and flow of the role creation process through all of the associated steps. Any field name denoted with an asterisk (*) is required.

Creating a Methodology Process


Procedure To create a methodology process: 1. On the Configuration tab, navigate to Methodology > Process. The Process screen displays all of the processes configured for your application. 2. Click Create. The Create Process screen appears. 3. In the Process ID field, enter a name for the methodology. 4. In the Description field, enter a brief description for the methodology. 5. From the Status dropdown list, select Enable or Disable. If you select Enable, the methodology is available for a role by matching the attributes of the role in question with the condition group(s) associated with this process. If you select Disable, it is not available. 6. On the Detailed Description tab, enter a detailed description of the methodology. 7. On the Steps tab, click Add. 8. From the dropdown list, select a step for this process. You can use the up and down arrows to change the position of a step in the process. 9. Repeat steps 7 through 8 to add more steps to the process. 10. On the Apply To tab, click Add. 11. From the dropdown list, select a condition group to apply to the process. 12. Repeat steps 10 through 11 to apply the process to more than one condition group. For more information, see the sections Managing Condition Groups and Changing a Condition Group. 13. Click Save. 14. (Optional) click Apply to existing Roles to update the role methodology process to existing roles. Note If more than one methodology process is configured in your system, select one process as the default. To set a default process, click the light bulb icon associated with the process you want to set as the default. All other processes are triggered based on condition group. For more information, see Limitations to Apply to Existing Roles.

Page 311 of 397

Enterprise Role Management Role Creation Methodology Setup

Changing a Methodology Process


Procedure To change a methodology process, do the following: 1. Select the checkbox next to the methodology process you want to change. 2. Click Change. The methodology process appears with the Process ID dimmed, indicating that you can only change the process attributes, not its name. 3. Make any changes. 4. Click Save. 5. (Optional) click Apply to existing Roles to update the role methodology process to existing roles. For more information, see Limitations to Apply to Existing Roles .

Applying Role Methodology Updates to Existing Roles


The Apply to Existing Roles feature enables you to update the role methodology for existing roles. The function has the following conditions: Roles in the approval stage are not updated. The approval must be complete before the roles are updated. Roles in the edit mode are not updated, that is, the internal status of the role is locked. If the role contains derived roles, and the new methodology removes the Derivation step from the methodology. You must first remove all the derived roles and come back the process steps screen to update the roles. If a new stage is added and the roles have moved past that step, the roles are not reset to this new stage. The following example illustrates that an approval stage has been added to the methodology. Roles that are in the generation step continue in the generation stage (they are not rerouted back to the new approval step). Previous method: Definition -> Authorization -> Derivation -> Generation New method: Definition -> Authorization -> Derivation -> Approval -> Generation Note In the example above, the role has an approval stage, however, there may not be any approvers defined nor would the role have gone through an approval process. This may have an impact on the compliance audit of the role, as the process stage indicates that there is an approval stage but no approval has been done.

If you select derived roles that use a different methodology than the master role, only roles with the same methodology are updated. If you miss a role, you can update the role methodology separately. Recommendation Select all the roles that need to be updated together.

312

August 2010

Enterprise Role Management Managing the Workflow

Deleting a Methodology Process


Procedure A methodology process cannot be deleted if it is set as the default process, if it is being used for role creation, or if it is the only process configured in Enterprise Role Management. 1. Select the checkbox next to the methodology process you want to delete, 2. Click Delete. 3. Click OK to confirm the deletion.

Managing the Workflow


Enterprise Role Management integrates with Compliant User Provisioning for role approval workflow. As part of the integration, a role approver is defined during the role creation process to be used by the approval workflow. During the role creation process, you can manually define approvers and alternate approvers for each role, or you can allow Enterprise Role Management to automatically assign approvers and alternate approvers to that role based on the approval criteria you create and the role attributes the user selects. To create approval criteria, you assign approvers and alternate approvers for a set of role attributes or conditions. Any field name denoted with an asterisk (*) is required. Prerequisites You must have Compliant User Provisioning installed and configured in order to use the workflow function. For more information, see the section Compliant User Provisioning.

Creating Approval Criteria for a Workflow


Procedure To create approval criteria for approval workflow: 1. On the Configuration tab, navigate to Workflow > Approval Criteria. The Search Approval Criteria screen appears. 2. Click Create. The Create Approval Criteria screen appears. 3. In the Group Name field, enter the name of the group for which you want to create approval criteria. 4. Click Add on the Attribute screen. The Attribute screen appears. 5. From the dropdown list, select the attribute(s) required to specify your approval. 6. Click Assign Approvers. The Approval Criteria Values screen appears. 7. Click Assign Approvers.

Page 313 of 397

Enterprise Role Management Managing the Workflow The Change Approval Criteria screen appears. 8. Under the Condition table, click Add. a. In the Attribute column, select an attribute from the dropdown list. In the Value column, select a value from the dropdown list. Click Add. Repeat steps a through c to add additional attributes and values. To remove an attribute line record, click the 9. Under the Approver table, click Add. 10. In the Approver column, click Search. The Approver Search window appears. Alternatively, you can enter First Name and/or Last Name of approver to specifically search for an approver. 11. Click Search. A list of potential approvers appears. 12. Select the radio button next to the user ID of the user you want to assign as an approver. 13. Click Select. The Approver Search window closes, and the Approver field on the Change Approval Criteria screen is populated. 14. Repeat steps 10 through 13 to select an alternate approver. 15. Click Add. 16. Repeat steps 10 through 14 to add more approvers and alternate approvers. To remove an approver and alternate approver line record, click the 17. Click Save. The Approval Criteria Values screen displays the Approver and Alternate Approver for the selected condition attributes. icon. icon.

Changing Approval Criteria for a Workflow


Procedure To change approval criteria: 1. On the Search Approval Criteria screen, select the checkbox next to the group for which you want to change approval criteria. 2. Click Change. The Approval Criteria Values screen for the group you selected appears. 3. You can add new approval criteria or change existing approval criteria to the group. To add new approval criteria, click Assign Approvers and then follow steps 7 and 8 in the section Creating Approval Criteria for a Workflow. To change existing approval criteria, select the checkbox next to the Approval Expression you want to change. Then click Change to make the changes.

314

August 2010

Enterprise Role Management Managing Naming Conventions 4. Click Save.

Deleting Approval Criteria for a Workflow


Procedure To delete all approval criteria for a group: 1. On the Search Approval Criteria screen, select the checkbox next to the group whose approval criteria you want to delete. 2. Click Delete. 3. Click OK to confirm the deletion. 4. To delete specific approval criteria for a group: 5. Select the checkbox next to the group whose approval criteria you want to delete. 6. Click Change. 7. Select the checkbox next to the Approval Expression you want to delete. 8. Click Delete. 9. Click OK to confirm the deletion.

Managing Naming Conventions


You create naming conventions to enforce role and profile naming standards during the role creation process. Naming conventions are specific to a system landscape and role type. The landscape and role type determine the attributes available to assign to a naming convention. Any field name denoted with an asterisk (*) is required. Example You can have different naming conventions for the Single role type in the development system landscape and the test system landscape. You can have different naming conventions for the Composite role type in the development system landscape and the test system landscape, and so on.

Creating a Naming Convention


You create a naming convention by entering free text or text dynamically linked to your role attributes. The role attributes available for naming convention creation for all role types are Business Process, Subprocess, and Project/Release. For SAP derived roles, additional role attributes are available: Master Role Name, Derived Org Level, From Value, To Value. Procedure To create a naming convention: 1. On the Configuration tab, navigate to Naming Convention. The Configure Naming Conventions screen appears. 2. Click Create. The Create Naming Convention screen appears. 3. In the Name field, enter a name for the new naming convention.

Page 315 of 397

Enterprise Role Management Managing Naming Conventions 4. From the System Landscape dropdown list, select a system landscape. 5. From the Role Type dropdown list, select a role type. The role type you select determines the attributes available to you in the next step. Available role types are: Single Composite Derived Profile

6. From the Enforced field dropdown list, select Disable or Enabled. Enabled - the naming convention is enforced and cannot be overridden by the user. Disable - the naming convention is suggested, but can be overridden by the user.

The Expression field contains the format of the naming convention. It is auto-populated each time you assign an attribute and/or text character, but you decide the order and number of characters. The maximum number of characters allowed for a role name is 30 (with the exception of the profile name role type Profile which only allows 12 characters). Each time you add characters, the position of the assigned characters and number of characters still available is displayed on the right side of the Create Naming Convention screen. Two types of character appear in the Expression field: Variable characters represent the attribute value you select from the Attribute dropdown list and are represented in the Expression field as a dollar sign ($). When you create a user role, the Variable character is either auto-populated or changed, depending on your business needs. Free Text characters allow you to enter whatever text best fulfills your business needs, but it is typically based on valid characters for SAP role names. Free text is represented in the Expression field by either a dollar sign ($) or the actual text you enter in the Text field.

7. Populate the Expression field: a. Select an attribute from the Attribute dropdown list. Take one of the following actions: Enter the number of characters needed to represent the selected attribute in the No. of Chars field, and click the Add icon. Enter text in the Text field, and click Add.

The characters that represent the variable or free text you enter appear in the Expression field, and the positions the characters hold in the expression appear in the screen on the right. In addition, you can see the number of characters that remain available for the naming convention. 8. Click Save.

Changing a Naming Convention


Procedure To change a naming convention: 1. Select the checkbox to the left of the naming convention you want to modify. 2. Click Change. The Edit Naming Convention screen appears.

316

August 2010

Enterprise Role Management Managing Organizational Value Mapping 3. Make the changes on the screen. 4. Click Save.

Deleting a Naming Convention


Procedure To delete a naming convention: 1. Select the checkbox to the left of the naming convention you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion.

Managing Organizational Value Mapping


If you want to restrict user access by organizational area, you can use the organizational value mapping feature to map roles to different organizational levels. To define all associated organizational values, you can create an organizational value map for each organizational area (such as North America, Europe, and Asia Pacific). Prior to creating an organizational value map, you must run a background job to import existing organizational fields and values from your SAP ERP system. After the initial import, you can create a background job to schedule periodic synchronization to keep the data updated. For more information about background jobs, see the section Managing Background Jobs. You always create an organizational value map with a primary organizational level and value, because Enterprise Role Management uses that to store and search for the organizational value. You can create multiple maps for the same primary organizational level and value combination. After the primary organizational level and value are set, you can define the values for all child organizational levels within the map to complete the organizational value map creation. After you create the organizational value map, it can be used by all users as a basis to derive any master role. You must run the initial background jobs for Org Value Sync, Transaction/Object/Field Sync, and Activity Val Sync prior to configuring organizational value maps. These background jobs are a prerequisite for the organizational value mapping feature. Any field name denoted with an asterisk (*) is required. Example Create an organizational value map for North America with the primary organizational level as Company Code with value 1000 through 2000. Within Company Code 1000 through 2000, the child organizational levels, such as a plant or division, are set with the value of 100 through 200 (the location of the plant or division). When you derive a role using this North America map, the derived role assumes the primary organizational level values and all child organizational levels values 100 through 200.

Creating an Organizational Value Mapping


Procedure To create an organizational value map: 1. On the Configuration tab, navigate to Org. Value Mapping. The Search Org. Value Mapping screen appears.

Page 317 of 397

Enterprise Role Management Managing Organizational Value Mapping 2. Click Create. The Create Org. Value Mapping screen appears. 3. In the Mapping Name field, enter the organizational value map name. 4. From the Derived Org. Level dropdown list, select an organizational level. 5. Click Search to the right of the Org. Value From field. The Value Search window appears. 6. Click Search. A list of values and their descriptions appears. 7. Select the button next to the value you want and click Select. The Value Search window closes, and the Org. Value From field is populated. 8. Click Search to the right of the Org. Value To field. The Value Search window appears. 9. Click Search. A list of values and their descriptions appears. 10. Select the button next to the value you want to use and click Select. The Value Search window closes, and the Org. Value To field is populated. 11. In the Description field, enter a description of the organizational value map. 12. Select the organizational level on which to base this new organizational value map by clicking Add on the Mapped Org. Levels screen. 13. In the Field column, select an organizational level from the dropdown list. 14. Select From and To values by clicking Search and then repeating steps 8 and 9. 15. Repeat steps 12 and 13 to add additional organizational level and values to the org value map. 16. Click Save. 17. To view all existing roles affected by this mapping, click Master Role Impact or Derived Role Impact.

Changing an Organizational Value Mapping


Procedure To change an organizational value mapping: 1. On the Search Org. Value Mapping screen, select the checkbox next to the Mapping Name you want to change. 2. Click Change. The Change Org. Value Mapping screen appears. 3. Make the desired changes. 4. Click Save. 5. To view and update the roles affected by this change, click Impacted Master Roles or Impacted Derived Roles.

318

August 2010

Enterprise Role Management Managing Organizational Value Mapping

Deleting an Organizational Value Mapping


Procedure To delete an organizational value mapping: 1. On the Search Org. Value Mapping screen, select the box next to the Mapping Name you want to delete. 2. Click Delete. 3. Click OK to confirm the deletion.

Importing an Organizational Value Mapping


Procedure You can manually maintain the organizational value map within Enterprise Role Management, or you can mass import your data using the import feature. To import organizational value mapping(s): 1. On the Search Org. Value Mapping screen, click Import. A standard Windows Choose File dialog box appears. You can click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Locate the file you want to import. 3. Click Open to import the file. If the information was imported successfully, a success message appears.

Exporting an Organizational Value Mapping


After you create organizational value maps, you can export them to a directory on your computer in spreadsheet format (.xls). This feature uses the spreadsheet for reporting purposes, as well as for making changes to the information in the spreadsheet and then importing the file back into Enterprise Role Management. Enterprise Role Management also provides you with a template for importing and exporting organizational value maps. After you download the template into a directory, you can add your organizational value maps and then import those maps into Enterprise Role Management. You can use your own spreadsheet to import organizational value maps as long as you use the same column and header formatting as used in the Enterprise Role Management template. SAP recommends that you use the template provided with Enterprise Role Management for importing organizational value maps. Do not modify the column format or header names because those names affect how the template interacts with Enterprise Role Management. Procedure To export organizational value mapping(s): 1. On the Configuration tab, navigate to Org. Value Mapping. The Search Org. Value Mapping screen appears. 2. Click Export.

Page 319 of 397

Enterprise Role Management System Logs 3. Click Open to view the spreadsheet or Save to save the spreadsheet to a directory on your computer. 4. After you make any changes to the information in the spreadsheet, use the Import function to import the changes back into Enterprise Role Management. For more information about importing organizational value maps, see the section Importing Organizational Value Map.

System Logs
System logs provide a history of role management actions and are used by administrators and developers for troubleshooting purposes. Activities You can view system logs by navigating to the System Logs screen and selecting Get Logs.

Transaction Import
The transaction import feature of Enterprise Role Management imports non-SAP transactions (actions) into Enterprise Role Management to be used as authorization data during the role creation process. If you choose not to import the non-SAP actions, you must manually enter authorization data when documenting non-SAP roles. Procedure 1. On the Configuration tab, navigate to Transaction Import. The Transaction Import: Non-SAP ABAP screen appears. You can click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. From the System Type field, select the appropriate system from the dropdown list. 4. Click Import. If the information was imported successfully, a Transactions imported successfully message appears.

Importing Mass Roles


For SAP systems, the mass role import feature of Enterprise Role Management synchronizes the SAP back-end systems with Enterprise Role Management by importing roles that already exist in the SAP ERP system. For non-SAP systems, the mass role import feature of Enterprise Role Management imports your roles and transactions/actions data from a spreadsheet based on the provided template format. Prerequisites Before you can use the mass role import functionality of Enterprise Role Management, you must: Ensure that connectors, a system landscape, and role attributes are configured within Enterprise Role Management. Ensure that role attribute master data on your import file matches the data in Enterprise Role Management.

320

August 2010

Enterprise Role Management Transaction Import For SAP systems only, you must: Ensure that all background jobs, including Transaction/Object/Field Value, Org Value, and Activity Value synchronizations, are complete. Download a Bulk Download text file by executing the /VIRSA/RE_DNLDROLES transaction on that system. Run the /VIRSA/RE_DNLDROLES transaction as a background process. When executing the /VIRSA/RE_DNLDROLES transaction, save the Bulk Download file as a text file with .txt file extension to either your local computer or to the server on which Enterprise Role Management is installed. Specify a file name that is easily remembered. You can download single, composite, and derived roles in the same download file. Create a role and attribute information file for the downloaded roles in Enterprise Role Management. This file contains required role attribute information specific to Enterprise Role Management. This information does not exist in the back-end SAP system. The information file must be in tab-delimited text format and contain the following role attributes with the corresponding role names: Business Process Sub-Process Project/Release.

o o o

Enterprise Role Management provides a template for creating the information file. You can access the template by using the Mass Role Import screen on the Configuration tab. In the System Type field, select SAP from the dropdown menu. The Enterprise Role Management Information File field appears. Click the red download arrow to download the template. Here is an example of the information in tab-delimited text format: Z_AP_PAYABLE Z_AP_CLERK FINANCE FINANCE ACCOUNTS_PAYABLE ACCOUNTS_RECEIVABLE ALPHA_RELEASE BETA_RELEASE

You must use attribute IDs, rather than their descriptions, when populating the template. You can also download template files from Help on the main Enterprise Role Management application screen. For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3. If you import a derived role, its master role must exist in the same import file with the derived roles or it must already exist in Enterprise Role Management. You must also create a Primary Org Level file. Enterprise Role Management provides a template for this purpose. Access the template by clicking the red download arrow next to the Browse icon from the Mass Role Import screen.

Importing Multiple Roles


Procedure To import multiple roles:

Page 321 of 397

Enterprise Role Management Transaction Import

Any field name denoted with an asterisk (*) is required. 1. On the Configuration tab, navigate to Mass Role Import. The Mass Role Import screen appears. 2. From the Source Connectors dropdown list, select the connector to which you want to import the roles. 3. From the System Type dropdown list, select the system type to which you want to import the roles. 4. From the System Landscape dropdown list, select the system landscape to which you want to import the roles. 5. From the Import Source dropdown list, select the source from which to import the roles. The selection you make here depends on where you saved the import files. For SAP systems, select the location file source where you saved the Bulk Download text file you downloaded using the /VIRSA/RE_DNLDROLES transaction. If you saved the file to your local system, select Browser Upload. If you saved the file to the server, select Server Files.

For more information about the /VIRSA/RE_DNLDROLES transaction, see the section Mass Role Import. 6. In the Bulk Download File field, either enter the server file path or click Browse to locate the files on your hard drive. For non-SAP systems, Enterprise Role Management provides a template for this purpose. Access the template by clicking the red download arrow next to the Browse icon. For SAP systems, this is the file you downloaded when you ran the /VIRSA/RE_DNLDROLES transaction. For more information about the Bulk Download file, see the section Mass Role Import. 7. (SAP systems only.) In the Enterprise Role Management Information File field, either enter the server file path or click Browse to locate the files on your hard drive. For more information about the Enterprise Role Management Information file, see the section Mass Role Import. 8. In the Primary Org Level File field, either enter the server file path or click Browse to locate the files on your hard drive. For more information about the Primary Org Level file, see the section Mass Role Import. 9. From the Overwrite Role if Exists dropdown list, select Yes to overwrite existing roles or No to prevent the roles from being overwritten. 10. Click Continue. 11. Select Foreground or Background. If you select Foreground, the Import Results screen displays the role name and import status. If you select Background, the system automatically schedules a background job and displays the message Background job for mass role import is successfully scheduled; job ID is ###. For more information, see the section Viewing the History of a Background Job.

322

August 2010

Enterprise Role Management Transaction Import

Role Usage Synchronization


Role usage information is stored in ERM and used in CUP to provide role usage information for User Access Review. You can update the information by either synchronizing ERM with the SAP ERP system or by uploading the information using the upload file template. For detailed information on format usage, see the section Role Usage Import Template. Note To ensure proper synchronization, you must match the role usage parameters between CUP and ERM. Procedure To perform role usage synchronization from a system: 1. On the Configuration tab, navigate to Role Usage Synchronization. The Role Usage Synchronization screen appears. 2. Select the system from which you want to synchronize the role usage. Note The systems configured in Enterprise Role Management are SAP systems. For non-SAP systems, use the manual upload feature described below. 3. Choose the Synchronization Start Date. Note For the initial run, the application uses todays date. The default behavior is to get data starting from the previous synchronization and to append the data. For example, if the previous synchronization is January 2009, the application synchronizes data from January 2009 to the current date. If you want to overwrite previously synched data, schedule the job for an earlier date. For example, the previous synchronization is January 15, 2009. To overwrite the synchronized data, schedule a new job to run January 14 or earlier.

4. Click Schedule.

To perform a manual upload: 1. On the Configuration tab, navigate to Role Usage Synchronization. 2. From the Upload Role Usage section, select the system type of the source system where the role usage information is being uploaded.

Page 323 of 397

Enterprise Role Management Approving Roles During Mass Maintenance

The Upload Role Usage feature is primarily used for uploading the role usage synchronization data from a non-SAP system to Enterprise Role Management. 3. In the File Name field, click Browse to locate the file you want to import. You can click the red arrow next to the Browse button to download the Role Usage Import Template that contains the format for the import file. 4. Click Upload.

Role Usage Import Template


Field Name System (Name) User (ID) First Name Last Name Role (Name) Execution Count Last Executed Expired Definition Alphanumeric (20) Alphanumeric (40) Alphanumeric (50) Alphanumeric (50) Alphanumeric (100) Numeric Date (MM/DD/YYYY) Numeric (1= expired, otherwise leave blank. Blank= not expired.) Example QF6 Tchard1 Tom Chard Z_AP_Payable Number of times that the role was used. 08/27/2008 Any value other than 1 indicates that the role is not expired.

Enterprise Role Management compiles role usage data from SAP systems into the format used by the role usage import template. You use the same format for compiling role usage data from a non-SAP system and later upload to Enterprise Role Management.

Approving Roles During Mass Maintenance


The configuration parameter Enable role methodology for mass role update allows you to send mass role updates through the role methodology and approval phases. To enable role methodology and approval for mass role updates: 1. On the Configuration tab, navigate to Miscellaneous. 2. Scroll to Enable role methodology for mass role update, and choose Yes. Setting the parameter to Yes, enables all of the updated roles to go through the role methodology. When the roles are updated, they are set to the first step of the role methodology. The default value for this parameter is No. If Enable role methodology for mass role update is set to No during a mass update, a popup message appears you to choose whether to send updated roles through the approval phase again by resetting the methodology to the first step.

Importing and Exporting Configuration Settings


This feature exports configuration settings from one Enterprise Role Management system and imports them into another. You must export the settings first and then use the generated file as the import source file for the other system. For example, after you configure the development system, you can export the configuration settings and import them into the production system, so you do not have to manually reconfigure the settings.

324

August 2010

Enterprise Role Management Importing and Exporting Configuration Settings

Exporting Configuration Settings


Procedure 1. On the Configuration tab of the configured system, navigate to Configuration Settings. The Import/Export Configuration screen appears. 2. In the Export Settings section, select the checkbox next to the attribute grouping to select a group of attributes, or select the checkbox in the top left corner of the section to select all attributes. 3. Click Export. 4. The system prompts you to Open or Save the file. Click Open to view the export file prior to saving it. Click Save to save the export file by specifying file name and file location. Remember where you save the file, so you can use it as an import file later. SAP does not recommend that you manually modify this file.

Importing Configuration Settings


Procedure 1. On the Configuration tab of the system you have not yet configured, navigate to Configuration Settings. The Import/Export Configuration screen appears. 2. In the Import Settings section, click Browse to locate the export file you exported. 3. Click Import.

Page 325 of 397

Enterprise Role Management Miscellaneous

Miscellaneous
This section describes the configuration options available on the Miscellaneous tab.

Option Conduct Risk Analysis Before Role Generation

Description Choose whether risk analysis is required before role generation. If you set this configuration to No, roles can be generated without risk analysis. Configure whether the role can be generated despite violations. If you set this option to No, you cannot generate the role unless all role violations are resolved. Configure whether the role can be generated on multiple systems. Configure whether the logged-in user credentials are used during role generation. If you set this option to No, the system uses the target back-end system user ID and password. Specify a default risk analysis level. Set this option to Object to set the risk analysis defaults to the Object or Permission level. Set this option to Transaction to set the risk analysis defaults to the Transaction Code or Action level. You can override the default setting at the time you perform risk analysis.

Allow Role Generation With Violations

Allow Role Generation on Multiple Systems Use Logged On User Credentials for Role Generation

Analysis Type

Web Service Info. for CC Risk Analysis Web Service Info. for CC Transaction Usage Web Service Info. for CC Mitigation Control Web Service Info. for CC Functions Web Service Info. for AE Workflow Allow Editing Org. Level Values For Derived Roles

Set the Web service URL for risk analysis. Set the Web service URL for transaction usage. Set Web service URL for Mitigation Control. Set the Web service URL for Functions. Set the Web service URL for the role approval workflow. Edit organizational level values for derived roles. If you set this option to No, you cannot edit organizational level values for derived roles during the authorization data step in the role creation process. If you set this option to Yes, it adds authorization data by retrieving a function from Risk Analysis and Remediation.

Allows You to Add a Function to Authorizations

326

August 2010

Enterprise Role Management Miscellaneous

Option Add Objects To a Role

Description Add objects to a role directly during the authorization data step of the role creation process. If you set this option to Yes, the system allows you to add objects directly to the role authorization data. If you set this option to No, you can add objects to a role only by adding functions and/or transactions. Specify whether you must enter a ticket number after making any additions or changes to the authorization data in a role. If you set this option to Yes, after you save any additions or changes made to the authorization data in a role, the system prompts you for a ticket number. If you set this option to No, the system does not prompt you for a ticket number. Configure whether the role can be opened and edited in PFCG. If you set this option to No, you cannot create or edit the role through PFCG integration. Set a default folder for all the files uploaded from Enterprise Role Management. Allows you to configure the log level. Set the default language. Limits the number of background jobs that can be run concurrently. Enables attaching files to a role, and allows you to limit the attachment file size (in KBs). This option allows you to delete the selected roles from both the front end and back end of SAP systems. Indicate the types of users that are included in Role Usage Synchronization and, therefore, in User Access Review requests. Identify the lock codes that are excluded from Role Usage Synchronization and, therefore, from User Access Review requests. For example, indicate whether accounts locked from incorrect log on attempts should be excluded. Locked by Administrator: Centrally or Locally (Lock Code 32 or 64) Locked Due to Incorrect Logons (Lock Code 128)

Ticket Number After Authorization Data Changes

Allow Editing Role Authorizations in PFCG

Upload Directory Log Level Default Language Number of Concurrent Background Jobs Allows You to Attach Files to Role Definition Allow Role Deletion from Backend

Include User Type in Role Usage Synchronization Exclude Locked Users with Lock Codes for Role Usage Synchronization

Page 327 of 397

Enterprise Role Management Mass Role Import

Option Exclude Expired Users for Role Usage Synchronization

Description Indicate whether expired users are excluded during the Role Usage Synchronization job and, therefore, from User Access Review requests.

Procedure 1. On the Configuration tab, navigate to Miscellaneous. 2. From the dropdown list next to each option, select the options. 3. Click Save. 4. (For the Role Usage Synchronization options only) Schedule the role usage synchronization job. a. Navigate to the Configuration tab. In the left navigation pane, select Role Usage Synchronization. b. Select a job, choose a start date, and click Schedule. For more information, see Enterprise Role Management > Role Usage Synchronization.

Mass Role Import


You use the Mass Role Import feature to import the roles from the back-end system into the ERM repository. 1. Execute the VIRSA/RE_DNLDROLES program. The following files are downloaded in Excel format: Authorization Data Role information Primary Org Level 2. In ERM, select the Configuration tab. In the left navigation pane, select Mass Role Import. The Mass Role Import screen appears. 3. Select and choose the following parameters: Source connectors System type System landscape Import source Bulk download file Click Browse and select the Excel data files created above. Overwrite role if exists 4. Click Continue to import the roles and data. The Role Info file has the following attributes: Role Name Critical level Role owner Multiple Role owners can exist to a particular role. This is the role approver in ERM for maintaining roles Role approver Multiple Role approvers can exist to a particular role. This is Role approver in CUP for provisioning. Business Process Sub Process

328

August 2010

Enterprise Role Management Role Usage Synchronization Functional Area Multiple functional area can exists to a particular role. Transactions Multiple Transactions can exist to a particular role. Custom attributes Multiple Custom attributes can exists to a particular role. Role Status Overwrite role Yes or No This will override the flag setting in the user interface.

The template for the Primary Org Level has the following attributes: Role Name Derived Org Level From Value To Value

Note Import of Roles for 4.0 version are not supported.

Role Usage Synchronization


You use the Role Usage Synchronization feature to schedule role usage synchronization background jobs. This provides role usage information and the user-to-role relationship for the user access review. The usage of each role is calculated from the action usage data of the Alert Generation job in RAR and the actions defined in each role. For each back-end system to be included in the UAR review, the role assignment information must be either obtained from the back-end system using a real-time agent or uploaded manually. Either approach requires definition of a system (connector) in ERM. You define ERM connectors in Configuration > System Landscape > Systems. To schedule the background job: 1. Navigate to the Configuration tab. In the left navigation pane, select Role Usage Synchronization. 2. Select a job, choose a start date, and click Schedule. To manually upload the role usage data: 1. In the Upload Role Usage section, choose the System Type. 2. Click Browse to search for and select a data file. 3. Click Upload.

Language Configuration for Enterprise Role Management


When you initially log on to Enterprise Role Management, three fields are displayed on the Welcome screen: User ID, Password, and Language. Although User ID and Password are required fields, Language is not. Therefore, you must set a default language in the Miscellaneous Configuration screen by selecting the appropriate language from the Language dropdown list and then clicking Save.

Page 329 of 397

Enterprise Role Management Role Usage Synchronization

You must log off and then log back on again in order for this change to take effect in the user interface. In addition, if an end user selects a language from the Language dropdown list on the Welcome screen that differs from the default language specified in Miscellaneous Configuration, the default language is overridden and the user interface appears in the end user-selected language. When the end user logs in using a language from the Language dropdown list on the Welcome screen that differs from the default language specified in Miscellaneous Configuration, they can use the Create option to create a new object. By default, Enterprise Role Management shows the default language description and allows the end user to create and modify the object with the corresponding language text.

330

August 2010

Custom Reports (Data Mart) Role Usage Synchronization

7. Custom Reports (Data Mart)


You can use the Data Mart functionality to extract data from RAR and CUP, and load it to any reporting tool, such as Crystal Reports. This enables you to display RAR and CUP data in custom reports. Prerequisites You have installed Access Control 5.3 SP11. You have installed the RAR capability. You have installed the Common Launchpad component.

Procedure 1. Enable the data mart job: a. Log into RAR as an administrator. b. Go to Configuration tab -> Additional Options. c. Select Enable Data Mart Job and choose Yes.

d. Save. 2. Schedule the data mart job: a. On the Configuration tab, navigate to Background Job > Data Mart Job. The Schedule Data Mart Job screen appears. b. In the Data Mart Extraction section, choose the data type. Master Data The Data Mart Job always performs a full synchronization of master data. Transactional Data You can choose to perform a full or incremental synchronization of transactional data. We recommend performing a full synchronization before performing any incremental synchronizations. Only the following tables are delta-enabled and everything else is always full-sync: o GRC_DM_CC_SOD_ACT o GRC_DM_CC_SOD_PRM CUP Choose this to include CUP data in the extraction. c. Click Schedule. The Schedule Data Mart Synch Batch Background Job screen appears.

d. Enter the required information. e. (optional) To perform the job multiple times, select Schedule Periodically, and indicate the frequency as well as the End Date past which no jobs will execute. f. Click Schedule to accept your input or Reset to begin again. After the background job runs, the data is transported to the Report Mart. For more information about Report Mart, see SAP Note: 1369045 AC SP09 Data Mart Design Description. 3. Follow the procedure for your reporting engine to load the data and display the custom reports.

Page 331 of 397

Role Usage Synchronization

Aborted and Errored-out Data Mart Synchronization Jobs


To rerun any aborted or errored-out data mart synchronization jobs from RAR, rerun Data mart ETL in full-

sync mode.

332

August 2010

Access Control and Identity Manager Integration Role Usage Synchronization

8. Access Control and Identity Manager Integration


Access Control can integrate with IdM systems. For example, you can define policies and Segregation of Duties (SoD) rules for granting access to resources through Access Control. The integration between GRC Access Control and the IdM system ensures that user provisioning does not introduce unknown risk violations. Integration involves exposing Web services in both Access Control and the IdM system. You can call these Web services from either system to request user provisioning. This extends the IdM system by enabling Compliant User Provisioning. The Web service solution provides proactive enforcement of access policies, especially those that prevent SoD and risk violations. These Web services can alert you to potential SoD conflicts when assigning roles to users. The Web services offered by Access Control comply with Service Provisioning Markup Language (SPML) 1.0. Access Control can call Web services offered by IdM system if they comply to SPML 1.0. Access Control supports the following integration approaches: Using the IdM system as the leading provisioning system where requests are submitted to Access Control for SoD compliance and provisioning to one or more ERP systems. For more information, see the section IdM System as a Leading Provisioning System. Using Access Control as the leading provisioning system where requests are submitted to the IdM system for provisioning to one or more non-ERP systems. For more information, see the section GRC Access Control provisioning to non-ERP Systems. Using Access Control as the leading provisioning system where requests are submitted to other supported systems via SPLM SOAP provisioning requests. For more information, see the section GRC Access Control provisioning to Other Supported Systems.

Page 333 of 397

Access Control and Identity Manager Integration Calling Web Services

Calling Web Services


There are several business reasons for calling the Web services provided by GRC Access Control. Here are three examples: IdM system as a leading provisioning system Access Control as a leading provisioning system Access Control provisioning to other support systems via SPML SOAP

IdM System as a Leading Provisioning System


From the IdM system, you want to request access to an ERP system using the Submit Request Web service. This request is submitted to Access Control. Once the request is approved and provisioned, a status is sent back to the IdM system. You can also call the Submit Request Web service from Access Control to request a non-ERP system on the IdM system. Again, once the status is completed, a notification is sent to Access Control. To request the system and role, you must know what systems and roles are available. From the IdM system, you can perform specific actions, such as calling the Application Selection and Role Selection Web services, before calling the Request Submission Web service in Access Control. The figure 1 illustrates this interaction: Figure -1

334

August 2010

Access Control and Identity Manager Integration Calling Web Services

Access Control as a Leading Provisioning System


A request is triggered in Access Control by one of two events: An event, such as a hire or a position change, occurs in SAP Human Resources (SAP HR) A self-service creation process within Access Control.

In either case, if the request involves accessing an ERP system and a non-ERP system, then the request follows two parallel paths. The non-ERP system portion of the request is submitted to the IdM system. The ERP system portion is processed by Access Control.

Figure -2 illustrates this interaction Figure-2

For configuration steps applicable to this example, see the section Integrating with an Identity Management Solution.

Page 335 of 397

Access Control and Identity Manager Integration Calling Web Services

Access Control provisioning to Other Supported Systems via SPML SOAP


Access Control can provision to other target systems that are SPML SOAP compliant. Like the previous example, when an event occurs in SAP Human Resources (SAP HR), it triggers a request in Access Control. A request can also be triggered by a self-service creation process within Access Control. When the provisioning request is approved in Access Control, an SPML SOAP call is submitted to the target system for provisioning. The following diagram illustrates this interaction.

For configuration steps applicable to this example, see the section Provisioning to Other Target Systems with SPML SOAP Compliant Call.

336

August 2010

Access Control and Identity Manager Integration Access Control and IdM System Integration Architecture

Access Control and IdM System Integration Architecture


The integration of Access Control and the IdM system is coupled by the ability to call Web services. Figure -3 illustrates the logic when calling the Web services from Access Control or the IdM system. Figure -3

Access Control IdM Web Services are generally unidirectional, but some are bidirectional. You can call them either from IdM or from Access Control.

Page 337 of 397

Access Control and Identity Manager Integration Access Control and IdM System Integration Architecture

Available Web Services


The IdM system can call the following Web services on the Access Control system: Name Select Applications Search Roles Technical Name SAPGRC_AC_IDM_SELECTAPPLICATION SAPGRC_AC_IDM_SEARCHROLES Description This Web service returns a list of resources that are configured in Access Control This Web service enables you to search for roles before submitting a request to Access Control. To refine your search, you can use a filtration function. This Web service provides detailed information about the selected role. This Web service is an incremented version of the SAPGRC_AC_IDM_ROLEDETAILS Web service. In addition to providing the SAPGRC_AC_IDM_ROLEDETAILS information, it includes the custom attributes. You can use either Web service. V1_1 does not over write the SAPGRC_AC_IDM_ROLEDETAILS Web service. This Web service provides detailed information about the following: Request status Roles Application Priority Risks Mitigated risks. Current Stage Information (Approval status, Approver name) Next Stage Information (Stage name)

Role Details Role Details version 1.1

SAPGRC_AC_IDM_ROLEDETAILS) SAPGRC_AC_IDM_ROLEDETAILS_V1_1

Request Details

SAPGRC_AC_IDM_REQUESTDETAILS

338

August 2010

Access Control and Identity Manager Integration Access Control and IdM System Integration Architecture

Name

Technical Name

Description Risk Analysis (Risks Identified and Mitigated) Request Information (Request ID, Priority, Application, Roles)

Submit Request (to Access Control) Risk Analysis Audit Trail (includes the Provisioning Log Web service)

SAPGRC_AC_IDM_SUBMITREQUEST SAPGRC_AC_IDM_RISKANALYSIS SAPGRC_AC_IDM_AUDITTRAIL

You use this Web service from the IdM system for compliant provisioning to Access Control. This Web service enables you to perform Segregation of Duties (SoD) analysis. It returns any possible risk violations. This Web service returns a comprehensive audit history. It allows the IdM system to retrieve an audit log from Access Control (for ERP provisioning) as well as provides an audit history of user provisioning to Access Control. This Web service returns the status and detailed request information for the selected request.

Request Status

SAPGRC_AC_IDM_REQUESTSTATUS

Page 339 of 397

Access Control and Identity Manager Integration Access Control and IdM System Integration Architecture

Access Control Web Services calls to IdM


Name Submit Request to IdM Technical Name SAPGRC_AC_IDM_SUBMITREQUEST_TO_IDM Description This Web service is called by GRC to submit a request to IdM. The Web services are called in the following situations: When a user requests non-ERP system from the GRC End User Form, GRC calls this service to submit a request to the IdM. When a user is created or changed in an SAP HR system, a new request is submitted to IdM to create or remove users and their privileges.

Example: An event occurs in SAP HR, such as the hiring of a new employee. This event initiates a request to enable the user have some basic privileges to perform their job function. The request might consist of both ERP and Non-ERP applications, thereby triggering a request to the IdM system for non-ERP system while GRC processes the request for the ERP systems. The audit logs and request status can be consolidated by calling the Audit Logs and Request Status web services. Audit Trail from IDM SAPGRC_AC_IDM_AUDITTRAIL_FROM_IDM This Web service returns a comprehensive detailed list of audit history. It enables GRC to retrieve the audit logs from IdM (for non-ERP provisioning).

340

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Technical Definitions for Access Control IdM Web Services


When calling a Web service, you must provide technical definitions as part of your request. These definitions help in filtering the returned results and subsequent user provisioning.

Select Applications (SAPGRC_AC_IDM_SELECTAPPLICATION)


You can call this Web service from the IdM system to Access Control. It returns a list of resources which are available for user provisioning. For bidirectional integration, the list of resources configured in the IdM system is maintained in Access Control. Before submitting a request, make sure that the nonERP resources are configured in Access Control.

Function/Method
getSystems (test.types.p2.GetSystems parameters)

Input Parameters
Field System Type Description The resources are categorized by Production, Non-Production, QA, Test, and so on. Possible Value(s)/Example The default is All. Example: Development, Production, Non-Production, QA, Test, etc. The default is All. Example: SAP, Oracle, etc. The default is EN.

Application Type

The resource type indicates whether the server is an SAP system or a non-SAP system. The language in which the information is to be returned.

Locale

Output Parameters
Field System ID Description System Category Example Q5F Q5F Dev System Development

Page 341 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Search Role (SAPGRC_AC_IDM_SEARCHROLES)


You can call this Web service to retrieve a list of roles within a selected source. It includes a filtration capability for refining the search.

Function/Method
getRoles (test.types.p3.GetRoles parameters)

Input Parameters
Field Application * Description The name of the application server that has the given role information. The criteria to use while searching. Roles You can search by role name and description. Transaction Enter the exact transaction code of the role search. CreateAccount Enter a role or account to create a new account that is similar to an existing account. The default is All. Example: Finance The default is All. Example: Account Payable The default is All. Example: Z_AP_Accountant The default is All. Example: Accountant Role The default is All. Example: Finance Payables The default is All. Example: SAP Possible Value(s)/Example There is no default. Example: VA6 There is no default. Possible Values: Roles Transaction CreateAccount

Access Type *

Business Process

The name of the business process which is used for the role search. The name of the business subprocess which is used for the role search. The name of the role used for the role search. The description of the role name used for the role search. The functional area of the role used for the role search. The company name of the role used for the role search.

Sub Process (Sub Process for the selected Business Process) Role Name

Role/Profile Description

Functional Area

Company (Name)

Transaction (Applicable for Access Type > Transaction Code only) The transaction code of the The default is All.

342

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Field

Description user is entered in this parameter if roles are searched using transaction code.

Possible Value(s)/Example Example: FB01

User Info Group (Applicable for Access Type > Create Account Like only) User ID The ID of the user whose roles are displayed. Applicable for all Access Types Locale Hit Count The language in which the information is returned. The count of the role information retrieved at a time.

There is no default. Example: CPerkins

The default is EN. The default is 100. Example: 40

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered.

Output Parameters
Field Application Role Name Role Type Role Description Valid From Valid To Lead Owner Example VA6 Z_AP_CLERK Single Role Z_AP_CLERK not applicable not applicable Brian Law

The Valid From and Valid To fields are empty. They appear in the user interface, but are not used.

Page 343 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Role Details (SAPGRC_AC_IDM_ROLEDETAILS)


You can call this Web service to retrieve the detailed description of the selected role. You must pass the system in the input parameters, else the transaction code will not display.

Function/Method
roleDetails (test.types.p2.RoleDetails parameters)

Input Parameters
Field Role/Profile Name * Description The name of the Role/Profile whose details are returned. The name of application server that has the given role information. The language in which the information is returned. Possible Value(s)/Example There is no default. Example: Z_AP_Accountant The default is All. Example: CRM The default is EN. Example: EN, DE, JA, ES, FR, PT, IT, HU, ZH, RU, KO, PL

System

Locale

Note If the role details information is not available in the selected language, they are displayed in the system default language.

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered.

You can also search for Roles by using the Search Role Web service.

Output Parameters
Field Role Name Role Type Role Description Detail Description Business Process Sub Process Critical Level Reaffirm Period Last Reaffirm Date List System CRM Example Z_AP_Accountant Single Role Z_AP_Accountant Accountant Role Finance Account Payable HIGH 0 05/05/2009

344

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Field List List Functional Area List Company List Functional Area and Company Approver List Transaction Code Role Approver Alternate Approver

Example

Brian Law Cheryl Jones

Finance Payables

SAP

Mark Horsten

F-02

Page 345 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Role Details (SAPGRC_AC_IDM_ROLEDETAILS_V1_1)


This Web service is implemented for AC 5.3 SP09. It is an incremented version of the SAPGRC_AC_IDM_ROLEDETAILS Web service. In addition to providing the SAPGRC_AC_IDM_ROLEDETAILS Web service information, it includes the custom attributes. You can use either Web service. V1_1 does not over write the SAPGRC_AC_IDM_ROLEDETAILS Web service.

Function/Method
Same as the SAPGRC_AC_IDM_ROLEDETAILS Web service information.

Input Parameters
Same as the SAPGRC_AC_IDM_ROLEDETAILS Web service information.

Output Parameters
Same as the SAPGRC_AC_IDM_ROLEDETAILS Web service information, and the following additional output parameters:

Field List Custom Field Name Value

Example GROUP_TYPE Finance

346

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Request Details (SAPGRC_AC_IDM_REQUESTDETAILS)


This Web service provides current workflow stage information, next stage information, risk analysis details and request information (Request ID, Priority, Application, Role).

Function/Method
getRequestDetails (test.types.p3.GetRequestDetails parameters)

Input Parameters
Possible Value(s)/Example Example: 1854 The default is EN. Example: EN, DE, JA, ES, FR, PT, IT, HU, ZH, RU, KO, PL Note: Parameters marked with an asterisk (*) indicate they are mandatory. The Web service fails if the correct value is not entered. Field Request Id* Locale Description Request number The language in which the information is returned.

Output Parameters
Field Request Id User Name Email Requestor Name Email Manager Name Email Approval Due date Request Status Request Type Priority List Application Valid From Valid To List System List Role System Type Description
GTS Master Data Maintenance VS::GTS_MASTER_DATA_MAINTAIN AR2 GTS

Example 1854 May Wong [MWONG] mwong@dev27.dev-wdf.sap.corp Calvin Klein [CKLEIN] cklein@dev27.dev-wdf.sap.corp Calvin Klein [CKLEIN] cklein@dev27.dev-wdf.sap.corp
12/31/9999

Open Change Type HIGH AR2 - GTS 3/9/2009 12/31/2500 QF7

Single

Approver
CPERKINS

Valid From

3/9/2009 12/31/9999

Page 347 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services Field Valid To Action Example
REMOVE

List - Risk Violation System Type System Risk Description Org Rules Violation Count Status

SAP AR2-GTS Security Administration and Transport Administration

1 High

List - Mitigation System Risk Description Org Rules Control Id Functional Area Approver Valid From Valid To

AR2-GTS Security Administration and Transport Administration

MITCTL_001

AC53 MJONES 11/10/2008 11/10/2009 Manager Brian Law Approved Role Owner

Current Stage Name List Approver Name Next Stage Approver Status

348

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Submit Request (to Access Control) (SAPGRC_AC_IDM_SUBMITREQUEST)


You can call this Web service from the IdM system to submit a request in Access Control.

Function/Method
getSubmitRequest (test.types.p2.GetSubmitRequest parameters)

Input Parameters
Field Request Type * Description Refers to existing configured request types in the Compliant User Provisioning. It is used to determine what actions are performed to process the request. Indicates the severity of the submitted request. Possible Value(s)/Example There is no default. Example: NEW, CHANGE, DELETE, LOCK, UNLOCK, and so on.

Priority *

The default is HIGH. Example: HIGH, MEDIUM, LOW There is no default. Example: CRM

Applications *

The name of the target application server. You can include multiple applications by listing them with commas, such as VA6, QA6.

functionalArea

The classification is used to organize activities within a department or Business Process.

There is no default value. Example: Finance Payable, Purchasing.

User Info Group (retrieves details from selected resources) User ID * The unique ID of the person for whom you are requesting access. The name of the person for whom you are requesting access. The e-mail address of the person for whom you are requesting access. The telephone number of the user for whom you are requesting access. The department of the user for whom you are requesting access. The location of the user for There is no default. Example: mwong There is no default. Example: Mae Wong There is no default. Example: mae.wong@sap.com There is no default. Example: 16501367006 There is no default. Example: Accounting There is no default.

User Name * (First Name and Last Name) Email *

Telephone Number

Department

Location

Page 349 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Field

Description whom you are requesting access. The company name of the person for whom you are requesting access. This is the status of the employee in the company.

Possible Value(s)/Example Example: Palo Alto There is no default. Example: SAP There is no default. Example: NEW

Company

Employee Type

Requestor Info Group (these parameters must match the existing data in the target authentication system) Requestor ID * The unique ID of the user There is no default. who is submitting the Example: sjones request. Requestor Email * The e-mail address of the There is no default. user who is submitting the Example: request. sandra.jones@sap.com Requestor Name * The name of the person There is no default. who is submitting the Example: Sandra Jones request. Telephone Number The telephone number of There is no default. the person who is Example: 16505551212 submitting the request. Manager Info Group (these parameters must match the existing data in the target authentication system) Manager ID * The unique ID of the There is no default. manager of the user who is Example: BFAUST submitting the request. The Manager ID parameter is mandatory only if the workflow pathos at the Manager stage. Manager Name (First The name of the manager There is no default. Name and Last Name) of the user who is Example: Bill Faust submitting the request. Manager Email The e-mail address of the There is no default. manager of the user who is Example: submitting the request. bfaust@mycompany.com Manager Telephone This is the managers There is no default. telephone number. Example: 650 847-2000 Request Reason The reason for requesting access is entered in this field. This parameter is the name of the Secure Network There is no default. Example: New employee Example: CN=I801018, 0=SAP-

SNC Name

350

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Field

Description Communication (SNC). You use the SNC value for Single Sign-On to systems that run in an ABAP environment and use SAP GUI as the front-end client. If this field is set to True, the user can log on without having a default SNC name for authentication. This field indicates the validity start date for a user. This field indicates the validity end date for a user

Possible Value(s)/Example AG,C=DE

unsecurelogon

Example: True/False

validfrom

Example: 07/03/2009 Example: 09/05/2020

validto

Role Info Group (retrieves other details from Search Role Web service) System ID The name of the There is no default. application server that Example: VA6 contains the role information. Role ID The role ID of the There is no default. submitted request. Example: Z_AP_Clerks Add/Remove Action This determines what Example: ADD, REMOVE, action is performed for the KEEP role (for example, add or remove the role for the user) Valid From This indicates the role Example: 07/03/2009 validity start date for a user. The date when the user can start using the role. Valid To This indicates the role Example: 09/05/2020 validity end date for a user. The date when the user can no longer use the role. Custom Fields Info Group Field Name

The name of the additional custom field defined by your corporate policy. The value of the corresponding additional custom field defined by your corporate policy.

There is no default. Example: Region There is no default. Example: EMEA

Value

Page 351 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered.

352

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Output Parameters
Field Request Number Status Example 1001 Open

Page 353 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Risk Analysis (SAPGRC_AC_IDM_RISKANALYSIS)


You can call this Web service to perform Segregation of Duties (SoD) analysis after submitting a request. You select specific roles and then check for any possible risk violation when the roles are assigned to users.

Function/Method
execute (test.types.p4.Execute parameters)

Input Parameters
If the Request ID value is entered, then the User ID and System parameters are optional and vice versa.

Field Request ID *

Description The unique identification number of an existing request.

Possible Value(s)/Example There is no default. The IDs of existing requests are possible values. Example: 1002

User ID *

The unique ID of the user to be provisioned. The name of the application server where risk analysis is executed. The language in which the information is returned.

There is no default. Example: mwong There is no default. Example: CRM The default is EN. Example: EN, DE, JA, ES, FR, PT, IT, HU, ZH, RU, KO, PL.

System *

Locale

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered.

354

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Output Parameters
Field TCodeDetails Role Description System Transaction code description Transaction code ID Example

Z_AP_Payables CRM Create Vendor FK01

Risk Details Org Rule Details Risk Risk Description Risk Level System Transaction codes Violation Count

BUKRS P001 Create fictitious vendor and initiate payment to vendor HIGH

CRM FK01, FB01 2

Risk Analysis Results Critical Tcode PFCG

Page 355 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Audit Trail (SAPGRC_AC_IDM_AUDITTRAIL)


You can call this Web service from either Access Control or the IdM system. When calling the Audit Logs Web service from the IdM system, it provides the request approval history. It returns the requests detail information such as when the request was created, who submitted it, and who approved it. All the provisioning service activity performed in Access Control is logged in the audit trail. When calling the Audit Logs Web service from Access Control, it returns the provisioning actions performed in the IdM system.

The GRC Audit Trail also displays the audit history provided by the IdM system for non-ERP system provisioning.

Function/Method
getAuditLogs (test.types.p3.GetAuditLogs parameters)

Input Parameters
Field Request ID Description The unique identification number of existing request. Possible Value(s)/Example Request ID of already submitted request. Example : 1002 User Info Group (retrieves details from selected resources) User ID The unique ID of the user for which audit information is retrieved. The first name of the user for which audit information is retrieved. The last name of the user for which audit information is retrieved. The starting date when the audit information is retrieved. The end date when the audit information is retrieved. This is the status of the request. The language in which the information is returned. Example : mwong

User First Name

Example: Mae

User Last Name

Example: Wong

From Date To Date Action

Example: 05/03/2008 Example : 05/22/2008 Possible values are: OPEN, HOLD, REJECT, CLOSED, CANCEL. The default is EN. Possible values are: DE, JA, ES ,FR, PT, IT, HU, ZH, RU, KO, PL.

Locale

356

August 2010

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Output Parameters
The following table shows the output parameters that are part of the returned message response: Field Priority Status Created Date Request ID Submitted By Requested By Example High OPEN 2008-05-05 1002 Sandra Jones Sandra Jones

Request History Path Stage ID CREATE_USER_PATH MANAGER 3485 Note: This is the parent ID for the action being performed. Q5F

Description Display String

Request 1002 Submitted by Sandra Jones(SJONES) on 05/05/2008 02:35 MWONG 1002

User ID Request ID Action Date Action Value Dependent ID

05/05/2008 07:00 Z_AP_PAYABLE 3487 Note: This is the child ID for the action being performed.

Page 357 of 397

Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Request Status (SAPGRC_AC_IDM_REQUESTSTATUS)


You can call this Web service from either Access Control or the IdM system. When you call the Request Status Web service from the IdM system, it checks the status of a request processed in Access Control including its detailed information. When you call the Request Status Web service from Access Control, it returns the status of the request within the IdM system.

Function/Method
getStatus (test.types.p2.GetStatus parameters)

Input Parameters
Field Request ID * Description The unique identification number of the submitted request whose status is returned. The language in which the information is returned. Possible Value(s)/Example Example: 1002

Locale

The default is EN.

Parameters marked with an asterisk (*) are required. The Web service fails if the correct value is not entered.

Output Parameters
Field Request Status Request ID Status Approval Due Date User Name Stage Example

1002 Open 07/08/2008 Mark Wong Approver

All messages returned by the Web service consist of a response object comprising Message Type, Message Code, and Message Description.

358

August 2010

Access Control and Identity Manager Integration Integrating with an Identity Management Solution

Integrating with an Identity Management Solution


You can integrate Access Control with an IdM solution by performing configuration steps in the Compliant User Provisioning capability of Access Control. The procedures in this section describe the integration approach when Access Control is the leading provisioning system where provisioning requests are submitted to the IdM system. For more information, see the section Access Control as a Leading Provisioning System for the business case. You also must perform configuration steps in the IdM solution. However, these steps vary from vendor to vendor. Therefore, this section does not provide specific configuration information required for the IdM system. The following diagram shows the configuration workflow required in Access Control to integrate with an IdM system:

Page 359 of 397

Access Control and Identity Manager Integration Defining Connectors for IdM Systems

Defining Connectors for IdM Systems


You must create a connector for each resource that is configured in the IdM system. Procedure 1. Go to Compliant User Provisioning > Configuration > Connectors > Create Connector. 2. In Connector Type, select IDM. 3. In the Web Service URI field, enter the URI address of the Web service in the IdM. 4. Enter the user ID and password for the application server using this connection. The user ID must have the appropriate role to perform technical configuration tasks. 5. (Optional) In the System Language field, enter the system language of the target IdM system. If no language is selected, this field defaults to the language of the target IdM system. 6. In Connector Category, select Production, Non-production or Other. 7. In Password Self-service, select whether or not the password self-service feature is enabled for the connector. 8. Map the IdM actions to the Access Control actions: 1. For the IdM system integration, obtain a copy of the SPML Schema file (an XML file). You must physically obtain a copy of the SPML Schema file from the IdM vendor. This file contains action names and their required parameters. This includes the following: Create User Change User Delete User Lock/Unlock User Audit Logs Reset Password

2. Identify the action name and map these actions to the corresponding actions of Access Control. For example, if an action is defined as an Object Class in the IdM schema, map it as: Create User:OC = BasicUser (where BasicUser is the name of the ObjectClassDfinition in the IdM schema). If an action is defined as an Extended Request Definition in the IdM schema, map it as: LOCK_USER:EXT = disableUser (where disableUser is the name of the ExtendedRequestDefinition in the IdM schema). The following table shows the parameters required to configure an IdM connector. These parameter values vary from one IdM vendor to another depending on the schema:

360

August 2010

Access Control and Identity Manager Integration Defining Connectors for IdM Systems

Action Map New Account (Create User) Asynchronous

Parameter Name CREATE_USER:OC

Parameter Value Name of user object class defined in the IdM schema For example, BasicUser. Async/Sync (depending upon the provisioning workflow the default is Sync) For more information on Async/Sync., see the section Sending Provisioning Request to an IdM System.

PROV_CALL

Change User Delete User Lock User

CHANGE_USER:OC DELETE_USER:OC LOCK_USER:EXT

Name of user object class for modifying user defined in the IdM schema For example, BasicUser. Name of user object class for deleting user defined in the IdM schema For example, BasicUser. Name of the object class /extended request for locking users defined in the IdM schema For example, disableUser. Name of the object class /extended request for unlocking users defined in the IdM schema For example, enableUser. Name of the object class /extended request for assigning role defined in the IdM schema For example, BasicUser. Name of the object class /extended request for resetting user password defined in the IdM schema For example, resetUserPassword.

Unlock User

UNLOCK_USER:EXT

Assign Roles

ASSIGN_ROLES:OC

Password Reset

RESET_PASSWORD:EXT

9. Click Test Connection.

Setting the Field Mapping


You can maintain a map of the IdM fields that correspond to the Access Control fields. To configure the field mapping between Access Control and the IdM system, do the following: 1. Go to Compliant User Provisioning > Configuration > Field Mapping > Provisioning. 2. Click Create. 3. In Connector Type, select IDM. 4. Click Add for the Application field and select the desired application connector defined for the IdM system. 5. Click Continue. The field mapping screen for Access Control Fields and Application Fields appears. A schema request is sent to the IdM system to retrieve all the IdM fields defined in the schema.

6. Click Add to select a field name (these are the IdM fields) and map the fields.

Page 361 of 397

Access Control and Identity Manager Integration Defining Connectors for IdM Systems Example: Access Control Field Email Address - STANDARD User FName - STANDARD User ID STANDARD User LName -STANDARD Application Field email firstname accountId lastname

Importing Roles
You must import all roles for the IdM source to Access Control. These roles are then assigned to users when the Assign Roles Request Web Service is submitted to the IdM system. The role file is in a tab-delimited format. To import roles perform the following: 1. Go to Compliant User Provisioning > Configuration > Roles > Import Roles. 2. Click Download Template and save the RoleImport.xls file to your local drive. This is a template for you to enter all of your role information for your organization. 3. Save your changes. You can rename the template if desired. 4. Select From File. If you want to overwrite any existing role file with the same name, select the Overwrite Existing Roles indicator. 5. Click Import.

362

August 2010

Access Control and Identity Manager Integration Sending Provisioning Request to an IdM System

Sending Provisioning Request to an IdM System


After configuring Access Control to the IdM system, a provisioning request is sent from Access Control. Based on the action map of parameter, PROV_CALL (set as either asynchronous or synchronous); the provisioning request can take one of the two possible process flows. The diagram below illustrates how a provisioning request is sent to an IdM system to access a nonERP application:

When a provisioning request is submitted in Access Control and the connector parameter setting PROV_CALL is set to asynchronous, the Submit Request Web service is immediately called without processing in the approval workflow. The provisioning request is submitted to the IdM system and processed in the provisioning workflow for access to a non-ERP system. If the provisioning workflow is not defined, it defaults to Synchronous.

If PROV_CALL is set to synchronous, the provisioning request is sent to the approval workflow. Approving the provisioning request triggers an SPML SOAP provisioning request, which is submitted to the IdM system for processing within the provisioning workflow. The SPML SOAP request is submitted to the IdM system to perform the following operations: New Account (Create User)

Page 363 of 397

Access Control and Identity Manager Integration Sending Provisioning Request to an IdM System Change User Delete User Lock/Unlock User Assign/Remove Roles Password Reset

The IdM system immediately returns a response message to Access Control before processing the provisioning request. Both the SPML SOAP provisioning request and the Submit Request Web service are SPML requests that groups its operations in a batch. Access Control always sends a service provisioning request as a batch. The batch request is for grouping of requests and is processed as a batch job. The batch request provides both synchronous and asynchronous processing of the request. The batch request will contain all the request types that you have defined during Request Creation process in Compliant User Provisioning. Here is a code snippet of the batch request that specifies the provisioning actions: Batch Request Example
<spml:batchRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" requestID="101530.017441490037271357" processing="urn:oasis:names:tc:SPML:1:0#sequential" onError="urn:oasis:names:tc:SPML:1:0#resume"> <!-SPML Request for Creating a USer format -->

<spml:addRequest> <spml:attributes> <dsml:attr name="objectclass"> <dsml:value>BasicUser</dsml:value> </dsml:attr> <dsml:attr name="accountId"> <dsml:value>ALL_ACTION_TEST3</dsml:value> </dsml:attr> <dsml:attr name="email"> <dsml:value>john.doe@sap.com</dsml:value> </dsml:attr> <dsml:attr name="lastname"> <dsml:value>doe</dsml:value> </dsml:attr> <dsml:attr name="firstname"> <dsml:value>john</dsml:value> </dsml:attr> <dsml:attr name="options.onlyResourcesUserPasswordRequired"> <dsml:value>true</dsml:value> </dsml:attr> <dsml:attr name="resources"> <dsml:value>LDAP</dsml:value>

364

August 2010

Access Control and Identity Manager Integration Sending Provisioning Request to an IdM System
</dsml:attr> <dsml:attr name="options.AllowPasswordGeneration"> <dsml:value>true</dsml:value> </dsml:attr> </spml:attributes> </spml:addRequest> <!-- SPML Request For Changing User Attributes Format --> <spml:modifyRequest> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>ALL_ACTION_TEST3</spml:id> </spml:identifier> <spml:modifications> <dsml:modification name="firstname" operation="replace"> <dsml:value>srinivas</dsml:value> </dsml:modification> </spml:modifications> </spml:modifyRequest>

<!-- SPML Request For Deleting a User Format --> <spml:deleteRequest> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>ALL_ACTION_TEST3</spml:id> </spml:identifier> </spml:deleteRequest>

<!-- SPML Request For UNLOCKING a User Format -->

<spml:extendedRequest> <spml:operationIdentifier operationIDType="urn:oasis:names:tc:SPML:1:0#GenericString"> <spml:operationID>disableUser</spml:operationID> </spml:operationIdentifier> <spml:attributes> <dsml:attr name="accountId"> <dsml:value>ALL_ACTION_TEST3</dsml:value> </dsml:attr> </spml:attributes> </spml:extendedRequest>

<!-- SPML Request For LOCKING a User Format --> <spml:extendedRequest> <spml:operationIdentifier operationIDType="urn:oasis:names:tc:SPML:1:0#GenericString"> <spml:operationID>enableUser</spml:operationID>

Page 365 of 397

Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call
</spml:operationIdentifier> <spml:attributes> <dsml:attr name="accountId"> <dsml:value>ALL_ACTION_TEST3</dsml:value> </dsml:attr> </spml:attributes> </spml:extendedRequest> <!-- SPML Request For ASSIGNING ROLES for a User Format --> <spml:modifyRequest> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>ALL_ACTION_TEST3</spml:id> </spml:identifier> <spml:modifications> <dsml:modification name="roles" operation="add"> <dsml:value>Configurator Role</dsml:value> </dsml:modification> </spml:modifications> </spml:modifyRequest>

Provisioning to Other Target Systems with SPML SOAP Compliant Call


Access Control can provision to other systems that are SMPL SOAP compliant. The integration is similar to that used with an IdM or SAP Enterprise Portal. The procedures in this section describe the integration approach when Access Control is provisioning to other supported systems. For more information, see the section Access Control provisioning to other supported Systems via SMPL SOAP for the business case. Before performing configuration steps in Compliant User Provisioning, you must be able to: Use SPML SOAP with provisioning services Extract the SPML Schema parameter definitions You also must perform configuration steps within the target system. These steps vary from system to system. Therefore, this section does not provide specific configuration information required for the target system.

366

August 2010

Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call

Defining a Connector for Target Systems other than IdM


To integrate with other target systems, perform the following steps: 1. Go to Compliant User Provisioning > Configuration > Connectors > Create Connector. 2. The Connectors screen appears. In the Connector Type dropdown menu, select Others. 3. In the Name field, enter a name for the connector. 4. In the Short Description field, enter a brief description of the connector. 5. In the Description field, enter a long text description of the connector. 6. In the Web Service URI field, enter the URI address of the SPML SOAP provisioning request. 7. In the User ID and Password fields, enter the user ID and password for the application server using this connection. The user ID must have the appropriate role to perform technical configuration tasks. 8. In the System Language field, enter the system language. 9. In the Connector Category dropdown menu, select the type of connector category. 10. For the target system integration, obtain a copy of the SPML Schema file (XML file). You must physically obtain a copy of the SPML Schema file from the IdM vendor. This file contains action names and their required parameters, which includes the following: Create User Change User Delete User Lock/Unlock User Audit Logs Reset Password With this schema, you identify the action name so that you can map these actions to the corresponding actions of Access Control. For example, if an action is defined as an Object Class in the schema, map it as: Create User:OC = BasicUser (where BasicUser is the name of the ObjectClassDfinition in the schema). If an action is defined as Extended Request Definition in the schema, map it as: LOCK_USER:EXT = disableUser (where disableUser is the name of the ExtendedRequestDefinition in the schema). The following table shows example parameters for the connector configuration. These parameter values vary depending on the schema.

Action Map New Account (Create User) Asynchronous Change User Delete User

Parameter Name CREATE_USER:OC

Parameter Value Name of user object class defined in the IdM schema For example, BasicUser. Async/Sync (depending upon the provisioning workflow the default is Sync) Name of user object class for modifying user defined in the IdM schema For example, BasicUser. Name of user object class for deleting user defined in the IdM schema For example, BasicUser.

PROV_CALL CHANGE_USER:OC DELETE_USER:OC

Page 367 of 397

Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call

Action Map Lock User

Parameter Name LOCK_USER:EXT

Parameter Value Name of the object class /extended request for locking users defined in the IdM schema For example, disableUser. Name of the object class /extended request for unlocking users defined in the IdM schema For example, enableUser. Name of the object class /extended request for assigning role defined in the IdM schema For example, BasicUser. Name of the object class /extended request for resetting user password defined in the IdM schema For example, resetUserPassword.

Unlock User

UNLOCK_USER:EXT

Assign Roles Password Reset

ASSIGN_ROLES:OC RESET_PASSWORD: EXT

11. Click Test Connection.

Setting the Field Mapping


You can maintain a map of the IdM fields that correspond with the Access Control fields. This configuration is performed in Compliant User Provisioning. To configure the field mapping between Access Control and the target system: 1. Go to Compliant User Provisioning > Configuration > Field Mapping > Provisioning. 2. Click Create. 3. Click Add and select the desired application connector defined for the target system. 4. Click Continue. A schema request is sent to the target system to retrieve all the parameter fields defined in the schema. 5. Click Add and select a name of the field for Access Control and Application (these are the parameter fields) to map the fields. Example: Access Control Field Email Address - STANDARD User FName - STANDARD User ID STANDARD User LName -STANDARD Application Field email firstname accountId lastname

Importing Roles
You must import all roles for the IdM source to Access Control. These roles are then assigned to users when the Assign Roles Request Web service is submitted to the IdM system. The role file is in a tab-delimited format. Go to Compliant User Provisioning > Configuration > Roles > Import Roles.

368

August 2010

Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call Click Download Template. Save the RoleImport.xls file to your local drive. This is a template for you to enter all of your role information for your organization. Save your changes. Enable the From File radio button. If you want to overwrite any existing role file with the same name, select Overwrite Existing Roles. Click Import.

Page 369 of 397

Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager

Integration with SAP NetWeaver Identity Manager


Access Control is integrated with SAP NetWeaver Identity Manager. Prerequisite You have configured the following web services: Submit Request (to Access Control) Select Application Search Role Role Details Request Status Audit Trail

This section contains integration information for configuring: Provisioning Operations that are used for the Submit Request Web service to the NetWeaver Identity Manager. Search Operations that are used for Audit Trail Web service called from the NetWeaver Identity Manager.

Provisioning Operations
The available provisioning operations are as follows: Adding a person entry Modifying a person entry Deleting a person entry

Adding a person entry


Operation properties Key Operation DN Value / Description SPML Add operation The unique id of the entry to be added. It is stored in the mskeyvalue attribute in the Identity Store Any set of the attributes available for the MX_PERSON. It is possible to add only person objects.

Attributes

Example
SPML request
Supplied identifier: Simple User Supplied attributes and values givenname=Simple, sn=User, objectclass=MX_PERSON

370

August 2010

Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager
<SOAP-ENV:Body> <spml:addRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" requestID="add123"> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>Simple User</spml:id> </spml:identifier> <spml:attributes> <dsml:attr name="sn"> <dsml:value>User</dsml:value> </dsml:attr> <dsml:attr name="objectclass"> <dsml:value>MX_PERSON</dsml:value> </dsml:attr> <dsml:attr name="givenname"> <dsml:value>Simple</dsml:value> </dsml:attr> </spml:attributes> </spml:addRequest> </SOAP-ENV:Body>

SPML response Failure


<SOAP-ENV:Body> <spml:addResponse errorMessage="Insufficient access" requestID="add123" result="urn:oasis:names:tc:SPML:1:0#success" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" xmlns:spml="urn:oasis:names:tc:SPML:1:0"/> </SOAP-ENV:Body>

Success
<SOAP-ENV:Body> <spml:addResponse requestID=add123 result=urn:oasis:names:tc:SPML:1:0#success xmlns:dsml=urn:oasis:names:tc:DSML:2:0:core xmlns:spml=urn:oasis:names:tc:SPML1:0/> </SOAP-ENV:Body>

Modifying person entry


Operation properties Key Operation DN Attributes Value / Description SPML Modify operation The unique id of the entry to be modified. Any set of the attributes available for the MX_PERSON. It is possible to modify only person objects.

Example
SPML request
Supplied identifier: Simple User Supplied attributes and values: initials=SU mail=simple.user@sap.com, telephonenumber=+4711223344

Page 371 of 397

Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager
<SOAP-ENV:Body> <spml:modifyRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" requestID="modify124"> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>Simple User</spml:id> </spml:identifier> <spml:modifications> <dsml:modification name="initials" operation="add"> <dsml:value>SU</dsml:value> </dsml:modification> <dsml:modification name="mail" operation="add"> <dsml:value>simple.user@sap.com</dsml:value> </dsml:modification> <dsml:modification name="telephonenumber" operation="add"> <dsml:value>+4711223344</dsml:value> </dsml:modification> </spml:modifications> </spml:modifyRequest> </SOAP-ENV:Body>

Deleting person entry Operation properties


Key Value / Description

Operation Starting point

SPML Delete operation The unique id of the entry to be deleted.

Example
SPML request
Supplied identifier: Simple User <SOAP-ENV:Body> <spml:deleteRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>Simple User</spml:id> </spml:identifier> </spml:deleteRequest> </SOAP-ENV:Body>

Depending on the nature and capabilities of the system, there are two execution modes for provisioning operations: asynchronous and synchronous SAP NetWeaver Identity Manager is an asynchronous system. The following steps outline the processing of provisioning request in asynchronous mode. 1. Provisioning request is sent to Identity Services. The SPML request contains field requested. Typically, the requestor sets the value for this field. 2. Identity Service accepts the request and returns the preliminary approval to the requestor. Identity Service extracts the requestID from the request. If the value is not given by the requestor, the Identity Services generates a new value. The SPML response to the requested field are set to this value.

372

August 2010

Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager Information about all subsequent processing of the request are stored together with the requested value discussed above. The requestor can now check the status of the operation using this value.

3. Identity Service handles the request Typically, these are multiple requests to managed applications for approvals and so forth. Occasionally, the requests are retry operations due to error conditions.

4. The requestor checks for the status of its provisioning request using the requestID value mentioned above.

Page 373 of 397

Access Control and Identity Manager Integration Search Operations

Search Operations
Checking the Result of Update Operation
Since SAP NetWeaver Identity Manager operates in asynchronous mode, the requestor must regularly check the status of each provision operation by executing a special Identity Service operation.

Operation Properties
Key Operation Starting point Search type Attributes requested Filter Value / Description SPML Search operation operation= auditlog not relevant * (objectclass=*)

Returned Entry
List of entries is returned. The identifiers of the returned entries are on the form cn = < mskeyvalue >, <used System Naming Context> Attribute requestoperation requestuserid requestid taskname Description The original update operation whose status is checked The user ID (mskeyvalue) of the entry which was updated The request ID for operation The name of the task that is executed as a result of the request. The ID of the task that is executed as result of the request. The status of the operation Date/time when the status of the audit entry is updated Additional message about the state of the request. Typically explanatory error message is shown here mskey of the entry that was the source of the operation in question The ID of the object in the audit table Value add, modify, delete

taskid

operationstatus timestamp message

OK, Error, Task initiated etc.

mskey

auditid

Example SPML request

374

August 2010

Access Control and Identity Manager Integration Search Operations


Supplied identifier: Supplied filter: auditlog (special IDS operation) (requested=add123)

<SOAP-ENV:Body> <spml:searchRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"> <spml:searchBase type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>operation=auditlog</spml:id> </spml:searchBase> <dsml:filter> <dsml:equalityMatch name="requestid"> <dsml:value>add123</dsml:value> </dsml:equalityMatch> </dsml:filter> </spml:searchRequest> </SOAP-ENV:Body>

SPML response
<SOAP-ENV:Body> <spml:searchResponse requestID="add123" result="urn:oasis:names:tc:SPML:1:0#success" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" xmlns:spml="urn:oasis:names:tc:SPML:1:0"> <searchResultEntry> <spml:identifier> <spml:id>cn=234,ou=audit,o=control</spml:id> </spml:identifier> <spml:attributes> <dsml:attr name="auditid"> <dsml:value type="xsd:string">234</dsml:value> </dsml:attr> <dsml:attr name="userid"> <dsml:value type="xsd:string">*24:INSERT</dsml:value> </dsml:attr> <dsml:attr name="mskey"> <dsml:value type="xsd:string">169</dsml:value> </dsml:attr> <dsml:attr name="msg"> <dsml:value type="xsd:string">no message</dsml:value> </dsml:attr> <dsml:attr name="auditroot"> <dsml:value type="xsd:string">234</dsml:value> </dsml:attr> <dsml:attr name="lastaction"> <dsml:value type="xsd:string">26</dsml:value> </dsml:attr> <dsml:attr name="provision_status"> <dsml:value type="xsd:string">Failed</dsml:value> </dsml:attr> <dsml:attr name="taskname"> <dsml:value type="xsd:string">Process ASYNC Request</dsml:value> </dsml:attr> <dsml:attr name="posteddate"> <dsml:value type="xsd:string">2008-01-16 15:23:58.49</dsml:value> </dsml:attr> <dsml:attr name="taskid"> <dsml:value type="xsd:string">20</dsml:value> </dsml:attr> <dsml:attr name="postedby"> <dsml:value type="xsd:string">mxmc_rt_u</dsml:value> </dsml:attr>

Page 375 of 397

Access Control and Identity Manager Integration Search Operations


<dsml:attr name="idsid"> <dsml:value type="xsd:string">3</dsml:value> </dsml:attr> </spml:attributes> </searchResultEntry> </spml:searchResponse> </SOAP-ENV:Body>

Obtaining Entry Information


At any time, you can obtain information about entries managed by the IDS. Usually, SPML does not offer the possibility to list multiple entries, but rather returns base level information, for example, information about a single entry. Identity Services implements additional operations to list multiple entries.

Listing multiple entries Operation properties


Key Operation Starting point Search type Attributes requested Filter Value / Description SPML Search operation operation=list not relevant * OR any attribute subset (see available attributes below) The following must be present in the filter: (objectclass=MX_PERSON). In addition the filter can contain any valid filtering based on objects attributes

Detailed Search on Single Person


Operation properties
Key Operation Starting point Search type Attributes requested Filter Value / Description SPML Search operation The unique id of the entry to be listed. not relevant Or any valid attribute subset (objectclass=*) OR any valid filtering based on objects attributes

Example
SPML request
<SOAP-ENV:Body> <spml:searchRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"> <spml:searchBase type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>Simple User</spml:id> </spml:searchBase> <dsml:filter> <dsml:present name="objectclass"></dsml:present> </dsml:filter>

376

August 2010

Access Control and Identity Manager Integration Search Operations


</spml:searchRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>Example SPML response

SPML response (entry after successful ADD)


This example shows SPML response AFTER the first example ADD operation (see above)
<SOAP-ENV:Body> <spml:searchResponse result="urn:oasis:names:tc:SPML:1:0#success" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" xmlns:spml="urn:oasis:names:tc:SPML:1:0"><searchResultEntry><spml:identifier><sp ml:id>cn=Simple User,ou=nwidm1,o=ids</spml:id></spml:identifier><spml:attributes><dsml:attr name="sn"><dsml:value type="xsd:string">User</dsml:value></dsml:attr><dsml:attr name="objectclass"><dsml:value type="xsd:string">MX_PERSON</dsml:value></dsml:attr><dsml:attr name="mskeyvalue"><dsml:value type="xsd:string">Simple User</dsml:value></dsml:attr><dsml:attr name="mskey"><dsml:value type="xsd:string">167</dsml:value></dsml:attr><dsml:attr name="mxdisabled"><dsml:value type="xsd:string">1</dsml:value></dsml:attr><dsml:attr name="givenname"><dsml:value type="xsd:string">Simple</dsml:value></dsml:attr></spml:attributes></searchResul tEntry></spml:searchResponse> </SOAP-ENV:Body>

SPML response (entry after successful MODIFY)


This example shows SPML response AFTER the modify example (see above)
<SOAP-ENV:Body> <spml:searchResponse result="urn:oasis:names:tc:SPML:1:0#success" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" xmlns:spml="urn:oasis:names:tc:SPML:1:0"><searchResultEntry><spml:identifier><sp ml:id>cn=Simple User,ou=nwidm1,o=ids</spml:id></spml:identifier><spml:attributes><dsml:attr name="sn"><dsml:value type="xsd:string">User</dsml:value></dsml:attr><dsml:attr name="objectclass"><dsml:value type="xsd:string">MX_PERSON</dsml:value></dsml:attr><dsml:attr name="telephonenumber"><dsml:value type="xsd:string">+4711223344</dsml:value></dsml:attr><dsml:attr name="mskeyvalue"><dsml:value type="xsd:string">Simple User</dsml:value></dsml:attr><dsml:attr name="mskey"><dsml:value type="xsd:string">167</dsml:value></dsml:attr><dsml:attr name="mxdisabled"><dsml:value type="xsd:string">1</dsml:value></dsml:attr><dsml:attr name="initials"><dsml:value type="xsd:string">SU</dsml:value></dsml:attr><dsml:attr name="mail"><dsml:value type="xsd:string">simple.user@sap.com</dsml:value></dsml:attr><dsml:attr name="givenname"><dsml:value type="xsd:string">Simple</dsml:value></dsml:attr></spml:attributes></searchResul tEntry></spml:searchResponse> </SOAP-ENV:Body>

Page 377 of 397

Appendix A: Rule File Templates Business Process Template

9. Appendix A: Rule File Templates


This appendix describes the templates that upload SoD rules, critical actions, and critical permissions. You must use the format specified in these templates when you load rules. You can name your rule loading files anything you want, but use a naming convention that lets you identify which file contains which type of data. It is important to identify the system in the file name for function_action and function_permission files. For more information, see the section Rule Uploads.

Business Process Template


Business Process: ALL_business_processes.txt Field BUSINESS PROCESS ID LANGUAGE DESCRIPTION Type Data Length

CHAR 4 CHAR 2 CHAR 120

Function Template
Functions : ALL_business_function.txt Field FUNCTION ID LANGUAGE DESCRIPTION FUNCTION SCOPE Type Data Length Value Description

CHAR 8 CHAR 2 CHAR 120 CHAR 1 S = Single System C = Cross System

Function-Business Process Relationship Template


FunctionBusiness Process Relationship: ALL_function_bp.txt Field FUNCTION ID BUSINESS PROCESS ID Type CHAR CHAR Data Length 8 4

378

August 2010

Appendix A: Rule File Templates Function-Action Relationship Template

Function-Action Relationship Template


FunctionAction Relationship: <SYSTEM>_function_action.txt Field FUNCTION ID TRANSACTION STATUS Type CHAR CHAR NUMC Data Length 8 20 1 0=ENABLED 1=DISABLED Value Description

Function-Permission Relationship Template


FunctionPermission Relationship: <SYSTEM>_function_permission.txt Field FUNCTION ID T-CODE OBJECT FIELD FROM VALUE TO VALUE SEARCH TYPE STATUS Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR NUMC Data Length 8 20 10 10 40 40 3 1 AND/OR/NOT 0=ENABLED 1=DISABLED To load critical permission rules using the function-permission relationship, you can create a dummy entry in the t-code field for the load to work. The dummy value is ^!PERMISSION. For example, to load authorization object S_BDC_MONI as a critical permission type rule, enter ^!S_BDC_MONI in the t-code field of this file. Value Description

Rule Set Template


Rule Set: ALL_ruleset.txt Field RULE SET ID LANGUAGE Type Data Length CHAR 8 CHAR 2

RULE SET DESCRIPTION CHAR 132

Page 379 of 397

Appendix A: Rule File Templates Risk Definition Template

Risk Definition Template


Risk Definition: <SYSTEM>_risks.txt Field RISK ID FUNCTION 1 ID FUNCTION 2 ID FUNCTION 3 ID FUNCTION 4 ID FUNCTION 5 ID Type Data Length Value Description

CHAR 4 CHAR 8 CHAR 8 CHAR 8 CHAR 8 CHAR 8

BUSINESS PROCESS ID CHAR 4 PRIORITY NUMC 1 0=Medium 1=High 2=Low 3=Critical STATUS NUMC 1 0=ENABLED 1=DISABLED RISK TYPE CHAR 1 1=SoD 2=Critical Action 3=Critical Permission

Risk Description Template


Risk Description: <SYSTEM>_risks_desc.txt Field RISK ID LANGUAGE RISK DESCRIPTION Type Data Length

CHAR 4 CHAR 2 CHAR 132

DETAIL DESCRIPTION CHAR 1000 CONTROL OBJECTIVE CHAR 1000

380

August 2010

Appendix A: Rule File Templates Risk to Rule Set Relationship Template

Risk to Rule Set Relationship Template


Risk Rule Set Mapping: <SYSTEM>_risk _ruleset.txt Field RISK ID RULE SET ID Type CHAR CHAR Data Length 4 8

Page 381 of 397

Appendix B: Data Mapping Templates for Non-RTA Systems User File Template

10. Appendix B: Data Mapping Templates for Non-RTA Systems


When you want to include non-RTA-supported systems in Risk Analysis and Remediation, use these templates to format data from those systems to ensure successful loading to Access Control. Tab-delimited text files are supported for uploading to Risk Analysis and Remediation.

User File Template


This template shows the required user information. When you download user information, the USERID field must be unique and not NULL. You should also ensure there are no duplicate records in the files and no blank records at the end of the file.

User File Template Data Field Type String String Field Field Size Values Sorting 50 50 CAPS

Field USERID FNAME

Req'd Description User ID First name (if not available, repeat User ID here) Last name (if not available, repeat User ID here) Email address Phone number (leave blank if unavailable) Department User Group (leave blank if unavailable)

Transformation Unique records only

Sort Yes Ascending Yes

LNAME

String

50

Yes

EMAIL PHONE

String String

250 40

No No

DEPARTMENT String USER-GROUP String

40 20 CAPs

No No

382

August 2010

Appendix B: Data Mapping Templates for Non-RTA Systems User Action File Template

User Action File Template


User Action File Template Data Field Type Field Field Size Values Sorting

Field USERID

Req'd Description User ID

Transformation Unique record = The combination of columns 13 (User ID, Roles, and Action From) must be unique

String 50

CAPS Sort Yes Ascending Order 1

ROLES

String 49

CAPS Sort Yes Ascending Order 2 CAPS sort Yes Ascending Order 3 CAPS Yes

Access Role Name User Action

ACTIONFROM String 50

ACTIONTO

String 50

User Action, If this value does not only applicable exist for the source if User Action system, leave blank has range From/To Action Profile, if applicable. If not, repeat Role Name field. If this value does not exist for the source system, repeat ROLE field from column 2

PROFILE

String 50

CAPS

Yes

COMPOSITE ROLE NAME

String 50

CAPS

No

Composite role If this value does not name, leave exist for the source blank if not system, leave blank. available.

User Permission File Template


This file is required for legacy systems with configurable permission levels. User Permission File Template Data Field Field Field Type Size Values Sorting String 50

Field USERID

Req'd Description User ID

Transformation Unique record = The combination of columns 13 (User ID, Roles, and Action From) must be unique

CAPS Sort Yes Ascending Order 1

ROLE

String 49

CAPS Sort Yes Ascending

Access Role Name

Page 383 of 397

Appendix B: Data Mapping Templates for Non-RTA Systems User Permission File Template

User Permission File Template Data Field Field Field Type Size Values Sorting Order 2 PERMISSION String 100 CAPS Sort Yes Ascending Order 3 User Permission (Permission Object/Field), required if applicable Query generated numerical sequence (1+ counter per user) Permission Value Permission If this value does value, only not exist for source applicable if system, leave blank User Action has range From/To User Permission Profile, if applicable. Composite role name, leave blank if not available. If this value does not exist for source system, repeat ROLE field from column 2 If this value does not exist for source system, leave blank. ACTION and PERMISSION field that use | | with no space in between

Field

Req'd Description

Transformation

PRMGRP

String 20

Generate after sorting

Yes

Extractor/query generates this value. The value is generated after the data is sorted.

FROMVALUE String 50 TOVALUE String 50

CAPS CAPS

Yes Yes

PROFILE

String 50

CAPS

Yes

COMPOSITE String 50 ROLE

CAPS

No

If a single permission in the PRMGRP field contains multiple fields, the PRMGRP value must be the same for the different fields, if they are within the same authorization. Using the SAP security model as an example, say you have permission F_BKPF_KOA which contains two fields, Activity and Authorization Group. If a user has this permission in multiple roles, each roles authorization should have the same PRMGRP value for Activity and Authorization Group for F_BKPF_KOA. For example:

384

August 2010

Appendix B: Data Mapping Templates for Non-RTA Systems Role File Template User ID - 12345 - Jane Doe Role A Authorization Object F_BKPF_KOA Field Activity 01 Field Auth Group AA Role B Authorization Object F_BKPF_KOA Field Activity 02 Field Auth Group BB The file layout is: UserID 12345 12345 12345 12345 Role Role A Role A Role B Role B Permission F_BKPF_KOA||ACTVT F_BKPF_KOA||BEGRU F_BKPF_KOA||ACTVT F_BKPF_KOA||BEGRU PRMGRP 1 1 2 2 FROMVALUE 01 AA 02 BB

Role File Template


This file is required for non-SAP security structures. Role File Template Data Field Type String String Field Field Size Values Sorting 50 100 CAPS Sorted Ascending

Field ROLE ROLE DESCRIPTION

Req'd Description Yes Yes Access Role Name Role Description

Transformation

Role Action File Template


This file is required for non-SAP security structures. Role Action File Template Data Field Type String Field Field Size Values Sorting 50

Field ROLE

Req'd Description Transformation Role Name

CAPS Sort Yes Ascending/ Sort Order 1 CAPS Sort Yes Ascending/ Sort Order 2 No

ACTIONFROM String

50

Role Action

ACTIONTO

String

50

Role Action If this value does not exist for source system, leave blank.

Page 385 of 397

Appendix B: Data Mapping Templates for Non-RTA Systems Role Permission File Template

Role Action File Template Data Field Type String Field Field Size Values Sorting 50 CAPS

Field PROFILE

Req'd Description Transformation Yes Security Profile If this value does not exist for source system, repeat ROLE field from column 2

Role Permission File Template


The role permission file is required for non-SAP systems that include permission level data. Role Permission File Template Data Field Type Field Field Size Values Sorting CAPS Sort Ascending Order 1 CAPS Sort Ascending Order 2 Generate after sorting Yes

Field ROLE

Req'd Description Yes Role Name

Transformation

String 50

PERMISSION String 100

Object/Field

Concatenate ACTION and PERMISSION fields that use | | with no space in between Extractor/query generates this value. The value is generated after the data is sorted.

PRMGRP

String 20

Query generated numerical sequence (1++ counter per user) Permission Value Permission value, only applicable if User Action has range From/To Role Profile, if applicable.

FROMVALUE String 50 TOVALUE String 50

CAPS CAPS

Yes Yes

If this value does not exist for source system, leave blank

PROFILE

String 50

CAPS

Yes

If this value does not exist for source system, repeat ROLE field from column 2

386

August 2010

Appendix B: Data Mapping Templates for Non-RTA Systems Profile File Template

Profile File Template


This file is required for non-SAP security structures that use Profiles. Profile File Template Data Field Type String String Field Field Size Values Sorting 50 100 CAPS Sorted Ascending

Field PROFILE PROFILE DESCRIPTION

Req'd Description Yes Yes Access Profile Name Profile Description

Transformation

Profile Action File Template


This file is required for non-SAP security structures that use Profiles. Profile Action File Template Data Field Type String Field Field Size Values Sorting 50 CAPS Sort Ascending/ Sort Order 1 Sort Ascending/ Sort Order 2

Field PROFILE

Req'd Description Transformation Yes Profile Name Profile Action Profile Action If this value does not exist for source system, leave blank.

ACTIONFROM String

50

CAPS

Yes

ACTIONTO

String

50

No

Profile Permission File Template


The profile permission file is required for non-SAP systems that include permission level data. Profile Permission File Template Data Field Type Field Field Size Values Sorting CAPS Sort Ascending Order 1 CAPS Sort Ascending Order 2

Field PROFILE

Req'd Description Yes Profile Name

Transformation

String 50

PERMISSION String 100

Object/Field

Concatenate ACTION and PERMISSION fields that use | | with no space in between

Page 387 of 397

Appendix B: Data Mapping Templates for Non-RTA Systems

Profile Permission File Template Data Field Type Field Field Size Values Sorting Generate after sorting

Field PRMGRP

Req'd Description Yes Query generated numerical sequence (1++ counter per user) Permission Value Permission value, only applicable if User Action has range From/To

Transformation Extractor/query generates this value. The value is generated after the data is sorted.

String 20

FROMVALUE String 50 TOVALUE String 50

CAPS CAPS

Yes Yes

If this value does not exist for source system, leave blank

Action Permission Objects Template


Action Permission Objects Template Data Field Type String Field Field Size Values Sorting 20 CAPS Sort Ascending Order 1 Sort Ascending Order 3

Field ACTION

Req'd Description Yes Action

Transformation

PERMISSION String

10

CAPS

Yes

Permission

ACTVT

String

10 50

CAPS CAPS

Yes Yes

Permission Object Field Permission Object Field Value Permission Object Value If this value does not exist for source system, leave blank

FROMVALUE String

TOVALUE

String

50

CAPS

No

Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File)
The ACT_PRM_FLD_VAL file loads descriptive text for actions, permissions, fields, and values. All values are included in one table, and the text is identified by the text in the second field of the table, which should be ACT for actions, PRM for permission, FLD for field values, and VAL for the

388

August 2010

Appendix B: Data Mapping Templates for Non-RTA Systems Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File) value description. If rules are not required at the permission level, only Action text is required in this file. Sample File

Action Template
This table shows the format for the action description section of the ACT_PRM_FLD_VAL description file. Action Template Data Field Type Field Field Size Values Sorting Req'd Description Mandatory field. Required by load format 3 CAPS Hard code ACT as value for this file Mandatory field. Required by load format String 50 2 String <100 CAPS CAPS Yes Yes Action

Field Leave Blank

Transformation Leave Blank

ACT

Hard coded value ACT Leave Blank

Leave Blank

TCODE EN TCODE DESCRIPTIONS

Sorted Ascending

Hard code EN as Hard coded value for this field value EN Action Description

Permission Template
This table shows the format for the permission section of the ACT_PRM_FLD_VAL description file. Permission Template Data Field Type Field Field Size Values Sorting Req'd Description

Field

Transformation

Page 389 of 397

Appendix B: Data Mapping Templates for Non-RTA Systems Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File) Permission Template Data Field Type Field Field Size Values Sorting Req'd Description

Field Leave Blank

Transformation

Mandatory field. Leave Blank Required by load format 3 CAPS Hard code PRM: Hard coded as value for this value PRM file Mandatory field. Leave Blank Required by load format String 50 2 String <100 CAPS CAPS Yes Yes Permission Sorted Ascending

PRM

Leave Blank

PERMISSION EN PERMISSION DESCRIPTIONS

Hard code EN as Hard coded value for this field value EN Permission Description

Field Template
This table shows the format for the field section of the ACT_PRM_FLD_VAL description file. Field Template Data Field Field Field Type Size Values Sorting Req'd Description Transformation Mandatory Leave Blank field. Required by load format CAPS Hard code FLD: as value for this file Yes Hard coded value FLD

Field Leave Blank

FLD

ACTVT

String 50

CAPS

Mandatory Leave Blank field. Required by load format Permission object field If this field does not exist for the source system, use hard coded ACTVT in this column

PERMISSION/PERMISSION VALUE

String <100 CAPS

Yes

EN

CAPS

Hard code Hard coded value EN as value EN

390

August 2010

Appendix B: Data Mapping Templates for Non-RTA Systems Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File) Field Template Data Field Field Field Type Size Values Sorting Req'd Description Transformation for this field OBJECT FIELD DESCRIPTION String <100 Yes Permission Object Description

Field

Value Template
This table shows the format for the VAL_DESCR section of the ACT_PRM_FLD_VAL description file. Value Template Data Field Type Field Field Size Values Sorting Req'd Description Mandatory field. Required by load format CAPS

Field Leave Blank

Transformation Leave Blank

VAL

Hard code Hard coded value VAL VAL: as value for this file Mandatory field. Required by load format Leave Blank

Leave Blank

PERMISSION/ PERMISSION VALUE

String <100 CAPS

Yes

Permission value field

Concatenate PERMISSION AND PERMISSION VALUE fields with hard coded /. Insure that no space is added before and after / character Hard coded value EN

EN

CAPS

Hard code EN as value for this field Yes Permission Value Description

PERMISSION VALUE DESCRIPTION

String <100

Page 391 of 397

Appendix C: Configuring RAR for SAP Enterprise Portal Creating an iView

11. Appendix C: Configuring RAR for SAP Enterprise Portal


You can retrieve master data from the SAP Enterprise Portal, which is a component of the SAP NetWeaver J2EE engine. Risk Analysis and Remediation is configured to connect to SAP Enterprise Portal through Web services, which in turn call the real-time agent (RTA) to retrieve master data. Before you install the RTA, sap.com~grc~ccsapeprta.sda, you must install the SAP Enterprise Portal component on the SAP NetWeaver J2EE engine and configure it for Risk Analysis and Remediation. For more information, see the following sections: Creating an iView Creating an iView Role Assigning an iViews to a Role Retrieving Master Data Creating a Function in Risk Analysis and Remediation for iView Creating a Portal Connection Verifying Portal RTA Creating a Function in Risk Analysis and Remediation for iView Creating a Function in Risk Analysis and Remediation for User Management Engine Actions

Creating an iView
An iView is an executable unit in the SAP Enterprise Portal content of SAP NetWeaver. In Risk Analysis and Remediation, it is equivalent to an action in the SAP system. An iView allows you to group fields in a header area. It can be used in multiple tabs of an application. For further information about creating iViews in SAP NetWeaver, see the SAP NetWeaver documentation on SAP Help Portal at http://help.sap.com.

Creating an iView Role


An iView Role allows users to access or perform an action on an assigned iView. Procedure To create an iView role: 1. Go to Content Administration > Portal Content >New >Role. 2. The Role Wizard appears. In Step 1: General Properties, enter the role name, role ID, Prefix of ID, master language, and a description of the iView Role. 3. Click Next. Example: iView Name Role1

392

August 2010

Appendix C: Configuring RAR for SAP Enterprise Portal Assigning an iView to a Role iView ID ID Prefix Master Language Description Role1_ID (leave blank) English text description

Assigning an iView to a Role


After creating an iView, you must assign it to a role in order for users to use the iView. Procedure To assigning an iView to a role: 1. Open the Property Editor for the role you created. In this case, the role is Role1. 2. Highlight the iView that you want to assign. In this case, the folder is SAPSearch. Right mouse click to display the dropdown menu. An iView can be added to a role either by Delta Link or Copy. For this example, select Delta Link. 3. Accept the defaults in the Property Editor. The iView is automatically assigned to the role. The PCD location ID of the assigned iView to a role is used as the Action ID in Risk Analysis and Remediation.

Retrieving Master Data


The master data is a list of text objects to be uploaded for Risk Analysis and Remediation. Procedure To retrieve the master data follow the steps below: 1. Ensure that the Web Dynpro component grc / cceprta is installed under the VIREPRTA component and that your SAP GRC Access Control 5.3 system is at Support Pack 04 or higher. To verify that you have the right support pack level, go to the website below and click About. 2. Go to the URL : http://<server:port>/webdynpro/dispatcher/sap.com/ grc~cceprta/DownloadData?SAPtestID=1 Replace server:port with your location. 3. Click on Download File!. 4. Save the file to your local directory as type Text Document and name it masterdata.txt. This file contains both Portal iViews and UME actions. 5. Upload the file into SAP GRC Risk Analysis and Remediation by following the instructions under the topic Risk Analysis and Remediation -> Upload Objects. .

Page 393 of 397

Appendix C: Configuring RAR for SAP Enterprise Portal Verifying Portal RTA

Verifying Portal RTA


The Portal Real-Time Agent (RTA) that you must deploy on your NetWeaver J2EE server is sap.com~grc~ccsapeprta.sda. After deploying this component, verify that is it correctly installed and working. Procedure To verify the Portal RTA: 1. Open Access Control Risk Analysis and Remediation. 2. Make sure that the Web services for the RTA are exposed. Ensure that Web service, CCRTAWS is displayed in the Web Service Navigator. 3. Make sure that the portal service is deployed in the portal server. Example: Logon to the portal server. http://<IP Address>:<port>/irj/portal 4. Go to System Administrator/Support/Portal Runtime 5. In the Portal Anywhere Admin Tools pane, click Administration Console. 6. In the Archive Deployment Checker dropdown menu, make sure that the portal service, CCRTAWS is displayed. This confirms that the portal RTA is deployed properly. 7. Test that the portal connector is working. Open the CCDebugger screen. Example: http://<IP Address>:<port number>/webdynpro/dispatcher/sap.com/ grc~ccappcomp/CCDebugger a. The CCDebugger screen appears. In the Debugger dropdown menu, select the connector that you defined for the portal. In the Object Type dropdown menu, select the user/role. In the Object ID fields, enter an asterisk (*) for a wildcard search. Click Search Obj. In the search results pane, a list of users from the User Management Engine or roles from the portal server appears. This confirms that the connectors are working properly.

Creating a Function in RAR for iView


Before you create a function in Risk Analysis and Remediation, download the Master Data from the portal server and upload it to the Risk Analysis and Remediation database. All PCD Location IDs of the Portal Content (Roles, iViews, Pages, Workset, Layout, Folder) are available in Risk Analysis and Remediation. Procedure To create a function in Risk Analysis and Remediation for Portal Risk Analysis: 1. Open Access Control Risk Analysis and Remediation. 2. Select the Rule Architect tab. 3. In the navigation bar, click Function > Create. The Create Function screen appears. 4. Enter information in the following fields:

394

August 2010

Appendix C: Configuring RAR for SAP Enterprise Portal Creating a Function in RAR for UME Actions For information on these fields, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/grc/ ->Access Control -> SAP GRC Access Control 5.3. Function ID Description Business Process (use dropdown menu) Analysis Scope (use dropdown menu) 5. On the Action tab, click the Add icon to activate the first field under System. Use the dropdown menu and select the connector name defined for the Portal RTA. 6. In the Action field, select the Search icon to display the Search window. Search for the iView that you created. Example: SAPSearch is the iView name. 7. A list of assigned iViews appears along with PCD locations or IDs. Select the required iView and save the function. 8. On the Permissions tab, the Function Information screen displays the values for the following fields: Field defaults to PERM Value From can be Full Control, Owner, Read/Write, Read, None (based on the permission set in the portal) 9. Set the Status to ENABLE, to enable the permission. 10. Complete this function as required for generating rules or creating risk.

Creating a Function in RAR for UME Actions


For User Management Engine (UME) role-based analysis, you must create function(s) in Risk Analysis and Remediation. These functions contain UME actions for risk rules generation and subsequent role assignments. Before you can create a function, verify that the master data is loaded into the Risk Analysis and Remediation database. If it is not, download the master data from the portal server and upload it to the Risk Analysis and Remediation database. Procedure To create a function in Risk Analysis and Remediation for User Management Engine Actions: 1. Open Access Control Risk Analysis and Remediation. 2. Select the Rule Architect tab. 3. In the navigation bar, select Function > Create. 4. The Create Function screen appears. Enter information in the following fields: For information on these fields, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/grc/ ->Access Control -> SAP GRC Access Control 5.3. Function ID Description Business Process (use the dropdown menu) Analysis Scope (use the dropdown menu)

Page 395 of 397

Appendix C: Configuring RAR for SAP Enterprise Portal Creating a Function in RAR for UME Actions 5. On the Actions tab, click Add to activate the first field under System. Use the dropdown menu and select the connector name defined for the Portal RTA. 6. In the Action field, enter the User Management Engine action. Example: Function ID - AEACTION Description - SearchRequestView Business Process - Business Process Analysis Scope - Single System Actions tab: o o System - SAP EP Action - AE.ViewSearchRequestAll

6. Create a second function. Example: Function ID - CCACTION Description - SearchRequestView Business Process - Business Process Analysis Scope - Single System Actions tab: o o System - SAP EP Action - com.virsa.cc.RunAuditReports

7. Create a risk and generate rules based on functions created above. Go to Rule Architect tab. In the navigation bar, go to Risks > Create. The Create Risk screen appears. Example: Risk ID - UMER Description - User Management Engine actions risk of AC Risk Type - Segregation of Duties Risk Level - Medium Business Level - Finance Status - Enable Conflicting Functions tab: Function o o SearchRequestView - (AEACTION) RunAuditReports (CCACTION)

8. In SAP Enterprise Portal, create a role based on the User Management Engine actions that you previously assigned for functions. Go to User Administration > Identity Management. For detailed information on these fields, see the SAP Enterprise Portal documentation. Example: Role Name - CC_AE_ROLE Actions

396

August 2010

Appendix C: Configuring RAR for SAP Enterprise Portal Creating a Function in RAR for UME Actions o o SearchRequestView - (AEACTION) RunAuditReports (CCACTION)

9. Assign the role to the User ID. Go to User Administration > Identity Management. Example: User ID - dow_jones 10. In Risk Analysis and Remediation, perform a risk analysis on the User ID defined in the previous step. If a risk occurs, then the SoD violation is displayed.

Page 397 of 397