ac53 config guide en

397
Configuration Guide SAP™ GRC Access Control 5.3 Target Audience System administrators Technology consultants Document Version 3.17 August 2010

Upload: tfioretti

Post on 10-Mar-2015

974 views

Category:

Documents


2 download

TRANSCRIPT

Configuration Guide

SAP™ GRC

Access Control 5.3

Target Audience

System administrators

Technology consultants

Document Version 3.17 – August 2010

© 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.

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.

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

by SAP’s 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

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

Typographic Conventions

Type Style Represents

Example text Emphasized words or phrases in body text, titles of graphics, and tables.

Example Text 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.

Example text 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.

Example text Exact user entries—that is, words or characters that you enter in the system exactly as they appear in the documentation. Quick links (not

part of a URL.)

<Example

text> Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate

entries.

EXAMPLE TEXT Keys on the keyboard, such as function keys (F2) or the ENTER

key.

Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Configuration Guide Access Control

4 August 2010

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 Date Changes

1.00 March 2008 Ramp-up release of GRC Access Control 5.3.

2.00 June 2008 Release to customers of GRC Access Control 5.3.

2.10 September 2008 Quality update revision

2.11 November 2008 Defining connectors for SAP Enterprise Portal

2.12 December 2008 New background for SoD/UAR requests.

3.00 September 2009 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.

3.15 December 2009 Per SP10, added Enable Data Mart Job to the

RAR chapter, Additional Options section.

3.16 February 2010 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.

Configuration Guide Access Control

August 2010 5

Version Date Changes

3.17 August 2010 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

Getting Started

6 August 2010

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

Table of Contents

August 2010 7

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

Getting Started

8 August 2010

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

Table of Contents

August 2010 9

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

Getting Started

10 August 2010

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

Table of Contents

August 2010 11

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

Getting Started

12 August 2010

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

Table of Contents

August 2010 13

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

Getting Started

14 August 2010

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

Table of Contents

August 2010 15

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

Getting Started

16 August 2010

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

Table of Contents

August 2010 17

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

Getting Started

Security and Master Data Configuration

18 August 2010

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.

Getting Started

August 2010 19

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 Location on SAP Service Marketplace

Latest versions of installation and upgrade guides

service.sap.com/instguides

SAP Business Maps – general information about applications, solutions and business

scenarios

service.sap.com/businessmaps

Sizing, calculation of hardware requirements - such as CPU, disk and memory resource

service.sap.com/sizing

Released platforms and technology-related topics such as maintenance strategies and

language support

service.sap.com/platforms

To access the Platform Availability Matrix directly, enter service.sap.com/pam.

Network security service.sap.com/securityguide

High Availability service.sap.com/ha

Performance service.sap.com/performance

Information about Support Package Stacks, latest software versions and patch level requirements

service.sap.com/sp-stacks

Information about Unicode technology service.sap.com/unicode@sap

SAP Service Marketplace Links

The following table lists further links on SAP Service Marketplace:

Content Location on SAP Service Marketplace

Information about creating error messages service.sap.com/messages

SAP Notes search service.sap.com/notes

SAP Software Distribution Center (software

download and ordering of software)

service.sap.com/swdc

SAP Online Knowledge Products (OKPs) –

role-specific Learning Maps

service.sap.com/rkt

Getting Started

20 August 2010

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 Location

Configuration Guide http://service.sap.com/instguides

Master Guide http://service.sap.com/instguides

Installation Guide http://service.sap.com/instguides

Upgrade Guide http://service.sap.com/instguides

Security Guide http://service.sap.com/securityguide

Operations Guide http://service.sap.com/instguides

Release Notes http://service.sap.com/releasenotes

Application Help http://help.sap.com

GRC Access Control Integration

Security and Master Data Configuration

August 2010 21

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.

GRC Access Control Integration

Security and Master Data Configuration

22 August 2010

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.

Risk Analysis and Remediation

Security and Master Data Configuration

August 2010 23

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

Risk Analysis and Remediation

Risk Analysis Configuration

24 August 2010

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 tab‘s navigation bar.

Default Values

Parameter / Purpose Options

Default Report Type

This option determines the default report type

populated when executing a Risk Analysis.

Action Level

Permission Level (default)

Critical Actions

Critical Roles/Profiles

Mitigation Controls

Default Risk Level

This option determines the default risk level

populated when executing a Risk Analysis.

All (default)

Critical

High

Medium

Low

Default User Type

This option determines the default user type included

when executing a Risk Analysis.

All

Dialog (default)

System

Communication

Service

Reference

Risk Analysis and Remediation

Risk Analysis Configuration

August 2010 25

Parameter / Purpose Options

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.

All defined rule sets are available

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.

Yes (default)

No

Exclude Expired Users

This option specifies whether expired users are

excluded when executing a Risk Analysis.

Yes (default)

No

Exclude Mitigated Risks

This option specifies whether risks with assigned mitigating controls are excluded when executing a

Risk Analysis.

Yes (default)

No

Performance Tuning

Parameter Purpose

Batch Size for User

Synchronization

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 Threads

This setting specifies the number of server threads to 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.

Risk Analysis and Remediation

Risk Analysis Configuration

26 August 2010

Parameter Purpose

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

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 Purpose

Ignore Critical Roles and Profiles 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

This setting determines whether composite role names are displayed when risk analysis is performed.

Use SoD Supplementary Table for Analysis

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.

Risk Analysis and Remediation

Workflow Integration with Compliant User Provisioning

August 2010 27

Parameter Purpose

Convert Users, Roles and Profiles to Upper Case

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

Risk Analysis and Remediation

Workflow Integration with Compliant User Provisioning

28 August 2010

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 Purpose

Risk Maintenance 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.

Risk Analysis and Remediation

Workflow Integration with Compliant User Provisioning

August 2010 29

Parameter Purpose

Workflow Service URL 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

Provisioning‘s 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 Mitigating Control (MITICTRL)

o Mitigation Object (MITIOBJ)

o Risk (RISK)

You can view these objects in Compliant User Provisioning, by going to

Configuration tab > Miscellaneous

Request Types:

o Delete, Create, and Update Mitigating Control

o Delete, Create, and Update Mitigation Object

o Delete, Create, and Update Risk

Priorities:

o MC_HIGH – Mitigating Control

o MO_HIGH – Mitigation Object

o RS_HIGH - Risk

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

Risk Analysis and Remediation

Workflow Integration with Compliant User Provisioning

30 August 2010

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 Description

MITICTRLC Create Mitigating Control

MITICTRLD Delete Mitigating Control

MITICTRLU Update Mitigating Control

MITIOBJC Create Mitigation Object

MITIOBJD Delete Mitigation Object

MITIOBJU Update Mitigation Object

RISKC Create Risk

RISKD Delete Risk

RISKU 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 Description

MC_HIGH High Priority for Mitigating Control

MO_HIGH High Priority for Mitigation Object (Assignment)

RS_HIGH 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:

Risk Analysis and Remediation

Workflow Integration with Compliant User Provisioning

August 2010 31

Request Attribute Name Workflow Type

Priority Mitigation Control

Priority Mitigation Object

Priority Risk

Request Type Mitigation Control

Request Type Mitigation Object

Request Type 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 Field Lable Workflow Type

RSRISKID Risk ID Risk

BUSPROCID Business Process ID Risk

OBJTYPE Object Type Mitigation Object

MOMITREFNO Mitigation Control ID Mitigation Object

MITREFNO Mitigation Control ID Mitigation Control

APPROVERID Approver ID 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 Description

CC_MITCTLRL_INT 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

Risk Analysis and Remediation

Workflow Integration with Compliant User Provisioning

32 August 2010

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

Risk Analysis and Remediation

Workflow Integration with Compliant User Provisioning

August 2010 33

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 Workflow Type Initiator Stage 1

CC_MITCTRL Mitigation Control CC_MITCTRL_INT CC_MITCTROL

CC_MITOBJ Mitigation Control Assignment

CC_MITOBJ_INT CC_MITOBJ

CC_RISK Risk CC_RISK_INT 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.

Risk Analysis and Remediation

Miscellaneous

34 August 2010

For Risk Analysis and Remediation using mitigating control, mitigating object, and risk, add the exit URI:

http://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?wsdl&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.

Risk Analysis and Remediation

Management of Internal Controls

August 2010 35

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

Risk Analysis and Remediation

Management of Internal Controls

36 August 2010

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:

Risk Analysis and Remediation

Defining Connectors for Risk Analysis and Remediation

August 2010 37

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 Connection Type(s)

SAP SAP JCO

Web Service

Adaptive RFC

File – Local

File - FTP

Oracle JDBC

JDBC – SLD

Web Service

Legacy File – Local

Risk Analysis and Remediation

Defining Connectors for Risk Analysis and Remediation

38 August 2010

System Type Connection Type(s)

File - FTP

PEOPLESOFT JDBC

JDBC – SLD

Web Service

JD Edwards JDBC

JDBC – SLD

Web Service

Portal Web Service

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.

Risk Analysis and Remediation

Defining Connectors for Risk Analysis and Remediation

August 2010 39

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 system‘s 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.

Risk Analysis and Remediation

Defining Connectors for Risk Analysis and Remediation

40 August 2010

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.

Risk Analysis and Remediation

Defining Connectors for Risk Analysis and Remediation

August 2010 41

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

Risk Analysis and Remediation

Logical Systems

42 August 2010

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.

Risk Analysis and Remediation

Logical Systems

August 2010 43

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 system‘s 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.

Risk Analysis and Remediation

Cross Systems

44 August 2010

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.

Risk Analysis and Remediation

Cross Systems

August 2010 45

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.

Risk Analysis and Remediation

Cross Systems

46 August 2010

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

Risk Analysis and Remediation

Cross Systems

August 2010 47

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.

Risk Analysis and Remediation

Deleting a System

48 August 2010

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

Risk Analysis and Remediation

August 2010 49

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.

Risk Analysis and Remediation

User Mapping

50 August 2010

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:

Risk Analysis and Remediation

Upload Objects

August 2010 51

CUSTOM_GROUP_A JSMITH

CUSTOM_GROUP_A TMSMITH

CUSTOM_GROUP_A RSMITH

CUSTOM_GROUP_A JJOHNSON

CUSTOM_GROUP_A BJOHNSON

CUSTOM_GROUP_B GLOPEZ

CUSTOM_GROUP_B MWASHINGTON

CUSTOM_GROUP_B KCHOW

CUSTOM_GROUP_B 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

Risk Analysis and Remediation

Rule Upload

52 August 2010

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.

Risk Analysis and Remediation

Rule Upload

August 2010 53

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.

Risk Analysis and Remediation

Rule Upload

54 August 2010

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.

Risk Analysis and Remediation

Rule Upload

August 2010 55

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.

Risk Analysis and Remediation

Back-end Synchronization (with Management of Internal Controls)

56 August 2010

Back-end Synchronization (with Management of Internal Controls)

When you integrate SAP‘s 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.

Risk Analysis and Remediation

Background Jobs

August 2010 57

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.

Risk Analysis and Remediation

Background Jobs

58 August 2010

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

Risk Analysis and Remediation

Background Jobs

August 2010 59

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.

Risk Analysis and Remediation

Background Jobs

60 August 2010

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.

Risk Analysis and Remediation

Background Jobs

August 2010 61

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.

Risk Analysis and Remediation

Organizational User Mapping

62 August 2010

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).

Risk Analysis and Remediation

Custom Tabs

August 2010 63

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 screen‘s 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

Risk Analysis and Remediation

Utilities

64 August 2010

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.

Risk Analysis and Remediation

Utilities

August 2010 65

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 cross-system definitions)

User mapping

Risk Analysis and Remediation

Configuration Change History

66 August 2010

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.

Risk Analysis and Remediation

Configuration Change History

August 2010 67

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 Field Risk Analysis < 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

Risk Analysis and Remediation

Configuration Change History

68 August 2010

Use SoD Supplementary Table for Analysis

Mitigating Controls

<Select Value>

Mitigating Controls

Workflow <Select Value >

All

Mitigating Control Maintenance

Risk Maintenance

Workflow Service URL

Miscellaneous <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

Connectors <Select Value>

All

Connection Type

JCO Destination

Outbound Connection

Report Name

SAP Gateway

System

System Name

System Type

Unicode System

Logical Systems <Select Value>

All

Logical System

Description

System

Cross Systems <Select Value>

All

Cross System

Description

System

Master User Source

<Select Value>

System

Risk Analysis and Remediation

August 2010 69

Rule Upload <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

Background Job <Select Value>

All Comment

Object Type

Object Value From

Object Value To

Status

System

Utilities <Select Value>

All

Export

Import File Location

Purge Records Older Than

Max. Records per File

Data Extractor <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

Risk Analysis and Remediation

Risk Terminator

70 August 2010

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 Purpose Setting

Select the CC release to be

used

Tells Risk Terminator what version of Risk Analysis and Remediation

is used for the SoD rules.

Set to CC5.X

RFC destination for

release CC5.X

References the RFC connection.

Enter the name of the RFC destination created previously in transaction SM59.

PFCG Plug in Determines behavior at role creation or change

with PFCG.

To have Risk Terminator checked when creating or changing roles with PFCG, set

this parameter to Yes.

PFCG User Assignment

Plug-In

Determines behavior at role assignment with

PFCG.

To have Risk Terminator checked when assigning a role to a user with PFCG, set

this parameter to Yes.

SU01 Role Assignment

Plug-In

Determines behavior at role assignment with

SU01.

To have Risk Terminator checked when assigning a role to a user with SU01, set

this parameter to Yes.

SU10 Multiple User Role

Assignment

Determines behavior at role assignment to

multiple users with SU10.

To have Risk Terminator checked when assigning roles to multiple users with

SU10, set this parameter to Yes.

Risk Analysis and Remediation

Additional Configuration Options

August 2010 71

Risk Terminator Configuration Parameters

Parameter Purpose Setting

Stop

Generation

Stops generation if service detects that a

violation exists.

To allow role generation and user assignments with SoD violations, set this

parameter to No.

Comments are Required

Determines whether comments are required when the service detects

a violation.

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.

Risk Analysis and Remediation

Additional Configuration Options

72 August 2010

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.

Risk Analysis and Remediation

Additional Configuration Options

August 2010 73

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

SAP Name Legacy Name (non-RTA system)

User User ID User ID

Action Transaction Screen

Permission Authorization Object Variable

Field Auth Object Field Not Used

Role Role Grouping

Profile Profile Not Used

Risk Analysis and Remediation

Additional Configuration Options

74 August 2010

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 Description

Target Definition User File (Required) This file includes user master information such as ID, name, email address, department, and

user group.

Target Definition User Action File

(Required)

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.

Risk Analysis and Remediation

Additional Configuration Options

August 2010 75

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)

This file identifies the actions for each profile.

Profile Permission File (Optional) 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.

Action Permission Objects 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.

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.

Risk Analysis and Remediation

Additional Configuration Options

76 August 2010

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.

Risk Analysis and Remediation

Additional Configuration Options

August 2010 77

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.

Risk Analysis and Remediation

Additional Tabs

78 August 2010

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.

Risk Analysis and Remediation

Additional Tabs

August 2010 79

You can generate reports for users, user groups, roles, profiles, HR objects, and organizational levels. Each option on the Informer tab‘s 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

Risk Analysis and Remediation

Additional Tabs

80 August 2010

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.

Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

August 2010 81

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.

Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

82 August 2010

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 Definition Authorization Values

S_RFC Authorization check for RFC

access

ACTVT = ‘16’ RFC_NAME/VIRSA/FF_UTIL_RPT

/VIRSA/ZVFAT, BAPT RFC1 SDIF SDIFRUNTIME,

SDTX SUSR SUUS SU_USER SYST SYSU RFC_TYPE =

FUGR

S_DEVELOP ACTVT 16

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

Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

August 2010 83

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 Definition Behavior

Remote Function Call

Superuser Privilege Management requires an RFC

destination to log on.

Enter the RFC destination that you created with transaction SM59.

Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

84 August 2010

Configuration Parameter Behavior

Parameter Name Definition Behavior

Retrieve Change Log

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.

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)

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.

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.

Assign FF Roles Instead

of FF IDs

This parameter switches the interface from Firefighter ID-based administration to Firefighter role-based

administration.

To use Firefighter IDs, set this parameter to No (default).

To use Firefighter roles, set this

parameter to Yes.

Default Role Expiration in

Days

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.

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.

Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

August 2010 85

Configuration Parameter Behavior

Parameter Name Definition Behavior

Auto Archive Location

Use this parameter to specify a folder for the Auto Archive

feature.

Specify the folder location where archive files are stored.

Firefighter Owner Additional

Authorization

Each Superuser Privilege Management has a defined owner. This parameter overrides

the defined owner privileges.

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.

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.

To make a comment mandatory, set this parameter to Yes.

To make a comment optional, set

this parameter to No.

Firefighter Controller Additional

Authorization

This parameter provides additional authorization to a

controller.

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.

Send Log Report with Critical Transactions

Only

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

attachment.

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.

Send Log Report Execution

Notification

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

controllers.

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.

Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

86 August 2010

Configuration Parameter Behavior

Parameter Name Definition Behavior

Send Log Report Execution Notification

Immediately

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.

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 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.

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.

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.

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:

Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

August 2010 87

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.

Superuser Privilege Management

Defining Connectors for Superuser Privilege Management

88 August 2010

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 object‘s 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

Superuser Privilege Management

Defining Connectors for Superuser Privilege Management

August 2010 89

Authorizations for S_RFC

Field Value

ACTVT 16

RFC_NAME /VIRSA/*FF*, BAPT, RFC1, SDIF, SDTX, SUSR, SUUS, SU_USER,

SYST, SYSU, SDIFRUNTIME

RFC_TYPE FUGR

Authorizations for ZFAT_0001

Field Value

ACTVT *

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.

Superuser Privilege Management

Defining Connectors for Superuser Privilege Management

90 August 2010

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 Description

Connector ID Name of the connector.

Connector Description

Description for the connector.

Application Server 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.

Superuser Privilege Management

Archived Data for Log Reports

August 2010 91

Connector Field Description

System Number The system identification number.

Client 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.

Superuser Privilege Management

Archived Data for Log Reports

92 August 2010

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.

Compliant User Provisioning

Prior to Configuration

August 2010 93

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

Compliant User Provisioning

Basic Functionality

94 August 2010

Provisioning Process

Information Description

What specific condition initiates the request?

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

does the request require?

Each organization has unique requirements for how many people must approve a user access request. In addition, some 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, who is authorized to approve

the request?

For each step in the process, determine who is responsible for approving or denying a request. This can be an individual user

or, in some cases, any one of a group of users.

What happens if any of the assigned approvers chooses

to deny the request?

Determine what action must be taken if a designated approver denies the request. This can include steps to mitigate risk, to provision only the approved portion of the request, or to abort

the provisioning process entirely.

What happens if any of the assigned approvers fail to respond to the request within a specified period of

time?

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.

Is a partial approval acceptable for the request?

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.

In the event that the request is ultimately approved, should Compliant User Provisioning automatically

initiate provisioning?

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

Compliant User Provisioning

Key Concepts

August 2010 95

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 user‘s 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 and Mitigation

The identification and mitigation of risk is a key element of provisioning. A 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.

Compliant User Provisioning

Users

96 August 2010

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 Description

Requestor 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.

Approver 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.

Compliant User Provisioning

Administration Tasks

August 2010 97

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.

Compliant User Provisioning

Preconfiguration Tasks

98 August 2010

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

Compliant User Provisioning

Preconfiguration Tasks

August 2010 99

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 company‘s 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.

Compliant User Provisioning

Initialization System Data

100 August 2010

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

Compliant User Provisioning

Configuration Tasks

August 2010 101

Append

Clean and Insert

5. The files you import are:

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.

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

Compliant User Provisioning

Configuration Tasks

102 August 2010

the connectors, you specify how Compliant User Provisioning communicates with these back-

end 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 back-end 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

Compliant User Provisioning

Configuration Tasks

August 2010 103

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 user‘s HR record, set this field to (B012) – Managers.

b. If you want the Reports to line value to be automatically populated from the user‘s HR record, set this field to (A002) – Reports (line) to (for organizational

units).

Compliant User Provisioning

Configuration Tasks

104 August 2010

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.

Compliant User Provisioning

Configuration Tasks

August 2010 105

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 Parameter Values

ASSIGN_GROUPS:OC sapgroup

ASSIGN_ROLES:OC saprole

CHANGE_USER:OC sapuser

CREATE_USER:OC sapuser

CREATE_USER:password password

DELETE_USER:OC sapuser

LOCK_USER:OC sapuser

LOCK_USER:islocked true

RESET_PASSWORD:OC sapuser

RESET_PASSWORD:password password

ROLESEARCH_URI http://<server>:<port>/UserRoleSearchForAEService_5_3/Config1?wsdl&style=document

ROLESEARCH_URI_USERNAME username

ROLESEARCH_URI_PASSWORD password

ROLE_DATA_SOURCE ROLE.UME_ROLE_PERSISTENCE.un:

SCHEMA_ID SAPprincipals

UNLOCK_USER:OC Sapuser

UNLOCK_USER:islocked false

Compliant User Provisioning

Configuration Tasks

106 August 2010

Parameter Names Parameter Values

USER_DATA_SOURCE 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.

Compliant User Provisioning

Configuration Tasks

August 2010 107

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.

Compliant User Provisioning

Configuration Tasks

108 August 2010

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 E-Directory, 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.

Compliant User Provisioning

Configuration Tasks

August 2010 109

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.

Compliant User Provisioning

Configuration Tasks

110 August 2010

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.

Compliant User Provisioning

User Data Source Definition

August 2010 111

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 user‘s 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 user‘s 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.

Compliant User Provisioning

User Data Source Definition

112 August 2010

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 user‘s 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

Compliant User Provisioning

User Data Source Definition

August 2010 113

they are searched. The system searches the systems until it finds the user ID

and retrieves the user‘s details.

Compliant User Provisioning

Field Mapping

114 August 2010

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 Manager ID Requestor LName

Business Area Manager LName Requestor Telephone

Company ManagerTelephone SNC

Cost Center Org. Unit Telephone Number

Department Personnel Number Unsecured SNC Logon

Email Address Position User End Valid Date

Functional Area Request Category User FName

Job Request Reason User ID

Location Requestor Email User LName

Manager Email Requestor FName User Start Valid Date

Manager FName Requestor ID

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.

Compliant User Provisioning

Field Mapping

August 2010 115

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 Application Field

Email Address – STANDARD email

Telephone Number –STANDARD mobile

User FName – STANDARD firstname

User ID – STANDARD logonname

User LName - STANDARD lastname

9. Click Save.

Compliant User Provisioning

Field Mapping

116 August 2010

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

enterprise‘s 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 Manager ID Org. Unit

Company Administration Group Valid To

Valid From Manager Last Name Job

Organization Functional Area Date Format

Employee Type Company Address Manager Last Name

Position LBL_SAP_User_ID LBL_Locale

Example

You can map fields in an LDAP table using F_Field to the field FirstName_Field.

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.

Compliant User Provisioning

Field Mapping

August 2010 117

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.

Compliant User Provisioning

Integrating CUP and RAR

118 August 2010

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.

Compliant User Provisioning

Request Configuration

August 2010 119

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

Compliant User Provisioning

Request Configuration

120 August 2010

Unlock

Example

If the request type is New, it relates to the creation of a new account in the SAP back-end 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.

Compliant User Provisioning

Request Configuration

August 2010 121

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

Compliant User Provisioning

Request Configuration

122 August 2010

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.

Compliant User Provisioning

Request Priority Configuration

August 2010 123

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.

Compliant User Provisioning

Application Configuration

124 August 2010

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

Compliant User Provisioning

Employee Type Configuration

August 2010 125

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 full-time 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.

Compliant User Provisioning

Number Ranges

126 August 2010

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.

Compliant User Provisioning

Authentication Source for Requestors

August 2010 127

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 100–1000 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 requestor‘s 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.

Compliant User Provisioning

Authentication Source for Requestors

128 August 2010

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 requestor‘s 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.

Compliant User Provisioning

Risk Analysis

August 2010 129

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.

o 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.

Compliant User Provisioning

Mitigation

130 August 2010

Frequently Asked Questions

Question Answer

Can you choose the rule set to perform the risk analysis from Compliant User

Provisioning?

No. The default rule set is always used to perform risk analysis from Compliant User

Provisioning.

Can you identify which SoD risk criticality levels have been assessed for a request

access?

No. All risk levels are included in the risk analysis from Compliant User Provisioning.

How does Compliant User Provisioning perform a risk analysis?

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.

What steps need to be taken if a risk

analysis fails?

For more information about how to troubleshoot issues with risk analysis, see the

SAP Notes 1136379, 1049058, 1145700, 1234807, 1085586, 1061088, 1003239, and 1166368.

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.

Compliant User Provisioning

End User Personalization

August 2010 131

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.

Compliant User Provisioning

End User Personalization

132 August 2010

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 Description Personalized Values

Action Group

Attachments The Attachments button allows users to select files and attach them to a

request.

Default Value – N/A

Mandatory – N/A

Editable – N/A

Visible – Yes/No

Cancel The Cancel button allows users to cancel a request.

Default Value - N/A

Mandatory – N/A

Editable – N/A

Visible – Yes/No

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.

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).

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.

Roles This field enables users to

add roles to a request.

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.

Compliant User Provisioning

End User Personalization

August 2010 133

Field Description Personalized Values

Action Group

Submit This button allows users to

submit a request.

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.

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

Provisioning.

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.

Request Info Group

Application (list of systems) This is the name of the application server(s) in which the requested action

is performed.

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.

Functional Area This is an organizational category associated with the

user‘s role or profile.

Default Value – Yes, you can select a value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

Priority This value determines how quickly a request is

approved.

Default Value – Yes, you can select a value.

Mandatory – N/A

Editable – Yes/No

Visible – N/A

Users cannot submit requests without this information.

Request Reason This field allows users to enter the reason for

requesting access.

Default Value – Yes, you can enter a reason.

Mandatory – N/A

Compliant User Provisioning

End User Personalization

134 August 2010

Field Description Personalized Values

Action Group

Editable – Yes/No

Visible – Yes/No

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.

Default Value – N/A

Mandatory – N/A

Editable – Yes/No

Visible – N/A

Requestor Email This is the requestor‘s email address.

Default Value – N/A

Mandatory – N/A

Editable – N/A

Visible – Yes/No

Requestor Name This is the requestor‗s name.

Default Value – N/A

Mandatory – N/A

Editable – N/A

Visible – Yes/No

Requestor Telephone This is the requestor‘s

telephone number.

Default Value – N/A

Mandatory – N/A

Editable – N/A

Visible – Yes/No

Manager Info Group

Manager Email This is the manager‗s 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.

Manager Information Lookup

This is the search icon (magnifying glass) used to launch the search feature

for manager information.

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.

Manager Name This is the manager‘s name. Default Value – N/A

Mandatory – Yes/No

Editable – Yes/Yes if data missing/No

Visible – Yes/No

Manager Telephone This is the manager‘s

telephone number.

Default Value – N/A

Mandatory – Yes/No

Editable – Yes/No

Compliant User Provisioning

End User Personalization

August 2010 135

Field Description Personalized Values

Action Group

Visible – Yes/No

User Info Group

Accounting Number It will populate the accounting number field in the Logon Data tab of the

User Master Record.

Default Value – Yes, you can select a value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

Company This is the company name associated with the user

requesting access.

Default Value – Yes, you can select a value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

Department This is the name of the department associated with

the user requesting access.

Default Value – Yes, you can enter a value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

Employee Type This is the status of the

employee in the company.

Default Value – Yes, you can select a value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

Location This is the location name associated with the user

requesting access.

Default Value – Yes, you can enter a value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

User Email Address This is the email ID of the person for whom the user is

requesting access.

Default Value – N/A

Mandatory – N/A

Editable – Yes/No

Visible – N/A

User First Name This is the first name of the person for whom the user is

requesting access.

Default Value – N/A

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

User Group It will populate the User Group for Authorization Check field in the Logon Data tab of the User Master

Record.

Default Value – Yes, you can enter a default value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

User ID This is the unique ID of the person for whom you are

requesting access.

Default Value – N/A

Mandatory – N/A

Editable – Yes/No

Visible – N/A

User Information Lookup This is the search icon (magnifying glass) used to launch the search feature

for user information.

Default Value – N/A

Mandatory – N/A

Editable – N/A

Visible – Yes/No

User Last Name This is the last name of the Default Value – N/A

Mandatory – N/A

Compliant User Provisioning

End User Personalization

136 August 2010

Field Description Personalized Values

Action Group

person for whom the user is

requesting access. Editable – Yes/No

Visible – N/A

User Telephone This is the telephone number of the user for whom the user is requesting

access.

Default Value – N/A

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

User Valid From This field indicates the validity start date for a user.

Default Value – Yes, you can enter a default value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

User Valid To This field indicates the

validity end date for a user.

Default Value – Yes, you can enter a default value.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

Self User Info Group

Self User Email Address This is the email address of the user submitting a

request.

Default Value – N/A

Mandatory – N/A

Editable – Yes/Yes, if data missing/No

Visible – N/A

Self User First Name This is the first name of the user submitting a request.

Default Value – N/A

Mandatory – Yes/No

Editable – Yes/Yes if data is missing/No

Visible – Yes/No

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

Default Value – N/A

Mandatory – N/A

Editable – Yes/Yes if data is missing/No

Visible – N/A

Self User Information Lookup

This is the search icon (magnifying glass) used to launch the search feature

for self user information.

Default Value – N/A

Mandatory – N/A

Editable – N/A

Visible – Yes/Yes if data is missing/No

Self User Last Name This is the last name of the

user submitting a request.

Default Value – N/A

Mandatory – N/A

Editable – Yes/Yes if data is missing/No

Visible – N/A

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

Compliant User Provisioning

End User Personalization

August 2010 137

Field Description Personalized Values

Action Group

that run in an ABAP environment and use SAP

GUI as the front-end client.

For more information, see SAP Note 1177556 – Compliance User Provisioning SNC Parameters.

Unsecure Logon Allowed

(SNC)

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

Default Value – Yes, you can select a value of Yes or No.

Mandatory – Yes/No

Editable – Yes/No

Visible – Yes/No

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.

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.

One User per Request per System

This allows you to restrict users to no more than one request submission for an

application.

Default Value – N/A

Mandatory – Yes/No

Editable – N/A

Visible – N/A 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.

Compliant User Provisioning

End User Personalization

138 August 2010

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.

Compliant User Provisioning

End User Personalization

August 2010 139

Frequently Asked Questions

Question Answer

Where does Compliant User Provisioning obtain a user‘s manager information?

The Access Request screen. The manager‘s 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 that searching for manager information is

from the correct data source?

Ensure that the LDAP and SAPHR connectors are correctly set up in Access Control and verify that the appropriate connector is 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.

Compliant User Provisioning

Technical Support Contact Identification

140 August 2010

Question Answer

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

field?

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 User Information configuration and Request

for Others Information configuration?

To activate the Self User Information (magnifying glass) search icon, select the Requesting for Other User checkbox when 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.

Compliant User Provisioning

Available Request Attributes

August 2010 141

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 organization‘s 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.

Compliant User Provisioning

Custom Fields

142 August 2010

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.

Compliant User Provisioning

Service Level

August 2010 143

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 Priority Condition

New High Condition 1

Change Medium 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.

Compliant User Provisioning

Workflow Management

144 August 2010

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 organization‘s 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.

Compliant User Provisioning

Workflow Management

August 2010 145

Workflow Component Elements

Element Description

Initiators 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.

Stages 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.

Paths 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.

Compliant User Provisioning

Workflow Management

146 August 2010

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 planning—determining how you want the workflow to function—that requires

some consideration.

Prerequisites

When you create a workflow, you establish your organization‘s 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 workflow‘s 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.

Compliant User Provisioning

Workflow Management

August 2010 147

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.

Compliant User Provisioning

Workflow Management

148 August 2010

Basic Workflow with Three Stages

Compliant User Provisioning

Workflow Management

August 2010 149

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 Business Process Company

Employee Type Functional Area Request Priority

Request Type

The ERM workflow type provides the following attributes:

Request Type Priority

The SOD Review workflow type provides the following attributes:

Application Priority Request Type

SoD Review Risk

The User Access Review workflow type provides the following attributes:

Application Priority Request Type

UAR Review Role

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).

Compliant User Provisioning

Workflow Management

150 August 2010

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.

Compliant User Provisioning

Workflow Management

August 2010 151

Workflow-Specific Configuration Tasks

Workflow-Specific Configuration Task

Description

Custom Approver

Determinators

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 organization‘s 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.

Compliant User Provisioning

Workflow Management

152 August 2010

Workflow-Specific Configuration Tasks

Workflow-Specific Configuration Task

Description

Auto Provisioning 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.

Compliant User Provisioning

Workflow Management

August 2010 153

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.

Compliant User Provisioning

Workflow Management

154 August 2010

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.

Compliant User Provisioning

Workflow Management

August 2010 155

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 Attribute Value

OR Functional Area Finance

AND Request Type 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 Attribute Value

OR Functional Area Finance

AND Request Type New

OR Company 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.

Compliant User Provisioning

Workflow Management

156 August 2010

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 High FWilson

New Medium BLaw

New Low 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.

Compliant User Provisioning

Workflow Management

August 2010 157

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.

o 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.

Compliant User Provisioning

Workflow Management

158 August 2010

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.

Compliant User Provisioning

Workflow Management

August 2010 159

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 approver‘s 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

Compliant User Provisioning

Workflow Management

160 August 2010

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 administrator‘s 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.

Compliant User Provisioning

Workflow Management

August 2010 161

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 approver‘s 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.

Compliant User Provisioning

Workflow Management

162 August 2010

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.

Setting Result

Yes

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).

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.

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.

o 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

Compliant User Provisioning

Workflow Management

August 2010 163

example, manager and security approvers can approve or reject any role on the

request.

o Role: Approvers can only approve those roles that belong to them. This option is especially useful for role approvers.

o 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.

o 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.

o Role: Approvers can only reject those roles that belong to them. This option is

especially useful for role approvers.

o 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.

o 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.

Compliant User Provisioning

Workflow Management

164 August 2010

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.

o 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.

o 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.

o 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.

o 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:

o 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.

o 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

o 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.

o 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.

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

Compliant User Provisioning

Workflow Management

August 2010 165

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.

Compliant User Provisioning

Workflow Management

166 August 2010

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.

Compliant User Provisioning

Workflow Management

August 2010 167

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.

Compliant User Provisioning

Workflow Management

168 August 2010

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 non-SAP 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.

Compliant User Provisioning

Workflow Management

August 2010 169

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.

Compliant User Provisioning

Email Reminder and Email Notification Setup

170 August 2010

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 user‘s 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 Description

CUP Workflow for Compliant User Provisioning.

ERM Workflow for Enterprise Risk Management.

RISK Workflow for Risk Analysis and Remediation.

Compliant User Provisioning

Email Reminder and Email Notification Setup

August 2010 171

SoD Review Workflow for Segregation of Duties Review.

User Access 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 Description

CUP Workflow for Compliant User Provisioning.

ERM Workflow for Enterprise Risk Management.

RISK Workflow for Risk Analysis and Remediation.

SoD Review Workflow for Segregation of Duties Review.

User Access 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.

Compliant User Provisioning

Email Reminder and Email Notification Setup

172 August 2010

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.

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.

c. 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 user‘s 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.

Compliant User Provisioning

Email Reminder and Email Notification Setup

August 2010 173

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.

Compliant User Provisioning

Email Reminder and Email Notification Setup

174 August 2010

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 approver‘s 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.

Compliant User Provisioning

SMTP Server Identification

August 2010 175

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 application‗s

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.

Compliant User Provisioning

CUA System Setting Configuration

176 August 2010

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.

Compliant User Provisioning

CUA System Setting Configuration

August 2010 177

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 back-end 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 user‘s HR record,

set this field to (B012) – Managers.

b. If you want the Reports to line value to be automatically populated from the user‘s 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.

Compliant User Provisioning

CUA System Setting Configuration

178 August 2010

12. Click Create.

13. Click Test Connection.

Compliant User Provisioning

CUA System Setting Configuration

August 2010 179

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.

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--.

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 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.

Compliant User Provisioning

CUA System Setting Configuration

180 August 2010

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.

Compliant User Provisioning

Provisioning

August 2010 181

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.

Compliant User Provisioning

Provisioning

182 August 2010

Parameter Name Parameter Value

ASSIGN_GROUPS:OC sapgroup

USER_DATA_SOURCE See your UME system administrator for

the value of the user data source.

d. Click Create.

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 Application Field

Email Address – STANDARD email

Telephone Number –STANDARD mobile

User FName – STANDARD firstname

User ID – STANDARD logonname

User LName - STANDARD lastname

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.

Compliant User Provisioning

Provisioning

August 2010 183

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 group

GroupDescription description

GroupMember memberOf

GroupName name

USERNGROUP member

validToDate 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.

Compliant User Provisioning

Provisioning

184 August 2010

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.

Compliant User Provisioning

Auto Provisioning

August 2010 185

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 user‘s master record, changing the user‘s 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 user‘s 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 user‘s master record directly, changing the user‘s 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.

Compliant User Provisioning

Auto Provisioning

186 August 2010

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 Processing new requests.

o Changing or modifying existing requests.

o Deleting requests.

o 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 CREATE_USER and CHANGE_USER

o CREATE_USER and LOCK_USER

o CREATE_USER and UNLOCK_USER

o 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.

Compliant User Provisioning

Auto Provisioning

August 2010 187

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 user‘s 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.

Compliant User Provisioning

Approvers

188 August 2010

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.

Compliant User Provisioning

Approvers

August 2010 189

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 security‘s 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.

Compliant User Provisioning

Approvers

190 August 2010

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.

Compliant User Provisioning

Approvers

August 2010 191

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.

Compliant User Provisioning

Stale Requests

192 August 2010

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 administrator‘s 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 period‘s requests during normal viewing.

Compliant User Provisioning

Request Administration

August 2010 193

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.

Compliant User Provisioning

User Review

194 August 2010

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.

Compliant User Provisioning

User Review

August 2010 195

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 company‘s 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 Configuration

ERM You configure system connectors. This is required for transaction usage and for user-role assignment information.

RAR You configure connectors. This is required for alert generation to provide transaction usage information.

CUP 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 Access review requests are generated.

o E-mail notifications are sent to reviewers.

o Requests are reviewed and actions are noted by the reviewer.

o Roles marked for removal can be de–provisioned from the back-end system(s)

Compliant User Provisioning

User Review

196 August 2010

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.

User’s Manager: The direct manager of a user as defined in the User Details Data Source.

Role Owner: The role owner specified in CUP master data.

Reviewer: This term refers to the approver at the Reviewer stage. The Reviewer may be

the user‘s 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 User‘s 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 Application

o Request type

o 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.

Compliant User Provisioning

User Review

Page 197 of 397

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 stage‘s 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 request‘s 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 request‘s 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.

Compliant User Provisioning

User Review

198 August 2010

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.

Compliant User Provisioning

User Review

Page 199 of 397

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. In the Workflow Types pane, maintain the entry UAR_REVIEW.

c. 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.

Compliant User Provisioning

User Review

200 August 2010

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.

o 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 Manager represents the manager of the user as identified in the User Detail Data Source.

o 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 Max Field

Length

Recommendation Possible Values

ReasonCode

(required)

10

characters

All UPPER case

No special characters, no spaces

Letters and numbers

ReasonEnable n/a Have some desired value.

Yes/yes/y/YES/Y

No/no/n/NO/N ( When empty default

value No)

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

Letters and numbers

4. Under Import Rejection Reasons, click Browse.

Compliant User Provisioning

User Review

Page 201 of 397

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 organization‘s 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 user‘s 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 auto-

provisioning. 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

Compliant User Provisioning

User Review

202 August 2010

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 User’s 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.

Compliant User Provisioning

User Review

Page 203 of 397

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 Permission Included

ViewManageRejectionReasons Provides the ability to configure Rejection Reasons to be used in reviews

ViewRejectUsers Enables the Reject Users button in review requests

ViewManageRejections Provides the ability to view the Manage Rejections functionality for UAR

ManageRejectionsGenerationAction Provides the ability to generate new requests for rejected users

ManageRejectionsCancelGenerationAction

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

User‘s 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 User’s 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.

Compliant User Provisioning

User Review

204 August 2010

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.

Compliant User Provisioning

User Review

Page 205 of 397

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 user‘s 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.

Compliant User Provisioning

User Review

206 August 2010

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 user‘s 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 Possible Values Default Value

Rejection Date From Any date Current date

Rejection Date To Any date Current date

Compliant User Provisioning

User Review

Page 207 of 397

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 SOD Review

User Access Review

All

Reason Any reason code for rejecting a user. All

Status All

New

To Generate

In Process

Error

Completed

All

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.

Compliant User Provisioning

User Review

208 August 2010

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.

Compliant User Provisioning

User Review

Page 209 of 397

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 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.

o 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.

Compliant User Provisioning

User Review

210 August 2010

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

company‘s 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.

Compliant User Provisioning

User Review

Page 211 of 397

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 user‘s manager or the risk owner.

User’s 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 User’s 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

Compliant User Provisioning

User Review

212 August 2010

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.

Compliant User Provisioning

User Review

Page 213 of 397

Escalation

You decide whether to escalate SOD review requests in each stage‘s 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 request‘s 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)

Compliant User Provisioning

User Review

214 August 2010

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.

Compliant User Provisioning

User Review

Page 215 of 397

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.

Compliant User Provisioning

User Review

216 August 2010

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. In the Workflow Types pane, maintain the entry SOD_REVIEW.

3. 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.

Compliant User Provisioning

User Review

Page 217 of 397

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 Max Field

Length

Recommendation Possible Values

ReasonCode

(required)

10

characters

All UPPER case

No special characters, no

spaces

Letters and numbers

ReasonEnable n/a Have some desired value. 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.

Compliant User Provisioning

User Review

218 August 2010

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.

o 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.

Compliant User Provisioning

User Review

Page 219 of 397

9. Configure workflow

You can configure an SOD review workflow based on your organization‘s 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 whether the stage approver can indicate actions for

request items

Reject Users whether the Reject User button will be accessible (Appropriate UME authorizations are also required

to utilize the reject feature)

Approval Type whether the stage approver sees all request items

Display Review Screen whether the review screen is shown after submission of the request. Recommendation is No as this screen is redundant for SOD Review

requests.

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 user‘s 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 User’s Manager or a Risk Owner. Access Control uses the coordinator information to generate

reports that can be used while managing the review process.

Compliant User Provisioning

User Review

220 August 2010

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 Description

Version 5.3 Web Service

URI http://<server>:<port>/VirsaCCRiskAnalysisService/Config1?wsdl&style=document

User Name The authorized account CUP uses to log on to RAR.

Password The authorized account CUP uses to log on to RAR.

Perform Org.

Rule

Analysis

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 Description

Allow Approvers to approve access, despite any

conflicts

Select this indicator if your process allows provisioning despite the provisioning introducing risk violations.

Default Duration (Days) for the Mitigation

Control

The default number of days the mitigating control assignment is effective.

Mitigation

URI

http://<server>:<port>/VirsaCCMitigation5_0Service/Config1?wsdl&style=document

Risk Search URL http:// <server>:<port>/VirsaCCRisk5_0Service/Config1?wsdl&style=document

Org. Rule Search URI

http:// <server>:<port>/VirsaCCOrgRules5_3Service/Config1?wsdl&style=document

Function Search URI http:// <server>:<port>/VirsaCCFunction5_0Service/Config1?wsdl&style=document

These are the addresses for the RAR web services.

Compliant User Provisioning

User Review

Page 221 of 397

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 User’s

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.

Compliant User Provisioning

User Review

222 August 2010

UME Action Permission Included

ViewManageRejectionReasons Provides the ability to configure Rejection Reasons to

be used in reviews

ViewRejectUsers Enables the Reject Users button in review requests

ViewManageRejections Provides the ability to view the Manage Rejections

functionality

ManageRejectionsGenerationAction Provides the ability to generate new requests for

rejected users

ManageRejectionsCancelGenerationAction Provides the ability to cancel the generation of new

requests for rejected users

Compliant User Provisioning

User Review

Page 223 of 397

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 User‘s 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 User’s 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.

Compliant User Provisioning

User Review

224 August 2010

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. Cancel selected SOD review requests.

2. Choose Yes when asked if the users should be considered as rejected users.

3. Maintain source data.(Ensure you have maintained the reviewers).

4. 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

Compliant User Provisioning

User Review

Page 225 of 397

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.

Compliant User Provisioning

User Review

226 August 2010

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

Compliant User Provisioning

User Review

Page 227 of 397

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 Possible Values Default Value

Rejection Date From Any date 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 SOD Review

User Access Review

All

Reason Any reason code for rejecting a user. All

Status All

New

To Generate

In Process

Error

Completed

All

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.

Compliant User Provisioning

User Review

228 August 2010

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.

Compliant User Provisioning

User Review

Page 229 of 397

Options

You configure review parameters for both SoD and user access reviews.

Option Description

Admin. review required before sending tasks to reviewers

Choose whether to require admin review before request is forwarded to reviewers.

Who are the reviewers Select the role to perform the review.

SoD Review Users URI Define the URI for the Web service that retrieves User IDs.

http://<server>:<port>/VirsaCCSODViolatedUsersWS/ConfigVirsaCCSODViolatedUsers?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/configVirsaCCSODViolationsWS?wsdl&style=document

Number of line items per request

Choose the number of items to display per request.

Default request type If you have configured multiple request types, choose the type you want as default.

Default priority Choose the default priority for user access reviews.

Enter URL for SoD review instructions

Enter the URL for the location of the SoD review instructions html page.

Enter URL for UAR

instructions

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.

Compliant User Provisioning

User Review

230 August 2010

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.

Compliant User Provisioning

User Review

Page 231 of 397

Request Review

Administrators can review requests, and choose to cancel them or change the user-to-manager 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 Description

Change 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 Possible Values Default Value

Rejection Date From Any date 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 SOD Review

User Access Review

All

Reason Any reason code for rejecting a All

Compliant User Provisioning

User Review

232 August 2010

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 Description

User You can sort the users by the User IDs.

Workflow Type

This column displays the related workflow type: SOD Review or User

Access Review.

Rejection Date This column displays the date the user is rejected.

Status 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.

Reason This column displays the reason a user was rejected from the request.

Original

Request

The column displays the original request number and request status for

the rejected user.

New Request The column displays the new request number and status for the

rejected user.

Compliant User Provisioning

User Review

Page 233 of 397

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.

Compliant User Provisioning

User Review

234 August 2010

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 Max Field

Length

Recommendation Possible Values

ReasonCode (required)

10 characters

All UPPER case

No special characters, no spaces

Letters and numbers

ReasonEnable n/a Have some desired value. 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

Compliant User Provisioning

User Review

Page 235 of 397

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 Description

Role critical level 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.

Role name Generate reviews for these specific roles.

Exclude roles Exclude these roles when generating reviews.

Function area Generate reviews for roles in this specific function area.

Note

You must ensure the function area values in ERM and CUP are

consistent.

Users Generate reviews for these specific users.

Exclude users Exclude these users when generating reviews.

User group Generate reviews for roles of a specific SU01 logon user group.

System Generate reviews for roles from a specific system.

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.

Compliant User Provisioning

User Review

236 August 2010

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.

Compliant User Provisioning

Change Log

Page 237 of 397

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 Description

Change Log ID This is the log identifier. Example: Change Log ID 200

Object Name This is the object that has been changed. Example: Connector Configuration.

Object Value This is the value that has been modified for the object.

Example: QF8600 is a system name.

Action This is the type of action performed for the Object Name.

Example: New.

Changed by This is the person responsible for making the change.

Example: BLAW

Change Log Time This is the date and time that the change was made.

Example: 10/07/2008 19:17:21

Field Name This is the name of the field that was touched. Example: Is Active

Old Value This is the field‘s old value.

Example: true.

New Value This is the field‘s new value.

Example: false

Action This is the type of action performed in the field name.

Example: Modified.

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.

Compliant User Provisioning

Roles

238 August 2010

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 imported/added to Compliant User Provisioning? Can a requestor still

select that role and add it to a request?

No. You must import the role first.

Compliant User Provisioning

Roles

Page 239 of 397

Question Answer

Can a role be deleted from a user after it is assigned?

Compliant User Provisioning can delete roles from users within a workflow that has a request type 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 have to import it again to synchronize

Compliant User Provisioning with SAP?

No. If you delete a role in the SAP system and then import roles into CUP, the role reference remains in

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.

Compliant User Provisioning

Roles

240 August 2010

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 Description

All Roles 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

Imports all roles except any predefined roles in the specified SAP system.

Selected Roles 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.

From File 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.

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.

Compliant User Provisioning

Roles

Page 241 of 397

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.

Compliant User Provisioning

Roles

242 August 2010

Role Import/Export Template Details

The following table describes the items in the import template spreadsheet.

Role Import Template Spreadsheet

Role Import Column Description Mandatory Case-

Sensitive

Connector Type Name of the connector type. Only one connector type is allowed.

Yes Yes – upper case

letters

RoleName Technical name of the role. Yes Yes

Type Select Single or Composite. Only one value is allowed.

Yes No

Last Reaffirm Date Date of the role‘s last reaffirm. Required format is MM/DD/YY.

Yes MM/DD/YY

System 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.

Yes, at least one system is

required

Yes, upper case

letters

RoleApprover User ID of the role‘s 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.

No No

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.

Yes – at least one functional area is

required

Yes

Company 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

Yes – at least one Company is

required

Yes

RoleProfileIndicator Options are either Role or Profile. Yes No

Compliant User Provisioning

Roles

Page 243 of 397

Role Import Template Spreadsheet

Role Import Column Description Mandatory Case-Sensitive

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.

Yes – use a zero if not using this

functionality

N/A

Comments

Mandatory

Options are Yes or No. Yes Yes – use upper case letters Yes or mixed

Yes.

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 Choose No if not using this

functionality

No

Description_de German short description. Required only if your users want to use Access Control in

German.

No No

DetailDescription_de German detailed description. Required only if your users want to use Access Control in

German.

No No

Description_hu Hungarian short description. Required only if 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.

No No

Description_ja Japanese short description. Required only if 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.

No No

Description_it Italian short description. Required only if your users want to use Access Control in

Italian.

No No

DetailDescription_it Italian detailed description. Required only if your users want to use Access Control in

Italian.

No No

Compliant User Provisioning

Roles

244 August 2010

Role Import Template Spreadsheet

Role Import Column Description Mandatory Case-Sensitive

Description_ es Spanish short description. Required only if your users want to use Access Control in

Spanish.

No No

DetailDescription_es Spanish detailed description. Required only if your users want to use Access Control in

Spanish.

No No

Description_pt Portuguese short description. Required only 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.

No No

Description_en English short description. Required only if your users want to use Access Control in

English.

No No

DetailDescription_en English detailed description. Required only if your users want to use Access Control in

English.

No No

Description_fr French short description. Required only if your users want to use Access Control in

French.

No No

DetailDescription_fr French detailed description. Required only if your users want to use Access Control in

French.

No No

BusinessProcess The technical name of the business process, which must exist in the system before the role is uploaded successfully. Only one

business process is allowed per role.

Yes Yes – use upper case

letters

Subprocess 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 Yes, use upper case

letters

CriticalLevel Options are Critical, High, Medium, and Low. Yes No, suggest using mixed case letters as displayed in the description

column

Compliant User Provisioning

Roles

Page 245 of 397

Role Import Template Spreadsheet

Role Import Column Description Mandatory Case-Sensitive

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.

Yes N/A – enter a

number

Custom Attributes (Custom Fields for

the Role)

This column contains all custom role attributes for the role.

No N/A

Verification Training

System

This column contains all system name for

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.

Compliant User Provisioning

Roles

246 August 2010

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 None

o Actual End Date

Compliant User Provisioning

Roles

Page 247 of 397

o Maximum Duration of Assignment

c. 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 icon to add a functional area to associate with this

new role.

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.

Compliant User Provisioning

Roles

248 August 2010

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 Description

Role Name 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

Enter the role description you want to find.

System Enter the SAP system name where the role you want to find resides.

Business Process

Enter the business process associated with the role you want to find.

Subprocess 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.

Compliant User Provisioning

Roles

Page 249 of 397

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.

3. In the Access Requestor group, select one of the following settings:

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.

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.

Compliant User Provisioning

Roles

250 August 2010

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.

Compliant User Provisioning

Roles

Page 251 of 397

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.

Compliant User Provisioning

Roles

252 August 2010

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 role‘s 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.

Compliant User Provisioning

Roles

Page 253 of 397

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.

Compliant User Provisioning

Roles

254 August 2010

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 Description

Company 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.

Compliant User Provisioning

Roles

Page 255 of 397

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.

Business Process

Suggested definition: The process of the actual work, such as accounting.

Business process is required at the role level.

Business

Subprocess

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.

Functional Area and Company

The name of the approver for the organization for the combination of functional 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 company‘s 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.

Compliant User Provisioning

Roles

256 August 2010

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.

Compliant User Provisioning

Roles

Page 257 of 397

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.

Compliant User Provisioning

Roles

258 August 2010

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.

Compliant User Provisioning

Roles

Page 259 of 397

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.

Compliant User Provisioning

Roles

260 August 2010

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.

Compliant User Provisioning

Roles

Page 261 of 397

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.

Compliant User Provisioning

262 August 2010

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.

Compliant User Provisioning

Role Reaffirmation

Page 263 of 397

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.

Compliant User Provisioning

Background Jobs

264 August 2010

Background Jobs

You use background jobs to run selected tasks. SAP delivers the following Background Jobs for Compliant User Provisioning:

Background Job Description

Email Reminder Send reminder for all non SoD or UAR requests that are inactive for the configured number of days.

Email Reminder for SoD Review Send reminder for SoD requests that are inactive for the configured number of days.

Email Reminder for UAR Send reminder for UAR requests that are inactive for

the configured number of days.

Escalation Create escalation workflow for all requests that are

past the configured escalation threshold days.

HR Triggers Create requests from the HR system user data.

HR Triggers Load Data Extract user data from HR system and load into CUP.

Role Reaffirm Notification Send notification to persons whose roles are flagged

as removed.

SoD Review Load Data with

Mitigated Risks

Extract data from RAR batch risk analysis data, load into CUP, and create requests. Include items with

mitigated risks.

SoD Review Load Data without Mitigated Risks

Extract data from RAR batch risk analysis data, load into CUP, and create requests. Include only items

without mitigated risks.

SoD Review Process Rejected Send requests that are rejected and flagged for regeneration.

SoD Review Update Workflow If Admin Review Required is mandatory, move request to next reviewer in workflow.

Stale Requests Close all Stale requests.

For more information, see Stale Requests.

UAR Review Load Data Extract user and role information from ERM.

UAR Review Process Rejected Process all requests flagged as rejected.

UAR Review Update Workflow 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.

Compliant User Provisioning

Background Jobs

Page 265 of 397

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 Description

Run Run the job immediately; ignore the start date.

Activate Enable the job; run it per the start date.

Save Save the configuration information; do not activate it.

Display Schedule 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.

Compliant User Provisioning

User Default Management

266 August 2010

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 Default System

You must select an SAP back-end system to act as the default system where 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 Default Mapping

Use this option to create, change, or activate/deactivate the user default. For 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.

Compliant User Provisioning

User Default Management

Page 267 of 397

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 icon to add a parameter and its value.

You can add multiple parameters.

16. Click Save.

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.

Compliant User Provisioning

User Default Management

268 August 2010

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.

Compliant User Provisioning

Attachments

Page 269 of 397

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 user‘s access history to applications with that user‘s 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.

Compliant User Provisioning

HR Trigger

270 August 2010

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.

Compliant User Provisioning

HR Trigger

Page 271 of 397

3. Configure actions.

4. Configure rules.

5. Configure provisioning.

6. Schedule background jobs.

Compliant User Provisioning

HR Trigger

272 August 2010

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. Select the Configuration tab. In the left navigation pane, select Workflow.

2. Create an initiator.

3. Create a customer approver determinator.

4. 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.

Compliant User Provisioning

HR Trigger

Page 273 of 397

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.

Parameter ID Choose whether to update this field with changed data when the user is provisioned. Parameter Ids are fetched from CUP User Defaults.

Default Choose whether the SU01 User Defaults is for provisioning. Values are fetched from the CUP User default.

User Group Choose whether to update the User Group field [User Group, User Group Name]. This updates the user Group tab in SU01.

Compliant User Provisioning

HR Trigger

274 August 2010

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 icon. The table becomes active.

b. 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.

Compliant User Provisioning

HR Trigger

Page 275 of 397

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 today‘s date.

o If you enter 3 in days, then the role‘s 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.

Compliant User Provisioning

Password Self Service

276 August 2010

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.

Compliant User Provisioning

Password Self Service

Page 277 of 397

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 user‘s 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.

Compliant User Provisioning

Password Self Service

278 August 2010

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.

Compliant User Provisioning

Password Self Service

Page 279 of 397

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 Self-

Service). 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

Compliant User Provisioning

Miscellaneous Configuration

280 August 2010

User Registration

All users who have registered for Password Self-Service are available for searches and are displayed on this screen. Once searched, the user‘s 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 user‘s 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 re-register 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

Compliant User Provisioning

Miscellaneous Configuration

Page 281 of 397

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=document

Compliant User Provisioning

Miscellaneous Configuration

282 August 2010

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.

Enterprise Role Management

Configuring Enterprise Role Management

Page 283 of 397

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.

Enterprise Role Management

Initial System Data Importation

284 August 2010

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.

Enterprise Role Management

Managing Background Jobs

Page 285 of 397

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 Org Value Sync: This job synchronizes the organizational values in Enterprise Role Management with the SAP ERP back-end system.

o Transaction/Object/Field Sync: This job synchronizes the Transaction, Object, and Field

values with the SAP back-end system.

o 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 job‘s 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

Enterprise Role Management

Managing Background Jobs

286 August 2010

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.

Enterprise Role Management

Managing Background Jobs

Page 287 of 397

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.

Enterprise Role Management

Configuring Risk Analysis Integration with RAR

288 August 2010

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.

Enterprise Role Management

Configuring Workflow Integration with CUP

Page 289 of 397

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

Enterprise Role Management

Configuring Workflow Integration with CUP

290 August 2010

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.

Enterprise Role Management

Configuring Workflow Integration with CUP

Page 291 of 397

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.

Enterprise Role Management

System Landscape Definition

292 August 2010

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.

Enterprise Role Management

Defining Connectors for Enterprise Role Management

Page 293 of 397

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.

Enterprise Role Management

Defining Connectors for Enterprise Role Management

294 August 2010

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.

Enterprise Role Management

Defining Connectors for Enterprise Role Management

Page 295 of 397

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.

Enterprise Role Management

Defining Connectors for Enterprise Role Management

296 August 2010

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.

Enterprise Role Management

Role Designer

Page 297 of 397

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

Enterprise Role Management

Role Designer

298 August 2010

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 role‘s 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.

Enterprise Role Management

Role Designer

Page 299 of 397

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.

Enterprise Role Management

Role Designer

300 August 2010

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.

Enterprise Role Management

Role Designer

Page 301 of 397

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.

Enterprise Role Management

Role Designer

302 August 2010

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:

Enterprise Role Management

Role Designer

Page 303 of 397

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.

Enterprise Role Management

Role Designer

304 August 2010

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 If you select SAP, you can select a Source System and enter both a Table Name and a Field Name.

o 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 Date

o Numeric

o 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.

Enterprise Role Management

Role Designer

Page 305 of 397

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 organization‘s 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:

Enterprise Role Management

Role Status

306 August 2010

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.

Enterprise Role Management

Managing Condition Groups

Page 307 of 397

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.

Enterprise Role Management

Role Creation Methodology Setup

308 August 2010

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 group‘s 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

Enterprise Role Management

Role Creation Methodology Setup

Page 309 of 397

Management is delivered with the predefined role methodology process Virsa Default Process. You can also configure your own role creation process according to your organization‘s

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.

Enterprise Role Management

Role Creation Methodology Setup

310 August 2010

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 Description

Approval of a Role 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

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.

Saving Role

Definition

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

This action is triggered when you want to maintain the authorization data

for the role.

Saving Role Derivation

This action is triggered when you want to maintain the role derivation data.

Enterprise Role Management

Role Creation Methodology Setup

Page 311 of 397

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.

Enterprise Role Management

Role Creation Methodology Setup

312 August 2010

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.

Enterprise Role Management

Managing the Workflow

Page 313 of 397

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.

Enterprise Role Management

Managing the Workflow

314 August 2010

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 icon.

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 icon.

17. Click Save.

The Approval Criteria Values screen displays the Approver and Alternate Approver for the selected condition attributes.

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.

Enterprise Role Management

Managing Naming Conventions

Page 315 of 397

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.

Enterprise Role Management

Managing Naming Conventions

316 August 2010

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.

Enterprise Role Management

Managing Organizational Value Mapping

Page 317 of 397

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.

Enterprise Role Management

Managing Organizational Value Mapping

318 August 2010

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.

Enterprise Role Management

Managing Organizational Value Mapping

Page 319 of 397

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.

Enterprise Role Management

System Logs

320 August 2010

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.

Enterprise Role Management

Transaction Import

Page 321 of 397

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:

o Business Process

o Sub-Process

o Project/Release.

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 FINANCE ACCOUNTS_PAYABLE ALPHA_RELEASE

Z_AP_CLERK FINANCE ACCOUNTS_RECEIVABLE 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:

Enterprise Role Management

Transaction Import

322 August 2010

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.

Enterprise Role Management

Transaction Import

Page 323 of 397

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 today‘s 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.

Enterprise Role Management

Approving Roles During Mass Maintenance

324 August 2010

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 Definition Example

System (Name) Alphanumeric (20) QF6

User (ID) Alphanumeric (40) Tchard1

First Name Alphanumeric (50) Tom

Last Name Alphanumeric (50) Chard

Role (Name) Alphanumeric (100) Z_AP_Payable

Execution Count Numeric Number of times that the role was used.

Last Executed Date (MM/DD/YYYY) 08/27/2008

Expired Numeric (1= expired, otherwise leave blank.

Blank= not expired.)

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 pop‐up 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.

Enterprise Role Management

Importing and Exporting Configuration Settings

Page 325 of 397

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.

Enterprise Role Management

Miscellaneous

326 August 2010

Miscellaneous

This section describes the configuration options available on the Miscellaneous tab.

Option Description

Conduct Risk Analysis Before Role

Generation

Choose whether risk analysis is required before role generation. If you set this configuration to No, roles can be generated without risk analysis.

Allow Role Generation With Violations 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.

Allow Role Generation on Multiple Systems Configure whether the role can be generated on multiple systems.

Use Logged On User Credentials for Role Generation

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.

Analysis Type 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.

Web Service Info. for CC Risk Analysis Set the Web service URL for risk analysis.

Web Service Info. for CC Transaction Usage

Set the Web service URL for transaction usage.

Web Service Info. for CC Mitigation Control Set Web service URL for Mitigation Control.

Web Service Info. for CC Functions

Set the Web service URL for Functions.

Web Service Info. for AE Workflow Set the Web service URL for the role approval workflow.

Allow Editing Org. Level Values For Derived Roles

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.

Allows You to Add a Function to

Authorizations

If you set this option to Yes, it adds authorization data by retrieving a function

from Risk Analysis and Remediation.

Enterprise Role Management

Miscellaneous

Page 327 of 397

Option Description

Add Objects To a Role 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.

Ticket Number After Authorization Data Changes

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.

Allow Editing Role Authorizations in PFCG 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.

Upload Directory Set a default folder for all the files uploaded

from Enterprise Role Management.

Log Level Allows you to configure the log level.

Default Language Set the default language.

Number of Concurrent Background Jobs Limits the number of background jobs that

can be run concurrently.

Allows You to Attach Files to Role Definition

Enables attaching files to a role, and allows you to limit the attachment file size (in KBs).

Allow Role Deletion from Backend This option allows you to delete the selected roles from both the front end and back end

of SAP systems.

Include User Type in Role Usage Synchronization

Indicate the types of users that are included in Role Usage Synchronization and,

therefore, in User Access Review requests.

Exclude Locked Users with Lock Codes for Role Usage Synchronization

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)

Enterprise Role Management

Mass Role Import

328 August 2010

Option Description

Exclude Expired Users for Role Usage

Synchronization

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

Enterprise Role Management

Role Usage Synchronization

Page 329 of 397

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.

Enterprise Role Management

Role Usage Synchronization

330 August 2010

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.

Custom Reports (Data Mart)

Role Usage Synchronization

Page 331 of 397

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.

Role Usage Synchronization

332 August 2010

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.

Access Control and Identity Manager Integration

Role Usage Synchronization

Page 333 of 397

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.

Access Control and Identity Manager Integration

Calling Web Services

334 August 2010

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

Access Control and Identity Manager Integration

Calling Web Services

Page 335 of 397

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.

Access Control and Identity Manager Integration

Calling Web Services

336 August 2010

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.

Access Control and Identity Manager Integration

Access Control and IdM System Integration Architecture

Page 337 of 397

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.

Access Control and Identity Manager Integration

Access Control and IdM System Integration Architecture

338 August 2010

Available Web Services

The IdM system can call the following Web services on the Access Control system:

Name Technical Name Description

Select Applications SAPGRC_AC_IDM_SELECTAPPLICATION This Web service returns a list of resources that are configured in Access Control

Search Roles SAPGRC_AC_IDM_SEARCHROLES 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.

Role Details SAPGRC_AC_IDM_ROLEDETAILS) This Web service provides detailed information about the selected

role.

Role Details version 1.1 SAPGRC_AC_IDM_ROLEDETAILS_V1_1 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.

Request Details SAPGRC_AC_IDM_REQUESTDETAILS 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)

Access Control and Identity Manager Integration

Access Control and IdM System Integration Architecture

Page 339 of 397

Name Technical Name Description

Risk Analysis (Risks Identified and Mitigated)

Request Information (Request ID, Priority, Application, Roles)

Submit Request (to Access

Control)

SAPGRC_AC_IDM_SUBMITREQUEST You use this Web service from the IdM system for compliant

provisioning to Access Control.

Risk Analysis SAPGRC_AC_IDM_RISKANALYSIS This Web service enables you to perform Segregation of Duties

(SoD) analysis. It returns any possible risk violations.

Audit Trail (includes the

Provisioning Log Web service)

SAPGRC_AC_IDM_AUDITTRAIL 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.

Request Status SAPGRC_AC_IDM_REQUESTSTATUS This Web service returns the status and detailed request information for the selected request.

Access Control and Identity Manager Integration

Access Control and IdM System Integration Architecture

340 August 2010

Access Control Web Services calls to IdM

Name Technical Name Description

Submit Request to IdM SAPGRC_AC_IDM_SUBMITREQUEST_TO_IDM 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).

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 341 of 397

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 non-

ERP resources are configured in Access Control.

Function/Method

getSystems (test.types.p2.GetSystems parameters)

Input Parameters

Field Description Possible Value(s)/Example

System Type The resources are categorized by Production, Non-Production,

QA, Test, and so on.

The default is All.

Example: Development, Production, Non-Production, QA,

Test, etc.

Application Type The resource type indicates whether the server is an SAP

system or a non-SAP system.

The default is All.

Example: SAP, Oracle, etc.

Locale The language in which the information is to be returned.

The default is EN.

Output Parameters

Field Example

System ID Q5F

Description Q5F Dev System

System Category Development

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

342 August 2010

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 Description Possible Value(s)/Example

Application * The name of the application server that has the given role

information.

There is no default.

Example: VA6

Access Type * 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.

There is no default.

Possible Values:

Roles

Transaction

CreateAccount

Business Process The name of the business process which is used for the

role search.

The default is All.

Example: Finance

Sub Process (Sub Process for the selected Business

Process)

The name of the business subprocess which is used for

the role search.

The default is All.

Example: Account Payable

Role Name The name of the role used for the role search.

The default is All.

Example: Z_AP_Accountant

Role/Profile Description The description of the role name used for the role

search.

The default is All.

Example: Accountant Role

Functional Area The functional area of the

role used for the role search.

The default is All.

Example: Finance Payables

Company (Name) The company name of the role used for the role search.

The default is All.

Example: SAP

Transaction

(Applicable for Access Type > Transaction Code only)

The transaction code of the The default is All.

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 343 of 397

Field Description Possible Value(s)/Example

user is entered in this parameter if roles are searched using transaction

code.

Example: FB01

User Info Group

(Applicable for Access Type > Create Account Like only)

User ID The ID of the user whose roles are displayed.

There is no default.

Example: CPerkins

Applicable for all Access Types

Locale The language in which the

information is returned.

The default is EN.

Hit Count The count of the role information retrieved at a

time.

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 Example

Application VA6

Role Name Z_AP_CLERK

Role Type Single

Role Description Role Z_AP_CLERK

Valid From not applicable

Valid To not applicable

Lead Owner Brian Law

The Valid From and Valid To fields are empty. They appear in the user interface, but are not used.

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

344 August 2010

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 Description Possible Value(s)/Example

Role/Profile Name * The name of the Role/Profile whose details are returned.

There is no default.

Example: Z_AP_Accountant

System The name of application server that has the given role

information.

The default is All.

Example: CRM

Locale The language in which the

information is returned.

The default is EN.

Example: EN, DE, JA, ES, FR, PT, IT, HU, ZH, RU, KO, PL

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 Example

Role Name Z_AP_Accountant

Role Type Single

Role Description Role Z_AP_Accountant

Detail Description Accountant Role

Business Process Finance

Sub Process Account Payable

Critical Level HIGH

Reaffirm Period 0

Last Reaffirm Date 05/05/2009

List

System

CRM

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 345 of 397

Field Example

List

Role Approver

Alternate Approver

Brian Law

Cheryl Jones

List

Functional Area

Finance Payables

List

Company

SAP

List

Functional Area and

Company Approver

Mark Horsten

List

Transaction Code

F-02

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

346 August 2010

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 Example

List Custom Field

Name

Value

GROUP_TYPE

Finance

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 347 of 397

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 Field Description Possible Value(s)/Example

Request Id* Request number Example: 1854

Locale The language in which the information is returned.

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.

Output Parameters Field Example

Request Id 1854

User Name May Wong [MWONG]

Email [email protected]

Requestor Name Calvin Klein [CKLEIN]

Email [email protected]

Manager Name Calvin Klein [CKLEIN]

Email [email protected]

Approval Due date 12/31/9999

Request Status Open

Request Type Change Type

Priority HIGH

List Application

AR2 - GTS

Valid From 3/9/2009

Valid To 12/31/2500

List System

QF7

List

Role

System

Type

Description

Approver

Valid From

VS::GTS_MASTER_DATA_MAINTAIN

AR2 – GTS

Single

GTS Master Data Maintenance

CPERKINS

3/9/2009

12/31/9999

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

348 August 2010

Field Example

Valid To

Action

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

Current Stage Name Manager

List

Approver Name

Approver Status

Brian Law Approved

Next Stage Role Owner

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 349 of 397

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 Description Possible Value(s)/Example

Request Type * Refers to existing configured request types in the Compliant User Provisioning. It is used to determine what actions are performed to process the

request.

There is no default.

Example: NEW, CHANGE, DELETE, LOCK, UNLOCK,

and so on.

Priority * Indicates the severity of the submitted request.

The default is HIGH.

Example: HIGH, MEDIUM,

LOW

Applications * The name of the target

application server.

You can include multiple applications by listing them with commas, such as

VA6, QA6.

There is no default.

Example: CRM

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.

There is no default.

Example: mwong

User Name * (First Name

and Last Name) The name of the person for whom you are requesting

access.

There is no default.

Example: Mae Wong

Email * The e-mail address of the person for whom you are requesting access.

There is no default.

Example: [email protected]

Telephone Number The telephone number of the user for whom you are

requesting access.

There is no default.

Example: 16501367006

Department The department of the user for whom you are

requesting access.

There is no default.

Example: Accounting

Location The location of the user for There is no default.

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

350 August 2010

Field Description Possible Value(s)/Example

whom you are requesting

access. Example: Palo Alto

Company The company name of the person for whom you are

requesting access.

There is no default.

Example: SAP

Employee Type This is the status of the employee in the company.

There is no default.

Example: NEW

Requestor Info Group (these parameters must match the existing data in the target

authentication system)

Requestor ID * The unique ID of the user who is submitting the

request.

There is no default.

Example: sjones

Requestor Email * The e-mail address of the user who is submitting the request.

There is no default.

Example: [email protected]

Requestor Name * The name of the person who is submitting the

request.

There is no default.

Example: Sandra Jones

Telephone Number The telephone number of the person who is

submitting the request.

There is no default.

Example: 16505551212

Manager Info Group (these parameters must match the existing data in the target

authentication system)

Manager ID *

The Manager ID parameter is mandatory only if the workflow pathos at the Manager stage.

The unique ID of the manager of the user who is

submitting the request.

There is no default.

Example: BFAUST

Manager Name (First

Name and Last Name) The name of the manager of the user who is

submitting the request.

There is no default.

Example: Bill Faust

Manager Email The e-mail address of the manager of the user who is

submitting the request.

There is no default.

Example: [email protected]

Manager Telephone This is the manager‘s telephone number.

There is no default.

Example: 650 847-2000

Request Reason The reason for requesting access is entered in this

field.

There is no default.

Example: New employee

SNC Name This parameter is the name of the Secure Network

Example:

CN=I801018, 0=SAP-

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 351 of 397

Field Description Possible Value(s)/Example

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.

AG,C=DE

unsecurelogon If this field is set to True, the user can log on without having a default SNC

name for authentication.

Example:

True/False

validfrom This field indicates the validity start date for a

user.

Example:

07/03/2009

validto This field indicates the

validity end date for a user

Example:

09/05/2020

Role Info Group (retrieves other details from Search Role Web service)

System ID The name of the application server that contains the role

information.

There is no default.

Example: VA6

Role ID The role ID of the submitted request.

There is no default.

Example: Z_AP_Clerks

Add/Remove Action This determines what action is performed for the role (for example, add or remove the role for the

user)

Example: ADD, REMOVE,

KEEP

Valid From This indicates the role validity start date for a user. The date when the user can start using the

role.

Example: 07/03/2009

Valid To This indicates the role validity end date for a user. The date when the user

can no longer use the role.

Example: 09/05/2020

Custom Fields Info Group

Field Name The name of the additional custom field defined by

your corporate policy.

There is no default.

Example: Region

Value The value of the corresponding additional custom field defined by

your corporate policy.

There is no default.

Example: EMEA

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

352 August 2010

Parameters marked with an asterisk (*) are required fields. The Web service fails if the

correct value is not entered.

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 353 of 397

Output Parameters

Field Example

Request Number 1001

Status Open

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

354 August 2010

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 Description Possible Value(s)/Example

Request ID * The unique identification number of an existing

request.

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.

There is no default.

Example: mwong

System * The name of the application server where risk analysis is

executed.

There is no default.

Example: CRM

Locale The language in which the information is returned.

The default is EN.

Example: EN, DE, JA, ES, FR, PT, IT, HU, ZH, RU, KO, PL.

Parameters marked with an asterisk (*) are required fields. The Web service fails if the

correct value is not entered.

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 355 of 397

Output Parameters

Field Example

TCodeDetails

Role Description

System

Transaction code

description

Transaction code ID

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

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

356 August 2010

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 request‘s 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 Description Possible Value(s)/Example

Request ID The unique identification number of existing request.

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.

Example : mwong

User First Name The first name of the user for which audit information is

retrieved.

Example: Mae

User Last Name The last name of the user for which audit information is

retrieved.

Example: Wong

From Date The starting date when the audit information is retrieved.

Example: 05/03/2008

To Date The end date when the audit information is retrieved.

Example : 05/22/2008

Action This is the status of the request.

Possible values are: OPEN,

HOLD, REJECT, CLOSED, CANCEL.

Locale The language in which the information is returned.

The default is EN.

Possible values are: DE, JA, ES ,FR, PT, IT, HU, ZH, RU,

KO, PL.

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

Page 357 of 397

Output Parameters

The following table shows the output parameters that are part of the returned message response:

Field Example

Priority

Status

Created Date

Request ID

Submitted By

Requested By

High

OPEN

2008-05-05

1002

Sandra Jones

Sandra Jones

Request History

Path

Stage

ID

Description

Display String

User ID

Request ID

Action Date

Action Value

Dependent ID

CREATE_USER_PATH

MANAGER

3485 Note: This is the parent ID for the action

being performed.

Q5F

Request 1002 Submitted by Sandra Jones(SJONES) on 05/05/2008 02:35

MWONG

1002

05/05/2008 07:00

Z_AP_PAYABLE

3487

Note: This is the child ID for the action being

performed.

Access Control and Identity Manager Integration

Technical Definitions for Access Control IdM Web Services

358 August 2010

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 Description Possible Value(s)/Example

Request ID * The unique identification number of the submitted request whose status is

returned.

Example: 1002

Locale The language in which the

information is returned.

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 Example

Request Status

Request ID

Status

Approval Due Date

User Name

Stage

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.

Access Control and Identity Manager Integration

Integrating with an Identity Management Solution

Page 359 of 397

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:

Access Control and Identity Manager Integration

Defining Connectors for IdM Systems

360 August 2010

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:

Access Control and Identity Manager Integration

Defining Connectors for IdM Systems

Page 361 of 397

Action Map Parameter Name Parameter Value

New Account (Create User)

CREATE_USER:OC

Name of user object class defined in the IdM schema – For example, BasicUser.

Asynchronous PROV_CALL 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.

Change User CHANGE_USER:OC Name of user object class for modifying user defined in the IdM schema – For example, BasicUser.

Delete User DELETE_USER:OC Name of user object class for deleting user defined in the IdM schema – For example, BasicUser.

Lock User LOCK_USER:EXT Name of the object class /extended request for locking users defined in the IdM schema – For

example, disableUser.

Unlock User UNLOCK_USER:EXT Name of the object class /extended request for unlocking users defined in the IdM schema – For

example, enableUser.

Assign Roles ASSIGN_ROLES:OC Name of the object class /extended request for assigning role defined in the IdM schema – For

example, BasicUser.

Password Reset RESET_PASSWORD:EXT

Name of the object class /extended request for resetting user password defined in the IdM schema

– For example, resetUserPassword.

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.

Access Control and Identity Manager Integration

Defining Connectors for IdM Systems

362 August 2010

Example:

Access Control Field Application Field

Email Address - STANDARD email

User FName - STANDARD firstname

User ID – STANDARD accountId

User LName -STANDARD 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.

Access Control and Identity Manager Integration

Sending Provisioning Request to an IdM System

Page 363 of 397

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 non-

ERP 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)

Access Control and Identity Manager Integration

Sending Provisioning Request to an IdM System

364 August 2010

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>[email protected]</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>

Access Control and Identity Manager Integration

Sending Provisioning Request to an IdM System

Page 365 of 397

</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>

Access Control and Identity Manager Integration

Provisioning to Other Target Systems with SPML SOAP Compliant Call

366 August 2010

</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.

Access Control and Identity Manager Integration

Provisioning to Other Target Systems with SPML SOAP Compliant Call

Page 367 of 397

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 Parameter Name Parameter Value

New Account (Create User)

CREATE_USER:OC

Name of user object class defined in the IdM schema – For example, BasicUser.

Asynchronous PROV_CALL Async/Sync (depending upon the provisioning workflow – the default is Sync)

Change User CHANGE_USER:OC Name of user object class for modifying user defined in the IdM schema – For example, BasicUser.

Delete User DELETE_USER:OC Name of user object class for deleting user defined in the IdM schema – For example, BasicUser.

Access Control and Identity Manager Integration

Provisioning to Other Target Systems with SPML SOAP Compliant Call

368 August 2010

Action Map Parameter Name Parameter Value

Lock User LOCK_USER:EXT Name of the object class /extended request for locking users defined in the IdM schema – For example,

disableUser.

Unlock User UNLOCK_USER:EXT Name of the object class /extended request for unlocking users defined in the IdM schema – For example,

enableUser.

Assign Roles ASSIGN_ROLES:OC Name of the object class /extended request for assigning role defined in the IdM schema – For example, BasicUser.

Password Reset RESET_PASSWORD:

EXT

Name of the object class /extended request for resetting user password defined in the IdM schema – For example,

resetUserPassword.

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 Application Field

Email Address - STANDARD email

User FName - STANDARD firstname

User ID – STANDARD accountId

User LName -STANDARD 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.

Access Control and Identity Manager Integration

Provisioning to Other Target Systems with SPML SOAP Compliant Call

Page 369 of 397

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.

Access Control and Identity Manager Integration

Integration with SAP NetWeaver Identity Manager

370 August 2010

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 Value / Description

Operation SPML Add operation

DN The unique id of the entry to be added. It is stored in the mskeyvalue attribute in the Identity Store

Attributes Any set of the attributes available for the MX_PERSON. It is possible to add only person objects.

Example

SPML request

Supplied identifier: Simple User

Supplied attributes and values givenname=Simple,

sn=User,

objectclass=MX_PERSON

Access Control and Identity Manager Integration

Integration with SAP NetWeaver Identity Manager

Page 371 of 397

<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 Value / Description

Operation SPML Modify operation

DN The unique id of the entry to be modified.

Attributes 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

[email protected],

telephonenumber=+4711223344

Access Control and Identity Manager Integration

Integration with SAP NetWeaver Identity Manager

372 August 2010

<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>[email protected]</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 SPML Delete operation

Starting point 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.

Access Control and Identity Manager Integration

Integration with SAP NetWeaver Identity Manager

Page 373 of 397

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.

Access Control and Identity Manager Integration

Search Operations

374 August 2010

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 Value / Description

Operation SPML Search operation

Starting point operation= auditlog

Search type not relevant

Attributes requested *

Filter (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 Description Value

requestoperation The original update operation whose status is checked

add, modify, delete

requestuserid The user ID (mskeyvalue) of the entry which was updated

requestid The request ID for operation

taskname The name of the task that is executed as a result of the request.

taskid The ID of the task that is executed as result of the request.

operationstatus The status of the operation OK, Error, Task initiated etc.

timestamp Date/time when the status of the audit entry is updated

message Additional message about the state of the request. Typically explanatory error message is shown here

mskey mskey of the entry that was the source of the operation in question

auditid The ID of the object in the audit table

Example SPML request

Access Control and Identity Manager Integration

Search Operations

Page 375 of 397

Supplied identifier: auditlog (special IDS operation)

Supplied filter: (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>

Access Control and Identity Manager Integration

Search Operations

376 August 2010

<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 Value / Description

Operation SPML Search operation

Starting point operation=list

Search type not relevant

Attributes requested * OR any attribute subset (see available attributes below)

Filter 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 Value / Description

Operation SPML Search operation

Starting point The unique id of the entry to be listed.

Search type not relevant

Attributes requested Or any valid attribute subset

Filter (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>

Access Control and Identity Manager Integration

Search Operations

Page 377 of 397

</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="mx-

disabled"><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="mx-

disabled"><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">[email protected]</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>

Appendix A: Rule File Templates

Business Process Template

378 August 2010

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 Type Data Length

BUSINESS PROCESS ID CHAR 4

LANGUAGE CHAR 2

DESCRIPTION CHAR 120

Function Template

Functions : ALL_business_function.txt

Field Type Data Length Value Description

FUNCTION ID CHAR 8

LANGUAGE CHAR 2

DESCRIPTION CHAR 120

FUNCTION SCOPE CHAR 1 S = Single System

C = Cross System

Function-Business Process Relationship Template

Function—Business Process Relationship: ALL_function_bp.txt

Field Type Data Length

FUNCTION ID CHAR 8

BUSINESS PROCESS ID CHAR 4

Appendix A: Rule File Templates

Function-Action Relationship Template

Page 379 of 397

Function-Action Relationship Template

Function—Action Relationship: <SYSTEM>_function_action.txt

Field Type Data Length Value Description

FUNCTION ID CHAR 8

TRANSACTION CHAR 20

STATUS NUMC 1 0=ENABLED

1=DISABLED

Function-Permission Relationship Template

Function—Permission Relationship: <SYSTEM>_function_permission.txt

Field Type Data Length Value Description

FUNCTION ID CHAR 8

T-CODE CHAR 20

OBJECT CHAR 10

FIELD CHAR 10

FROM VALUE CHAR 40

TO VALUE CHAR 40

SEARCH TYPE CHAR 3 AND/OR/NOT

STATUS NUMC 1 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.

Rule Set Template

Rule Set: ALL_ruleset.txt

Field Type Data Length

RULE SET ID CHAR 8

LANGUAGE CHAR 2

RULE SET DESCRIPTION CHAR 132

Appendix A: Rule File Templates

Risk Definition Template

380 August 2010

Risk Definition Template

Risk Definition: <SYSTEM>_risks.txt

Field Type Data Length Value Description

RISK ID CHAR 4

FUNCTION 1 ID CHAR 8

FUNCTION 2 ID CHAR 8

FUNCTION 3 ID CHAR 8

FUNCTION 4 ID CHAR 8

FUNCTION 5 ID 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 Type Data Length

RISK ID CHAR 4

LANGUAGE CHAR 2

RISK DESCRIPTION CHAR 132

DETAIL DESCRIPTION CHAR 1000

CONTROL OBJECTIVE CHAR 1000

Appendix A: Rule File Templates

Risk to Rule Set Relationship Template

Page 381 of 397

Risk to Rule Set Relationship Template

Risk Rule Set Mapping: <SYSTEM>_risk _ruleset.txt

Field Type Data Length

RISK ID CHAR 4

RULE SET ID CHAR 8

Appendix B: Data Mapping Templates for Non-RTA Systems

User File Template

382 August 2010

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

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

USERID String 50 CAPS Sort Ascending

Yes User ID Unique records only

FNAME String 50 Yes First name (if not available, repeat

User ID here)

LNAME String 50 Yes Last name (if not available, repeat

User ID here)

EMAIL String 250 No Email address

PHONE String 40 No Phone number (leave blank if

unavailable)

DEPARTMENT String 40 No Department

USER-GROUP String 20 CAPs No User Group (leave blank if

unavailable)

Appendix B: Data Mapping Templates for Non-RTA Systems

User Action File Template

Page 383 of 397

User Action File Template

User Action File Template

Field

Data Field

Type

Field

Size

Field

Values Sorting Req'd Description Transformation

USERID String 50 CAPS Sort Ascending

Order 1

Yes User ID Unique record = The combination of columns 1–3 (User ID, Roles, and Action

From) must be unique

ROLES String 49 CAPS Sort Ascending

Order 2

Yes Access Role

Name

ACTIONFROM String 50 CAPS sort Ascending

Order 3

Yes User Action

ACTIONTO String 50 CAPS Yes User Action, only applicable if User Action has range

From/To

If this value does not exist for the source

system, leave blank

PROFILE String 50 CAPS Yes 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

COMPOSITE

ROLE NAME

String 50 CAPS No Composite role name, leave blank if not available.

If this value does not exist for the source

system, leave blank.

User Permission File Template

This file is required for legacy systems with configurable permission levels.

User Permission File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

USERID String 50 CAPS Sort Ascending Order 1

Yes User ID Unique record = The combination of columns 1–3 (User ID, Roles, and Action From) must

be unique

ROLE String 49 CAPS Sort Ascending

Yes Access Role Name

Appendix B: Data Mapping Templates for Non-RTA Systems

User Permission File Template

384 August 2010

User Permission File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

Order 2

PERMISSION String 100 CAPS Sort Ascending

Order 3

Yes User Permission (Permission Object/Field), required if

applicable

ACTION and PERMISSION field that use | | with no

space in between

PRMGRP String 20 Generate after

sorting

Yes Query generated numerical sequence (1+ counter per

user)

Extractor/query generates this value. The value is generated after the

data is sorted.

FROMVALUE String 50 CAPS Yes Permission Value

TOVALUE String 50 CAPS Yes Permission value, only applicable if User Action has

range From/To

If this value does not exist for source

system, leave blank

PROFILE String 50 CAPS Yes User Permission Profile, if

applicable.

If this value does not exist for source system, repeat ROLE field from

column 2

COMPOSITE ROLE

String 50 CAPS No Composite role name, leave blank if not

available.

If this value does not exist for source system, leave

blank.

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 role‘s authorization should have the same PRMGRP

value for Activity and Authorization Group for F_BKPF_KOA. For example:

Appendix B: Data Mapping Templates for Non-RTA Systems

Role File Template

Page 385 of 397

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 Role Permission PRMGRP FROMVALUE 12345 Role A F_BKPF_KOA||ACTVT 1 01 12345 Role A F_BKPF_KOA||BEGRU 1 AA 12345 Role B F_BKPF_KOA||ACTVT 2 02 12345 Role B F_BKPF_KOA||BEGRU 2 BB

Role File Template

This file is required for non-SAP security structures.

Role File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

ROLE String 50 CAPS Sorted Ascending

Yes Access Role Name

ROLE DESCRIPTION

String 100 Yes Role Description

Role Action File Template

This file is required for non-SAP security structures.

Role Action File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

ROLE String 50 CAPS Sort Ascending/

Sort Order 1

Yes Role Name

ACTIONFROM String 50 CAPS Sort Ascending/

Sort Order 2

Yes Role Action

ACTIONTO String 50 No Role Action If this value does not exist for source system, leave blank.

Appendix B: Data Mapping Templates for Non-RTA Systems

Role Permission File Template

386 August 2010

Role Action File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

PROFILE String 50 CAPS 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

Field

Data Field

Type

Field

Size

Field

Values Sorting Req'd Description Transformation

ROLE String 50 CAPS Sort Ascending

Order 1

Yes Role Name

PERMISSION String 100 CAPS Sort Ascending

Order 2

Object/Field Concatenate ACTION and PERMISSION fields that use | | with

no space in between

PRMGRP String 20 Generate after

sorting

Yes Query generated numerical sequence (1++

counter per user)

Extractor/query generates this value. The value is generated after the

data is sorted.

FROMVALUE String 50 CAPS Yes Permission Value

TOVALUE String 50 CAPS Yes Permission value, only applicable if User Action has

range From/To

If this value does not exist for source

system, leave blank

PROFILE String 50 CAPS Yes Role Profile, if applicable.

If this value does not exist for source system, repeat ROLE

field from column 2

Appendix B: Data Mapping Templates for Non-RTA Systems

Profile File Template

Page 387 of 397

Profile File Template

This file is required for non-SAP security structures that use Profiles.

Profile File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

PROFILE String 50 CAPS Sorted Ascending

Yes Access Profile Name

PROFILE DESCRIPTION

String 100 Yes Profile Description

Profile Action File Template

This file is required for non-SAP security structures that use Profiles.

Profile Action File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

PROFILE String 50 CAPS Sort Ascending/

Sort Order 1

Yes Profile Name

ACTIONFROM String 50 CAPS Sort Ascending/ Sort Order 2

Yes Profile

Action

ACTIONTO String 50 No Profile

Action

If this value does not exist for source

system, leave blank.

Profile Permission File Template

The profile permission file is required for non-SAP systems that include permission level data.

Profile Permission File Template

Field

Data Field Type

Field Size

Field Values Sorting Req'd Description Transformation

PROFILE String 50 CAPS Sort Ascending

Order 1

Yes Profile Name

PERMISSION String 100 CAPS Sort Ascending

Order 2

Object/Field Concatenate ACTION and PERMISSION fields that use | | with

no space in between

Appendix B: Data Mapping Templates for Non-RTA Systems

388 August 2010

Profile Permission File Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

PRMGRP String 20 Generate after

sorting

Yes Query generated numerical sequence (1++

counter per user)

Extractor/query generates this value. The value is generated after the

data is sorted.

FROMVALUE String 50 CAPS Yes Permission Value

TOVALUE String 50 CAPS Yes Permission value, only applicable if User Action has

range From/To

If this value does not exist for source

system, leave blank

Action Permission Objects Template

Action Permission Objects Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

ACTION String 20 CAPS Sort Ascending

Order 1

Yes Action

PERMISSION String 10 CAPS Sort Ascending

Order 3

Yes Permission

ACTVT String 10 CAPS Yes Permission Object Field

FROMVALUE String 50 CAPS Yes Permission Object Field

Value

TOVALUE String 50 CAPS No Permission Object Value

If this value does not exist for source

system, leave blank

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

Appendix B: Data Mapping Templates for Non-RTA Systems

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

File)

Page 389 of 397

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

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

Leave Blank Mandatory field. Required by load

format

Leave Blank

ACT 3 CAPS Hard code ACT as value for this

file

Hard coded value ACT

Leave Blank Mandatory field. Required by load

format

Leave Blank

TCODE String 50 CAPS Yes Action Sorted Ascending

EN 2 CAPS Hard code EN as value for this field

Hard coded value EN

TCODE DESCRIPTIONS

String <100 Yes Action Description

Permission Template

This table shows the format for the permission section of the ACT_PRM_FLD_VAL description file.

Permission Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

Appendix B: Data Mapping Templates for Non-RTA Systems

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

File)

390 August 2010

Permission Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

Leave Blank Mandatory field. Required by load

format

Leave Blank

PRM 3 CAPS Hard code PRM: as value for this

file

Hard coded value PRM

Leave Blank Mandatory field. Required by load

format

Leave Blank

PERMISSION String 50 CAPS Yes Permission Sorted Ascending

EN 2 CAPS Hard code EN as value for this field

Hard coded value EN

PERMISSION DESCRIPTIONS

String <100 Yes Permission Description

Field Template

This table shows the format for the field section of the ACT_PRM_FLD_VAL description file.

Field Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

Leave Blank Mandatory field. Required by

load format

Leave Blank

FLD CAPS Hard code FLD: as value for

this file

Hard coded value FLD

ACTVT String 50 CAPS Yes Mandatory field. Required by

load format

Leave Blank

PERMISSION/PERMISSION VALUE

String <100 CAPS Yes Permission object field

If this field does not exist for the source system, use hard coded ACTVT in this

column

EN 2 CAPS Hard code EN as value

Hard coded value EN

Appendix B: Data Mapping Templates for Non-RTA Systems

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

File)

Page 391 of 397

Field Template

Field

Data Field

Type Field Size

Field Values Sorting Req'd Description Transformation

for this field

OBJECT FIELD

DESCRIPTION

String <100 Yes Permission Object

Description

Value Template

This table shows the format for the VAL_DESCR section of the ACT_PRM_FLD_VAL description file.

Value Template

Field

Data Field

Type

Field

Size

Field

Values Sorting Req'd Description Transformation

Leave Blank Mandatory field. Required by

load format

Leave Blank

VAL CAPS Hard code VAL: as value

for this file

Hard coded value VAL

Leave Blank Mandatory field. Required by

load format

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

EN 2 CAPS Hard code EN as value

for this field

Hard coded value EN

PERMISSION VALUE DESCRIPTION

String <100 Yes Permission Value Description

Appendix C: Configuring RAR for SAP Enterprise Portal

Creating an iView

392 August 2010

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

Appendix C: Configuring RAR for SAP Enterprise Portal

Assigning an iView to a Role

Page 393 of 397

iView ID Role1_ID

ID Prefix (leave blank)

Master Language English

Description 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.

.

Appendix C: Configuring RAR for SAP Enterprise Portal

Verifying Portal RTA

394 August 2010

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:

Appendix C: Configuring RAR for SAP Enterprise Portal

Creating a Function in RAR for UME Actions

Page 395 of 397

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)

Appendix C: Configuring RAR for SAP Enterprise Portal

Creating a Function in RAR for UME Actions

396 August 2010

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 System - SAP EP

o 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 System - SAP EP

o 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 SearchRequestView - (AEACTION)

o 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

Appendix C: Configuring RAR for SAP Enterprise Portal

Creating a Function in RAR for UME Actions

Page 397 of 397

o SearchRequestView - (AEACTION)

o 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.