54057AC53_ConfigGuide

Configuration Guide

SAP™ GRCAccess ControlConfiguring SAP® with Release 5.3Target Audience

System administrators

Technology consultants

Document Version 2.10 – September, 2008

© Copyright 2008 SAP AG, All rights reserved.

No part of this publication may be reproduced or transmitted in anyform or for any purpose without the express permission of SAP AG.The information contained herein may be changed without priornotice.

Some software products marketed by SAP AG and its distributorscontain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registeredtrademarks 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 andPowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are eithertrademarks or registered trademarks of Adobe Systems Incorporated inthe 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 theOpen Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,VideoFrame, and MultiWin are trademarks or registered trademarks ofCitrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registeredtrademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., usedunder 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, andother SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AGin Germany and in several other countries all over the world. All otherproduct and service names mentioned are the trademarks of theirrespective companies. Data contained in this document servesinformational purposes only. National product specifications mayvary.

These materials are subject to change without notice. These materialsare provided by SAP AG and its affiliated companies ("SAP Group")for informational purposes only, without representation or warranty ofany kind, and SAP Group shall not be liable for errors or omissionswith respect to the materials. The only warranties for SAP Groupproducts and services are those that are set forth in the expresswarranty statements accompanying such products and services, if any.Nothing herein should be construed as constituting an additionalwarranty.

DisclaimerSome components of this product are based on Java™. Any codechange in these components may cause unpredictable and severemalfunctions and is therefore expressively prohibited, as is anydecompilation of these components.

Any Java™ Source Code delivered with this product is only to be usedby SAP’s Support Services and may not be modified or altered in anyway.

Documentation in the SAP Service MarketplaceYou can find this documentation at the following Internet address:service.sap.com/instguides

SAP AGDietmar-Hopp-Allee 16

69190 Walldorf

Germany

T +49/18 05/34 34 34

F +49/18 05/34 34 20www.sap.com

Typographic Conventions

Type Style Represents

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

Example Text Words or characters thatappear on the screen, includingfield names, screen titles,checkboxes, and radio buttons.Menu names, paths, andoptions. Cross-references toother documentation.

Example text Screen output, including file anddirectory names and their paths,messages, names of variablesand parameters, source code.Names of installation, upgrade,and database tools.

Example text Exact user entries—that is,words or characters that youenter in the system exactly asthey appear in thedocumentation. Quick links (notpart of a URL.)

<Exampletext>

Variable user entry. Anglebrackets indicate that youreplace these words andcharacters with appropriateentries.

EXAMPLE TEXT Keys on the keyboard, such asfunction keys (F2) or the ENTERkey.

Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Configuration Guide Access Control

4 September 2008

Document HistoryThis guide is regularly updated on SAP Service Marketplace athttp://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions forGRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Make sure you have the latest version of this guide by checking SAP Service Marketplacebefore starting the installation.The following table provides an overview of the most important changes that were made inthe latest versions.

Configuration Guide Version Important 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

Table of Contents

September 2008 5

Table of Contents

1 Getting Started ............................................................................................... 15About this Document ............................................................................................................ 15

Related Information .............................................................................................................. 15

Planning Information ....................................................................................................... 15

SAP Service Marketplace Links ....................................................................................... 16

Important SAP Notes ........................................................................................................... 16

GRC Access Control Documentation .................................................................................... 17

2 GRC Access Control Integration .................................................................. 18Security and Master Data Configuration ............................................................................... 18

3 Risk Analysis and Remediation .................................................................... 20Risk Analysis Configuration .................................................................................................. 21

Default Values ................................................................................................................ 21

Performance Tuning ........................................................................................................ 22

Additional Options ........................................................................................................... 22

Mitigating Controls .......................................................................................................... 24

Workflow Integration with Compliant User Provisioning ........................................................ 24

Workflow Configuration in Risk Analysis and Remediation ............................................... 24

Workflow Configuration in Compliant User Provisioning ................................................... 25

Miscellaneous ...................................................................................................................... 31

Management of Internal Controls ......................................................................................... 31

MIC Destinations in the MIC System ............................................................................... 31

MIC User Mappings ........................................................................................................ 33

MIC Risk Mappings ......................................................................................................... 33

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

Configuring Connectors for an SAP system using SAP JCo............................................. 35

Verifying JCo Connectors ................................................................................................ 36

Configuring Connectors for an Oracle, PEOPLESOFT, or JD Edwards System usingJDBC .............................................................................................................................. 36

Configuring Connectors for a Legacy system................................................................... 37

Configuring Connectors for a Portal using a Web Service ................................................ 37

Logical Systems ................................................................................................................... 38

Creating a Logical System............................................................................................... 39

Loading Rules against a Logical System ......................................................................... 40

Cross Systems ..................................................................................................................... 40

Creating a Cross System ................................................................................................ 40

1 Getting Started

About this Document

6 September 2008

Data Extraction ............................................................................................................... 41

Master User Source ............................................................................................................. 43

User Mapping ...................................................................................................................... 44

Custom User Groups ........................................................................................................... 44

Upload Objects .................................................................................................................... 45

Uploading Static Text ...................................................................................................... 45

Uploading Authorization Objects ..................................................................................... 46

Rule Upload ......................................................................................................................... 46

Uploading a Business Process Text File .......................................................................... 47

Uploading Function Text Files ......................................................................................... 47

Uploading Function Authorization Text Files .................................................................... 48

Uploading a Rule Set Text File ........................................................................................ 48

Uploading Risk Text Files ................................................................................................ 48

Scheduling Rule Generation ............................................................................................ 49

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

Synchronizing Mitigation ................................................................................................. 50

Synchronizing Rule ......................................................................................................... 50

Background Jobs ................................................................................................................. 50

Scheduling a Synchronization Job ................................................................................... 51

Scheduling Batch Risk Analysis ...................................................................................... 51

Scheduling Management Report Generation ................................................................... 52

Scheduling Alert Generation ............................................................................................ 53

Organizational User Mapping ............................................................................................... 54

Maintaining User Organizational Information ................................................................... 54

Custom Tabs ....................................................................................................................... 54

Adding a Custom Tab ..................................................................................................... 55

SAP Adapter ........................................................................................................................ 55

Utilities ................................................................................................................................. 55

Export Utility.................................................................................................................... 55

Import Utility .................................................................................................................... 56

Purge Action Usage Utility ............................................................................................... 56

Risk Terminator.................................................................................................................... 57

Configuring Risk Terminator Parameters ......................................................................... 57

Additional Configuration Options .......................................................................................... 59

Administration for RTA Supported Systems ..................................................................... 59

Administration for Non-RTA Supported Systems ............................................................. 59

Analyze and Create Rules ............................................................................................... 64

Add Action to Function .................................................................................................... 65

Table of Contents

September 2008 7

Scheduling Batch Risk Analysis ...................................................................................... 65

Additional Tabs .................................................................................................................... 66

Informer Tab ................................................................................................................... 66

Rule Architect Tab .......................................................................................................... 67

Mitigation Tab ................................................................................................................. 67

Alert Monitor Tab ............................................................................................................ 67

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

Remote Function Calls .................................................................................................... 68

Defining the Background Job for Log Reports.................................................................. 69

Configuration Parameters ............................................................................................... 70

Email Configuration ......................................................................................................... 73

Reason Codes ................................................................................................................ 74

Defining Connectors for Superuser Privilege Management ................................................... 74

Creating a Connector to View Reports............................................................................. 75

Deleting a Connector ...................................................................................................... 76

Editing a Connector......................................................................................................... 76

Searching for a Connector............................................................................................... 76

Archived Data for Log Reports ............................................................................................. 77

Archiving the Log Report ................................................................................................. 78

Automatic Archiving the Log Report ........................................................................... 78

5 Compliant User Provisioning........................................................................ 80Prior to Configuration ........................................................................................................... 80

Basic Functionality ............................................................................................................... 81

Key Concepts ...................................................................................................................... 82

Users ................................................................................................................................... 83

Administration Tasks ............................................................................................................ 84

Preconfiguration Tasks......................................................................................................... 85

Initializing System Data - Initial Logon ............................................................................. 86

Initializing System Data - Required User Management Engine Roles/Permissions ........... 87

Initialization System Data ..................................................................................................... 87

Configuration Tasks ............................................................................................................. 88

Integrating with the System Landscape Directory (SLD) .................................................. 88

Defining Connectors for Compliant User Provisioning ...................................................... 88

Defining Connectors for SAP ........................................................................................... 89

Defining Connectors for SAP Enterprise Portal ................................................................ 91

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

1 Getting Started

About this Document

8 September 2008

Defining Connectors for LDAP......................................................................................... 95

Defining Connectors for Verification/Training System ...................................................... 96

Viewing and Maintaining Available Connectors ................................................................ 98

User Data Source Definition ................................................................................................. 98

Configuring the User Data Source ................................................................................... 99

Integrating Compliant User Provisioning and Risk Analysis and Remediation ..................... 100

Request Configuration ....................................................................................................... 101

Request Type Configuration .......................................................................................... 101

Request Priority Configuration ............................................................................................ 105

Creating a Request Priority ........................................................................................... 105

Changing or Deleting a Request Priority ........................................................................ 106

Application Configuration ................................................................................................... 106

Configuring an Application............................................................................................. 107

Changing an Application Configuration .......................................................................... 107

Employee Type Configuration ............................................................................................ 107

Configuring an Employee Type ..................................................................................... 108

Changing an Employee Type ........................................................................................ 108

Number Ranges ................................................................................................................. 108

Configuring Number Ranges ......................................................................................... 109

Changing Number Ranges ............................................................................................ 109

Authentication Source for Requestors ................................................................................ 109

Defining Authentication ................................................................................................. 110

Defining Multiple LDAP Authentication .......................................................................... 110

Risk Analysis ..................................................................................................................... 110

Configuring Risk Analysis .............................................................................................. 111

Frequently Asked Questions ......................................................................................... 111

Mitigation Setting ............................................................................................................... 112

Configuring Mitigation ................................................................................................... 112

End User Personalization ................................................................................................... 113

Frequently Asked Questions ......................................................................................... 120

Technical Support Contact Identification ............................................................................. 121

Defining Contact Information ......................................................................................... 121

Defining Support Screen information ............................................................................. 122

Available Request Attributes .............................................................................................. 122

Configuring Attributes .................................................................................................... 122

Custom Fields .................................................................................................................... 122

Creating Custom Fields ................................................................................................. 123

Changing or Deleting a Custom Field ............................................................................ 124

Table of Contents

September 2008 9

Service Level Period .......................................................................................................... 124

Configuring a Service Level ........................................................................................... 124

Changing a Service Level ............................................................................................. 125

Workflow Management....................................................................................................... 125

About Workflows ........................................................................................................... 125

Workflow Components .................................................................................................. 126

Workflow Creation ......................................................................................................... 127

Sample Workflows ........................................................................................................ 128

Basic Workflows............................................................................................................ 128

Workflow-Specific Configuration Tasks .......................................................................... 131

Initiators ........................................................................................................................ 134

Custom Approver Determinators ................................................................................... 136

Creating a Custom Approver Determinator .................................................................... 137

Stages .......................................................................................................................... 138

Paths ............................................................................................................................ 144

Detour Paths ................................................................................................................. 145

Forked Workflows ......................................................................................................... 148

Email Reminder Setup ....................................................................................................... 150

Setting Up Email Reminders or Notifications.................................................................. 150

Setting Up New User Password Notifications................................................................. 151

Escape Route ............................................................................................................... 151

SMTP Server Identification ................................................................................................. 153

Configuring the SMTP Server ........................................................................................ 153

CUA System Setting Configuration ..................................................................................... 154

Configuring the CUA System Setting ............................................................................. 154

Auto Provisioning ............................................................................................................... 158

Configuring Global Settings for Auto Provisioning .......................................................... 159

Configuring Auto Provisioning by System ...................................................................... 160

Approvers .......................................................................................................................... 161

Security Leads .............................................................................................................. 162

Point of Contact ............................................................................................................ 162

Application Approvers ................................................................................................... 163

Distribution Group ...................................................................................................... 163

DL Approvers .............................................................................................................. 164

Stale Requests .................................................................................................................. 165

Request Administration ...................................................................................................... 165

Administration ............................................................................................................... 165

Archive ......................................................................................................................... 165

1 Getting Started

About this Document

10 September 2008

Field Mapping .................................................................................................................... 166

Provisioning .................................................................................................................. 166

LDAP Mapping .............................................................................................................. 167

User Review ...................................................................................................................... 168

Initiating User SoD Reviews .......................................................................................... 169

Initiating User Access Reviews...................................................................................... 174

Coordinator ................................................................................................................... 175

Request Review ............................................................................................................ 176

Change Log ....................................................................................................................... 180

Change Log Configuration............................................................................................. 180

Search Change Log ...................................................................................................... 180

Roles ................................................................................................................................. 181

Import Roles ................................................................................................................. 182

Configuration for Role Synchronization Integration with Enterprise Role Management ... 183

Role Import/Export Template Details ............................................................................. 184

Changing Existing Roles with the Export/Import Spreadsheet ........................................ 188

Role Creation ................................................................................................................ 188

Role Search .................................................................................................................. 190

Role Exporting .............................................................................................................. 191

Role Selection ............................................................................................................... 191

Default Roles Configuration ........................................................................................... 193

Role Mapping Option .................................................................................................... 194

Role Attributes .............................................................................................................. 196

Role Reaffirmation ............................................................................................................. 205

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

Background Jobs ............................................................................................................... 206

Setting Up Background Jobs ......................................................................................... 206

User Default Management.................................................................................................. 207

Configuring User Defaults ............................................................................................. 207

Setting User Default Mapping ........................................................................................ 208

Selecting a User Default System ................................................................................... 209

Changing User Defaults ................................................................................................ 209

Deleting User Default Mapping ...................................................................................... 209

Attachments ....................................................................................................................... 209

System Log Monitoring....................................................................................................... 210

Viewing the System Log ................................................................................................ 211

Viewing the Application Log .......................................................................................... 211

HR Trigger Configuration ................................................................................................... 212

Table of Contents

September 2008 11

Creating Actions............................................................................................................ 213

Creating Rules .............................................................................................................. 214

Changing a Rule ........................................................................................................... 216

Changing or Deleting a Rule ......................................................................................... 216

Mapping Fields Using the SAP HR System ................................................................... 216

Schedule HR Trigger Background Jobs ......................................................................... 216

View Process Log ......................................................................................................... 217

Password Self Service ....................................................................................................... 217

Defining Password Self Service for SAP HR .................................................................. 217

Defining Password Self-Service for Challenge Response .............................................. 218

Defining Password Self Service for Peoplesoft HR ........................................................ 220

Disabling Password Self Service ............................................................................... 220

User Registration .......................................................................................................... 220

Miscellaneous Configuration .............................................................................................. 220

Language Configuration ................................................................................................ 221

Log Level Configuration ................................................................................................ 221

Cache Job Interval Configuration .................................................................................. 221

Configure Workflow Types ............................................................................................ 222

Configure the Background Job Interval .......................................................................... 222

6 Enterprise Role Management ..................................................................... 223Configuring Enterprise Role Management .......................................................................... 223

Initial Logon to Enterprise Role Management ..................................................................... 223

Initial System Data Importation ........................................................................................... 224

Importing Initial System Data ......................................................................................... 224

Initial Background Job ................................................................................................... 224

Managing Background Jobs ............................................................................................... 225

Creating a Static Background Job ................................................................................. 226

Editing a Background Job ............................................................................................. 226

Deleting a Background Job ........................................................................................... 227

Activating/Deactivating a Background Job ..................................................................... 227

Searching for a Background Job ................................................................................... 227

Viewing the History of a Background Job....................................................................... 227

Configuration for Risk Analysis Integration with Risk Analysis and Remediation ................. 228

Configuration for Workflow Integration with Compliant User Provisioning ............................ 229

Configuring Compliant User Provisioning Workflow for Enterprise Role Management .... 229

Configuring Enterprise Role Management Web Services for Compliant UserProvisioning .................................................................................................................. 231

System Landscape Definition ............................................................................................. 232

1 Getting Started

About this Document

12 September 2008

Defining Connectors for Enterprise Role Management. ...................................................... 232

Configuring a Connector for SAP .................................................................................. 233

Configuring a Connector for Enterprise, Non-SAP, or SAP EP ....................................... 234

Creating the Landscape ................................................................................................ 234

Role Designer .................................................................................................................... 237

Managing Role Attributes .............................................................................................. 237

Managing Business Processes...................................................................................... 237

Role Status ........................................................................................................................ 246

Managing Condition Groups ............................................................................................... 247

Creating a Condition Group ........................................................................................... 247

Changing a Condition Group ......................................................................................... 247

Deleting a Condition Group ........................................................................................... 248

Role Creation Methodology Setup ................................................................................. 248

Managing the Workflow ...................................................................................................... 251

Creating Approval Criteria for a Workflow ...................................................................... 252

Changing Approval Criteria for a Workflow .................................................................... 253

Deleting Approval Criteria for a Workflow ...................................................................... 253

Managing Naming Conventions .......................................................................................... 254

Creating a Naming Convention...................................................................................... 254

Changing a Naming Convention .................................................................................... 255

Deleting a Naming Convention ...................................................................................... 255

Managing Organizational Value Mapping ........................................................................... 255

Creating an Organizational Value Mapping .................................................................... 256

Changing an Organizational Value Mapping .................................................................. 257

Deleting an Organizational Value Mapping .................................................................... 257

Importing an Organizational Value Mapping .................................................................. 257

Exporting an Organizational Value Mapping .................................................................. 258

System Logs ...................................................................................................................... 258

Transaction Import ............................................................................................................. 259

Importing Mass Roles ................................................................................................... 259

Role Usage Synchronization ......................................................................................... 261

Importing and Exporting Configuration Settings .................................................................. 263

Exporting Configuration Settings ................................................................................... 263

Exporting System Data.................................................................................................. 263

Importing Configuration Settings ................................................................................... 264

Miscellaneous .................................................................................................................... 264

Language Configuration for Enterprise Role Management ............................................. 265

Table of Contents

September 2008 13

7 Access Control and Identity Manager Integration .................................... 267Calling Web Services ......................................................................................................... 268

Access Control and IdM System Integration Architecture .................................................... 273

Web Services offered by Access Control and SPML 1.0 Compliant IdM Solutions ......... 274

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

Select Applications (SAPGRC_AC_IDM_SELECTAPPLICATION) ................................ 275

Search Role (SAPGRC_AC_IDM_SEARCHROLES) ..................................................... 277

Role Details (SAPGRC_AC_IDM_ROLEDETAILS) ....................................................... 279

Submit Request (to Access Control) (SAPGRC_AC_IDM_SUBMITREQUEST) ............. 281

Risk Analysis (SAPGRC_AC_IDM_RISKANALYSIS) .................................................... 285

Audit Trail (SAPGRC_AC_IDM_AUDITTRAIL) .............................................................. 287

Request Status (SAPGRC_AC_IDM_REQUESTSTATUS) ............................................ 289

Integrating with an Identity Management Solution ............................................................... 290

Defining Connectors for IdM Systems................................................................................. 291

Setting the Field Mapping .............................................................................................. 292

Importing Roles ............................................................................................................. 293

Sending Provisioning Request to an IdM System................................................................ 294

Provisioning to Other Target Systems with SPML SOAP Compliant Call ............................. 297

Defining a Connector for Target Systems other than IdM ............................................... 297

Setting the Field Mapping .............................................................................................. 299

Importing Roles ............................................................................................................. 300

Integration with SAP NetWeaver Identity Manager ............................................................. 301

Provisioning Operations ................................................................................................ 301

Search Operations ............................................................................................................. 305

Checking the Result of Update Operation ...................................................................... 305

Returned Entry .............................................................................................................. 305

Obtaining Entry Information ........................................................................................... 307

Detailed Search on Single Person ................................................................................. 307

Appendix A: Rule File Templates .................................................................. 310Business Process Template ............................................................................................... 310

Function Template ............................................................................................................. 310

Function-Business Process Relationship Template ............................................................ 310

Function-Action Relationship Template .............................................................................. 311

Function-Permission Relationship Template ....................................................................... 311

Rule Set Template ............................................................................................................. 311

Risk Definition Template .................................................................................................... 312

Risk Description Template.................................................................................................. 312

1 Getting Started

About this Document

14 September 2008

Risk to Rule Set Relationship Template .............................................................................. 313

Appendix B: Data Mapping Templates for Non-RTA Supported Systems . 314User File Template ............................................................................................................. 314

User Action File Template .................................................................................................. 315

User Permission File Template........................................................................................... 315

Role File Template ............................................................................................................. 317

Role Action File Template .................................................................................................. 317

Role Permission File Template ........................................................................................... 318

Profile File Template .......................................................................................................... 318

Profile Action File Template ................................................................................................ 319

Profile Permission File Template ........................................................................................ 319

Action Permission Objects Template .................................................................................. 320

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

Action Template ............................................................................................................ 321

Permission Template .................................................................................................... 321

Field Template .............................................................................................................. 322

Value Template ............................................................................................................. 323

Appendix C: Configuring Risk Analysis and Remediation for SAPEnterprise Portal ............................................................................................. 324

Creating an iView ............................................................................................................... 324

Creating an iView Role ....................................................................................................... 324

Assigning an iView to a Role .............................................................................................. 325

Retrieving Master Data....................................................................................................... 325

Verifying Portal RTA ........................................................................................................... 326

Creating a Function in Risk Analysis and Remediation for iView ......................................... 326

Creating a Function in Risk Analysis and Remediation for User Management EngineActions .............................................................................................................................. 327

1 Getting Started

About this Document

September 2008 15

1 Getting StartedSAP Governance, Risk, and Compliance (GRC) Access Control provides end-to-endautomation for documenting, detecting, remediating, mitigating, and preventing access andauthorization 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 violationsbefore they occur.

Compliant User Provisioning, which automates provisioning, tests for segregation ofduties (SoD) risks, and streamlines approvals by the appropriate business approvers tounburden IT staff and provide a complete history of user access.

Enterprise Role Management, which standardizes and centralizes role creation andmaintenance.

Superuser Privilege Management, which enables users to perform emergency activitiesoutside their roles as privileged users in a controlled and auditable environment.

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

About this DocumentThis 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 AccessControl, and the latest installation and configuration guides, on SAP Service Marketplaceat http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutionsfor GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3. We recommendthat you use the documents available there, since the guides are regularly updated.

Related InformationThis section describes topics for planning. Links to reference documentation found on SAPService Marketplace are also provided.

Planning Information

For information about planning topics not covered in this guide, see the following content onSAP Service Marketplace:

1 Getting Started

Important SAP Notes

16 September 2008

Content Location on SAP Service Marketplace

Latest versions of installation and upgradeguides

service.sap.com/instguides

SAP Business Maps – general informationabout applications, solutions and businessscenarios

service.sap.com/businessmaps

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

service.sap.com/sizing

Released platforms and technology-relatedtopics such as maintenance strategies andlanguage support

service.sap.com/platforms

To access the Platform Availability Matrixdirectly, 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 levelrequirements

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 (softwaredownload and ordering of software)

service.sap.com/swdc

SAP Online Knowledge Products (OKPs) –role-specific Learning Maps

service.sap.com/rkt

Important SAP NotesTo obtain the latest technical information, read the following SAP Notes before you startinstallation. These notes also contain updates and correction to the installationdocumentation. The most up-to-date version of SAP Notes is found on SAP ServiceMarketplace at: service.sap.com/notes.

1 Getting Started

GRC Access Control Documentation

September 2008 17

SAP Note Number Title Description

1133167 VIRSANH Installation notes for530_700

1133168 VIRSAHR Installation notes for530_700

1133173 VIRSANH Upgrades notes for 530_700

1133174 VIRSAHR Upgrades notes for 530_700









1133161 VIRSANH Installation notes for530_46C

1133162 VIRSAHR Installation notes for530_46C

GRC Access Control DocumentationYou can find documentation, including this guide, on SAP Service Marketplace athttp://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

2 GRC Access Control Integration

Security and Master Data Configuration

18 September 2008

2 GRC Access Control IntegrationTo provide a complete end-to-end process for managing user access, the capabilities ofAccess Control are integrated for risk analysis, mitigation, workflow approval, and rolesynchronization. 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 sameserver as Compliant User Provisioning.

Access authorization is achieved through a centralized Web user account, which has therequired administration rights in the User Management Engine (UME). This Web user musthave administration rights for the capabilities Compliant User Provisioning (CUP), RiskAnalysis 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 ReviewIn 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 usage synchronization for User Access Review

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

Security and Master Data ConfigurationWhen integrating Access Control capabilities, you should plan security and master dataproactively to ensure consistent data across the application. Some master data normalizationis necessary for the functionality to be effectively integrated. In the section below, this datatype is marked as Required. All other data types are best practice recommendations toensure seamless integration.

Security and System Data: Connectors

- Create the same connector Name, User ID, and Password for each systemin all capabilities.

2 GRC Access Control Integration


September 2008 19

- Use the same connector User ID and Password for Web user creation.

If Compliant User Provisioning is connected to one or more CUA systems,the connector name must match the back-end SAP system logical name.

Web UserThis user facilitates communication between the capabilities via Web services. It hasto 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 IDis configured with the individual Web services for each capability.

For information about the authorizations required for your Web user, see the SAPGRC Access Control 5.3 Security Guide on SAP Service Marketplace athttp://service.sap.com/instguides -> SAP Solution Extensions -> SAPSolutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Remote Function Call (RFC) User

This user communicates between front-end Java applications and SAP targetsystems.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 GRCAccess Control 5.3 Security Guide on SAP Service Marketplace athttp://service.sap.com/instguides -> SAP Solution Extensions -> SAPSolutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Master Data:

You must define the following role attribute master data and assign matching names inEnterprise Role Management and Compliant User Provisioning (Required).

Functional Area (Functional Area ID field in ERM must exactly match the FunctionalArea Name field in CUP)

Business Process (Business Process ID field in ERM must exactly match theBusiness Process Name field in CUP)

Subprocess (Subprocess ID field in ERM must exactly match the Subprocess Namefield in CUP)

Role owner in ERM should be the same as role approver in CUPOther 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.

3 Risk Analysis and Remediation


20 September 2008

3 Risk Analysis and RemediationRisk Analysis and Remediation is a Web-based, automated security audit and segregation ofduties (SoD) analysis application. It uses custom tables to store SoD data. You use RiskAnalysis and Remediation to identify, analyze, and resolve all SoD and audit issues relatingto regulatory compliance.

You can perform risk analysis to identify risks associated with a user, role, profile, or humanresources (HR) object. For risks that cannot be eliminated, you define mitigating controls.You also define monitors and approvers, assign them to specific controls, and createbusiness units to categorize the controls.

This section describes how to configure Risk Analysis and Remediation (a front-end tool), aswell 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 Analysisand Remediation. Since this tab is displayed only for users with administration permissions,the information in this section is not relevant for all users.

The Configuration tab does not provide settings for Risk Terminator.Configuration impacts the behavior of many Risk Analysis and Remediation functions andfeatures. Therefore, you must work closely with security and user administrators, as well asbusiness 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

Custom User Groups


Risk Analysis Configuration

September 2008 21

Upload Objects

Rule Upload

Backend Synchronization

Background Jobs

Organizational User Mapping

Custom Tabs

SAP Adapter

Utilities

Risk Analysis ConfigurationThis section describes the options available under Risk Analysis on the Configuration tab’snavigation bar.

Default Values

Parameter / Purpose Options

Default Report Type

This option determines the default report typepopulated 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 levelpopulated when executing a Risk Analysis.

All (default)

Critical

High

Medium

Low

Default User Type

This option determines the default user type includedwhen executing a Risk Analysis.

All

Dialog (default)

System

Communication

Service

Reference

Default Rule Set

This option determines the default rule set usedwhen executing a Risk Analysis.

All defined rule sets are available



22 September 2008

Parameter / Purpose Options

Exclude Locked Users

This option specifies whether locked users areexcluded when executing a Risk Analysis.

For information on the lock codes or user flags andhow to include or exclude certain values, see SAPNote 1013217.

Yes (default)

No

Exclude Expired Users

This option specifies whether expired users areexcluded when executing a Risk Analysis.

Yes (default)

No

Exclude Mitigated Risks

This option specifies whether risks with assignedmitigating controls are excluded when executing aRisk Analysis.

Yes (default)

No

Performance Tuning

Parameter Purpose

Batch Size for UserSynchronization

This setting specifies the number of users to synchronize atonce or in one batch.

To improve performance, increase the value. Be aware,however, that increasing thevalue too much can causetimeouts to occur during synchronization.

Number of Web Services WorkerThreads

This setting specifies the number of server threads todedicate to Web service calls, such as calls from the RiskAnalysis Engine.

If you experience risk analysis performance issues,consider increasing this thread allocation.

Number of Background Job WorkerThreads

This setting specifies the number of server threads todedicate for background jobs.

If background job operations slow performance, considerincreasing this thread allocation. If you schedule multiplebackground job processes to run simultaneously, theseoperations might be delayed until another background jobcompletes.

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

This setting specifies in minutes the timeout value forremote function calls.

The amount of data you process and the number of threadsyou allocate can affect whether you experience RFCtimeouts during Web service or background job operations.

Additional Options

Parameter Purpose



September 2008 23

Parameter Purpose

Ignore Critical Roles and Profiles This setting determines whether roles and profilesmaintained in the Critical Roles and Profiles tables areignored when user risk analysis is performed.

The default is No.

Show Composite Role in UserAnalysis

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

Use SoD Supplementary Table forAnalysis

This setting determines whether the SoD supplementarytable is checked when risk analysis is performed.

If no supplementary rules are maintained, this parametermust be set to No to avoid incorrect results in Risk Analysis.

Include Role/Profile MitigatingControls in User Analysis

This setting determines whether role-based or profile-basedmitigating controls are included in user-based Risk Analysisreports.

The risk analysis includes user-level mitigating control IDs,if they exist. If not, the report displays either the role-basedor profile-based mitigating control ID (in that order). If youset this option to Yes, the mitigation flows to the risksmitigated at the role/profile level (regardless of whether theuser 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 withoutreal-time communication with a back-end system and usesdata from the Batch Risk Analysis for reporting.

Enabling offline analysis results in faster response times forRisk Analysis reports.

Consider Organizational Rules This setting determines whether to consider organizationalrules when updating the Management Reports of theInformer tab and during the Risk Analysis Web service call.

If no organizational rules are maintained, this parametermust be set to No to avoid incorrect results in the RiskAnalysis.

The default value is No.

Convert Users, Roles and Profilesto Upper Case

This setting determines whether names of users, roles andprofiles are converted to upper case.

Recommendation

This setting is recommended for SAP systems to facilitatesearches.


Workflow Integration with Compliant User Provisioning

24 September 2008

Parameter Purpose

Include Reference User whendoing User Analysis

This setting determines whether access gained throughassignment of a reference user to a user ID is included inRisk Analysis for users.

Reference users are templates, which give predefinedaccess to individual user IDs. If reference user security isconsidered in Risk Analysis, the report rows related toaccess gained from reference user assignment aredisplayed in a different color than the rows resulting fromaccess gained by direct assignment.

Show all objects in Risk Analysis This setting determines whether all objects in the selectioncriteria range are shown in the report, whether or not theyhave associated risks.

For example, user-level Risk Analysis shows User A hasrisks and User B has no risks. Setting this value to Yesreturns Users A and B in the results, whereas setting thisvalue to No returns only User A.

Enable monitor notification This setting enables email notification to the specifiedmonitor.

This occurs when the monitor is assigned to or removedfrom a mitigation control.

Show Selection Criteria This setting determines whether to show selection criteria inRisk Analysis reports.

The default value is Yes.

Mitigating Controls

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

Workflow Integration with Compliant UserProvisioningRisk Analysis and Remediation integrates with Compliant User Provisioning for:

Approval of risk updates

Approval of mitigation control updates

Approval of mitigating control assignments

Workflow Configuration in Risk Analysis and Remediation

Workflow configuration allows you to specify the conditions under which workflows aretriggered. Risk Analysis and Remediation supports Compliant User Provisioning workflowsonly.

The table below lists the workflow parameters and their purpose:

Parameter Purpose



September 2008 25

Parameter Purpose

Risk Maintenance If you set this option to Yes, creating a new risk andchanging or deleting an existing risk triggers workflow. Thedefault value is No.

During risk creation or maintenance, icon nomenclatureindicates whether workflow has been enabled:

If the Submit option appears, workflow for RiskMaintenance is enabled. The system notifies the riskowner through a workflow task and, on approval, savesthe risk changes and generates the rules. No manualrule update is required.

If the Save option appears, workflow for RiskMaintenance is disabled. The change is immediate andrules are generated at once.

Mitigation Control Maintenance If you set this option to Yes, editing a mitigating controltriggers workflow. The default value is No.

When a mitigating control is created or changed, iconnomenclature indicates whether workflow has beenenabled.

If the Submit option appears, workflow for MitigationControl Maintenance is enabled. The system notifies therisk owner through a workflow task and, on approval,saves the risk changes and generates the rules. Until thecontrol is approved, it is not available for assignment.

If the Save option appears, workflow for MitigationControl Maintenance is disabled. The change isimmediate, and the control is available for assignment.

Mitigation If you set this option to Yes, mitigating, changing, orremoving risks for users, roles, profiles, or HR objectstriggers workflow. The default value is No.

When a mitigating control is assigned or changed, iconnomenclature indicates whether workflow has been enabled.

If the Submit option appears, workflow for Mitigation isenabled. The system sends the workflow task based onmaster data in Compliant User Provisioning. The changetakes effect on approval.

If the Save option appears, workflow for Mitigation isdisabled. The change is immediate.

Workflow Service URL Enter the URL for submitting workflow requests toCompliant User Provisioning.

Workflow Configuration in Compliant User Provisioning

To configure Compliant User Provisioning for approval workflow, you must upload the appendfiles from installation of Risk Analysis and Remediation.

Procedure

To configure for approval workflow:



26 September 2008

1. Upload append file.

The append file for Compliant User Provisioning is provided with Risk Analysis andRemediation installation or can be found in SAP Service Marketplace. Copy the fileAE_init_append_data_cc.xml. The append file is not build-dependent.

If the XML files have already been loaded, this step is not needed. Verify they havebeen loaded by reviewing the Request Type and Priority screen in Compliant UserProvisioning’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 inCompliant 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 toConfiguration 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.


b. Go to Configuration tab > Request Type

c. Select a request type and click Change. The Create Request Type screenappears.

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



September 2008 27

MITIOBJC Create Mitigation Object

MITIOBJD Delete Mitigation Object

MITIOBJU Update Mitigation Object

RISKC Create Risk

RISKD Delete Risk

RISKU Update Risk

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

3. Configure request priority.


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.


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:

Request Attribute Name Workflow Type

Priority Mitigation Control

Priority Mitigation Object

Priority Risk

Request Type Mitigation Control

Request Type Mitigation Object

Request Type Risk



28 September 2008

5. Verify custom fields.


b. Go to Configuration tab > Custom Fields. The Available Custom Fields tabledisplays the pre-delivered custom fields with Compliant User Provisioning forworkflow integration with Risk Analysis and Remediation.

c. Verify that the custom field names are relevant for the workflow integration. Theworkflow 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 UserProvisioning for workflow integration with Risk Analysis and Remediation. Theintegration 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.


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

When mitigating controls are created, updated ordeleted, a request is sent from Risk Analysis andRemediation to Compliant User Provisioning via a Webservice 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 RiskAnalysis and Remediation to Compliant UserProvisioning via a Web service to trigger workflowapproval of the assignment.



September 2008 29

CC_RISK_INT For changes to risk definitions, configure the initiatorCC_RISK_INT.

When risks are maintained, a request is sent from RiskAnalysis and Remediation to Compliant UserProvisioning via a Web service to trigger workflowapproval of the change to the risk.

7. Configure custom approver determinators.

Custom approver determinators (CADs) determine the path for routing the approvalrequest. 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, butyou must create one for Risk Analysis and Remediation workflow integration.


b. Go to Configuration tab > Workflow > Custom Approver Determinators.

c. For Risk Analysis and Remediation workflow integration, create a CAD formitigating control assignment approval. This CAD is used for users, roles, andprofiles 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 canselect additional attributes to differentiate approvers for different processes. Forexample, you can assign different approvers for each Request Type.

d. Create another CAD for Risk Analysis and Remediation. This is for the mitigatingcontrol maintenance approver.

Name (example) – CC_MITCTRL_CAD


Workflow Type – Mitigation Control


e. Create another CAD for Risk Analysis and Remediation risk maintenanceapprover.

Name (example) – CC_RISK_CAD


Workflow Type – Risk


f. In the Select Attributes pane, identify the characteristics of the request or theusers that determines the approver to receive the workflow request. Forexample, Business Process is used to segregate approvals between differentbusiness process owners.



30 September 2008

g. In the Select Role Attributes pane, identify the characteristics of the role(s) on therequest that determines the approver to receive the workflow request. Forexample, the criticality of the role is used to require additional approval for highsensitivity roles.

h. Select the Approvers option to identify the primary approver and the alternateapprover 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 initiatorsthat were configured in the previous step. Create each path with Number of Stages equalto 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 ControlAssignment

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 havethe 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 capabilitiesin the Name field.

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


Miscellaneous

September 2008 31

c. Enter the User Name and Password.

d. Select Active.

MiscellaneousUse Miscellaneous settings to specify:

How often to invoke the background job daemon (in seconds). The default value is 60seconds.

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.

The Alert Log file name and location. No default value is provided. When action usageinformation is obtained from the back-end system, it is stored here. This information isstill accessible to Risk Analysis and Remediation as well as Enterprise RoleManagement.

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 tolocate the risk. Click Change History.

Whether to keep a change history of all additions and deletions of functions. The defaultvalue 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, aresupported. These directories are viewed with SAP ERP transaction, AL11. The samedirectory 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 ControlsYou can integrate Risk Analysis and Remediation with SAP Management of Internal Controls(MIC). SAP MIC supports the implementation and documentation of regulatory processesand controls, as well as the assessment of internal controls performed by Risk Analysis andRemediation. The path mappings related to the SAP MIC controls can also be accessedthrough the Configuration tab.

MIC Destinations in the MIC System

Configuration for Destinations in MIC is not available on the Access Control Configurationtab.To enable Risk Analysis and Remediation to work with SAP MIC, you must configure theExchange Infrastructure (XI) communication system and connect it to the system where MICis 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


Management of Internal Controls

32 September 2008

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:


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

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 –


Management of Internal Controls

September 2008 33

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


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

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


Defining Connectors for Risk Analysis and Remediation

34 September 2008

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-endsystem, schedule a periodic job to update this information.

Defining Connectors for Risk Analysis andRemediationWhen you have installed Risk Analysis and Remediation, you must enable integration withSAP applications by defining connectors. Each back-end ABAP system/client combination tobe supported by Risk Analysis and Remediation requires a connector.

You can connect to an SAP system or non-SAP system by using the appropriate connectiontype. 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

File - FTP

PEOPLESOFT JDBC

JDBC – SLD

Web Service

JD Edwards JDBC

JDBC – SLD

Web Service



September 2008 35

Portal Web Service

The connector configuration procedures in this section are examples of each of the systemtypes with a commonly used connector type.

Access Control communicates with multiple systems. SAP recommends usingHTTPS communication protocol for secure communication.

Configuring Connectors for an SAP system using SAP JCo

You can create a Java connector (JCo) using Adaptive RFC for Web Dynpro or SAP JavaConnector (SAP JCo). SAP recommends that you use the more efficient Adaptive RFC foryour first 21 connectors. If you need more than 21 connectors, use SAP JCo. Because of thedifference in efficiency, consider using the 21 Adaptive RFC JCos for higher-volumeor production environments.

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

Procedure

To create an SAP 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 areconnecting.

The connector names are important when integrating with other GRC capabilities andthe CUA. Verify that the connector name for Access Control is the same as the oneconfigured 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, anew configuration screen appears with additional fields.

You can create additional JCo connectors to connect multiple SAP systems to asingle 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 instanceor group of application servers of the SAP ERP system.

12. In the Report Name field, create a unique external program name, suchas GRCRTTOCC5X.



36 September 2008

13. Select the Outbound Connection Flag checkbox to enable the connector for RiskTerminator.

14. Select the Unicode System Flag checkbox to designate that the back-end SAP ERPsystem is a Unicode system.

15. Click Save.

Verifying JCo Connectors

Procedure

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

1. Go to http://<host_name>:5<instance number>00/.

2. Use an assigned User Management Engine role with WebDynpro administrative actionsto 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 thebottom 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 forthe 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 usingJDBC


Procedure

To configure connectors for Oracle, PEOPLESOFT, and JD Edwards:


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


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.



September 2008 37

9. In the Password field, enter the password associated with the User ID.

10. Click Save.

Configuring Connectors for a Legacy system


Procedure

To configure a connector for a legacy system:


2. In the System field, enter the system ID of the system to which you are connecting.



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. Fordata extraction, there are three folders that are needed in the directory: IN, OUTand EXP. The connector path should reference the OUT folder.

The location where the files are stored must be in a directory that the applicationis mounted to. We recommend that the files are stored 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


Procedure

To configure a connector for a Portal:


2. In the System field, enter the system ID of the new system to which you are connecting.



Logical Systems

38 September 2008


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

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 specifythe IP address of the server name if the server name is not supported for aspecific 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 SAPEnterprise Portal, see Appendix C, Configuring Risk Analysis and Remediation forEnterprise Portal.

Logical SystemsA logical system is two or more physical systems grouped together to allow you to maintainrules against one system grouping instead of each physical system. Logical systems reducethe time and system resources required to maintain rule sets by avoiding identical rule setsfor multiple systems.

Physical systems take precedence over logical systems. If a physical systemgrouped within a logical system holds rules specific to that system, the physicalsystem 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


Logical Systems

September 2008 39

When you create functions in Rule Architect, you can create or delete an action or permissionand assign it to a specific system. You can define a function action against a logical systemand a physical system.

When you define or modify a logical system, you must regenerate rules for all the risks of thatlogical 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 particularrisk only requires updating the rules for that risk and, therefore, does not require access tothe Configuration tab.

ExampleThe following example describe the relationship between physical systems and logicalsystems, when rules or functions are applied separately to both.You define a logical system, PROD consisting of physical system, PR1 and physicalsystem, PR2, where the two instances are SAP ERP systems. You can update the twophysical systems with transaction codes which make up the rules. For instances, you canupdate PR1 and PR2 with the transaction code FB01 with the same permission byspecifying the logical system, PROD.In another instances, the transaction code, ZFB01 has an extra permission that you wantto add in PR1. You can specify the physical system PR2 so that only the physical systemis updated with ZFB01 and the permission. In this case, the logical system is not updatedwith ZFB01.

Defining a logical system streamlines the rule definition process. For this reason, you seelogical systems you have created from within Rule Architect, but you do not see theselogical systems when running Risk Analysis.

Physical systems take precedence over logical systems. If a physical system groupedwithin a logical system holds one or more rules specific to that system, the system checksthe 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 logicalsystem.

For more information, see Appendix A, Rule File Templates.

4. Generate rules by navigating to Logical Systems > Generate Rules on the Configurationtab.

You must load permission and text data for at least one physical system by navigatingto Configuration > Upload Objects. If you define a logical system and load text formultiple physical systems, the logical system’s text and authorizations are used whenupdating function data. Text loaded for the first system listed in the logical systemdefinition is used as the logical system text.

You use the permission and text data when you manually update functions. Use thetext data to populate the descriptions in the analysis reports.


Cross Systems

40 September 2008

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 toLogical Systems > Generate Rules on the Configuration tab.

When generating rules for the logical system, you do not see rules for the individualphysical systems within the logical system. The rules are created at the logical systemlevel only.

ExampleYou load the global rules against physical system A and generate all the rules. You thencreate a logical system that contains both physical system A and physical system B. Youthen reload all of the actions/permissions against the logical system and generate therules. The system generates the rules for the logical system, but since you also have therules for physical system A, those rules also still exist. If a system is contained within alogical system but has rules built against the physical and logical systems, the physicalsystem takes precedence.

Cross SystemsA cross system is two or more physical systems grouped together so you can perform useranalysis operations across multiple systems. You can select and view cross systems whenyou 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 definetwo or more systems as a cross system. With a subset of systems defined as a cross systemand available in the System dropdown list, you can perform analysis operations against onephysical 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, sothe system-specific rules can be updated in the database. You generate rules by navigatingto Cross Systems > Generate Rules. Updating a particular risk only requires updating therules for that risk and, subsequently, does not require access to the Configuration tab.

ExampleYou define a cross system ID, XFINANCE consisting of physical system, ERP1 andphysical system, ORA2, where the two instances are an SAP ERP system and an Oracleapplication server, respectively. The ERP1 system is solely used for buying services fromvendors, whereas ORA2 system is for paying vendors. The two systems can use differenttransaction codes.You can perform risk analysis in a cross system, where risk analysis determines access ineach system defined in a cross-system risk to determine if the risk exists.

Creating a Cross System

Procedure

To create a cross system:

1. Navigate to Configuration Cross Systems > Create.


Cross Systems

September 2008 41

2. Create a cross system, and assign its physical systems.

3. Generate rules by navigating to Configuration Cross Systems > Generate Rules.

Data Extraction

The data extraction function uploads user, role, and profile data from legacy systems andreconciles 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 andRemediation to upload it.


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

To create a data extractor:

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

3. In the Object dropdown list, select the object data you want to import. You must repeatthese steps for each object: User, Role, and Profile.

When you select an object, that object name appears on the first tab. The dropdownlists available on all three tabs are customized to display the options that apply to yourselection. For example, when you select the Role object, the title of the first tab isRole. 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 foruser objects.

The location (application server path) where these files are stored must be defined inthe 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 fieldin the Target Field and Source Field, highlight the field and click the icon.


Cross Systems

42 September 2008

In the Source Field column, enter the output file number to specify the field order of theextracted output. For example, if you entered 5 as the Source Field value for theUSERID, Risk Analysis and Remediation uploads the data in column 5 from your text fileas the USERID. The Data Extractor order must exactly match the order of the data inyour extracted flat file.

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

7. The Upload Extractor Data screen appears. Select the checkboxes for User, Actions, orPermissions.

If the system contains permission-level records that you want to extract, selectPermissions.

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 andtime 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 torun for that period.

13. In the End Date field, enter a date to end the job. You can use the Calendar icon to setthe date.

14. Click Schedule.

Read the status line message underneath the navigation bar to verify that the job isscheduled.

Running the Comparison Utility

Use this information to compare and load changes from your non-RTA system. The securityenvironment constantly changes due to adding, modifying, and deleting users. Therefore, it isrecommended to frequently re-extract data from your legacy system and reload it into RiskAnalysis and Remediation.

When re-extracting and reloading the definition files, ensure that the file names remain thesame. Save these new files into the IN folder.


Configuring Connectors for a Legacy System


Master User Source

September 2008 43


Procedure

The Comparison Utility takes data files from the IN folder, compares it to data in the RiskAnalysis and Remediation database, and places the incremental added, deleted, or changeddata files in the OUT folder for Data Extraction loading. When the system completes thisprocess, the Comparison Utility deletes data files from the IN folder. The system also updatesthe EXP folder with the changed data files along with exceptions and statistical information,such as how many users were changed and processed.

To run the comparison utility:

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 ofsystems 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 thenew information into the system.

The Comparison Utility only generates a delta file. The data in Risk Analysis andRemediation is not updated until the Data Extractor is executed again.

For more information, see the section Extracting User and Role Data in a BackgroundJob.

Master User SourceAs part of the post-installation process, you define a Master User Source to specify theprimary 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 theinitial source for retrieving basic user information, such as name and user group. If the searchcannot find a user ID in the Master User Source, it searches the remaining systems withconnectors until it finds the user ID. In this case, it obtains the user information from a systemother than the Master User Source.

Change the Master User Source setting only to change the primary system for user data. Ifyou change the Master User Source setting, verify and update any previous custom usermapping and perform a back-end User Sync.

Only systems for which you have created a connector appear in the Select Systemdropdown list.


User Mapping

44 September 2008

User MappingIf you are analyzing multiple systems and a user ID does not represent the same individual ineach system, you must maintain the user mapping. User Mapping links the accounts of theuser, so the system can recognize all of the IDs of a user. This ensures that risk analysisproduces accurate results for each user.

Example

User Mapping allows you to create one user ID mapping to multiple different user IDs for thesame user in several systems. You can define a user ID as the Master User ID and associatethe system name and the user ID for that system. You can define the same Master User ID toother systems, such as an SAP, non-SAP, LDAP, and the like. For instance, in an SAPsystem you set the Master User ID as CPERKINS along with the same system user ID. Youthen can set the same Master User ID (CPERKINS) for a non-SAP with the system user IDof calvin.perkins. And also map an LDAP directory with the same Master User ID with thesystem 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 IDCPERKINS, 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 identifythis user in generated reports.

3. In the System dropdown menu, select the system name on which the secondaryaccount 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, youdo not need to map users.

Custom User GroupsCustom user groups are definable groups that associate user accounts, so they can beprocessed together. You can specify these custom user groups as selection criteria when youperform 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 RiskAnalysis and Remediation or any tab-delimited text file in the following format:

CUSTOM_GROUP_A JSMITH


Upload Objects

September 2008 45

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 ObjectsYou load descriptive (static) text and authorization objects for each Access Control capability.For SAP systems, descriptive text comes from various text tables, and the authorizationobject is SU24/USOBT_C data. You use the Upload Object option to upload objects fordifferent physical systems or for one or more logical systems.

The system uses the descriptive text to complete the report output and provide the textdescriptions 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 lastauthorization object file upload. These default permissions are also included if you add anaction 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

To upload descriptive text from the SAP server:

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 tothe 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 toUpload Objects > Text Objects.

6. Complete the following fields:


Rule Upload

46 September 2008

System ID

If you have connected to multiple SAP systems, enter a single system ID, and repeatthe 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 anapplication server.

If the text must be in multiple languages, the user must log on to the back-end ABAPsystem using the language under which the file should be exported. Run the programas described above for each language that you want to load into Risk Analysis andRemediation, and upload each file as described above.

Uploading Authorization Objects

Procedure

To upload authorization objects:

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 locatedto the right of the Local File field to navigate to the desired directory, and then namethe file. For easy access, store the file on your desktop, and name itSAPAuthObj.txt.

4. Click Execute.

5. Return to Risk Analysis and Remediation, and navigate to Configuration > UploadObjects > Authorization Objects.

6. In the Local File field, enter the specified path (or browse to the location), and specifySAPAuthObj.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 applicationserver.

For more information, see the following sections:Uploading Static Text

Uploading Authorization Objects

Rule UploadRisk Analysis and Remediation is delivered with text files for uploading default action andpermission rules for SAP ERP, APO, CRM, and SRM systems and EC-CS. You can load HR


Rule Upload

September 2008 47

and BASIS rules for SAP ERP systems independently, if desired. Action rules are includedfor selected non-SAP applications as well.

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 systemconnectors before you can upload rules to systems. For example, if you want a specific CRMsystem to be analyzed for SoDs and critical access, you must establish the connector to thatsystem before you can upload rules for that CRM system. Similarly, to monitor a BusinessIntelligence (BI) system for BASIS activities, you must establish the connector to that systembefore 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 tothe 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 orderas the tree structure. You can expand the Rule Upload submenu to display these availableoptions:

Business Process

Function

Function Authorization

Rule Set

Risk

Generate Rules


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

To upload a business process text file:

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

To upload function text files:


Rule Upload

48 September 2008

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.

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

When uploading multiple system rules, upload the file for SAP ERP first. When theSAP ERP rules are loaded against a system, the SAP BASIS and HR files are notloaded since their rules are included in the overall SAP ERP file. Load SAP BASISand 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 thefunctions

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.


Rule Upload

September 2008 49

5. Click Open.

6. In the Rule Set Mapping field, browse for the file [SYSTEM]_Risk_RuleSet.txt.

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.

You can regenerate a rule.


Back-end Synchronization (with Management of Internal Controls)

50 September 2008

Back-end Synchronization (with Management ofInternal Controls)When you integrate SAP’s Management of Internal Controls (MIC) application with RiskAnalysis and Remediation, you must perform a back-end synchronization with MIC. Doingthis transfers the mitigation and rule information from Risk Analysis and Remediation to theback-end ABAP stack where the MIC application resides.

When defining mitigation information in Risk Analysis and Remediation, you can import theinformation 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 inRisk 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 setinformation, whereas synchronization in the background is a scheduled job that happens at adefined 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.

Background JobsUse Background Jobs to schedule synchronization with back-end systems, batch riskanalyses, generation of management reports, and generation of alerts.

When you schedule a background job, you can synchronize in Full mode or Incrementalmode.

Full mode is the synchronization of all user, role, or profile information.

Incremental mode means updating only the information about the user, role, or profilethat has changed since the last synchronization. Risk Analysis and Remediationkeeps track of all synchronization time and date. Therefore, when you want to


Background Jobs

September 2008 51

synchronize in Incremental mode, Risk Analysis and Remediation knows when thelast update occurred and synchronizes only the information that has changed.

You can schedule the information synchronization by using the Batch Risk Analysisoperation. Here you can also do a Full mode or Incremental mode for the following riskanalysis type:

User Analysis

Role Analysis

Scheduling a Synchronization Job

Procedure

To schedule a synchronization job:

1. Log on to Risk Analysis and Remediation.

2. In the Configuration tab, select Background Job > Schedule Analysis.

3. In the Sync Mode field under User/Role/Profile Synchronization, select Full Sync orIncremental.

After the initial synchronization, schedule a nightly job to perform an incrementalsynchronization. Perform a full synchronization periodically as well to ensure dataintegrity.

4. Select the desired synchronization:

User Synchronization

Role Synchronization

Profile Synchronization

5. Select System or accept the wildcard (*) value to perform synchronization for allconnected systems.

6. Click Schedule. The Schedule Risk Analysis 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, andindicate 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.

The following message displays:

Background job scheduled successfully, Job ID: XX.

Scheduling Batch Risk Analysis

Incremental batch risk analysis evaluates only users, roles, and profiles that havechanged in the back-end system. Any changes in the front-end system, such aschanges to rules or mitigation, are not included. Therefore, SAP recommends that youalso run a monthly full batch risk analysis to reflect any front-end changes.

Procedure

To schedule Batch Risk Analysis:

1. On the Configuration tab, navigate to Background Job > Schedule Analysis.


Background Jobs

52 September 2008

2. On the Batch Mode dropdown list, select Full Sync or Incremental.

For non-SAP systems, select Full Sync, and if needed, specify a rule set to apply forbatch analysis.

3. For Rule Set, select an option from the dropdown list.

4. For Report Type, select 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

The Critical Action and Role/Profile Analysis consists of two types of reports thatanalyzes all user information and all associated systems.

6. Click Schedule. The Schedule Background Job screen appears.

7. In the Job Name field, enter a name for this job.


If you want to perform the job multiple times, select Schedule Periodically, and indicatethe frequency as well as the End Date past which no jobs will execute.


The following message displays:Background job scheduled successfully, Job ID: XX.

Scheduling Management Report Generation

Procedure

To schedule generation of the management reports:

1. On the Configuration tab, navigate to Background Job > Schedule Analysis.

2. In the Management Report section, select the Management Reports checkbox.

3. Click Schedule.

The Schedule Background Job screen appears.



If you want to perform the job multiple times, select Schedule Periodically, and indicatethe frequency as well as the End Date past which no jobs will execute.


The following message displays:

Background job scheduled successfully, Job ID: XX.


Background Jobs

September 2008 53

Scheduling Alert Generation

When you generate an action log, the data is loaded to a local table in Risk Analysis andRemediation. You can then 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 riskanalysis. If you select the Consider Mitigated Users option, alerts are generated on user whoare associated with a mitigated risk. The generation of these alert types are useful fortransaction 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 thealert type. By selecting Conflicting Actions and/or Critical Actions alert types, notifications aresent to Risk Owners. Selecting Control Monitoring alert type sends notification to theManagement Approver of the Mitigating Control.

Procedure

To generate alerts:

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 serversthat have connectors created appear in the dropdown list.

4. Select one or more types of alerts to include in the action log.

Conflicting Action

5. Select the Risk IDs and Risk Level.

Indicate whether to Consider Mitigated Users.

By default, the Consider Mitigated Users option is not checked, and the mitigated risks fora particular user do not display in the alerts. Check this option if you want mitigated risksto show up in the alerts.

Critical Action

6. Select the Risk IDs and Risk Level. Indicate whether to Consider Mitigated Users.

Control Monitoring

7. 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. ControlMonitoring notifications are sent to the Management Approver of the Mitigating Control.

8. Click Schedule. The Schedule Background Job screen appears.



Organizational User Mapping

54 September 2008

10. 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 thefrequency as well as the End Date.


Upon completion of scheduling, the following message displays: Background jobscheduled successfully, Job ID: XX.

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

Organizational User MappingYou can perform a risk analysis to identify users who have display or update activitypermissions for an organizational level. This type of analysis is dependent on organizationallevel data for users maintained in Risk Analysis and Remediation. Use Organizational UserMapping to extract and maintain this organizational level data from the back-end sourcesystem.

By mapping users to organizational level, you create an organizational user mapping tablethat is used for filtering the user for organizational level analysis. You can then applyorganizational rules that filters for certain conditions during analysis. For instance, you have aorganizational rule for company code and during the organizational level analysis, only usersthat 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 wantupdated 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.

b. Enter the first listed user in the User field.

c. 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, clickBackground to schedule the job(s).

Custom TabsUse the Custom Tabs menu item to add up to three customer-specific tabs to the RiskAnalysis and Remediation menu. The custom tabs appear to the right of the Configuration tabafter definition of the custom screen’s URL.


SAP Adapter

September 2008 55

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 Webbrowser 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 thetabs user-specific.

SAP AdapterThe SAP Adapter is a continuously running interface between Risk Analysis and Remediationand the SAP back-end system where the SAP Adapter is defined. The SAP Adapter enablesreal-time analysis in the Risk Terminator. Whenever Risk Terminator is triggered in the SAPback-end system, data is transmitted to the SAP Adapter and, subsequently, to Risk Analysisand Remediation. The SAP Adapter performs the risk analysis and sends the results back tothe 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.

UtilitiesThe Utilities options include Export, Import, and Purge Action Usage utilities.

Export Utility

You can export configuration information for Risk Analysis and Remediation that is defined inone system (source) to another system (destination). The Export utility allows you to selectone or many types of data components and transfer them to a define system ID. Thefunctionality of the Export utility is similar to the export tool found in the Rule Architect tab andMitigation tab, but with different data extract files.

The Export utility exports many types of data, including:

Configuration Data

Connectors


Utilities

56 September 2008

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 beginsby identifying the source system of the exported records. A metadata record follows thesource system and identifies the technical table and field names of the exported data. Datarecords follow the metadata record. If more than one type of data was exported, there areadditional sections, each with a metadata record followed by data records.

When you export rules, mitigation, or configuration, dependent tables are included, even ifyou do not manually select them.

ExampleYou want to download User Mitigation. User mitigation entries require a Control ID andMonitor, 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 thegenerated 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 tablesincluded in the export. The Import utility does not append these records to existing records; itoverwrites all existing entries. As a precaution, if configuration or mitigation records exist inthe system to which you are importing new data, export all configuration or mitigation entriesfrom that system as a backup. The system notifies you at the time of loading the data that thisprocess will overwrite all existing entries.

The Import utility overwrites all existing entries; it does not append records. Ifconfiguration 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 areoverwritten.

Purge Action Usage Utility

The Purge Action Usage utility archives records from time periods that are no longer ofinterest. This utility reduces the size of large databases or files. The system stores the purgedaction usage data in the file location specified during configuration.

Purging action usage records affects the SoD Review and User Access Review reports ofother capabilities, since they use the database tables. Purging action usage does notimpact Risk Analysis and Remediation reports, since they access the archived files inaddition to the action usage tables.

During configuration, specify the date when you want to retain action usage data and themaximum records allowed in each file. If you schedule a foreground job, a message confirmsthe date. If you purge the actions in the background, you can schedule a job and determinehow frequently to execute it.


Risk Terminator

September 2008 57

When you purge data, the system purges the action usage data in the Alert file locationspecified during configuration. Follow change management procedures prior to purgingaction 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 thecurrent 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 usagecompleted successfully.

Risk TerminatorRisk Terminator is a service that resides in the back-end SAP ERP system to notify you whena 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 Terminator creates a log entry when you add transactions using the:

PFCG Menu tab and click Change Authorization Data

PFCG Authorizations form and click Generate

Activities

Determine which SAP operations to analyze with Risk Terminator. Proceed with configuringRisk 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 ofyour 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.


Risk Terminator

58 September 2008

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 logginginto the back-end system and executing transaction SM59. Double-click the TCP/IPConnection 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 CCrelease to beused

Tells Risk Terminatorwhat version of RiskAnalysis and Remediationis used for the SoD rules.

Set to CC5.X

RFCdestination forrelease CC5.X

References the RFCconnection.

Enter the name of the RFC destinationcreated previously in transaction SM59.

PFCG Plug in Determines behavior atrole creation or changewith PFCG.

To have Risk Terminator checked whencreating or changing roles with PFCG, setthis parameter to Yes.

PFCG UserAssignmentPlug-In

Determines behavior atrole assignment withPFCG.

To have Risk Terminator checked whenassigning a role to a user with PFCG, setthis parameter to Yes.

SU01 RoleAssignmentPlug-In

Determines behavior atrole assignment withSU01.

To have Risk Terminator checked whenassigning a role to a user with SU01, setthis parameter to Yes.

SU10 MultipleUser RoleAssignment

Determines behavior atrole assignment tomultiple users with SU10.

To have Risk Terminator checked whenassigning roles to multiple users withSU10, set this parameter to Yes.

StopGeneration

Stops generation ifservice detects that aviolation exists.

To allow role generation and userassignments with SoD violations, set thisparameter to No.

Comments areRequired

Determines whethercomments are requiredwhen the service detectsa violation.

To force the system to prompt you to entercomments for any SoD violations foundwhen you use transactions PFCG, SU01,or SU10 to generate roles or to make userassignments, set this parameter to Yes.

To view comments, see the Log Report.

SendNotification

Determines whether tosend notification whenservice detects a violation.

To have the system send an email to thedesignated user when a violation isdetected, set this parameter to Yes.

Doing this displays Risk Owner and RoleOwner checkboxes.

Notify RoleOwner

Determines whether RoleOwner is notified whenservice detects a violation.

Selecting this checkbox provides emailnotification to corresponding role ownerswhen Risk Terminator identifies a violation.


Additional Configuration Options

September 2008 59

Risk Terminator Configuration Parameters

Parameter Purpose Setting

Notify RiskOwner

Determines whether RiskOwner is notified whenservices detects aviolation.

Selecting this checkbox provides emailnotification to corresponding risk ownerswhen Risk Terminator identifies a violation.

DefaultAnalysis Level

Specifies the type ofanalysis Risk Terminatorperforms when you clickthe Change AuthorizationData button on the PFCGAuthorizations tab.

This setting determines the level of SoDviolations to be reported by RiskTerminator.

If you select Object Level Analysis, RiskTerminator reports object (permission)-level violations. The report form includesan option to perform action-level analysisand an option to toggle the analysis-levelsetting each time you generate a report.

Define risk owners through the Alerts Module Email Configuration form. If a Risk ID isassociated with an email address specified in the Email Configuration form, thesystem sends an email to that address. If no email address is associated with anidentified Risk ID, the risk owner does not receive a notification.

Additional Configuration OptionsAdministration for RTA Supported Systems

Real Time Agents (RTAs) are required for real-time communication between Access Controland the back-end system. RTAs are also provided for some non-SAP systems. Agents areavailable from the GRC software download area of SAP Service Marketplace. To requestaccess to them, open a CSS message. Installation guides for these agents are packagedwith the software.


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

Before extracting data from your legacy system, read SAP Note 1131003, which includestips on using a control file to facilitate the loading of multiple files, how to calculate forextracted files, loading of data files, and using the Comparison Utility tool.

Perform these tasks only to include legacy systems in analysis operations. Tasks includecreating 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 itmust be in tab-delimited text files in the format specified in Appendix B: Data MappingTemplates. After creation, and then periodically thereafter, place the files on an applicationserver in a specific folder structure for uploading to Risk Analysis and Remediation. For moreinformation, see the section Initial Setup for Non-RTA Supported Systems. Since manysystems do not store deleted users or dates of last change, a utility compares the new data



60 September 2008

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, itcreates a new file, which contains only incremental changes.


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 systemsnot supported by RTAs. You can perform Risk Analysis against users and roles for thesesystems.

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

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 theUser/Role/Profile Synchronization.



September 2008 61

Create a Connector for a Non-RTA Systems

Use this information to create a connector for a system not supported by RTAs. You mustcreate 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 CreateConnector 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 andreference 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 notsupported by RTAs (legacy systems) with the user and role authorization data. Before doingthis, understand the legacy system methodology and map it to the security model of the SAPsystem. 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 Analysisand Remediation.

The following table maps the methodology of a legacy system to that of SAP. This mappingensures that the data loading is in an accurate format.

Risk Analysis andRemediation Name

SAP Name Legacy Name (non-RTAsystem)

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

After completing the mapping, extract the definition files from your legacy system in theproper 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 needcorrect data from the security structure. You may need to create a custom program inyour legacy system to extract the data. The extraction process is not a one-timeprocess but rather a periodic one. Make sure that you can repeat the extractionprocess for updating Risk Analysis and Remediation.



62 September 2008

Data Mapping for Non-RTA Supported Systems

Extract six to eleven key files from your legacy system for analysis. The actual number of filesdepends on the security structure of your legacy system. When extracting these definitionfiles; 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 suchas ID, name, email address, department, anduser group.

Target Definition User Action File(Required)

This file contains a list of user IDs and thecorresponding actions that they access in thelegacy system.

It is important that you map the actions thatyou extract to your defined rules. Otherwise,Risk Analysis and Remediation will not reportresults correctly.

User Permission File (Optional) This file contains data similar to theauthorization objects in SAP.

It is optional because the file depends on thesecurity structure of your legacy system. Ifthere is no permission concept associated withthe actions in the legacy application, there isno reason to load this data. However, this file isrequired if permissions do exist and your rulesinclude 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 conceptof roles in the legacy application. If so, thenthere is no reason to create this file. However,if the legacy application groups the actions intoa 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 withthe role ID in the User Action File. The actionsin this file must also match the action IDs thatare used in creating roles.

Role Permission File (Optional) This file is similar to the User Permission File.

If your legacy system does not usepermissions, this file is not required.

Profile File Target Definition (Optional) This file contains the Profile ID and user name.

A profile is a grouping of actions. In somelegacy 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.



September 2008 63

Profile Permission File (Optional) Like the Role Permission File, if your legacysystem does not have permissions, this file isnot required. However, if you do use it, makesure that you translate your legacy systemsecurity model to SAP terminology.

Action Permission Objects This table contains the relationship of actionsto permissions. Risk Analysis and Remediationuses this data when new actions are loadedinto rules or when simulation analysis occurs.

Depending on how often your master datachanges, you should reload this data. Thistable is comparable to transaction SU24 (TableUSOBT_C) in SAP.

Description File for Action, PermissionFields, and Values(ACT_PRM_FLD_VAL File)

This table contains data for action andpermission descriptions.

It is comparable to table, TSTCT. Dependingon how often your master data changes, youcan reload this data.

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

Upload Objects to Risk Analysis and Remediation

Use this information to upload objects from Action Permission Objects file and DescriptionFile for Action and Permission Fields, and Values. These are tables that contain action andpermission objects from your legacy system that you need before building your rules in RiskAnalysis and Remediation.

For Action Permission File, upload the objects using Auth Objects mode, whereas forDescription 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 theprocedure is similar for the Auth Objects mode.

Procedure

To upload objects:

1. Go to Risk Analysis and Remediation > Configuration tab > Upload Objects > TextObjects. The Text Objects Upload screen appears.

2. In the System field, enter the identifier of the non-RTA system. For this, use thesystem ID you created for the connector.

3. In the Local File field, enter the full path of the text file or click Browse to navigate tothe 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.



64 September 2008

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 requireall nine files listed. Systems that have security controlled at an action level can skip the userpermission, role permission, and profile permission files (files 3, 6, and 9).

For more information about the referenced files, see Appendix B: Data Mapping Templatesfor Non-RTA Supported Systems.

Technical Requirements

This section provides the technical requirements for file generation from legacy systems forintegration with Risk Analysis and Remediation. This information is based on the eleven filesin 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 theloading.

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 inthe 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 youstore a maximum of 60,000 records in a file. If the data exceeds 60,000 records, create acontrol file and multiple load files. You can use the Data Extractor to manage all files inthe 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 asthe tab-delimited file name, Access Control uses the control file to retrieve each file byuploading 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 ofUSERID, ROLE, ACTIONFROM, and ACTIONTO fields must be unique.

For more information about the referenced files, see Appendix B: Data Mapping Templatesfor Non-RTA Supported Systems.

The data extractor must generate the PRMGRP field in numerical sequence by USERID orROLE and PERMISSION. The system does not allow duplicates of this combination.

Analyze and Create Rules

Understand the security methodology of your legacy system before you begin creatingrules.

If you already have Risk Analysis and Remediation deployed in your organization, you haveprobably defined the functions and risks during the implementation. Therefore, you are notrequired to create new functions or risks, but rather add the security data from your legacysystem to the existing functions.

To ensure a complete analysis of your security methodology, evaluate all actions used inproduction by end users. Determine which actions allow the end user to perform functions



September 2008 65

that are defined in Risk Analysis and Remediation. Once an action is associated with afunction, 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 toyour legacy system.

Procedure

To search and modify a function:

1. Go to Risk Analysis and Remediation > Rule Architect tab > Search. The SearchFunctions 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 allexisting functions. All functions that meet your search criteria appear in the SearchResults pane. Select the function to modify.

3. Click Change. The Change Functions screen appears. There is an Actions tab andPermissions 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 setSingle 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 youcreate is only for a single system. For example, you can have 10 systems undera 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 usedin cross system risks and cross system rules to be built where applicable. If youset a function to Cross System, then the system generates rules across othersystems for all risks that have that associated function.

Only set a function to Cross System when there are conflicting actions acrossthe systems. Risk Analysis and Remediation limits the risks to 46,656 totalrules. If you have a function with thousands of actions, and it is set to CrossSystem, 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-RTAsystem.

7. In the Action column, enter the action name from your legacy system.

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 aconnected system. The major difference is that management reports are based on the datauploaded 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 dataextraction is performing the data synchronization. Also, since the data extraction overwritesthe data in the database, there are no dates that show changes. The data is overwritten. For


Additional Tabs

66 September 2008

this reason, only perform full batch risk analysis. Do not run incremental batch risk analysisfor 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 > ScheduleAnalysis. The User/Role/Profile Synchronization and Batch Risk Analysis screenappears.

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 (asopposed to doing them all at one time). Select the Management Report checkbox foreach 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 startdate 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 jobto run for that period.

11. In the End Date field, enter a date to end the job. You can use the Calendar icon to enterthe date.

12. Click Schedule. Otherwise, click Reset.

Additional TabsInformer Tab

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

You can generate reports for users, user groups, roles, profiles, HR objects, andorganizational levels. Each option on the Informer tab’s navigation bar represents a differentreport.

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


Additional Tabs

September 2008 67

Background Job: Reports generated by background jobs.

For more information, see the SAP GRC Access Control 5.3 Application Help on SAP HelpPortal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance ->SAP 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 providesutilities to import and export definitions, view changes to functions or risks, and define andview:

Rules

Business Processes

Rule Sets

Functions

Risks

Critical Roles

Critical Profiles

Organizational Rules

Supplementary Rules


Mitigation Tab

The Mitigation tab mitigates risks that cannot be removed by modifying access. This includesmaintaining the following types of data manually or with export/import utilities and using thedata to mitigate users, roles, profiles, HR Objects, or users at organizational levels.

Mitigating Controls

Administrators

Business Units

Control Monitors


Alert Monitor TabThe Alert Monitor tab defines how alerts are generated and cleared for:

Conflicting Actions

Critical Actions

Controls


4 Superuser Privilege Management

Initial Configuration in the Back-end ABAP System

68 September 2008

4 Superuser Privilege ManagementInitial Configuration in the Back-end ABAP SystemTo set up Superuser Privilege Management, you must perform the following initialconfiguration 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 andtransaction use.

Set configuration parameters.

Configuration parameters define role-based and ID-based activities, mail preferences,and report preferences.


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 SAPNote 992200 Firefighter User Exit.

Remote Function Calls

You configure a remote function call (RFC) destination to call an RFC-enabled functionmodule. Superuser Privilege Management uses this RFC each time a Firefighter ID logs onand creates a new session.

Recommendation

SAP recommends that you use the three-character SAP system ID as the default RFCdestination. If you create a new RFC destination, make sure that the name is basic and doesnot 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.

6. When you have created the RFC, enter the RFC name in the Configuration Parametertable and save it.



September 2008 69

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 GRCSecurity Guide. There is a delivered, default role (/VIRSA/FF_DEFAULT_ROLE) for thesystem ID that performs background jobs in the ABAP system. You can use the default roleas provided. If you choose to customize the role, ensure that it has the following authorizationvalues:

ABAP Objects and Authorization Values

Object Definition Authorization Values

S_RFC Authorizationcheck for RFCaccess

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

ZVFAT_0001 ACTVT *

ZVFAT_0002 /VIRSA/FAT *

Assigning Default Role to Firefighter ID

In order for a user to access the capabilities of Superuser Privilege Management, you mustassign 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

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

Procedure

To define the background job for log reports:

1. Run transaction SM36.

2. Enter a job name.

For example: /VIRSA/ZVFATBAK



70 September 2008

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

Configuration Parameters

The configuration parameters specify the handling or behavior of log information, criticaltransactions, roles, and IDs. The following table describes each parameter.

Configuration Parameter Behavior

ParameterName Definition Behavior

RemoteFunction Call

Superuser PrivilegeManagement requires an RFCdestination to log on.

Enter the RFC destination that you createdwith transaction SM59.

RetrieveChange Log

Specifies the amount of changelog information you capturewhen the background jobexecutes. Superuser PrivilegeManagement captures two loglevels: a transaction log and theSAP change log. It captures thetransaction level informationfrom the STAT Data and thechange log information from theCDHDR/CDPOS tables.

To capture the transaction and thechange log information, set thisparameter to Yes.

To capture only the transaction loginformation, set this parameter to No.



September 2008 71



CriticalTransactionTable fromRisk AnalysisandRemediation

Superuser PrivilegeManagement reports criticaltransaction use in the log for thefollowing cases:

- You are using Risk Analysisand Remediation to maintaincritical transactions there, and

- Risk Analysis and Remediationand Superuser PrivilegeManagement reside on thesame server.

If both these conditions are met,you can configure SuperuserPrivilege Management to usethe Risk Analysis andRemediation data rather thanduplicate maintenance.

To use the critical transactions definedin Risk Analysis and Remediation, setthis parameter to Yes.

To use the critical transaction defined inSuperuser Privilege Management, setthis parameter to No.

Assign FFRoles Insteadof FF IDs

This parameter switches theinterface from Firefighter ID-based administration toFirefighter role-basedadministration.

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

To use Firefighter roles, set thisparameter to Yes.

Default RoleExpiration inDays

This parameter is in effect onlywhen the Assign FF RolesInstead of FF IDs parameter isset to Yes.

It determines the assignmentlength, in days, of Firefighterroles, but it can be over-riddenat the time of role assignment.

If a From date is specified in theFirefighter dashboard, the To date isincremented by this number of days.

If you do not specify a From date, itdefaults to the current date. The Todate increments by this number of days.

If you assign valid From and To datesto a Firefighter, these dates override thedates in this parameter.

Auto ArchiveLocation

Use this parameter to specify afolder for the Auto Archivefeature.

Specify the folder location where archivefiles are stored.

FirefighterOwnerAdditionalAuthorization

Each Superuser PrivilegeManagement has a definedowner. This parameter overridesthe defined owner privileges.

To allow only the defined owner of aFirefighter ID to view and assign theFirefighter ID, set this parameter to Yes.

To allow any owner to view and assignthat Firefighter ID, set this parameter toNo.



72 September 2008



ConfigurationChangeCommentRequired

This parameter makes acomment mandatory forchanges to configuration. Thecomment will be provided in theConfiguration Change LogReport.

To make a comment mandatory, setthis parameter to Yes.

To make a comment optional, set thisparameter to No.

ControllerAdditionalAuthorization

This parameter providesadditional authorization to acontroller.

To allow users to maintain controllersfor those Firefighter IDs for which theyare the owner or administrator, set thisparameter to Yes.

To allow any user to maintaincontrollers, set this parameter to No.

Send LogReport withCriticalTransactionsOnly

Use this parameter to send logreports with critical transactionsto the controller as an emailattachment.

To send a log report that contains onlycritical transactions to controllers, setthis parameter to Yes.

To send a log report that contains alltransactions to controllers, set thisparameter to No.

Send LogReportExecutionNotification

This parameter specifieswhether log reports that containinformation about Firefighteractivity are emailed tocontrollers.

To send an email to a controller withFirefighter log information, set thisparameter to Yes.

To send no log information to thecontroller, set this parameter to No.

Send LogReportExecutionNotificationImmediately

This option specifies whetherthe log reports are sent to thecontrollers as soon as thebackground job(/VIRSA/ZVFATBAK) isexecuted or at a predefined dateand time. If you want the job torun at different intervals, youmust use an external schedulingtool.

To enable this parameter,set the Send Log ReportExecution Notification toYes.

To send log report email notifications tothe controller inboxes as soon as the/VIRSA/ZVFATBAK job runs, set thisparameter to Yes.

If you plan to receive the job at regularintervals, schedule the job/VIRSA/ZVFAT_LOG_REPORT atregular intervals, and set this parameterto No.

SendFirefighter IDLogonNotification

This option specifies whether tosend a logon notification emailto controllers with informationabout when a Firefighter sessionwas started and by which user.

To send an email to a controller withFirefighter logon information, set thisparameter to Yes.

To send no email with Firefighter logoninformation to a controller, set thisparameter to No.



September 2008 73



Send LogonNotificationImmediately

This option specifies whetherthe logon notifications areemailed to the controllers assoon as they are run or whenthey are scheduled.

To send an email to a controller withFirefighter ID logon information aftereach logon session, set this parameterto Yes.

To schedule the/VIRSA/ZVFAT_LOG_NOTIFICATIONreport at regular intervals, set thisparameter to No.

Connector IDfor RiskAnalysis andRemediation

This option checks for SoDviolations.

Enter the connector ID of the Risk Analysisand Remediation capability.

See the section, DefiningConnectors for Risk Analysis andRemediation for connector IDinformation.

Configuring a Parameter

The administrator must configure and maintain configuration parameters. Superuser PrivilegeManagement is not shipped with configured parameters.

Procedure

To configure the parameters:

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 theConfiguration Parameter Value list.

Email Configuration

You configure email messages the same way for both ID-based and role-basedadministration. To enable a user for email, set the following configuration parameters foremail notifications on the Configuration tab.

Send Firefighter ID Logon Notification

Send Logon Notification Immediately

Send Log Report Execution

Send Log Report Notification Immediately

You must also set the controller's Usage Flag Information field in the Controllers table toEmail or Workflow.

To receive log email messages, ensure that you run the /VIRSA/ZVFATBAK reportbefore you submit the /VIRSA/ZVFAT_LOG_REPORT.


Defining Connectors for Superuser Privilege Management

74 September 2008

Reason Codes

Reason codes describe each task that a Firefighter expects to perform. For example, areason code might be a technical support case number. The reason code must be clear sothat the Firefighter understands the task that it represents. To enable users to search or filterthe Reason and Activity report, or the Log Report by reason code, the reason code statusmust 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.

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 supportissue, 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 PrivilegeManagementYou use the Superuser Privilege Management connector to access web-based reports. To dothis, you must first create a URL using the following format:http://<servername>:<port>/webdynpro/dispatcher/sapgrc/ffappcomp/Firefighter

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

Access Control communicates with multiple systems. SAP recommends using HTTPScommunication protocol for secure communication.

To interface with other Access Control capabilities, ensure that the connector names arethe same in each capability.

You must also create a connector to establish a connection between Superuser PrivilegeManagement and Risk Analysis and Remediation when both capabilities are not installed onthe same system.



September 2008 75

For Superuser Privilege Management to interface properly with Risk Analysis andRemediation, follow the instructions in SAP Note 1055976 - Firefighter 5.2 - Unable to runthe SoD analysis report.To ensure that the connector works properly, verify that you have the following authorizationsfor S_RFC and SVFAT_0001. The BASIS Security Administrator creates a role using theauthorization objects in this table. The role is assigned to a user ID, which is used whencreating a connector. Make sure that the authorization object’s fields and values areconfigured appropriately. See the SAP GRC Access Control 5.3 Security Guide in SAPService Marketplace for more information.

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 PrivilegeManagement 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 serverwhere Superuser Privilege Management is installed and the system you are connectingto. 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 beobtained 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 passwordcontains eight characters.



76 September 2008

Deleting a Connector

Procedure

To delete a connector:

1. Using the URL supplied by your administrator, log on to the Superuser PrivilegeManagement administration dashboard.

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 description, a complete list of allavailable 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 PrivilegeManagement 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 availableconnectors 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 PrivilegeManagement 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


Archived Data for Log Reports

September 2008 77

Connector Field Description

Connector ID Name of the connector.

ConnectorDescription

Description for the connector.

Application Server The host name or IP address of the SAP server where SuperuserPrivilege Management is installed and the system you areconnecting to.

You obtain this information from the SAPGUI Logon pad.

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 ReportsThis 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 adownload or as an archive.

Superuser Privilege Management saves data in three text files, each of which archivedifferent 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 havepreviously downloaded.

The Download button on the ID-based log report downloads the SLOG, TLOG, and CLOGfiles as one consolidated file. You must perform any changes to the downloaded filemanually.SLOG Files

Files that end with SLOG store Firefighter ID logon events. Each row in the spreadsheetrecords 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 clocktime, format the column in a time format. SLOG files are not available in the role-basedreport.TLOG Files

Files that end with TLOG store transaction type records. Each row in the spreadsheet is theTransaction Type record for the corresponding row in the SLOG table. The column headingsare: Firefighter ID, Transaction Date, Transaction Time, Server Name, Transaction Code,Report Name, and Report Title.



78 September 2008

TLOG files display the Transaction Time column as a number. To display the value asclock 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, ChangeIndicator, Old Value, New Value, and Change Document Number.

The CLOG file displays the Transaction Time column as a number. To display the valueas 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 rangeof Firefighter IDs.

If you leave these text fields blank, Superuser Privilege Management downloads all logonevents 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, TransactionLog, 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 ApplicationServer File field is automatically populated with a location. You can enter a differentlocation 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 changelogs are archived.

Delete Log Data after Archive – If you select this option, the three logs are deletedfrom Superuser Privilege Management after they have been archived.

Upload Log Data – If you select this option, archived log data is uploaded toSuperuser Privilege Management.

4. Define how you want to perform the archiving:



September 2008 79

If you click Background Job, the background job scheduler appears and you candefine the date and time you want to schedule the job.

If you click F8 or Execute, the archiving runs in the foreground.

5 Compliant User Provisioning

Prior to Configuration

80 September 2008

5 Compliant User ProvisioningCompliant User Provisioning simplifies the provisioning of access to system users. You canuse 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 informationand approvals necessary to grant access to system users. Once deployed, the workflowsmanage each provisioning requests by tracking its progress through the different stages andby gathering the necessary approvals. At the end of the workflow, the request has all theapprovals required to provision access for a user. Compliant User Provisioning then passesthe collected information to the user or department responsible for the provisioning, orautomatically uses a remote function call to launch the actual provisioning process.

Prior to ConfigurationBefore you configure Compliant User Provisioning, you must complete the installationprocess. This includes the software installation and certain one-time configurationprocedures, such as creating the initial administrative user and importing roles.

For more information, see the SAP GRC Access Control 5.3 Installation Guide on SAPService Marketplace at http://service.sap.com/instguides -> SAP SolutionExtensions-> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC AccessControl 5.3.

Integration

To ensure that your installation is complete:

Ensure that you have applied all real time agents (RTAs) have been applied to allCompliant 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 modelingyour provisioning processes. Compliant User Provisioning uses workflows to replicate ormodel the provisioning process, and to collect the information necessary to carry out aprovisioning request. The process for creating workflows is straightforward if you know inadvance:

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 reflectbefore you create the workflow. For more information, see the section Managing Workflows.

Preparing to create workflows requires some research. Typically, you build a profile orspreadsheet of each provisioning process for which you want to create a workflow. After youhave completed a profile that details each step of the process, you can create and deploy aworkflow that implements that process.

The information in a provisioning process includes:


Basic Functionality

September 2008 81

Provisioning Process Information

Provisioning ProcessInformation Description

What specific conditioninitiates the request?

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

How many levels of approvaldoes the request require?

Each organization has unique requirements for how manypeople must approve a user access request. In addition, someuser roles might require only one or two approvers, whileothers might require three or more. This typically depends onthe nature and sensitivity of the requested user role. For eachof your provisioning processes, make a note of how manylevels of approval are required.

For each level of approval,who is authorized to approvethe request?

For each step in the process, determine who is responsible forapproving or denying a request. This can be an individual useror, in some cases, any one of a group of users.

What happens if any of theassigned approvers choosesto deny the request?

Determine what action must be taken if a designated approverdenies the request. This can include steps to mitigate risk, toprovision only the approved portion of the request, or to abortthe provisioning process entirely.

What happens if any of theassigned approvers fail torespond to the requestwithin a specified period oftime?

To expedite the provisioning process, set a limit for how longan approver has to approve or deny a request. You must alsodecide what must happen to the request if an approver doesnot act within the specified period.

Is a partial approvalacceptable for the request?

If a request includes more than one user role, it is possiblethat one role in the request could be approved and anotherdenied. Define what must happen in that situation.

In the event that the requestis ultimately approved,should Compliant UserProvisioning automaticallyinitiate provisioning?

Compliant User Provisioning does not actually perform theprovisioning process. Completing a workflow assembles theinformation and approvals necessary for provisioning.However, you can set a workflow to start the provisioningprocess. Depending on how your organization prefers toconduct provisioning, you might need to determine whether ornot to automatically begin provisioning when a request isapproved.

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

Basic FunctionalityYou can classify functionality into three basic categories:

Creating requests

Performing risk analysis


Key Concepts

82 September 2008

Approving/denying requests

Administration

Creating requests and approving/denying requests are requestor/approver functions.Compliant User Provisioning supports these functions by providing a Web-based interface forrequestors and interacting with approvers through email.

This guide describes administration functions that enable you to create and deploy theworkflows that manage the provisioning request process. Requestors and approvers followpredefined paths to assign user permissions. Administrators define those paths.

As an administrator, you configure Compliant User Provisioning and use it to create anddeploy workflows.

Key ConceptsTo understand better the descriptions and procedures in this section, familiarize yourself withthe following keys concepts, which are intrinsic to Compliant User Provisioning:

Compliant User Provisioning Key Concepts

Key Concept Description

ProvisioningAccess

When you provision access for a user, you enable that user to connect to aspecific business module. That is, you allow a specific user account andpassword combination to log on to that module. In most cases, the accessyou grant to the user is restricted to the tasks that user must perform. It canalso be restricted to certain systems or applications. Additionally, you usethe provisioning process to change or remove a user’s access.

In Compliant User Provisioning, the terms provisioning or provisioningaccess refer to the process of defining the modules and systems to which auser has access.

Roles andRoleAssignment

Compliant User Provisioning supports provisioning for ERP systems inwhich user access is role-based. A role is a predefined set of accesspermissions. Access is not granted to individual users but rather to roles.

If, for example, you want to provision access to a financial application for auser, you must assign that user a role that has access to the application. Ifthe user has the required role, he or she automatically has access to theapplication.

Since different users may need to access the same module or applicationbut might also require different levels of access, there are typically multipleroles that include some form of access to any given application. The rolesassigned to a user define which applications the user can access and thelevel of access the user has.

Role assignment is the fundamental starting point for the provisioningprocess. A request defines a user and the role(s) to be assigned to the user.

Risk Analysisand Mitigation

The identification and mitigation of risk is a key element of provisioning. Arisk is a conflict between roles assigned to a user. In most organizations, forexample, the roles Receiving, Inventory, and Accounts Payable are mutuallyexclusive. To prevent the risk of fraud, a user responsible for catalogingdeliveries cannot also have the ability to catalog inventory, nor can that userhave 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


Users

September 2008 83

analysis.

If analysis determines that a provisioning request poses a risk, you haveseveral ways to mitigate the risk. Risk mitigation refers to the actions youtake to lessen or remove an identified risk. When you define the provisioningprocess for a role, you can include risk mitigation options for some of yourapprovers. The approvers can then choose to take action to mitigate a riskor to deny the provisioning request.

Workflow A workflow defines the steps required to approve the assignment of one ormore roles to a specific user. The workflow catalogs the steps of the processand identifies the people required to approve the request.

Workflows are intended to model the business processes your organizationalready has in place to authorize access. In practice, you may want torethink your approval processes as you create your workflows (preferablybeforehand).

When you have created and deployed a workflow, other Compliant UserProvisioning requestors and approvers use it to request access for otherusers.

Request andApproval

Administrators are responsible for creating workflows, but other usersusually use the workflows. They do so by either making requests or bygranting or denying approval.

In Compliant User Provisioning, a request is an official message asking foraccess for a user (referred to as initiating a request), and the user who doesthis is the initiating requestor or requestor. A requestor is any authenticateduser who initiates a request on their own behalf or on behalf of another user.

Depending on your organization, you may be able to configure whichtypes of access a requestor can request or whether or not a requestorcan select specific access types at all.

After a user initiates a request, it must be approved. Request workflows aremade up of one or more stages. At each stage, the request requires theapproval of the user (approver) designated in the workflow for that stage.

UsersThere are three types of user, each corresponding to a basic Compliant User Provisioningfunction:

Compliant User Provisioning User Types

User Description

Requestor Requestors create provisioning requests, which ask for a specific user to beassigned to one or more user roles. Each request initiates a workflow, aprocess requesting approval of the role assignment from designatedapprovers.


Administration Tasks

84 September 2008

Compliant User Provisioning User Types

User Description

Approver Approvers either approve or deny provisioning requests. Compliant UserProvisioning interacts with approvers through email. At each stage of aworkflow, users are designated as the approvers for that stage, and thoseusers 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.

Administrator Administrators create and deploy workflows. These workflows are designed tofollow the organizational path for assigning roles to a user. Administrators areresponsible for ensuring that the workflows they create accurately reflect thecorrect process, designating the correct approvers, and achieving the correctprovisioning result.

Each of these users must be assigned the appropriate role(s) in the User ManagementEngine (UME), and the roles determine who has the authority to act in which capacity. Forexample, only users with the requestor role can create new requests; only users with theadministrator role can create and deploy workflows.

Administration TasksWhen you are sure that Compliant User Provisioning is correctly installed and you documentthe business processes your organization follows to provision user access, you are ready toperform administration tasks. These tasks fall into two categories:

Configuring Compliant User Provisioning in preparation for creating and deployingworkflows

Workflow management, including creating, validating, modifying, deploying, and deletingworkflows

The primary administration task is creating the workflows that implement the processes. Asan 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 thedetails before you begin creating workflows.

Prerequisites

When you configure Compliant User Provisioning, you define the details that are the buildingblocks for workflows. Before you begin configuring or creating workflows, however, completeyour preconfiguration responsibilities:

Work with your business process owners to capture and record the approvalrequirements 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

September 2008 85

Preconfiguration TasksSetting up Compliant User Provisioning involves configuring or defining connectors, datasources, security settings, Web services, and many other objects that you use when youcreate workflows.

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 requestorsand approvers. As an administrator, you must configure Compliant User Provisioning so itmeets your business requirements. Gather all essential information prior to setting upCompliant User Provisioning.

Complete the pre-workflow configuration tasks in the order listed below. After configuring theinitial 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


Preconfiguration Tasks

86 September 2008

Defining Password Self Service

Setting Up Background Jobs

Creating Custom Fields

Compliant User Provisioning modifies your configuration to reflect your current businessmodel. However, it is important that you correctly configure it before using it in a productionenvironment.

Initializing System Data - Initial Logon

After installing Compliant User Provisioning, use a Web browser to log on and access theapplication.

To do so, enter either of the following URLs in your browser:

The GRC Access Control launch pad works for approvers and administrators. Whenselecting Compliant User Provisioning from the launch pad, you bypass the RequestAccess screens and display the main screen within Compliant User Provisioning. Thestructure of the Access Control launchpad is:http://<server_name>:<port_number>/webdynpro/dispatcher/sap.com/grc~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 Controlresides, 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 Provisioninghome 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, thesystem displays the access request types configured for your system. When you selectan 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 anadministrator to gain access to the My Work tab, the Informer reporting tab, and/or theConfiguration tab.

The access you gain to Compliant User Provisioning depends on the User ManagementEngine (UME) roles/permissions granted by your system administrator.

All Compliant User Provisioning roles are defined in the UME. UME administrationrights are required to assign Compliant User Provisioning roles.


Initialization System Data

September 2008 87

Initializing System Data - Required User Management Engine Roles/Permissions

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

When defining Compliant User Provisioning roles, define the UME roles with the permissionsthat you would like each user to have. Approvers may have different permissions based ontheir responsibilities. For example, some approvers can create mitigating controls from withinCompliant User Provisioning, but some cannot.

Requestors do not need specific UME permissions to create a request, althoughdepending on the configuration settings, they may need to exist in the AuthenticationSystem. For more information, see the section Authentication Source for Requestors.

All other users (approvers and administration users) must be assigned specific UMEpermissions to access Compliant User Provisioning through the User Logon option.

On the SAP NetWeaver Server Index Screen, click User Management to create roles andassign them to users.

The following are the roles that Compliant User Provisioning provides:

Roles are provided with the installation files and must be uploaded into the UserManagement Engine during the installation process.

AEAdmin

AEApprover

AESecurity

For more information, see the SAP GRC 5.3 Access Control Security Guide on SAP ServiceMarketplace at http://service.sap.com/instguides -> SAP Solution Extensions-> SAPSolutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Initialization System DataBefore you begin configuring Compliant User Provisioning, you must import initial systemdata. This data is the default system data that is prepackaged with the system. It is theminimum set of data required for the application to function properly and is imported directlyfrom the application itself.

Import initial data only if it was not done during the post-installation phase of the SAP GRCAccess Control installation process. For more information, see the SAP GRC 5.3 AccessControl Installation Guide on SAP Service Marketplace athttp://service.sap.com/instguides -> SAP Solution Extensions-> SAP Solutions forGRC -> SAP GRC 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.


Configuration Tasks

88 September 2008

Insert

Append

Clean and Insert

5. The files you import are:

AE_init_append_data.xml – Select append

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 dataoriginally shipped with Compliant User Provisioning.

6. Click Import.

Configuration TasksIntegrating with the System Landscape Directory (SLD)

Integration with SLD allows for scenarios where the SAP back-end system and the AccessControl server are on different networks.

Connection data is maintained only once in SLD and can be shared across Compliant UserProvisioning, Superuser Privilege Management, and Enterprise Role Management. When theinformation 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 SNCinterface and the SAP cryptographic library, all connector communication can be encrypted.This enbles you to protect password transmission from Compliant User Provisioning to SAPback-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 theappropriate back-end systems via connectors. This is essential to provision approved usersto the back-end systems. Compliant User Provisioning supports several connector types forthe back-end systems.

Access Control communicates with multiple systems. SAP recommends using HTTPScommunication 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 SAPsystems, non-SAP systems, SAP Enterprise Portal, LDAP, and other systems. By configuring


Configuration Tasks

September 2008 89

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 datasources including their sequence order for extracting data. The supported multiple datasource 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 SourceDefinition.

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 > CreateConnectors. The Connectors screen appears.

2. In the Connector Type dropdown menu, select SAP.

Any field name denoted with an asterisk (*) is required. To complete theConnectors screen, obtain the connection information from your networkadministrator and BASIS administrator.

3. In the Name field, enter a name for the connector.

The connector names are important when integrating with other GRC productsand the CUA. Make sure that the connector name for Access Control is the sameas the one configured for CUA.

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 Application field, enter the name of the application or application server.


Configuration Tasks

90 September 2008

7. In the Application Server Host field, enter the host name of the application server.


9. In the Client field, enter the SAP client number.

10. 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 tasksrequired. If provisioning is configured for this connector, this user ID must haveauthorization access to maintain users in the SAP system. If provisioning isconfigured, this user ID appears on each change record on the SU01 user masterrecord.

For more information on user ID authorization, see the SAP GRC 5.3 AccessControl Security Guide on SAP Service Marketplace athttp://service.sap.com/instguides -> SAP Solution Extensions-> SAPSolutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

See also the SAP GRC Access Control 5.3 Application Help on SAP Help Portalat http://help.sap.com -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Ensure that the user ID associated with this name has the access to view andmaintain the SU01 user records.

11. In the Password field, enter the specified password for the SAP user ID.

12. In the System Language field, enter the language for the system. The BASISadministrator provides this information.

13. In the Message Server Name, enter the name of the message server, which is usedfor load balancing of your SAP clustered environment.

14. In the Message Server Group, enter the Logon Group name to which the messageserver belongs. Your BASIS administrator provides this information.

15. In the Message Server Host, enter the host name of your message server. YourBASIS administrator provides this information.

16. In the SAP Version dropdown menu, select the appropriate SAP version. CompliantUser 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 systemis used or not. An HR system flag indicates whether the SAPHR module is installedon this connector, not necessarily whether you are using the SAPHR module. If thesystem is an HR system, the appropriate HR RTAs must be installed.

For more information, see the SAP GRC 5.3 Access Control Installation Guide onSAP Service Marketplace at http://service.sap.com/instguides -> SAPSolution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control ->SAP GRC Access Control 5.3.

17. In the SLD Connector checkbox, select this checkbox to enable the StandardLandscape Directory.For more information, see Integrating with System Landscape Directory.

18. In the Connector Category dropdown menu, select the category to which theconnector belongs. Possible values are Production, Non-Production, or Other. Thisselection is used to classify the servers into categories on the Access Request forms.


Configuration Tasks

September 2008 91

19. In the Role dropdown menu, select whether or not role information comes fromEnterprise Role Management or the SAP backend.

20. 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 Managerfield value to be automatically populated from the user’s HR record, set this fieldto (B012) – Managers.

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

SAP HR provides an organizational structure view that contains the object,relationships, and attributes. The organizational structure view contains therelationship types, B012-Managers and A002- Reports to.

21. Click Create.

22. Click Test Connection to ensure that the connection is valid. Executing this testverifies that the information on the connector is valid and initial communications canbe established. It also verifies the user ID and password. This test, however, doesnot 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 ServiceProvisioning Markup Language (SPML) service on SAP Enterprise Portal is configured on theportal 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

Procedure

To define connectors for SAP Enterprise Portal systems:


2. In the Connector Type dropdown menu, select SAP EP. The Connectors screenappears.

Any field name denoted with an asterisk (*) is required.

To complete the Connectors screen, obtain the connection information from yournetwork administrator and BASIS administrator.

3. In the Name field, enter the SAP Enterprise Portal connector name.

4. In the Short Description field, enter a short description of the connector. Thisdescription appears for the users to select.

5. In the Description field, enter the description of the new enterprise portal connector.

6. In the Web Service URI field, enter the URI address of the Web service of theapplication server.


Configuration Tasks

92 September 2008

Obtain the Web service URI address during the installation process of the RTA forthe specific application server. The Web service must be exposed in theapplication server side to establish communication links with Access Control.

7. In the User ID field, enter the user ID of a portal RTA user for this connection. Thisuser must have the appropriate role to perform this technical configuration. Assignthe role, pcd:portal_content/administrator/super_admin/super_admin_role to the RTAuser.

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 applicationserver. For example, use En_US for US.

10. In the Connector Category dropdown menu, select Production, Non-Production, orOther connector type. This selection helps classify the servers into the appropriatecategories in the Access Request forms.

11. In the Parameter pane, a table appears for you to map Parameter Names toParameter Values. The parameter value pair mapping is specific to the applicationserver.

The table below displays the required parameters for Provisioning Actions. Eachprovisioning action has a parameter value pair mapping for Parameter Name andParameter Value for the SAP Enterprise Portal connector.

Provisioning Actions SAP Enterprise Portal

(Required Parameter Value Pairs for theconnector definition)

ASSIGN_ROLES_ACTION_MAP ASSIGN_ROLES:OC = saprole

To Remove roles:

ROLESEARCH_URI =http://ip:port/UserRoleSearchForAEService_5_3/Config?wsdl&style=document

ROLESEARCH_URI_PASSWORD = password

ROLESEARCH_URI_USERNAME = username

CHANGE_ACTION_MAP CHANGE_USER:OC = sapuser

CREATE_ACTION_MAP CREATE_USER:OC = sapuser

CREATE_USER:password=password

DELETE_ACTION_MAP DELETE_USER:OC = sapuser

LOCK_ACTION_MAP LOCK_USER:OC= sapuser

LOCK_USER:islocked = true

LOCK_USER:type = CHANGE_USER

UNLOCK_ACTION_MAP LOCK_USER:OC= sapuser

LOCK_USER:islocked = false

LOCK_USER:type = CHANGE_USER

SCHEMA_ID SCHEMA_ID = SAPprincipals


Configuration Tasks

September 2008 93

Provisioning Actions SAP Enterprise Portal

(Required Parameter Value Pairs for theconnector definition)

DATA_SOURCE USER_DATA_SOURCE=USER.PRIVATE_DATASOURCE:un

ROLE DATA SOURCE -none-

For asynchronous requests to an IDM system, map the parameter value pair in theconnector definition: PROV_CALL = async.

When mapping parameter value pairs, you may have to define the user name andpassword for role search service in the provisioning action. This mapping is differentfrom the user ID and password that you set in the Connectors screen.

12. Click the Add icon to add more parameter value pair mapping.

13. Click Create.


If your connector does not have a RTA installed, you do not need to test theconnection, because the connection occurs between the two systems throughCompliant User Provisioning.

Field Mapping for SAP Enterprise Portal

When you have configured the connector for the SAP Enterprise Portal, you must configurethe field mapping between SAP Enterprise Portal and Compliant User Provisioning.

Procedure

To configure the field mapping for SAP Enterprise Portal:

1. Go to Compliant User Provisioning > Configuration tab > Field Mapping > Provisioning.The Field Mapping screen appears.

2. Click Create.

3. In the Group Name field, enter a name for the group of connectors.

4. In the Short Description field, enter a brief description of the group.

5. In the Connector Type field, select from the dropdown menu, SAP EP.

6. Click the Add icon to activate the dropdown menu for the Application field. Select thedesired application connector defined for enterprise portal (EP).

7. Click the Default System radio button to indicate that this connector is the default.

8. Click Continue.

9. The field mapping screen for AC Fields and Application Fields appears. Click the Addicon to display the dropdown menu where you can select a name of the field for AC andApplication in order to associate the fields.

Example:


Configuration Tasks

94 September 2008

AC Field Application Field

Email Address - Standard email

User FName - Standard firstname

User ID -Standard logonname

10. Click Save.

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

Procedure

The following steps are applicable for Oracle Applications, JD Edwards, PeopleSoft, andOthers with the following exceptions:

For RTA information for Oracle Applications, JD Edwards, and PeopleSoft, see theGreenlight Adapter documentation.

For Others connector type, you can connect to a system that supports SPML 1.0 or not.


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 yournetwork 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 theapplication server.

For more information on RTA information for specific application servers, see theGreenlight Adapter documentation.

7. In the User ID field, enter the user name to access this connection.



10. In the Connector Category dropdown menu, select Production, Non-Production, orOther connector type. This selection helps classify the servers into the appropriatecategories in the Access Request forms.

11. In the Parameter pane, a table to map Parameter Names to Parameter Valuesappears. The parameter value pair mapping is specific to the application server. Themapping of parameter values is the actual Web service for the provisioning action.

To complete the mapping of parameter value pairs, obtain the connectioninformation from your network administrator and ERP Security administrator.

During the mapping of parameter value pairs, you may have to define the user


Configuration Tasks

September 2008 95

name and password for role search service in the provisioning action. Thismapping is different from the user ID and password that you set on theConnectors screen.

12. Click the Add icon to add more parameter value pair mappings.

RecommendationFor more information on ERP-specific connection parameters, see the GreenlightAdapter documentation.

13. Click Create.


If your connector does not have a RTA installed, you do not need to test theconnection. It is not needed because the connection occurs between the twosystems 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 provisionuser access (no auto-provisioning). In this case, the legacy system doesnot 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 configuringconnectors for Microsoft Active Directory, SUN Microsystems SUNONE, Novell E-Directory, and IBM Tivoli see Configuring LDAP Connector in Compliant User Provisioningof GRC Access Control on SAP Community Network at http://sdn.sap.com.

Procedure

To define connectors for LDAP systems:


2. In the Connector Type dropdown menu, select LDAP. The Connectors LDAP screenappears.


To complete the LDAP Connectors screen, obtain the connection information fromyour 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 yoursystem. The connector names are very important when integrating to other GRCproducts. The system names for all connectors must be the same.


Configuration Tasks

96 September 2008

4. In the Short Description field, enter a short description of the connector. This descriptionappears 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.

7. In the Domain field, enter the location of the LDAP root. The LDAP root is whereCompliant 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 LDAPuser directory.


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 theconnector 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 theAccess Request forms.

16. Click Create.

17. Click Test Connection to ensure that the connection is valid. Executing this test verifiesthat the information on the connector is valid and initial communications can beestablished. It also verifies the user ID and password. This test, however, does not verifythat 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 UserProvisioning.

Defining Connectors for Verification/Training System

You can connect to your training system to implement and verify that users have completedthe required training program before requesting roles, privileges, and the like.

In general, you select the Verification/Training System connector type when your organizationrequires users to participate in a training program. Once the user completes the trainingprogram, you can verify that the user has successfully performed the prescribed tasks. Forexample, before assigning a role to a user, you can verify that the user is competent increating an access request.

Procedure

To define connectors for verification/training systems:


2. In the Connector Type dropdown menu, select Verification/Training System. TheConnectors screen appears.


Configuration Tasks

September 2008 97


To complete the Connectors screen, obtain the connection information from yournetwork administrator and system 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 applicationserver.

For an SAP system, you obtain the Web service URI address by going to SAPNetWeaver Web Application Server. Perform the following:

a. Go to SAP NetWeaver Web Application Server Start Page > Web ServiceNavigator.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.



10. In the Connector Category dropdown menu, select Production, Non-Production, or Otherconnector type. This selection helps classify the servers into the appropriate categories inthe Access Request forms.

11. In the Parameter pane, a table appears for you to map Parameter Names to ParameterValues. The parameter value pair mapping is specific to the application server.

To complete the mapping of parameter value pairs, obtain the connection informationfrom your network administrator and system administrator. However, most trainingsystems 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 verifiesthat the information on the connector is valid and initial communications can beestablished. It also verifies the user ID and password. This test, however, does not verifythat 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 UserProvisioning.


User Data Source Definition

98 September 2008

Viewing and Maintaining Available Connectors

You can view a list of the connectors configured to connect to back-end systems and changeor delete them.

To do this, select a connector name and click Change or Delete.

If you select Change, the Connectors screen appears. You can edit and save anychanges 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, clickTest Connection.

User Data Source DefinitionUse the User Data Source option to increase the scope of SAP back-end systems that youconfigured in the Connectors screen. You define the primary source for extracting user dataon the User Data Source screen. Mapping the data source allows Compliant UserProvisioning to search for all users, managers, and approvers. However, keep in mind thatthis 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 determineshow certain types of data are handled through the assigned protocols and from specificsystems. Therefore, once you select a user data source, you do not need to perform anyadditional 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 anenterprise portal environment. UME is also used a data source by NetWeaver forother applications that are integrated into the SAP system.

UME is a central management repository for retrieving user data on SAP throughCompliant User Provisioning.

Using LDAP as the User Data Source:

Using LDAP as the user data source is highly preferable, because LDAP is normallythe first point of entry for users accessing the enterprise system. LDAPs generallycontain 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 theLDAP 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 thesequence in which the data sources should be searched. The system searches thesystems in the specified order until it finds the user ID and retrieves the user’s detailsfrom that system. For example, all employee user information can be fetched fromSAP HR. However, part-time and contract personnel detail information exists in anLDAP system. In this case, you can configure Multiple Datasources with SAP HR andLDAP systems which fetches detail information for both employees and contractors.

Integration

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


User Data Source Definition

September 2008 99

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 saveoption. The Search Data Source and the Users Details Data Source do not have to bethe same data source.

The Search Data Source contains user-related information such as the user ID. The UserDetails Data Source contains additional user data such as phone number, e-mailaddress, 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, includinga 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 FunctionTemplate 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 andapprover data in an enterprise portal environment or when User ManagementEngine is used by SAP NetWeaver for other applications that are integrated intothe SAP system. The User Management Engine is the central managementrepository 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 isnormally the first point of entry for users accessing the enterprise system. LDAPsgenerally contain as much information about the user as the SAP businesssystem.

If you set the User Detail Data Source to LDAP, the user’s manager listed on theLDAP 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 screenappears. You can then select the systems to be searched and the order in which


Integrating Compliant User Provisioning and Risk Analysis and Remediation

100 September 2008

they are searched. The system searches the systems until it finds the user IDand retrieves the user’s details.

Integrating Compliant User Provisioning and RiskAnalysis and RemediationYou integrate Compliant User Provisioning with Risk Analysis and Remediation to enable riskanalysis, 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 ServiceNavigator. 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 theVersion dropdown menu.

4. In the URI field, enter the Risk Analysis URI. You can paste in the copied shortcut youobtained 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 thefollowing:

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



September 2008 101

8. Go to Compliant User Provisioning > Configuration tab > Mitigation. The Mitigationscreen appears.

9. Select the Allow Approvers to Approve Access Despite any Conflicts checkbox.

10. In the Default Duration (Days) for the Mitigation Control, enter a number of days you wantfor 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. Forexample: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 Webservice. 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 ConfigurationThe Request Configuration option customizes the Request screen. This means defining thefields that you want to appear. You can customize Request Types, create a new RequestCategory or Request Reason, and provide a range of values that appear when a user makesa new request.

The Request Configuration screen provides Configuration tabs for request creations that youmust define to meet the range of request cases in your system. These configuration valuesdepend 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 therequest process. The Request Type configuration specifies what actions are performed onthe processing of that request.

Features

Request types determine the actions to be performed. Request types can be reference pointsfor initializing a workflow. Compliant User Provisioning provides a standard set of requesttypes. These standard request types represent actions that occur in the SAP back-endsystems. 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 typescan also be used as an attribute in the initiator/workflow selection process.

The standard request types are:

New

Change



102 September 2008

Delete

Lock

Unlock

ExampleIf 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 installationprocess from an XML basic configuration file.

You can configure the Request Type for the request during the End UserPersonalization configuration. Configure this field with a default value and indicatewhether it is mandatory, editable, and visible.

You can also create your own custom request types, instead of using any of the deliveredrequest types. Customized request types allows you to define the sequence of provisioningactions for a request.

The following are examples of customized request types:

Create, Assign Roles, and Lock

Change and Lock

Change and Unlock

ExampleIf you create a customized request type as Create and Lock, it relates to the creationof a new account in the SAP backend system with their role assignment and lockingthe account for a ‘go-live’ scenario.You then can use the customized request type as an attribute in the Initiator/Workflowselection 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 fieldname 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 throughoutCompliant User Provisioning when you perform a query. This field is limited to 38characters.

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 torequest types defines the order in which request types appear on the Request Accessscreen.



September 2008 103

If you assign the value 0, the request type does not appear on the Request Accessscreen. However, if the request type is active, it appears on the Request Typedropdown 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 isintegrated with Risk Analysis and Remediation and/or Enterprise Role Managementand 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 requestorscan select a specific request type. This description should contain information that ishelpful to them when deciding which request type to use.

10. In the Select Actions window, select the actions to be performed during provisioning ofthis request type.

On the left side of the screen, the Assigned Actions appear. These are theactions to be performed during provisioning.

On the right side of the screen, the Available Actions appear. These are theactions that are available to be performed during provisioning.

11. When searching for Available Actions, enter the name of the action and click Go, or clickGo 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 thedesired action.

2. Click the left arrow (<) button to move the Available Action to the Assigned Actiontable.

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.

ExampleIf you select Create User, Lock User, and Assign Roles, the system creates the userin the target system, immediately locks the user ID, and assigns all approved roles



104 September 2008

listed in the request. If you select only Create User, the system creates the user ID inthe target system and does not assign any roles.If you select User Defaults, the system applies the user defaults defined during theuser default mapping process. If you do not select User Defaults, the system does notprovision the defined user defaults.

Customizing Request Types with Associated Actions

Procedure

To create a customized request type, use the same procedures as discussed in CreatingRequest 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

ExampleYou can create a customized request type by using Create User and Lock User actions. Inthis case, the name of the custom request type is Create_Lock. This request type is forscenarios where you create a user, then lock the user account until a future event, suchas a go-live launch or training class start date. At such time, the user must be unlockedby using the Unlock User request.Configuring with Superuser Access Action

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

As a prerequisite, you must set up a connection between Compliant User Provisioning and anSAP system with Superuser Privilege Management. Specifically, ensure that the FirefighterOwners and Firefighter IDs are set up in the connected SAP back-end system beforeprovisioning.

For more information, see the section Configuring Connectors for SAP.

There are standard approver determinators for assigning the request to controllers andowners. You can use these approver determinators when configuring the stages of aworkflow. In addition to user provisioning, you can also provision the appropriate firefighterrole 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 inSuperuser Privilege Management. No risk analysis is done when processing a requestfor user access from Compliant User Provisioning.


Request Priority Configuration

September 2008 105

Procedure

To create a Firefighter ID (FFID) in Superuser Privilege Management from Compliant UserProvisioning, 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 fieldsbecome active.

3. Make your modifications.

The Request Type and Workflow Type fields are not editable. All other fields and valuesare editable.

4. Click Save.

Request Priority ConfigurationYou 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 Priorityoption allows managers to oversee the processing functions of a specific organizational teamresponsible for requests and approvals. You can also use the priority as an attribute in theInitiator/Workflow selection process.

When configuring the Priority attribute, remember it is a required field, which the requestoruses when defining the request. Therefore, this priority attribute affects the workflow bydetermining the time rate for the approval process. You can also use the Priority attribute toroute a request to a group of approvers.

Priority is configurable on the request through the End User Personalizationconfiguration. 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.


Application Configuration

106 September 2008

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.


The Workflow Type option is available only if Compliant User Provisioning isintegrated with the Risk Analysis and Remediation and/or Enterprise RoleManagement capabilities and you have enabled the Workflow Types on theMiscellaneous 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 throughoutCompliant User Provisioning when you perform a query. This field is limited to 38characters.

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

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 ConfigurationOn the Application Configuration screen you can add selection options for non-connectedsystems, which appear as part of the Access Request approval process. The screen also listsall systems for which connectors have been defined (in a read-only mode).

When you define an application, the requestor sees the application name and descriptionwhen using the Search function to find available applications. Then, by selecting theapplication, 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 insome approval stage of a workflow in order to fulfill the request. For example, when


Employee Type Configuration

September 2008 107

requesting access to a non-SAP system, there can be an approval stage where the requestorneeds network access. After the approver approves the request, the system administratormust 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.


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 ConfigurationThe 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 usethe Employee Type field as an attribute in the Initiator/Workflow selection process. Anotheruse of the Employee Type attribute is to track which end users are requesting access.

After you configure an Employee Type, the name appears on a dropdown list on the AccessRequest screen.


Number Ranges

108 September 2008

Employee Type is configurable on the request through the End User Personalizationconfiguration. Configure this field with a default value and indicate whether it ismandatory, editable, and visible.

Configuring an Employee Type

Procedure

To configure an employee type:

1. On the Configuration tab, navigate to Request Configuration > Employee TypeConfiguration. 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.


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

2. Click Change to modify the selected employee type.

3. Make your changes.

4. Click Save.

Number RangesRequests 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. CompliantUser Provisioning uses these numbers for invoices and identification. For example, you canconfigure a number range to reflect the month of April by setting your number range to 0401to 0430.

It is important to create multiple number ranges that correspond to your businessrequirements. However, make sure that individual ranges do not overlap. For example, donot have a number range of 100–1000 and another number range of 500– 2000. Onlyone number range can be active at a time.

The system does not activate the number ranges automatically. You must activate thenumber range after it reaches its last invoice number.


Authentication Source for Requestors

September 2008 109

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 RequestorsThe Authentication option verifies the requestor’s identity from the selected system. After youconfigure the Connectors and Authentication attributes, Compliant User Provisioning confirmsthe user ID and password the requestor uses during logon.

The approver is always authenticated and authorized using SAP NetWeaver UserManagement Engine (UME). For users other than approvers, authentication andauthorization system can be any system such as LDAP, SAPHR, SAP, and non-SAPsystems.

Do not confuse the authentication system with a user data source. Although theauthentication system can be the same system as the user data source, each has separatefunctionality.

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


Risk Analysis

110 September 2008

Defining Authentication

Procedure

The requestor of a request does not need any permission; therefore, requestors can beauthenticated 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 dropdownlist. 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 (includingLDAP authentication systems). It allows the requestor to log on without a password, ifthat 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 dropdownlist and selecting a number from 1 to 9, where 1 is the highest, 9 is the lowest, and 0deselects the LDAP. Compliant User Provisioning searches for LDAPs in the specifiedorder to find the user ID and password. The search stops after it finds the first user IDmatch.

Select the End User Verification Required checkbox to enable the verification of auser ID without requiring the user to enter a password. The system only verifies thatthe user ID exists in the data source.

3. Click Save.

Risk AnalysisThe Risk Analysis option selects the options for performing the actual risk analysis. You canidentify the level of risk analysis and specify the Risk Analysis and Remediation version forprocessing risks.


Risk Analysis

September 2008 111

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 whileperforming risk analysis.

4. Click Save.

5. Under Select Risk Analysis and Remediation Version, select the Version of CompliantUser Provisioning used from the dropdown list.

If you select 5.0 Web Service or later, three additional fields appear: URI, UserName, and Password.

o For URI, identify the correct Web service URL by:

a) Open a new browser session and navigate to the Web ApplicationServer (http://<server>:50000/index.html)

b) Click Web Services Navigator. The Web Services Navigator screenappears.

c) Expand the VirsaCCRiskAnalysisService folder, and then clickDocument. The Web service URL is listed below the WSDL (WebServices Description Language) heading.

d) Right-click Web Service URL and select Copy Shortcut from thecontext menu.

e) Return to Compliant User Provisioning's Configuration Tab > RiskAnalysis and paste the URL into the URI field.

o For User Name and Password, enter the User Name and Password ofyour Webuser that has been defined for communication between theAccess 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 analysistime. This is only applicable if you have configured organizational rules in Risk Analysisand Remediation. If you have not configured organizational rules, do not choose thisoption.

7. Click Save.

8. Under Risk Analysis On Request Submission, select Yes or No from the Perform RiskAnalysis On Request dropdown list to enable or disable the ability to perform risk analysison submission of a request.

9. Click Save.

Frequently Asked Questions

Question Answer


Mitigation Setting

112 September 2008

Question Answer

Can you choose the rule set to perform therisk analysis from Compliant UserProvisioning?

No. The default rule set is always used toperform risk analysis from Compliant UserProvisioning.

Can you identify which SoD risk criticalitylevels have been assessed for a requestaccess?

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

How does Compliant User Provisioningperform a risk analysis?

Compliant User Provisioning performs a riskanalysis by using an EJB call or Web services.It first uses an EJB service call. If that fails, aWeb service call is made. A successful EJBcall is executed only when Compliant UserProvisioning and Risk Analysis andRemediation are installed on the same server.If the EJB call fails, the Web service is called.

What steps need to be taken if a riskanalysis fails?

For more information about how totroubleshoot issues with risk analysis, see theSAP Notes 1136379, 1049058, 1145700,1234807, 1085586, 1061088, 1003239, and1166368.

Mitigation SettingThe Mitigation option allows approvers to approve requests when SoD violations are foundduring risk analysis. If this option is not enabled, the approver cannot approve the requestwhen role conflicts are discovered. In that case, the approver can either reject some rolesand perform risk analysis again to check for violations or mitigate the existing violations toproceed.

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 despiteconflicts checkbox. This option is a global setting, but it can be configured during theworkflow stage configuration.

To allow approvers to approve their requests with unmitigated SoD conflicts, selectthe checkbox. When the approver executes the risk analysis, the resulting SoDconflicts are displayed.

To require approvers to address the SoD conflicts during the access requestprocessing, deselect the checkbox. This requires the approver to remove or mitigatethe SoD conflict before they can approve.

3. In the Default Duration (in days) for the Mitigation Control field, enter the number of daysyou want the mitigating control to be active.


End User Personalization

September 2008 113

4. In the next four fields, identify the Web service URL/URI for obtaining the mitigationinformation 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 ServicesDescription Language) heading.

Right-click Web Service URL and select Copy Shortcut from the contextmenu.

Return to Compliant User Provisioning's Configuration tab > Mitigationand paste the correct URL into the corresponding URI fields.

e. Repeat the previous step for each Web service URL required.

5. Click Save.

End User PersonalizationThe End User Personalization screen allows you to set the parameters that define thebehavior of the fields and buttons on the Request Access screen.

These parameters affect only the Request Access screen. They do not affect theCreate 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 enduser opens the Access Request screen.

Mandatory – Setting this parameter to Yes requires the end user to enter a value in theselected field in order to submit a request.

Editable – Setting this parameter to Yes allows the end user to edit the value in theselected field. If the parameter is set to No, then the value in the field is displayed asread-only.

Visible – Setting this parameter to Yes makes the field visible to the end user on theAccess Request screen.

These parameter settings apply to every access request submitted. You cannotcustomize some parameters, because they default to either Yes or No based on thenature of the field. For example, a mandatory field must be visible on the RequestAccess 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. Thefields are arranged by their logical grouping for conceptual context and accessibility toconfiguration information.



114 September 2008

Field Description Personalized Values

Action Group

Attachments The Attachments buttonallows users to select filesand attach them to arequest.

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

Cancel The Cancel button allowsusers 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 thePassword Self Serviceoption, which allows users toreset their passwords in theSAP back-end systemwithout involving the SAPHelp Desk or the SAPSecurity Group.


Setting Visible to Yes makesthe hyperlink available in theRequest Access screen.Setting Visible to No hides thehyperlink in the RequestAccess screen.

Requesting for Other User This checkbox appears onthe logon page to access theRequest Access screen.Selecting it enables the UserInformation Lookup (searchfeature).


Setting Visible to Yes allowsthe end user to submitrequests for others.

Roles This field enables users toadd roles to a request.

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

Setting Mandatory to Yesrequires the end user to selectroles before submitting arequest.Setting Visible to Yes enablesthe Select Roles button, whichallows end users to select rolesfor a request.

Submit This button allows users tosubmit a request.


Setting Visible to Yes allowsend users to submit requestsfrom the Request Accessscreen. Otherwise, they mustuse the Select Roles screen to



September 2008 115

do that.

Super Access The Superuser Accessaction type allows users torequest a Firefighter ID(FFID) in SuperuserPrivilege Management fromCompliant UserProvisioning.


Setting Visible to Yes makesthe Select SuperUserAccessbutton visible.This button is disabled if theprovisioning actionSUPER_USER_ACCESS isnot associated with theselected request type.

Request Info Group

Application (list of systems) This is the name of theapplication server(s) inwhich the requested actionis performed.

Default Value – Yes, youcan select a value.

Mandatory – N/A Editable – Yes/No Visible – N/A

Since users cannot submitrequests without thisinformation, the Mandatory andVisible parameters default toYes. You cannot change thesesettings.

Functional Area This is an organizationalcategory associated with theuser’s role or profile.


Mandatory – Yes/No Editable – Yes/No Visible – Yes/No

Priority This value determines howquickly a request isapproved.


Mandatory – N/A Editable – Yes/No Visible – N/A

Users cannot submit requestswithout this information.

Request Reason This field allows users toenter the reason forrequesting access.

Default Value – Yes, youcan enter a reason.

Mandatory – N/A Editable – Yes/No Visible – Yes/No

Request Type Request types determine theactions to perform. They arereference points forinitializing a workflow, suchas 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 emailaddress.




116 September 2008

Requestor Name This is the requestor‘sname.


Requestor Telephone This is the requestor’stelephone number.


Manager Info Group

Manager Email This is the manager‘s emailaddress.

Default Value – N/A Mandatory – Yes/No Editable – Yes/Yes if data

missing/No Visible – Yes/No

If the Editable parameter is setto Yes, if data missing, the fieldis editable only if the value ismissing from the data source.

Manager InformationLookup

This is the search icon(magnifying glass) used tolaunch the search feature formanager information.

Default Value – N/A Mandatory – N/A Editable – N/A Visible – Yes/Yes if data

missing/NoIf the Visible parameter is setto Yes, if data missing, and themanager information is notassociated with the user ID inthe data source, then thesearch 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’stelephone number.

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

User Info Group

Company This is the company nameassociated with the userrequesting access.



Department This is the name of thedepartment associated withthe user requesting access.

Default Value – Yes, youcan enter a value.


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


Mandatory – Yes/No



September 2008 117

Editable – Yes/No Visible – Yes/No

Location This is the location nameassociated with the userrequesting access.



User Email Address This is the email ID of theperson for whom the user isrequesting access.


User First Name This is the first name of theperson for whom the user isrequesting access.


User ID This is the unique ID of theperson for whom you arerequesting access.


User Information Lookup This is the search icon(magnifying glass) used tolaunch the search feature foruser information.


User Last Name This is the last name of theperson for whom the user isrequesting access.


User Telephone This is the telephonenumber of the user for whomthe user is requestingaccess.


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

Default Value – Yes, youcan enter a default value.


User Valid To This field indicates thevalidity end date for a user.

Default Value – Yes, youcan enter a default value.


Self User Info Group

Self User Email Address This is the email address ofthe user submitting arequest.

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 theuser submitting a request.

Default Value – N/A Mandatory – Yes/No Editable – Yes/Yes if data

is missing/No Visible – Yes/No



118 September 2008

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

Default Value – N/A Mandatory – N/A Editable – Yes/Yes if data

is missing/No Visible – N/A

Self User InformationLookup

This is the search icon(magnifying glass) used tolaunch the search feature forself user information.

Default Value – N/A Mandatory – N/A Editable – N/A Visible – Yes/Yes if data is

missing/NoSelf 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 nameof the Secure NetworkCommunication (SNC). Youuse the SNC value forSingle Sign-On to systemsthat run in an ABAPenvironment and use SAPGUI as the front-end client.



For more information, seeSAP Note 1177556 –Compliance UserProvisioning SNCParameters.

Unsecure Logon Allowed(SNC)

If this field is set to Yes, theuser can log on withouthaving a default SNC namefor authentication.

Default Value – Yes, youcan select a value of Yesor No.


Validation Group

Approve Reject OwnRequests

You can set Compliant UserProvisioning to allow usersto approve or reject theirown access request. Forcompliance purposes, thedefault behavior preventsusers from approving orrejecting their own requests.


If Visible is set to Yes, thisallows end users who are alsoapprovers to approve/reject therequest during the approvalprocess.

One User per Request perSystem

This allows you to restrictusers to no more than onerequest submission for anapplication.

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

Setting Mandatory to Yes



September 2008 119

allows the end user to submitonly one request per system.All open requests in theapproval process must becompleted before anotherrequest can be submitted tothe same system.Setting Mandatory to No allowsthe end user to submit multiplerequests 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.

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 AccessRequest 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 AccessRequest submission or No to make the field invisible.

6. Click Save.



120 September 2008


Question Answer

Where does Compliant User Provisioningobtain a user’s manager information?

The Access Request screen. The manager’sfirst name, last name, and email address canbe entered with:

Free form text entry fields. There is novalidation of the field contents.

The user search function in the Managerfield on the Access Request. This uses thesystem configured for searching for theselected user.

The search (magnifying glass) icon,entered manually and mapped from theLDAP or SAPHR system. However, toimport the manager's information, the userdata sources must be set to the LDAP orSAPHR system. If you are using the CUAas the user data source, encourage therequestors to use the search dropdowncapabilities for accuracy.

How do I set up End User Personalization sothat searching for manager information isfrom the correct data source?

Ensure that the LDAP and SAPHR connectorsare correctly set up in Access Control andverify that the appropriate connector isconfigured as the user details source so thatthe manager information is retrieved.

For more information on configuringconnectors as user details source, seethe section User Data SourceDefinition.

In the End User Personalization screen, set theManager Name, Manager Email, ManagerInformation Lookup, and Manager Telephonefields with the Editable parameter set to Yes ifdata is missing. Ensure that the ManagerInformation Lookup field is set with the Visibleparameter to Yes.


Technical Support Contact Identification

September 2008 121

Question Answer

How do I prevent users from entering fakeuser IDs in the request form and only allowthem to select a user ID using the searchfeature?

On the End User Personalization screen, setthe User ID, User Email, User Last Name, andUser First Name fields with the Editable valueto No. Ensure that User Information Lookup isvisible.

When users log on and make a request forothers, they cannot enter data in the userinformation fields. They are then obliged to usethe Search (magnifying glass) icon to query fora user ID.

How do I allow users to enter information infields left empty because the search resultsdid not return information for that particularfield?

If you know that user information is missing ordoes not exist if the user does a search, youcan make the field editable and allow entry ofthe information.

For example, if the email address is missing fora user, you can set the User Email field asEditable with Yes if data is missing. This allowsthe user to enter the email address in theRequest Access Form. This is the same formissing information for User ID, User Name,and User Last Name.

What are the differences between the SelfUser Information configuration and Requestfor Others Information configuration?

To activate the Self User Information(magnifying glass) search icon, select theRequesting for Other User checkbox whenentering your logon credentials. After loggingon, you can search for user information (via theSearch feature) for which you are requestingaccess.

If you do not select the Requesting for OtherUser checkbox, the Self User Informationfields, (which include Self User Email, SelfUser First Name, Self User ID, and Self UserLast Name) are automatically pre-populated.To make the Self User Information Lookup(search icon) visible, set the Visible value toYes.

Technical Support Contact IdentificationThe Support option defines a primary contact for Compliant User Provisioning, includingemail and phone information.

Defining Contact Information

Procedure

To define contact information:

1. On the Configuration tab, navigate to Support.


Available Request Attributes

122 September 2008

The Support screen appears.

2. In the System Administrator field of the Contact Information section, enter in the user IDof 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.

Defining Support Screen information

The Support screen is viewable by requestors from the Access Request screen by clickingSupport.

To define the Support screen information:

1. In the File Name field, enter the name of the HTML file containing the support informationto be displayed when a requestor selects Support from the initial Access Request screen.

Compliant User Provisioning provides a default Support page. However, you cancreate your own Support page and point to it by clicking Browse. Otherwise, clickRestore Default to restore the original support page.

2. Click Import.

Available Request AttributesThe Attributes screen provides a standard list of attributes that the requestor can select aspart of the access request process. Use the Attributes option to select attributes to appear onthe Access Request screen (listed in the dropdown list or text field). Attributes allow the usersto input valid information when requesting access.

The standard list of attributes is basic in every business model. Do not disable anattribute 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 whendefining 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 FieldsThe Custom Fields option creates customized fields that are required for additionalinformation or security. You can use custom fields to determine the workflow of the request or


Custom Fields

September 2008 123

to extend the current attributes for the organization’s requirements. Custom fields appear inthe More Options section of the Access Request screen.

For more information, see the sections Creating a Custom Field and Changing or Deleting aCustom Field.

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. In the Name field, enter the name of the new custom field.

4. In the Description field, enter the description of the new custom field.

5. In the Field Label field, enter the name you want to label the field.

6. From the Workflow dropdown list, select Yes for this field to appear on a dropdown list, orselect No to prevent this field from appearing on a dropdown list.

7. From the Mandatory dropdown list, select Yes to require the end user to enter informationinto this field, or select No to indicate that the end user is not required to enter informationinto this field.

8. From the Applicable To dropdown list, select whether this field is applicable to a role orrequest.

9. From the Workflow Type dropdown list, select the workflow to which you want this field toapply.

10. From the Field Type dropdown list, select Dropdown or Text.

If you select Dropdown, a Data Source dropdown list appears. Select a datasource.

If you select SAP, you will be prompted to enter the following information:

Source System - Select the SAP system for which the custom field willbe applicable.

Table Name – Enter the SAP table from which to pull the custom fieldoptions. This field is case-sensitive.

Field Name – Enter the field from the SAP table above from which to pullthe custom field options. This field is case-sensitive.

If you select AE, a table of custom value fields appears. Use the andicons 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 textfield.

If you select Date, you are not required to enter a data length.

If you select Numeric, enter a data length for the numeric characterrequirements.

If you select Varchar2, enter a data length for the numeric characterrequirements.


Service Level Period

124 September 2008

11. Click Save.

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 PeriodThe Service Level option sets the time frame for a task to be completed. Service levelagreements 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 forRequests report).

Example

You create a service level where the workflow type is CUP and the number of days for arequest to be approved to 10 (days). This service level is also configured for attributes ofRequest 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 actuallyapproved on 11/05/08, the latter date is marked to indicate that a service level agreement forthis 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. In the Name field, enter the name of the service.

4. In the Short Description field, enter a short description of the service.



Workflow Management

September 2008 125

5. In the Description field, enter the description of the new service.

6. In the Workflow Type field, select a workflow type.

The Workflow Type option is available only if Compliant User Provisioning isintegrated with Risk Analysis and Remediation or Enterprise Role Management andyou enable Workflow Types on the Miscellaneous screen.

7. In the No. of Days field, enter the number of days in which this new request must beprocessed.

8. From the No. of Hours dropdown list, select the number of hours in which this newservice must be processed.

9. From the Attribute dropdown list, select an attribute.

10. From the Value dropdown list, select a value.

11. From the Condition dropdown list, select a condition.

You can select OR, NOT, or AND for the selected attribute.

12. Click Add Attributes.

The attributes are displayed on the Service Level Details screen.

13. Repeat steps 9 through 12 for each attribute you want to add to the Service Level DetailsList.

14. Click Save.

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.


4. Click Save.

Workflow ManagementWorkflow management includes creating, modifying, deploying, activating, deactivating, anddeleting workflows. Each workflow should replicate one of your organization’s existingprovisioning approval processes.

About Workflows

A workflow defines the required steps to approve the assignment of one or more roles to aspecific user. Each access request specifies a distinct condition. When a request comes in, ittriggers the specific workflow designed to manage requests with that particular condition.Although neither the requestor nor the approvers ever see the actual workflow, the workflowdetermines the approval process.


Workflow Management

126 September 2008

Features

Compliant User Provisioning uses workflows to automate the collection of approvals, and itcan automate the provisioning process as well.

Activities

Every company has established processes for requesting and granting access to users, bothfor new employees and for existing employees whose role in the company changes. Eachprocess 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 aworkflow, you define elements. These elements are described in the following table.

Workflow Component Elements

Element Description

Initiators An initiator is an object that defines a precise request condition, and identifiesthe single, unique workflow designed to handle that type of request. Initiatorsand workflows function as matched pairs. Each initiator can call only oneworkflow, 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 approversmust approve or deny the request. The stage defines who must approve therequest. It also determines what happens next, based on the decision of theapprover. At each stage of the request process, the system sends an emailmessage to the user designated to approve or deny the request. The requestprocess cannot continue until the approver responds by approving or rejectingthe request.

Paths A path defines the sequence of stages in a workflow. When you create aworkflow, you begin by creating each of its stages. By themselves, the stagesserve no purpose. Each stage is an independent entity, unrelated to any otherstage. When you create a path, you define the order in which the workflowcalls its stages.


Workflow Management

September 2008 127

Workflow Creation

Creating a workflow involves both planning and execution. In most cases, planning aworkflow is far more time-consuming than creating it. Creating a workflow is a straightforwardprocess of creating or selecting the necessary capabilities and then defining a path to bindthem. It is the planning—determining how you want the workflow to function—that requiressome consideration.

Prerequisites

When you create a workflow, you establish your organization’s policy for approving a specifictype of access request. You identify the condition (the specific attributes of the request) thatcalls 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 thesame 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 thatdoes not exist, you must create it. Since you can use the same stage in several differentworkflows, you only create a new stage if it does not already exist. Your first step is toevaluate your existing stages to if you want to use any of them in your workflow. Thencreate the stages you need that do not yet exist.

You can create an additional stage, even if the approver determinator is the same butthe stage configuration details are different. For example, one role approver stagemight have risk analysis required and another role approver stage might not requirethe risk analysis.

3. Create and activate the path.

The path is the structure and framework of the workflow. It binds the various capabilitiesinto a cohesive process. When you define the path, you create an association among theworkflow, the approvers, and its initiator, and you identify the workflow’s stages and thesequence in which they are called.

Result

When you save and activate the workflow, it becomes effective immediately. Any subsequentrequest that matches its initiator calls the workflow, which then manages the approvalprocess.

Workflows manage the approval process behind the scenes. Users who initiaterequests do not see the workflow. Approvers who enter requests to approve them dosee the workflow, but not until the second screen of the approval process. They cansee 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 activatethem. You can delete a workflow only if no access request has ever called it. When aworkflow has managed a request, you cannot delete it. Do not activate a workflowuntil you are certain it reflects its intended approval path.


Workflow Management

128 September 2008

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 theapproval process for a single role, this is not required. If you have two roles that arealways assigned to a user in tandem, you can create an initiator using a Boolean andoperator, so that any request that includes both roles triggers the workflow.

More commonly, a single workflow approves several different roles. You can create aninitiator that uses a Boolean or operator. Any request that includes any of the rolesdefined 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 aretimes when the requested roles conflict, or are inappropriate for the user. When thatoccurs, it is the responsibility of the designated approver to deny the request.

Once the request is denied, you must determine how Compliant User Provisioning shouldhandle the request. Do you want to abort the request or do you want to pass the requestto security for analysis? If only part of the request has been denied, do you want toproceed with the remainder of the request? You can design detour workflows that triggerwhen 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 variationsdescribed in the following sections.

Basic Workflows

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


Workflow Management

September 2008 129

Basic Workflow with Three Stages


Workflow Management

130 September 2008

This diagram shows the sequence of stages and identifies the designated approver at eachstage. This type of path is typical, because its initiator is triggered by a request. The requestcondition that satisfies the initiator can include multiple attributes.

The basic workflow is triggered by an initiator, which is configured with a workflow type. Thestandard workflow types are:

CUP – This is a workflow type for Compliant User Provisioning.

Mitigation Control – This is workflow type for mitigation purposes.

Mitigation Control Assignment – This is a workflow type for creating/modifyingmitigation control assignments.

ERM – This is a workflow type for role approval.

Risk – This is a workflow type for creating/modifying risks.

SOD Review – This is a workflow type for creating a Segregation of Duties review.

User Access Review – This is a workflow type for creating a user access review.

Workflow types are associated with certain attributes that are relevant to the request. Theattributes define the workflow logic and determine how the request is processed through thedesignated 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 nothave associated attributes.

Most of the workflows you create are main workflows. For more information, see the sectionCreating 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 workflowssimultaneously (in parallel).

Parallel workflows work only when initiators are created at the role level. A request issplit by roles into the parallel workflows.


Workflow Management

September 2008 131

When the requestor submits the request and two initiators are satisfied, the system initiatestwo or more workflows. These workflows contain the same request number, and the SearchRequest screen displays the various paths. Although each path moves through its workflowindividually, 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.

ExampleIf the initiators are defined by roles and a user submits a request with two different rolesthat satisfy two different initiators, the system establishes a parallel workflow. If both pathscall for the manager to be the first approver, the manager needs to approve the requestonly once for both workflow paths. Since the manager turns out to be the same user inboth paths, Compliant User Provisioning sends only one approval email to that user, whoneeds to make only a single decision.Assuming the approver approves the request, Compliant User Provisioning proceeds tothe next stage for each workflow. Since the two workflows have two different stages, itgenerates two different emails, one for each identified approver. It then waits for theapprovers to take action.When both approvers approve their stages, Compliant User Provisioning moves on to thenext stage. Since security is the next stage in both workflows, security has the ability toapprove both requests with one approval, if both workflows arrive in the security stage atthe same time, or security might approve each workflow individually.Detour Workflows

Detours are stand alone workflows that assume the management of the request if specificconditions are met. If the conditioners are met, the request will actual change workflow pathsand 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-SAPapplications 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 mustcomplete these tasks before migrating your provisioning processes into Compliant UserProvisioning. These workflow-specific configuration tasks are explained in the following table.


Workflow Management

132 September 2008


Workflow-SpecificConfiguration Task Description

Custom ApproverDeterminators

Compliant User Provisioning uses approver determinators toidentify approvers at workflow runtime. However, the deliveredapprover determinators might not be sufficient for yourrequirements, because your enterprise might also need customcombinations of attributes as approver determinators. In thatcase, you can create your own custom approver determinatorsbefore you create your workflows.

For more information about how to define custom approverdeterminators, see the section Custom ApproverDeterminators.

Approvers You can define approvers in several different places, based onthe workflow approver choices.

The Approvers option allows you to define a user ID as anapprover as well as a distribution list of approvers.

For more information about approvers, see the sectionApprovers.

Custom Fields The Custom Fields option allows you to create customized fieldsthat are required for additional information or security. You canuse custom fields to determine the workflow of the request or toextend the current attributes for the organization’s requirements.

For more information about creating custom fields, see thesection Custom Fields.

Setting Up EmailReminders

Since Compliant User Provisioning processes a requestthrough a workflow path, it sends approval emails to theapprovers at each stage. However, it is not only approvers whohave a vested interest in the process. Each user involved in theprovisioning process needs to know when the request has beensubmitted and when the request has been approved. Alongwith the necessary approval emails, the system generatesemail notifications to all approvers at the time of submissionand at the time of final approval.

You can also configure Compliant User Provisioning toautomatically send email reminders to approvers who havefailed to act on requests within a specified time period. Thisaction can help to ensure that the approval process does notget sidetracked.

For more information, see the section Email Reminder Setup.


Workflow Management

September 2008 133


Workflow-SpecificConfiguration Task Description

Auto Provisioning Compliant User Provisioning automates the process ofcollecting approvals for provisioning requests, ensuring that thecorrect supervisors approve or deny all requests in a timelyfashion. You can also configure it to launch the provisioningrequest. This action streamlines the provisioning process fromstart to finish, so that it becomes an automated cycle.

Users are only required to submit requests. Approvers are onlyrequired 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 CUASystem Setting

Many enterprise environments use a single host system tomanage users. Such a system is typically referred to as theCentral User Administration (CUA) system or host. SinceCompliant User Provisioning manages the provisioning processand must authenticate the users with whom it interacts,Compliant User Provisioning communicates directly with theCUA. Therefore, if your enterprise uses a CUA, you mustdefine the CUA in Compliant User Provisioning before you canbegin creating workflows.

For more information, see the section Configuring the CUASystem Setting.

Identifying the SMTPServer

Compliant User Provisioning interacts with approvers and, ifconfigured 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 ServerIdentification.

Each workflow defines how Compliant User Provisioning manages the approval process for aspecific access request.

To create a workflow, you must create a path, name it, determine its initiator and stages, andthen activate it. If the initiator and stages you need already exist in Compliant UserProvisioning, it simplifies the process.

Prerequisites

Ensure that the initiators and stages you require exist. In some cases, you might be able touse default Compliant User Provisioning objects to construct workflows, but you must createyour own custom stages, and you need to define your initiators. Initiators and stages are thebuilding 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 theminside.

For more information, see the section About Workflows.

Before you begin creating initiators, stages, and paths, plan not only individualworkflows, but also a comprehensive approval strategy. Only when you have an ideaof the stages and initiators should you begin creating these objects.


Workflow Management

134 September 2008

Activities

When you are familiar with the Compliant User Provisioning workflow concepts and you havecreated 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 UserProvisioning. 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 beforeyou create them in Compliant User Provisioning. Some of the stages you require probablyexist as default objects. Compare the stages you need with the stages available to you, andcreate 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 ofteneasier to create the initiators first, but it is unnecessary. However, you need to createboth 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 yourworkflow paths. For more information on creating a path, see the section Creating MainPaths.

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 theapplications included in the access request. For more information, see the sections EscapeRoute and Forked Workflow Creation.

For more information about the concepts underlying escape routes and forked workflows, seethe section About Workflows.

Initiators

Initiators are collections of request attributes that act as templates. When a user submits arequest, the system compares the attributes of that request to all active initiators. If theattributes of the request match the attributes of an initiator, it uses the initiator to trigger aworkflow.

However, be careful not to create multiple initiators with the same attributes. This may causethe workflow logic to find multiple combinations and throw an error message. For example, ifyou create an initiator with the attributes Request Type and Priority, and then you createanother initiator with the attribute Priority, the workflow logic finds the two combinations ofattributes and throws an error message due to the multiple initiators. Similarly, if the workflowlogic does not find an initiator, an error message is also thrown.

Each initiator must have a unique combination of attributes. Every submitted requestshould match one initiator, and it should be impossible for a request to match more thanone initiator. If a request is submitted that somehow satisfies multiple initiators, therequest creation will fail.

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.


Workflow Management

September 2008 135

3. In the appropriate fields of the Initiator area, give the new initiator a name, shortdescription, and long description.



The Workflow Type option is available only if Compliant User Provisioning isintegrated with Risk Analysis and Remediation or Enterprise Role Management andyou 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 musthave at least one attribute and typically have two or more. Select attributes that, whencombined, match all requests that trigger this initiator and, at the same time, excluderequests 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 attributea value of Finance. In that case, for a request to match this initiator, the user for whomthe 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 inorder 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 attributeor 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 chooseattribute.

ExampleYou can have multiple attributes defined in your initiator. When defining the attributesmake sure that the Boolean operators (AND, OR, NOT) are used correctly in order forall attributes to be considered. For instance, you want the initiator to consider twoattributes. The two attributes are Functional Area = Finance and Request Type =New. By using the condition, AND, the two attributes are considered. Using thecondition, OR, only one attribute is considered.The initiator configuration below shows two attributes with two conditions, but theworkflow logic reads this configuration as Functional Area and Request Type. The ORcondition 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 inthe configuration is then considered by the workflow logic.

Condition Attribute Value

OR Functional Area Finance

AND Request Type New


Workflow Management

136 September 2008

OR Company SAPThe initiator configuration takes the attributes of Functional Area and Request Type orCompany. 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 Savedappears.

For Superuser Access, you can create an initiator with the Super User Access requesttype and use it to drive a specific workflow.

Custom Approver Determinators

Each stage of a workflow specifies an approver. You configure the approver when you createthe 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. Thisdeterminator 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 ApproverDeterminator (CAD).

ExampleYou 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 isconfigured with the same attributes. You set up the approvers for this CAD with thefollowing: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 ofRequest Type and Priority, the appropriate approver is then determined. An emailnotification is then sent to the appropriate approver. For instance, a request is submittedwith the Request Type of New and Priority of High. Therefore, the custom approver isthen determined to be FWilson.

ExampleA user requesting access in New York must be approved by the manager in NewYork. The submitted request includes the information, both department and location,but there is no default determinator that combines these two attributes. To create theManager stage, you must also create a custom determinator that enables CompliantUser Provisioning to derive who is the correct approver based on the request.


Workflow Management

September 2008 137

Creating a Custom Approver Determinator

Whether you need a custom approver determinator depends on your business needs. Theyare optional. However, many enterprises require custom approver determinators to makeproper 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. Onlywhen you have established the approvers can you determine whether you must createcustom 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 newdeterminator.


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 atruntime. Additional fields may appear, such as Workflow Type, depending on theattributes chosen.

o Select Attributes are listed for selection. These are the attributes that appear on arequest. For example, you might want a particular type of employee, such ascontractors, to be approved by the same person.

o Role Attributes are listed for selection. These are attributes assigned to the roleschosen for provisioning. For example, you might decide that all roles that belongto 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 suchas URL, user name, and password appear.

The Web service is called from Enterprise Role Management and retrieves a list ofapprovers. For example, if the Web service gets 20 approver names from EnterpriseManagement, 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 theattributes you have selected, this screen displays the attributes in the table column.

8. Click Add. The Approver Determinator Value pop-up screen appears. Use this screen toassign values to the attributes and operator.


Workflow Management

138 September 2008

For the approver and alternative approver, click the arrow icon to search for approverand alternative approvers. Click the Add icon to search and select the approver andalternate 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 tonavigate 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 approverdeterminator configuration. Use the template by adding more values to your selectedattributes, operators, approvers and alternative approvers.

You can also export the modified file to mass update custom approver determinators in othersystems by clicking Export.

Stages

There are two procedures for creating a stage:

Defining the stage:

The primary purpose of any stage is to pass a request to an approver. When you create astage, you define the user who must approve or deny a request when the requestreaches 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 identifythe 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 determinewhich 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, shortdescription, and description for the new stage in the appropriate fields.

The name you enter for the stage must be unique.



Workflow Management

September 2008 139

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 isintegrated with Risk Analysis and Remediation or Enterprise Role Management andyou have enabled the workflow types on the Miscellaneous screen.

5. From the Approver Determinator dropdown list, select the approver determinator for thestage (that is, how to identify the approver(s) of the stage). It is important to select thecorrect approver determinator. The approver determinator is used at runtime to derive theapprover for the stage.

If you select No Stage, the system automatically approves requests for the users androles going through this stage. For example, you can provision users with certainbasic roles with no approval required.

If you select Superuser Access Coordinator, the system gets the configured controllerfrom the SAP system where the Superuser Privilege Management is installed andassigns the request to that approver.

If you select Superuser Access Owner, the system fetches the configured owner fromthe SAP system where the Superuser Privilege Management is installed and assignsthe request to that approver.

6. In the Request Wait Time fields, enter the amount of time (days and/or hours) you wantCompliant User Provisioning to wait at this stage for an approver to respond to a requestbefore escalating the request.

You need to do this only if you plan to configure the stage to escalate if the approverdoes not respond. If you do not plan to define an escalation action, you can ignore thesefields.

7. From the Escalation Configuration dropdown list, select how to handle a request when anapprover fails to respond within the time allotted during stage definition:

No Escalation (default setting): Compliant User Provisioning waits for the approver’sresponse, even after the specified wait time passes, and does not take any steps toresolve the stalled request. The approver approves or rejects the request. Anadministrator can manually resolve the problem by approving on behalf of theassigned approver, forwarding the request to another approver, or rerouting therequest. For more information, see the section Request Administration.

Forward to Next Stage: Compliant User Provisioning ignores the expected approvalat 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 preventthe request from being approved. Use caution with this option since it allows therequest to bypass the defined approvers.

Forward to Alternate Approver: Provides a fallback option if the designated approverdoes not respond within the time allotted. Compliant User Provisioning reassigns theapprover. Alternate approvers must be maintained for the approver determinator ofthe stage where this option is set. Escalation to an alternate approver happens onlyonce; there is no alternate approver for the alternate. After the system escalates theapproval for the stage to the alternative approver, the original approver no longer hasaccess 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


Workflow Management

140 September 2008

administrator’s information must be maintained on the Configuration Support screenfor 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 theconfiguration options and applies them to the stage. A Workflow StageSuccessfully 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 nowconfigure 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 togenerate at this stage.

Select which users receive emails for each possible action, and compose the message toaccompany the notification.

3. In the Additional Configuration section, define any additional functionality required at thisstage.

4. In the Additional Security Configuration screen, define whether or not the approver needsto 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.

Configuring Notifications

The Notification Configuration screen configures email notifications for a stage to determinewhether 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 whenthe approver approves the request.

Rejected: The system sends the email notification configured on the Rejected tab whenthe approver rejects or denies the request.


Workflow Management

September 2008 141

Escalation: The system sends the email notification configured on the Escalation tabwhen the approver fails to respond to the request within the allotted wait time and anescalation has occurred.

Next Approver: The system sends the email notification to the approver(s) of the stagewhen the request enters this stage. The next approver is the approver of the currentstage.

The users you select next to each possible action are the users who are notified when thataction takes place. You must schedule the Email Dispatcher background job to automaticallysend these notifications. For the next approver, there is no way to turn this feature off or addadditional users to receive the emails. The background job automatically sends the nextapprover emails to each approver of the stage.

To determine who receives these emails, select the appropriate users when thecorresponding action occurs. In each email notification, a link allows the recipient to accessCompliant User Provisioning in display mode of the request. The next approver’s email linktakes the recipient into approver mode of the request. All other links go to the display mode ofthe request.

Use caution when determining which email notifications to send to which users. Too manyemail notifications can annoy the recipients. Configure email notifications for users only if it isnecessary 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 nomanager is listed, no email is sent. (This does not cause an error.)

Other Approvers: Sends email notification to all approvers that have been involved inthe request up to and including this stage.

If the user, requestor and/or approvers are the same, each receives multiple emailnotifications. When sending an email notification to the user and the requestor, if theuser is the requestor, the system sends two email notifications. If the requestor andthe manager are the same user, that person receives two emails.

Select these email notification options with caution. If users receive too many emailnotifications, they get used to ignoring them or get frustrated due to the amount ofunnecessary email they are receiving.

In addition, you can compose a different rich text or HTML message for each action youselect to accompany the notification. Click the tab that corresponds with the notification actionyou select, and enter your message in the field provided.

Select the appropriate Email Arguments from the dropdown list when configuring yournotification. Email arguments allow you to include specific information in the email. You canchange 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 stagereceive a blank email with only a link to this request in Compliant User Provisioning whenrequests enter this stage. Email content is limited to 2000 characters.


Workflow Management

142 September 2008

Additional Configuration

The Additional Configuration screen refines the behavior of a stage. The options availabledepend 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, allfuture options are based on that selection. Some fields become available and others becomeunavailable.

Risk Analysis Mandatory: Select Yes or No to determine whether the approver is requiredto perform a risk analysis before approving the request.

Change Request Content: An approver has the authority to change the content of therequest.

o If set to Yes, the Add Roles field becomes available for selection. Select Yes or No toallow roles to be added during this stage.

o If set to Yes, the Path Evaluation For New Roles field becomes available forselection. This setting determines how the roles are evaluated to see if they are onthe correct path (This is necessary only if you configure your initiators by roles).

o All Roles in Evaluation Path: All roles are re-evaluated against the initiators.

New Roles Only: These new roles are analyzed against the initiators todetermine if another parallel workflow mist be created for the newly added roles.

None: No re-evaluation is conducted.

o If the Change Request Content configuration option is set to Yes but Add Roles is setto No, the approver can remove roles from the request but not add additional roles.

o If the Change Request Content configuration option is set to No, the approver cannotchange the roles on the request. They cannot reject or remove roles nor can theyadd additional 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. Whenthey are approving all roles or when they reject, they are rejecting all roles. Forexample, manager and security approvers can approve or reject any role on therequest.

o Role: Approvers can only approve those roles that belong to them. This option isespecially 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 theyare 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 isespecially 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 whetherall 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 backwardscompatibility.


Workflow Management

September 2008 143

Comments Mandatory: Select whether the approver is required to enter comments whenapproving or rejecting the request. If you set this option toYes, checkboxes appear toallow the user to specify when comments are required (on Approvals, RequestRejections, or both).

Request Rejection: If you set this option to Yes, the approver is allowed to reject theentire request. The Reject button appears next to the Approve button, so the approvercan reject the entire request without individually rejecting each role. If No, the approverscan 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 asan alternative to rejecting the request entirely. Re-routing does not apply if the approverchooses to approve the request.

Confirm Approval: The approver must answer an additional question, if he or she wantsto confirm the approval action.

Confirm Rejection: The approver must answer an additional question, if he or she wantsto confirm the rejection action.

Reject by Email and Approve by Email: The approver can reject or approve the requestby email.

o If you set this option to Yes, there could be two additional links on the email when theapprover gets the email notification for this stage, stating that there is a requestwaiting for action. One link is for the Approve Request Action, if Approve by Emailspecifies Yes. Another link is for Reject Request Action, if Reject by Email specifiesYes. The approver can use these buttons, and the link transfers them to CompliantUser Provisioning. The approver must still be the valid approver for this stage of therequest 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 fieldmust be set to Yes. If you set this option to No, these buttons do not appear in the email notification

to the next approver.

Reject by Email: The approver can reject the request by email. This setting is not anoption 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 theapprover gets the email notification for this stage, stating that there is a requestwaiting for action. The approver can use this button, and the link transfers them toCompliant User Provisioning. The approver must still be the valid approver for thisstage 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 tothe next approver.

Approve by Email: Options will allow the approver to approve the request by email. Thissetting will not be an option if actions are required for instance if Risk Analysis orComments are required.

o If you set this option to Yes, there could be an additional link on the email when theapprover gets the email notification for this stage, stating that there is a requestwaiting for action. The approver can use this button, and the link transfers them toCompliant User Provisioning. The approver must still be the valid approver for thisstage 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 tothe next approver.


Workflow Management

144 September 2008

Forward: The approver has the authority to forward the request to someone else forapproval.

Approve request despite risks:

o If you set this option to Yes, the approver is allowed to approve this stage, even ifthere are SoD violations that have not been mitigated.

o If you set this option to No, the approver at this stage must remediate (remove) ormitigate the violation before he or she can approve the request. The approver isrequired to enter comments when approving or denying the request.

Forward Type: Options Any One Approver or All Approvals: If you select the Forwardoption, you can specify whether:

o Any one of the approvers that the request is forwarded can approve and the requestcan continue on.

o All approvers listed on the Forward are required to approve before the request cancontinue on.

Additional Security Configuration

The Additional Security Configuration screen specifies whether the approver needs to confirmhis or her identity to take an action at this stage. Approvers confirm their identities (reaffirmtheir decisions) by entering their password at a prompt when they take an action. The actionsthat can be configured to require reaffirmation are:

Approve

Reject

Create User

Paths

After creating and configuring initiators and stages, you can create workflow paths. There arethree 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:

a. Enter a Name.

The name of the path must be unique. It might also be useful to give the path both aname and a description that are easy for you to identify later.

b. Enter a Short Description.


Workflow Management

September 2008 145

The short description appears in dropdown lists throughout Compliant UserProvisioning as an option when you perform a query. This field is limited to 38characters.

c. Enter a Description.

The description is longer than the short description and can contain more detailedinformation.

d. Select a Workflow Type.

The Workflow Type option is available only if Compliant User Provisioning isintegrated with Risk Analysis and Remediation or Enterprise Role Management andyou have enabled the workflow types on the Miscellaneous screen.e. In the No. of Stages field, enter the number of stages you want to include in the path.

f. From the Initiator dropdown list, select the initiator that triggers the workflow to whichthe path belongs.

g. 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 thischeckbox selected, the path becomes a detour. If it is a detour, it cannot have aninitiator, 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 apath 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.When you finished entering these details, the system displays a graphical representationof the path.

4. Click Save.

A Workflow Path Successfully Saved message is displayed. When you return tothe Workflow Paths screen, the new path is listed.

Detour Paths

Detours are standalone workflows that assume management of a request from a mainworkflow. Detours are not subsets or dependents of main workflows. They do not haveinitiators, so they cannot be triggered by a submitted request. If the state of a request meetspredefined 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 fromproceeding on its defined path. If something occurs that interferes with a request, the mainworkflow 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 thanone role. If an approver denies one of the roles in the request, you might want the remainderof the request to proceed. Rather than aborting the request, you can have the main workflowtransfer it to a detour workflow. The detour can then continue the approval process for theremaining roles.


Workflow Management

146 September 2008

When the main workflow passes a request to a detour workflow, the request ceases tobe 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 adefined starting point and a sequence of one or more stages. At each stage of the detour, anapprover must approve the request before it can proceed.

You create a detour using the same procedures that you use to create a main workflow. Formore information, see the section Creating New Workflows.

For more information about how to define a jump from a main workflow to a detour, see thesection 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 botha name and a description that are easy for you to identify.

b. Enter a Short Description.

The short description appears in dropdown lists in different places throughoutCompliant User Provisioning as an option when you perform a query. This field islimited to 38 characters.

c. Enter a Description.

The description is longer than the short description and can contain more detailedinformation.

d. Select a Workflow Type.

e. In the No. of Stages field, enter the number of stages you want to include in thedetour path.

f. Ensure that there is no value selected in the Initiator dropdown list.

g. Select the Active checkbox to make the path active when you save the path.

h. Select the Detour checkbox to specify that this path is a detour.

When you finish entering these details, the system displays a graphicalrepresentation of the detour path.

4. Click Save.

A Workflow Path Successfully Saved message appears. When you return to theWorkflow Paths screen, the new path is listed.


Workflow Management

September 2008 147

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 isintegrated with Risk Analysis and Remediation or Enterprise Role Management andyou have enabled Workflow Types on the Miscellaneous screen.b. In the Path dropdown list, select the main path to which you want to connect the

detour.

c. In the Stage dropdown list, select the stage of the main path where you want therequest to jump to the detour.

d. In the Action dropdown list, select the action that must occur to execute the detour.

e. In the Condition dropdown list, select the condition that must occur to execute thedetour. 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 aremitigated 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 roleapprovers and some do not, the request splits into a parallel workflow withthose roles with no role approvers routed directly other than the roles withrole approvers.

Verification/Training Failed – Request Level: When a verification/ trainingsystem has been implemented and Compliant User Provisioning isconfigured to verify training.

Role Verification/Training Failed – Role Level: When a verification/ trainingsystem has been implemented and Compliant User Provisioning isconfigured to verify training.

NDA Not Signed For Insider Roles: Not generally used.

f. In the Value dropdown list, select Yes or No to specify whether the detour executesin 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 conditionoccurs.

If you select No, the detour executes only when the condition does not occur.

g. In the Detour Path dropdown list, select the detour path to which you want to connectthe main path.

4. Click Save.


Workflow Management

148 September 2008

A Workflow Detour Successfully Created message appears. The detourconfiguration is now listed on the Workflow Stage Detour screen.

After a request routes to a detour, it completes the workflow on the detour path. Adetour 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, theworkflow determines which path is appropriate to manage the request. A forked workflow canmanage a request using either one of its paths or both, depending on the condition of therequest.

Forked workflows are available only when separating workflows by SAP andworkflows 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 theworkflow. The decision itself is based on whether the requested access is for an SAPapplication or for a non-SAP application.

If the approval process for a user request is the same for access to SAP applicationsas it is for non-SAP applications, there is no reason to use a forked workflow tomanage the request.

ExampleYou can create an initiator that calls a workflow to manage all user access requestswhere 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 matchesthe 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, submittingthe request calls the same initiator. If the workflow forks, the attributes of the requestdetermine how the workflow manages the request:

If it requests access to SAP applications only, the path configured to manage SAPapplication approvals manages the request.

If it requests access to non-SAP applications only, the path configured to managenon-SAP application approvals manages the request.

If it requests access to both SAP and non-SAP applications, the request followsboth paths simultaneously.

Creating forked workflows is optional. If the approval process for access to non-SAPapplications differs from the process for SAP applications, you can configure it in either of twoways:

Create two different initiators, one for each application type, with each workflow handlingrequests 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 ForkedWorkflow Creation.


Workflow Management

September 2008 149

In most cases, the terms workflow and path are interchangeable, because the majority ofworkflows 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 todifferent types of applications. The distinction between these types of applications is whetheror not they are native SAP applications. Compliant User Provisioning provides forkedworkflows 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 foreither an SAP or a non-SAP application (or both).

You want to use a different path to handle access requests for SAP applications than theone 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 applicationtype. However, creating a single workflow to handle both can simplify the task of creatinginitiators and workflows.

You create a forked workflow by joining two distinct, independent paths. At least one of thesepaths must be a main path, triggered by an initiator. A forked workflow begins with one pathand then joins a second path to it. The first path must be a main path. The second path canbe either a main path or a detour.

The procedure that follows describes how to join two existing paths together to form a fork. Ifthe fork you want to create includes paths that do not exist, you must create the paths beforeyou 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.

b. From the Initiator dropdown list, select the main path on which you want to base thefork.

c. From the Action dropdown list, select Save.

d. From the Condition dropdown list, select the condition that must occur to execute theforked path.

e. From the Value dropdown list, select either Yes to specify if the workflow occurs inthe presence of the condition defined in the third dropdown list, or No to specify if theworkflow forks in its absence.

f. If you select Yes, the request follows the fork only when the specified conditionoccurs. If you select No, the request follows the fork only when the condition does notoccur.

g. From the Fork Path dropdown list, select the alternative path you want to join to theprimary path to form the fork.


Email Reminder Setup

150 September 2008

5. Click Save.

A success message appears. The new fork is listed on the Path Fork tab of the WorkFlow Stage Detour screen.

Email Reminder SetupYou can configure email messages to communicate with users, requestors, managers, andapprovers. You can also configure email reminders to send request progress notifications tointerested parties and reminders to approvers who have failed to act within a specified timeperiod. The configuration process is the same for both reminders and notifications.

On the configuration screen, you can determine whether or not to send the password to auser when the user is created in the back-end system. Several companies have implementeda Single Sign-on procedure in which the user does not need to log on to each system with aseparate user ID and password. If you set up something similar, do not include the passwordin the new user ID notification email.

When the system sends a password, it sends a link to the password display, not thepassword itself. In addition to being able to configure whether the password is included in theemail, you can specify how long the user can access the password using the link included inthe email.

For every new user created in the system, the system automatically sends an emailnotification to the user. This email goes to the email address listed on the request andincludes the new user’s ID and the list of systems that the user can access. Thesystem sends the email notification automatically; it is not configurable. For securitynotification reasons, the system sends the email only to the user listed on the request.The only configuration control for this email is whether or not a password is includedin the email.

Setting Up Email Reminders or Notifications

Procedure

To set up an email reminder or notification:

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 or notification youwant to configure.

There are several different types of email notification. You can configure the content ofthe email messages based on the type of notification.

The options that appear on the dropdown lists are the short descriptions of the workflowtypes that you configured on the Miscellaneous screen.

3. In the Days field, enter the number of days after the event that an email reminder isgenerated.

Typically, this only applies to reminders. In most cases, email notifications are generatedimmediately upon submission or completion.

4. In the Subject and Comment fields, enter text.



September 2008 151

5. 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 notifyapprovers. In the Notification Configuration section, select the Other Approverscheckbox.

Submission: When a request is submitted, an email reminder can be sent tonotify the user, the requestor, the manager and other approvers. In theNotification Configuration section, select the checkboxes. The email reminderincludes a link to view the status of the request.

Closing: When a request is closed, an email reminder can be sent to notify theuser, the requestor, the manager and other approvers. In the NotificationConfiguration section, select the checkboxes.

6. In the Subject and Content fields, enter the appropriate text. You can also add specificrequest data to the email reminder in the Content fields. The email argument variable canbe copied into the Subject field of the email.

7. In the Submission tab, select who should receive email notifications of request closing.Select one or many email recipients, which includes User, Requestor, and/or Manager.For the Closing tab, you can also select one or many email recipients including, OtherApprovers.

8. Click Save.

You can also add specific request data to the email reminder. The email argument variablecan be copied into the Subject field of the email.

Setting Up New User Password NotificationsProcedure

To set up new user password notification:

1. On the Configuration tab, navigate to Workflow > Email Reminder.

2. Click the Closing tab.

3. For Send password in email field, select Yes or No.

If you select Yes, the system includes the password in the email.

4. From the Password Display Period (in Seconds) field, enter the number of secondsfor which the password is displayed to the user when the link is clicked in the email.

Escape Route

Workflow Escape Routes

An escape route is a mechanism you configure as part of a workflow to handle an ApproverNot Found condition at the first stage. The purpose of an escape route is to prevent a requestfrom being trapped in an irreconcilable situation by causing the request to bypass one ormore stages of the workflow. If a workflow encounters an Approver Not Found condition atthe 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 orwhere the request is sent if an approver is not found. From there, the request follows theescape route workflow until the end of that workflow.

When a request takes a path other than its intended path, there can be securityconsequences. Since a request bypassing approval stages presents a risk that itmight not meet security requirements, one common application of escape routes is topass the request directly to a security stage, where the request can be evaluated.



152 September 2008

After the request has been evaluated, the security user routes the request to theappropriate 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 andcannot be determined by the workflow path. Only one escape route can be created and onlyfor 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 requestwhere the approver is not found proceeds down the same escape route. This couldcause 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 notfound on submission of the request.

Approver Not Found applies to all requests submitted. It cannot be set for specificworkflow paths.

Approver Not Found is a very specific condition. It informs you that the workflowcannot derive the identity of the designated approver, because the attributes of theapprover are either ambiguous or inadequate. If Compliant User Provisioning cannotdetermine who the first approver is, the email notification cannot be sent, and thesystem responds with an Approver Not Found message. Only in these cases willthe request follow the escape route instead of the route by configured on theinitiators.

Approver Not Found at a Stage

Approver Not Found at a Stage resolves the situation when the next approver cannotbe found. In this case, the request transfers to the escape route instead of displayingthe error of Approver Not Found to the current approver.

Approver Not Found at a Stage applies to all requests submitted on all workflows. Itcannot be set for specific workflow paths or specific stages.

Auto Provisioning Failure

Auto Provisioning Failure is triggered when auto provisioning failures occur. You canestablish an escape route to send the requests to security or to a Compliant UserProvisioning 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 therequest. The request waits in this approver’s inbox until the provision situation hasbeen cleared. After this approver is cleared, he or she must approve the requestagain, so that the request is provisioned and closed.

Since an escape route is an attribute of a workflow, you must create a workflow beforeyou can add an escape route to it.


SMTP Server Identification

September 2008 153

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 isintegrated with other Access Control capabilities and you have enabled the WorkflowTypes on the Miscellaneous screen.

b. From the Condition dropdown list, select Approver Not Found, Approver Not Foundat a Stage, or Auto Provisioning Failure.

c. From the Path dropdown list, select the path that the request follows if the conditionsare met.

d. From the Stage dropdown list, select the stage of the specified path that the requestfollows if the conditions are met.

3. Click Save.

4. From the Escape Routing Enabled dropdown list, select Yes if using escape routes or Noif 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.

SMTP Server IdentificationTo send notification emails to the users, requestors, and approvers of the requests, you mustconfigure Compliant User Provisioning to use the correct mail server. Compliant UserProvisioning communicates with approvers through email messages.

If this setting is not properly configured, the approval process does not work properly.Emails sent by Compliant User Provisioning to notify requestors, approvers, andadministrators 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. In the Email Server Name field, enter the name of the SMTP server that Compliant UserProvisioning uses to transmit messages.

3. Click Save.


CUA System Setting Configuration

154 September 2008

Emails are not sent automatically. To send the emails, run the Email Dispatcher as abackground job. For more information, see the section Setting Up Background Jobs.

CUA System Setting ConfigurationThis 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 choosebetween the two. There are reasons to use the CUA and reasons to use Compliant UserProvisioning.

CUA manages users and their access in the child systems.

Compliant User Provisioning provides the access request ability, audit trails for theapprovers on the requests, and provisions the approved roles to the CUA.

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 pushesthose roles down to the child systems. Compliant User Provisioning allows the CUA tomanage the access in the child systems.

You must create connectors and install the appropriate RTAs on those systems for the CUAparent system, as well as each of the CUA client systems.

For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAPService Marketplace at http://service.sap.com/instguides -> SAP SolutionExtensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC AccessControl 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 andapprove the access to the individual applications (child system clients), but you provision theaccess with the CUA.

The CUA system setting can be a global setting in Compliant User Provisioning, or it can beset by each individual system connector. Therefore, some of your systems can be connectedto a CUA and others not connected, but both can be provisioned through Compliant UserProvisioning.

Since most of the activity between the requestor and approver occurs directly within theapplication itself, the only difference is that a CUA client is where the user and roles areprovisioned. If it is a CUA child system, provisioning happens on the CUA parent, whereas anon-CUA system provisions to itself.

You must load roles for the CUA child clients into Compliant User Provisioning to make themavailable for the requestor to select them through the Select Roles functionality. Do not loadCUA child system roles assigned to the CUA parent system into Compliant UserProvisioning; load them only to the child systems.

Configuring the CUA System Setting

Procedure

For organizations with complex SAP landscapes consisting of many SAP systems, SAPrecommends that you use CUA for user administration tasks. Using CUA enables securityadministrators to maintain user master records centrally from one system. Compliant UserProvisioning provides the ability to perform user provisioning centrally from one system, but itdoes not replace CUA. Compliant User Provisioning deals mainly with compliant automatedprovisioning.



September 2008 155

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 thesame as the logical system names defined in the CUA master and child systems.

From your SAP server (back-end system), start transaction SCUA. The MaintainSystem Landscape appears. The name displayed in the Sending System field is themaster 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.







11. 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 eachof the tasks required. If provisioning is configured for this connector, the user ID mustbe authorized to maintain users in the SAP system. If provisioning is configured, thisuser ID appears on each change record on the SU01 user master record.

For more information about user ID authorization, see the SAP GRC AccessControl 5.3 Security Guide on SAP Service Marketplace athttp://service.sap.com/instguides -> SAP Solution Extensions -> SAPSolutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Ensure that the user ID associated with this name has the proper access toview/maintain the SU01 user records.

12. In the Password field, enter the specified password for the SAP user ID.

13. In the System Language field, enter the language for the system. The BASISadministrator provides this information.

14. In the Message Server Name, enter the name of the message server, which is usedfor load balancing of your SAP clustered environment.

15. In the Message Server Group, enter the group name to which the message serverbelongs. Your BASIS administrator provides this information.



156 September 2008

16. In the Message Server Host, enter the host name of your message server. YourBASIS administrator provides this information.

17. In the SAP Version dropdown menu, select the appropriate SAP version. CompliantUser Provisioning supports SAP 4.6C, 4.7, and ECC 6.0.

18. In the HR System dropdown menu, select Yes or No to indicate if an SAP HR systemis used or not. An HR system flag indicates whether the SAPHR module is installedon this connector, not necessarily whether you are using the SAPHR module. If thesystem is an HR system, the appropriate HR RTAs must be installed. For moreinformation, see the SAP GRC Access Control Installation Guide.

19. In the SLD Connector checkbox, select this checkbox to enable the StandardLandscape Directory.

20. In the Connector Category dropdown menu, select the category to which theconnector belongs. The choices are Production, Non-Production, or Other. Thisselection is used to help classify the servers into the appropriate categories in theaccess request forms.

21. In the Role dropdown menu, select whether or not role information comes fromEnterprise Role Management or the SAP backend.

22. In the HR Manager Path dropdown menu, do the following:

a. If you are using SAPHR as the user details data source and want theManager 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 theuser’s HR record, set this field to (A002) – Reports (line) to (fororganizational units).

SAP HR provides an organizational structure view that contains theobject, relationships, and attributes. The organizational structure viewcontains the relationship types, B012-Managers and A002- Reports to.

23. Click Create.

24. Click Test Connection.

25. Repeat Steps 2 through 24 to configure for child systems.

Configuring CUA Master System

In order to provision through the CUA system, the CUA master system name needs to be setin 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 menudisplays a list of all SAP systems configured as connectors.

Make sure that the master system and child system/client are created as an SAPconnector.



September 2008 157

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

If your environment does not use a CUA system, make sure that there is nohost 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 doesuse a CUA, continue with the next steps.

4. In the Function Template fields of both the CUA User Provisioning Configuration andCUA Role Provisioning Configuration areas, select either Standard or Custom.

Select Standard triggers Compliant User Provisioning to use out-of-the-boxprograms for CUA provisioning.

Select Custom if you have developed custom CUA BAPIs. If you are usingcustom BAPIs, contact SAP Technical Support to ensure that your BAPIsintegrate 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 systemconnectors.

To add another system to this table, click Create.

To change an existing CUA system configuration, select the system and clickChange.

All available fields for changing appear editable.

8. If you have selected Create, select the other system you wish to add from the Systemdropdown 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.

10. In the CUA System field, if the system is configured as a CUA child client, select thesystem connector.

11. You can configure multiple CUAs. To do so, select the CUA system that is connected tothe child system you are maintaining.

12. For each field, User Provisioning Function Template and Role Provisioning FunctionTemplate, 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 UserProvisioning.


Auto Provisioning

158 September 2008

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 inthe connectors for all master and child systems.

2. If step 1 is not successful, you can also modify the application name and shortdescription of the connectors to be the same as the connector name. Go to CompliantUser 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 theName field.

5. Click Save.

Auto ProvisioningCompliant User Provisioning automates the collection of approvals for access and alsoautomatically provisions access to the target back-end system(s). Auto provisioning can bedone either globally or by system.

Auto provisioning is optional, but it is activated by default. If you do not want to usethis functionality, select No for Auto Provisioning.

Auto provisioning is only available to SAP systems and non-SAP systems supportedwith RTAs. Non-RTA systems, such as legacy systems, can only be provisionedmanually.

Auto provisioning can occur on the SAP User Master Record (transaction SU01), which isreferred to as Direct Provisioning, or against the SAP HR system. If you configure an HR jobor 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 masterrecord, 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 DirectProvisioning.

If you assign security roles based on the user’s HR organizational position, use InDirectprovisioning. In InDirect provisioning, Compliant User Provisioning sends a request to theSAP 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 DoNot Autoprovision.

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


Auto Provisioning

September 2008 159

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 Typedropdown list, select the type:

Direct:Most companies use Direct provisioning. This method allows Compliant UserProvisioning to modify the user’s master record directly, changing the user’sassigned permissions as defined in the request.

Indirect:If you select InDirect, you must select the type of HR object Compliant UserProvisioning needs to transmit to the HR module. There are three possible objecttypes: Position, OrgType, and Job.

Combined: During provisioning, the system tries to use InDirect provisioning. If itfails, it tries Direct provisioning.

If you select Combined, you must select the type of HR object Compliant UserProvisioning needs to transmit to the HR module. There are three possible objecttypes: Position, OrgType, and Job.

These settings can also be configured by system. For more information, see thesection Configuring Auto Provisioning by System.

3. Click Save.

4. Under Auto Provisioning – Provisioning Options, from the Auto Provisioning Typedropdown list, select the type:

Auto Provision At End of Request: Select this option to begin provisioning whenall of the workflow paths in the submitted request are approved.

Auto Provision At End of Each Path: Select this option to provision the accessrequested for each path as the path is approved. This method works only whenthe request splits into parallel workflows.

No Auto Provision: Select this option to turn off auto provisioning

5. Click Save.

6. Under Auto Provisioning – Provisioning – Change Request Options, select one of thefollowing 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 ofthe user.

7. Click Save.

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

Use this setting with SAPHR indirect provisioning only.


Auto Provisioning

160 September 2008

9. Click Save.

10. Under Password Expiration for ORAAPPS, select the basis on which the passwordexpires: 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 oraccesses becomes active.

11. Enter the number of days or accesses, if required.

12. Click Save.

13. Under Provisioning – Role Assignment, from the Provisioning Effective Immediatelydropdown 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 afterprovisioning. If you select No, the User Compare feature in the SAP system does not run.

14. Click Save.

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

System: Select the system in which you want to enable specific system settingsfor auto provisioning.

Default Role Provisioning Type: Select Direct, InDirect, or Combined.

Select InDirect or Combined only if your SAP environment includes the SAP HRmodule and you want to use SAP HR to perform provisioning on the HR recordinstead 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 CompliantUser Provisioning needs to transmit to the HR module from the Indirect ProvisioningType dropdown list.

Indirect Provisioning Type: Select Jobs, Position, and OrgType. This setting isavailable 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 toautomatically create the user. Select No if you do not want the user automaticallycreated.

Provisioning – Old Roles Delimit Duration: Enter the length of time fortransitioning from an old position to a new position. Use this setting only withSAPHR indirect provisioning.


Approvers

September 2008 161

Password Expiration for ORAAPPS: Select the basis on which the passwordexpires: 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 oraccesses becomes active.

Provisioning Effective Immediately: Select Yes if you want the provisioningprocess to be in effect immediately. Select No if you do not want it to startimmediately.

3. Click Save.

ApproversYou 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 thoseapprovers by attributes in Compliant User Provisioning.

The Approvers option defines a user ID as an approver. The Approver feature stores theapprover information on the following attributes:

Defining security lead – In general, the security lead is the person(s) responsible for thesecurity of a particular system(s).

Defining point of contact (based on functional area) – The contact person for a functionalarea is someone whose role is responsible for that particular business module.

Defining application approver – The application approver is based on the connector typeyou defined in the Application Configuration screen. This person is responsible for theapplication type.

Defining distribution group – You define the distribution group(s) in the Distribution Groupoption. This distribution group is associated with one or more distribution list.

Defining distribution list approver – You define the distribution list, which contains thenames 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 thedefined approvers to forward the request. For example, you can define an approver andalternate approver for the standard approver (Security, Point of Contact, Applicationapprover, and Distribution Group) or create your own approvers by configuring a CustomApprover Determinator (CAD). This CAD can be based on attributes such as functional areaand company, for a workflow stage. You can manually add a user ID as an approver by usingthe Search feature or import a text file containing user IDs of approvers. You then select anapprover and alternate approver.

Defining an alternate approver ID is mainly used for the workflow escalation process. Youdefine an alternate approver for Security, Point of Contact, and Application approver.

ExampleWhen you create a workflow stage using Stage Configuration screen, you set theWorkflow Type to CUP, which is a standard workflow type. You then set the ApproverDeterminator to Security. In the Request Wait Time (Days), enter the amount of daysyou want the approver to respond. Enter 1 for one day. In the Escalation Configurationfield, you select Forward to Alternate Approver. You also configure a background jobto send email notification for escalation. So after a day that the approver did notrespond to a request, Compliant User Provisioning sends a notification email to thealternate approver that you defined in the Security Approver screen.


Approvers

162 September 2008

Make sure that the user IDs for the approver and alternate approver exist in whatever searchdata source you have configured. The only approvers that must be defined are those that areused as approver determinators in the stages of your workflows.

Only add alternative approvers for those approvers whose stage is set with theirApprover Determinator and the stage is set for escalation to alternative approvers. Ifyou do not use escalation to alternative approvers, there is no need to add alternativeapprovers.

Security Leads

The Security Lead option defines a group email address, a primary security lead (ApproverID), and alternate security lead (Alternate Approver ID). The security lead is a standardapprover 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 groupemail address, instead of sending the email notifications to each security team memberindividually.

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 alternatesecurity 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 businessmodule. The Point of Contact option maps a functional area to a user ID, designated as theprimary contact and primary approver, as well as an alternate approver for escalationpurposes. 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 POCapprover 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 thecreation 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.


Approvers

September 2008 163

The Point of Contact, Approver Information screen appears.

2. Click Create.

At the bottom of the Functional Area column, a dropdown list is activated and two emptyfields 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 toquery for the desired user ID.

5. In the Alternate Point of Contact column, enter the User ID to assign the alternate POCapprover 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. Theapplication approver is a standard approver determinator that is available for selection duringany stage creation. Application approvers must be defined only in the determinator used in astage.

The list of options in the dropdown list is the applications configured as connectors, which areconfigured 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, andAlternate 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 primaryapprover.

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 thesecondary approver (if using escalation).

6. Click Save.

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


Approvers

164 September 2008

You can create a distribution group for only those distribution lists that exist in yourLDAP directories.

For detailed information on how to configure an LDAP directory, see DefiningConnectors 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 ApproversThe 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 distributionlist of approvers to a workflow stage where roles are assigned. if, for example, you wantapproval to assign the role Z_AP_Payable to a user, you can search for this role usingSearch Role and configure the Role Approver by specifying a distribution group. Thisdistribution group can have more than one distribution list. When a role stage receives therequest for approval of Z_AP_Payable, the request is forwarded to all approvers in thedistribution 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 inthis 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 forthe distribution list.

Currently, only LDAP directories are supported as a DL connector.6. Click Add.


Stale Requests

September 2008 165

Stale RequestsCompliant User Provisioning allows you to close any older request in the system that hasbeen waiting for an approver for a long period of time. Older requests are considered StaleRequests. Stale Requests can be processed and closed after a specified number of days.

1. On the Configuration tab, navigate to Workflow > 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 theaction is executed.

4. Click Save.

You must schedule a background job to review all open requests against the Stale Requestssettings. Any request that meets the Number of Days configuration setting is automaticallyclosed.

Request AdministrationOn 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 andreporting.

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 theAdministration screen is controlled by User Management Engine permissions.

Use caution when granting users access to the Administration screen. From thisscreen, a user can approve and/or reject any request in the system at any stage alongany path. The result could be that a request bypasses one or more required approvalstages.

ArchiveArchiving Requests is a way to view only the current period’s requests during normal viewing.

All requests for access are stored in the Compliant User Provisioning database. The systemcloses the requests after they are approved or rejected. The Archiving Requests functionalityhelps you archive the closed requests. The archived requests remain in the database but arenot 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 recordsare archived.

3. From the Date From dropdown list, select the oldest date of the closed records youwant to archive.

4. From the Date To dropdown list, select the most current date of the closed recordsyou want to archive.

5. You can search the archive records by enabling the Archive Request flag whenperforming the search. The Archive Request flag is located on the Search Requestsand Search Audit Trail screens, as well as on the Informer Reports.


Field Mapping

166 September 2008

Field MappingProvisioning

Field mapping provisioning allows you to provision fields from the Access Request to fieldson the SAP User Master Record (using transaction SU01). By doing this, you can provision asingle user to one or many SAP systems without having to go to each back-end system andmanually create a user. You can also create custom attributes for provisioning users to anon-SAP system (RTA-supported system).

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

For more information about configuring user data source, see the section, User DataResource Definition in this guide.

ExampleYou can map fields using Requestor FName from Access Request screen to the fieldManager 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 inthe Create Request screen. These fields can be mapped to the SAP User Master Recordscreen in the back-end system:

Business Area Company Cost Center

Department Email Address Functional Area

Job Location Manager Email

Manager FName Manager ID Manager LName

ManagerTelephone Org. Unit Personnel Number

Position Request Category Request Reason

Request Reason Requestor Email Requestor FName

Requestor ID Requestor LName Requestor Telephone

SNC Telephone Number Unsecured SNC Logon

User FName User ID User LName

User End Valid Date User Start Valid Date

Field Mapping for Provisioning System

Procedure

To map a field for a provisioning system:

1. On the Configuration tab, navigate to Field Mapping > Provisioning

The Field Mapping screen appears.

2. In the Group Name field, enter the name of the group of systems.


Field Mapping

September 2008 167


4. In the Connector dropdown menu, select the type of connector for the system.

5. In the Version dropdown menu, select the version number of the system.

6. In the Application dropdown menu, select a system name.

7. In the Default System pane, indicate if this system is a default by selecting the button.

8. Click the Plus icon to add another system to the group or click the Minus icon to removea system.

9. Click Continue.

10. In the AC Field pane, click the menu button to display the list of standard and customattributes.

11. In the Application Field pane, click the menu button to display the list of field namesassociated with the SAP User Master Record (using transaction, SU01).

12. Click the Plus icon to add another attribute field. Otherwise, click the Minus icon toremove an attribute.

13. Click Save.

LDAP Mapping

The LDAP Mapping option maps fields to corresponding fields in an LDAP database. Inaddition, you can add fields and then map them to attributes that already exist in yourenterprise’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 thatyou configured in the User Data Source option. The User Data Source option is where youconfigure one or many LDAP data source for searching and retrieving user detailinformation.

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

The following standard fields are provided by Compliant User Provisioning and can bemapped 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

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

Creating Additional Fields for LDAP Mapping

Procedure

To create additional fields for LDAP mapping:


User Review

168 September 2008

1. Click the icon at the bottom of the Additional Fields screen.

A dropdown list and field becomes active in the AE Fields and LDAP Fields columns.

2. From the dropdown list in the AE Fields column, select a field name.

3. In the selected field in the LDAP Fields column, enter the name of the LDAP attribute towhich you want to map.

4. Click Save.

Mapping an LDAP System

Procedure

To map an LDAP system:

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

The LDAP Mapping screen appears.

2. From the System dropdown list, select the appropriate LDAP system.

3. In the Employee ID field, enter the user ID that you want to map with the LDAP system.

4. In the First Name field, enter the user’s first name.

5. In the Last Name field, enter the user’s last name.

6. In the Email field, enter the user’s email address.

7. In the Department field, enter the user’s department name.

8. In the Telephone field, enter the user’s phone number.

9. In the Object Class field, enter the object class associated with the user.

10. In the Location field, enter the location of the user.

11. In the Location Country field, enter the country code for the country in which the user islocated.

12. In the UniqueLDAPKey field, enter a unique identifier for the LDAP mapping.

13. In the Manager field, enter the name of the name of the user’s manager.

14. In the Distribution List Member field, enter the name of the distribution list of roleapprovers for an LDAP directory.

15. Click Save.

User ReviewUser review allows designated approvers to review access and risk violations (both user andSoD violations) and take corrective actions. These two procedures are referred to as UserAccess Review and User SoD Review.

As part of compliance standards, companies are required to mitigate or remediate accessrisks and reaffirm mitigating controls. Periodic reviews of users’ access, risk violations, andcontrols are required as well. The internal compliance team can plan user access reviewssemi-annually, annually, or on other periodic bases in accordance with on company policies.

Access Control provides the following automated review features:

User SoD Review


User Review

September 2008 169

User Access Review (UAR)

User SoD Review and User Access Review both require Risk Analysis andRemediation to be set up for offline risk analysis processing. As a prerequisite,perform the following: For User SoD Review, run Role Usage Synchronization as a background job in

the Enterprise Role Management for all systems. For User Access Review, run Offline Risk Analysis from Risk Analysis and

Remediation.To produce tasks/requests for reviewers in User SoD Review and User Access Review, youmust configure workflow in Compliant User Provisioning.

The data to create SoD Review tasks/requests is derived from Risk Analysis andRemediation

The data for User Access Review is derived from Enterprise Role Management. Yourun a job in Enterprise Role Management get the user and role assignment from theback-end system. Then you run a job in CUP to pull in that data and create theUAR requests.

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

In this process, there are reviewers and coordinators.

Reviewers are users who review user access and SoD violations and mitigations.

Coordinators are users who monitor the process and make sure the reviewers arecompleting the reviews.

The system notifies the coordinator of any violations and updates the status of the reviewsperformed.

To assign coordinators to reviewers, you use the Coordinator table. You can manually enterthe assignments or upload them by navigating to User Review > Coordinators on theConfiguration tab. You can download a load template for reference.

Access Control administrators can purge usage information for user reviews prior to creatingthe workflow requests. For example, if you require only the prior three months of usage forreporting in the user reviews, the administrator can purge the data that is three months old ormore. This feature is controlled by the Risk Analysis and Remediation capability. For moreinformation, see the section Purge Action Usage Utility.

Initiating User SoD Reviews

Procedure

To configure SoD review options:

1. On the Configuration tab, navigate to User Review > Options > SOD Review.

2. If Coordinator Review is required prior to sending workflow requests generated forReviewers, set the option Admin Review required before sending tasks to reviewers toYes; otherwise, set it to No.

3. Set the Who are the reviewers to Manager or Risk Owner.

Managers: Managers of users with SoDs are identified from LDAP or by SAP HRand the manager information (user ID and email address) appears on theworkflow task/request.


User Review

170 September 2008

Risk Owners: Risk owners must be defined in the Rule Architect section of RiskAnalysis and Remediation and assigned to each risk.

4. Define the appropriate SOD Review Users URI. This Web service retrieves User IDs.

http://<server>:<port>/VirsaCCSODViolatedUsersWS/ConfigVirsaCCSODViolatedUsers?wsdl&style=document

5. Define the appropriate SOD Review Users Risks URI. This Web service retrieves therisks associated to User IDs.

http://<server>:<port>/VirsaCCSODViolationsWS/configVirsaCCSODViolationsWS?wsdl&style=document

6. Define Number of lines items per Request.

This is the maximum number of lines (such as users, SoD violations, or user-roleassignments) permitted on a request. If more lines are required than this setting allows,the user must open another request for the remainder of the items. Therefore, a reviewermight receive one, several, or many requests, depending on how many users or SoDviolations they have to approve.

7. Select the Default Request Type.

The dropdown list includes any request types in the system that are configured as SoDReview workflow type.

8. Select the Default Priority for the request.

9. Click Save.

10. Schedule background jobs to perform the batch risk analysis and management reportupdates in Risk Analysis and Remediation.

11. Schedule background job in Compliant User Provisioning:

If you only want unmitigated conflicts to be sent for review, select Schedule SODReview Load Data without Mitigated Risks job.

If you want both mitigated and unmitigated risks to be sent for review, selectSchedule SOD Review Load Data with Mitigated Risks

12. Select Yes or No for Admin Review required before sending tasks to reviewers:

If you select Yes, the administrator can begin reviewing the tasks. When theAdmin Review is complete, run background job SOD Review Update Workflow torelease requests to reviewers.

If you select No, run the background job SOD Review Update Workflow torelease requests to reviewers.

You can schedule new background jobs to create workflow requests for manager orrisk owner review only after all previous SoD Review request are closed.

Use the Coordinator table to assign coordinators to reviewers. You can upload thistable in Configuration > User Review > Coordinators. Download the load template forreference.

Coordinators review the tasks/requests in Configuration > User Review > Request Review.You can review the requests and make modifications to the reviewer and coordinatorinformation updated if necessary. The administrator or coordinator can search for all requestsand/or requests with no reviewers or no coordinators assigned.


User Review

September 2008 171

SoD Workflow Example

You can configure a SoD workflow based on your organization’s requirements. In thisexample, the SoD workflow consists of normal path containing a single stage for reviewerapproval. It also contains a second path as a detour. This detour path has a single stage forsecurity approval. If the value is satisfied, a detour condition connects the two paths.

The procedure steps in this section highlight only the fields that are required forconfiguring a SoD workflow.

For detailed information on basic workflow configuration, see the section WorkflowManagement.

To configure a SoD workflow in Compliant User Provisioning, you must perform the following:

Define an Initiator

Define a Stage (one stage for Reviewer and another stage for Security)

Define a Path (one path for a Reviewer and another path for Security)

Define a Detour with condition

Defining an Initiator1. Go to the Configuration tab > Workflow > Initiator. The Initiators screen appears.

2. Click Create. The Create Initiator screen appears.

3. In the Name field, enter a name for your initiator. For example, enter ‘SOD Initiator’.

4. In the Short Description field, enter a brief description for this initiator.

5. In the Description field, enter a long description for this initiator.

6. In the Workflow Type dropdown menu, select SOD Review.

7. In the Condition dropdown menu, select a condition for the initiator.

8. In the Attribute dropdown menu, select SOD Review Risk.

9. In the Value field, enter the desired value. For example, enter Yes.

10. Click Add Attribute.

11. Click Save.

Defining the Stage1. Go to Configuration tab > Workflow > Stage. The Workflow Stages screen appears.

2. Click Create. The Stage Configuration screen appears.

3. In the Name field, enter a name for your stage. For example, enter ‘SODREVIEWER’.

4. In the Short Description field, enter a brief description for this stage.

5. In the Description field, enter a long description for this stage.


7. In the Approver Determinator dropdown menu, select Reviewer (for Managers).


User Review

172 September 2008

Compliant User Provisioning provides two out-of-the-box approvers: Reviewerand Security. Optionally, you can define a Custom Approver Determinator (CAD)for a custom approver.

8. Request Wait Time (Days) and Request Wait Time (Hours), enter the number of daysand hours you want to wait until triggering the escalation action. This is the number ofdays and hours that have elapse since the request first reached the approver’sinbox.

9. In the Escalation Configuration dropdown menu, select the type of action to performwhen a request wait time is triggered. Select one of the following options:

Forward to the next stage – The request is moved to the next stage withoutreviewer’s approval from the current stage.

Forward to the Administrator – The request sent to the administrator for approval.

Deactivate; Forward To Next Stage – All user accounts associated with risks aredeactivated and the validity date is set to today’s date. The request is then forwardedto the next stage.

Deactivate; Lock, Forward To Next Stage – All user accounts associated with risksare deactivated and locked. The validity date is set to today’s date, then the requestis forwarded to the next stage.

Forward to Alternative Approver – The request is forwarded to the specifiedalternative approver.

10. In the Notification Configuration pane, select the Reviewer for Approved condition.

11. In the Approved tab, enter a subject description in the Subject field. For example,enter ‘Next Approver: Please approve this request.’

12. In the Email Arguments dropdown menu, select the desired arguments. For example,select Request Number, Reviewer, and Stage.

13. In the Additional Configuration pane, select Yes in the Change Request Contentdropdown menu.

The Yes option enables the Approve and Remove buttons on the Review Form. If theNo option is set, then the Approve and Remove buttons are disabled.

14. In the Approval Type dropdown menu, select Only Remove Items.

There are two selection options for Approval Types:

Complete Request – The reviewer in this stage receives all items withapprove or removed items.

Only Remove Items – The reviewer in this stage receives only items with theRemove action. Generally, only Security is concerned with removed itemssuch as roles and functions. Security is required to take the appropriateactions.

15. Click Save.

Defining the Path for Reviewers1. Go to Configuration tab > Workflow > Path. The Workflow Paths screen appears.

2. Click Create. The Create Path screen appears.

3. In the Name field, enter a name for your path. For example, enter ‘SOD REVIEW’.

4. In the Short Description field, enter a brief description for this path.

5. In the Description field, enter a long description for this path.


User Review

September 2008 173

6. In the Workflow Type dropdown menu, select ‘SOD Review’.

7. In the Number of Stages field, enter 1.

8. In the Initiator dropdown menu, select the initiator name that you created previously.In this example, the initiator name is ‘SOD Initiator’.

9. Select Active.

10. Select Detour.

11. In the Path Definition For Path pane, select ‘SOD REVIEWER’ in the dropdown menufor Stage 1.

12. Click Save.

Defining the Detour Path for Security1. Go to Configuration tab > Workflow > Path. The Workflow Paths screen appears.


3. In the Name field, enter a name for your path. For example, enter ‘SOD SECURITY’.

4. In the Short Description field, enter a brief description for this path.

5. In the Description field, enter a long description for this path.

6. In the Workflow Type dropdown menu, select ‘SOD Review’.


8. In the Initiator dropdown menu, make sure there is no initiator in this field.

9. Select Active.

10. Select Detour.

11. In the Path Definition For Path pane, select ‘SODSECURITY’ in the dropdown menufor Stage 1.

12. Click Save.

Defining a Detour

1. Go to Configuration tab > Workflow > Detour/Fork. The Workflow Stage Detourscreen appears. The screen defaults to the Stage Detour tab.

2. Click Create. At the bottom of the table, the entry fields become active.


4. In the Path dropdown menu, select ‘SOD REVIEW’.

5. In the Stage dropdown menu, select ‘SOD REVIEWER’.

6. In the Action dropdown menu, select Save.

7. In the Condition dropdown menu, select Items With Remove Action.

8. In the Value dropdown menu, select Yes. The Yes option indicates that if thecondition is true, the request is detoured to the path defined for Security.

9. In the Detour Path dropdown menu, select ‘SOD SECURITY’.

Defining an Email Reminder

1. Go to Configuration tab > Workflow > Email Reminder. The Email Reminder screenappears.

2. In the Workflow Type dropdown menu, select, SOD Review.


User Review

174 September 2008

3. In the Days field, enter a number of days from the time that the request first wassubmitted to the approver’s inbox.

4. Click Save.

5. Click the Reminder tab.

6. In the Subject field, enter a reminder statement for the Reviewer.

7. In the Content field, you can configure the appears of the email body.

The email reminder can state that there are a number of requests pending on thereviewer’s approval.

8. In the Email Arguments dropdown menu, select the argument that identifies therequest.

9. In the Notification Configuration pane, click Reviewer.

10. Repeat the steps above for the Reminder for Coordinator tab. Make sure you selectCoordinator in the Notification Configuration pane.

11. Click Save.

Initiating User Access Reviews

Procedure

To configure user Review options in Compliant User Provisioning:

1. On the Configuration tab, navigate to User Review > Options > User Review pane.

2. If administrator review is required prior to sending workflow requests to Reviewers, thenin the Admin Review required before sending tasks to reviewers dropdown menu, selectYes. Otherwise, select No.

If you select Yes, Compliant User Provisioning points to the Enterprise RoleManagement database, retrieves the mapping information of users and roles,and stores the data in a temporary file. You must create a background job usingUAR Review Load Data as the Task Name (see step 9) which generates arequest for the administrator to review the tasks. The administrator reviews and,if necessary, modifies the mapping information of users and roles. When theAdmin Review is complete, you must run a background job using UAR ReviewUpdate Workflow as the Task Name to release requests to reviewers

For more information, see the section Background Jobs.

If you select No, you must run a background job using UAR Review UpdateWorkflow as the Task Name to release requests to reviewers.

3. Configure the Who are the Reviewers to be Manager or Role Owner.

Managers: Managers of users are identified from an LDAP or SAP HR system.The manager information (user ID and email address) is set in the workflowtask/request.

Role Approvers: Role approvers are defined at role level in Compliant UserProvisioning or Enterprise Role Management.

4. Define Number of lines items per Request. This is the maximum number of lines for userrole assignments permitted on a request. If more lines are required, then another requestis required for the remainder of the items. Therefore, one reviewer may receive one orseveral requests, depending on how many user-role assignments they have to approve.


User Review

September 2008 175

5. Select the Default Request Type. The dropdown list includes any request types in thesystem that has User Access Review workflow type.

6. Select the Default Priority of the request

7. Click Save to save the configuration

8. Schedule a Role Usage Synchronization to perform the user access review in theEnterprise Role Management capability.

For more information, see the section Role Usage Synchronization.

9. Schedule the background job in Compliant User Provisioning; UAR Review Load Data.

a. On the Configuration tab, navigate to Background Jobs. The Schedule Servicescreen appears.

b. In the Task Name dropdown menu, select UAR Review Load Data.

c. In the Description field, enter a brief description.

d. In the Schedule Type dropdown menu, select the time to schedule this job. Thecorresponding Task Occurrence or Recurrence pane appears.

e. Enter the Time and Start Date.

f. For Immediate schedule type, click Run. For other schedule types (On Date,Daily, Weekly, Monthly, Quarterly, Yearly, and Other), you can Activate theservice and/or Save the schedule.

After the Admin Review is complete, you must create a background job to release therequests to reviewers. Repeat step 9 using UAR Review Update Workflow as the TaskName.

You can schedule new background jobs to create workflow requests for manager orrisk owner review only after all previous SoD Review request are closed.

Coordinators review the tasks/requests in Configuration > User Review > Request Review.You can review the requests and make modifications to the Reviewer and Coordinatorinformation updated if necessary. The administrator or coordinator can search for all requestsand/or requests with no reviewers or no coordinators assigned.

Coordinator

Procedure

To specify coordinator review options:

1. On the Configuration tab, navigate to User Review > Coordinator.

The Coordinator screen appears.

Review of all SoD or User Access violations is coordinated. The coordinator isoptional; it is possible to perform the review without a coordinator. In addition, onecoordinator might have many reviewers.

2. Use this screen to search for the coordinator and reviewer by user ID or by first and lastnames.

3. After identifying all coordinator /reviewer names, you can do another search on theresulting screen to determine whether the selected coordinator/reviewer pair is set toreview SoD risks or user access violations. You can create, change, delete, and exportmapping information for coordinator/reviewer names.


User Review

176 September 2008

4. If necessary, you can download a template for creating mapping information ofcoordinator/reviewer names by clicking Download Template. Afterwards, you can importthis file.

Request Review

Use this feature to search for any outstanding requests that are pending for either SoD orUser Access Review by the reviewers. You can either assign those requests to any newreviewers or cancel those requests.

1. On the Configuration tab, navigate to User Review > Request Review.

The Request Review screen appears.

2. From the Workflow Type dropdown list, select a workflow for the approval process.

3. From the Request Type dropdown list, select the type of request you want to initiate.

The options on this list are associated with workflow type.

4. In the Reviewer ID field, enter the reviewer’s user ID, or select the reviewer’s user ID bysearching for it.

You can opt not to have a reviewer at all by selecting the No Reviewer checkbox.

5. In the User ID field, enter the reviewer’s user ID, or select the reviewer’s user ID bysearching for it.

6. In the Coordinator ID field, enter the coordinator’s user ID, or select the coordinator’suser ID by searching for it.

You can opt not to have a coordinator at all by selecting the No Coordinator checkbox.

7. From the Date From and Date To fields, select the period for which you want to searchthe requests.

You can select any row and change the assigned reviewer or coordinator to any newreviewer or coordinator.

8. Selects a row. Then click Change.

The system displays the current coordinators and reviewers, and you can enter newvalues.

You can cancel any outstanding request by selecting the row and clicking Cancel.

UAR Workflow Example

You can configure an UAR workflow based on your organization’s requirements. In thisexample, the UAR workflow consists of normal path for reviewers containing a single stagefor reviewer approval. It also contains a second path as a detour. This detour path has asingle stage for security approval. A detour condition connects the two paths if the value issatisfied.

The procedure steps in this section highlight only the fields that are required forconfiguring the UAR workflow.

For more information, see section Workflow Management.

To configure a User Access Review workflow in Compliant User Provisioning, perform thefollowing:


User Review

September 2008 177

Define an Initiator

Define a Stage (one stage for Reviewer and another stage for Security)

Define a Path (one path for a Reviewer and another path for Security)

Define a Detour with condition

Defining an Initiator

1. Go to the Configuration tab > Workflow > Initiator. The Initiators screen appears.

2. Click Create. The Create Initiator screen appears.

3. In the Name field, enter a name for your initiator. For example, enter ‘UAR Initiator’.

4. In the Short Description field, enter a brief description for this initiator.

5. In the Description field, enter a long description for this initiator.

6. In the Workflow Type dropdown menu, select User Access Review.

7. In the Condition dropdown menu, select a condition for the initiator.

8. In the Attribute dropdown menu, select UAR Review Role.

9. In the Value field, enter the desired value.


11. Click Save.

Defining the Stage1. Go to Configuration tab > Workflow > Stage. The Workflow Stages screen appears.

2. Click Create. The Stage Configuration screen appears.

3. In the Name field, enter a name for your stage. For example, enter ‘UARREVIEWER’.




7. In the Approver Determinator dropdown menu, select Reviewer (for Managers orRole Approver).

Compliant User Provisioning provides two out-of-the-box approvers: Reviewerand Security. Optionally, you can define a Custom Approver Determinator (CAD)for a custom approver.

8. Request Wait Time (Days) and Request Wait Time (Hours), enter the number of daysand hours you want to wait until triggering the escalation action. This is the number ofdays and hours that have elapse since the request first reached the approver’sinbox.

9. In the Escalation Configuration dropdown menu, select the type of action to performwhen a request wait time is triggered. Select one of the following options:

Forward to the next stage – The request is moved to the next stage withoutreviewer’s approval from the current stage.

Forward to the Administrator – The request sent to the administrator for approval.

Deactivate; Forward To Next Stage – All user accounts associated user roleassignments are deactivated and the validity date is set to today’s date. The requestis then forwarded to the next stage.


User Review

178 September 2008

Deactivate; Lock, Forward To Next Stage – All user accounts associated user roleassignments are deactivated and locked. The validity date is set to today’s date, thenthe request is forwarded to the next stage.

Forward to Alternative Approver – The request is forwarded to the specifiedalternative approver.

10. In the Notification Configuration pane, select the Reviewer for Approved condition.

11. In the Approved tab, enter a subject description in the Subject field. For example,enter ‘Next Approver: Please approve this request.’

12. In the Email Arguments dropdown menu, select the desired arguments. For example,select Request Number, Reviewer, and Stage.

13. In the Additional Configuration pane, select Yes in the Change Request Contentdropdown menu.

The Yes option enables the Approve and Remove buttons on the Review Form. If theNo option is set, then the Approve and Remove buttons are disabled.

14. In the Approval Type dropdown menu, select Only Remove Items.

There are two selection options for Approval Types:

Complete Request – The reviewer in this stage receives all items withapprove or removed items.

Only Remove Items – The reviewer in this stage receives only items with theRemove action. Generally, only Security is concerned with removed itemssuch as roles and functions. Security is required to take the appropriateactions.

15. Click Save.

Defining the Path for Reviewers1. Go to Configuration tab > Workflow > Path. The Workflow Paths screen appears.


3. In the Name field, enter a name for your path. For example, enter ‘UAR REVIEW’.

4. In the Short Description field, enter a brief description of the stage.

5. In the Description field, enter a long description of the stage.



8. In the Initiator dropdown menu, select the initiator name that you previously created.In this example, the initiator name is ‘UAR Initiator’.

9. Select Active.

10. Select Detour.

11. Click Save.

Defining the Detour Path for Security1. Go to Configuration tab > Workflow > Path. The Workflow Paths screen appears.


3. In the Name field, enter a name for your path. For example, enter ‘UAR SECURITY’.



User Review

September 2008 179




8. In the Initiator dropdown menu, make sure there is no initiator in this field.

9. Select Active.

10. Select Detour.

11. In the Path Definition For Path pane, select ‘SECURITY’ in the dropdown menu forStage 1.

12. Click Save.

Defining a Detour

1. Go to Configuration tab > Workflow > Detour/Fork. The Workflow Stage Detourscreen appears. The screen defaults to the Stage Detour tab.

2. Click Create. At the bottom of the table, the entry fields become active.

3. In the Workflow Type dropdown menu, select ‘User Access Review’.

4. In the Path dropdown menu, select ‘UAR REVIEW’.

5. In the Stage dropdown menu, select ‘UAR REVIEWER’.

6. In the Action dropdown menu, select Save.

7. In the Condition dropdown menu, select Items With Remove Action.

8. In the Value dropdown menu, select Yes. The Yes option indicates that if thecondition is true then the request is detoured to the path defined for Security.

9. In the Detour Path dropdown menu, select ‘UARSECURITY’.

Defining an Email Reminder

1. Go to Configuration tab > Workflow > Email Reminder. The Email Reminder screenappears.

2. In the Workflow Type dropdown menu, select, User Access Review.

3. In the Days field, enter a number of days from the time that the request first wassubmitted to the approver’s inbox.

4. Click Save.

5. Click the Reminder tab.

6. In the Subject field, enter a reminder statement for the Reviewer.

7. In the Content field, you can configure the appears of the email body.

The email reminder can state that there are a number of requests pending on thereviewer’s approval.

8. In the Email Arguments dropdown menu, select the argument that identifies therequest.

9. In the Notification Configuration pane, click Reviewer.

10. Repeat the steps above for the Reminder for Coordinator tab. Make sure you selectCoordinator in the Notification Configuration pane.

11. Click Save.


Change Log

180 September 2008

Change LogOn the Configuration tab, you can configure a change log to capture any changes usersmake to configuration parameters. When a user performs configuration actions, the systemlogs 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 theobject.Example: QF8600 is a system name.

Action This is the type of action performed for the ObjectName.Example: New.

Changed by This is the person responsible for making thechange.Example: BLAW

Change Log Time This is the date and time that the change wasmade.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 fieldname.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 asyou want.

3. Click Save.

Search Change Log

Use the Search Change Log feature to search the log information in the database forconfiguration changes.

You can specify any of the following criteria to filter your search:


Roles

September 2008 181

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. Forexample, if you select Role for Object Name, you can specify the name of the role as itsvalue.

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 specificfield name to further refine the search.

Field Value: Based on the specified field name, you can specify a field value to fine tunethe search.

Change Date From and Change Date To: Specify the range of dates when configurationchanges you want to find were made.

Maximum Number of Hits: Specify the number of configuration log records to display inthe search results to narrow the search criteria.

RolesThe Roles option configures roles. A role is fundamental to users for accessing information. Arole can be specific to an individual user or a group of users. The role description must matchthe specific tasks for accessing information or application systems. The Roles option providesthe 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


Question Answer

What happens if a role has not beenimported/added to Compliant UserProvisioning? Can a requestor stillselect that role and add it to a request?

No. You must import the role first.


Roles

182 September 2008

Question Answer

Can a role be deleted from a user afterit is assigned?

Compliant User Provisioning can delete roles fromusers within a workflow that has a request typeconfigured with a Change User action. But, evenwith a deleted role, you must import/add the role toCompliant User Provisioning prior to selecting it fordeletion.

If a role is updated (for example, atransaction code is added), does therole need to be re-imported?

No. Compliant User Provisioning does not importrole details other than names and descriptions. Ifrequired, transaction code information is obtainedfrom the SAP system and is therefore always insync.

If I delete a role in the SAP system, do Ihave to import it again to synchronizeCompliant User Provisioning with SAP?

No. If you delete a role in the SAP system and thenimport roles into Compliant User Provisioning, therole reference remains in Compliant UserProvisioning. You must delete the role manuallyfrom Compliant User Provisioning.

Import Roles

Compliant User Provisioning provides several methods to load roles. One method is to importthe roles from an SAP business system. Another method is to import roles from aspreadsheet file.

You use Enterprise Role Management to build roles. These roles can be pushed toeach Access Control capability through a synchronization mechanism. For moreinformation about role synchronization, see the section Configuration for RoleSynchronization Integration with Enterprise Role Management. For import of non-SAProles, these roles are transferred to Compliant User Provisioning using the RoleImport file (a spreadsheet).

Be selective when importing roles. Take into consideration which roles you need. Forexample, if you do not want anyone to request SAP_ALL in the production client, do not loadit into the production client.

Load only the roles that you need. Importing a large number of roles can result in along list to scroll through when you must select one. In addition, deleting roles can betime consuming when thousands of roles are in one system.

Importing Roles

Procedure

Compliant User Provisioning provides several methods for loading roles. One method is toimport the roles from an SAP business system. Another method is to import roles from aspreadsheet file.

To import roles:

1. On the Configuration tab, navigate to Roles > Import Roles.

The Import Roles screen appears.


Roles

September 2008 183

2. From the System dropdown list, select the system that contains the roles you want toimport.

3. From the Role Source dropdown list, select either the SAP back end or Enterprise RoleManagement.

4. In the Last Sync Date field, select a date.

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

Use caution when importing roles. You might not need toimport all roles from the back-end system into CompliantUser Provisioning. The only roles you need to import arethe roles you want requestors to select for provisioning.

All Roles Except SAPPredefined Roles

Imports all roles except any predefined roles in the specifiedSAP system.

Selected Roles Imports individual roles. in this case, you must know the namesof the roles you want to import. Enter the roles one at a time inthe Role Name field, or use a wildcard option (an asterisk - *) tospecify a number of similarly named roles.

From File Use this setting to load roles from a spreadsheet file. This filecan be on your local host or on another system. Use Browse tonavigate to the file.

In your development system, where you create roles to transport, there might be rolesused 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 yourproduction 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 newroles to the system, select Overwrite Existing Roles.

This option does not affect any roles that are not listed in the spreadsheet or included inthe import.

7. Click Import.

The following message appears:

Import Status: xx successfully imported from yy records found.

Where xx is the number of roles successfully imported from the records found.

Configuration for Role Synchronization Integration with Enterprise Role Management

The integration of Compliant User Provisioning with Enterprise Role Management enablesrole synchronization. Enterprise Role Management is set as the system for role resource.


Roles

184 September 2008

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.

6. Click Import.

Role Import/Export Template Details

Downloading the Role Import Template

Procedure

To import roles, you can download a spreadsheet template to your local system. Afterdownloading the spreadsheet, populate the fields with your own roles, and then import theinformation.

Recommendation

SAP recommends that you edit the downloaded template with your additional roles. Use thedata format of the values represented in the dummy role. However, you must delete thedummy role in the template before using it. Do not modify the sheet name and headernames.

Business process, subprocess, functional area, company, and system must exist inCompliant User Provisioning before the roles can be successfully uploaded. If they do notexist, 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.

For more information, see the section Role Import/Export Template Details.

3. Save and close the template with the new information.

Now you can import the role information. For more information, see the section ImportingRoles.


Roles

September 2008 185

Role Import/Export Template Details

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

Role Import Template Spreadsheet

Role Import Column Description MandatoryCase-Sensitive

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

Yes Yes –upper caseletters

RoleName Technical name of the role. Yes Yes

Type Select Single or Composite. Only one valueis allowed.

Yes No

Last Reaffirm Date Date of the role’s last reaffirm. Requiredformat is MM/DD/YY.

Yes MM/DD/YY

System Technical name of the system in which therole resides. The system must exist as aconnector. List as many systems as youwant, separated by commas.

Yes, atleast onesystem isrequired

Yes, uppercaseletters

RoleApprover User ID of the role’s approvers. Several roleapprovers can be included, separated bycommas. Alternate approvers follow theapprover and are separated by a pipesymbol (|). Lead Approver designationfollows the alternate approver separated bya pipe symbol (|).

Format:

Roleappr|alternative|Y,roleapprover|alternate

Example:

WONG|BLAW|Y,CPERKINS MWONG isthe role approver, BLAW is MWONGsalternate approver and MWONG is theLead Approver. CPERKINS is the secondrole approver, no alternate and is not thelead approver.

No No

Functional Area Functional area of the role. This is thetechnical name of the functional area, and itmust expire in the system before the role isuploaded successfully. Several functionalareas are permitted, separated by commas.

Yes – atleast onefunctionalarea isrequired

Yes

Company Company associated with the role. This isthe technical name of the company, and itmust expire in the system before the role isuploaded successfully. Several companiesare permitted, separated by commas

Yes – atleast oneCompany isrequired

Yes

RoleProfileIndicator Options are either Role or Profile. Yes No


Roles

186 September 2008



Responsibilityid This field is no longer used but it remains inthe template for backward compatibility. It isa number used to represent theresponsibility ID.

Enter zero if not using this functionality.

Yes – use azero if notusing thisfunctionality

N/A

CommentsMandatory

Options are Yes or No. Yes Yes – useupper caseletters Yesor mixedYes.

ParentRoleOwner This field is no longer used as part ofCompliant User Provisioning but it remainsin the template for backward compatibility.

Options are Yes or No. Select No, if notusing this functionality.

YesChoose Noif not usingthisfunctionality

No

Description_de German short description. Required only ifyour users want to use Access Control inGerman.

No No

DetailDescription_de German detailed description. Required onlyif your users want to use Access Control inGerman.

No No

Description_hu Hungarian short description. Required only ifyour users want to use Access Control inHungarian.

No No

DetailDescription_hu Hungarian detailed description. Requiredonly if your users want to use AccessControl in Hungarian.

No No

Description_ja Japanese short description. Required only ifyour users want to use Access Control inJapanese.

No No

DetailDescription_ja Japanese detailed description. Requiredonly if your users want to use AccessControl in Japanese.

No No

Description_it Italian short description. Required only ifyour users want to use Access Control inItalian.

No No

DetailDescription_it Italian detailed description. Required only ifyour users want to use Access Control inItalian.

No No


Roles

September 2008 187



Description_ es Spanish short description. Required only ifyour users want to use Access Control inSpanish.

No No

DetailDescription_es Spanish detailed description. Required onlyif your users want to use Access Control inSpanish.

No No

Description_pt Portuguese short description. Required onlyif your users want to use Access Control inPortuguese.

No No

DetailDescription_pt Portuguese detailed description. Requiredonly if your users want to use AccessControl in Portuguese.

No No

Description_en English short description. Required only ifyour users want to use Access Control inEnglish.

No No

DetailDescription_en English detailed description. Required only ifyour users want to use Access Control inEnglish.

No No

Description_fr French short description. Required only ifyour users want to use Access Control inFrench.

No No

DetailDescription_fr French detailed description. Required only ifyour users want to use Access Control inFrench.

No No

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

Yes Yes – useupper caseletters

Subprocess The technical name of the subprocess,which must exist in the system and beassigned to the business process listed inthe Business Process column on thisspreadsheet before the role is uploadedsuccessfully. Only one subprocess isallowed per role.

Yes Yes, useupper caseletters

CriticalLevel Options are Critical, High, Medium, and Low. Yes No,suggestusingmixedcaseletters asdisplayedin thedescriptioncolumn


Roles

188 September 2008



ReaffirmPeriod The number of months that a role needs tobe reaffirmed. For example, enter a reaffirmperiod of one year or 12 months as 12.

Yes N/A –enter anumber

Custom Attributes(Custom Fields forthe Role)

This column contains all custom roleattributes for the role.

No N/A

Verification TrainingSystem

This column contains all system name foryour verification/training system.

No Yes, useupper caseletters

Changing Existing Roles with the Export/Import Spreadsheet

You can make mass changes to roles using a spreadsheet. Use the Search Role functionalityto export the selected roles and create a spreadsheet with the existing roles and their roleattributes. You can then change these attributes on the spreadsheet and import them backinto the system using the Overwrite Existing Role option.

Role Creation

The Create Role option creates a role within Compliant User Provisioning.

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 RoleAttributes screen. To access the Role Attributes screen, on the Configuration tab, navigateto 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.

5. From the Role/Profile dropdown list, select Role or Profile for the new role.


Roles

September 2008 189

When the role is displayed throughout Compliant User Provisioning, the standard SAPicon appears for roles and profiles.

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 itremains 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 newrole applies.

9. From the Subprocess dropdown list, select the sub-business process to which the newrole 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. Formore information, see the section Reaffirm Role.

The Due field displays the date of the next reaffirmation. This display field is calculatedbased on the date of the last reaffirmation and the number of months specified for thereaffirm period.

12. From the Comments Mandatory dropdown list, select Yes or No. If Yes, select the checkbox for Allow Role Comments on Roles > Role Selection to make comments availablewhen 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 inthe template for backward compatibility. Select No, if you do not want to use thisfunctionality.

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

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 autoprovisioning when selected by a user.


Roles

190 September 2008

Disable – roles that are disabled and are not displayed when the enduser uses the Search feature to query for 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 approverdeterminator is configured for escalation to alternative approvers. If escalation is notconfigured for escalation to alternative approvers, there is no need to add alternativeapprovers.

17. On the Functional Area tab, click the icon to add a functional area to associate withthis 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 menufor 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 therequest 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 filteryour query for role name, role description, system, business process, subprocess, functionalarea, and role owner. After you receive the search results, you can change or delete roles, orexport the search results from spreadsheet format.

The export feature is not available in Compliant User Provisioning, if you are usingEnterprise Role Management to create and maintain roles.

In addition, from the Roles Information screen's Search Results, you can begin the rolecreation process, if the role you are looking for does not exist.

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


Roles

September 2008 191

Field Description

Role Name Enter the role name you want to find.

Enter the role name in upper case.RoleDescription

Enter the role description you want to find.

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

BusinessProcess

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

Subprocess Enter the business subprocess associated with the role you want tofind.

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. Thisoption make changes to the role information and then imports the file back into CompliantUser 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 onyour computer where you want to save the file.

Role Selection

The Role Selection option narrows the scope of the search results for roles to a particularsubset. This option is useful when you have a large number of roles to search. To optimizethe 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 andaccess 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 aspart of a request, the search is actually querying Compliant User Provisioning, notSAP. There are several role attributes used as search criteria that are not stored inSAP.


Roles

192 September 2008

Configuring Role Selection

Procedure

To configure role selection:

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 thatsearching 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 mindthat searching a large set of roles can be time-consuming.

Restrict Role Selection — This allows access requestors to search for a specificattribute. Use the dropdown list to select the allowed attribute.

Allow Users to Select Roles — Check this box to allow users to select their ownroles.

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 entercomments. You can also make comments required by selecting the appropriatecheckbox.

6. In the Roles With No Approvers group, you can enable the Auto Approve Roles WithoutApprovers to approve roles with no defined approvers.

When you enable the Approve Roles Without Approvers flag, it is applicable at any stagewhere the approval level is set to Role.

Generally, you set the approval level to Role for those stages where the role is theapprover determinator or when the stage is associated with Custom ApproverDeterminator (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 areno role owner defined in any of the roles of the request, then the request gives the errormessage, Approver not found . This exception is displayed in the previous stage whenthe approver approves the request.

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

To avoid the Approver not found error message, configure an escape route or, if thestage has a Role as the approver determinator, use one of the detailed conditions (NoRole Owners or Roles with No Role Owner).

For more information, see the section Detour Paths.


Roles

September 2008 193

7. Click Save.

Default Roles Configuration

The Default Roles option configures a role for certain conditions. You configure default rolesto be added to an access request depending on the attributes selected by the requestor. Inaddition, you can allow users to add default roles, add roles for the attributes you assign, anddetermine 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 ofthe User Attributes field.

In addition to configuring default roles, you can import default roles from another system anddownload a template that you can use to populate with your own default roles. Then you canimport them into Compliant User Provisioning. To do so, import a spreadsheet file containingroles 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 forimporting default roles. After downloading the spreadsheet, populate the fields with your owndefault roles, and then import the information into Compliant User Provisioning.

ExampleAn example of using default roles is having an access request match therequirements that you configured using the Default Role Configuration screen, whereyou associate the company attribute with a role as a default. In this case, you setcompany name, ‘SAP’ with the role, ‘Z_AP_Payable’. When a stage is set up toprovision a role but only the company attribute is used in the request, the default roleis 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.

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


Roles

194 September 2008

12. Click Save.

Importing Default Roles from an External System

Procedure

Besides creating default roles from scratch, you can import a spreadsheet file containingroles 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 andselect 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 defaultroles into Compliance User Provisioning. After downloading the spreadsheet, populate thefields 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.

RecommendationSAP recommends that you edit the downloaded template with your additional roles.Do not modify the sheet name and header names. When importing default roles, useupper 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 Systemto import this information to Compliant User Provisioning.

For Superuser Access, use the Super User Access request type and configure thefirefighter role as the default role.

Role Mapping Option

The Role Mapping option assigns roles to specific systems depending on the selected role inthe request. Role mapping makes it easier for requestors when specifying a role on aparticular SAP back-end system. They are automatically granted a role when they specify acertain SAP system.

ExampleOne 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


Roles

September 2008 195

encompass many tasks or a single job, where one role is associated with a specificjob.

Mapping a Role to a System

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 defineby 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 forthat 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 SearchResults area.

7. Select a role name and click Add.

The Role Mapping screen appears. The role name that you added now appears in theRole Selected by User field.

After you finish adding main roles to the system, you can associate the main role withdependent 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 Systemdropdown 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 thelist below the main role.

Importing Role Mapping

Procedure

You can import files that already contain mapped roles. The files must be in spreadsheetformat. In addition, Compliant User Provisioning provides a spreadsheet template that mapsmultiple 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 andselect 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.


Roles

196 September 2008

Downloading the Role Mapping Template

Procedure

To download the role mapping 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.

RecommendationSAP strongly recommends that you edit the downloaded template with your own rolemapping information. Do not modify the sheet name and header names. Whenimporting role mapping, use upper case for the main role name and dependent rolename 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.

Enable and Remove Role Mappings

After you create mapped roles, you can configure role mapping to be enabled or disabled forthe system and whether role maps apply to removals.

Role removal relates to whether the role mappings function in reverse. Enabling this optionmeans that when the main role is added to the request to be removed from a user, themapped roles are also added to the request to be removed from the user. These are thesame 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 affectingthe 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 therequestor find the desired roles, as well as to facilitate the workflow functionality. When therole attributes are assigned to the roles, they help the user select the roles when creating therequest by filtering on these attributes.


Roles

September 2008 197

For example, if a user wants a finance role and all the finance roles have been assigned tothe Finance functional area, the requestor can display roles by selecting the functional areaFinance. In addition, if the user selects functional area Finance on the request header, bydefault, 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 alsodefine 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.

FunctionalArea

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.

Administration

Sales and Distribution

Marketing

Production

R & D

ApplicationArea

Suggested definition: The system that contains the application.

Application area is the top of the hierarchy for business process andsubprocess. Application area is not required. Application area is definedonly at the role level.

BusinessProcess

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

Business process is required at the role level.

BusinessSubprocess

Suggested definition: A subprocess of the actual work, such as auditing.

Subprocess is required at the role level and is a subprocess associated witha particular business process. Every subprocess can be assigned to onlyone business process.


Roles

198 September 2008

Predefined Attributes

Attributes Description

FunctionalArea andCompany

The name of the approver for the organization for the combination offunctional area and company. Set the owner/role for the workflow stages inyour approval path. This attribute is required only if one of your stages usesthis option as an approver determinator. For more information, see thesection Defining a Stage.

The definitions of these predefined attributes are suggestions and can be defineddifferently for your company’s requirements. For example, Functional Area might bedefined 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 thedropdown lists whenever you go to the Access Request entry screens or the Select Rolesscreen, depending on whether the attribute can be defined at the request and role level oronly the role level. On the Select Role screen, these attributes help the requestor to find theroles 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.

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


Roles

September 2008 199

Configuring Functional Area

Procedure

To configure a functional area:



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.


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

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.

4. Click Save.

Configuring an Application Area

Procedure



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.


Roles

200 September 2008

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:


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 configuremultiple application area attributes and then import into Compliant User Provisioning.

To download the application area attributes template:


2. Click Save.

Be sure to save the template in a location where you can find it later.


4. Enter values for Application Area, Short Description, Description, and System.

RecommendationIt is recommended that you edit the downloaded template with your own applicationarea attributes. Do not modify the sheet name or header names. Areas are availablefor a short description and long description in the following languages:

en = Englishes = Spanishde = Germanfr = Frenchpt = Portugueseja = Japanese


5. Click Save.

After using the template to add application area attributes, you can define the directory pathto this file, and then import the file using the instructions in the section Importing ApplicationArea Attributes.


Roles

September 2008 201

Changing an Application Area

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


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.

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


Roles

202 September 2008


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 canuse to configure multiple business process attributes and then import back into CompliantUser Provisioning.

To download the business process attributes template:

1. Click Download Template and then click Save to save the XLS template file to yoursystem.

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, AlternateApprover, Application Area, Short Description, and Long Description.

RecommendationIt is highly recommended that you edit the downloaded template with your ownbusiness 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 thefollowing languages:

en = Englishes = Spanishde = Germanfr = Frenchpt = Portugueseja = Japanese


Save this file to your local system, where it is stored. After using the template to addapplication area attributes, you can define the directory path to this file, and then import thefile 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 ApplicationArea fields become active. Make any edits.

3. Click Save.


Roles

September 2008 203

Configuring a Business Subprocess

Procedure


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 adropdown 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 listbecome active. Make any edits.

3. Click Save.

Configuring the Functional Area and Company Attribute

Procedure

To configure the functional area and company attribute:


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

4. In the Functional Area column, click the dropdown list to select the desired functionalarea.

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 FunctionalArea and Company screen, where you can query for approvers.


Roles

204 September 2008

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 ofapprovers, you must select a lead approver by clicking the option button at the end ofthe appropriate row. Lead approvers are also indicated by the Hat icon at thebeginning 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 andcompany attributes. The files must be in spreadsheet format (.xls).

To import functional area and company attributes:


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 canuse to configure multiple functional area and company attributes and then import them intoCompliant User Provisioning.

To download the functional area and company attributes template:


2. Click Save.

Be sure to save the template in a location where it is easy for you to find later.


4. Enter values for Functional Area, Company ID, Approver ID, Alternate Approver ID, andIS Lead.

RecommendationIt is highly recommended that you edit the downloaded template with your ownbusiness 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 thefollowing languages:

en = Englishes = Spanishde = Germanfr = French


Role Reaffirmation

September 2008 205

pt = Portugueseja = Japanese


5. Click Save.

After using the template to add application area attributes, you can define the directory pathto this file and then import the file using the instructions in the section Importing FunctionalArea 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 todelete by clicking anywhere in that row, outside any of the active fields.

2. Click the icon to delete the selected functional area.

Role ReaffirmationCompliant User Provisioning allows you to an send automatic email reminders to any roleapprover responsible for reaffirming a role. Use the Reaffirm Role option to configure thenumber 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 withthe exception of Role Reaffirmation entails configuring the reaffirm date on roles..

For more information on configuring role reaffirmation, see Access Control 5.3 ApplicationHelp.

You must schedule and run the Email Reminders background job to determine which rolesare due for reaffirmation and send the email reminders to the role approvers.

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


Background Jobs

206 September 2008

3. In the Number of days prior to Reaffirm due date (to send email reminder) field, enter thenumber 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 daysprior to the reaffirmation date set for each role.

4. Click Save.

Remember to schedule and run the Email Reminders background job to analyze rolesfor reaffirmation and send the email notifications.

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 andbased on the period, the due date is automatically calculated. You can later modifythis setting, if required.

For more information on configuring role reaffirmation, see the section, Role Creationin this guide.

Background JobsThe Background Jobs option runs jobs against the data in Compliant User Provisioning. Youcan also configure it to take new actions.

Example

If there are changes to a new request or modifications in the approval stage in which anaccess request is currently being processed, you can run a background job.

Setting Up Background Jobs

Procedure

To set up a background job:

1. On the Configuration tab, navigate to Background Jobs.

The Schedule Service screen appears.

2. From the Task Name dropdown list, select the desired task.

The screen displays the configuration group for that particular task name.

3. In the Description field, enter the description of the task.

4. In the Schedule Type field, click the dropdown list to select the job frequency.

The appropriate Task Occurrence group appears.

5. In the Start Date field, select the Calendar icon to enter the time for the scheduled job torun.

6. Click Save.

7. Click View Schedule to review the scheduled job.


User Default Management

September 2008 207

User Default ManagementManaging user defaults allows you to link data fields that are automatically set for newlycreated users. After you configure user defaults, the data is transferred to the SAP back-endsystem as defaults.

The User Defaults option assigns the following values:

User Defaults Option Assignments

Assignment Description

Selecting aUser DefaultSystem

You must select an SAP back-end system to act as the default systemwhere you can get the user defaults. The list of SAP systems in thedropdown list is based on the active SAP connections on the Connectorsscreen. For more information, see the section Selecting a User DefaultSystem.

You must select a user default system before you create userdefaults.

ConfiguringUser Defaults

Use this option to assign user defaults in the SAP back-end system fornew users. For more information, see the sections Configuring UserDefaults and Changing User Defaults.

You must select a user default system before you create userdefaults. For more information, see the section Selecting a UserDefault System.

Setting UserDefaultMapping

Use this option to create, change, or activate/deactivate the user default.For more information, see the sections Setting User Default Mapping andDeleting 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 beapplied.

You can apply multiple systems to the user default.

5. In the Short Description field, enter a short description of the default.


6. In the Description field, enter a description of the default.


User Default Management

208 September 2008

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

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

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

15. In the Parameter ID (PID) Details group, click the icon to add a parameter and itsvalue.

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 conditionsand values) so that when a submitted request meets the specified settings, the request isautomatically assigned the user defaults. For instance, you map the user default to have theattributes, Request Type=New and Functional Area=Finance . Any request having these twoattributes 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.


5. In the Description field, enter the description of the default mapping.

6. From the User Defaults dropdown list, select a user default.

The User Defaults in the dropdown list are created using the User Default option. Formore information on creating these, see the section Configuring User Defaults.


Attachments

September 2008 209

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

9. From the Condition dropdown list, select a logical operator.


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

2. Click Delete.

AttachmentsThe Attachments feature adds attachments at the request level. Attachments are not storedin Compliant User Provisioning due the amount of disk space they require. You mustdesignate a network folder to store all attachments.


System Log Monitoring

210 September 2008

Provide Folder For Request Attachments: By entering the folder in this field you are enablingthe attachment feature. Leaving this field blank disables the Attachment feature and prohibitsrequestors from attaching external documents to the requests.

System Log MonitoringThe Monitoring option allows you to view the system log and see what applications areprovisioned in Compliant User Provisioning.


System Log Monitoring

September 2008 211

The Monitoring option provides access to the following logs:

System Log Monitoring Access

LogMonitored Description

System Log Use the System Log option to view the current log file. The system log containssuch information as errors, sequence of operation, transaction flow, andexception reports. For more information, see the section Viewing the SystemLog.

ApplicationLog

Use the Application Log option to view a user’s access history to applicationswith that user’s provisioning actions in Compliant User Provisioning. Theapplication log displays the following types of actions:

USER CREATE – Action that indicates that a user was created in SAP byan 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.

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.


HR Trigger Configuration

212 September 2008

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 ConfigurationThe HR Triggers option creates rules in the SAP HR system and associates Compliant UserProvisioning actions to those rules. When an event is triggered in the SAP HR system, suchas the hiring of a new employee or an employee termination, rules are applied along withtheir corresponding HR Triggers. The system then performs an action in the form of arequest.

The HR Triggers option provides four tools to create and manage rules for HR Triggers:

HR Trigger Configuration Tools

Tool Description

Actions This option creates actions. HR Triggers are associated with the following actiontypes:

New (this can be a new hire)

Lock

Unlock

Delete

Change

Assign Roles

Superuser Access

User Defaults

The actions correspond to the standard request types. You can also use customactions that were created using the Create Request Type screen. For moreinformation on creating actions for HR Triggers, see the Creating an Actionsection in this guide.

For more information, see the section Creating an Action.

Rules This option creates HR rules that are stored in the SAP HR system.

For more information, see the sections Creating a Rule or Changing or Deleting aRule.

FieldMapping

This option maps fields to corresponding fields in the SAP HR system.

For more information, see the section Mapping Fields Using the SAP HRSystem.



September 2008 213

HR Trigger Configuration Tools

Tool Description

ProcessLog

This option allows you to view all of the processes that are associated with HRTriggers.

To view the Process Log, navigate to HR Trigger > Process Log on theConfiguration tab. The Process Log screen appears.

The approvers you define using this option appear throughout Compliant User Provisioningas part of the approval or workflow process.

To use the HR Triggers option, configure the background daemons as a scheduledjob. For more information, see the section Background Job Set Up.

RecommendationSAP recommends that you set the HR Trigger Load Data job to 60 seconds. The HRTrigger Load Data background daemon retrieves HR data resulting from triggerrules/actions. Set the HR Triggers job to 80 seconds. The HR Trigger backgrounddaemon schedules the HR Trigger rules to perform the actions in the request.

Creating Actions

Procedure

To create an action:

1. On the Configuration tab, navigate to HR Triggers > Actions.

The Actions screen appears.

2. Click Create.

The Actions Details screen appears.

3. In the Action ID field, enter a name for the action.

4. In the Short Description field, enter a short description of the action.


5. In the Description field, enter a description for the action.

6. From the Type dropdown list, select an action type.

7. From the Priority dropdown list, select a priority for the action.

This priority can be High or Low.

8. Select the System tab.

The System screen appears.

9. Click the icon to add a new system.

Repeat this step, as necessary, to add more systems to the action.

10. From the System dropdown list, select the SAP system you want to associate with theaction.



214 September 2008

11. In the Valid From field, click the calendar icon to select a valid start date.

12. In the Valid To field, click the calendar icon to select a valid end date.

13. Click the Address tab.

The Address screen appears.

14. From the Name dropdown list, select Yes or No to indicate whether you want the username to be updated in all corresponding SAP systems specified on the Systems tab.

15. From the Email dropdown list, select Yes or No to indicate whether you want the emailaddress to be updated in all corresponding SAP systems specified on the Systems tab.

16. From the Telephone dropdown list, select Yes or No to indicate whether you want theuser’s telephone number to be updated in all corresponding SAP systems specified onthe Systems tab.

17. Click the Parameter ID tab.

The Parameter ID configuration screen appears.

18. From the Parameter ID dropdown list, select Yes or No to indicate whether you want theparameter ID to be updated in all corresponding SAP systems specified on the Systemstab.

19. Click Default tab.

The Default configuration screen appears.

20. From the Default dropdown list, select Yes or No to indicate whether you want the userdefaults to be updated in all corresponding SAP systems specified on the Systems tab.

21. Click User Group tab.

The User Group configuration screen appears.

22. From the User Group dropdown list, select Yes or No to indicate whether you want theuser group to be updated in all corresponding SAP systems specified on the Systemstab.

23. In the User Group Name field, enter the name of the user group.

24. Click Save.

Creating Rules

Procedure

To create a rule:

1. On the Configuration tab, navigate to HR Triggers > Rules.

The Rules screen appears.

2. Click Create.

The Rules, Rules Details screen appears.

3. From the HR System dropdown list, select the desired HR system.

This is the HR system where the events occur (initiating HR triggers).

4. In the Rule ID field, enter the name of the rule.

5. In the Effective From field, click the calendar icon to select the date when the rule takeseffect.

6. In the Rule Short Description field, enter a short description for the rule.



September 2008 215

The information in the Rule Short Description field appears in dropdown liststhroughout Compliant User Provisioning when you perform a query. This field islimited to 38 characters.

7. In the Rule Description field, enter a description for the rule.

8. In the Action field, click the arrow icon.

The Select HR Trigger Actions screen appears.

The action IDs in this list are the actions that you created on the HR Trigger > Actionsscreen. For more information about creating HR trigger actions, see the sectionCreating an Action.

9. Select the actions you want to associate with the rule.

You can select one or more actions. If you select more than one action, you must set thesequence in which the actions are executed. The actions are executed from low to high,zero (0) being the lowest and first action in the sequence to be triggered.

10. Click Select.

11. In the Attributes field, click the icon to add a new attribute.

The fields in the Info Type, Sub Type, Field, Operator, Value, and And/Or/Not columnsbecome active.

12. In the Info Type field, click the search icon to select the info type for your rule.

The Available Info Types screen appears.

13. Scroll through the list to locate the info type. Then click the radio button next to the infotype you want to select.

14. From the Select Sub Type dropdown list, select a sub type.

The Sub Type dropdown list is populated based on the info type you select. However,some info types might not have an associated sub type.

15. From the Select Info dropdown list, select the desired info field where the new value isstored or where you define new field parameters to apply the rule.

The Info Field dropdown list is populated based on the sub type.

16. Click Continue.

The Attribute screen displays the configured information.

17. From the Operator dropdown list, select the desired operator.

The operators include: =, <, >, and <>.

18. In the Value field, enter a value to be compared with the value in the Field column foryour rule.

If the $ symbol precedes the field value, it denotes the previous value for this field. Forexample, if the field is Admin and the value is $admin and uses the operator <> (notequal), your rule evaluates these two fields to be different.

19. From the And/Or/Not dropdown list, select the logical operators you need for additionalattributes in your rule.

20. Click Save.



216 September 2008

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/Notcolumns become active.


4. Click Save.

Changing or Deleting a Rule

Procedure

1. On the Rules screen, select the rule name you want to change or delete.

2. Click Delete.

Mapping Fields Using the SAP HR System

Procedure

To map fields using the SAP HR system:

1. On the Configuration tab, navigate to HR Triggers.

This option expands to display Field Mapping.

2. Click Field Mapping.

The Field Mapping screen appears.

3. From the SAP HR System dropdown list, select the desired HR system.

The field mapping for the specified HR system is displayed.

4. From the AE Field dropdown list, select the field that you want to map.

5. From the Field Type dropdown list, select Custom or Standard, depending on the AEfield.

6. In the Info Type column, click the search icon to query for all available info types.

The Sub Type and Field Name columns are automatically populated, depending onthe specified info type.

7. Click Save.

8. Click Load Standard Field Mapping to upload the standard field mapping from the SAPHR system to Compliant User Provisioning.

9. Click Save.

Schedule HR Trigger Background JobsTo get information from the SAP HR system to Compliant User Provisioning, you need toconfigure the background daemons to schedule HR Trigger jobs. The two jobs you need toschedule for the HR Trigger function are:

HR Triggers Load Data – It is recommended that you schedule this job for every 60seconds. This job is scheduled to update CUP HR Trigger rules and actions to theAC RTA installed on the SAP HR system.


Password Self Service

September 2008 217

HR Triggers – It is recommended that you schedule this job for every 80 seconds.This job is scheduled to retrieve HR Trigger event change information according tospecified rules to generate requests in CUP.

For more details on job scheduling, see the Background Jobs section.

View Process LogTo view the process log, click Process Log. This page shows all HR Triggers-relatedrequests.

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

Password Self ServiceThe Password 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 toolsaves the SAP Security Group time and expedites the password resetting process for the enduser.

The Password Reset via a CUA requires that the attribute for Inital Password is set toEverywhere in the CUA central system. You can use transaction SCUM to set theattribute.

There are three options for Password Self Service:

SAP HR Authentication: Requires the SAP HR module to be used for personnelinformation and personnel numbers linked to SAP user IDs, so that the user submittingthe request for the password reset can be verified against their personnel data in the SAPHR system.

Challenge Response: Allows the administrator to configure questions that the users canregister 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 onsuccessful answering the questions will the passwords be reset.

Peoplesoft HR Authentication: Requires the Peoplesoft HR module to be used forpersonnel information, so that the user submitting the request for the password reset canbe verified against their HR data.

When a user enters a request for a password reset, Compliant User Provisioning validatesthat 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 addressconfigured for that user.

When the user resets his/her password, the system emails the new password to them.

Defining Password Self Service for SAP HR

The process for using the Password Self Service for SAP HR Authentication includesconfiguration of which infotype, field, value combination in SAP HR personnel record isverified against the user.

In configuration, select the infotype and field combination. When the user enters the requestto reset their passwords, the user is asked to enter information based on the infotype fieldconfigured. The information they enter is matched against the user’s personnel record on that



218 September 2008

specific infotype value. If there is a match, the passwords are reset and sent to the emaillisted on the SAP HR personnel record. Compliant User Provisioning matches user IDs withHR personnel records using the Communication Infotype 0105 record subtype 01

ExampleConfiguration is set to compare the user’s Social Security Number (SSN). Theadministrator selects the infotype and field combination where the SSN is stored in the HRpersonnel record. When the user requests a password reset, they are asked to enter theirSSN. Based on the user ID, the HR personnel record is found and the SSN entered by theuser is compared to the SSN listed on the HR record. If they match, the passwords arereset and an email sent to the user.Configuration can include one or multiple infotype/field combinations. The user could beasked to enter multiple responses which will be compared to the HR record. For instance, itcan be configured that the user must enter their SSN, their national insurance number as wellas their birth date.

Procedure

To configure password self service:

1. On the Configuration tab, navigate to Password Self Service.

The Password Self Service screen appears.

2. Select the Type for Password Self-Service.

The screen changes for the specified type.

3. Click Create.

The fields in the Info Type, Sub Type, Field, and Description columns become active.

Make sure to add Verification Data Source as an Info Type. Currently PSS is workingfor SAPHR.

4. In the Info Type field, enter the info type, or click the search icon to query available infotypes.

5. In the Sub Type field, enter the associated sub type.

6. In the Field field, enter the field name for authentication.

7. In the Description field, enter a description of the verification .

8. Set the status to Active.

9. Click Save.

10. On the Verification Data Source screen, select a system to authenticate passwords fromthe System dropdown list.

11. Click Save.

12. On the Default System screen, select a system to authenticate passwords from theSystem dropdown list.

13. Click Save.

Defining Password Self-Service for Challenge Response

In the Challenge Response option, the administrator can enter a variety of questions theusers can choose from. The number of questions that the user must enter can also beconfigured. In addition to the questions, the administrator decides how many wrong answers



September 2008 219

are permitted before the user ID is locked. After this happens, a Compliant User ProvisioningAdministrator has to get involved to unlock the user ID.

After configuration is complete, each user must self-register themselves, choose thequestions they wish to answer and answer them. Their answers are then stored in CompliantUser Provisioning.

When a user enters a password reset request, they are asked to answer the questions theyselected during self-registration. If they answer them correctly, their user IDs are reset andthe email notification is sent to the user ID from the User Details Data Source.

When a user wants to change their challenge questions, this can be done by re-registering.This process allows them to reselect the questions to answer and answer them.

For new users, passwords are provisioned upon the completion of the approval workflow. Anotification email is sent to the user with password information. If the user logon fails after anumber of attempts, the user is locked. The user must then click the Password Self Servicelink in the End User Form to access the Self-Registration screen. In this screen, the user canselect the questions they would like to answer and submits the answers. Compliant UserProvisioning verifies that the questions are correct, and if so, it sends a notification email tothe user with a new password.

Example

As the administrator, you can create challenge questions for end users to select andanswer. After creating these questions, you must activate them in order to display themwhen the end user accesses the Registration link from the End User Form. Thesequestions should be generic and easy to answer. For instance, a simple challengequestion may be, “What is your favorite color?”

Procedure

To configure password self service for Challenge Response:

1. On the Configuration tab, navigate to Password Self-Service.

The Password Self Service screen appears.

2. Select the Type for Password Self-Service.

Once you have chosen the Type, the screen changes for the Type selected.

3. Select Number of Questions End User has to register:

This is the number of questions that the end user must answer during self-registration.This is also the number of questions the users must answer before their user IDs arereset.

4. Enter the Number of Unsuccessful Attempts after which user gets locked.

This is the number of attempts the user can try and enter the correct answers before theiruser ID is locked. The user IDs can be unlocked via the User Registration screen.

5. Click Save to save the configuration

6. Enter a List of Questions.

The administrator enters the questions that the users choose from when registering theiruser IDs for password self-service. Enter as many or as few questions as you wish.There must be at least as many questions as your response to Number of Questions EndUser has to register: Each question needs to be activated by clicking on the active icon(match stick). The Options available are Create, Change, Delete, Save.


Miscellaneous Configuration

220 September 2008

Defining Password Self Service for Peoplesoft HR

Procedure

To configure password self service for Peoplesoft HR:

1. On the Configuration tab, navigate to Password Self-Service.The Password Self-Service screen appears.

2. Select the Type for Password Self-Service. Once you have chosen the Type, the screenchanges for the Type selected.

3. Specific table and field information must be entered in accordance with Peoplesoft’s HRmodule.

Disabling Password Self Service

Procedure

To disable password self service:

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.

User Registration

All users who have registered for Password Self-Service are available for searches and aredisplayed on this screen. Once searched, the user’s user ID, status and number of attemptsto answer their challenge questions are displayed. If a user gets locked due to the number ofunsuccessful attempts, the administrator must to unlock their user ID from this screen.

Delete - deletes the user’s registration record. The user must perform self-registrationagain to choose and answer their challenge questions.

Unlock - unlocks the user who has been locked due to unsuccessful attempts to answerthe 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 screenafter they have answered their challenge questions.

Miscellaneous ConfigurationThe Miscellaneous Configuration screen defines system-level settings not associated withother features of Compliant User Provisioning. It establishes the workflow types to beintegrated with the other GRC Access Control features and capabilities.

You can configure the following settings from this screen:

Language Configuration

Log Level Configuration



September 2008 221

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 theWelcome screen: User ID, Password, and Language.

Although User ID and Password are required fields, Language is not. Set a default languagein the Miscellaneous screen by selecting a language from the Language dropdown list andthen 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 thatdiffers from the default language specified on the Miscellaneous screen, the default languageis 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 defaultlanguage. Objects created in a non-default language display descriptions in the defaultlanguage even when logged on to a different language.

When users log on to Compliant User Provisioning using the default language, they cancreate objects such as Initiator, Stage, Path, Approver, and the like. However, if they log onusing a language from the Language dropdown list on the Welcome screen that differs fromthe default language specified in Miscellaneous Configuration, they can only use the Changeoption to modify the object settings. They cannot use the Create option to create a newobject. By default, Compliant User Provisioning shows the default language description andallows 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, multiplemessages. Compliant User Provisioning automatically logs these messages. When youconfigure the log level setting, you specify which transaction messages it logs and which itignores.

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 systemdata in a cache. This allows access to key data without having to perform a database call. Onstart up, the system loads the data from its database into the cache, and it refreshes the dataeach time it performs a transaction.



222 September 2008

To ensure that the cached data is current, even when Compliant User Provisioning is idle, thesystem periodically refreshes the cache.

When you configure the cache job interval, you specify the amount of time that must elapsebefore 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 mustwait before refreshing the cache into the Cache Job Time Interval in Seconds text field andthen click Save.

Configure Workflow Types

The Configure Workflow Types feature establishes the workflow types to be integrated withthe 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 SystemData load, you cannot change these descriptions. The Short Description is displayed onscreens and on dropdown lists throughout Compliant User Provisioning.

Exit URL: This is the URL that Compliant User Provisioning uses to connect andcommunicate with this capability.

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

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

RISKhttp://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?wsdl&style=document

REhttp://<server>:<port>/AEWFExitServiceWS_5_2/Config1?wsdl&style=document

User Name: This is the name of the user Compliant User Provisioning uses to accessthat capability. This user ID must have the appropriate User Management Enginepermissions 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 beused in configuration, and it is not displayed in the Compliant User Provisioning screensand dropdown lists.

Configure the Background Job Interval

Compliant User Provisioning uses a daemon process to run scheduled background jobs. Thedaemon runs periodically and executes all background jobs scheduled to run. Setting thebackground job interval determines how much time must elapse before the background jobdaemon is executed.

To set the Background Job Time Interval, in the Background Job Time Interval in Minutesfield, enter the number of minutes that Compliant User Provisioning waits before running thebackground job daemon. Then click Save.

6 Enterprise Role Management

Configuring Enterprise Role Management

September 2008 223

6 Enterprise Role ManagementEnterprise Role Management allows you to create and maintain roles to reflect your businessmodel and requirements. You should set up a functional environment and test it thoroughlybefore attempting to use it in a production environment.

Configuring Enterprise Role ManagementSAP recommends that you configure certain functions before others In Enterprise RoleManagement.

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 ManagementAfter installing Enterprise Role Management on a SAP NetWeaver server, use a Webbrowser 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 onwithin 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 theREAdmin user name and password.


Initial System Data Importation

224 September 2008

The REAdmin user name and password are created during the Access Control installationprocess. For more information, see the section Role Creation.

For more information, see the SAP GRC 5.3 Access Control Installation Guide onSAP Service Marketplace at http://service.sap.com/instguides -> SAPSolution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAPGRC Access Control 5.3.

Initial System Data ImportationBefore you configure Enterprise Role Management, you must import initial system data. Thisdata is the default system data that is pre-packaged with the system. It is the minimum set ofdata 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 theSAP GRC Access Control installation process as described in the section Role Creation.


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 dataoriginally shipped with Enterprise Role Management.

Result

Initial system data is now imported, and Enterprise Role Management is now ready for furtherconfiguration.

Initial Background JobExecuting initial background jobs for Org Value Sync, Transaction/Object/Field Sync, andActivity. Org Val Sync is a prerequisite for SAP role authorization data maintenance andorganizational value mapping.


Managing Background Jobs

September 2008 225

Managing Background JobsYou use background jobs to synchronize information in Enterprise Role Management with theSAP back-end system and to perform mass maintenance. Enterprise Role Managementprovides two kinds of background job:

Dynamic - Dynamic background jobs are scheduled by Enterprise Role Managementusers through mass role import and role mass maintenance. For more information seethe 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 Managementto the SAP back-end system. You can use the Mass Generation option to schedulethe background job.

Risk Analysis and Role Generation – This job schedules role generation for aparticular 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 theMass Risk Analysis option to schedule the background job.

Role Import – This job uploads the roles from the SAP back-end system to EnterpriseRole Management. You use the Mass Role Import screen to schedule a backgroundjob.

Role Usage Synchronization – This job synchronizes usage data. You use the RoleUsage Synchronization screen to schedule a background job.

Static - Static background jobs are scheduled by the Enterprise Role Managementadministrator and can be run immediately or periodically to synchronize the SAP systemwith Enterprise Role Management.

The following static background jobs are available:

o Org Value Sync: This job synchronizes the organizational values in Enterprise RoleManagement with the SAP ERP back-end system.

o Transaction/Object/Field Sync: This job synchronizes the Transaction, Object, andField 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 thecount on the Miscellaneous screen. This setting allows only a fixed number of backgroundjobs to run at one time. If the number of background jobs scheduled to run exceeds the



226 September 2008

number set on the Miscellaneous screen, the surplus jobs are queued and run in the orderscheduled. For more information about scheduling the number of background jobs to runconcurrently, see the section Configuring Miscellaneous Functions.

Creating a Static Background Job

Procedure

To create a static background job:


The Background Jobs screen appears.

2. Click Create.


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 SearchResults screen of the Background Jobs screen.

Editing a Background Job

Procedure

To edit a background job:



2. Click the radio button next to the Job ID of the background job you want to change.

3. Click Edit.



5. Click Schedule.



September 2008 227

Deleting a Background Job

Procedure

To delete a background job:

You can only delete background jobs in the Ready State.1. On the Configuration tab, navigate to Background Jobs.


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

To activate/deactivate a background job:

You can activate or deactivate a background job only if it is active (running).1. On the Configuration tab, navigate to Background Jobs.


2. Click the button next to the Job ID of the background job you want to activate ordeactivate.

If a background job is active, the light bulb icon in the Active column appears as on. If thebackground 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:



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:



2. Click the button next to the Job ID of the background job for which you want to view ahistory.


Configuration for Risk Analysis Integration with Risk Analysis and Remediation

228 September 2008

3. Click Job History.

The Background Job History screen appears.

Configuration for Risk Analysis Integration with RiskAnalysis and RemediationEnterprise Role Management works directly with Risk Analysis and Remediation to performthe following functions:

Risk analysis

Risk mitigation

Authorization function search

Transaction usage

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

If it is on the same server, select Do not use Web Service and skip only theconfiguration for CC Risk Analysis in step 4. For this option, Enterprise RoleManagement integrates with Risk Analysis and Remediation using EJB service withinthe Web server to facilitate faster integration. Configuration for all other Web servicesin step 4 is still required.

If it is not on the same server, select Use Web Service, and continue with step 4 toconfigure all Web services.

4. On the Configuration tab, identify the correct Risk Analysis and Remediation Web serviceURLs, 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

To identify the correct Web service URL:

a. Open a new browser session, and navigate to the Web Application Serverhttp://<server>:50000/.

b. In the new browser window, click Web Services Navigator to display the WebServices Navigator screen.

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


Configuration for Workflow Integration with Compliant User Provisioning

September 2008 229

CC Functions expands the VirsaCCFunction5_0Service folder.

d. Click Document.

The Web service URL is listed below the Web Services Description Language(WSDL) heading.

Right-click the Web service URL, and then click Copy Shortcut.

Return to the Configuration / Miscellaneous screen, and paste the URL intothe appropriate Web service URL field.

Repeat steps a through d for each CC Web service URL.

e. Repeat steps a through d for each CC Web service URL.

5. Enter the Web service user name and password in each of the Web Service Info. for CCscreen's fields.

Obtain the Web service user name and password for the Web services from yoursystem administrator. This user communicates across the GRC capabilities throughthe Web services configured in each application.

Use the same user name and password information from the connector and create acommon Web user in the User Management Engine (UME) for all capabilities. Usingthe same user for all Web service configurations across the GRC capabilities helpsavoid integration issues caused by incorrect user name, password, and/orauthorizations.

6. Click Save.

Configuration for Workflow Integration with CompliantUser ProvisioningEnterprise Role Management integrates with Compliant User Provisioning for the roleapproval workflow feature. During the approval phase, the role is submitted for approvalusing Compliant User Provisioning approval workflow.

Configuring Compliant User Provisioning Workflow for Enterprise Role Management

Procedure

You perform the workflow configuration activities for the Enterprise Role Managementapproval process in Compliant User Provisioning. To configure Compliant UserProvisioning for use with Enterprise Role Management, you must have CompliantUser Provisioning administrator privileges. For more information on completing thefollowing 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 intoCompliant User Provisioning, using Append on the Import Initial Data screen.

For more information, see the Compliant User Provisioning section of this guide. Importinitial system data only if it was not done during the SAP GRC Access Control installationprocess as described in the section Role Creation.



230 September 2008


After the initial configuration data is imported, you see RE in the dropdown list forworkflow 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 sureyou 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.

e. Select Condition And and Attribute Request Type.

f. Select Value from the dropdown list. This should be the request type for EnterpriseRole Management which you created in step 4.

g. Click Add Attribute.

h. Select Condition And and Attribute Priority.

i. Select Value from the dropdown list. This should be the priority for Enterprise RoleManagement which you created in step 5.

Click Add Attribute.

j. Click Save.

8. Create a Custom Approver Determinator for Enterprise Role Management requests:

a. Set the CAD Type to Web Service.

b. The Workflow Type must be set to RE.

c. Enter the Web Service URI.

d. Enter the Web service User Name and Password.

e. Click Save.

To find the correct URI for Compliant User Provisioning, follow steps a through d inthe section Configuring Enterprise Role Management Web Services for CompliantUser Provisioning. Expand the AEWFCADApproversServiceWS_5_2 folder to obtainthe correct Compliant User Provisioning URI.



September 2008 231

The Web service user must be the same user you created for application integrationin the earlier configuration step.

9. Create the Enterprise Role Management approver stage for the approval workflowprocess.

Depending on your approval process, you can create an additional approval stage bycreating another Custom Approver Determinator by repeating step 8. Using CAD TypeAttribute.

The Workflow Type must be set to RE. The approver determinator you select here is thecustom 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.

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

f. Select the Initiator that you created in step 7.

g. For Path Definition in the Path section, select the stage(s) you created in step 9.

h. Click Save.

i. Select Miscellaneous to configure exit Web service for Enterprise Role Managementapproval workflow.

j. Configure the exit Web service information for Enterprise Role Management approvalworkflow.

The Exit URL is the return path for role approval or rejection information from CompliantUser Provisioning to Enterprise Role Management.

To find the correct exit URL for Compliant User Provisioning, follow steps a through din the section Configuring Enterprise Role Management Web Services for CompliantUser Provisioning. Expand the AEWFExitServiceWS_5_2 folder to obtain the correctCompliant User Provisioning Exit Service URL.

11. Click Active.

Configuring Enterprise Role Management Web Services for Compliant UserProvisioning

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 Serverhttp://<server>:50000/.

b. Click Web Services Navigator.

The Web Services Navigator screen appears.


System Landscape Definition

232 September 2008

c. Expand the AEWFRequestSubmissionService_5_2 folder, and then click Document.

The Web service URL is listed below the WSDL (Web Services DescriptionLanguage) heading.

d. Right-click Web Service URL and select Copy Shortcut from the context menu.

3. Return to Enterprise Role Management's Configuration screen, and paste the URL intothe Workflow URL field in the Web Service Info. for AE Workflow section.

4. Click Save to save your selections.

System Landscape DefinitionA system landscape is a configuration of systems where role definition, creation, testing, andrisk 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 touse for risk analysis purposes only. Then, you can create a system landscape where eachsystem is associated with the actions to be used in the role management process.


If you adhere to change control procedures in your ERP application (where all rolesare created in Development, then transported to Quality Assurance/Production), youshould not have a production system in your landscape associated with RoleGeneration action.

ExampleYou have three systems (or connectors) in a landscape, in which to perform the rolecreation process: Test Development Production or Quality Assurance

This landscape uses the test system to design, define, and test your roles. When you arecomfortable with the role definition, generate the role in the development system foradditional 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 controltools. For risk analysis to reflect your most realistic risk, the either the production systemor the quality assurance system serves as the system of origin against which you performrisk analysis.

Defining Connectors for Enterprise Role Management.You can set up different types of connectors in Enterprise Role Management. These includeEnterprise, non-SAP, SAP, and SAP EP connectors.

The Enterprise, non-SAP, and SAP EP connectors are descriptive connectors usedto document the landscape to which each role belongs.

The SAP connector is a live system connector that facilitates the transfer of databetween Enterprise Role Management and other SAP ABAP systems.

When setting up a landscape, you specify how you want Enterprise Role Management tocommunicate with the target systems by associating the connectors with predefined actionsduring the landscape creation process.


Defining Connectors for Enterprise Role Management.

September 2008 233

The actions available for you to associate the connectors with are delivered withEnterprise Role Management. You cannot create your own actions.

Access Control communicates with multiple systems; therefore SAP recommends usingHTTPS communication protocol for secure communication.

Configuring a Connector for SAP

Your network administrator must provide information for completing the Create Systemscreen.

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 andthe CUA. Make sure that the connector name for Access Control is the same as theone configured for CUA.

6. In the Description field, enter a detailed description of the system connector, such as HRQA System.





11. In the User ID field, enter the SAP user name.

12. In the Password field, enter the password associated with the SAP user.

13. In the System Language field, enter the system language for the application server.

14. In the Message Server Name field, enter the name of the message server, which is usedfor load balancing of your SAP clustered environment.

15. In the Message Server Group field, enter the Logon Group name the message serverbelongs.

16. In the Message Server Host field, enter the host name of the message server.

17. In the SAP Version dropdown menu, select the appropriate SAP version. Enterprise RoleManagement supports SAP 4.6c and higher.

18. Click Save.



234 September 2008

When you have created the new connector, click Test Connection to ensure that theconnection is valid.

Configuring a Connector for Enterprise, Non-SAP, or SAP EP

You can use the following procedure to plan and document the connection between ERM andnon-ABAP systems. ERM can only communicate with ABAP systems directly.

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

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.

After you create the new connector, click Test Connection to ensure that theconnection is valid.

Creating the Landscape

A system landscape is a logical grouping of systems. A landscape contains more than onesystem and is populated by assigning systems and then associating them with a predefinedaction or actions. Associating actions with a system defines which action is performed inwhich system within a particular landscape.

ExampleYou can associate role risk analysis with a test system or a production system and ageneration 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. Youcannot create your own actions.

Setting up a landscape allows you to associate role definitions that you create in EnterpriseRole Management to multiple systems. The landscape can contain SAP and non-SAPsystems. You can configure certain role definitions to be associated to a specific landscape.



September 2008 235

Example

You create a landscape that contains the system types SAP HR system, SAP FI system, andOracle Application system (non-SAP). Each of these system types has a system forDevelopment, Test, and Production. You name this landscape, ‘Palo Alto Landscape’.

In Enterprise Role Management, go to the Role Management tab > Roles > Create to createa role definition and specify the landscape, ‘Palo Alto Landscape’. In the Role Generationphase of role creation, you can select the appropriate system (with Generation of Role actionassigned) for the role generation.

Automated Role Generation from Enterprise Role Management is applicable to SAPABAP only.

After completing the creation of role definitions, you must define the Web service URL thatsubmits the role definitions to the approval workflow process in Compliant UserProvisioning. Go to Configuration tab > Miscellaneous. In the Configuration screen, enterthe Web service URL in the Web Service Info. for AE Workflow pane.In Compliant User Provisioning, a request is submitted to the approval workflow. Thisrequest is a RE (Role Expert) workflow type. Make sure that the RE workflow type isactive 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 tothe ‘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 sectionAssigning Systems to the Landscape.

Assigning Systems to the Landscape

Procedure

Before you can assign systems to a landscape, you must create the landscape. To assignsystems to the landscape:



236 September 2008


The Search System Landscape screen displays available system landscapes. Search forthe 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 thecheckbox 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 youwant the system to perform.

5. Click Add.

All systems available for this landscape type appear on a dropdown list for the user toselect.

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 withpredefined 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 RoleManagement. You cannot create your own actions.


The Search System Landscape screen displays all available system landscapes. Searchfor 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 thecheckbox 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.

To activate a dropdown list from which you can select a connector for an action, click theAdd 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 actionyou want to set as default.


Role Designer

September 2008 237

The system and its associated action are automatically saved in the landscape as thedefault connector.

If you have associated more than one system with an action, you must set a defaultconnector for that action. For example, systems A, B and C are assigned to the actionGeneration 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 systemson the Role Generation screen.

For mass role generation, the default system is always used and cannot bechanged, unless you change the default in your system assignmentconfiguration.

Role DesignerRole Designer provides you with a logical, step-by-step roadmap to support configuration ofrole master data for your Enterprise Role Management process. Following the outlinedprocedure ensures that major role master data configuration steps or data to be associatedwith each role are not missed.

Features

When you select the role designer step, the system takes you directly to the configurationtask 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 creationprocess. You determine values for each attribute during Enterprise Role Managementconfiguration 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

Managing Business Processes

A business process is a collection of related activities that produces something of value foryour organization or business and is categorized according to the organizational structure ofyour enterprise. A business process can be managerial, operational, or supporting, and canbe defined narrowly or broadly, depending on your business needs. When you create a rolein Enterprise Role Management, the business process you assign to the role is one of therole’s defining attributes and determines which subprocesses you can assign to that role.


Role Designer

238 September 2008


ExampleSome 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 byBusiness 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 theSearch Business Process screen.

Changing a Business Process

Procedure

To change a business process:

1. On the Search Business Process screen, select the checkbox next to the businessprocess 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 anew one.3. Make any changes to the description or abbreviation.

4. Click Save.

Deleting a Business Process

Procedure

To delete a business process:


Role Designer

September 2008 239

A business process can be deleted only if it is not associated with a role, businesssubprocess, 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 ormass 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 theformat 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, selectOverwrite.

New records in the file are added. If you do not want to overwrite existing records (ifthese records are in the import file), do not select this box.

4. Click Import.

The system message Business Process saved successfully indicates that thedata was imported successfully.

Managing Business Subprocesses

A business process can be divided into several business subprocesses, each with its ownattributes. A business process typically contains one or more subprocesses.


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.


Role Designer

240 September 2008

6. Click Save.

Your subprocess is saved and now appears in the list of subprocesses on the SearchSubprocess 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 wantto 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 wantto modify.

2. Click Change.

The Change Subprocess screen appears with the Subprocess ID dimmed, indicating thatthe ID cannot be changed.

3. Make any changes to the description or abbreviation

4. Click Save.

Mapping Subprocesses to Business Processes

Procedure

During the role creation process, the subprocesses available for you to select as roleattributes 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 thenselect Process Mapping.

The Associate Business Subprocess to Business Process screen appears.

If the business process you select already has an associated subprocess, thesubprocess 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.


Role Designer

September 2008 241

Only those subprocesses not already assigned to a business process appear in thedropdown list.

5. Click Save.

A business process can include more than one subprocess. Repeat steps 3 through 5 to mapanother subprocess to the same business process. Alternatively, select another businessprocess from the Business Process dropdown list at the top of the screen, and then repeatsteps 3 through 5.

Importing Subprocesses

Procedure

You can manually maintain the subprocesses within Enterprise Role Management, or youcan 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 containsthe format for the import file.

2. Click Browse to locate the file you want to import.


New records in the file are added. If you do not want to overwrite existing records (ifthese records are in the import file), do not check this box.

4. Click Import

The system message Subprocess saved successfully indicates that the data wasimported successfully.

Managing Functional Areas

A functional area is a classification of processes for a department or business process. WithinSAP, a functional area is used to organize certain activities within a department or businessprocess. In Enterprise Role Management, a functional area is a role attribute used tocategorize roles and define the approval and role maintenance processes. In addition, afunctional area is used to filter the results of a role search, identifying only those rolesassociated with a specific functional area.


ExampleWithin your business you might have the business process Procurement, which containsthe functional areas of Purchasing, Administration, and Receiving. However, one or moreof these functional areas might also fall under the business process Finance.


Role Designer

242 September 2008

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

A functional area can be deleted only if it is not associated with a role, approvalcriteria, or condition group.

1. On the Search Functional Area screen, select the checkbox next to the functional areayou want to delete.

2. Click Delete.


Importing a Functional Area

Procedure

You can manually maintain the functional areas within Enterprise Role Management, or youcan mass import your data using the import feature.

1. On the Search Subprocess screen, click Import.

The Import – Functional Area screen appears.


Role Designer

September 2008 243





4. Click Import

The system message Functional area saved successfully indicates the datawas imported successfully.

Managing Custom Fields

Custom fields allow you to add attributes to a role that are specific to your company ororganization. For example, if you want to distinguish a role by region, add a custom attributeand 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.


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.

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 adropdown list or a text field.

If the field type is a dropdown list, select a data source from which to import the datafor 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 Nameand a Field Name.

o If you select RE, you can enter multiple field values users can select from in theCustom Fields Values section.

If the field type is a text field, select a data type from the dropdown list. Available datatypes are:

o Date

o Numeric


Role Designer

244 September 2008

o Varchar2

If the data type is either Numeric or Varchar2, you must define the number ofcharacters 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 tomodify.

2. Click Change.

The Change Custom Fields screen appears with the name of the custom field dimmed,indicating that the name cannot be changed.


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

2. Click Delete.


Importing a Custom Field

Procedure

You can manually maintain the custom fields within Enterprise Role Management, or you canmass import your data using the import feature.

1. On the Custom Field screen, click Import.

The Import – Custom Fields screen appears.



3. If you want to overwrite all existing records with the new data in the import file, select theOverwrite checkbox.


4. Click Import.


Role Designer

September 2008 245

The system message Custom field saved successfully indicates that the datawas imported successfully.

Managing Projects and ReleasesThe project or release can be a project name, release name, or release number that youwant to associate with a particular role. The Project or Release ID field allows you to trackand filter roles by project or release based on your organization’s requirements.


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 areaon the Search Project/Release screen.

Changing Project or Release Information

Procedure

To change project or release information:

1. On the Search Project/Release screen, select the checkbox next to the project or releaseyou 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 arole, approval criteria, or condition group.

1. On the Search Project/Release screen, select the checkbox next to the project or releaseyou want to delete.

2. Click Delete.


Role Status

246 September 2008


Importing a Project or Release

You can manually maintain the project or releases within Enterprise Role Management, oryou can mass import your data using the import feature.

Procedure

1. On the Project/Release screen, click Import.

The Import - Project/Release screen appears.





4. Click Import.

The system message Project/Release saved successfully indicates the datawas imported successfully.

Role StatusDuring the role creation process, Role Status is a required field. You can set the status of therole to Development or Production.

Development indicates that the role is not ready for production usage and is usuallynot transported to a production environment.

Production indicates that the role is ready for production usage and usually istransported to a production environment.

The role status is used by the system for integration with Compliant User Provisioning rolesynchronization, with Enterprise Role Management set as the role source. If the role status isset to Production, Enterprise Role Management synchronizes the role to Compliant UserProvisioning for user provisioning. Therefore, role status is predefined and delivered withEnterprise Role Management. You can change the role status description only.

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 toDevelopment or Production for identification purposes. You can then easily search for therole status Development and retrieve the 200 roles.


Managing Condition Groups

September 2008 247

These roles are not automatically transferred to their respective systems but ratherimported by using the Mass Role Import tool.

Managing Condition GroupsA 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 andconditions. After you create a condition group, the system applies it to a role creation processto override the default role creation process when the criteria from the condition group aremet. You can apply multiple condition groups in one role creation process, but you cannotassociate multiple processes to one condition group.


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.

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

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:



248 September 2008

1. On the Condition Groups screen, select the checkbox next to the condition group youwant to change.

2. Click Change.

The condition group appears with the Condition Group ID dimmed, indicating that youcan 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 youwant to change.

2. Click Delete.


A condition group can be deleted only if it is not associated with a methodologyprocess.

Role Creation Methodology Setup

A role creation process consists of predefined methodology actions and the methodologysteps associated with those actions. The steps then create a methodology process, whichguides you through the process of defining, generating, and testing a role during rolecreation. Enterprise Role Management is delivered with the predefined role methodologyprocess Virsa Default Process. You can also configure your own role creation processaccording to your organization’s requirements.

Methodology Steps

Methodology steps are the steps to create a role during the role creation process. Based onthese steps, you can tell which phase of the role creation process a role is in. Enterprise RoleManagement allows you to create methodology steps and associate them with predefinedactions provided within Enterprise Role Management. After you associate the steps with thepredefined actions, you can create a role methodology process.


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.



September 2008 249

4. In the Description field, enter a brief description for the step.


If you select Enable, the step is available for inclusion in a methodology process. If youselect Disable, it is not available.

6. From the Associate Action dropdown list, select an action with which to associate thestep.

The actions you associate with your step are predefined in Enterprise RoleManagement.

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 tochange,

2. Click Change.

The methodology step appears with the Step ID dimmed, indicating that you can onlychange the attributes of the step, not its name.

3. Make any changes to the methodology step.

4. Click Save.

Deleting a Methodology Step

Procedure

To delete a methodology step:

If a methodology step is already associated with a methodology process, neither thestep nor the process can be deleted.

1. On the Steps screen, select the checkbox next to the methodology step you want todelete.

2. Click Delete.


Methodology Actions

Enterprise Role Management is delivered with predefined actions. Although you cannotcreate new actions, you can create steps to associate with the predefined actions and thenuse those steps to create a methodology process.

Activities

Clicking each action name on the Predefined Actions screen allows you to see which buttontriggers the associated action.

To view Enterprise Role Management predefined actions, select Methodology Actions on theConfiguration tab.

Enterprise Role Management Predefined Actions



250 September 2008

Action Description

Approval of a Role This action is associated with sending the role for approval throughapproval workflow.

Generation of aRole

This action is triggered when you want to generate the role in the back-end ERP system.

Initiating RiskAnalysis

This action is triggered when you want to perform risk analysis on arole. The risk analysis is based on the default analysis settingsspecified during configuration.

Saving RoleDefinition

This action is associated with saving the definition of a role. Thisexcludes saving authorization data and risk analysis results.

Saving Test Results This action is triggered when you want to maintain test results aftertesting a role.

Saving RoleAuthorization Data

This action is triggered when you want to maintain the authorizationdata for the role.

Saving RoleDerivation

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

Methodology Process

A methodology process consists of multiple steps and defines the order and flow of the rolecreation process through all of the associated steps.


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.


If you select Enable, the methodology is available for a role by matching the attributesof the role in question with the condition group(s) associated with this process. If youselect 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.


Managing the Workflow

September 2008 251

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

13. Click Save.

If more than one methodology process is configured in your system, select oneprocess as the default. To set a default process, click the light bulb icon associatedwith the process you want to set as the default. All other processes are triggeredbased on condition group.

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 canonly change the process attributes, not its name.


4. Click Save.

Deleting a Methodology Process

Procedure

To delete a methodology process:

A methodology process cannot be deleted if it is set as the default process, if it isbeing used for role creation, or if it is the only process configured in Enterprise RoleManagement.

1. Select the checkbox next to the methodology process you want to delete,

2. Click Delete.


Managing the WorkflowEnterprise Role Management integrates with Compliant User Provisioning for role approvalworkflow. As part of the integration, a role approver is defined during the role creationprocess to be used by the approval workflow.

During the role creation process, you can manually define approvers and alternate approversfor each role, or you can allow Enterprise Role Management to automatically assignapprovers and alternate approvers to that role based on the approval criteria you create andthe role attributes the user selects.

To create approval criteria, you assign approvers and alternate approvers for a set of roleattributes or conditions.



252 September 2008


Prerequisites

You must have Compliant User Provisioning installed and configured in order to use theworkflow 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 createapproval 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.

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.

b. In the Value column, select a value from the dropdown list.

c. Click Add.

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



September 2008 253

The Approver Search window closes, and the Approver field on the Change ApprovalCriteria 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 forthe 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 whichyou 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 inthe section Creating Approval Criteria for a Workflow.

To change existing approval criteria, select the checkbox next to the ApprovalExpression you want to change. Then click Change to make the changes.

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 whoseapproval criteria you want to delete.

2. Click Delete.


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.



Managing Naming Conventions

254 September 2008

Managing Naming ConventionsYou create naming conventions to enforce role and profile naming standards during the rolecreation process. Naming conventions are specific to a system landscape and role type. Thelandscape and role type determine the attributes available to assign to a naming convention.


ExampleYou can have different naming conventions for the Single role type in thedevelopment system landscape and the test system landscape. You can havedifferent naming conventions for the Composite role type in the development systemlandscape 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 roleattributes. The role attributes available for naming convention creation for all role types areBusiness Process, Subprocess, and Project/Release. For SAP derived roles, additional roleattributes 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.

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-populatedeach time you assign an attribute and/or text character, but you decide the order andnumber 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 12characters). Each time you add characters, the position of the assigned characters andnumber of characters still available is displayed on the right side of the Create NamingConvention screen.


Managing Organizational Value Mapping

September 2008 255

Two types of character appear in the Expression field:

Variable characters represent the attribute value you select from the Attributedropdown list and are represented in the Expression field as a dollar sign ($). Whenyou 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 businessneeds, but it is typically based on valid characters for SAP role names. Free text isrepresented in the Expression field by either a dollar sign ($) or the actual text youenter in the Text field.

7. Populate the Expression field:

a. Select an attribute from the Attribute dropdown list.

b. Take one of the following actions:

Enter the number of characters needed to represent the selected attribute in theNo. 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 theExpression field, and the positions the characters hold in the expression appear inthe screen on the right. In addition, you can see the number of characters that remainavailable 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.

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.


Managing Organizational Value MappingIf you want to restrict user access by organizational area, you can use the organizationalvalue mapping feature to map roles to different organizational levels. To define all associatedorganizational values, you can create an organizational value map for each organizationalarea (such as North America, Europe, and Asia Pacific).



256 September 2008

Prior to creating an organizational value map, you must run a background job to importexisting 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 dataupdated. For more information about background jobs, see the section ManagingBackground 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 organizationalvalue. You can create multiple maps for the same primary organizational level and valuecombination. After the primary organizational level and value are set, you can define thevalues for all child organizational levels within the map to complete the organizational valuemap creation.

After you create the organizational value map, it can be used by all users as a basis to deriveany master role.

You must run the initial background jobs for Org Value Sync, Transaction/Object/FieldSync, and Activity Val Sync prior to configuring organizational value maps. Thesebackground jobs are a prerequisite for the organizational value mapping feature. Any fieldname denoted with an asterisk (*) is required.

ExampleCreate an organizational value map for North America with the primary organizationallevel as Company Code with value 1000 through 2000. Within Company Code 1000through 2000, the child organizational levels, such as a plant or division, are set withthe value of 100 through 200 (the location of the plant or division). When you derive arole using this North America map, the derived role assumes the primaryorganizational 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.

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.



September 2008 257

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

16. Click Save.

17. To view all existing roles affected by this mapping, click Master Role Impact or DerivedRole 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 MappingName 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 orImpacted Derived Roles.

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 youwant to delete.

2. Click Delete.


Importing an Organizational Value Mapping

Procedure

You can manually maintain the organizational value map within Enterprise RoleManagement, 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.


System Logs

258 September 2008

A standard Windows Choose File dialog box appears.

You can click the red arrow next to the Browse button to download a template thatcontains 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 yourcomputer in spreadsheet format (.xls). This feature uses the spreadsheet for reportingpurposes, as well as for making changes to the information in the spreadsheet and thenimporting the file back into Enterprise Role Management.

Enterprise Role Management also provides you with a template for importing and exportingorganizational value maps. After you download the template into a directory, you can addyour organizational value maps and then import those maps into Enterprise RoleManagement.

You can use your own spreadsheet to import organizational value maps as long as youuse the same column and header formatting as used in the Enterprise Role Managementtemplate. SAP recommends that you use the template provided with Enterprise RoleManagement for importing organizational value maps. Do not modify the column format orheader names because those names affect how the template interacts with EnterpriseRole 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.

3. Click Open to view the spreadsheet or Save to save the spreadsheet to a directory onyour computer.

4. After you make any changes to the information in the spreadsheet, use the Importfunction to import the changes back into Enterprise Role Management.

For more information about importing organizational value maps, see the sectionImporting Organizational Value Map.

System LogsSystem logs provide a history of role management actions and are used by administratorsand developers for troubleshooting purposes.

Activities

You can view system logs by navigating to the System Logs screen and selecting Get Logs.


Transaction Import

September 2008 259

Transaction ImportThe transaction import feature of Enterprise Role Management imports non-SAP transactions(actions) into Enterprise Role Management to be used as authorization data during the rolecreation process. If you choose not to import the non-SAP actions, you must manually enterauthorization 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 thatcontains the format for the import file.


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 importedsuccessfully message appears.

Importing Mass Roles

For SAP systems, the mass role import feature of Enterprise Role Management synchronizesthe SAP back-end systems with Enterprise Role Management by importing roles that alreadyexist in the SAP ERP system.

For non-SAP systems, the mass role import feature of Enterprise Role Management importsyour roles and transactions/actions data from a spreadsheet based on the provided templateformat.

Prerequisites

Before you can use the mass role import functionality of Enterprise Role Management, youmust:

Ensure that connectors, a system landscape, and role attributes are configured withinEnterprise Role Management.

Ensure that role attribute master data on your import file matches the data in EnterpriseRole Management.

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_DNLDROLEStransaction on that system.

Run the /VIRSA/RE_DNLDROLES transaction as a background process.

When executing the /VIRSA/RE_DNLDROLES transaction, save the Bulk Downloadfile as a text file with .txt file extension to either your local computer or to the server onwhich Enterprise Role Management is installed. Specify a file name that is easilyremembered. You can download single, composite, and derived roles in the samedownload file.


Transaction Import

260 September 2008

Create a role and attribute information file for the downloaded roles in Enterprise RoleManagement. This file contains required role attribute information specific to EnterpriseRole Management. This information does not exist in the back-end SAP system. Theinformation file must be in tab-delimited text format and contain the following roleattributes 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. Youcan 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 RoleManagement Information File field appears. Click the red download arrow to downloadthe 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 thetemplate.

You can also download template files from Help on the main Enterprise RoleManagement application screen.

For more information, see the SAP GRC Access Control 5.3 Application Help on SAPHelp 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 thederived roles or it must already exist in Enterprise Role Management. You must alsocreate a Primary Org Level file. Enterprise Role Management provides a template for thispurpose. Access the template by clicking the red download arrow next to the Browse iconfrom the Mass Role Import screen.

Importing Multiple Roles

Procedure

To import multiple roles:

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 toimport the roles.

3. From the System Type dropdown list, select the system type to which you want to importthe roles.

4. From the System Landscape dropdown list, select the system landscape to which youwant to import the roles.

5. From the Import Source dropdown list, select the source from which to import the roles.


Transaction Import

September 2008 261

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 textfile 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 sectionMass Role Import.

6. In the Bulk Download File field, either enter the server file path or click Browse to locatethe files on your hard drive.

For non-SAP systems, Enterprise Role Management provides a template for thispurpose. Access the template by clicking the red download arrow next to the Browseicon.

For SAP systems, this is the file you downloaded when you ran the/VIRSA/RE_DNLDROLES transaction. For more information about the Bulk Downloadfile, see the section Mass Role Import.

7. (SAP systems only.) In the Enterprise Role Management Information File field, eitherenter the server file path or click Browse to locate the files on your hard drive. For moreinformation about the Enterprise Role Management Information file, see the section MassRole Import.

8. In the Primary Org Level File field, either enter the server file path or click Browse tolocate 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 orNo 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 importstatus.

If you select Background, the system automatically schedules a background job anddisplays the message Background job for mass role import issuccessfully scheduled; job ID is ###. For more information, see thesection Viewing the History of a Background Job.

Role Usage Synchronization

This feature allows you to synchronize role usage information by user from your SAP ERPsystem or to upload this information using the upload file template. For detailed informationon format usage, see the section Role Usage Import Template. Role usage information isstored in Enterprise Role Management for integration with Compliant User Provisioning toprovide role usage information for User Access Review.

Procedure

To perform role usage synchronization from a system:

1. On the Configuration tab, navigate to Role Usage Synchronization.

2. From the Role Usage Synchronization section, select the system from which you want tosynchronize the role usage.


Transaction Import

262 September 2008

The systems configured in Enterprise Role Management are SAP systems. For non-SAP systems, use the manual upload feature described below.

3. Enter the Synchronization Start Date. This is the date when you want the synchronizationto begin. If you leave this field blank, it defaults to the date of the last synchronization job.For the initial run, it uses today’s date.

Enterprise Role Management remembers the initial start date that you enter in thisfield for the first synchronization. When you synchronize the role usage for the secondtime, it compares data from the initial synchronization date to the data of the new startdate. Enterprise Role Management updates only those records that are different.

4. Click Schedule.

The system displays the message Role usage synchronization job scheduledsuccessfully; job ID ## if the synchronization is scheduled successfully.

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 wherethe role usage information is being uploaded.

The Upload Role Usage feature is primarily used for uploading the role usagesynchronization 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 UsageImport 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 therole 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 1indicates that the role isnot expired.

Enterprise Role Management compiles role usage data from SAP systems into the formatused by the role usage import template. You use the same format for compiling role usagedata from a non-SAP system and later upload to Enterprise Role Management.


Importing and Exporting Configuration Settings

September 2008 263

Importing and Exporting Configuration SettingsThis feature exports configuration settings from one Enterprise Role Management systemand imports them into another. You must export the settings first and then use the generatedfile as the import source file for the other system. For example, after you configure thedevelopment system, you can export the configuration settings and import them into theproduction system, so you do not have to manually reconfigure the settings.

Exporting Configuration Settings

Procedure

1. On the Configuration tab of the configured system, navigate to Configuration Settings.

The Import/Export Configuration screen appears.

2. In the Export Settings section, select the checkbox next to the attribute grouping to selecta group of attributes, or select the checkbox in the top left corner of the section to selectall 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 doesnot recommend that you manually modify this file.

Exporting System Data

Procedure

To export system data:

1. On the Configuration tab, navigate to Initial System Data. The Initialize DB screenappears

2. Under Export Data, select the desired system data.

Initial Data – This data consists of all configuration data of the system when first set.It includes all values and flags that were initially set.

Connector – This data includes connector information for all systems (SAP, non-SAP, LDAP, etc) that were configured.

Roles – This data includes all roles that were created and imported to the system.

Role export does not export role attributes. Role attributes must exist in thesystem before roles can be imported.

Workflow Configuration – This data includes all information from Initiator, CustomApprover Determinator, Stage, Path, Approvers, and the like.

User Defaults – This data includes all mappings, values, and attribute settings.

HR Triggers – This data includes all actions, rules, field mappings, and associatedvalues and flag settings.

3. Click Export.


Miscellaneous

264 September 2008

Role export does not export role attributes. Role attributes must exist in the systembefore roles can be imported.

The export feature produces several zip files, which you can upload to another AccessControl Compliant User Provisioning system for the initial load of the configuration data ofthat system.

Importing Configuration Settings

Procedure

1. On the Configuration tab of the system you have not yet configured, navigate toConfiguration 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.

MiscellaneousThis section describes the configuration options you can configure from the Miscellaneoustab. On this tab, you can:

Option Description

Allow Role Generation With Violations Configure whether the role can begenerated despite violations. If you set thisoption to No, you cannot generate the roleunless all role violations are resolved.

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

Use Logged-In User Credentials For RoleGeneration

Configure whether the logged-in usercredentials are used during role generation.If you set this option to No, the system usesthe target back-end system user ID andpassword.

Analysis Type Specify a default risk analysis level. If youset this option to Object, the risk analysisdefaults to the Object or Permission level. Ifyou set this option to Transaction, the riskanalysis defaults to the Transaction Code orAction level. You can override the defaultsetting at the time you perform risk analysis.

Allow Editing Org. Level Values ForDerived Roles

Edit organizational level values for derivedroles. If you set this option to No, you cannotedit organizational level values for derivedroles during the authorization data step inthe role creation process.


Miscellaneous

September 2008 265

Option Description

Allow Adding Function To Authorization If you set this option to Yes, it addsauthorization data by retrieving a functionfrom Risk Analysis and Remediation.

Add Objects To a Role Add objects to a role directly during theauthorization data step of the role creationprocess. If you set this option to Yes, thesystem allows you to add objects directly tothe role authorization data. If you set thisoption to No, you can add objects to a roleonly by adding functions and/or transactions.

Ticket Number After Authorization DataChanges

Specify whether you must enter a ticketnumber after making any additions orchanges to the authorization data in a role. Ifyou set this option to Yes, after you saveany additions or changes made to theauthorization data in a role, the systemprompts you for a ticket number. If you setthis option to No, the system does notprompt you for a ticket number.

Allow Editing Role Authorizations in PFCG Configure whether the role can be openedand edited in PFCG. If you set this option toNo, you cannot create or edit the rolethrough PFCG integration.

Upload Directory Set a default folder for all the files uploadedfrom Enterprise Role Management.

Log Level Debuginfowarnerror Allows you to configure the log level.

Default Language Set the default language.

No of Concurrent Background Jobs Limit the number of background jobs thatcan be run concurrently.

Ability To Attach Files To Role Definition Attach files to a role and to set theattachment file size (in KBs).

Procedure

1. On the Configuration tab, navigate to Miscellaneous.

2. From the dropdown list next to each option, select the options.

3. Click Save.

Language Configuration for Enterprise Role Management

When you initially log on to Enterprise Role Management, three fields are displayed on theWelcome screen: User ID, Password, and Language.

Although User ID and Password are required fields, Language is not. Therefore, you must seta default language in the Miscellaneous Configuration screen by selecting the appropriatelanguage from the Language dropdown list and then clicking Save.

You must log off and then log back on again in order for this change to take effect inthe user interface.


Miscellaneous

266 September 2008

In addition, if an end user selects a language from the Language dropdown list on theWelcome screen that differs from the default language specified in MiscellaneousConfiguration, the default language is overridden and the user interface appears in the enduser-selected language.

When the end user logs in using a language from the Language dropdown list on theWelcome screen that differs from the default language specified in MiscellaneousConfiguration, they can use the Create option to create a new object. By default, EnterpriseRole Management shows the default language description and allows the end user to createand modify the object with the corresponding language text.

7 Access Control and Identity Manager Integration

Miscellaneous

September 2008 267

7 Access Control and Identity ManagerIntegrationLarge corporations deal with personnel changes on a daily basis. There can be hundreds ofnew hires, terminations, and role changes on any given day. To handle this volume ofactivity, the IT organization uses an Identity Management (IdM) system to provision users inapplications throughout the enterprise. A typical IdM system has the following features:

User information self-service

Management of (changed and lost) passwords

Workflow

Provisioning and de-provisioning of identities from resources

However, most IdM systems do not provide the complete functionality to enforce governanceand control policies. Some IdM systems lack an approval workflow mechanism and reportingcapability for tracking and auditing purposes.

Access Control can integrate with IdM systems. For instance, you can define policies andSegregation of Duties (SoD) rules for granting access to resources through Access Control.The integration between GRC Access Control and the IdM system ensures that userprovisioning does not introduce unknown risk violations.

Integration involves exposing Web services in both Access Control and the IdM system. Youcan call these Web services from either system to request user provisioning. This extends theIdM system by enabling Compliant User Provisioning. The Web service solution providesproactive enforcement of access policies, especially those that prevent SoD and riskviolations. These Web services can alert you to potential SoD conflicts when assigning rolesto users.

With these Web services, the integration of Access Control and IdM also provides real-timeaccess management as a standard provisioning process across heterogeneous IT systems,as well as greater governance and control over your IT environment.

Access Control is integrated with SAP NetWeaver Identity Manager. To facilitate thisintegration, the following Web services must be supported:

Submit Request (to Access Control)

Select Application

Search Role

Role Details

Request Status

Audit Trail

For more information about configuring provisioning operations for the Submit Request Webservice and search operations for the Audit Trail Web service, see the section Integration withNetWeaver Identity Manager.


Calling Web Services

268 September 2008

Access Control and IdM system integration supports only Service ProvisioningMarkup Language (SPML) 1.0. SPML is the open standard protocol for integration ofservice provisioning requests. SPML is an OASIS standard. The Web services calledfrom Access Control to an IdM system are SPML 1.0 compliant. However, the AccessControl Web services exposed to an IdM system or other application are not SPML1.0 compliant. The diagram below illustrates this point.

Other applications or other supported systems refer to any systemsthat are SPML 1.0 compliant. Non-ERP systems also fall into the categoryof other supported systems.

There are several business reasons for integrating Access Control in order to provision to aheterogeneous environment. Each corporation has its own specific provisioning needs, butthere are three general integration approaches for consideration. These approaches are:

1. Using the IdM system as the leading provisioning system where requests aresubmitted to Access Control for SoD compliance and provisioning to one or moreERP systems. For more information, see the section IdM System as a LeadingProvisioning System.

2. Using Access Control as the leading provisioning system where requests aresubmitted to the IdM system for provisioning to one or more non-ERP systems. Formore information, see the section GRC Access Control provisioning to non-ERPSystems.

3. Using Access Control as the leading provisioning system where requests aresubmitted to other supported systems via SPLM SOAP provisioning requests. Formore information, see the section GRC Access Control provisioning to OtherSupported Systems.

Calling Web ServicesThere are several business reasons for calling the Web services provided by GRC AccessControl. Here are three examples:



September 2008 269

IdM System as a Leading Provisioning System

From the IdM system, you want to request access to an ERP system using the SubmitRequest Web service. This request is submitted to Access Control. Once the request isapproved and provisioned, a status is sent back to the IdM system. You can also call theSubmit Request Web service from Access Control to request a non-ERP system on the IdMsystem. 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. Fromthe IdM system, you can perform specific actions, such as calling the Application Selectionand Role Selection Web services, before calling the Request Submission Web service inAccess Control.



270 September 2008

The following diagram illustrates this interaction.

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



September 2008 271

The following diagram illustrates this interaction.

For configuration steps applicable to this example, see the section Integrating with an IdentityManagement Solution.



272 September 2008

Access Control provisioning to Other Supported Systems via SMPL SOAP

Access Control can provision to other target systems that are SPML SOAP compliant. Likethe previous example, when an event occurs in SAP Human Resources (SAP HR), it triggersa request in Access Control. A request can also be triggered by a self-service creationprocess 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 diagramillustrates this interaction.

For configuration steps applicable to this example, see the section Provisioning to OtherTarget Systems with SPML SOAP Compliant Call.


Access Control and IdM System Integration Architecture

September 2008 273

Access Control and IdM System IntegrationArchitectureThe integration of Access Control and the IdM system is coupled by the ability to call Webservices that are unidirectional and bidirectional. The following diagram illustrates the logicwhen calling the Web services from Access Control or the IdM system.

Figure 1: Access Control and IdM Integration using Web Services

Access Control IdM Web Services are generally unidirectional, but some are bidirectional inthat you can call them either from IdM or from Access Control.


Access Control and IdM System Integration Architecture

274 September 2008

Web Services offered by Access Control and SPML 1.0 Compliant IdM Solutions

The IdM system can call the following Web services: 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 enablesyou to search for roles before submitting a request to Access Control. To refine yoursearch, you can use a filtration function.

o Role Details (SAPGRC_AC_IDM_ROLEDETAILS) - This Web service providesdetailed information about the selected role.

Submit Request (to Access Control) (SAPGRC_AC_IDM_SUBMITREQUEST) - Youuse this Web service from the IdM system for compliant provisioning to AccessControl.

Risk Analysis (SAPGRC_AC_IDM_RISKANALYSIS) - This Web service enables youto perform Segregation of Duties (SoD) analysis. It returns any possible riskviolations.

Audit Trail (includes the Provisioning Log Web service)(SAPGRC_AC_IDM_AUDITTRAIL) - This Web service returns a comprehensiveaudit 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 toAccess Control.

Request Status (SAPGRC_AC_IDM_REQUESTSTATUS) - This Web servicereturns the status and detailed request information for the selected request.

Web Services calls from IdM

Submit Request to IdM (SAPGRC_AC_IDM_SUBMITREQUEST_TO_IDM) - ThisWeb service is called by GRC to submit a request to IdM.

The Web services are called:

When a user is created or changed in an SAP HR system, a new request issubmitted 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 privilegesto perform their job function.

The request might consist of both ERP and Non-ERP applications, therebytriggering a request to the IdM system for non-ERP system while GRCprocesses the request for the ERP systems.

The audit logs and request status can be consolidated by calling the ‘AuditLogs’ and ‘Request Status’ web services.

When a user requests non-ERP system from the GRC End User Form, GRCcalls this service to submit a request to the IdM.


Technical Definitions for Access Control IdM Web Services

September 2008 275

Audit Trail from IDM (SAPGRC_AC_IDM_AUDITTRAIL_FROM_IDM) – This Webservice returns a comprehensive detailed list of audit history. It enables GRC toretrieve the audit logs from IdM (for non-ERP provisioning).

Technical Definitions for Access Control IdM WebServicesWhen 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 ofresources which are available for user provisioning.

For bidirectional integration, the list of resources configured in the IdM system is maintainedin Access Control. Before submitting a request, make sure that the non-ERP resources areconfigured in Access Control.

Function/Method

getSystems (test.types.p2.GetSystems parameters)

Input Parameters

The following table shows the input parameters that are available for your request:

Field Description Possible Value(s)/Example

System Type The resource type indicateswhether the server is an SAPsystem or a non-SAP system.

The default is All.

Example: SAP, Oracle, etc.

Application Type The resources are categorizedby Production, Non-Production,QA, Test, and so on.

The default is All.

Example: Development,Production, Non-Production, QA,Test, etc.

Locale The language in which theinformation is to be returned.

The default is EN.



276 September 2008

Output Parameters

This table shows the output parameters which are part of the returned message response.

Field Example

System ID Q5F

Description Q5F Dev System

System Category Development



September 2008 277

Search Role (SAPGRC_AC_IDM_SEARCHROLES)

You can call this Web service to retrieve a list of roles within a selected source. It includes afiltration capability for refining the search.

Function/Method

getRoles (test.types.p3.GetRoles parameters)

Input Parameters

This table shows the input parameters that are available for your request:


Application * The name of the applicationserver that has the given roleinformation.

There is no default.

Example: VA6

Access Type * The criteria to use whilesearching. Roles – You can search

by role name anddescription.

Transaction Code –Enter the exacttransaction code of therole search.

Create Account Like –Enter a role or account tocreate a new accountthat is similar to anexisting account.


Possible Values: Roles,Transaction Code, CreateAccount Like

Business Process The name of the businessprocess which is used for therole search.

The default is All.

Example: Finance

Sub Process (Sub Processfor the selected BusinessProcess)

The name of the businesssubprocess which is used forthe role search.

The default is All.

Example: Account Payable

Role Name The name of the role usedfor the role search.

The default is All.

Example: Z_AP_Accountant

Role/Profile Description The description of the rolename used for the rolesearch.

The default is All.

Example: Accountant Role

Functional Area The functional area of therole used for the role search.

The default is All.

Example: Finance Payables

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

The default is All.

Example: SAP

Transaction



278 September 2008

(Applicable for Access Type > Transaction Code only)

The transaction code of theuser is entered in thisparameter if roles aresearched using transactioncode.

The default is All.

Example: FB01

User Info Group(Applicable for Access Type > Create Account Like only)

User ID The ID of the user whoseroles are displayed.


Example: CPerkins

Applicable for all Access Types

Locale The language in which theinformation is returned.

The default is EN.

Hit Count The count of the roleinformation retrieved at atime.

The default is 100.

Example: 40

Parameters marked with an asterisk (*) are required fields. The Web service fails if thecorrect value is not entered.

Output Parameters

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

Field Example

Application VA6

Role Name Z_AP_CLERK

Role Type Single

Role Description Role Z_AP_CLERK

Valid From 05/07/1998

Valid To 06/03/2017

Lead Owner Brian Law



September 2008 279

Role Details (SAPGRC_AC_IDM_ROLEDETAILS)

You can call this Web service to retrieve the detailed description of the selected role.

Function/Method

roleDetails (test.types.p2.RoleDetails parameters)

Input Parameters



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


Example: Z_AP_Accountant

System The name of applicationserver that has the given roleinformation.

The default is All.

Example: CRM


The default is EN.

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


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

List



280 September 2008

Role Approver

Alternate Approver

Brian Law

Cheryl Jones

List Functional Area Finance Payables

List Company SAP

List Functional Area and

Company ApproverMark Horsten

List Transaction Code F-02



September 2008 281

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



Request Type * Refers to existingconfigured request types inthe Compliant UserProvisioning. It is used todetermine what actions areperformed to process therequest.


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

Priority * Iindicates the severity ofthe submitted request.

The default is HIGH.

Example: HIGH, MEDIUM,LOW

Applications * The name of theapplication server in whichthe user is provisioned orthe requested action isperformed.


Example: CRM

User Info Group (retrieves details from selected resources) User ID * The unique ID of the

person for whom you arerequesting access.


Example: mwong

User Name * (FirstName and LastName)

The name of the person forwhom you are requestingaccess.


Example: Mae Wong

Email * The e-mail address of theperson for whom you arerequesting access.


Example:[email protected]

Telephone Number The telephone number ofthe user for whom you arerequesting access.


Example: 16501367006

Department The department of the userfor whom you arerequesting access.


Example: Accounting

Location The location of the user forwhom you are requestingaccess.


Example: Palo Alto

Company The company name of theperson for whom you arerequesting access.


Example: SAP



282 September 2008

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


Example: NEW

Requestor Info Group (these parameters must match the existing data in the targetauthentication system)

Requestor ID * The unique ID of the userwho is submitting therequest.


Example: sjones

Requestor Email * The e-mail address of theuser who is submitting therequest.



Requestor Name * The name of the personwho is submitting therequest.


Example: Sandra Jones

Telephone Number The telephone number ofthe person who issubmitting the request.


Example: 16505551212

Manager Info Group (these parameters must match the existing data in the targetauthentication system)

Manager ID *

The Manager IDparameter is mandatoryonly if the workflow path isat the ‘Manager’ stage.

The unique ID of themanager of the user who issubmitting the request.


Example: BFAUST

Manager Name (FirstName and LastName)

The name of the managerof the user who issubmitting the request.


Example: Bill Faust

Manager Email The e-mail address of themanager of the user who issubmitting the request.



Manager Telephone This is the manager’stelephone number.


Example: 650 847-2000

Request Reason The reason for requestingaccess for the desired roleis entered in this field.


Example: New employee

SNC Name This parameter is the nameof the Secure NetworkCommunication (SNC).You use the SNC value forSingle Sign-On to systemsthat run in an ABAPenvironment and use SAPGUI as the front-end client.

Example:

CN=I801018, 0=SAP-AG,C=DE



September 2008 283

unsecurelogon If this field is set to True,the user can log on withouthaving a default SNCname for authentication.

Example:

True/False

validfrom This field indicates thevalidity start date for auser.

Example:

07/03/2009

validto This field indicates thevalidity 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 thatcontains the roleinformation.


Example: VA6

Role ID The role ID of thesubmitted request.


Example: Z_AP_Clerks Add/Remove Action This determines what

action is performed for therole (for example, add orremove the role for theuser)

Example: ADD, REMOVE,KEEP

Valid From This indicates the rolevalidity start date for auser. The date when theuser can start using therole.

Example: 07/03/2009

Valid To This indicates the rolevalidity end date for a user.The date when the usercan no longer use the role.

Example: 09/05/2020

Custom Fields Info Group Field Name The name of the additional

custom field defined byyour corporate policy.


Example: Region

Value The value of thecorresponding additionalcustom field defined byyour corporate policy.


Example: EMEA


Output Parameters




284 September 2008

Field Example

Request Number 1001

Status Open



September 2008 285

Risk Analysis (SAPGRC_AC_IDM_RISKANALYSIS)

You can call this Web service to perform Segregation of Duties (SoD) analysis aftersubmitting a request. You select specific roles and then check for any possible risk violationwhen 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 optionaland vice versa.


Request ID * The unique identificationnumber of an existingrequest.


The IDs of existing requestsare possible values.

Example: 1002

User ID * The unique ID of the user tobe provisioned.


Example: mwong

System * The name of the applicationserver where risk analysis isexecuted.


Example: CRM


The default is EN.

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

This Web service call fails if any of the fields for Request ID, System, and User ID arenot provided.



286 September 2008

Output Parameters


Field Example

TCodeDetails Role Description

System

Transaction codedescription

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 andinitiate payment to vendor

HIGH

CRM

FK01, FB01

2

Risk Analysis Results Critical Tcode PFCG



September 2008 287

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 therequest was created, who submitted it, and who approved it. All the provisioningservice activity performed in Access Control is logged in the audit trail.

When calling the Audit Logs Web service from Access Control, it returns theprovisioning 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



Request ID The unique identificationnumber of existing request.

Request ID of alreadysubmitted request.

Example : 1002

User Info Group (retrieves details from selected resources) User ID The unique ID of the user

for which audit information isretrieved.

Example : mwong

User First Name The first name of the userfor which audit information isretrieved.

Example: Mae

User Last Name The last name of the userfor which audit information isretrieved.

Example: Wong

From Date The starting date when theaudit information isretrieved.

Example: 05/03/2008

To Date The end date when the auditinformation is retrieved.

Example : 05/22/2008

Action This is the status of therequest.

Possible values are: OPEN,HOLD, REJECT, CLOSED,CANCEL.


The default is EN.

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



288 September 2008

Output Parameters


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

3485Note: This is the parent ID for the actionbeing performed.

Q5F

Request 1002 Submitted by SandraJones(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 beingperformed.



September 2008 289

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 thestatus of the request within the IdM system.

Function/Method

getStatus (test.types.p2.GetStatus parameters)

Input Parameters



Request ID * The unique identificationnumber of the submittedrequest whose status isreturned.

Example: 1002


The default is EN.


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 comprisingMessage Type, Message Code, and Message Description.


Integrating with an Identity Management Solution

290 September 2008

Integrating with an Identity Management SolutionYou can integrate Access Control with an IdM solution by performing configuration steps inthe Compliant User Provisioning capability of Access Control.

The procedures in this section describe the integration approach when Access Control is theleading provisioning system where provisioning requests are submitted to the IdM system.For more information, see the section Access Control as a Leading Provisioning System forthe business case.

You also must perform configuration steps in the IdM solution. However, these steps varyfrom vendor to vendor. Therefore, this section does not provide specific configurationinformation required for the IdM system.

The following diagram shows the configuration workflow required in Access Control tointegrate with an IdM system:


Defining Connectors for IdM Systems

September 2008 291

Defining Connectors for IdM Systems1. Go to Compliant User Provisioning > Configuration > Connectors > Create Connector.

The Connectors screen appears.

2. In the Connector Type dropdown menu, select IDM.




6. In the Web Service URI field, enter the URI address of the Web service in the IdM.

7. In the User ID and Password fields, enter the user ID and password for the applicationserver using this connection. The user ID must have the appropriate role to performtechnical configuration tasks.

8. (Optional) In the System Language field, enter the system language of the target IdMsystem. If no language is selected, this field defaults to the language of the target IdMsystem.

9. In the Connector Category dropdown menu, select the type of connector category(Production, Non-production or Other).

10. For the IdM system integration, obtain a copy of the SPML Schema file (an XML file). Youmust physically obtain a copy of the SPML Schema file from the IdM vendor. This filecontains action names and their required parameters. This 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 thecorresponding actions of Access Control. For example, if an action is defined as anObject Class in the IdM schema, map it as:

Create User:OC = BasicUser (where BasicUser is the name of the ObjectClassDfinitionin 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 theExtendedRequestDefinition in the IdM schema).

The following table shows the parameters required to configure an IdM connector. Theseparameter values vary from one IdM vendor to another depending on the schema:



292 September 2008

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 provisioningworkflow – the default is Sync)

For more information on Async/Sync., see the sectionSending Provisioning Request to an IdM System.

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

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

Lock User LOCK_USER:EXT Name of the object class /extended request forlocking users defined in the IdM schema – Forexample, disableUser.

Unlock User UNLOCK_USER:EXT Name of the object class /extended request forunlocking users defined in the IdM schema – Forexample, enableUser.

Assign Roles ASSIGN_ROLES:OC Name of the object class /extended request forassigning role defined in the IdM schema – Forexample, BasicUser.

Password Reset RESET_PASSWORD:EXT Name of the object class /extended request forresetting user password defined in the IdM schema– For example, resetUserPassword.

11. Click Save.


You must create a connector for each resource that is configured in the IdM system.

Setting the Field MappingYou can maintain a map of the IdM fields that correspond to the Access Control fields. Toconfigure the field mapping between Access Control and the IdM system, do the following:

1. Go to Compliant User Provisioning > Configuration > Field Mapping > Provisioning. ClickCreate.

2. The Field Mapping screen appears. In the Group Name field, enter a name for the groupof connectors.


4. In the Connector Type dropdown menu, select IDM.

5. Click the Add icon to activate the dropdown menu for the Application field and select thedesired application connector defined for the IdM system.



September 2008 293

6. Click Default to indicate that this connector is the default.

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

8. Click the Add icon to display the dropdown menu where you can select a name of thefield for Access Control and Application (these are the IdM fields) in order to map thefields.

Example:Access Control Field Application Field

Email Address - STANDARD email

User FName - STANDARD firstname

User ID – STANDARD accountId

User LName -STANDARD lastname

9. Click Save.

Importing RolesYou must import all roles for the IdM source to Access Control. These roles are thenassigned to users when the Assign Roles Request Web Service is submitted to the IdMsystem. 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. The ImportRoles screen appears.

2. Click Download Template and save the RoleImport.xls file to your local drive. This is atemplate 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.

5. Click Browse to navigate to your role file (RoleImport.xls).

6. If you want to overwrite any existing role file with the same name, select the OverwriteExisting Roles indicator.

7. Click Import.


Sending Provisioning Request to an IdM System

294 September 2008

Sending Provisioning Request to an IdM SystemAfter configuring Access Control to the IdM system, a provisioning request is sent fromAccess Control. Based on the action map of parameter, PROV_CALL (set as eitherasynchronous or synchronous); the provisioning request can take one of the two possibleprocess flows. The diagram below illustrates how a provisioning request is sent to an IdMsystem to access a non-ERP application:

When a provisioning request is submitted in Access Control and the connector parametersetting PROV_CALL is set to asynchronous, the Submit Request Web service is immediatelycalled without processing in the approval workflow. The provisioning request is submitted tothe 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 approvalworkflow. Approving the provisioning request triggers an SPML SOAP provisioning request,

September 2008 295

which is submitted to the IdM system for processing within the provisioning workflow. TheSPML SOAP request is submitted to the IdM system to perform the following operations:

New Account (Create User)

Change User

Delete User

Lock/Unlock User

Assign/Remove Roles

Password Reset

The IdM system immediately returns a response message to Access Control beforeprocessing the provisioning request.

Both the SPML SOAP provisioning request and the Submit Request Web service are SPMLrequests that groups its operations in a batch. Access Control always sends a serviceprovisioning request as a batch. The batch request is for grouping of requests and isprocessed as a batch job. The batch request provides both synchronous and asynchronousprocessing of the request. The batch request will contain all the request types that you havedefined 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: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>

296 September 2008

</dsml:attr>

<dsml:attr name="resources">

<dsml:value>LDAP</dsml:value>

</dsml:attr>

<dsml:attr name="options.AllowPasswordGeneration">

<dsml:value>true</dsml:value>

</dsml:attr>

</spml:attributes>

</spml:addRequest>



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



</spml:identifier>

</spml:deleteRequest>



<spml:extendedRequest>

<spml:operationIdentifieroperationIDType="urn:oasis:names:tc:SPML:1:0#GenericString">

<spml:operationID>disableUser</spml:operationID>

</spml:operationIdentifier>

<spml:attributes>



</dsml:attr>

</spml:attributes>

</spml:extendedRequest>



<spml:extendedRequest>

Provisioning to Other Target Systems with SPML SOAP Compliant Call

September 2008 297

<spml:operationIdentifieroperationIDType="urn:oasis:names:tc:SPML:1:0#GenericString">

<spml:operationID>enableUser</spml:operationID>

</spml:operationIdentifier>

<spml:attributes>



</dsml:attr>

</spml:attributes>

</spml:extendedRequest>



<spml:modifyRequest>



</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 SPMLSOAP Compliant CallAccess Control can provision to other systems that are SMPL SOAP compliant. Theintegration is similar to that used with an IdM or SAP Enterprise Portal.

The procedures in this section describe the integration approach when Access Control isprovisioning to other supported systems. For more information, see the section AccessControl 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 varyfrom system to system. Therefore, this section does not provide specific configurationinformation required for the target system.

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.



298 September 2008

2. The Connectors screen appears. In the Connector Type dropdown menu, select Others.




6. In the Web Service URI field, enter the URI address of the SPML SOAP provisioningrequest.

7. In the User ID and Password fields, enter the user ID and password for the applicationserver using this connection. The user ID must have the appropriate role to performtechnical 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). Youmust physically obtain a copy of the SPML Schema file from the IdM vendor. This filecontains 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 thecorresponding 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 theObjectClassDfinition 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 theExtendedRequestDefinition in the schema).

The following table shows example parameters for the connector configuration. Theseparameter 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 – Forexample, 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 theIdM schema – For example, BasicUser.

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

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



September 2008 299

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

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

Password Reset RESET_PASSWORD:EXT

Name of the object class /extended request for resettinguser password defined in the IdM schema – For example,resetUserPassword.

11. Click Save.


Setting the Field MappingYou can maintain a map of the IdM fields that correspond with the Access Control fields. Thisconfiguration is performed in Compliant User Provisioning. To configure the field mappingbetween Access Control and the target system:

1. Go to Compliant User Provisioning > Configuration > Field Mapping > Provisioning. ClickCreate.

2. The Field Mapping screen appears. In the Group Name field, enter a name for the groupof connectors.


4. In the Connector Type dropdown menu, select Others.

5. Click the Add icon to activate the dropdown menu for the Application field and select thedesired application connector defined for the target system.

6. Click Default to indicate that this connector is the default.

7. Click Continue.

A schema request is sent to the target system to retrieve all the parameter fieldsdefined in the schema.

8. The field mapping screen for Access Control Fields and Application Fields appears. Clickthe Add icon to display the dropdown menu where you can select a name of the field forAccess 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

9. Click Save.



300 September 2008

Importing RolesYou must import all roles for the IdM source to Access Control. These roles are thenassigned to users when the Assign Roles Request Web service is submitted to the IdMsystem. The role file is in a tab-delimited format.

1. Go to Compliant User Provisioning > Configuration > Roles > Import Roles. The ImportRoles screen appears.

2. Click Download Template. Save the RoleImport.xls file to your local drive. This is atemplate for you to enter all of your role information for your organization.

3. Save your changes. You can rename it, if desired.

4. Enable the From File radio button.

5. Click Browse to navigate to your role file (RoleImport.xls).

6. If you want to overwrite any existing role file with the same name, select OverwriteExisting Roles.

7. Click Import.


Integration with SAP NetWeaver Identity Manager

September 2008 301

Integration with SAP NetWeaver Identity ManagerThis section contains integration information for configuring:

Provisioning Operations that are used for the Submit Request Web service to theNetWeaver Identity Manager.

Search Operations that are used for Audit Trail Web service called from theNetWeaver Identity Manager.

Provisioning Operations

Depending on the nature and capabilities of the system, there are two execution modes forprovisioning operations: asynchronous and synchronous

SAP NetWeaver Identity Manager is an asynchronous system. The following steps outlinethe processing of provisioning request in asynchronous mode1. Provisioning request is sent to Identity Services

The SPML request contains field requested. Typically, the requestor sets the valuefor this field.

2. Identity Services accepts the request and returns the preliminary approval to therequestor

Identity Services extracts the requestID from the request. If the value is not given bythe requestor, the Identity Services generates a new value. The SPML response tothe requested field are set to this value.

Information about all subsequent processing of the request are stored together withthe 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 soforth.

Occasionally, the requests are retry operations due to error conditions.

4. The requestor checks for the status of its provisioning request using the requestID valuementioned above.



302 September 2008

Adding person entry

Operation properties Key Value / DescriptionOperation SPML Add operationDN The unique id of the entry to be added. It is

stored in the mskeyvalue attribute in theIdentity Store

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

Example

SPML requestSupplied identifier: Simple UserSupplied attributes and values givenname=Simple,

sn=User,objectclass=MX_PERSON

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

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



September 2008 303

Modifying person entry

Operation properties Key Value / DescriptionOperation SPML Modify operationDN 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 UserSupplied attributes and values: initials=SU

[email protected],telephonenumber=+4711223344

<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 / DescriptionOperation SPML Delete operationStarting point The unique id of the entry to be deleted.

Example

SPML requestSupplied 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">

mailto:[email protected]



304 September 2008

<spml:id>Simple User</spml:id> </spml:identifier></spml:deleteRequest></SOAP-ENV:Body>


Search Operations

September 2008 305

Search OperationsChecking the Result of Update Operation

Since SAP NetWeaver Identity Manager operates in asynchronous mode, the requestor mustregularly check the status of each provision operation by executing a special Identity Serviceoperation.

Operation Properties

Key Value / DescriptionOperation SPML Search operationStarting point operation= auditlogSearch type not relevantAttributes 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 Valuerequestoperation The original update operation

whose status is checkedadd, modify, delete

requestuserid The user ID (mskeyvalue) ofthe entry which was updated

requestid The request ID for operationtaskname The name of the task that is

executed as a result of therequest.

taskid The ID of the task that isexecuted as result of therequest.

operationstatus The status of the operation OK, Error, Task initiated etc.timestamp Date/time when the status of

the audit entry is updatedmessage Additional message about

the state of the request.Typically explanatory errormessage is shown here

mskey mskey of the entry that wasthe source of the operation inquestion

auditid The ID of the object in theaudit table

ExampleSPML request

Supplied identifier: auditlog (special IDS operation)


Search Operations

306 September 2008

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><dsml:attr name="idsid">


Search Operations

September 2008 307

<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, SPMLdoes not offer the possibility to list multiple entries, but rather returns base level information,for example, information about a single entry. Identity Services implements additionaloperations to list multiple entries.

Listing multiple entries


Key Value / DescritpionOperation SPML Search operationStarting point operation=listSearch type not relevantAttributes requested * OR any attribute subset (see available

attributes below)Filter The following must be present in the filter:

(objectclass=MX_PERSON). In addition thefilter can contain any valid filtering based onobjects’ attributes

Detailed Search on Single Person


Key Value / DescriptionOperation SPML Search operationStarting point The unique id of the entry to be listed.Search type not relevantAttributes requested Or any valid attribute subsetFilter (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></spml:searchRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>Example SPML response


Search Operations

308 September 2008


Search Operations

September 2008 309

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><spml:id>cn=SimpleUser,ou=nwidm1,o=ids</spml:id></spml:identifier><spml:attributes><dsml:attrname="sn"><dsml:valuetype="xsd:string">User</dsml:value></dsml:attr><dsml:attrname="objectclass"><dsml:valuetype="xsd:string">MX_PERSON</dsml:value></dsml:attr><dsml:attrname="mskeyvalue"><dsml:value type="xsd:string">SimpleUser</dsml:value></dsml:attr><dsml:attr name="mskey"><dsml:valuetype="xsd:string">167</dsml:value></dsml:attr><dsml:attr name="mx-disabled"><dsml:value type="xsd:string">1</dsml:value></dsml:attr><dsml:attrname="givenname"><dsml:valuetype="xsd:string">Simple</dsml:value></dsml:attr></spml:attributes></searchResultEntry></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><spml:id>cn=SimpleUser,ou=nwidm1,o=ids</spml:id></spml:identifier><spml:attributes><dsml:attrname="sn"><dsml:valuetype="xsd:string">User</dsml:value></dsml:attr><dsml:attrname="objectclass"><dsml:valuetype="xsd:string">MX_PERSON</dsml:value></dsml:attr><dsml:attrname="telephonenumber"><dsml:valuetype="xsd:string">+4711223344</dsml:value></dsml:attr><dsml:attrname="mskeyvalue"><dsml:value type="xsd:string">SimpleUser</dsml:value></dsml:attr><dsml:attr name="mskey"><dsml:valuetype="xsd:string">167</dsml:value></dsml:attr><dsml:attr name="mx-disabled"><dsml:value type="xsd:string">1</dsml:value></dsml:attr><dsml:attrname="initials"><dsml:valuetype="xsd:string">SU</dsml:value></dsml:attr><dsml:attrname="mail"><dsml:valuetype="xsd:string">[email protected]</dsml:value></dsml:attr><dsml:attrname="givenname"><dsml:valuetype="xsd:string">Simple</dsml:value></dsml:attr></spml:attributes></searchResultEntry></spml:searchResponse></SOAP-ENV:Body>

Appendix A: Rule File Templates

Business Process Template

310 September 2008

Appendix A: Rule File TemplatesThis appendix describes the templates that upload SoD rules, critical actions, and criticalpermissions. You must use the format specified in these templates when you load rules. Youcan name your rule loading files anything you want, but use a naming convention that letsyou identify which file contains which type of data. It is important to identify the system in thefile name for function_action and function_permission files. For more information,see the section Rule Uploads.

Business Process TemplateBusiness Process: ALL_business_processes.txt

Field Type Data Length

BUSINESS PROCESS ID CHAR 4

LANGUAGE CHAR 2

DESCRIPTION CHAR 120

Function TemplateFunctions : 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 SystemC = Cross System

Function-Business Process Relationship TemplateFunction—Business Process Relationship: ALL_function_bp.txt


FUNCTION ID CHAR 8



Function-Action Relationship Template

September 2008 311

Function-Action Relationship TemplateFunction—Action Relationship: <SYSTEM>_function_action.txt


FUNCTION ID CHAR 8

TRANSACTION CHAR 20

STATUS NUMC 1 0=ENABLED

1=DISABLED

Function-Permission Relationship TemplateFunction—Permission Relationship: <SYSTEM>_function_permission.txt


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


1=DISABLED

To load critical permission rules using the function-permission relationship, youcan 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 criticalpermission type rule, enter ^!S_BDC_MONI in the t-code field of this file.

Rule Set TemplateRule Set: ALL_ruleset.txt


RULE SET ID CHAR 8

LANGUAGE CHAR 2

RULE SET DESCRIPTION CHAR 132


Risk Definition Template

312 September 2008

Risk Definition TemplateRisk Definition: <SYSTEM>_risks.txt

Field Type Data LengthValue Description

RISK ID CHAR 4

FUNCTION 1 ID CHAR 8






PRIORITY NUMC 1 0=Medium

1=High

2=Low

3=Critical


1=DISABLED

RISK TYPE CHAR 1 1=SoD

2=Critical Action

3=Critical Permission

Risk Description TemplateRisk Description: <SYSTEM>_risks_desc.txt


RISK ID CHAR 4

LANGUAGE CHAR 2

RISK DESCRIPTION CHAR 132

DETAIL DESCRIPTION CHAR 1000

CONTROL OBJECTIVE CHAR 1000


Risk to Rule Set Relationship Template

September 2008 313

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


RISK ID CHAR 4

RULE SET ID CHAR 8

Appendix B: Data Mapping Templates for Non-RTA Supported Systems

User File Template

314 September 2008

Appendix B: Data Mapping Templates forNon-RTA Supported SystemsWhen 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 toAccess Control. Tab-delimited text files are supported for uploading to Risk Analysis andRemediation.

User File TemplateThis 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 atthe end of the file.

User File Template

Field

DataFieldType

FieldSize

FieldValues Sorting Req'dDescription Transformation

USERID String 50 CAPS SortAscending

Yes User ID Unique recordsonly

FNAME String 50 Yes First name (ifnot available,repeat User IDhere)

LNAME String 50 Yes Last name (ifnot available,repeat User IDhere)

EMAIL String 250 No Email address

PHONE String 40 No Phone number(leave blank ifunavailable)

DEPARTMENT String 40 No Department

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


User Action File Template

September 2008 315

User Action File TemplateUser Action File Template

Field

DataFieldType

FieldSize


USERID String 50 CAPS SortAscendingOrder 1

Yes User ID Unique record =The combination ofcolumns 1–3 (UserID, Roles, andAction From) mustbe unique

ROLES String 49 CAPS SortAscendingOrder 2

Yes Access RoleName

ACTIONFROM String 50 CAPS sortAscendingOrder 3

Yes User Action

ACTIONTO String 50 CAPS Yes User Action,onlyapplicable ifUser Actionhas rangeFrom/To

If this value doesnot exist for thesource system,leave blank

PROFILE String 50 CAPS Yes Action Profile,if applicable.If not, repeatRole Namefield.

If this value doesnot exist for thesource system,repeat ROLE fieldfrom column 2

COMPOSITEROLE NAME

String 50 CAPS No Compositerole name,leave blank ifnot available.

If this value doesnot exist for thesource system,leave blank.

User Permission File TemplateThis file is required for legacy systems with configurable permission levels.

User Permission File Template

Field

DataFieldType

FieldSize


USERID String 50 CAPS SortAscendingOrder 1

Yes User ID Unique record =The combination ofcolumns 1–3 (UserID, Roles, andAction From) mustbe unique



316 September 2008


Field

DataFieldType

FieldSize


ROLE String 49 CAPS SortAscendingOrder 2

Yes Access RoleName

PERMISSION String 100 CAPS SortAscendingOrder 3

Yes UserPermission(PermissionObject/Field),required ifapplicable

ACTION andPERMISSION fieldthat use | | with nospace in between

PRMGRP String 20 Generateaftersorting

Yes Querygeneratednumericalsequence (1+counter peruser)

Extractor/querygenerates thisvalue. The value isgenerated after thedata is sorted.

FROMVALUE String 50 CAPS Yes PermissionValue

TOVALUE String 50 CAPS Yes Permissionvalue, onlyapplicable ifUser Action hasrange From/To

If this value doesnot exist for sourcesystem, leave blank

PROFILE String 50 CAPS Yes UserPermissionProfile, ifapplicable.

If this value doesnot exist for sourcesystem, repeatROLE field fromcolumn 2

COMPOSITEROLE

String 50 CAPS No Composite rolename, leaveblank if notavailable.

If this value doesnot exist for sourcesystem, leaveblank.

If a single permission in the PRMGRP field contains multiple fields, the PRMGRP valuemust be the same for the different fields, if they are within the same authorization. Usingthe SAP security model as an example, say you have permission F_BKPF_KOA whichcontains two fields, Activity and Authorization Group. If a user has this permission inmultiple roles, each role’s authorization should have the same PRMGRP value for Activityand Authorization Group for F_BKPF_KOA. For example:


Role File Template

September 2008 317

User ID - 12345 - Jane Doe Role A

Authorization Object F_BKPF_KOAField Activity – 01Field Auth Group – AA

Role BAuthorization Object F_BKPF_KOA

Field Activity – 02Field Auth Group – BB

The file layout is:

UserID Role Permission PRMGRP FROMVALUE

12345 Role A F_BKPF_KOA||ACTVT 1 0112345 Role A F_BKPF_KOA||BEGRU 1 AA12345 Role B F_BKPF_KOA||ACTVT 2 0212345 Role B F_BKPF_KOA||BEGRU 2 BB

Role File TemplateThis file is required for non-SAP security structures.

Role File Template

Field

DataFieldType

FieldSize

FieldValues Sorting Req'd Description Transformation

ROLE String 50 CAPS SortedAscending

Yes Access RoleName

ROLEDESCRIPTION

String 100 Yes RoleDescription

Role Action File TemplateThis file is required for non-SAP security structures.

Role Action File Template

Field

DataFieldType

FieldSize


ROLE String 50 CAPS SortAscending/Sort Order 1

Yes Role Name

ACTIONFROM String 50 CAPS SortAscending/Sort Order 2

Yes Role Action

ACTIONTO String 50 No Role Action If this value does notexist for sourcesystem, leave blank.


Role Permission File Template

318 September 2008

Role Action File Template

Field

DataFieldType

FieldSize


PROFILE String 50 CAPS Yes SecurityProfile

If this value does notexist for sourcesystem, repeatROLE field fromcolumn 2

Role Permission File TemplateThe role permission file is required for non-SAP systems that include permission level data.

Role Permission File Template

Field

DataFieldType

FieldSize


ROLE String 50 CAPS SortAscendingOrder 1

Yes Role Name


Object/Field ConcatenateACTION andPERMISSIONfields that use | |with no space inbetween


Yes Querygeneratednumericalsequence (1++counter peruser)



TOVALUE String 50 CAPS Yes Permissionvalue, onlyapplicable ifUser Actionhas rangeFrom/To


PROFILE String 50 CAPS Yes Role Profile, ifapplicable.

If this value doesnot exist for sourcesystem, repeatROLE field fromcolumn 2

Profile File TemplateThis file is required for non-SAP security structures that use Profiles.


Profile Action File Template

September 2008 319

Profile File Template

Field

DataFieldType

FieldSize


PROFILE String 50 CAPS SortedAscending

Yes AccessProfile Name

PROFILEDESCRIPTION

String 100 Yes ProfileDescription

Profile Action File TemplateThis file is required for non-SAP security structures that use Profiles.

Profile Action File Template

Field

DataFieldType

FieldSize


PROFILE String 50 CAPS SortAscending/Sort Order 1

Yes ProfileName

ACTIONFROM String 50 CAPS SortAscending/Sort Order 2

Yes ProfileAction

ACTIONTO String 50 No ProfileAction

If this value doesnot exist for sourcesystem, leaveblank.

Profile Permission File TemplateThe profile permission file is required for non-SAP systems that include permission level data.

Profile Permission File Template

Field

DataFieldType

FieldSize


PROFILE String 50 CAPS SortAscendingOrder 1

Yes Profile Name


Object/Field ConcatenateACTION andPERMISSIONfields that use | |with no space inbetween


320 September 2008

Profile Permission File Template

Field

DataFieldType

FieldSize



Yes Querygeneratednumericalsequence (1++counter peruser)



TOVALUE String 50 CAPS Yes Permissionvalue, onlyapplicable ifUser Actionhas rangeFrom/To


Action Permission Objects TemplateAction Permission Objects Template

Field

DataFieldType

FieldSize


ACTION String 20 CAPS SortAscendingOrder 1

Yes Action


Yes Permission

ACTVT String 10 CAPS Yes PermissionObject Field

FROMVALUE String 50 CAPS Yes PermissionObject FieldValue

TOVALUE String 50 CAPS No PermissionObject Value


Description File Templates for Action, PermissionFields, and Values (ACT_PRM_FLD_VAL File)The ACT_PRM_FLD_VAL file loads descriptive text for actions, permissions, fields, andvalues. All values are included in one table, and the text is identified by the text in the second


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

September 2008 321

field of the table, which should be ACT for actions, PRM for permission, FLD for field values,and VAL for the value description. If rules are not required at the permission level, only Actiontext is required in this file.

Sample File

Action Template

This table shows the format for the action description section of the ACT_PRM_FLD_VALdescription file.

Action Template

Field

DataFieldType

FieldSize

FieldValues SortingReq'dDescription Transformation

Leave Blank Mandatory field.Required byload format

Leave Blank

ACT 3 CAPS Hard code ACTas value for thisfile

Hard codedvalue ACT

Leave Blank Mandatory field.Required byload format

Leave Blank

TCODE String 50 CAPS Yes Action SortedAscending

EN 2 CAPS Hard code ENas value for thisfield

Hard codedvalue EN

TCODEDESCRIPTIONS

String <100 Yes ActionDescription

Permission Template

This table shows the format for the permission section of the ACT_PRM_FLD_VALdescription file.

Permission Template


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

322 September 2008

Field

DataFieldType

FieldSize

FieldValues SortingReq'd Description Transformation

Leave Blank Mandatoryfield. Requiredby load format

Leave Blank

PRM 3 CAPS Hard codePRM: as valuefor this file

Hard codedvalue PRM

Leave Blank Mandatoryfield. Requiredby load format

Leave Blank

PERMISSION String 50 CAPS Yes Permission SortedAscending

EN 2 CAPS Hard code ENas value for thisfield

Hard codedvalue EN

PERMISSIONDESCRIPTIONS

String <100 Yes PermissionDescription

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

Field Template

Field

DataFieldType

FieldSize


Leave Blank Mandatoryfield.Required byload format

Leave Blank

FLD CAPS Hard codeFLD: asvalue forthis file

Hard coded valueFLD

ACTVT String 50 CAPS Yes Mandatoryfield.Required byload format

Leave Blank

PERMISSION/PERMISSIONVALUE

String <100 CAPS Yes Permissionobject field

If this field doesnot exist for thesource system,use hard codedACTVT in thiscolumn

EN 2 CAPS Hard codeEN as valuefor this field

Hard coded valueEN


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

September 2008 323

Field Template

Field

DataFieldType

FieldSize


OBJECT FIELDDESCRIPTION

String <100 Yes PermissionObjectDescription

Value Template

This table shows the format for the VAL_DESCR section of the ACT_PRM_FLD_VALdescription file.

Value Template

Field

DataFieldType

FieldSize



Leave Blank

VAL CAPS Hard codeVAL: asvalue for thisfile

Hard coded value VAL


Leave Blank

PERMISSION/PERMISSIONVALUE

String <100 CAPS Yes Permissionvalue field

ConcatenatePERMISSION ANDPERMISSION VALUEfields with hard coded/. Insure that no spaceis added before andafter / character

EN 2 CAPS Hard codeEN as valuefor this field

Hard coded value EN

PERMISSIONVALUEDESCRIPTION

String <100 Yes PermissionValueDescription

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal

Creating an iView

324 September 2008

Appendix C: Configuring Risk Analysisand Remediation for SAP Enterprise PortalYou can retrieve master data from the SAP Enterprise Portal, which is a component of theSAP NetWeaver J2EE engine. Risk Analysis and Remediation is configured to connect toSAP Enterprise Portal through Web services, which in turn call the real-time agent (RTA) toretrieve master data.

Before you install the RTA, sap.com~grc~ccsapeprta.sda, you must install the SAPEnterprise Portal component on the SAP NetWeaver J2EE engine and configure it forRisk Analysis and Remediation.


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 iViewAn iView is an executable unit in the SAP Enterprise Portal content of SAP NetWeaver. InRisk Analysis and Remediation, it is equivalent to an action in the SAP system. An iViewallows 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 NetWeaverdocumentation on SAP Help Portal at http://help.sap.com.

Creating an iView RoleAn 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


Assigning an iView to a Role

September 2008 325

iView ID Role1_ID

ID Prefix (leave blank)

Master Language English

Description text description

Assigning an iView to a RoleAfter 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. Rightmouse click to display the dropdown menu. An iView can be added to a role either byDelta 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 RiskAnalysis and Remediation.

Retrieving Master DataThe master data is a list of text objects to be uploaded for Risk Analysis and Remediation.

Procedure

To retrieve the master data:

1. Open the SAP NetWeaver Portal and select Web Services Navigator.

Example: Go to http://<localhost>:5300/wsnavigator/enterwsdl.html

The Web Services Navigator screen appears.

2. In the Available Web Services Cluster Node, find the Web service, CCRTAWS and clickTest.

The CCRTAWS Web services test page appears and displays a list of operationmethods.

3. Click getMasterData.

The hierarchical tree for getMasterData appears.

4. Verify the folder name is correct.

5. Enter the full path to a server with a filename.

6. Click Send. A success message appears.

You can verify that the master data is retrieved by going to the file that you defined. Thisfile is a text object data and contains the master data. You can then upload the masterdata to Risk Analysis and Remediation.


Verifying Portal RTA

326 September 2008

Verifying Portal RTAThe Portal Real-Time Agent (RTA) that you must deploy on your NetWeaver J2EE server issap.com~grc~ccsapeprta.sda. After deploying this component, verify that is it correctlyinstalled 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

c. The CCDebugger screen appears. In the Debugger dropdown menu, select theconnector that you defined for the portal.

d. In the Object Type dropdown menu, select the user/role.

e. In the Object ID fields, enter an asterisk (*) for a wildcard search.

f. Click Search Obj.

g. In the search results pane, a list of users from the User Management Engine or rolesfrom the portal server appears. This confirms that the connectors are workingproperly.

Creating a Function in Risk Analysis and Remediationfor iViewBefore you create a function in Risk Analysis and Remediation, download the Master Datafrom 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:


2. Select the Rule Architect tab.

3. In the navigation bar, click Function > Create. The Create Function screen appears.



September 2008 327

4. Enter information in the following fields:

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

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 thedropdown 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 theiView that you created.

Example: SAPSearch is the iView name.

7. A list of assigned iViews appears along with PCD locations or IDs. Select the requirediView and save the function.

8. On the Permissions tab, the Function Information screen displays the values for thefollowing fields:

Field defaults to PERM

Value From can be Full Control, Owner, Read/Write, Read, None (based on thepermission 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 Risk Analysis and Remediationfor User Management Engine ActionsFor User Management Engine (UME) role-based analysis, you must create function(s) in RiskAnalysis and Remediation. These functions contain UME actions for risk rules generation andsubsequent role assignments.

Before you can create a function, verify that the master data is loaded into the Risk Analysisand Remediation database. If it is not, download the master data from the portal server andupload it to the Risk Analysis and Remediation database.

Procedure

To create a function in Risk Analysis and Remediation for User Management Engine Actions:


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 more information on these fields, see the SAP GRC Access Control 5.3Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User ->


Creating a Function in Risk Analysis and Remediation for User Management EngineActions

328 September 2008

Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC AccessControl 5.3 -> Application Help.

Function ID

Description

Business Process (use the dropdown menu)

Analysis Scope (use the dropdown menu)

5. On the Actions tab, click Add to activate the first field under System. Use the dropdownmenu 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 Architecttab. 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)



September 2008 329

8. In SAP Enterprise Portal, create a role based on the User Management Engine actionsthat you previously assigned for functions. Go to User Administration > IdentityManagement.

For detailed information on these fields, see the SAP Enterprise Portaldocumentation.Example:

Role Name - CC_AE_ROLE

Actions

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 theprevious step. If a risk occurs, then the SoD violation is displayed.

54057AC53_ConfigGuide

Documents

Transcript of 54057AC53_ConfigGuide