Configuration Guide

SAP GRC Access Control

Configuring SAP with Release 5.3
Target Audience System administrators Technology consultants

Document Version 2.10 September, 2008

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

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

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

Disclaimer UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. Any Java Source Code delivered with this product is only to be used HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. Documentation in the SAP Service Marketplace You can find this documentation at the following Internet address: by SAPs Support Services and may not be modified or altered in any way. Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components.

service.sap.com/instguides

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

Icons Icon Meaning Caution Example Note Recommendation Syntax

Example Text

Example text

Example text

<Example text>

EXAMPLE TEXT

Configuration Guide Access Control

Document History
This guide is regularly updated on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3. Make sure you have the latest version of this guide by checking SAP Service Marketplace before starting the installation. The following table provides an overview of the most important changes that were made in the latest versions. Configuration Guide Version 1.00 2.00 2.10 March, 2008 June, 2008 September, 2008 Important Changes Ramp-up release of GRC Access Control 5.3. Release to customers of GRC Access Control 5.3. Quality update revision

September 2008

Table of Contents

Table of Contents 1 Getting Started ............................................................................................... 15

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

Security and Master Data Configuration ............................................................................... 18

3 Risk Analysis and Remediation.................................................................... 20

Risk 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 using JDBC .............................................................................................................................. 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

September 2008

1 Getting Started About this Document 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

September 2008

Table of Contents

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

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

Prior 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

September 2008

1 Getting Started About this Document 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

September 2008

Table of Contents

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

September 2008

1 Getting Started About this Document 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

10

September 2008

Table of Contents

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

Configuring 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 User Provisioning .................................................................................................................. 231 System Landscape Definition ............................................................................................. 232

September 2008

11

1 Getting Started About this Document 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

12

September 2008

Table of Contents

7 Access Control and Identity Manager Integration .................................... 267

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

Business 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

September 2008

13

1 Getting Started About this Document Risk to Rule Set Relationship Template.............................................................................. 313

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

User 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 SAP Enterprise 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 Engine Actions .............................................................................................................................. 327

14

September 2008

1 Getting Started About this Document

1 Getting Started
SAP Governance, Risk, and Compliance (GRC) Access Control provides end-to-end automation for documenting, detecting, remediating, mitigating, and preventing access and authorization risk enterprise wide, resulting in proper segregation of duties, lower costs, reduced risk, and better business performance. Access Control includes the following capabilities: Risk Analysis and Remediation, which supports real-time compliance to detect, remove, and prevent access and authorization risks by preventing security and control violations before they occur. Compliant User Provisioning, which automates provisioning, tests for segregation of duties (SoD) risks, and streamlines approvals by the appropriate business approvers to unburden IT staff and provide a complete history of user access. Enterprise Role Management, which standardizes and centralizes role creation and maintenance. Superuser Privilege Management, which enables users to perform emergency activities outside their roles as privileged users in a controlled and auditable environment. Access Control helps companies comply with the Sarbanes-Oxley Act and other regulatory mandates by enabling organizations to rapidly identify and remove authorization risks from IT systems. It also allows preventive controls to be embedded in business processes to identify and prevent SoD violations from being introduced without proper approval and mitigation.

About this Document

This guide describes how to integrate and configure each of the Access Control capabilities. For more information, see the following sections: GRC Access Control Integration Enterprise Role Management Compliant User Provisioning Risk Analysis and Remediation Superuser Privilege Management You can find the most current information about the implementation of SAP GRC Access Control, and the latest installation and configuration guides, on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3. We recommend that you use the documents available there, since the guides are regularly updated.

Related Information
This section describes topics for planning. Links to reference documentation found on SAP Service Marketplace are also provided. Planning Information For information about planning topics not covered in this guide, see the following content on SAP Service Marketplace:

September 2008

15

1 Getting Started Important SAP Notes Content Latest versions of installation and upgrade guides SAP Business Maps general information about applications, solutions and business scenarios Sizing, calculation of hardware requirements such as CPU, disk and memory resource Released platforms and technology-related topics such as maintenance strategies and language support Network security High Availability Performance Information about Support Package Stacks, latest software versions and patch level requirements Information about Unicode technology SAP Service Marketplace Links The following table lists further links on SAP Service Marketplace: Location on SAP Service Marketplace service.sap.com/instguides service.sap.com/businessmaps

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

service.sap.com/unicode@sap

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

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

Important SAP Notes

To obtain the latest technical information, read the following SAP Notes before you start installation. These notes also contain updates and correction to the installation documentation. The most up-to-date version of SAP Notes is found on SAP Service Marketplace at: service.sap.com/notes.

16

September 2008

1 Getting Started GRC Access Control Documentation

SAP Note Number 1133167 1133168 1133173 1133174 1133165 1133166 1133171 1133172 1133163 1133164 1133169 1133170 1133161 1133162

Title VIRSANH VIRSAHR VIRSANH VIRSAHR VIRSANH VIRSAHR VIRSANH VIRSAHR VIRSANH VIRSAHR VIRSANH VIRSAHR VIRSANH VIRSAHR

Description Installation notes for 530_700 Installation notes for 530_700 Upgrades notes for 530_700 Upgrades notes for 530_700 Installation notes for 530_640 Installation notes for 530_640 Upgrades notes for 530_640 Upgrades notes for 530_640 Installation notes for 530_620 Installation notes for 530_620 Upgrades notes for 530_620 Upgrades notes for 530_620 Installation notes for 530_46C Installation notes for 530_46C

GRC Access Control Documentation

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

September 2008

17

2 GRC Access Control Integration Security and Master Data Configuration

2 GRC Access Control Integration

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

Role data synchronization in Enterprise Role Management: In Compliant User Provisioning, role data synchronization is required for: Roles for provisioning Role usage synchronization for User Access Review

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

Security and Master Data Configuration

When integrating Access Control capabilities, you should plan security and master data proactively to ensure consistent data across the application. Some master data normalization is necessary for the functionality to be effectively integrated. In the section below, this data type is marked as Required. All other data types are best practice recommendations to ensure seamless integration. Security and System Data: Connectors - Create the same connector Name, User ID, and Password for each system in all capabilities.

18

September 2008

2 GRC Access Control Integration Security and Master Data Configuration 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 User This user facilitates communication between the capabilities via Web services. It has to be configured in each capability. - Use the same User ID and Password information from the connector. - Create a common Web user in the User Management Engine for all capabilities. This user is used for all Web service configurations across the capabilities (Required).

This is not the user ID configured in the back-end system connectors; this user ID is configured with the individual Web services for each capability. For information about the authorizations required for your Web user, see the SAP GRC Access Control 5.3 Security Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions 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 target systems. 1. Create the RFC user with User Type Communications Data in the target system(s) and assign administration authorizations for all applications. 2. Assign appropriate RFC authorization.

For information about the authorizations required for your RFC, see the SAP GRC Access Control 5.3 Security Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions 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 in Enterprise Role Management and Compliant User Provisioning (Required). Functional Area (Functional Area ID field in ERM must exactly match the Functional Area Name field in CUP) Business Process (Business Process ID field in ERM must exactly match the Business Process Name field in CUP) Subprocess (Subprocess ID field in ERM must exactly match the Subprocess Name field in CUP) Role owner in ERM should be the same as role approver in CUP Other key fields are not used by the applications as key integration fields to synchronize data. To avoid confusion for business users, however, create them with consistent descriptions.

September 2008

19

3 Risk Analysis and Remediation Security and Master Data Configuration

3 Risk Analysis and Remediation

Risk Analysis and Remediation is a Web-based, automated security audit and segregation of duties (SoD) analysis application. It uses custom tables to store SoD data. You use Risk Analysis and Remediation to identify, analyze, and resolve all SoD and audit issues relating to regulatory compliance. You can perform risk analysis to identify risks associated with a user, role, profile, or human resources (HR) object. For risks that cannot be eliminated, you define mitigating controls. You also define monitors and approvers, assign them to specific controls, and create business units to categorize the controls. This section describes how to configure Risk Analysis and Remediation (a front-end tool), as well as Risk Terminator (a back-end tool). Configuration is required: After a new installation of Risk Analysis and Remediation After an upgrade of Risk Analysis and Remediation To conduct routine administrative tasks The Configuration tab provides controls, which allow you to define and manage Risk Analysis and Remediation. Since this tab is displayed only for users with administration permissions, the information in this section is not relevant for all users. The Configuration tab does not provide settings for Risk Terminator. Configuration impacts the behavior of many Risk Analysis and Remediation functions and features. Therefore, you must work closely with security and user administrators, as well as business process owners to determine the required settings and definitions. You can use Risk Analysis and Remediation configuration to: Specify default settings for users who perform risk analysis with the Informer tab Tune the system to optimize your usage and network environments Determine how data is used in Risk Analysis and Remediation reports Access the functions of the Configuration tab through its navigation menu. For more information, see the following sections: Risk Analysis Mitigating Controls Workflow Miscellaneous MIC User Mapping MIC Risk Mapping Connectors Logical Systems Cross Systems Master User Source User Mapping Custom User Groups

20

September 2008

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

Risk Analysis Configuration

This section describes the options available under Risk Analysis on the Configuration tabs navigation bar. Default Values Parameter / Purpose Default Report Type This option determines the default report type populated when executing a Risk Analysis. Options Action Level Permission Level (default) Critical Actions Critical Roles/Profiles Mitigation Controls Default Risk Level This option determines the default risk level populated when executing a Risk Analysis. All (default) Critical High Medium Low Default User Type This option determines the default user type included when executing a Risk Analysis. All Dialog (default) System Communication Service Reference Default Rule Set This option determines the default rule set used when executing a Risk Analysis. All defined rule sets are available

September 2008

21

3 Risk Analysis and Remediation Risk Analysis Configuration

Parameter / Purpose Exclude Locked Users This option specifies whether locked users are excluded when executing a Risk Analysis. For information on the lock codes or user flags and how to include or exclude certain values, see SAP Note 1013217. Exclude Expired Users This option specifies whether expired users are excluded when executing a Risk Analysis. Exclude Mitigated Risks This option specifies whether risks with assigned mitigating controls are excluded when executing a Risk Analysis. Performance Tuning Parameter Batch Size for User Synchronization Purpose

Options Yes (default) No

Yes (default) No Yes (default) No

This setting specifies the number of users to synchronize at once or in one batch. To improve performance, increase the value. Be aware, however, that increasing thevalue too much can cause timeouts to occur during synchronization.

Number of Web Services Worker Threads

This setting specifies the number of server threads to dedicate to Web service calls, such as calls from the Risk Analysis Engine. If you experience risk analysis performance issues, consider increasing this thread allocation.

Number of Background Job Worker This setting specifies the number of server threads to Threads dedicate for background jobs. If background job operations slow performance, consider increasing this thread allocation. If you schedule multiple background job processes to run simultaneously, these operations might be delayed until another background job completes. RFC Time-out for Web Services / Background Job Worker Threads This setting specifies in minutes the timeout value for remote function calls. The amount of data you process and the number of threads you allocate can affect whether you experience RFC timeouts during Web service or background job operations. Additional Options Parameter Purpose

22

September 2008

3 Risk Analysis and Remediation Risk Analysis Configuration

Parameter Ignore Critical Roles and Profiles

Purpose This setting determines whether roles and profiles maintained in the Critical Roles and Profiles tables are ignored when user risk analysis is performed. The default is No.

Show Composite Role in User Analysis Use SoD Supplementary Table for Analysis

This setting determines whether composite role names are displayed when risk analysis is performed. This setting determines whether the SoD supplementary table is checked when risk analysis is performed. If no supplementary rules are maintained, this parameter must be set to No to avoid incorrect results in Risk Analysis.

Include Role/Profile Mitigating Controls in User Analysis

This setting determines whether role-based or profile-based mitigating controls are included in user-based Risk Analysis reports. The risk analysis includes user-level mitigating control IDs, if they exist. If not, the report displays either the role-based or profile-based mitigating control ID (in that order). If you set this option to Yes, the mitigation flows to the risks mitigated at the role/profile level (regardless of whether the user has the risk from that role or from additional roles). The default value is No.

Enable Offline Risk Analysis

This setting allows Risk Analysis to be performed without real-time communication with a back-end system and uses data from the Batch Risk Analysis for reporting. Enabling offline analysis results in faster response times for Risk Analysis reports.

Consider Organizational Rules

This setting determines whether to consider organizational rules when updating the Management Reports of the Informer tab and during the Risk Analysis Web service call. If no organizational rules are maintained, this parameter must be set to No to avoid incorrect results in the Risk Analysis. The default value is No.

Convert Users, Roles and Profiles to Upper Case

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

September 2008

23

3 Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

Parameter Include Reference User when doing User Analysis

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

Show all objects in Risk Analysis

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

Enable monitor notification

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

Show Selection Criteria

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

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

Workflow Integration with Compliant User Provisioning

Risk Analysis and Remediation integrates with Compliant User Provisioning for: Approval of risk updates Approval of mitigation control updates Approval of mitigating control assignments Workflow Configuration in Risk Analysis and Remediation Workflow configuration allows you to specify the conditions under which workflows are triggered. Risk Analysis and Remediation supports Compliant User Provisioning workflows only. The table below lists the workflow parameters and their purpose:

Parameter

Purpose

24

September 2008

3 Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

Parameter Risk Maintenance

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

Mitigation Control Maintenance

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

Mitigation

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

Workflow Service URL

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

Workflow Configuration in Compliant User Provisioning To configure Compliant User Provisioning for approval workflow, you must upload the append files from installation of Risk Analysis and Remediation. Procedure To configure for approval workflow:

September 2008

25

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

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

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

Priorities: o o o MC_HIGH Mitigating Control MO_HIGH Mitigation Object RS_HIGH - Risk

2. Configure request types for Risk Analysis and Compliant User Provisioning integration. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Request Type c. Select a request type and click Change. The Create Request Type screen appears.

d. Select Active. e. Click Save. The table below lists the request types that are available: Request Types MITICTRLC MITICTRLD MITICTRLU Description Create Mitigating Control Delete Mitigating Control Update Mitigating Control

26

September 2008

3 Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

MITIOBJC MITIOBJD MITIOBJU RISKC RISKD RISKU

Create Mitigation Object Delete Mitigation Object Update Mitigation Object Create Risk Delete Risk Update Risk

Create Mitigation Object means assigning a mitigating control. Delete Mitigation Object means removing the assignment of a mitigating control. Update Mitigation Object means modifying a mitigating control assignment. 3. Configure request priority. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Priority c. Select a priority and click Change. The Modify Priority screen appears.

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

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

d. Click Save. The table below lists the request attributes that are available: Request Attribute Name Priority Priority Priority Request Type Request Type Request Type Workflow Type Mitigation Control Mitigation Object Risk Mitigation Control Mitigation Object Risk

September 2008

27

3 Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

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

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

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

Initator Name CC_MITCTLRL_INT

Description For mitigating control changes, configure the initiator CC_MITCTRL_INT. When mitigating controls are created, updated or deleted, a request is sent from Risk Analysis and Remediation to Compliant User Provisioning via a Web service to trigger workflow approval of the change.

CC_MITOBJ_INT

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

28

September 2008

3 Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning

CC_RISK_INT

For changes to risk definitions, configure the initiator CC_RISK_INT. When risks are maintained, a request is sent from Risk Analysis and Remediation to Compliant User Provisioning via a Web service to trigger workflow approval of the change to the risk.

7. Configure custom approver determinators. Custom approver determinators (CADs) determine the path for routing the approval request. You must create a CAD for each Risk Analysis and Remediation workflow type. Compliant User Provisioning does not require a CAD for a workflow within itself, but you must create one for Risk Analysis and Remediation workflow integration. a. Log on to Compliant User Provisioning with administrator privileges. b. Go to Configuration tab > Workflow > Custom Approver Determinators. c. For Risk Analysis and Remediation workflow integration, create a CAD for mitigating control assignment approval. This CAD is used for users, roles, and profiles mitigation change approver. Use the following parameter values: Name (example) CC_MITOBJ_CAD CAD Type Attribute Workflow Type Mitigation Control Assignment Select the appropriate attributes for the custom approver determination. You can select additional attributes to differentiate approvers for different processes. For example, you can assign different approvers for each Request Type. d. Create another CAD for Risk Analysis and Remediation. This is for the mitigating control maintenance approver. Name (example) CC_MITCTRL_CAD CAD Type Attribute Workflow Type Mitigation Control Select the appropriate attributes for the custom approver determination. You can select additional attributes to differentiate approvers for different processes. For example, you can assign different approvers for each Request Type. e. Create another CAD for Risk Analysis and Remediation risk maintenance approver. Name (example) CC_RISK_CAD CAD Type Attribute Workflow Type Risk Select the appropriate attributes for the custom approver determination. You can select additional attributes to differentiate approvers for different processes. For example, you can assign different approvers for each Request Type. f. In the Select Attributes pane, identify the characteristics of the request or the users that determines the approver to receive the workflow request. For example, Business Process is used to segregate approvals between different business process owners.

September 2008

29

3 Risk Analysis and Remediation Workflow Integration with Compliant User Provisioning g. In the Select Role Attributes pane, identify the characteristics of the role(s) on the request that determines the approver to receive the workflow request. For example, the criticality of the role is used to require additional approval for high sensitivity roles. h. Select the Approvers option to identify the primary approver and the alternate approver for each Request Type. 8. Configure workflow stage. You can create workflow stages for the following workflow types: Mitigation Control Assignment Mitigation Control Risk Maintenance For more information, see the section Workflow Creation Process. 9. Configure workflow paths. The workflow paths must be configured for all Risk Analysis and Remediation workflows. A path defines the steps that are followed when a workflow is triggered for the initiators that were configured in the previous step. Create each path with Number of Stages equal to one (1) and the paths in Active status. Name CC_MITCTRL CC_MITOBJ CC_RISK Workflow Type Mitigation Control Mitigation Control Assignment Risk Initiator CC_MITCTRL_INT CC_MITOBJ_INT CC_RISK_INT Stage 1 CC_MITCTROL CC_MITOBJ CC_RISK

For more information, see the section Creating Main Paths. 10. Configure exit URI for all integration workflow types. You must configure Exit URIs for all integration workflow types. All workflow types have the same functionality. a. Log on to Compliant User Provisioning > Configuration tab > Miscellaneous. The Miscellaneous Configuration screen appears. b. In the Workflow Types pane, add the Exit URI for the appropriate capabilities in the Name field. For Risk Analysis and Remediation using mitigating control, mitigating object, and risk, add the exit URI: http://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?w sdl&style=document Example: http://iwdfvm2363:51000/VirsaCCWFExitService5_2Service/Config1 ?wsdl&style=document

30

September 2008

3 Risk Analysis and Remediation Miscellaneous c. Enter the User Name and Password.

d. Select Active.

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

Management of Internal Controls

You can integrate Risk Analysis and Remediation with SAP Management of Internal Controls (MIC). SAP MIC supports the implementation and documentation of regulatory processes and controls, as well as the assessment of internal controls performed by Risk Analysis and Remediation. The path mappings related to the SAP MIC controls can also be accessed through the Configuration tab. MIC Destinations in the MIC System Configuration for Destinations in MIC is not available on the Access Control Configuration tab. To enable Risk Analysis and Remediation to work with SAP MIC, you must configure the Exchange Infrastructure (XI) communication system and connect it to the system where MIC is located. You must then perform the following steps on the system where MIC is running: 1. Create HTTP destination for master data query: Transaction SM59

September 2008

31

3 Risk Analysis and Remediation Management of Internal Controls RFC Destination <MICMasterDataQuery> VIRSAQUERY Type G Target Host <HostNameofXiSystem> ld0141.wdf.sap.corp Service No <PortNumberOfXiSystem> 54100 Path Prefix /XISOAPAdapter/MessageServlet?version=3.0&channel=:<ServiceName>: <ChannelName> /XISOAPAdapter/MessageServlet?version=3.0&channel=:mic_test: SENDER_REQUEST Use basic authentication with User ID and Password (xiappluser, xipass) 2. Create the HTTP destination for test logs: Transaction SM59 RFC Destination <MICTestLog> VIRSALOG Type G Target Host <HostNameofXiSystem> ld0141.wdf.sap.corp Service No <PortNumberOfXiSystem> 54100 Path Prefix: /XISOAPAdapter/MessageServlet?version=3.0&channel=:<ServiceName>: <ChannelName> /XISOAPAdapter/MessageServlet?version=3.0&channel=:mic_test: SENDER_NOTIFICATION Use basic authentication with User ID and Password (xiappluser, xipass) 3. Create default logical port for master data query proxy. Transaction lpconfig 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

32

September 2008

3 Risk Analysis and Remediation Management of Internal Controls Point to HTTP destination created in step 2 - VIRSALOG 5. Create Risk Analysis and Remediation parameters. 60 - MIC RE Post Result for Orgs with no issue (Yes/No) Yes 61 - MIC Interface RFC System ID (if Interface and Risk Analysis and Remediation are in different systems VIRSAXIPROXY 62 MIC Printer ID (for PDF creation) LP01 6. Create RFC destination for Web as 640 / 700 (in case of different systems). Transaction SM59 VIRSAXIPROXY Create RFC destination type 3 with same name as parameter 61 of step 5. 7. Create user map. Transaction /VIRSA/MICCONFIG 8. Create risk map. Transaction /VIRSA/MICCONFIG 9. Schedule job or execute program for automated test. Schedule job for program /VIRSA/MICTESTEX. 10. Schedule job or execute program. /VIRSA/MICDATASYNC MIC User Mappings MIC user mappings map MIC controls to Risk Analysis and Remediation objects. This integrates operations with MIC systems that you want to include in your compliance analysis. You can manually map remote MIC object data or import MIC user mapping information. To manually map remote MIC object data: 1. Navigate to Configuration > MIC User Mappings > Create. 2. Specify the system that contains the user information. 3. Specify the MIC Org ID, Process ID, and Control ID that you want to map. 4. Specify the Risk Analysis and Remediation object type that you want to map to (User, User Group, Org Level, or HR Org). 5. Specify the Map Value. 6. Click Save. 7. To import MIC user mapping information: Navigate to Configuration > MIC User Mappings > Create. 8. Click Import. Use the MIC User Mapping search to verify that the user map was successfully imported. MIC Risk Mappings MIC risk mappings map MIC controls to Risk Analysis and Remediation objects. This integrates operations with MIC systems that you want to include in your compliance analysis. You can manually map remote MIC control IDs or import MIC user mapping information. To manually map remote MIC object data:

September 2008

33

3 Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation 1. Navigate to Configuration > MIC User Mappings > Create. 2. Specify the system that contains the Control ID. 3. Specify the Control ID that you want to map. 4. Specify the Risk ID that you want to map to the Control ID. 5. Click Save. 6. To import MIC user mapping information: Navigate to Configuration > MIC User Mappings > Create. 7. Click Import. 8. Use the MIC User Mapping search to verify that the user map was successfully imported. To ensure that Risk Analysis and Remediation is synchronized with the back-end system, schedule a periodic job to update this information.

Defining Connectors for Risk Analysis and Remediation

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

System Type SAP

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

Oracle

JDBC JDBC SLD Web Service

Legacy

File Local File - FTP

PEOPLESOFT

JDBC JDBC SLD Web Service

JD Edwards

JDBC JDBC SLD Web Service

34

September 2008

3 Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation

Portal

Web Service

The connector configuration procedures in this section are examples of each of the system types with a commonly used connector type. Access Control communicates with multiple systems. SAP recommends using HTTPS 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 Java Connector (SAP JCo). SAP recommends that you use the more efficient Adaptive RFC for your first 21 connectors. If you need more than 21 connectors, use SAP JCo. Because of the difference in efficiency, consider using the 21 Adaptive RFC JCos for higher-volume or production environments.

To complete the Create Connectors screen, obtain the information from your network administrator. 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 are connecting. The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 3. In the System Type dropdown menu, select SAP for the system. 4. In the Connection Type dropdown menu, select SAP JCO. The screen selections change according to the selected connection type. For SAP JCo, a new configuration screen appears with additional fields. You can create additional JCo connectors to connect multiple SAP systems to a single Risk Analysis and Remediation landscape. 5. In the Host Name field, enter the host name of the system. 6. In the User ID field, enter the SAP user name. 7. In the Client ID field, enter the SAP client ID number. 8. In the System Number field, enter the number in the SAP system log. 9. In the Language field, enter the system language. 10. In the Logon Group field, enter the group name associated with the user ID. 11. In the SAP Gateway field, enter the back-end systems gateway name for each instance or group of application servers of the SAP ERP system. 12. In the Report Name field, create a unique external program name, such as GRCRTTOCC5X.

September 2008

35

3 Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation 13. Select the Outbound Connection Flag checkbox to enable the connector for Risk Terminator. 14. Select the Unicode System Flag checkbox to designate that the back-end SAP ERP system is a Unicode system. 15. Click Save. Verifying JCo Connectors 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 actions to log on. 3. Select Content Administrator. 4. Select Check SLD Connection. 5. For Check Connection to the SLD, select Test Connection. Maximize the main window so you can view the status message that appears at the bottom of the window. 6. On the Content Administrator screen, select Maintain JCo Destinations. Verify that you have created proper JCo destinations for each SAP target system and for the associated SAP client. 7. Click Test to test each Java connection. A message appears at the bottom of the screen indicating the test was successful. Configuring Connectors for an Oracle, PEOPLESOFT, or JD Edwards System using JDBC To complete the Create Connectors screen, obtain the information from your network administrator. Procedure To configure connectors for Oracle, PEOPLESOFT, and JD Edwards: 1. Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. 2. In the System field, enter the system ID of the new system to which you are connecting. 3. In the System Name field, enter the name of the new system to which you are connecting. The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 4. In the System Type dropdown menu, select Oracle. 5. In the Connection Type dropdown menu, select JDBC connection. 6. In the Driver Name field, enter the name of the JDBC driver. 7. In the URL field, enter the directory path of the WSDL. 8. In the User ID field, enter the user ID for the Oracle system.

36

September 2008

3 Risk Analysis and Remediation Defining Connectors for Risk Analysis and Remediation 9. In the Password field, enter the password associated with the User ID. 10. Click Save. Configuring Connectors for a Legacy system To complete the Create Connectors screen, obtain the information from your network administrator. Procedure To configure a connector for a legacy system: 1. Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. 2. In the System field, enter the system ID of the system to which you are connecting. 3. In the System Name field, enter the name of the new system to which you are connecting. The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 4. In the System Type dropdown menu, select Legacy. 5. In the Connection Type dropdown menu, select one of the following: File-FTP connection. In the FTP URL field, enter the directory path of the file transfer protocol location. File-Local connection In the Location field, enter the directory path of where the files will be stored. For data extraction, there are three folders that are needed in the directory: IN, OUT and EXP. The connector path should reference the OUT folder.

The location where the files are stored must be in a directory that the application is mounted to. We recommend that the files are stored directly on the application server that hosts the Access Control application. 6. In the User ID field, enter the user ID for the Legacy system. 7. In the Password field, enter the password associated with the User ID. 8. Click Save. Configuring Connectors for a Portal using a Web Service To complete the Create Connectors screen, obtain the information from your network administrator. Procedure To configure a connector for a Portal: 1. Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. 2. In the System field, enter the system ID of the new system to which you are connecting. 3. In the System Name field, enter the name of the new system to which you are connecting.

September 2008

37

3 Risk Analysis and Remediation Logical Systems

The connector names are important when integrating with other GRC capabilities and the CUA. Verify that the connector name for Access Control is the same as the one configured for CUA. 4. In the System Type dropdown menu, select Portal . 5. In the Connection Type dropdown menu, select the Web Service. 6. In the URL field, enter the URL link for the wsdl file, CCRTAWS. Enter the following address into your Web browser: http//<server_name>:<instance>/CCRTAWS/Config1?wsdl&style=document server_name is the name of your J2EE system instance is the instance of your J2EE engine Example: http://p168081.wdf.sap.corp:51000/CCRTAWS/Config1?wsdl&style=document or http://10.66.162.120:5100/CCRTAWS/Config1?wsdl&style=document The server name is where the Portal RTA is installed. You may need to specify the IP address of the server name if the server name is not supported for a specific J2EE engine. 7. In the User ID field, enter the user ID of the system administrator. 8. In the Password field, enter the password for the User you entered in the previous step. 9. In the Server Name field, enter the IP address of the server. 10. In the Port Number field, enter the port number for the server. 11. Click Save. For more information on configuring Risk Analysis and Remediation for the SAP Enterprise Portal, see Appendix C, Configuring Risk Analysis and Remediation for Enterprise Portal.

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

38

September 2008

3 Risk Analysis and Remediation Logical Systems When you create functions in Rule Architect, you can create or delete an action or permission and assign it to a specific system. You can define a function action against a logical system and a physical system. When you define or modify a logical system, you must regenerate rules for all the risks of that logical system so that the rules specific to each physical system are updated in the database. You generate rules on the Logical Systems > Generate Rules screen. Updating a particular risk only requires updating the rules for that risk and, therefore, does not require access to the Configuration tab. Example The following example describe the relationship between physical systems and logical systems, when rules or functions are applied separately to both. You define a logical system, PROD consisting of physical system, PR1 and physical system, PR2, where the two instances are SAP ERP systems. You can update the two physical systems with transaction codes which make up the rules. For instances, you can update PR1 and PR2 with the transaction code FB01 with the same permission by specifying the logical system, PROD. In another instances, the transaction code, ZFB01 has an extra permission that you want to add in PR1. You can specify the physical system PR2 so that only the physical system is updated with ZFB01 and the permission. In this case, the logical system is not updated with ZFB01. Defining a logical system streamlines the rule definition process. For this reason, you see logical systems you have created from within Rule Architect, but you do not see these logical systems when running Risk Analysis. Physical systems take precedence over logical systems. If a physical system grouped within a logical system holds one or more rules specific to that system, the system checks the physical system rule first. Creating a Logical System Procedure To create a logical system: 1. On the Configuration tab, navigate to Logical Systems > Create. 2. Create a logical system, and assign its physical systems. 3. Use Rule Upload to upload function_actions and function_permissions for the logical system. For more information, see Appendix A, Rule File Templates. 4. Generate rules by navigating to Logical Systems > Generate Rules on the Configuration tab. You must load permission and text data for at least one physical system by navigating to Configuration > Upload Objects. If you define a logical system and load text for multiple physical systems, the logical systems text and authorizations are used when updating function data. Text loaded for the first system listed in the logical system definition is used as the logical system text. You use the permission and text data when you manually update functions. Use the text data to populate the descriptions in the analysis reports.

September 2008

39

3 Risk Analysis and Remediation Cross Systems Loading Rules against a Logical System 1. After creating a logical system, load rules against the logical system. For more information, see the section Uploading the Function Authorization Text Files. 2. When uploading the files, select the logical system as the system name. 3. After uploading the data, generate the rules for the logical system by navigating to Logical Systems > Generate Rules on the Configuration tab. When generating rules for the logical system, you do not see rules for the individual physical systems within the logical system. The rules are created at the logical system level only. Example You load the global rules against physical system A and generate all the rules. You then create a logical system that contains both physical system A and physical system B. You then reload all of the actions/permissions against the logical system and generate the rules. The system generates the rules for the logical system, but since you also have the rules for physical system A, those rules also still exist. If a system is contained within a logical system but has rules built against the physical and logical systems, the physical system takes precedence.

Cross Systems
A cross system is two or more physical systems grouped together so you can perform user analysis operations across multiple systems. You can select and view cross systems when you generate and view Informer Management Reports or perform Risk Analysis. Physical systems, logical systems, and cross systems share the following relationships: You can link one physical system to one or more logical systems. You can link one physical system to one or more cross systems. You can perform risk analysis against one system or all systems. To do so, you must define two or more systems as a cross system. With a subset of systems defined as a cross system and available in the System dropdown list, you can perform analysis operations against one physical system, all physical systems, or a selected cross system. When you define or modify a cross system, you must regenerate the rules for all the risks, so the system-specific rules can be updated in the database. You generate rules by navigating to Cross Systems > Generate Rules. Updating a particular risk only requires updating the rules for that risk and, subsequently, does not require access to the Configuration tab. Example You define a cross system ID, XFINANCE consisting of physical system, ERP1 and physical system, ORA2, where the two instances are an SAP ERP system and an Oracle application server, respectively. The ERP1 system is solely used for buying services from vendors, whereas ORA2 system is for paying vendors. The two systems can use different transaction codes. You can perform risk analysis in a cross system, where risk analysis determines access in each system defined in a cross-system risk to determine if the risk exists. Creating a Cross System Procedure To create a cross system: 1. Navigate to Configuration Cross Systems > Create.

40

September 2008

3 Risk Analysis and Remediation Cross Systems 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 and reconciles and unifies that data in Risk Analysis and Remediation format.

For legacy systems, you must extract the data to a file first, then use Risk Analysis and Remediation to upload it. For more information, see the following sections: Appendix B: Data Mapping Templates for Non-RTA Support Systems Running the Comparison Utility Configuring Connectors for a Legacy System Administration for Non-RTA Supported Systems Creating a Data Extractor Procedure 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 data files. 3. In the Object dropdown list, select the object data you want to import. You must repeat these steps for each object: User, Role, and Profile. When you select an object, that object name appears on the first tab. The dropdown lists available on all three tabs are customized to display the options that apply to your selection. For example, when you select the Role object, the title of the first tab is Role. The Target Fields are associated with the Role object. 4. In the Data Extraction dropdown list, select Flat File. Only the Flat File mode is supported. 5. On the User, Actions, or Permissions tab, enter the file name in the File Name field. This file contains the data you want to import to GRC Access Control. For example, the file for user objects. The location (application server path) where these files are stored must be defined in the Connector. 6. In the File Type dropdown menu, select Delimited. 7. In the Delimiter field, enter \t. This specifies a tab-delimited output file. 8. (Optional) If you must add more field names for the Target Field and Source Field, highlight the field where you want the new field and select the icon. To remove a field in the Target Field and Source Field, highlight the field and click the icon.

September 2008

41

3 Risk Analysis and Remediation Cross Systems In the Source Field column, enter the output file number to specify the field order of the extracted output. For example, if you entered 5 as the Source Field value for the USERID, Risk Analysis and Remediation uploads the data in column 5 from your text file as the USERID. The Data Extractor order must exactly match the order of the data in your extracted flat file. 9. Click Save. Extracting User and Role Data in a Background Job Use the Extract Background mode to load the data into Risk Analysis and Remediation. You want to load each file (user, roles, and permissions) separately. Procedure 1. Go to Risk Analysis and Remediation > Configuration tab > Data Extraction > Search. The Search Extractor screen appears. 2. In the System field, enter your legacy system. 3. In the Object dropdown list, select the object data you want. 4. Click Search. 5. In the Systems and Data Extractors screen, select a data extractor, and click Change. 6. In the Change Data Extractor screen, accept all of the defaults, and select Extract Background. 7. The Upload Extractor Data screen appears. Select the checkboxes for User, Actions, or Permissions. If the system contains permission-level records that you want to extract, select Permissions. 8. Select Upload. 9. In the Schedule Background Job screen, enter a Job Name. 10. Click either Immediate Start or Delayed Start. For an Immediate Start, the start date and time is grayed out. For Delayed Start, enter the desired start date and time. 11. To schedule this job to run periodically, click Schedule Periodically. 12. Select either Daily, Weekly, or Monthly and enter the number of times you want the job to run for that period. 13. In the End Date field, enter a date to end the job. You can use the Calendar icon to set the date. 14. Click Schedule. Read the status line message underneath the navigation bar to verify that the job is scheduled. Running the Comparison Utility Use this information to compare and load changes from your non-RTA system. The security environment constantly changes due to adding, modifying, and deleting users. Therefore, it is recommended to frequently re-extract data from your legacy system and reload it into Risk Analysis and Remediation. When re-extracting and reloading the definition files, ensure that the file names remain the same. Save these new files into the IN folder. For more information, see the following sections: Configuring Connectors for a Legacy System

42

September 2008

3 Risk Analysis and Remediation Master User Source Administration for Non-RTA Supported Systems Procedure

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

Master User Source

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

September 2008

43

3 Risk Analysis and Remediation User Mapping

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

If a single user ID always represents the same user, regardless of the source system, you do not need to map users.

Custom User Groups

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

CUSTOM_GROUP_A

JSMITH

44

September 2008

3 Risk Analysis and Remediation Upload Objects

CUSTOM_GROUP_A CUSTOM_GROUP_A CUSTOM_GROUP_A CUSTOM_GROUP_A CUSTOM_GROUP_B CUSTOM_GROUP_B CUSTOM_GROUP_B CUSTOM_GROUP_B

TMSMITH RSMITH JJOHNSON BJOHNSON GLOPEZ MWASHINGTON KCHOW ADESALVO

Upload Objects
You load descriptive (static) text and authorization objects for each Access Control capability. For SAP systems, descriptive text comes from various text tables, and the authorization object is SU24/USOBT_C data. You use the Upload Object option to upload objects for different physical systems or for one or more logical systems. The system uses the descriptive text to complete the report output and provide the text descriptions for technical objects, such as transactions, objects, fields, and values. The authorization object data provides default objects, fields, and values for the rule architect. If you create a function, the permissions for each action default to the data in the last authorization object file upload. These default permissions are also included if you add an action to an existing function. To ensure that Risk Analysis and Remediation is synchronized with the back-end system, schedule a periodic job to upload the object files. Uploading Static Text Procedure 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 to the right of the Local File field to navigate to the desired directory, and name the file. For easy access, store the file on your desktop and name it SAPText.txt. 4. Click Execute. 5. Return to Risk Analysis and Remediation, select the Configuration tab, and navigate to Upload Objects > Text Objects. 6. Complete the following fields:

September 2008

45

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

Uploading Authorization Objects Procedure 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 located to the right of the Local File field to navigate to the desired directory, and then name the file. For easy access, store the file on your desktop, and name it SAPAuthObj.txt. 4. Click Execute. 5. Return to Risk Analysis and Remediation, and navigate to Configuration > Upload Objects > Authorization Objects. 6. In the Local File field, enter the specified path (or browse to the location), and specify SAPAuthObj.txt. 7. Click the button to execute this process in the background or foreground. To execute this job in the background, the text file must be stored on an application server. For more information, see the following sections: Uploading Static Text Uploading Authorization Objects

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

46

September 2008

3 Risk Analysis and Remediation Rule Upload and BASIS rules for SAP ERP systems independently, if desired. Action rules are included for 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 system connectors before you can upload rules to systems. For example, if you want a specific CRM system to be analyzed for SoDs and critical access, you must establish the connector to that system before you can upload rules for that CRM system. Similarly, to monitor a Business Intelligence (BI) system for BASIS activities, you must establish the connector to that system before you can upload the BASIS rules for that BI system. You can also create custom rules and rules for legacy systems. Format the rules according to the standard formats. For more information, see Appendix A, Rule File Templates. Save all of the delivered text files to the same directory. Load the text files in the same order as the tree structure. You can expand the Rule Upload submenu to display these available options: Business Process Function Function Authorization Rule Set Risk Generate Rules For more information, see the following sections: Uploading a Business Process Text File Uploading the Function Text Files Uploading the Function Authorization Text Files Uploading a Rule Set Text File Uploading the Risk Text Files Scheduling Rule Generation Uploading a Business Process Text File Procedure 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:

September 2008

47

3 Risk Analysis and Remediation Rule Upload 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 the SAP ERP rules are loaded against a system, the SAP BASIS and HR files are not loaded since their rules are included in the overall SAP ERP file. Load SAP BASIS and HR files only on systems that do not have the full SAP ERP rules loaded. Procedure To upload function authorization files: 1. On the Configuration tab, navigate to Rule Upload > Function Authorization. 2. From the System dropdown list, select the system for which you want to load the functions 3. In the Function Action field, browse for the file [SYSTEM]_function_action.txt. 4. Click Open. 5. In the Function Permission field, browse for the file [SYSTEM]_function_permission.txt. 6. Click Open. 7. Click Upload. 8. Repeat this procedure for each system that requires loaded rules. Uploading a Rule Set Text File Procedure To upload a rule set text file: 1. On the Configuration tab, navigate to Rule Upload > Rule Set. 2. In the File Location field, browse for the file [ALL]_Ruleset.txt. 3. Click Open. 4. Click Upload. Uploading Risk Text Files Procedure To upload the risk text files: 1. On the Configuration tab, navigate to Rule Upload > Risk. 2. In the Risk field, browse for the file [SYSTEM]_Risk.txt. 3. Click Open. 4. In the Risk Description field, browse for the file [SYSTEM]_Risk_desc.txt.

48

September 2008

3 Risk Analysis and Remediation Rule Upload 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.

September 2008

49

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

Back-end Synchronization (with Management of Internal Controls)

When you integrate SAPs Management of Internal Controls (MIC) application with Risk Analysis and Remediation, you must perform a back-end synchronization with MIC. Doing this transfers the mitigation and rule information from Risk Analysis and Remediation to the back-end ABAP stack where the MIC application resides. When defining mitigation information in Risk Analysis and Remediation, you can import the information to the destination system, which is an SAP back-end system where MIC resides. This concept is the same for the rule synchronization, where you define the system rule set in Risk Analysis and Remediation and then import that information to the destination system. Synchronization in the foreground is an immediate import of the mitigation or rule set information, whereas synchronization in the background is a scheduled job that happens at a defined timeframe. Activities You can perform mitigation synchronization and rule synchronization to the back end. Synchronizing Mitigation Procedure To perform mitigation synchronization with the backend: 1. On the Configuration tab, navigate to back-end Sync > Mitigation Sync. 2. Select a Source System from the dropdown list. 3. Select a Destination System from the dropdown list. 4. Select Foreground or Background to synchronize the mitigation with MIC. Synchronizing Rule Procedure To perform rule synchronization with the backend: 1. On the Configuration tab, navigate to back-end Sync > Rules Sync. 2. Select a System Rule Set from the dropdown list. 3. Select a Destination System from the dropdown list. 4. Select Foreground or Background to synchronize the rules with MIC.

Background Jobs
Use Background Jobs to schedule synchronization with back-end systems, batch risk analyses, generation of management reports, and generation of alerts. When you schedule a background job, you can synchronize in Full mode or Incremental mode. Full mode is the synchronization of all user, role, or profile information. Incremental mode means updating only the information about the user, role, or profile that has changed since the last synchronization. Risk Analysis and Remediation keeps track of all synchronization time and date. Therefore, when you want to

50

September 2008

3 Risk Analysis and Remediation Background Jobs synchronize in Incremental mode, Risk Analysis and Remediation knows when the last update occurred and synchronizes only the information that has changed. You can schedule the information synchronization by using the Batch Risk Analysis operation. Here you can also do a Full mode or Incremental mode for the following risk analysis 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 or Incremental. After the initial synchronization, schedule a nightly job to perform an incremental synchronization. Perform a full synchronization periodically as well to ensure data integrity. 4. Select the desired synchronization: User Synchronization Role Synchronization Profile Synchronization 5. Select System or accept the wildcard (*) value to perform synchronization for all connected 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, and indicate the frequency as well as the End Date past which no jobs will execute. 9. Click Schedule to accept your input or Reset to begin again. 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 have changed in the back-end system. Any changes in the front-end system, such as changes to rules or mitigation, are not included. Therefore, SAP recommends that you also run a monthly full batch risk analysis to reflect any front-end changes. Procedure To schedule Batch Risk Analysis: 1. On the Configuration tab, navigate to Background Job > Schedule Analysis.

September 2008

51

3 Risk Analysis and Remediation Background Jobs 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 for batch 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 that analyzes 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. 8. Select Immediate Start, or select Delayed Start and indicate the date and time to begin. If you want to perform the job multiple times, select Schedule Periodically, and indicate the frequency as well as the End Date past which no jobs will execute. 9. Click Schedule to accept your input or Reset to begin again. 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. 4. In the Job Name field, enter a name for this job. 5. Select Immediate Start, or select Delayed Start and indicate the date and time to begin. If you want to perform the job multiple times, select Schedule Periodically, and indicate the frequency as well as the End Date past which no jobs will execute. 6. Click Schedule to accept your input or Reset to begin again. The following message displays: Background job scheduled successfully, Job ID: XX.

52

September 2008

3 Risk Analysis and Remediation Background Jobs Scheduling Alert Generation When you generate an action log, the data is loaded to a local table in Risk Analysis and Remediation. 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 risk analysis. If you select the Consider Mitigated Users option, alerts are generated on user who are associated with a mitigated risk. The generation of these alert types are useful for transaction usage in Segregation of Duties (SoD) Review and User Access Review (UAR). You can also set up a background job for sending alert notification via email based on the alert type. By selecting Conflicting Actions and/or Critical Actions alert types, notifications are sent to Risk Owners. Selecting Control Monitoring alert type sends notification to the Management Approver of the Mitigating Control. Procedure 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 servers that 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 for a particular user do not display in the alerts. Check this option if you want mitigated risks to 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. Control Monitoring notifications are sent to the Management Approver of the Mitigating Control. 8. Click Schedule. The Schedule Background Job screen appears. 9. In the Job Name field, enter a name for this job.

September 2008

53

3 Risk Analysis and Remediation Organizational User Mapping 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 the frequency as well as the End Date. 11. Click Schedule to accept your input or Reset to begin again. Upon completion of scheduling, the following message displays: Background job scheduled successfully, Job ID: XX.

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

Organizational User Mapping

You can perform a risk analysis to identify users who have display or update activity permissions for an organizational level. This type of analysis is dependent on organizational level data for users maintained in Risk Analysis and Remediation. Use Organizational User Mapping to extract and maintain this organizational level data from the back-end source system. By mapping users to organizational level, you create an organizational user mapping table that is used for filtering the user for organizational level analysis. You can then apply organizational rules that filters for certain conditions during analysis. For instance, you have a organizational rule for company code and during the organizational level analysis, only users that have permission to access the company code are considered. Maintaining User Organizational Information Procedure To add or update user information: 1. On the Configuration tab, navigate to Organizational User Mapping. 2. In the System ID dropdown list, select the system that contains the user data you want updated within Risk Analysis and Remediation. 3. In the User selection fields, enter a user range to maintain. 4. To update organizational-level data for all users in the selected system: a. Click Search. 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, click Background to schedule the job(s).

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

54

September 2008

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

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

Utilities
The Utilities options include Export, Import, and Purge Action Usage utilities. Export Utility You can export configuration information for Risk Analysis and Remediation that is defined in one system (source) to another system (destination). The Export utility allows you to select one or many types of data components and transfer them to a define system ID. The functionality of the Export utility is similar to the export tool found in the Rule Architect tab and Mitigation tab, but with different data extract files. The Export utility exports many types of data, including: Configuration Data Connectors

September 2008

55

3 Risk Analysis and Remediation Utilities MIC User Mappings MIC Risk Mappings Logical Systems Cross Systems Data Extraction User Mapping Custom User Groups One exported file is generated for each execution of the Export utility. The export file begins by identifying the source system of the exported records. A metadata record follows the source system and identifies the technical table and field names of the exported data. Data records follow the metadata record. If more than one type of data was exported, there are additional sections, each with a metadata record followed by data records. When you export rules, mitigation, or configuration, dependent tables are included, even if you do not manually select them. Example You want to download User Mitigation. User mitigation entries require a Control ID and Monitor, so those tables are also included in the exported data. Select Get Configuration to generate the data and provide the option to open or save the generated file. Save this file to a location for upload into another system. Import Utility The Import utility imports files exported from other Risk Analysis and Remediation instances. The data format from the exported file is used during the data import. When importing files into another Access Control system, the Import utility loads all tables included in the export. The Import utility does not append these records to existing records; it overwrites all existing entries. As a precaution, if configuration or mitigation records exist in the system to which you are importing new data, export all configuration or mitigation entries from that system as a backup. The system notifies you at the time of loading the data that this process will overwrite all existing entries. The Import utility overwrites all existing entries; it does not append records. If configuration or mitigation records exist in the system where you are importing new data, export all configuration or mitigation entries from that system prior to importing other data. The system notifies you at the time of loading the data that existing entries are overwritten. Purge Action Usage Utility The Purge Action Usage utility archives records from time periods that are no longer of interest. This utility reduces the size of large databases or files. The system stores the purged action usage data in the file location specified during configuration. Purging action usage records affects the SoD Review and User Access Review reports of other capabilities, since they use the database tables. Purging action usage does not impact Risk Analysis and Remediation reports, since they access the archived files in addition to the action usage tables. During configuration, specify the date when you want to retain action usage data and the maximum records allowed in each file. If you schedule a foreground job, a message confirms the date. If you purge the actions in the background, you can schedule a job and determine how frequently to execute it.

56

September 2008

3 Risk Analysis and Remediation Risk Terminator

When you purge data, the system purges the action usage data in the Alert file location specified during configuration. Follow change management procedures prior to purging action logs. Procedure To purge action usage logs: 1. On the Configuration tab, navigate to Utilities > Purge Action usage. 2. In the Purge Records Older Than field, enter the first day for action logs to be retained. For example, if you want to purge files for the prior calendar year, enter January 1 of the current year. 3. Specify the Max. Records per File. 4. Select Foreground or Background execution. Successful foreground execution results in a message that the purge action usage completed successfully.

Risk Terminator
Risk Terminator is a service that resides in the back-end SAP ERP system to notify you when a risk violation occurs. Risk Terminator options are disabled by default. To enable them, configure Risk Terminator according to your requirements. You can configure Risk Terminator to take action when risk violations occur while: Adding transactions to a role with PFCG Assigning user roles with PFCG Assigning roles or profiles with SU01 Assigning roles or profiles with SU10 Risk 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 configuring Risk Terminator. Configuring Risk Terminator Parameters Procedure To set the Risk Terminator configuration parameters: 1. Log on to the back-end ABAP system where security administration is to take place. 2. Start transaction SM59, and create a TCP/IP RFC connection for the RFC Destination of your system. For Connection Type, enter T for Start an external program with TCP/IP. For Activation Type, enter Registration. For Registration Program ID, enter GRCRTTOCC5X.

September 2008

57

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

Enter the name of the RFC destination created previously in transaction SM59. To have Risk Terminator checked when creating or changing roles with PFCG, set this parameter to Yes. To have Risk Terminator checked when assigning a role to a user with PFCG, set this parameter to Yes. To have Risk Terminator checked when assigning a role to a user with SU01, set this parameter to Yes. To have Risk Terminator checked when assigning roles to multiple users with SU10, set this parameter to Yes. To allow role generation and user assignments with SoD violations, set this parameter to No. To force the system to prompt you to enter comments for any SoD violations found when you use transactions PFCG, SU01, or SU10 to generate roles or to make user assignments, set this parameter to Yes. To view comments, see the Log Report.

PFCG User Assignment Plug-In SU01 Role Assignment Plug-In SU10 Multiple User Role Assignment Stop Generation Comments are Required

Send Notification

Determines whether to send notification when service detects a violation.

To have the system send an email to the designated user when a violation is detected, set this parameter to Yes. Doing this displays Risk Owner and Role Owner checkboxes.

Notify Role Owner

Determines whether Role Owner is notified when service detects a violation.

Selecting this checkbox provides email notification to corresponding role owners when Risk Terminator identifies a violation.

58

September 2008

3 Risk Analysis and Remediation Additional Configuration Options Risk Terminator Configuration Parameters Parameter Notify Risk Owner Purpose Determines whether Risk Owner is notified when services detects a violation. Specifies the type of analysis Risk Terminator performs when you click the Change Authorization Data button on the PFCG Authorizations tab. Setting Selecting this checkbox provides email notification to corresponding risk owners when Risk Terminator identifies a violation. This setting determines the level of SoD violations to be reported by Risk Terminator. If you select Object Level Analysis, Risk Terminator reports object (permission)level violations. The report form includes an option to perform action-level analysis and an option to toggle the analysis-level setting each time you generate a report.

Default Analysis Level

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

Additional Configuration Options

Administration for RTA Supported Systems Real Time Agents (RTAs) are required for real-time communication between Access Control and the back-end system. RTAs are also provided for some non-SAP systems. Agents are available from the GRC software download area of SAP Service Marketplace. To request access to them, open a CSS message. Installation guides for these agents are packaged with the software. Administration for Non-RTA Supported Systems You can load user and role data from non-RTA supported (legacy) systems into Risk Analysis and Remediation and include it in risk analysis. To do this, you must export the data from the legacy system and upload it to Risk Analysis and Remediation. You can create or update functions by using the Rule Architect feature in Risk Analysis and Remediation with the legacy actions. These functions are for monitoring rules, which includes legacy actions. Before extracting data from your legacy system, read SAP Note 1131003, which includes tips on using a control file to facilitate the loading of multiple files, how to calculate for extracted files, loading of data files, and using the Comparison Utility tool. Perform these tasks only to include legacy systems in analysis operations. Tasks include creating extractor definitions, user and role mapping, and scheduling background jobs. To have data included in the analysis, you must extract data from the relevant systems and it must be in tab-delimited text files in the format specified in Appendix B: Data Mapping Templates. After creation, and then periodically thereafter, place the files on an application server in a specific folder structure for uploading to Risk Analysis and Remediation. For more information, see the section Initial Setup for Non-RTA Supported Systems. Since many systems do not store deleted users or dates of last change, a utility compares the new data

September 2008

59

3 Risk Analysis and Remediation Additional Configuration Options files against records in Access Control. It determines users and roles that were added, deleted, or updated since the last file extract. After the comparison utility job is complete, it creates a new file, which contains only incremental changes. For more information, see the following sections: Initial Setup Create a Connector for a non-RTA System Analyze and Create Rules Data Extraction Schedule Batch Risk Analysis Initial Setup for Non-RTA Supported Systems Use this information to create extractor definitions to upload user and role data from systems not supported by RTAs. You can perform Risk Analysis against users and roles for these systems. Procedure 1. Create files as defined in the Appendix B: Data Mapping Templates. 2. Identify tables and fields in the legacy system that provide the information required for completing Risk Analysis. 3. Create spreadsheets of the data to be uploaded into Risk Analysis and Remediation. 4. Follow the templates exactly. 5. Create three folders for each legacy system on the file server, and name them IN, OUT, and EXP. The Comparison Utility background job requires these folders. Example \\servername\legacysystemfoldername\IN\ \\servername\legacysystemfoldername\OUT\ \\servername\legacysystemfoldername\EXP\ 6. Log on to Risk Analysis and Remediation as an administrator. 7. Create a connector for each legacy system. 8. Define the connector path as the path of the OUT folder created above. 9. Extract data from the legacy system. 10. Analyze and create system-specific rules. 11. Run Data Extractor to upload initial data. 12. After loading the initial data, periodically run the Comparison Utility to load changes. 13. Schedule Batch Risk Analysis to populate management reports. Do not include legacy systems when executing the User/Role/Profile Synchronization. Only include systems that are connected to systems with an RTA in the User/Role/Profile Synchronization.

60

September 2008

3 Risk Analysis and Remediation Additional Configuration Options Create a Connector for a Non-RTA Systems Use this information to create a connector for a system not supported by RTAs. You must create a connector for each non-RTA system. Procedure To create a connector for non-RTA supported systems: Go to Risk Analysis and Remediation > Configuration tab > Connectors > Create. The Create Connector screen appears. 1. In the System field, enter an identifier of the non-RTA system. 2. In the System Name field, enter the name of the system. 3. In the System Type dropdown menu, select Legacy. 4. In the Connection Type dropdown menu, select File-Local. 5. In the Location field, enter the full path of where the definition files are stored and reference the OUT folder. Verify there is a backlash (\) at the end of the file name. 6. In the User ID and Password fields, enter your logon credentials. 7. Click Save. Extracting Data from the Legacy System The file integration method requires you to generate and create files from systems not supported by RTAs (legacy systems) with the user and role authorization data. Before doing this, understand the legacy system methodology and map it to the security model of the SAP system. In SAP, you define roles to contain transactions and authorization objects for actions. You then assign roles to users. You can then map it to the layout required in Risk Analysis and Remediation. The following table maps the methodology of a legacy system to that of SAP. This mapping ensures that the data loading is in an accurate format. Risk Analysis and Remediation Name User Action Permission Field Role Profile SAP Name User ID Transaction Authorization Object Auth Object Field Role Profile Legacy Name (non-RTA system) User ID Screen Variable Not Used Grouping Not Used

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

September 2008

61

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

Target Definition User Action File (Required)

62

September 2008

3 Risk Analysis and Remediation Additional Configuration Options

Profile Permission File (Optional)

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

Action Permission Objects

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

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

For the Action Permission Objects file and Description File for Action, Permission Fields, and Values file, you need to upload the text to Risk Analysis and Remediation. This step must be completed before building your rules. Upload Objects to Risk Analysis and Remediation Use this information to upload objects from Action Permission Objects file and Description File for Action and Permission Fields, and Values. These are tables that contain action and permission objects from your legacy system that you need before building your rules in Risk Analysis and Remediation. For Action Permission File, upload the objects using Auth Objects mode, whereas for Description File for Action, Permission Fields, and Values use the Text Objects mode. In the steps below, the Text Objects mode is used as an example; however the procedure is similar for the Auth Objects mode. Procedure To upload objects: 1. Go to Risk Analysis and Remediation > Configuration tab > Upload Objects > Text Objects. The Text Objects Upload screen appears. 2. In the System field, enter the identifier of the non-RTA system. For this, use the system ID you created for the connector. 3. In the Local File field, enter the full path of the text file or click Browse to navigate to the file location. 4. In the Server File field, enter the full path of the text file, if necessary. Use either the Local File or the Server File, but do not use both.

September 2008

63

3 Risk Analysis and Remediation Additional Configuration Options 5. If you want the object to be loaded in the foreground, click Foreground. Otherwise, click Background for the object to be loaded in the background.

Only legacy systems where authorizations are controlled down to a permission level require all nine files listed. Systems that have security controlled at an action level can skip the user permission, role permission, and profile permission files (files 3, 6, and 9). For more information about the referenced files, see Appendix B: Data Mapping Templates for Non-RTA Supported Systems. Technical Requirements This section provides the technical requirements for file generation from legacy systems for integration with Risk Analysis and Remediation. This information is based on the eleven files in the Data Mapping Template. You must ensure that your files meet the following criteria: No duplicate records. No blank fields or records at the end of the files. Follow the sorting instructions in the mapping document closely, since they can affect the loading. The column separator in all the files must be either a tab or a comma. Multiple user IDs must not exist in the user file for one system, although they can exist in the multiple systems. Some operating systems have file size limits, and data can be missed from the upload. For example, if your operating system limits file size to 2GB, SAP recommends that you store a maximum of 60,000 records in a file. If the data exceeds 60,000 records, create a control file and multiple load files. You can use the Data Extractor to manage all files in the control file for data upload. The Control file contains the creation date in the first line. List all the individual file names, starting on the second line. In the data extractor, if you provide the control file name as the tab-delimited file name, Access Control uses the control file to retrieve each file by uploading them one-by-one. (This is an information record only. You can leave it blank.) The USERID field in file 2 (Target Definition User Action file) and the ROLE field in file 5 (Role Action File Target Definition) can have multiple values. However, the combination of USERID, ROLE, ACTIONFROM, and ACTIONTO fields must be unique. For more information about the referenced files, see Appendix B: Data Mapping Templates for Non-RTA Supported Systems. The data extractor must generate the PRMGRP field in numerical sequence by USERID or ROLE and PERMISSION. The system does not allow duplicates of this combination. Analyze and Create Rules Understand the security methodology of your legacy system before you begin creating rules. If you already have Risk Analysis and Remediation deployed in your organization, you have probably defined the functions and risks during the implementation. Therefore, you are not required to create new functions or risks, but rather add the security data from your legacy system to the existing functions. To ensure a complete analysis of your security methodology, evaluate all actions used in production by end users. Determine which actions allow the end user to perform functions

64

September 2008

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

5. In the Actions tab, click the

icon. A new row appears in the table.

6. In the System column, use the menu to select the connector created for the non-RTA system. 7. In the Action column, enter the action name from your legacy system. 8. Make sure that the action has the status of Enable. 9. Click Save.

Scheduling Batch Risk Analysis Updating management reports for a legacy system is similar to updating reports for a connected system. The major difference is that management reports are based on the data uploaded and are not dependent on a connection to a legacy system. With a legacy system, you cannot run a synchronization job, which is required for a connected system. The data extraction is performing the data synchronization. Also, since the data extraction overwrites the data in the database, there are no dates that show changes. The data is overwritten. For

September 2008

65

3 Risk Analysis and Remediation Additional Tabs this reason, only perform full batch risk analysis. Do not run incremental batch risk analysis for a system that has data loaded through Data Extraction. Procedure To schedule batch risk analysis: 1. Go to Risk Analysis and Remediation > Configuration tab > Background Job > Schedule Analysis. The User/Role/Profile Synchronization and Batch Risk Analysis screen appears. 2. From the Batch Risk Analysis pane, select Full Sync in the Batch Mode dropdown menu. 3. Enable the User Analysis checkbox. 4. In the Systems field, enter Legacy. 5. Enable the Management Reports checkbox. Schedule individual jobs for User Analysis, Role Analysis, and Profile Analysis (as opposed to doing them all at one time). Select the Management Report checkbox for each job. 6. Click Schedule. The Schedule Risk Analysis Background Job screen appears. 7. In the Job Name field, enter the name for this job. 8. Click either Immediate Start or Delayed Start. For Delayed Start, enter the desired start date and time. 9. To schedule this job to run periodically, click Schedule Periodically. 10. Choose either Daily, Weekly, or Monthly and enter the number of times you want the job to run for that period. 11. In the End Date field, enter a date to end the job. You can use the Calendar icon to enter the date. 12. Click Schedule. Otherwise, click Reset.

Additional Tabs
Informer Tab Risk Analysis and Remediation provides detailed compliance analysis and enforcement for companies of all sizes. It allows you to examine your ERP system and to implement internal controls. The data gathered in each analysis is made available for viewing in a range of predefined and customizable reports. You can access these reports through the Informer tab. You can generate reports for users, user groups, roles, profiles, HR objects, and organizational levels. Each option on the Informer tabs navigation bar represents a different report. Informer tab report types include: Management View: Summarized results with interactive displays. Risk Analysis: Risk analysis of users, roles, profiles, HR objects, and users at an organizational level. Analyzes where risks are contained, assigned, and mitigated. Audit Reports: Query rules, critical actions, critical roles/profiles, and mitigating controls. Security Reports: Query security information for users, roles, profiles, and action usage.

66

September 2008

3 Risk Analysis and Remediation Additional Tabs Background Job: Reports generated by background jobs. For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3. Rule Architect Tab The Rule Architect tab defines the rules that drive Risk Analysis and Remediation. It provides utilities to import and export definitions, view changes to functions or risks, and define and view: Rules Business Processes Rule Sets Functions Risks Critical Roles Critical Profiles Organizational Rules Supplementary Rules For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3. Mitigation Tab The Mitigation tab mitigates risks that cannot be removed by modifying access. This includes maintaining the following types of data manually or with export/import utilities and using the data to mitigate users, roles, profiles, HR Objects, or users at organizational levels. Mitigating Controls Administrators Business Units Control Monitors For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3. Alert Monitor Tab The Alert Monitor tab defines how alerts are generated and cleared for: Conflicting Actions Critical Actions Controls For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

September 2008

67

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

4 Superuser Privilege Management

Initial Configuration in the Back-end ABAP System
To set up Superuser Privilege Management, you must perform the following initial configuration steps in the back-end ABAP system before you execute the log report: Define a remote function call (RFC). An RFC is required each time a Firefighter ID logs on and creates a new session. Schedule a background job. The background job monitors the use of Firefighter IDs and records logon events and transaction use. Set configuration parameters. Configuration parameters define role-based and ID-based activities, mail preferences, and report preferences. For more information, see the following sections: Remote Function Calls Defining the Background Job for Log Reports Configuration Parameters To prevent users from logging on to Firefighter IDs directly, follow the instructions in SAP Note 992200 Firefighter User Exit. Remote Function Calls You configure a remote function call (RFC) destination to call an RFC-enabled function module. Superuser Privilege Management uses this RFC each time a Firefighter ID logs on and creates a new session. Recommendation SAP recommends that you use the three-character SAP system ID as the default RFC destination. If you create a new RFC destination, make sure that the name is basic and does not contain user or security information. Procedure To define and configure the RFC in the SAP backend system: 1. Use transaction SM59 or work with your BASIS administrator. 2. Click ABAP Connection. 3. Click on the Create icon or F8. 4. In the RFC Destination field, enter the system ID. 5. Click the Save icon or control S. 6. When you have created the RFC, enter the RFC name in the Configuration Parameter table and save it.

68

September 2008

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

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

S_DEVELOP

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 must assign the default role, /VIRSA/Z_VFAT_FIREFIGHTER to the Firefighter ID. Procedure To assign a default role to a Firefighter ID: 1. Run transaction SU01. 2. Enter the user ID you wish to assign the role. 3. In the Maintain User screen, click on the Role tab. 4. Enter the role, /VIRSA/Z_VFAT_FIREFIGHTER. 5. Enter dates in the Valid From and Valid To fields for validity of the assigned role. 6. Click the Save icon or control S.

Defining the Background Job for Log Reports For more information about defining background jobs and troubleshooting, see SAP Note 1039144. Procedure To define the background job for log reports: 1. Run transaction SM36. 2. Enter a job name. For example: /VIRSA/ZVFATBAK

September 2008

69

4 Superuser Privilege Management Initial Configuration in the Back-end ABAP System 3. Enter a job Class. SAP recommends the highest priority setting. 4. Specify a Target Server (optional). 5. Click Start Condition. 6. Click Immediate. 7. Select Periodic Job. 8. Select Period Values, and specify a time interval. SAP recommends running this background job hourly. 9. Click Save. 10. Click Step. 11. Select the ABAP application. 12. Run /VIRSA/ZVFATBAK. 13. Enter a Variant if you are scheduling a job with a time period that differs from hourly. 14. Click Save. 15. Click Save again to save the background job. The default variant time period is one hour and two minutes. If you schedule the job to run hourly, it gathers data from the last hour and two minutes to ensure that the job logs are complete If you schedule the job to run in a period other than hourly, you must create a variant with the same period to ensure that the logs are complete Configuration Parameters The configuration parameters specify the handling or behavior of log information, critical transactions, roles, and IDs. The following table describes each parameter. Configuration Parameter Behavior Parameter Name Remote Function Call Retrieve Change Log Definition Superuser Privilege Management requires an RFC destination to log on. Specifies the amount of change log information you capture when the background job executes. Superuser Privilege Management captures two log levels: a transaction log and the SAP change log. It captures the transaction level information from the STAT Data and the change log information from the CDHDR/CDPOS tables. Behavior Enter the RFC destination that you created with transaction SM59. To capture the transaction and the change log information, set this parameter to Yes. To capture only the transaction log information, set this parameter to No.

70

September 2008

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

Configuration Parameter Behavior Parameter Name Critical Transaction Table from Risk Analysis and Remediation Definition Superuser Privilege Management reports critical transaction use in the log for the following cases: - You are using Risk Analysis and Remediation to maintain critical transactions there, and - Risk Analysis and Remediation and Superuser Privilege Management reside on the same server. If both these conditions are met, you can configure Superuser Privilege Management to use the Risk Analysis and Remediation data rather than duplicate maintenance. Assign FF Roles Instead of FF IDs This parameter switches the interface from Firefighter IDbased administration to Firefighter role-based administration. This parameter is in effect only when the Assign FF Roles Instead of FF IDs parameter is set to Yes. It determines the assignment length, in days, of Firefighter roles, but it can be over-ridden at the time of role assignment. To use Firefighter IDs, set this parameter to No (default). To use Firefighter roles, set this parameter to Yes. If a From date is specified in the Firefighter dashboard, the To date is incremented by this number of days. If you do not specify a From date, it defaults to the current date. The To date increments by this number of days. If you assign valid From and To dates to a Firefighter, these dates override the dates in this parameter. Specify the folder location where archive files are stored. To allow only the defined owner of a Firefighter ID to view and assign the Firefighter ID, set this parameter to Yes. To allow any owner to view and assign that Firefighter ID, set this parameter to No. Behavior To use the critical transactions defined in Risk Analysis and Remediation, set this parameter to Yes. To use the critical transaction defined in Superuser Privilege Management, set this parameter to No.

Default Role Expiration in Days

Auto Archive Location Firefighter Owner Additional Authorization

Use this parameter to specify a folder for the Auto Archive feature. Each Superuser Privilege Management has a defined owner. This parameter overrides the defined owner privileges.

September 2008

71

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

Configuration Parameter Behavior Parameter Name Configuration Change Comment Required Definition This parameter makes a comment mandatory for changes to configuration. The comment will be provided in the Configuration Change Log Report. This parameter provides additional authorization to a controller. Behavior To make a comment mandatory, set this parameter to Yes. To make a comment optional, set this parameter to No.

Controller Additional Authorization

To allow users to maintain controllers for those Firefighter IDs for which they are the owner or administrator, set this parameter to Yes. To allow any user to maintain controllers, set this parameter to No.

Send Log Report with Critical Transactions Only

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

To send a log report that contains only critical transactions to controllers, set this parameter to Yes. To send a log report that contains all transactions to controllers, set this parameter to No. To send an email to a controller with Firefighter log information, set this parameter to Yes. To send no log information to the controller, set this parameter to No. To send log report email notifications to the controller inboxes as soon as the /VIRSA/ZVFATBAK job runs, set this parameter to Yes. If you plan to receive the job at regular intervals, schedule the job /VIRSA/ZVFAT_LOG_REPORT at regular intervals, and set this parameter to No.

Send Log Report Execution Notification

This parameter specifies whether log reports that contain information about Firefighter activity are emailed to controllers. This option specifies whether the log reports are sent to the controllers as soon as the background job (/VIRSA/ZVFATBAK) is executed or at a predefined date and time. If you want the job to run at different intervals, you must use an external scheduling tool. To enable this parameter, set the Send Log Report Execution Notification to Yes.

Send Log Report Execution Notification Immediately

Send Firefighter ID Logon Notification

This option specifies whether to send a logon notification email to controllers with information about when a Firefighter session was started and by which user.

To send an email to a controller with Firefighter logon information, set this parameter to Yes. To send no email with Firefighter logon information to a controller, set this parameter to No.

72

September 2008

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

Configuration Parameter Behavior Parameter Name Send Logon Notification Immediately Definition This option specifies whether the logon notifications are emailed to the controllers as soon as they are run or when they are scheduled. Behavior To send an email to a controller with Firefighter ID logon information after each logon session, set this parameter to Yes. To schedule the /VIRSA/ZVFAT_LOG_NOTIFICATION report at regular intervals, set this parameter to No. Enter the connector ID of the Risk Analysis and Remediation capability. See the section, Defining Connectors for Risk Analysis and Remediation for connector ID information.

Connector ID for Risk Analysis and Remediation

This option checks for SoD violations.

Configuring a Parameter The administrator must configure and maintain configuration parameters. Superuser Privilege Management is not shipped with configured parameters. Procedure To configure the parameters: 1. On the dashboard, click the Configuration tab. 2. If the Parameter table is empty, click the SAP List icon to see a list of parameters. 3. Select a parameter. 4. Use the information in the Configuration Parameters section, and enter a value in the Configuration Parameter Value list. Email Configuration You configure email messages the same way for both ID-based and role-based administration. To enable a user for email, set the following configuration parameters for email notifications on the Configuration tab. Send Firefighter ID Logon Notification Send 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 to Email or Workflow. To receive log email messages, ensure that you run the /VIRSA/ZVFATBAK report before you submit the /VIRSA/ZVFAT_LOG_REPORT.

September 2008

73

4 Superuser Privilege Management Defining Connectors for Superuser Privilege Management Reason Codes Reason codes describe each task that a Firefighter expects to perform. For example, a reason code might be a technical support case number. The reason code must be clear so that the Firefighter understands the task that it represents. To enable users to search or filter the Reason and Activity report, or the Log Report by reason code, the reason code status must be set to active. Activities Both administrators and users use reason codes: The Superuser Privilege Management administrator defines reason codes in a table. The user selects a reason code from a dropdown list on the dashboard. Creating a Reason Code Procedure To create a reason code: 1. Click the Reason Code tab on the administrator's dashboard tool bar. The reason code table appears. 2. Click New Entries. 3. In the Reason Code column, enter the reason code. This code relates to the description. For example, if the description is a technical support issue, the reason code might be the case number for this issue. 4. To describe the reason code, enter text in the Description field. A good description supplements the reason code and helps avoid misunderstandings 5. Click Save.

Defining Connectors for Superuser Privilege Management

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

74

September 2008

4 Superuser Privilege Management Defining Connectors for Superuser Privilege Management

For Superuser Privilege Management to interface properly with Risk Analysis and Remediation, follow the instructions in SAP Note 1055976 - Firefighter 5.2 - Unable to run the SoD analysis report. To ensure that the connector works properly, verify that you have the following authorizations for S_RFC and SVFAT_0001. The BASIS Security Administrator creates a role using the authorization objects in this table. The role is assigned to a user ID, which is used when creating a connector. Make sure that the authorization objects fields and values are configured appropriately. See the SAP GRC Access Control 5.3 Security Guide in SAP Service Marketplace for more information. Authorizations for S_RFC Field ACTVT RFC_NAME Value 16 /VIRSA/*FF*, BAPT, RFC1, SDIF, SDTX, SUSR, SUUS, SU_USER, SYST, SYSU, SDIFRUNTIME

RFC_TYPE FUGR

Authorizations for ZFAT_0001 Field ACTVT Value *

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

September 2008

75

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

Searching for a Connector Procedure To search for a connector: 1. Using the URL supplied by your administrator, log on to the Superuser Privilege Management toolbox. 2. Click the Connector tab. 3. In the left navigation bar, click Search. 4. On the Search Connectors form, enter the Connector ID and Description. 5. Click Search. The Search Results screen displays the following results: Connector Field Description

76

September 2008

4 Superuser Privilege Management Archived Data for Log Reports

Connector Field Connector ID Connector Description Application Server

Description Name of the connector. Description for the connector. The host name or IP address of the SAP server where Superuser Privilege Management is installed and the system you are connecting to. You obtain this information from the SAPGUI Logon pad.

System Number Client

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

Archived Data for Log Reports

This section describes actions that are performed through your back-end system. You can use the Archive menu to view both the ID-based and role-based log reports as a download or as an archive. Superuser Privilege Management saves data in three text files, each of which archive different log data: Session log (SLOG) files Transaction log (TLOG) files Change log (CLOG) files You can customize the log report by deleting data. You can also upload reports that you have previously downloaded. The Download button on the ID-based log report downloads the SLOG, TLOG, and CLOG files as one consolidated file. You must perform any changes to the downloaded file manually. SLOG Files Files that end with SLOG store Firefighter ID logon events. Each row in the spreadsheet records a Firefighter ID logon event. The column headings are: Firefighter ID, Firefighter, Session Date, Session Time, Reason, and Activity. SLOG files display the Session Time column as a number. To display the value as clock time, format the column in a time format. SLOG files are not available in the role-based report. TLOG Files Files that end with TLOG store transaction type records. Each row in the spreadsheet is the Transaction Type record for the corresponding row in the SLOG table. The column headings are: Firefighter ID, Transaction Date, Transaction Time, Server Name, Transaction Code, Report Name, and Report Title.

September 2008

77

4 Superuser Privilege Management Archived Data for Log Reports

TLOG files display the Transaction Time column as a number. To display the value as clock time, format the column in a time format. CLOG Files Files that end with CLOG store transaction change records. The column headings are: Firefighter ID, Firefighter, Session Date, Session Time, Object ID, Transaction Data, Transaction Time, Transaction Code, Table Name, Field Name, Field Description, Change Indicator, Old Value, New Value, and Change Document Number. The CLOG file displays the Transaction Time column as a number. To display the value as clock time, format the column in a time format.

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

Automatic Archiving the Log Report

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

78

September 2008

4 Superuser Privilege Management Archived Data for Log Reports If you click Background Job, the background job scheduler appears and you can define the date and time you want to schedule the job. If you click F8 or Execute, the archiving runs in the foreground.

September 2008

79

5 Compliant User Provisioning Prior to Configuration

5 Compliant User Provisioning

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

Prior to Configuration
Before you configure Compliant User Provisioning, you must complete the installation process. This includes the software installation and certain one-time configuration procedures, such as creating the initial administrative user and importing roles. For more information, see the SAP GRC Access Control 5.3 Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions-> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3. Integration To ensure that your installation is complete: Ensure that you have applied all real time agents (RTAs) have been applied to all Compliant User Provisioning systems. Choose the authentication system and ensure that all necessary user accounts exist. Verify that all directories have the correct permissions. Activities When you have configured Compliant User Provisioning, you are ready to begin modeling your provisioning processes. Compliant User Provisioning uses workflows to replicate or model the provisioning process, and to collect the information necessary to carry out a provisioning request. The process for creating workflows is straightforward if you know in advance: What steps a specific provisioning process contains Who is required to approve that access It is easier to create the workflow if you know the provisioning process you want to reflect before you create the workflow. For more information, see the section Managing Workflows. Preparing to create workflows requires some research. Typically, you build a profile or spreadsheet of each provisioning process for which you want to create a workflow. After you have completed a profile that details each step of the process, you can create and deploy a workflow that implements that process. The information in a provisioning process includes:

80

September 2008

5 Compliant User Provisioning Basic Functionality

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

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

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

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

September 2008

81

5 Compliant User Provisioning Key Concepts 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 for requestors and interacting with approvers through email. This guide describes administration functions that enable you to create and deploy the workflows that manage the provisioning request process. Requestors and approvers follow predefined paths to assign user permissions. Administrators define those paths. As an administrator, you configure Compliant User Provisioning and use it to create and deploy workflows.

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

82

September 2008

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

Users
There are three types of user, each corresponding to a basic Compliant User Provisioning function: Compliant User Provisioning User Types User Requestor Description Requestors create provisioning requests, which ask for a specific user to be assigned to one or more user roles. Each request initiates a workflow, a process requesting approval of the role assignment from designated approvers.

September 2008

83

5 Compliant User Provisioning Administration Tasks

Compliant User Provisioning User Types User Approver Description Approvers either approve or deny provisioning requests. Compliant User Provisioning interacts with approvers through email. At each stage of a workflow, users are designated as the approvers for that stage, and those users receive an approval email generated by Compliant User Provisioning. The email includes two links, one to approve the request, and one to deny it. The approver clicks the link to either approve or deny.

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

Administration Tasks
When you are sure that Compliant User Provisioning is correctly installed and you document the business processes your organization follows to provision user access, you are ready to perform administration tasks. These tasks fall into two categories: Configuring Compliant User Provisioning in preparation for creating and deploying workflows Workflow management, including creating, validating, modifying, deploying, and deleting workflows The primary administration task is creating the workflows that implement the processes. As an administrator, you define the workflows used by the requestors and approvers. Workflows incorporate a great deal of information. Among other details, you can: Identify the request condition that initiates a specific workflow. Determine the approvers, the roles, and the permissions associated with each role. Define these details for each workflow as you create it. It is more efficient, and your roles and permissions will be more consistent, if you define the details before you begin creating workflows. Prerequisites When you configure Compliant User Provisioning, you define the details that are the building blocks for workflows. Before you begin configuring or creating workflows, however, complete your preconfiguration responsibilities: Work with your business process owners to capture and record the approval requirements for each user role. Complete the preconfiguration tasks described in the next section. Once you have completed these tasks, you can begin the configuration process setup.

84

September 2008

5 Compliant User Provisioning Preconfiguration Tasks

Preconfiguration Tasks
Setting up Compliant User Provisioning involves configuring or defining connectors, data sources, security settings, Web services, and many other objects that you use when you create workflows. Activities Complete the following configuration tasks prior to setting up your workflows. Step 1: Pre-Workflow Configuration Before using Compliant User Provisioning, you must create an environment for requestors and approvers. As an administrator, you must configure Compliant User Provisioning so it meets your business requirements. Gather all essential information prior to setting up Compliant User Provisioning. Complete the pre-workflow configuration tasks in the order listed below. After configuring the initial workflow, you can make additional changes in any order. Initializing System Data Defining Connectors Request Configuration Number Ranges Authentication Source for Requestors Defining Authentication Defining Multiple LDAP Authentication Configuring Risk Analysis Configuring Mitigation Defining End User Personalization Defining Support Screen information Defining Role Attributes Configuring Application Approvers Defining SMTP Server Identification Step 2: Workflow Configuration Complete the workflow configuration tasks in the following order. Creating an Initiator Defining a Stage Creating Main Paths Adding Detours to a Main Path Defining Auto Provisioning Step 3: Post-Workflow Configuration Complete the post-workflow configuration tasks in any order. Configuring a Service Level Configuring User Defaults

September 2008

85

5 Compliant User Provisioning Preconfiguration Tasks Defining Password Self Service Setting Up Background Jobs Creating Custom Fields Compliant User Provisioning modifies your configuration to reflect your current business model. However, it is important that you correctly configure it before using it in a production environment. Initializing System Data - Initial Logon After installing Compliant User Provisioning, use a Web browser to log on and access the application. To do so, enter either of the following URLs in your browser: The GRC Access Control launch pad works for approvers and administrators. When selecting Compliant User Provisioning from the launch pad, you bypass the Request Access screens and display the main screen within Compliant User Provisioning. The structure of the Access Control launchpad is: http://<server_name>:<port_number>/webdynpro/dispatcher/sap.com/g rc~acappcomp/AC For any user who enters requests, use the direct Compliant User Provisioning URL: http://<server_name>:<port number>/AE The server_name is the name of the application server on which SAP GRC Access Control resides, and the port_number is the assigned port number of the application server. (Contact your system administrator for the correct URL on your system.) When using the specified Compliant User Provisioning URL, the Compliant User Provisioning home screen is displayed. On this home screen, there are four options: Request Access This option allows you to enter/submit access requests. When you select this option, the system displays the access request types configured for your system. When you select an access request type, the system prompts you to enter your user ID and password. Request Status This option displays the list of open access requests you have submitted. Support This option displays your companys support Web site. User Logon This option prompts you to log on to Compliant User Provisioning as an approver or an administrator to gain access to the My Work tab, the Informer reporting tab, and/or the Configuration tab. The access you gain to Compliant User Provisioning depends on the User Management Engine (UME) roles/permissions granted by your system administrator. All Compliant User Provisioning roles are defined in the UME. UME administration rights are required to assign Compliant User Provisioning roles.

86

September 2008

5 Compliant User Provisioning Initialization System Data Initializing System Data - Required User Management Engine Roles/Permissions To gain access to Compliant User Provisioning, you must make role assignments in the User Management Engine (UME). The UME is the SAP Security tool for managing access to SAP NetWeaver applications. When defining Compliant User Provisioning roles, define the UME roles with the permissions that you would like each user to have. Approvers may have different permissions based on their responsibilities. For example, some approvers can create mitigating controls from within Compliant User Provisioning, but some cannot. Requestors do not need specific UME permissions to create a request, although depending on the configuration settings, they may need to exist in the Authentication System. For more information, see the section Authentication Source for Requestors. All other users (approvers and administration users) must be assigned specific UME permissions to access Compliant User Provisioning through the User Logon option. On the SAP NetWeaver Server Index Screen, click User Management to create roles and assign them to users. The following are the roles that Compliant User Provisioning provides: Roles are provided with the installation files and must be uploaded into the User Management Engine during the installation process. AEAdmin AEApprover AESecurity For more information, see the SAP GRC 5.3 Access Control Security Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions-> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Initialization System Data

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

September 2008

87

5 Compliant User Provisioning Configuration Tasks 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 data originally shipped with Compliant User Provisioning. 6. Click Import.

Configuration Tasks
Integrating with the System Landscape Directory (SLD) Integration with SLD allows for scenarios where the SAP back-end system and the Access Control server are on different networks. Connection data is maintained only once in SLD and can be shared across Compliant User Provisioning, Superuser Privilege Management, and Enterprise Role Management. When the information changes, it is changed only once in SLD and not multiple times in each capability. SLD integration also allows for Secure Network Communication (SNC). Using the SNC interface and the SAP cryptographic library, all connector communication can be encrypted. This enbles you to protect password transmission from Compliant User Provisioning to SAP back-end systems. For more information about SLD, see the SAP Help Portal at http://help.sap.com. Defining Connectors for Compliant User Provisioning After installing Compliant User Provisioning, you must configure the interactions with the appropriate back-end systems via connectors. This is essential to provision approved users to the back-end systems. Compliant User Provisioning supports several connector types for the back-end systems. Access Control communicates with multiple systems. SAP recommends using HTTPS communication protocol for secure communication. For more information about configuring a connector for an identity management (IDM) system, see section Integrating with an Identity Management Solution. Features Connectors facilitate the transfer of data between Compliant User Provisioning and SAP systems, non-SAP systems, SAP Enterprise Portal, LDAP, and other systems. By configuring

88

September 2008

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

For more information on multiple data source, see the section User Data Source Definition. For multiple LDAPs, Compliant User Provisioning supports: Microsoft Active Directory Sun Microsystems SunOne Novell E-Directory IBM Tivoli Any other LDAP supported in NetWeaver Defining Connectors for SAP Procedure To define connectors for SAP systems: 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select SAP. Any field name denoted with an asterisk (*) is required. To complete the Connectors screen, obtain the connection information from your network administrator and BASIS administrator. 3. In the Name field, enter a name for the connector. The connector names are important when integrating with other GRC products and the CUA. Make sure that the connector name for Access Control is the same as the one configured for CUA. 4. In the 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.

September 2008

89

5 Compliant User Provisioning Configuration Tasks 7. In the Application Server Host field, enter the host name of the application server. 8. In the System Number field, enter the number in the SAP system log. 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 backend system. The user ID must have the security access to perform the tasks required. If provisioning is configured for this connector, this user ID must have authorization access to maintain users in the SAP system. If provisioning is configured, this user ID appears on each change record on the SU01 user master record. For more information on user ID authorization, see the SAP GRC 5.3 Access Control Security Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions-> SAP Solutions 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 Portal at 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 and maintain 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 BASIS administrator provides this information. 13. In the Message Server Name, enter the name of the message server, which is used for load balancing of your SAP clustered environment. 14. In the Message Server Group, enter the Logon Group name to which the message server belongs. Your BASIS administrator provides this information. 15. In the Message Server Host, enter the host name of your message server. Your BASIS administrator provides this information. 16. In the SAP Version dropdown menu, select the appropriate SAP version. Compliant User Provisioning supports SAP 4.6C, 4.7, and ECC 6.0. In the HR System dropdown menu, select Yes or No to indicate if an SAP HR system is used or not. An HR system flag indicates whether the SAPHR module is installed on this connector, not necessarily whether you are using the SAPHR module. If the system is an HR system, the appropriate HR RTAs must be installed.

For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution 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 Standard Landscape Directory. For more information, see Integrating with System Landscape Directory. 18. In the Connector Category dropdown menu, select the category to which the connector belongs. Possible values are Production, Non-Production, or Other. This selection is used to classify the servers into categories on the Access Request forms.

90

September 2008

5 Compliant User Provisioning Configuration Tasks 19. In the Role dropdown menu, select whether or not role information comes from Enterprise 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 Manager field value to be automatically populated from the users HR record, set this field to (B012) Managers. b. If you want the Reports to line value to be automatically populated from the users HR record, set this field to (A002) Reports (line) to (for organizational units). SAP HR provides an organizational structure view that contains the object, relationships, and attributes. The organizational structure view contains the relationship types, B012-Managers and A002- Reports to. 21. Click Create. 22. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector.

Defining Connectors for SAP Enterprise Portal Before you begin configuring for the SAP Enterprise Portal connector, check that the Service Provisioning Markup Language (SPML) service on SAP Enterprise Portal is configured on the portal server. Use the following URL in the browser: http://<server-name>:<port>/spml/spmlservice Make sure that the Web browser shows a page with the following message: SPML Provider successfully installed and configured Procedure To define connectors for SAP Enterprise Portal systems: 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select SAP EP. The Connectors screen appears. Any field name denoted with an asterisk (*) is required. To complete the Connectors screen, obtain the connection information from your network administrator and BASIS administrator. 3. In the Name field, enter the SAP Enterprise Portal connector name. 4. In the Short Description field, enter a short description of the connector. This description appears for the users to select. 5. In the Description field, enter the description of the new enterprise portal connector. 6. In the Web Service URI field, enter the URI address of the Web service of the application server.

September 2008

91

5 Compliant User Provisioning Configuration Tasks

Obtain the Web service URI address during the installation process of the RTA for the specific application server. The Web service must be exposed in the application server side to establish communication links with Access Control. 7. In the User ID field, enter the user ID of a portal RTA user for this connection. This user must have the appropriate role to perform this technical configuration. Assign the role, pcd:portal_content/administrator/super_admin/super_admin_role to the RTA user. 8. In the Password field, enter the password to access this connection. 9. In the System Language field, enter the native system language for the application server. For example, use En_US for US. 10. In the Connector Category dropdown menu, select Production, Non-Production, or Other connector type. This selection helps classify the servers into the appropriate categories in the Access Request forms. 11. In the Parameter pane, a table appears for you to map Parameter Names to Parameter Values. The parameter value pair mapping is specific to the application server. The table below displays the required parameters for Provisioning Actions. Each provisioning action has a parameter value pair mapping for Parameter Name and Parameter Value for the SAP Enterprise Portal connector. Provisioning Actions SAP Enterprise Portal (Required Parameter Value Pairs for the connector 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 CREATE_ACTION_MAP CHANGE_USER:OC = sapuser CREATE_USER:OC = sapuser CREATE_USER:password=password DELETE_ACTION_MAP LOCK_ACTION_MAP DELETE_USER:OC = sapuser 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

92

September 2008

5 Compliant User Provisioning Configuration Tasks

Provisioning Actions

SAP Enterprise Portal (Required Parameter Value Pairs for the connector definition)

DATA_SOURCE ROLE DATA SOURCE

USER_DATA_SOURCE=USER.PRIVATE_DATA SOURCE:un -none-

For asynchronous requests to an IDM system, map the parameter value pair in the connector definition: PROV_CALL = async. When mapping parameter value pairs, you may have to define the user name and password for role search service in the provisioning action. This mapping is different from the user ID and password that you set in the Connectors screen. 12. Click the Add icon to add more parameter value pair mapping. 13. Click Create. 14. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector. If your connector does not have a RTA installed, you do not need to test the connection, because the connection occurs between the two systems through Compliant User Provisioning. Field Mapping for SAP Enterprise Portal When you have configured the connector for the SAP Enterprise Portal, you must configure the 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 the desired 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 Add icon to display the dropdown menu where you can select a name of the field for AC and Application in order to associate the fields. Example:

September 2008

93

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

94

September 2008

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

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

September 2008

95

5 Compliant User Provisioning Configuration Tasks 4. In the Short Description field, enter a short description of the connector. This description appears for the users to select. 5. In the Description field, enter the description of the new LDAP connector. 6. In the Server Name field, enter the name of the LDAP server. 7. In the Domain field, enter the location of the LDAP root. The LDAP root is where Compliant User Provisioning binds to. 8. In the Port field, enter the number of the LDAP port. 9. In the User Principle Name field, enter user name to access this connection. Ensure that the user ID associated with this name has the access to view the LDAP user directory. 10. In the Password field, enter the password to access this connection. 11. In the User Path field, enter the directory path specific for the user. 12. In the Group Path, enter the directory path specific for the group. 13. In the LDAP Type dropdown menu, select the appropriate LDAP type. 14. In the Password Encryption dropdown menu, select the type of encryption to apply to the connector password. 15. In the Connector Category dropdown menu, select a Production or Non-Production type. This selection is used to help classify the servers into the appropriate categories in the Access Request forms. 16. Click Create. 17. Click Test Connection to ensure that the connection is valid. Executing this test verifies that the information on the connector is valid and initial communications can be established. It also verifies the user ID and password. This test, however, does not verify that the correct RTAs are installed on this connector. If your connector does not have a RTA installed, you do not need to test the connection, because the connection occurs between the two systems through Compliant User Provisioning. Defining Connectors for Verification/Training System You can connect to your training system to implement and verify that users have completed the required training program before requesting roles, privileges, and the like. In general, you select the Verification/Training System connector type when your organization requires users to participate in a training program. Once the user completes the training program, you can verify that the user has successfully performed the prescribed tasks. For example, before assigning a role to a user, you can verify that the user is competent in creating an access request. Procedure To define connectors for verification/training systems: 1. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 2. In the Connector Type dropdown menu, select Verification/Training System. The Connectors screen appears.

96

September 2008

5 Compliant User Provisioning Configuration Tasks

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

September 2008

97

5 Compliant User Provisioning User Data Source Definition Viewing and Maintaining Available Connectors You can view a list of the connectors configured to connect to back-end systems and change or delete them. To do this, select a connector name and click Change or Delete. If you select Change, the Connectors screen appears. You can edit and save any changes in the field values. If you select Delete, the system deletes the selected connection. To ensure that the entered values are valid in establishing the successful connection, click Test Connection.

User Data Source Definition

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

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

98

September 2008

5 Compliant User Provisioning User Data Source Definition

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

September 2008

99

5 Compliant User Provisioning Integrating Compliant User Provisioning and Risk Analysis and Remediation they are searched. The system searches the systems until it finds the user ID and retrieves the users details.

Integrating Compliant User Provisioning and Risk Analysis and Remediation

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

d. Right click on the URI address under the WSDL heading to copy as a shortcut. 2. Go to Compliant User Provisioning > Configuration tab > Risk Analysis. The Risk Analysis screen appears. 3. In the Select Analysis and Remediation Version pane, select 5.3 Web Service in the Version dropdown menu. 4. In the URI field, enter the Risk Analysis URI. You can paste in the copied shortcut you obtained in Step 1. 5. Enter a User Name and Password. 6. Click Save. 7. Configuring for Mitigation Integration. To do so, obtain the URI information for the following: Mitigation Risk Search Org. Rule Search Function Search To obtain the URI information, perform the following steps for each Web service: a. Go to SAP NetWeaver Web Application Server Start Page > Web Service Navigator. Example: http://<server>:<port>/index.html b. Expand the following Web services to extract their respective URI: VisaCCMitigation5_0Service VirsaCCRisk5_0Service VirsaCCOrgRules5_3Service VirsaCCFunction5_0Service c. Click Document.

d. Right click on the URI address under the WSDL heading to copy as a shortcut.

100

September 2008

5 Compliant User Provisioning Request Configuration 8. Go to Compliant User Provisioning > Configuration tab > Mitigation. The Mitigation screen appears. 9. Select the Allow Approvers to Approve Access Despite any Conflicts checkbox. 10. In the Default Duration (Days) for the Mitigation Control, enter a number of days you want for the default duration. 11. In the Mitigation URI field, enter the address for the mitigation Web service. For example: http:// <server>:<port>/VirsaCCMitigation5_0Service/Config1?wsdl&style=document 12. In the Risk Search URI field, enter the address for the risk search Web service. For example: http:// <server>:<port>/VirsaCCRisk5_0Service/Config1?wsdl&style=document 13. In the Org. Rule Search URI field, enter the address for the organization rule search Web service. For example: http:// <server>:<port>/VirsaCCOrgRules5_3Service/Config1?wsdl&style=document 14. In the Function Search URI field, enter the address for the function search Web service. For example: http:// <server>:<port>/ VirsaCCFunction5_0Service/Config1?style=document 15. Click Save.

Request Configuration
The Request Configuration option customizes the Request screen. This means defining the fields that you want to appear. You can customize Request Types, create a new Request Category or Request Reason, and provide a range of values that appear when a user makes a new request. The Request Configuration screen provides Configuration tabs for request creations that you must define to meet the range of request cases in your system. These configuration values depend on your business requirements. The Request Configuration screen includes: Configuring Request Types Configuring Request Priorities Configuring Applications Configuring Employee Types Request Type Configuration The Request Type tab configures the request type(s) that a requestor chooses during the request process. The Request Type configuration specifies what actions are performed on the processing of that request. Features Request types determine the actions to be performed. Request types can be reference points for initializing a workflow. Compliant User Provisioning provides a standard set of request types. These standard request types represent actions that occur in the SAP back-end systems. You can modify and configure these standard request types during configuration. You can also create your own custom request types for your business needs. Request types can also be used as an attribute in the initiator/workflow selection process. The standard request types are: New Change

September 2008

101

5 Compliant User Provisioning Request Configuration Delete Lock Unlock Example If the request type is New, it relates to the creation of a new account in the SAP backend system. The standard set of request types are loaded during the installation process from an XML basic configuration file. You can configure the Request Type for the request during the End User Personalization configuration. Configure this field with a default value and indicate whether it is mandatory, editable, and visible. You can also create your own custom request types, instead of using any of the delivered request types. Customized request types allows you to define the sequence of provisioning actions for a request. The following are examples of customized request types: Create, Assign Roles, and Lock Change and Lock Change and Unlock Example If you create a customized request type as Create and Lock, it relates to the creation of a new account in the SAP backend system with their role assignment and locking the account for a go-live scenario. You then can use the customized request type as an attribute in the Initiator/Workflow selection process. Creating Request Types Procedure 1. On the Configuration tab, navigate to Request Configuration > Request Type. The Request Configuration Request Type screen appears. 2. Click Create. The Create Request Type screen appears below the Request Type screen. Any field name with an asterisk (*) is required. 3. In the Type column, enter the request type. 4. In the Short Description field, enter a short description of the request type. The information in the Short Description field appears on dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. In the Description field, enter the full description of the new request type. 6. In the Sequence field, enter the sequence number. Assigning a sequence order value to request types defines the order in which request types appear on the Request Access screen.

102

September 2008

5 Compliant User Provisioning Request Configuration

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

September 2008

103

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

104

September 2008

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

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

Request Priority Configuration

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

September 2008

105

5 Compliant User Provisioning Application Configuration The Create Priority screen appears below the Priority screen. Any field name denoted with an asterisk (*) indicates that it is required. 3. In the Priority field, enter the name of the new priority. 4. From the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with the Risk Analysis and Remediation and/or Enterprise Role Management capabilities and you have enabled the Workflow Types on the Miscellaneous screen. 5. In the Short Description field, enter a short description of the new priority. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a description for the new priority. 7. Click Save. Changing or Deleting a Request Priority Procedure To change a Request Priority: 1. On the Priority screen, select the priority you want to change. Click Change. The Modify Priority screen appears. All of the available, editable fields become active. 2. Make your modifications. The Priority and Workflow Type fields are not editable. All other fields and values are editable. 3. Click Save. Procedure To delete a Request Priority: 1. On the Priority screen, select the priority you want to delete, and then click Delete. Only priorities that have not been used in a request can be deleted. 2. Click Save.

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

106

September 2008

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

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

Employee Type Configuration

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

September 2008

107

5 Compliant User Provisioning Number Ranges

Employee Type is configurable on the request through the End User Personalization configuration. Configure this field with a default value and indicate whether it is mandatory, editable, and visible.

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

Number Ranges
Requests in Compliant User Provisioning are identified through a system of distinct numbers. You use the Number Ranges option to define a range of unique request numbers. Compliant User Provisioning uses these numbers for invoices and identification. For example, you can configure a number range to reflect the month of April by setting your number range to 0401 to 0430. It is important to create multiple number ranges that correspond to your business requirements. However, make sure that individual ranges do not overlap. For example, do not have a number range of 1001000 and another number range of 500 2000. Only one number range can be active at a time. The system does not activate the number ranges automatically. You must activate the number range after it reaches its last invoice number.

108

September 2008

5 Compliant User Provisioning Authentication Source for Requestors Configuring Number Ranges Procedure To configure the number ranges: 1. On the Configuration tab, navigate to Number Ranges. The Number Ranges screen appears. 2. Click Create. Two empty fields appear below the From Number and To Number columns. 3. In the From Number field, enter the starting number. 4. In the To Number field, enter the ending number. 5. Click Save. 6. Click the Match icon to activate the new number range. The next request number appears in the Current Number field. Changing Number Ranges Procedure 1. On the Number Ranges screen, select the range of numbers you want to change. 2. Click Change to modify the number range. The From Number and To Number fields become editable. 3. Make any changes to the number ranges. 4. Click Save.

Authentication Source for Requestors

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

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

September 2008

109

5 Compliant User Provisioning Risk Analysis

Defining Authentication Procedure The requestor of a request does not need any permission; therefore, requestors can be authenticated against any connection. To define authentication: 1. On the Configuration tab, navigate to Authentication. The Authentication System screen appears. 2. In the Authentication System field, select the authentication system from the dropdown list. The options include Multiple LDAP, SAP, SAP UME, JDE, SAP EP, LDAP, SAPHR, PEOPLESOFT, and ORAAPPS. 3. In the System Name field, select the system name from the dropdown list. These are the systems configured as Connectors. 4. Select the End User Verification Required checkbox to make the verification required. The End User Verification Required option is available for any non-SAP system (including LDAP authentication systems). It allows the requestor to log on without a password, if that requestors user ID is defined in the LDAP. 5. Click Save. Defining Multiple LDAP Authentication Procedure To define multiple-LDAP authentication: 1. On the Configuration tab, navigate to Authentication. The Authentication System screen appears. 2. From the Authentication System dropdown list, select MULTIPLE LDAP. Order the sequence of the LDAPs you want authenticated by clicking on the dropdown list and selecting a number from 1 to 9, where 1 is the highest, 9 is the lowest, and 0 deselects the LDAP. Compliant User Provisioning searches for LDAPs in the specified order to find the user ID and password. The search stops after it finds the first user ID match. Select the End User Verification Required checkbox to enable the verification of a user ID without requiring the user to enter a password. The system only verifies that the user ID exists in the data source. 3. Click Save.

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

110

September 2008

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

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

Frequently Asked Questions Question Answer

September 2008

111

5 Compliant User Provisioning Mitigation Setting

Question Can you choose the rule set to perform the risk analysis from Compliant User Provisioning? Can you identify which SoD risk criticality levels have been assessed for a request access? How does Compliant User Provisioning perform a risk analysis?

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

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

Mitigation Setting
The Mitigation option allows approvers to approve requests when SoD violations are found during risk analysis. If this option is not enabled, the approver cannot approve the request when role conflicts are discovered. In that case, the approver can either reject some roles and perform risk analysis again to check for violations or mitigate the existing violations to proceed. Configuring Mitigation Procedure To configure mitigation: 1. On the Configuration tab, navigate to Mitigation. The Mitigation, Select Options screen appears. 2. Decide how you want to configure the Allow Approvers to approve access despite conflicts checkbox. This option is a global setting, but it can be configured during the workflow stage configuration. To allow approvers to approve their requests with unmitigated SoD conflicts, select the checkbox. When the approver executes the risk analysis, the resulting SoD conflicts are displayed. To require approvers to address the SoD conflicts during the access request processing, deselect the checkbox. This requires the approver to remove or mitigate the SoD conflict before they can approve. 3. In the Default Duration (in days) for the Mitigation Control field, enter the number of days you want the mitigating control to be active.

112

September 2008

5 Compliant User Provisioning End User Personalization 4. In the next four fields, identify the Web service URL/URI for obtaining the mitigation information from Risk Analysis and Remediation: a. Open a new browser session and navigate to the Web Application Server (http://<server>:50000/index.html). b. Click Web Services Navigator. The Web Services Navigator screen appears. c. Expand the folder that corresponds to the Web service: For Mitigation URI, expand the VirsaCCMitigation5_0Service folder For Risk Search URI, expand the VirsaCCRisk5_0Service folder For Org. Rule Search URI, expand the VirsaCCOrgRules5_3Service folder For Function Search URI, expand the VirsaCCFunction5_0Service folder d. Click Document. The Web service URL is listed below the WSDL (Web Services Description Language) heading. Right-click Web Service URL and select Copy Shortcut from the context menu. Return to Compliant User Provisioning's Configuration tab > Mitigation and paste the correct URL into the corresponding URI fields. e. Repeat the previous step for each Web service URL required. 5. Click Save.

End User Personalization

The End User Personalization screen allows you to set the parameters that define the behavior of the fields and buttons on the Request Access screen. These parameters affect only the Request Access screen. They do not affect the Create Request and Copy Request screens when you log on as an Approver. Default Values The values defined in this field appear (pre-populated) when the end user opens the Access Request screen. Mandatory Setting this parameter to Yes requires the end user to enter a value in the selected field in order to submit a request. Editable Setting this parameter to Yes allows the end user to edit the value in the selected field. If the parameter is set to No, then the value in the field is displayed as read-only. Visible Setting this parameter to Yes makes the field visible to the end user on the Access Request screen. These parameter settings apply to every access request submitted. You cannot customize some parameters, because they default to either Yes or No based on the nature of the field. For example, a mandatory field must be visible on the Request Access screen. Therefore, the Visible parameter has a default value of Yes. The following table lists the fields and buttons that make up the Request Access screen. The fields are arranged by their logical grouping for conceptual context and accessibility to configuration information.

September 2008

113

5 Compliant User Provisioning End User Personalization

Field Action Group Attachments

Description

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

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

Cancel

Password Self Service

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

Requesting for Other User

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

Roles

Submit

This button allows users to submit a request.

114

September 2008

5 Compliant User Provisioning End User Personalization do that. Super Access The Superuser Access action type allows users to request a Firefighter ID (FFID) in Superuser Privilege Management from Compliant User Provisioning. Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Setting Visible to Yes makes the Select SuperUserAccess button visible. This button is disabled if the provisioning action SUPER_USER_ACCESS is not associated with the selected request type. Default Value Yes, you can select a value. Mandatory N/A Editable Yes/No Visible N/A Since users cannot submit requests without this information, the Mandatory and Visible parameters default to Yes. You cannot change these settings. Default Value Yes, you can select a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can select a value. Mandatory N/A Editable Yes/No Visible N/A Users cannot submit requests without this information. Default Value Yes, you can enter a reason. Mandatory N/A Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/No Visible N/A

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

Functional Area

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

Priority

This value determines how quickly a request is approved.

Request Reason

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

Request Type

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

Requestor Email

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

September 2008

115

5 Compliant User Provisioning End User Personalization Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Default Value N/A Mandatory Yes/No Editable Yes/Yes if data missing/No Visible Yes/No If the Editable parameter is set to Yes, if data missing, the field is editable only if the value is missing from the data source. Default Value N/A Mandatory N/A Editable N/A Visible Yes/Yes if data missing/No If the Visible parameter is set to Yes, if data missing, and the manager information is not associated with the user ID in the data source, then the search icon is displayed. Default Value N/A Mandatory Yes/No Editable Yes/Yes if data missing/No Visible Yes/No Default Value N/A Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can select a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can select a value. Mandatory Yes/No

Requestor Name

This is the requestors name.

Requestor Telephone

This is the requestors telephone number.

Manager Info Group Manager Email This is the managers email address.

Manager Information Lookup

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

Manager Name

This is the managers name.

Manager Telephone

This is the managers telephone number.

User Info Group Company This is the company name associated with the user requesting access.

Department

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

Employee Type

This is the status of the employee in the company.

116

September 2008

5 Compliant User Provisioning End User Personalization Editable Yes/No Visible Yes/No Default Value Yes, you can enter a value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/No Visible N/A Default Value N/A Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/No Visible N/A Default Value N/A Mandatory N/A Editable N/A Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/No Visible N/A Default Value N/A Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a default value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value Yes, you can enter a default value. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable Yes/Yes, if data missing/No Visible N/A Default Value N/A Mandatory Yes/No Editable Yes/Yes if data is missing/No Visible Yes/No

Location

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

User Email Address

This is the email ID of the person for whom the user is requesting access. This is the first name of the person for whom the user is requesting access. This is the unique ID of the person for whom you are requesting access. This is the search icon (magnifying glass) used to launch the search feature for user information. This is the last name of the person for whom the user is requesting access. This is the telephone number of the user for whom the user is requesting access. This field indicates the validity start date for a user.

User First Name

User ID

User Information Lookup

User Last Name

User Telephone

User Valid From

User Valid To

This field indicates the validity end date for a user.

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

Self User First Name

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

September 2008

117

5 Compliant User Provisioning End User Personalization Default Value N/A Mandatory N/A Editable Yes/Yes if data is missing/No Visible N/A Default Value N/A Mandatory N/A Editable N/A Visible Yes/Yes if data is missing/No Default Value N/A Mandatory N/A Editable Yes/Yes if data is missing/No Visible N/A

Self User ID

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

Self User Information Lookup

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

Self User Last Name

SNC Info Group SNC Name This field contains the name of the Secure Network Communication (SNC). You use the SNC value for Single Sign-On to systems that run in an ABAP environment and use SAP GUI as the front-end client. Default Value Yes, you can enter a value. Mandatory Yes/No Editable Yes/No Visible Yes/No

For more information, see SAP Note 1177556 Compliance User Provisioning SNC Parameters. Default Value Yes, you can select a value of Yes or No. Mandatory Yes/No Editable Yes/No Visible Yes/No Default Value N/A Mandatory N/A Editable N/A Visible Yes/No If Visible is set to Yes, this allows end users who are also approvers to approve/reject the request during the approval process. Default Value N/A Mandatory Yes/No Editable N/A Visible N/A Setting Mandatory to Yes

Unsecure Logon Allowed (SNC)

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

Validation Group Approve Reject Own Requests You can set Compliant User Provisioning to allow users to approve or reject their own access request. For compliance purposes, the default behavior prevents users from approving or rejecting their own requests. This allows you to restrict users to no more than one request submission for an application.

One User per Request per System

118

September 2008

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

Procedure To change the settings for a particular user: 1. On the Configuration tab, navigate to End User Personalization. The End User Personalization screen appears. 2. Select the name of the field you want to change, and click Change. A Change screen appears at the bottom of the screen. You can select only one field to change at a time. 3. From the Mandatory dropdown list, select Yes to require users to complete the field during Access Request submission or No to make the field not required. 4. From the Editable dropdown list, select Yes to allow users to edit the field during Access Request submission or No to make the field not editable. 5. From the Visible dropdown list, select Yes to allow users to see the field during Access Request submission or No to make the field invisible. 6. Click Save.

September 2008

119

5 Compliant User Provisioning End User Personalization

Frequently Asked Questions Question Where does Compliant User Provisioning obtain a users manager information? Answer The Access Request screen. The managers first name, last name, and email address can be entered with: Free form text entry fields. There is no validation of the field contents. The user search function in the Manager field on the Access Request. This uses the system configured for searching for the selected user. The search (magnifying glass) icon, entered manually and mapped from the LDAP or SAPHR system. However, to import the manager's information, the user data sources must be set to the LDAP or SAPHR system. If you are using the CUA as the user data source, encourage the requestors to use the search dropdown capabilities for accuracy. How do I set up End User Personalization so Ensure that the LDAP and SAPHR connectors are correctly set up in Access Control and that searching for manager information is verify that the appropriate connector is from the correct data source? configured as the user details source so that the manager information is retrieved. For more information on configuring connectors as user details source, see the section User Data Source Definition. In the End User Personalization screen, set the Manager Name, Manager Email, Manager Information Lookup, and Manager Telephone fields with the Editable parameter set to Yes if data is missing. Ensure that the Manager Information Lookup field is set with the Visible parameter to Yes.

120

September 2008

5 Compliant User Provisioning Technical Support Contact Identification

Question How do I prevent users from entering fake user IDs in the request form and only allow them to select a user ID using the search feature?

Answer On the End User Personalization screen, set the User ID, User Email, User Last Name, and User First Name fields with the Editable value to No. Ensure that User Information Lookup is visible. When users log on and make a request for others, they cannot enter data in the user information fields. They are then obliged to use the Search (magnifying glass) icon to query for a user ID.

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

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

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

Technical Support Contact Identification

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

Defining Contact Information Procedure To define contact information: 1. On the Configuration tab, navigate to Support.

September 2008

121

5 Compliant User Provisioning Available Request Attributes The Support screen appears. 2. In the System Administrator field of the Contact Information section, enter in the user ID of the primary contact. This user is usually a system administrator for Access Control. 3. In the Email Address field, enter the email address of the contact. 4. In the Phone field, enter the phone number of contact. 5. Click Save. Defining Support Screen information The Support screen is viewable by requestors from the Access Request screen by clicking Support. To define the Support screen information: 1. In the File Name field, enter the name of the HTML file containing the support information to be displayed when a requestor selects Support from the initial Access Request screen. Compliant User Provisioning provides a default Support page. However, you can create your own Support page and point to it by clicking Browse. Otherwise, click Restore Default to restore the original support page. 2. Click Import.

Available Request Attributes

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

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

Custom Fields
The Custom Fields option creates customized fields that are required for additional information or security. You can use custom fields to determine the workflow of the request or

122

September 2008

5 Compliant User Provisioning Custom Fields to extend the current attributes for the organizations requirements. Custom fields appear in the More Options section of the Access Request screen. For more information, see the sections Creating a Custom Field and Changing or Deleting a Custom Field. 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. The Custom Fields screen appears. 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, or select 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 information into this field, or select No to indicate that the end user is not required to enter information into this field. 8. From the Applicable To dropdown list, select whether this field is applicable to a role or request. 9. From the Workflow Type dropdown list, select the workflow to which you want this field to apply. 10. From the Field Type dropdown list, select Dropdown or Text. If you select Dropdown, a Data Source dropdown list appears. Select a data source. If you select SAP, you will be prompted to enter the following information: Source System - Select the SAP system for which the custom field will be applicable. Table Name Enter the SAP table from which to pull the custom field options. This field is case-sensitive. Field Name Enter the field from the SAP table above from which to pull the custom field options. This field is case-sensitive. If you select AE, a table of custom value fields appears. Use the and icons to add or delete fields. Enter the valid field values for your custom field. If you select Text, a Data Type dropdown appears as well as a Data Length text field. If you select Date, you are not required to enter a data length. If you select Numeric, enter a data length for the numeric character requirements. If you select Varchar2, enter a data length for the numeric character requirements.

September 2008

123

5 Compliant User Provisioning Service Level Period 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 Period

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

Request Type New Change

Priority High Medium

Condition Condition 1 Condition 2

If a request is submitted on 10/21/08 and the approval due date is 10/31/08, but it is actually approved on 11/05/08, the latter date is marked to indicate that a service level agreement for this request has been broken. Configuring a Service Level Procedure 1. On the Configuration tab, navigate to Service Level. The Service Levels screen appears. 2. Click Create. The Create Service Level screen appears. 3. In the Name field, enter the name of the service. 4. In the Short Description field, enter a short description of the service. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters.

124

September 2008

5 Compliant User Provisioning Workflow Management 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 is integrated with Risk Analysis and Remediation or Enterprise Role Management and you 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 be processed. 8. From the No. of Hours dropdown list, select the number of hours in which this new service 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 Details List. 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. 3. Make any modifications. 4. Click Save.

Workflow Management
Workflow management includes creating, modifying, deploying, activating, deactivating, and deleting workflows. Each workflow should replicate one of your organizations existing provisioning approval processes. About Workflows A workflow defines the required steps to approve the assignment of one or more roles to a specific user. Each access request specifies a distinct condition. When a request comes in, it triggers the specific workflow designed to manage requests with that particular condition. Although neither the requestor nor the approvers ever see the actual workflow, the workflow determines the approval process.

September 2008

125

5 Compliant User Provisioning Workflow Management Features Compliant User Provisioning uses workflows to automate the collection of approvals, and it can automate the provisioning process as well. Activities Every company has established processes for requesting and granting access to users, both for new employees and for existing employees whose role in the company changes. Each process requires two basic tasks: Obtaining all of the required approvals for role assignments Carrying out the actual provisioning process within SAP Workflow Components Each workflow is called by a initiator and contains one or more stages. When you create a workflow, you define elements. These elements are described in the following table. Workflow Component Elements Element Initiators Description An initiator is an object that defines a precise request condition, and identifies the single, unique workflow designed to handle that type of request. Initiators and workflows function as matched pairs. Each initiator can call only one workflow, and each workflow can be called by one initiator. A stage is a decision point in a workflow. At each stage, one or more approvers must approve or deny the request. The stage defines who must approve the request. It also determines what happens next, based on the decision of the approver. At each stage of the request process, the system sends an email message to the user designated to approve or deny the request. The request process cannot continue until the approver responds by approving or rejecting the request. A path defines the sequence of stages in a workflow. When you create a workflow, you begin by creating each of its stages. By themselves, the stages serve no purpose. Each stage is an independent entity, unrelated to any other stage. When you create a path, you define the order in which the workflow calls its stages.

Stages

Paths

126

September 2008

5 Compliant User Provisioning Workflow Management

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

September 2008

127

5 Compliant User Provisioning Workflow Management

Sample Workflows Compliant User Provisioning supports several variations of workflows: You can create a single initiator for multiple roles. While many enterprises choose to create their workflows so that each one defines the approval process for a single role, this is not required. If you have two roles that are always assigned to a user in tandem, you can create an initiator using a Boolean and operator, so that any request that includes both roles triggers the workflow. More commonly, a single workflow approves several different roles. You can create an initiator that uses a Boolean or operator. Any request that includes any of the roles defined in the initiator then triggers the workflow. Workflows must define what happens if an approver denies a request. It is natural to think of a workflow as a series of approvers granting access, but there are times when the requested roles conflict, or are inappropriate for the user. When that occurs, it is the responsibility of the designated approver to deny the request. Once the request is denied, you must determine how Compliant User Provisioning should handle the request. Do you want to abort the request or do you want to pass the request to security for analysis? If only part of the request has been denied, do you want to proceed with the remainder of the request? You can design detour workflows that trigger when an approver denies part of a request, or an escape route that aborts it. You can create a single initiator for multiple roles. To configure provisioning for your enterprise, you must understand these workflow variations described in the following sections. Basic Workflows The typical workflow is a path leading from a request for user access to the provisioning of that access. This kind of workflow is the main workflow. It defines request approval as a linear process, starting with the initiator and ending with approval at the final stage. The following figure illustrates this basic path.

128

September 2008

5 Compliant User Provisioning Workflow Management Basic Workflow with Three Stages

September 2008

129

5 Compliant User Provisioning Workflow Management This diagram shows the sequence of stages and identifies the designated approver at each stage. This type of path is typical, because its initiator is triggered by a request. The request condition that satisfies the initiator can include multiple attributes. The basic workflow is triggered by an initiator, which is configured with a workflow type. The standard workflow types are: CUP This is a workflow type for Compliant User Provisioning. Mitigation Control This is workflow type for mitigation purposes. Mitigation Control Assignment This is a workflow type for creating/modifying mitigation 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. The attributes define the workflow logic and determine how the request is processed through the designated path. The CUP workflow type provides the following attributes: Application Employee Type Request Type The ERM workflow type provides the following attributes: Request Type Priority Business Process Functional Area Company Request Priority

The SOD Review workflow type provides the following attributes: Application SoD Review Risk The User Access Review workflow type provides the following attributes: Application UAR Review Role The workflow types of Mitigation Control, Mitigation Control Assignment, and Risk do not have associated attributes. Most of the workflows you create are main workflows. For more information, see the section Creating New Workflows. Parallel Workflows It is possible for a single request to call multiple initiators and trigger multiple workflows. When this occurs, Compliant User Provisioning processes all of the triggered workflows simultaneously (in parallel). Parallel workflows work only when initiators are created at the role level. A request is split by roles into the parallel workflows. Priority Request Type Priority Request Type

130

September 2008

5 Compliant User Provisioning Workflow Management When the requestor submits the request and two initiators are satisfied, the system initiates two or more workflows. These workflows contain the same request number, and the Search Request screen displays the various paths. Although each path moves through its workflow individually, if multiple paths arrive at the same stage and same approver at the same time, the approver can approve once for the request and satisfy both (or all) paths. Example If the initiators are defined by roles and a user submits a request with two different roles that satisfy two different initiators, the system establishes a parallel workflow. If both paths call for the manager to be the first approver, the manager needs to approve the request only once for both workflow paths. Since the manager turns out to be the same user in both paths, Compliant User Provisioning sends only one approval email to that user, who needs to make only a single decision. Assuming the approver approves the request, Compliant User Provisioning proceeds to the next stage for each workflow. Since the two workflows have two different stages, it generates two different emails, one for each identified approver. It then waits for the approvers to take action. When both approvers approve their stages, Compliant User Provisioning moves on to the next stage. Since security is the next stage in both workflows, security has the ability to approve both requests with one approval, if both workflows arrive in the security stage at the same time, or security might approve each workflow individually. Detour Workflows Detours are stand alone workflows that assume the management of the request if specific conditions are met. If the conditioners are met, the request will actual change workflow paths and continue down the detour instead of the main path are determined by the initiator. For more information, see the section Detour Paths. Forked Paths Forked paths allow the request to split off of a single initiator based on the SAP or non-SAP applications selected on the request. For more information, see the section Forked Workflows. Workflow-Specific Configuration Tasks The configuration tasks described in this section relate to the creation of workflows. You must complete these tasks before migrating your provisioning processes into Compliant User Provisioning. These workflow-specific configuration tasks are explained in the following table.

September 2008

131

5 Compliant User Provisioning Workflow Management

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

132

September 2008

5 Compliant User Provisioning Workflow Management

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

September 2008

133

5 Compliant User Provisioning Workflow Management Activities When you are familiar with the Compliant User Provisioning workflow concepts and you have created a strategy on which to base your workflows, you can begin the definition process. You start by identifying the initiators you require and then creating them in Compliant User Provisioning. For more information on creating initiators, see the section Create Initiator. Next, you create the stages for your workflows. Identify these stages in your strategy before you create them in Compliant User Provisioning. Some of the stages you require probably exist as default objects. Compare the stages you need with the stages available to you, and create any additional stages. For more information, see the section Defining a Stage. If you prefer, you can create your stages before you create your initiators. It is often easier to create the initiators first, but it is unnecessary. However, you need to create both your initiators and your stages before you can create your paths. When you have defined the necessary initiators and stages, you are ready to create your workflow paths. For more information on creating a path, see the section Creating Main Paths. You can use these procedures to create all your main workflows. When you have done this, you can add escape routes to your workflows and create multi-path workflows, based on the applications included in the access request. For more information, see the sections Escape Route and Forked Workflow Creation. For more information about the concepts underlying escape routes and forked workflows, see the section About Workflows. Initiators Initiators are collections of request attributes that act as templates. When a user submits a request, the system compares the attributes of that request to all active initiators. If the attributes of the request match the attributes of an initiator, it uses the initiator to trigger a workflow. However, be careful not to create multiple initiators with the same attributes. This may cause the workflow logic to find multiple combinations and throw an error message. For example, if you create an initiator with the attributes Request Type and Priority, and then you create another initiator with the attribute Priority, the workflow logic finds the two combinations of attributes and throws an error message due to the multiple initiators. Similarly, if the workflow logic does not find an initiator, an error message is also thrown. Each initiator must have a unique combination of attributes. Every submitted request should match one initiator, and it should be impossible for a request to match more than one initiator. If a request is submitted that somehow satisfies multiple initiators, the request creation will fail.

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.

134

September 2008

5 Compliant User Provisioning Workflow Management 3. In the appropriate fields of the Initiator area, give the new initiator a name, short description, and long description. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 4. From the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled the workflow types on the Miscellaneous screen. 5. From the Attribute dropdown list, select an attribute to apply to the initiator. The attributes available are based on the workflow type you select. Each initiator must have at least one attribute and typically have two or more. Select attributes that, when combined, match all requests that trigger this initiator and, at the same time, exclude requests that trigger a different initiator. 6. Select a Value and a Condition for the attribute. The value defines how this attribute must match the same attribute in a request. For example, if the attribute you select is Functional Area, you might give the attribute a value of Finance. In that case, for a request to match this initiator, the user for whom the request is made must work in the Finance functional area. The condition you select is a Boolean operator. If you select AND, you specify that in order to match this initiator, a request must match not only this attribute (for example, Functional Area = Finance) but also other attributes that you specify (for example, Request Type = New). If you select OR, a request needs to match either this attribute or any other attribute that you specify, but not necessarily both, to match the initiator. The third option is NOT. In a NOT condition, the request cannot equal the choose attribute. Example You can have multiple attributes defined in your initiator. When defining the attributes make sure that the Boolean operators (AND, OR, NOT) are used correctly in order for all attributes to be considered. For instance, you want the initiator to consider two attributes. The two attributes are Functional Area = Finance and Request Type = New. By using the condition, AND, the two attributes are considered. Using the condition, OR, only one attribute is considered. The initiator configuration below shows two attributes with two conditions, but the workflow logic reads this configuration as Functional Area and Request Type. The OR condition is not considered. Condition Attribute Value OR AND Functional Area Request Type Finance New

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

September 2008

135

5 Compliant User Provisioning Workflow Management

OR Company SAP The initiator configuration takes the attributes of Functional Area and Request Type or Company. Either Request Type or Company is used to match the request. 7. Click Add Attributes to add the attribute and its value and condition to the initiator. 8. Continue to add attributes until the initiator meets your requirements: The initiator must match all of its intended requests. The initiator must not match any requests intended for other initiators. 9. Click Save. The new initiator is saved and the message Initiator Successfully Saved appears. For Superuser Access, you can create an initiator with the Super User Access request type 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 create the stage. However, you cannot identify an actual user to be the approver for a stage. Instead, you configure a determinator, which is used to identify the approver. This determinator includes the attributes of the user who can approve the request at this stage, typically based on the attributes of the request and is considered a Custom Approver Determinator (CAD). Example You create a stage named Application Approval, which is based on two attributes, Request Type and Priority. You also create a CAD named, App_Approver, which is configured with the same attributes. You set up the approvers for this CAD with the following: Request Type Priority Approver Name New New New High Medium Low FWilson BLaw MWong

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

136

September 2008

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

If you select Web Service, the fields where you can enter Web Service details such as URL, user name, and password appear. The Web service is called from Enterprise Role Management and retrieves a list of approvers. For example, if the Web service gets 20 approver names from Enterprise Management, an email notification is sent to all 20 approvers. 5. Select the attributes or type in the Web Service details. 6. Click Save. A success message appears. 7. Click Approver. The Approver Determinator Values screen appears. Depending on the attributes you have selected, this screen displays the attributes in the table column. 8. Click Add. The Approver Determinator Value pop-up screen appears. Use this screen to assign values to the attributes and operator.

September 2008

137

5 Compliant User Provisioning Workflow Management For the approver and alternative approver, click the arrow icon to search for approver and alternative approvers. Click the Add icon to search and select the approver and alternate approver. 9. Click Add. 10. Click Import. The File Import screen appears. 11. In the File Name field, enter the path and name of the file. Otherwise, click Browse to navigate to the file. 12. Optionally, select the Overwrite Existing Data to overwrite the existing import file. 13. Click Download Template to download a text file to mass update your custom approver determinator configuration. Use the template by adding more values to your selected attributes, operators, approvers and alternative approvers.

You can also export the modified file to mass update custom approver determinators in other systems by clicking Export. Stages There are two 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 a stage, you define the user who must approve or deny a request when the request reaches that stage. When you define a stage, you specify the approver for that stage. The term approver determinator defines the approvers for the request and how to identify the approver(s) of the stage. Configuring the stage: There are various optional configurations you can add to a stage to specify notifications, require risk analysis, and manage security. When you configure a stage, you determine which options apply. Defining a Stage Procedure 1. On the Configuration tab, navigate to Workflow > Stages. The Workflow Stages screen appears. 2. Click Create. The Stage Configuration screen appears. 3. In the Stage Details area of the Stage Configuration screen, enter a name, short description, and description for the new stage in the appropriate fields. The name you enter for the stage must be unique. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters.

138

September 2008

5 Compliant User Provisioning Workflow Management 4. From the Workflow Type dropdown list, select a workflow type for the stage. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled the workflow types on the Miscellaneous screen. 5. From the Approver Determinator dropdown list, select the approver determinator for the stage (that is, how to identify the approver(s) of the stage). It is important to select the correct approver determinator. The approver determinator is used at runtime to derive the approver for the stage. If you select No Stage, the system automatically approves requests for the users and roles going through this stage. For example, you can provision users with certain basic roles with no approval required. If you select Superuser Access Coordinator, the system gets the configured controller from the SAP system where the Superuser Privilege Management is installed and assigns the request to that approver. If you select Superuser Access Owner, the system fetches the configured owner from the SAP system where the Superuser Privilege Management is installed and assigns the request to that approver. 6. In the Request Wait Time fields, enter the amount of time (days and/or hours) you want Compliant User Provisioning to wait at this stage for an approver to respond to a request before escalating the request. You need to do this only if you plan to configure the stage to escalate if the approver does not respond. If you do not plan to define an escalation action, you can ignore these fields. 7. From the Escalation Configuration dropdown list, select how to handle a request when an approver fails to respond within the time allotted during stage definition: No Escalation (default setting): Compliant User Provisioning waits for the approvers response, even after the specified wait time passes, and does not take any steps to resolve the stalled request. The approver approves or rejects the request. An administrator can manually resolve the problem by approving on behalf of the assigned approver, forwarding the request to another approver, or rerouting the request. For more information, see the section Request Administration. Forward to Next Stage: Compliant User Provisioning ignores the expected approval at this stage and proceeds to the next stage in the path. If you select this option, even if the designated approver does not respond to the request, it does not prevent the request from being approved. Use caution with this option since it allows the request to bypass the defined approvers. Forward to Alternate Approver: Provides a fallback option if the designated approver does not respond within the time allotted. Compliant User Provisioning reassigns the approver. Alternate approvers must be maintained for the approver determinator of the stage where this option is set. Escalation to an alternate approver happens only once; there is no alternate approver for the alternate. After the system escalates the approval for the stage to the alternative approver, the original approver no longer has access to approve or reject the request. Forward to Administrator: If the approver fails to respond within the allotted time, Compliant User Provisioning forwards the request to the administrator. The

September 2008

139

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

Configuring a Stage Procedure 1. In the Workflow Stages screen, click the name of the stage to configure. The Stage Configuration screen for that stage appears. 2. In the Notification Configuration section, define the notifications for the system to generate at this stage. Select which users receive emails for each possible action, and compose the message to accompany the notification. 3. In the Additional Configuration section, define any additional functionality required at this stage. 4. In the Additional Security Configuration screen, define whether or not the approver needs to reaffirm their actions by entering their password. Actions that can be configured to require password reaffirmation are: Approve Reject Create User (automatic creation of a new user record) 5. Click Save. Configuring Notifications The Notification Configuration screen configures email notifications for a stage to determine whether and to whom the system sends notifications about the actions taken at this stage. There are four possible actions: Approved: The system sends the email notification configured on the Approved tab when the approver approves the request. Rejected: The system sends the email notification configured on the Rejected tab when the approver rejects or denies the request.

140

September 2008

5 Compliant User Provisioning Workflow Management Escalation: The system sends the email notification configured on the Escalation tab when the approver fails to respond to the request within the allotted wait time and an escalation has occurred. Next Approver: The system sends the email notification to the approver(s) of the stage when the request enters this stage. The next approver is the approver of the current stage. The users you select next to each possible action are the users who are notified when that action takes place. You must schedule the Email Dispatcher background job to automatically send these notifications. For the next approver, there is no way to turn this feature off or add additional users to receive the emails. The background job automatically sends the next approver emails to each approver of the stage. To determine who receives these emails, select the appropriate users when the corresponding action occurs. In each email notification, a link allows the recipient to access Compliant User Provisioning in display mode of the request. The next approvers email link takes the recipient into approver mode of the request. All other links go to the display mode of the request. Use caution when determining which email notifications to send to which users. Too many email notifications can annoy the recipients. Configure email notifications for users only if it is necessary for those users to receive notifications at this stage or action of the request. Remember that you can also send submission and closing emails. User: Sends email notification to the user listed on the request. Requestor: Sends email notification to the requestor listed on the request. Manager: Sends email notification to the manager listed on the request. If no manager is listed, no email is sent. (This does not cause an error.) Other Approvers: Sends email notification to all approvers that have been involved in the request up to and including this stage. If the user, requestor and/or approvers are the same, each receives multiple email notifications. When sending an email notification to the user and the requestor, if the user is the requestor, the system sends two email notifications. If the requestor and the manager are the same user, that person receives two emails. Select these email notification options with caution. If users receive too many email notifications, they get used to ignoring them or get frustrated due to the amount of unnecessary email they are receiving. In addition, you can compose a different rich text or HTML message for each action you select to accompany the notification. Click the tab that corresponds with the notification action you select, and enter your message in the field provided. Select the appropriate Email Arguments from the dropdown list when configuring your notification. Email arguments allow you to include specific information in the email. You can change these arguments or cut and paste them into the subject line. If the email content for the next approver is not configured, the approvers of this stage receive a blank email with only a link to this request in Compliant User Provisioning when requests enter this stage. Email content is limited to 2000 characters.

September 2008

141

5 Compliant User Provisioning Workflow Management Additional Configuration The Additional Configuration screen refines the behavior of a stage. The options available depend on the workflow type you select when you initially define your stage. Decide what functions you need, and select the appropriate option from each dropdown list. Several of these settings work in conjunction with each other. When you make a selection, all future options are based on that selection. Some fields become available and others become unavailable. Risk Analysis Mandatory: Select Yes or No to determine whether the approver is required to perform a risk analysis before approving the request. Change Request Content: An approver has the authority to change the content of the request. o o If set to Yes, the Add Roles field becomes available for selection. Select Yes or No to allow roles to be added during this stage. If set to Yes, the Path Evaluation For New Roles field becomes available for selection. This setting determines how the roles are evaluated to see if they are on the correct path (This is necessary only if you configure your initiators by roles). All Roles in Evaluation Path: All roles are re-evaluated against the initiators. New Roles Only: These new roles are analyzed against the initiators to determine if another parallel workflow mist be created for the newly added roles. None: No re-evaluation is conducted. o o If the Change Request Content configuration option is set to Yes but Add Roles is set to No, the approver can remove roles from the request but not add additional roles. If the Change Request Content configuration option is set to No, the approver cannot change the roles on the request. They cannot reject or remove roles nor can they add 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. When they are approving all roles or when they reject, they are rejecting all roles. For example, manager and security approvers can approve or reject any role on the request. Role: Approvers can only approve those roles that belong to them. This option is especially useful for role approvers. System and Role: Approvers have the ability to approve the system and roles.

o o

Reject Level: The approver has the authority to reject the request at the Request, Role, or System and Role levels. o Request: The approver has the authority to reject all roles on the request. When they are approving all roles or when they reject, they are rejecting all roles. For example, manager and security approvers can approve or reject any role on the request. Role: Approvers can only reject those roles that belong to them. This option is especially useful for role approvers. System and Role: Approvers have the ability to reject the system and roles.

o o

Approval Type: Select whether any one approver can approve at this stage, or whether all approvers must approve at this stage, for the request to move on to the next stage. Email Group: A feature no longer used. It remains on the screen for backwards compatibility.

142

September 2008

5 Compliant User Provisioning Workflow Management Comments Mandatory: Select whether the approver is required to enter comments when approving or rejecting the request. If you set this option toYes, checkboxes appear to allow the user to specify when comments are required (on Approvals, Request Rejections, or both). Request Rejection: If you set this option to Yes, the approver is allowed to reject the entire request. The Reject button appears next to the Approve button, so the approver can reject the entire request without individually rejecting each role. If No, the approvers can reject roles on the request without the ability to reject the entire request. Re-Route: The approver has the authority to re-route the request to a previous stage as an alternative to rejecting the request entirely. Re-routing does not apply if the approver chooses to approve the request. Confirm Approval: The approver must answer an additional question, if he or she wants to confirm the approval action. Confirm Rejection: The approver must answer an additional question, if he or she wants to confirm the rejection action. Reject by Email and Approve by Email: The approver can reject or approve the request by email. o If you set this option to Yes, there could be two additional links on the email when the approver gets the email notification for this stage, stating that there is a request waiting for action. One link is for the Approve Request Action, if Approve by Email specifies Yes. Another link is for Reject Request Action, if Reject by Email specifies Yes. The approver can use these buttons, and the link transfers them to Compliant User Provisioning. The approver must still be the valid approver for this stage of the request and must enter his or her user ID and password. In order for an approver to be able to reject by email, the Request Rejected field must be set to Yes. 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 an option if actions are required; for example, if risk analysis or comments are required. o If you set this option to Yes, there could be an additional link on the email when the approver gets the email notification for this stage, stating that there is a request waiting for action. The approver can use this button, and the link transfers them to Compliant User Provisioning. The approver must still be the valid approver for this stage of the request and must enter his or her user ID and password. If you set this option to No, these buttons do not appear in the email notification to the next approver.

Approve by Email: Options will allow the approver to approve the request by email. This setting will not be an option if actions are required for instance if Risk Analysis or Comments are required. o If you set this option to Yes, there could be an additional link on the email when the approver gets the email notification for this stage, stating that there is a request waiting for action. The approver can use this button, and the link transfers them to Compliant User Provisioning. The approver must still be the valid approver for this stage of the request and must enter his or her user ID and password. If you set this option to No, these buttons do not appear in the email notification to the next approver.

September 2008

143

5 Compliant User Provisioning Workflow Management Forward: The approver has the authority to forward the request to someone else for approval. Approve request despite risks: o o If you set this option to Yes, the approver is allowed to approve this stage, even if there are SoD violations that have not been mitigated. If you set this option to No, the approver at this stage must remediate (remove) or mitigate the violation before he or she can approve the request. The approver is required to enter comments when approving or denying the request.

Forward Type: Options Any One Approver or All Approvals: If you select the Forward option, you can specify whether: o o Any one of the approvers that the request is forwarded can approve and the request can continue on. All approvers listed on the Forward are required to approve before the request can continue on.

Additional Security Configuration The Additional Security Configuration screen specifies whether the approver needs to confirm his or her identity to take an action at this stage. Approvers confirm their identities (reaffirm their decisions) by entering their password at a prompt when they take an action. The actions that can be configured to require reaffirmation are: Approve Reject Create User Paths After creating and configuring initiators and stages, you can create workflow paths. There are three different procedures for creating paths: Creating a Main Path Creating a Detour Path Adding a Detour to a Main Path Creating Main Paths Procedure To create a main path: 1. On the Configuration tab, navigate to Workflow > Path. The Workflow Paths screen appears. 2. Click Create. The Create Path area appears at the bottom of the screen. 3. Enter the details of the path in the fields provided: a. Enter a Name. The name of the path must be unique. It might also be useful to give the path both a name and a description that are easy for you to identify later. b. Enter a Short Description.

144

September 2008

5 Compliant User Provisioning Workflow Management The short description appears in dropdown lists throughout Compliant User Provisioning as an option when you perform a query. This field is limited to 38 characters. c. Enter a Description. The description is longer than the short description and can contain more detailed information. d. Select a Workflow Type. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled the workflow types on the Miscellaneous screen. 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 which the 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 this checkbox selected, the path becomes a detour. If it is a detour, it cannot have an initiator, and the system does not allow you to save it. You cannot change a path after a request has been submitted on it. To deactivate a path and reuse the initiator on another path: Remove the active flag on the path. Check the Detour checkbox to make the path a detour. Remove the initiator. Now the path is deactivated, and the initiator is available to be used in another path. Any request that has started using this path will finish, even though it is now inactive. It is inactive for new requests only. When you finished entering these details, the system displays a graphical representation of the path. 4. Click Save. A Workflow Path Successfully Saved message is displayed. When you return to the Workflow Paths screen, the new path is listed.

Detour Paths Detours are standalone workflows that assume management of a request from a main workflow. Detours are not subsets or dependents of main workflows. They do not have initiators, so they cannot be triggered by a submitted request. If the state of a request meets predefined conditions, a main workflow passes control of the request to a detour workflow. The type of event that triggers a detour is typically one that prevents a main workflow from proceeding on its defined path. If something occurs that interferes with a request, the main workflow can be configured to pass the request to a detour workflow. For example, you can design a workflow to handle a single request that includes more than one role. If an approver denies one of the roles in the request, you might want the remainder of the request to proceed. Rather than aborting the request, you can have the main workflow transfer it to a detour workflow. The detour can then continue the approval process for the remaining roles.

September 2008

145

5 Compliant User Provisioning Workflow Management

When the main workflow passes a request to a detour workflow, the request ceases to be associated with the original workflow and is managed by the detour workflow. The structure of a detour workflow is similar to the structure of a main workflow. It has a defined starting point and a sequence of one or more stages. At each stage of the detour, an approver must approve the request before it can proceed. You create a detour using the same procedures that you use to create a main workflow. For more information, see the section Creating New Workflows. For more information about how to define a jump from a main workflow to a detour, see the section Path Creation. Procedure To create a detour path: 1. On the Configuration tab, navigate to Workflow > Path. The Workflow Paths screen appears. 2. Click Create. The Create Path area appears at the bottom of the screen. 3. Enter the details of the detour path in the fields provided: a. Enter a Name. The name of the path must be unique. It might also be useful to give the detour both a name and a description that are easy for you to identify. b. Enter a Short Description. The short description appears in dropdown lists in different places throughout Compliant User Provisioning as an option when you perform a query. This field is limited to 38 characters. c. Enter a Description. The description is longer than the short description and can contain more detailed information. d. Select a Workflow Type. e. In the No. of Stages field, enter the number of stages you want to include in the detour 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 graphical representation of the detour path. 4. Click Save. A Workflow Path Successfully Saved message appears. When you return to the Workflow Paths screen, the new path is listed.

146

September 2008

5 Compliant User Provisioning Workflow Management Adding Detours to a Main Path Procedure To add a detour to a main path: 1. On the Configuration tab, navigate to Workflow > Detour/Fork. The Workflow Stage Detour screen appears. 2. Click Create. 3. Enter the details of the connection between the main path and the detour path. Working from left to right: a. In the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with Risk Analysis and Remediation or Enterprise Role Management and you have enabled Workflow Types on the Miscellaneous screen. 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 the request 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 the detour. Valid detour conditions are: SoD Violations: When the Risk Analysis is run and there are SoD risks, requests with SoD violations meet this condition, even if the risks are mitigated during the request approval process. No Role Owners: When no role approver is associated on the request. Roles with No Role Owners: When some roles on the request have role approvers and some do not, the request splits into a parallel workflow with those roles with no role approvers routed directly other than the roles with role approvers. Verification/Training Failed Request Level: When a verification/ training system has been implemented and Compliant User Provisioning is configured to verify training. Role Verification/Training Failed Role Level: When a verification/ training system has been implemented and Compliant User Provisioning is configured to verify training. NDA Not Signed For Insider Roles: Not generally used. f. In the Value dropdown list, select Yes or No to specify whether the detour executes in the presence of the condition defined in the Condition field or in its absence. If you select Yes, the detour executes only when the specified condition occurs. If you select No, the detour executes only when the condition does not occur. g. In the Detour Path dropdown list, select the detour path to which you want to connect the main path. 4. Click Save.

September 2008

147

5 Compliant User Provisioning Workflow Management A Workflow Detour Successfully Created message appears. The detour configuration is now listed on the Workflow Stage Detour screen. After a request routes to a detour, it completes the workflow on the detour path. A detour does not route back to the original path.

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

148

September 2008

5 Compliant User Provisioning Workflow Management In most cases, the terms workflow and path are interchangeable, because the majority of workflows employ only one path, and these workflows are indistinguishable from their paths. Forked workflows are the exception. A fork is a workflow that has two distinct paths, specifically to handle requests for access to different types of applications. The distinction between these types of applications is whether or not they are native SAP applications. Compliant User Provisioning provides forked workflows to manage requests for access to both SAP and non-SAP applications. You create a workflow fork if: You create a single workflow and initiator that can be triggered by an access request for either an SAP or a non-SAP application (or both). You want to use a different path to handle access requests for SAP applications than the one it uses to handle requests for access to non-SAP applications. You can, of course, define two initiators and two workflows, one to manage each application type. However, creating a single workflow to handle both can simplify the task of creating initiators and workflows. You create a forked workflow by joining two distinct, independent paths. At least one of these paths must be a main path, triggered by an initiator. A forked workflow begins with one path and then joins a second path to it. The first path must be a main path. The second path can be either a main path or a detour. The procedure that follows describes how to join two existing paths together to form a fork. If the fork you want to create includes paths that do not exist, you must create the paths before you can create the fork. For more information, see the section Path Creation.

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

d. From the Condition dropdown list, select the condition that must occur to execute the forked path. e. From the Value dropdown list, select either Yes to specify if the workflow occurs in the presence of the condition defined in the third dropdown list, or No to specify if the workflow forks in its absence. f. If you select Yes, the request follows the fork only when the specified condition occurs. If you select No, the request follows the fork only when the condition does not occur.

g. From the Fork Path dropdown list, select the alternative path you want to join to the primary path to form the fork.

September 2008

149

5 Compliant User Provisioning Email Reminder Setup 5. Click Save. A success message appears. The new fork is listed on the Path Fork tab of the Work Flow Stage Detour screen.

Email Reminder Setup

You can configure email messages to communicate with users, requestors, managers, and approvers. You can also configure email reminders to send request progress notifications to interested parties and reminders to approvers who have failed to act within a specified time period. The configuration process is the same for both reminders and notifications. On the configuration screen, you can determine whether or not to send the password to a user when the user is created in the back-end system. Several companies have implemented a Single Sign-on procedure in which the user does not need to log on to each system with a separate user ID and password. If you set up something similar, do not include the password in the new user ID notification email. When the system sends a password, it sends a link to the password display, not the password itself. In addition to being able to configure whether the password is included in the email, you can specify how long the user can access the password using the link included in the email. For every new user created in the system, the system automatically sends an email notification to the user. This email goes to the email address listed on the request and includes the new users ID and the list of systems that the user can access. The system sends the email notification automatically; it is not configurable. For security notification 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 included in 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 you want to configure. There are several different types of email notification. You can configure the content of the email messages based on the type of notification. The options that appear on the dropdown lists are the short descriptions of the workflow types that you configured on the Miscellaneous screen. 3. In the Days field, enter the number of days after the event that an email reminder is generated. Typically, this only applies to reminders. In most cases, email notifications are generated immediately upon submission or completion. 4. In the Subject and Comment fields, enter text.

150

September 2008

5 Compliant User Provisioning Email Reminder Setup 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 notify approvers. In the Notification Configuration section, select the Other Approvers checkbox. Submission: When a request is submitted, an email reminder can be sent to notify the user, the requestor, the manager and other approvers. In the Notification Configuration section, select the checkboxes. The email reminder includes a link to view the status of the request. Closing: When a request is closed, an email reminder can be sent to notify the user, the requestor, the manager and other approvers. In the Notification Configuration section, select the checkboxes. 6. In the Subject and Content fields, enter the appropriate text. You can also add specific request data to the email reminder in the Content fields. The email argument variable can be copied into the Subject field of the email. 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, Other Approvers. 8. Click Save. You can also add specific request data to the email reminder. The email argument variable can be copied into the Subject field of the email. Setting Up New User Password Notifications Procedure 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 seconds for 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 Approver Not Found condition at the first stage. The purpose of an escape route is to prevent a request from being trapped in an irreconcilable situation by causing the request to bypass one or more stages of the workflow. If a workflow encounters an Approver Not Found condition at the first stage, it sends the request to another workflow where the approver is found. When you create an escape route, you determine how many stages the request skips or where the request is sent if an approver is not found. From there, the request follows the escape route workflow until the end of that workflow. When a request takes a path other than its intended path, there can be security consequences. Since a request bypassing approval stages presents a risk that it might not meet security requirements, one common application of escape routes is to pass the request directly to a security stage, where the request can be evaluated.

September 2008

151

5 Compliant User Provisioning Email Reminder Setup After the request has been evaluated, the security user routes the request to the appropriate path and stage. There are three escape route conditions: Approver Not Found Approver Not Found at a Stage Auto Provisioning Failure These conditions exist globally for the implementation of Compliant User Provisioning and cannot be determined by the workflow path. Only one escape route can be created and only for one of the conditions. You cannot define three escape routes, one for each condition. Use caution with escape routes for Approver Not Found conditions. Every request where the approver is not found proceeds down the same escape route. This could cause an issue if your company has several workflow paths configured. Approver Not Found Approver Not Found can apply only to the first stage of the path if an approver is not found on submission of the request. Approver Not Found applies to all requests submitted. It cannot be set for specific workflow paths. Approver Not Found is a very specific condition. It informs you that the workflow cannot derive the identity of the designated approver, because the attributes of the approver are either ambiguous or inadequate. If Compliant User Provisioning cannot determine who the first approver is, the email notification cannot be sent, and the system responds with an Approver Not Found message. Only in these cases will the request follow the escape route instead of the route by configured on the initiators. Approver Not Found at a Stage Approver Not Found at a Stage resolves the situation when the next approver cannot be found. In this case, the request transfers to the escape route instead of displaying the error of Approver Not Found to the current approver. Approver Not Found at a Stage applies to all requests submitted on all workflows. It cannot be set for specific workflow paths or specific stages. Auto Provisioning Failure Auto Provisioning Failure is triggered when auto provisioning failures occur. You can establish an escape route to send the requests to security or to a Compliant User Provisioning administrator. If this escape route is not configured and an error occurs during auto provisioning, the current approver receives the error message, but cannot approve or close the request. The request waits in this approvers inbox until the provision situation has been cleared. After this approver is cleared, he or she must approve the request again, so that the request is provisioned and closed. Since an escape route is an attribute of a workflow, you must create a workflow before you can add an escape route to it.

152

September 2008

5 Compliant User Provisioning SMTP Server Identification Configuring an Escape Route Procedure To configure an escape route: 1. On the Configuration tab, navigate to Workflow > Escape Route. The Escape Routes screen appears. 2. In the Escape Route - Conditions area, specify the details of the escape route: a. From the Workflow Type dropdown list, select a workflow type. The Workflow Type option is available only if Compliant User Provisioning is integrated with other Access Control capabilities and you have enabled the Workflow Types on the Miscellaneous screen. b. From the Condition dropdown list, select Approver Not Found, Approver Not Found at a Stage, or Auto Provisioning Failure. c. From the Path dropdown list, select the path that the request follows if the conditions are met.

d. From the Stage dropdown list, select the stage of the specified path that the request follows if the conditions are met. 3. Click Save. 4. From the Escape Routing Enabled dropdown list, select Yes if using escape routes or No if you choose not to use them. If you select No, the system ignores any escape route, even if some are configured. 5. Click Save. A Successfully Saved Escape Route Configuration message appears.

SMTP Server Identification

To send notification emails to the users, requestors, and approvers of the requests, you must configure Compliant User Provisioning to use the correct mail server. Compliant User Provisioning communicates with approvers through email messages. If this setting is not properly configured, the approval process does not work properly. Emails sent by Compliant User Provisioning to notify requestors, approvers, and administrators are not delivered and the process stops.

Configuring the SMTP Server Procedure 1. On the Configuration tab, navigate to Workflow > SMTP Server. The SMTP Server screen appears. 2. In the Email Server Name field, enter the name of the SMTP server that Compliant User Provisioning uses to transmit messages. 3. Click Save.

September 2008

153

5 Compliant User Provisioning CUA System Setting Configuration

Emails are not sent automatically. To send the emails, run the Email Dispatcher as a background job. For more information, see the section Setting Up Background Jobs.

CUA System Setting Configuration

This setting applies only to SAP implementations that employ a Central User Administration (CUA) system. CUA and Compliant User Provisioning work well together, so it is not necessary to choose between the two. There are reasons to use the CUA and reasons to use Compliant User Provisioning. CUA manages users and their access in the child systems. Compliant User Provisioning provides the access request ability, audit trails for the approvers on the requests, and provisions the approved roles to the CUA. When a request is provisioned in Compliant User Provisioning and the CUA is used, Compliant User Provisioning provisions the requested roles to the CUA. The CUA pushes those roles down to the child systems. Compliant User Provisioning allows the CUA to manage the access in the child systems. You must create connectors and install the appropriate RTAs on those systems for the CUA parent system, as well as each of the CUA client systems. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3. Compliant User Provisioning performs all inquiries and searches against the child client itself; it only completes provisioning with the CUA parent. Requestors and approvers request and approve the access to the individual applications (child system clients), but you provision the access with the CUA. The CUA system setting can be a global setting in Compliant User Provisioning, or it can be set by each individual system connector. Therefore, some of your systems can be connected to a CUA and others not connected, but both can be provisioned through Compliant User Provisioning. Since most of the activity between the requestor and approver occurs directly within the application itself, the only difference is that a CUA client is where the user and roles are provisioned. If it is a CUA child system, provisioning happens on the CUA parent, whereas a non-CUA system provisions to itself. You must load roles for the CUA child clients into Compliant User Provisioning to make them available for the requestor to select them through the Select Roles functionality. Do not load CUA child system roles assigned to the CUA parent system into Compliant User Provisioning; load them only to the child systems. Configuring the CUA System Setting Procedure For organizations with complex SAP landscapes consisting of many SAP systems, SAP recommends that you use CUA for user administration tasks. Using CUA enables security administrators to maintain user master records centrally from one system. Compliant User Provisioning provides the ability to perform user provisioning centrally from one system, but it does not replace CUA. Compliant User Provisioning deals mainly with compliant automated provisioning.

154

September 2008

5 Compliant User Provisioning CUA System Setting Configuration To configure Compliant User Provisioning with CUA properly, you must: Configure connectors for the master system and child system(s) Configure the CUA master system Perform troubleshooting, if needed Configuring Connectors for Master System and Child System Procedure To configure connectors in Compliant User Provisioning: 1. Make sure that the connector names in Compliant User Provisioning are exactly the same as the logical system names defined in the CUA master and child systems. From your SAP server (back-end system), start transaction SCUA. The Maintain System Landscape appears. The name displayed in the Sending System field is the master system, while the child systems are listed in the Recipient column. 2. Configure the master system. Go to Compliant User Provisioning > Configuration tab > Connectors > Create Connectors. The Connectors screen appears. 3. In the Connector Type dropdown menu, select SAP. 4. In the Name field, enter the logical system name of the CUA master system. 5. In the Short Description field, enter a brief description of the connector. 6. In the Description field, enter a long text description of the connector. 7. In the Application field, enter the name of the application or application server. 8. In the Application Server Host field, enter the host name of the application server. 9. In the System Number field, enter the number in the SAP system log. 10. In the Client field, enter the SAP client number. 11. In the User ID field, enter the user ID you are configuring to have access to the backend system. The user ID must have the appropriate security access to perform each of the tasks required. If provisioning is configured for this connector, the user ID must be authorized to maintain users in the SAP system. If provisioning is configured, this user ID appears on each change record on the SU01 user master record. For more information about user ID authorization, see the SAP GRC Access Control 5.3 Security Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions 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 to view/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 BASIS administrator provides this information. 14. In the Message Server Name, enter the name of the message server, which is used for load balancing of your SAP clustered environment. 15. In the Message Server Group, enter the group name to which the message server belongs. Your BASIS administrator provides this information.

September 2008

155

5 Compliant User Provisioning CUA System Setting Configuration 16. In the Message Server Host, enter the host name of your message server. Your BASIS administrator provides this information. 17. In the SAP Version dropdown menu, select the appropriate SAP version. Compliant User 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 system is used or not. An HR system flag indicates whether the SAPHR module is installed on this connector, not necessarily whether you are using the SAPHR module. If the system is an HR system, the appropriate HR RTAs must be installed. For more information, see the SAP GRC Access Control Installation Guide. 19. In the SLD Connector checkbox, select this checkbox to enable the Standard Landscape Directory. 20. In the Connector Category dropdown menu, select the category to which the connector belongs. The choices are Production, Non-Production, or Other. This selection is used to help classify the servers into the appropriate categories in the access request forms. 21. In the Role dropdown menu, select whether or not role information comes from Enterprise 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 the Manager field value to be automatically populated from the users HR record, set this field to (B012) Managers. b. If you want the Reports to line value to be automatically populated from the users HR record, set this field to (A002) Reports (line) to (for organizational units). SAP HR provides an organizational structure view that contains the object, relationships, and attributes. The organizational structure view contains the relationship types, B012-Managers and A002- Reports to. 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 set in Compliant User Provisioning. Procedure To configure Compliant User Provisioning with CUA: 1. Go to Compliant User Provisioning > Configuration tab > Workflow > CUA System. The CUA System screen appears. On the Global tab, the Systems dropdown menu displays a list of all SAP systems configured as connectors.

Make sure that the master system and child system/client are created as an SAP connector.

156

September 2008

5 Compliant User Provisioning CUA System Setting Configuration 2. On the Global tab, select the correct system as your CUA parent system. If your environment uses a CUA system, select the CUA host from the list of connectors. If your environment does not use a CUA system, make sure that there is no host selected. The System dropdown menu should show, --Select--. 3. Click Save. If your system does not use a CUA, the configuration is finished. If your system does use a CUA, continue with the next steps. 4. In the Function Template fields of both the CUA User Provisioning Configuration and CUA Role Provisioning Configuration areas, select either Standard or Custom. Select Standard triggers Compliant User Provisioning to use out-of-the-box programs for CUA provisioning. Select Custom if you have developed custom CUA BAPIs. If you are using custom BAPIs, contact SAP Technical Support to ensure that your BAPIs integrate correctly with Compliant User Provisioning. If you select Custom in either area, the Function Template Name field appears. 5. Enter the name of your custom template. 6. Click Save. 7. On the By System tab, you can overwrite the global CUA setting for any or all system connectors. To add another system to this table, click Create. To change an existing CUA system configuration, select the system and click Change. All available fields for changing appear editable. 8. If you have selected Create, select the other system you wish to add from the System dropdown menu,. 9. In the Consider For CUA field: If the system is a child client using a CUA, select Yes. If the system is not using the CUA select No. 10. In the CUA System field, if the system is configured as a CUA child client, select the system connector. 11. You can configure multiple CUAs. To do so, select the CUA system that is connected to the child system you are maintaining. 12. For each field, User Provisioning Function Template and Role Provisioning Function Template, select Standard or Custom. If you select Custom for either field, a Function Template Name field appears. 13. Enter the template name. 14. Click Save. Troubleshooting for CUA Provisioning You can troubleshoot any issues concerning CUA provisioning from Compliant User Provisioning.

September 2008

157

5 Compliant User Provisioning Auto Provisioning Procedure To troubleshoot CUA provisioning from Compliant User Provisioning: 1. From your SAP server (backend system), start transaction SU01. Make sure that the Compliant User Provisioning service role /VIRSA/AE_DEFAULT_ROLE delivered with the RTA, or an equivalent customized (Z) role copied from the role that you defined previously, is assigned to the service user ID in the connectors for all master and child systems. 2. If step 1 is not successful, you can also modify the application name and short description of the connectors to be the same as the connector name. Go to Compliant User Provisioning > Configuration tab > Connectors > Available Connectors. 3. Select the connector and click Change. 4. Modify the entries in the Short Description and Application fields to be the same as the Name field. 5. Click Save.

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

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

158

September 2008

5 Compliant User Provisioning Auto Provisioning Configuring Global Settings for Auto Provisioning Procedure To configure global settings for auto provisioning: 1. On the Configuration tab, navigate to Workflow > Auto Provisioning. The Auto Provisioning screen appears, displaying the Global tab. 2. Under Auto Provisioning Provisioning Type, from the Default Role Provisioning Type dropdown list, select the type: Direct: Most companies use Direct provisioning. This method allows Compliant User Provisioning to modify the users master record directly, changing the users assigned permissions as defined in the request. Indirect: If you select InDirect, you must select the type of HR object Compliant User Provisioning needs to transmit to the HR module. There are three possible object types: Position, OrgType, and Job. Combined: During provisioning, the system tries to use InDirect provisioning. If it fails, it tries Direct provisioning. If you select Combined, you must select the type of HR object Compliant User Provisioning needs to transmit to the HR module. There are three possible object types: Position, OrgType, and Job. These settings can also be configured by system. For more information, see the section Configuring Auto Provisioning by System. 3. Click Save. 4. Under Auto Provisioning Provisioning Options, from the Auto Provisioning Type dropdown list, select the type: Auto Provision At End of Request: Select this option to begin provisioning when all of the workflow paths in the submitted request are approved. Auto Provision At End of Each Path: Select this option to provision the access requested for each path as the path is approved. This method works only when the request splits into parallel workflows. No Auto Provision: Select this option to turn off auto provisioning 5. Click Save. 6. Under Auto Provisioning Provisioning Change Request Options, select one of the following values from the Create If User Does Not Exist dropdown list: If you want the provisioning process to automatically create the user, select Yes. If you do not want the provisioning process to automatically create the user, select No. This setting is used only for requests of type Change and only where there is no record of the user. 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.

September 2008

159

5 Compliant User Provisioning Auto Provisioning 9. Click Save. 10. Under Password Expiration for ORAAPPS, select the basis on which the password expires: after a certain number of days, accesses, or not at all. If you select Days or Accesses, a field in which you can enter the number of days or accesses becomes active. 11. Enter the number of days or accesses, if required. 12. Click Save. 13. Under Provisioning Role Assignment, from the Provisioning Effective Immediately dropdown list, select: Yes for the provisioning to take place immediately No for the provisioning to take place at a later time If you select Yes, this runs the User Compare feature in the SAP system after provisioning. If you select No, the User Compare feature in the SAP system does not run. 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 following choices: System: Select the system in which you want to enable specific system settings for auto provisioning. Default Role Provisioning Type: Select Direct, InDirect, or Combined. Select InDirect or Combined only if your SAP environment includes the SAP HR module and you want to use SAP HR to perform provisioning on the HR record instead of on the users master record; otherwise, select Direct. If you select Direct, the InDirect Provisioning Type dropdown list appears dimmed, and you cannot select an HR object type. If you select InDirect or Combined, you must select the type of HR object Compliant User Provisioning needs to transmit to the HR module from the Indirect Provisioning Type dropdown list. Indirect Provisioning Type: Select Jobs, Position, and OrgType. This setting is available only if you select Indirect or Combined for the previous field. Create If User Does Not Exist: Select Yes if you want the provisioning process to automatically create the user. Select No if you do not want the user automatically created. Provisioning Old Roles Delimit Duration: Enter the length of time for transitioning from an old position to a new position. Use this setting only with SAPHR indirect provisioning.

160

September 2008

5 Compliant User Provisioning Approvers Password Expiration for ORAAPPS: Select the basis on which the password expires: after a certain number of days, accesses, or not at all. If you select Days or Accesses, a field in which you can enter the number of days or accesses becomes active. Provisioning Effective Immediately: Select Yes if you want the provisioning process to be in effect immediately. Select No if you do not want it to start immediately. 3. Click Save.

Approvers
You can define approvers in a variety of places based on the workflow approver choices. After approver determinators are selected on a stage, the administrator must maintain those approvers by attributes in Compliant User Provisioning. The Approvers option defines a user ID as an approver. The Approver feature stores the approver information on the following attributes: Defining security lead In general, the security lead is the person(s) responsible for the security of a particular system(s). Defining point of contact (based on functional area) The contact person for a functional area is someone whose role is responsible for that particular business module. Defining application approver The application approver is based on the connector type you defined in the Application Configuration screen. This person is responsible for the application type. Defining distribution group You define the distribution group(s) in the Distribution Group option. This distribution group is associated with one or more distribution list. Defining distribution list approver You define the distribution list, which contains the names of approvers for a stage that requires approval for role assignment. The approvers you define with this option become part of the workflow approval process. When a request needs approval at a particular stage, Compliant User Provisioning uses the defined approvers to forward the request. For example, you can define an approver and alternate approver for the standard approver (Security, Point of Contact, Application approver, and Distribution Group) or create your own approvers by configuring a Custom Approver Determinator (CAD). This CAD can be based on attributes such as functional area and company, for a workflow stage. You can manually add a user ID as an approver by using the Search feature or import a text file containing user IDs of approvers. You then select an approver and alternate approver. Defining an alternate approver ID is mainly used for the workflow escalation process. You define an alternate approver for Security, Point of Contact, and Application approver. Example When you create a workflow stage using Stage Configuration screen, you set the Workflow Type to CUP, which is a standard workflow type. You then set the Approver Determinator to Security. In the Request Wait Time (Days), enter the amount of days you want the approver to respond. Enter 1 for one day. In the Escalation Configuration field, you select Forward to Alternate Approver. You also configure a background job to send email notification for escalation. So after a day that the approver did not respond to a request, Compliant User Provisioning sends a notification email to the alternate approver that you defined in the Security Approver screen.

September 2008

161

5 Compliant User Provisioning Approvers Make sure that the user IDs for the approver and alternate approver exist in whatever search data source you have configured. The only approvers that must be defined are those that are used as approver determinators in the stages of your workflows. Only add alternative approvers for those approvers whose stage is set with their Approver Determinator and the stage is set for escalation to alternative approvers. If you do not use escalation to alternative approvers, there is no need to add alternative approvers.

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

Configuring a Security Lead Procedure To configure a security lead: 1. On the Configuration tab, navigate to Approvers > Security Lead. The Security Lead Approvers screen appears. 2. In the Group Email Address field, enter the security group email address. Specifying the Group Email Address sends the email notification to the securitys group email address, instead of sending the email notifications to each security team member individually. 3. In the Approver ID field, enter the user ID you want to assign as the primary security lead. You can use the Search icon to query for the user ID. 4. In the Alternate Approver ID field, enter the user ID you want to assign as the alternate security lead. This field is necessary only if you are using the escalation of that stage. 5. Click Save. Point of Contact After you define a functional area, assign a Point of Contact (POC) Approver to this business module. The Point of Contact option maps a functional area to a user ID, designated as the primary contact and primary approver, as well as an alternate approver for escalation purposes. The Functional Area is one of the standard fields on the Access Request screen. During the request access process, when the requestor selects a Functional Area, the POC approver is automatically specified. You can assign multiple approvers to a functional area. The POC is a standard approver determinator that is available for selection during the creation of any stage. You can select from the options on the Functional Areas dropdown list on the Roles > Attribute screen. Configuring Point of Contact Approvers Procedure 1. On the Configuration tab, navigate to Approvers > Point of Contact.

162

September 2008

5 Compliant User Provisioning Approvers 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 empty fields appear under the Point of Contact and Alternate Point of Contact columns. 3. In the Functional Area column, select a functional area from the dropdown list. 4. In the Point of Contact column, enter the User ID to assign a primary POC approver. You can also enter a Group of Approvers, if desired. You can click the Search icon to query for the desired user ID. 5. In the Alternate Point of Contact column, enter the User ID to assign the alternate POC approver used for escalation. You can click the Search icon to query for the desired user ID. 6. Click Save. Application Approvers The Application Approvers option defines the application approver and alternates. The application approver is a standard approver determinator that is available for selection during any stage creation. Application approvers must be defined only in the determinator used in a stage. The list of options in the dropdown list is the applications configured as connectors, which are configured on the Request Configuration screen. Configuring Application Approvers Procedure To configure an application approver: 1. On the Configuration tab, navigate to Approvers > Application. The Application Approver, Approver Information screen appears. 2. Click Create. A dropdown list and two empty fields become active in the Application, Approver ID, and Alternate Approver ID columns. 3. From the Application dropdown list, select the desired application. 4. In the Approver ID column, click the Search icon to query for the user ID as the primary approver. You can also add a Group of Approvers. 5. In the Alternate Approver ID column, click the Search icon to query for the user ID of the secondary approver (if using escalation). 6. Click Save.

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

September 2008

163

5 Compliant User Provisioning Approvers

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

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

164

September 2008

5 Compliant User Provisioning Stale Requests

Stale Requests
Compliant User Provisioning allows you to close any older request in the system that has been waiting for an approver for a long period of time. Older requests are considered Stale Requests. Stale Requests can be processed and closed after a specified number of days. 1. On the Configuration tab, navigate to 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 the action is executed. 4. Click Save. You must schedule a background job to review all open requests against the Stale Requests settings. Any request that meets the Number of Days configuration setting is automatically closed.

Request Administration
On the Request screen, you can review and process requests on behalf of other approvers. You can also archive old requests to exclude those requests from current searches and reporting. Administration On the Administration screen, you can access any open request in the system to approve, reject, forward, reroute, or cancel the request. When an administrator processes a request, the audit trail records the administrators user ID and the task performed. Access to the Administration screen is controlled by User Management Engine permissions. Use caution when granting users access to the Administration screen. From this screen, a user can approve and/or reject any request in the system at any stage along any path. The result could be that a request bypasses one or more required approval stages. Archive Archiving Requests is a way to view only the current periods requests during normal viewing. All requests for access are stored in the Compliant User Provisioning database. The system closes the requests after they are approved or rejected. The Archiving Requests functionality helps you archive the closed requests. The archived requests remain in the database but are not visible when the users run searches or reports. 1. On the Configuration tab, navigate to Archiving Requests. 2. The Last Archived Date field displays the current date, indicating when the records are archived. 3. From the Date From dropdown list, select the oldest date of the closed records you want to archive. 4. From the Date To dropdown list, select the most current date of the closed records you want to archive. 5. You can search the archive records by enabling the Archive Request flag when performing the search. The Archive Request flag is located on the Search Requests and Search Audit Trail screens, as well as on the Informer Reports.

September 2008

165

5 Compliant User Provisioning Field Mapping

Field Mapping
Provisioning Field mapping provisioning allows you to provision fields from the Access Request to fields on the SAP User Master Record (using transaction SU01). By doing this, you can provision a single user to one or many SAP systems without having to go to each back-end system and manually create a user. You can also create custom attributes for provisioning users to a non-SAP system (RTA-supported system). The field mapping you defined for the SAP, Enterprise Portal, and non-SAP systems are specific to the systems that you configured in the User Data Source option. The User Data Source option is where you configure one or many data source for searching and retrieving user detail information. For more information about configuring user data source, see the section, User Data Resource Definition in this guide.

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

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.

166

September 2008

5 Compliant User Provisioning Field Mapping 3. In the Short Description field, enter a brief description of the group. 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 remove a system. 9. Click Continue. 10. In the AC Field pane, click the menu button to display the list of standard and custom attributes. 11. In the Application Field pane, click the menu button to display the list of field names associated with the SAP User Master Record (using transaction, SU01). 12. Click the Plus icon to add another attribute field. Otherwise, click the Minus icon to remove an attribute. 13. Click Save. LDAP Mapping The LDAP Mapping option maps fields to corresponding fields in an LDAP database. In addition, you can add fields and then map them to attributes that already exist in your enterprises LDAP database by selecting those attributes on the Additional Fields screen. The field mapping you defined for the LDAP directory is specific to the LDAP systems that you configured in the User Data Source option. The User Data Source option is where you configure one or many LDAP data source for searching and retrieving user detail information. For more information about configuring user data source, see the section User Data Resource Definition. The following standard fields are provided by Compliant User Provisioning and can be mapped to fields used in an LDAP directory: Manager Email Company Valid From Organization Employee Type Position Manager ID Administration Group Manager Last Name Functional Area Company Address LBL_SAP_User_ID Org. Unit Valid To Job Date Format Manager Last Name LBL_Locale

Example You 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:

September 2008

167

5 Compliant User Provisioning User Review 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 to which 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 users first name. 5. In the Last Name field, enter the users last name. 6. In the Email field, enter the users email address. 7. In the Department field, enter the users department name. 8. In the Telephone field, enter the users 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 is located. 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 users manager. 14. In the Distribution List Member field, enter the name of the distribution list of role approvers for an LDAP directory. 15. Click Save.

User Review
User review allows designated approvers to review access and risk violations (both user and SoD violations) and take corrective actions. These two procedures are referred to as User Access Review and User SoD Review. As part of compliance standards, companies are required to mitigate or remediate access risks and reaffirm mitigating controls. Periodic reviews of users access, risk violations, and controls are required as well. The internal compliance team can plan user access reviews semi-annually, annually, or on other periodic bases in accordance with on company policies. Access Control provides the following automated review features: User SoD Review

168

September 2008

5 Compliant User Provisioning User Review User Access Review (UAR) User SoD Review and User Access Review both require Risk Analysis and Remediation 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, you must configure workflow in Compliant User Provisioning. The data to create SoD Review tasks/requests is derived from Risk Analysis and Remediation The data for User Access Review is derived from Enterprise Role Management. You run a job in Enterprise Role Management get the user and role assignment from the back-end system. Then you run a job in CUP to pull in that data and create the UAR requests. For more information about performing user reviews, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3. 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 are completing the reviews. The system notifies the coordinator of any violations and updates the status of the reviews performed. To assign coordinators to reviewers, you use the Coordinator table. You can manually enter the assignments or upload them by navigating to User Review > Coordinators on the Configuration tab. You can download a load template for reference. Access Control administrators can purge usage information for user reviews prior to creating the workflow requests. For example, if you require only the prior three months of usage for reporting in the user reviews, the administrator can purge the data that is three months old or more. This feature is controlled by the Risk Analysis and Remediation capability. For more information, 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 for Reviewers, set the option Admin Review required before sending tasks to reviewers to Yes; 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 HR and the manager information (user ID and email address) appears on the workflow task/request.

September 2008

169

5 Compliant User Provisioning User Review Risk Owners: Risk owners must be defined in the Rule Architect section of Risk Analysis 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 the risks 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-role assignments) 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 reviewer might receive one, several, or many requests, depending on how many users or SoD violations they have to approve. 7. Select the Default Request Type. The dropdown list includes any request types in the system that are configured as SoD Review 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 report updates 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 SOD Review Load Data without Mitigated Risks job. If you want both mitigated and unmitigated risks to be sent for review, select Schedule 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 the Admin Review is complete, run background job SOD Review Update Workflow to release requests to reviewers. If you select No, run the background job SOD Review Update Workflow to release requests to reviewers. You can schedule new background jobs to create workflow requests for manager or risk owner review only after all previous SoD Review request are closed. Use the Coordinator table to assign coordinators to reviewers. You can upload this table in Configuration > User Review > Coordinators. Download the load template for reference. Coordinators review the tasks/requests in Configuration > User Review > Request Review. You can review the requests and make modifications to the reviewer and coordinator information updated if necessary. The administrator or coordinator can search for all requests and/or requests with no reviewers or no coordinators assigned.

170

September 2008

5 Compliant User Provisioning User Review SoD Workflow Example You can configure a SoD workflow based on your organizations requirements. In this example, the SoD workflow consists of normal path containing a single stage for reviewer approval. It also contains a second path as a detour. This detour path has a single stage for security 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 for configuring a SoD workflow. For detailed information on basic workflow configuration, see the section Workflow Management. 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 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 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 Stage 1. 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 SOD REVIEWER. 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. 6. In the Workflow Type dropdown menu, select SOD Review. 7. In the Approver Determinator dropdown menu, select Reviewer (for Managers).

September 2008

171

5 Compliant User Provisioning User Review

Compliant User Provisioning provides two out-of-the-box approvers: Reviewer and 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 days and hours you want to wait until triggering the escalation action. This is the number of days and hours that have elapse since the request first reached the approvers inbox. 9. In the Escalation Configuration dropdown menu, select the type of action to perform when 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 without reviewers 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 are deactivated and the validity date is set to todays date. The request is then forwarded to the next stage. Deactivate; Lock, Forward To Next Stage All user accounts associated with risks are deactivated and locked. The validity date is set to todays date, then the request is forwarded to the next stage. Forward to Alternative Approver The request is forwarded to the specified alternative 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 Content dropdown menu. The Yes option enables the Approve and Remove buttons on the Review Form. If the No 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 with approve or removed items. Only Remove Items The reviewer in this stage receives only items with the Remove action. Generally, only Security is concerned with removed items such as roles and functions. Security is required to take the appropriate actions. 15. Click Save. Defining the Path for Reviewers 1. 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.

172

September 2008

5 Compliant User Provisioning User Review 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 menu for Stage 1. 12. Click Save. Defining the Detour Path for Security 1. 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 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. 7. In the Number of Stages field, enter 1. 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 menu for Stage 1. 12. Click Save. Defining a Detour 1. Go to Configuration tab > Workflow > Detour/Fork. The Workflow Stage Detour screen 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 SOD Review. 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 the condition 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 screen appears. 2. In the Workflow Type dropdown menu, select, SOD Review.

September 2008

173

5 Compliant User Provisioning User Review 3. In the Days field, enter a number of days from the time that the request first was submitted to the approvers 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 the reviewers approval. 8. In the Email Arguments dropdown menu, select the argument that identifies the request. 9. In the Notification Configuration pane, click Reviewer. 10. Repeat the steps above for the Reminder for Coordinator tab. Make sure you select Coordinator 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, then in the Admin Review required before sending tasks to reviewers dropdown menu, select Yes. Otherwise, select No. If you select Yes, Compliant User Provisioning points to the Enterprise Role Management database, retrieves the mapping information of users and roles, and stores the data in a temporary file. You must create a background job using UAR Review Load Data as the Task Name (see step 9) which generates a request for the administrator to review the tasks. The administrator reviews and, if necessary, modifies the mapping information of users and roles. When the Admin Review is complete, you must run a background job using UAR Review Update 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 Update Workflow 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 workflow task/request. Role Approvers: Role approvers are defined at role level in Compliant User Provisioning or Enterprise Role Management. 4. Define Number of lines items per Request. This is the maximum number of lines for user role assignments permitted on a request. If more lines are required, then another request is required for the remainder of the items. Therefore, one reviewer may receive one or several requests, depending on how many user-role assignments they have to approve.

174

September 2008

5 Compliant User Provisioning User Review 5. Select the Default Request Type. The dropdown list includes any request types in the system 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 the Enterprise 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 Service screen 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. The corresponding 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 the service and/or Save the schedule.

After the Admin Review is complete, you must create a background job to release the requests to reviewers. Repeat step 9 using UAR Review Update Workflow as the Task Name. You can schedule new background jobs to create workflow requests for manager or risk 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 Coordinator information updated if necessary. The administrator or coordinator can search for all requests and/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 is optional; it is possible to perform the review without a coordinator. In addition, one coordinator might have many reviewers. 2. Use this screen to search for the coordinator and reviewer by user ID or by first and last names. 3. After identifying all coordinator /reviewer names, you can do another search on the resulting screen to determine whether the selected coordinator/reviewer pair is set to review SoD risks or user access violations. You can create, change, delete, and export mapping information for coordinator/reviewer names.

September 2008

175

5 Compliant User Provisioning User Review 4. If necessary, you can download a template for creating mapping information of coordinator/reviewer names by clicking Download Template. Afterwards, you can import this file. Request Review Use this feature to search for any outstanding requests that are pending for either SoD or User Access Review by the reviewers. You can either assign those requests to any new reviewers 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 reviewers user ID, or select the reviewers user ID by searching 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 reviewers user ID, or select the reviewers user ID by searching for it. 6. In the Coordinator ID field, enter the coordinators user ID, or select the coordinators user 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 search the requests. You can select any row and change the assigned reviewer or coordinator to any new reviewer or coordinator. 8. Selects a row. Then click Change. The system displays the current coordinators and reviewers, and you can enter new values. 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 organizations requirements. In this example, the UAR workflow consists of normal path for reviewers containing a single stage for reviewer approval. It also contains a second path as a detour. This detour path has a single stage for security approval. A detour condition connects the two paths if the value is satisfied. The procedure steps in this section highlight only the fields that are required for configuring the UAR workflow. For more information, see section Workflow Management. To configure a User Access Review workflow in Compliant User Provisioning, perform the following:

176

September 2008

5 Compliant User Provisioning User Review 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. 10. Click Add Attribute. 11. Click Save. Defining the Stage 1. 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. 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. 6. In the Workflow Type dropdown menu, select User Access Review. 7. In the Approver Determinator dropdown menu, select Reviewer (for Managers or Role Approver). Compliant User Provisioning provides two out-of-the-box approvers: Reviewer and 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 days and hours you want to wait until triggering the escalation action. This is the number of days and hours that have elapse since the request first reached the approvers inbox. 9. In the Escalation Configuration dropdown menu, select the type of action to perform when 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 without reviewers 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 role assignments are deactivated and the validity date is set to todays date. The request is then forwarded to the next stage.

September 2008

177

5 Compliant User Provisioning User Review Deactivate; Lock, Forward To Next Stage All user accounts associated user role assignments are deactivated and locked. The validity date is set to todays date, then the request is forwarded to the next stage. Forward to Alternative Approver The request is forwarded to the specified alternative 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 Content dropdown menu. The Yes option enables the Approve and Remove buttons on the Review Form. If the No 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 with approve or removed items. Only Remove Items The reviewer in this stage receives only items with the Remove action. Generally, only Security is concerned with removed items such as roles and functions. Security is required to take the appropriate actions. 15. Click Save. Defining the Path for Reviewers 1. 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 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. 6. In the Workflow Type dropdown menu, select User Access Review. 7. In the Number of Stages field, enter 1. 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 Security 1. 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 UAR SECURITY. 4. In the Short Description field, enter a brief description for this stage.

178

September 2008

5 Compliant User Provisioning User Review 5. In the Description field, enter a long description for this stage. 6. In the Workflow Type dropdown menu, select User Access Review. 7. In the Number of Stages field, enter 1. 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 for Stage 1. 12. Click Save. Defining a Detour 1. Go to Configuration tab > Workflow > Detour/Fork. The Workflow Stage Detour screen 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 the condition 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 screen appears. 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 was submitted to the approvers 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 the reviewers approval. 8. In the Email Arguments dropdown menu, select the argument that identifies the request. 9. In the Notification Configuration pane, click Reviewer. 10. Repeat the steps above for the Reminder for Coordinator tab. Make sure you select Coordinator in the Notification Configuration pane. 11. Click Save.

September 2008

179

5 Compliant User Provisioning Change Log

Change Log
On the Configuration tab, you can configure a change log to capture any changes users make to configuration parameters. When a user performs configuration actions, the system logs the information in the database. You might also want to capture additional information, which you can specify on the Change Log Configuration screen. The Change Log captures the following: Change Log Item Change Log ID Object Name Object Value Description This is the log identifier. Example: Change Log ID 200 This is the object that has been changed. Example: Connector Configuration. This is the value that has been modified for the object. Example: QF8600 is a system name. This is the type of action performed for the Object Name. Example: New. This is the person responsible for making the change. Example: BLAW This is the date and time that the change was made. Example: 10/07/2008 19:17:21 This is the name of the field that was touched. Example: Is Active This is the fields old value. Example: true. This is the fields new value. Example: false This is the type of action performed in the field name. Example: Modified.

Action

Changed by

Change Log Time

Field Name Old Value New Value Action

Change Log Configuration 1. On the Configuration tab, navigate to Change Log Configuration. The Change Log Configuration screen appears. 2. Select the configuration items that you want to track. Select as few or as many items as you want. 3. Click Save. Search Change Log Use the Search Change Log feature to search the log information in the database for configuration changes. You can specify any of the following criteria to filter your search:

180

September 2008

5 Compliant User Provisioning Roles Change Log ID: The log ID in the log information in the database. User ID: The specific user ID of the user who made configuration changes. Object Name: Select the specific types of configuration changes you want to find. Object Value: Based on the specified object name, you can specify an object value. For example, if you select Role for Object Name, you can specify the name of the role as its value. Field Name: Each object has a specific set of fields. Based on the specified object name, the corresponding field names appear on the dropdown list, and you can select a specific field name to further refine the search. Field Value: Based on the specified field name, you can specify a field value to fine tune the search. Change Date From and Change Date To: Specify the range of dates when configuration changes you want to find were made. Maximum Number of Hits: Specify the number of configuration log records to display in the search results to narrow the search criteria.

Roles
The Roles option configures roles. A role is fundamental to users for accessing information. A role can be specific to an individual user or a group of users. The role description must match the specific tasks for accessing information or application systems. The Roles option provides the following configuration options: Import Roles Role Creation Role Search Role Exporting Role Selection Default Role Configuration Role Mapping Enablement and Removal of Role Mappings Attribute Definition Role Reaffirmation Frequently Asked Questions Question Answer

No. You must import the role first. What happens if a role has not been imported/added to Compliant User Provisioning? Can a requestor still select that role and add it to a request?

September 2008

181

5 Compliant User Provisioning Roles

Question

Answer

Can a role be deleted from a user after Compliant User Provisioning can delete roles from it is assigned? users within a workflow that has a request type configured with a Change User action. But, even with a deleted role, you must import/add the role to Compliant User Provisioning prior to selecting it for deletion. If a role is updated (for example, a transaction code is added), does the role need to be re-imported? No. Compliant User Provisioning does not import role details other than names and descriptions. If required, transaction code information is obtained from the SAP system and is therefore always in sync.

If I delete a role in the SAP system, do I No. If you delete a role in the SAP system and then have to import it again to synchronize import roles into Compliant User Provisioning, the Compliant User Provisioning with SAP? role reference remains in Compliant User Provisioning. You must delete the role manually from Compliant User Provisioning. Import Roles Compliant User Provisioning provides several methods to load roles. One method is to import the roles from an SAP business system. Another method is to import roles from a spreadsheet file. You use Enterprise Role Management to build roles. These roles can be pushed to each Access Control capability through a synchronization mechanism. For more information about role synchronization, see the section Configuration for Role Synchronization Integration with Enterprise Role Management. For import of non-SAP roles, these roles are transferred to Compliant User Provisioning using the Role Import file (a spreadsheet). Be selective when importing roles. Take into consideration which roles you need. For example, if you do not want anyone to request SAP_ALL in the production client, do not load it into the production client. Load only the roles that you need. Importing a large number of roles can result in a long list to scroll through when you must select one. In addition, deleting roles can be time consuming when thousands of roles are in one system. Importing Roles Procedure Compliant User Provisioning provides several methods for loading roles. One method is to import the roles from an SAP business system. Another method is to import roles from a spreadsheet file. To import roles: 1. On the Configuration tab, navigate to Roles > Import Roles. The Import Roles screen appears.

182

September 2008

5 Compliant User Provisioning Roles 2. From the System dropdown list, select the system that contains the roles you want to import. 3. From the Role Source dropdown list, select either the SAP back end or Enterprise Role Management. 4. In the Last Sync Date field, select a date. All roles that have been changed since the specified date are selected for import. 5. Select the setting in which to import your roles from the following table. Role Import Settings Role Import Setting All Roles Description Imports all roles from the specified system, which includes all predefined roles. Use caution when importing roles. You might not need to import all roles from the back-end system into Compliant User Provisioning. The only roles you need to import are the roles you want requestors to select for provisioning. All Roles Except SAP Predefined Roles Selected Roles Imports all roles except any predefined roles in the specified SAP system. Imports individual roles. in this case, you must know the names of the roles you want to import. Enter the roles one at a time in the Role Name field, or use a wildcard option (an asterisk - *) to specify a number of similarly named roles. Use this setting to load roles from a spreadsheet file. This file can be on your local host or on another system. Use Browse to navigate to the file.

From File

In your development system, where you create roles to transport, there might be roles used for testing that you do not want users to request. If you do not import these roles, they are not available for selection, approval, and provisioning. For SAP systems: If you do not want users requesting access to SAP_ALL in your production system, do not import SAP_ALL for the production system. 6. To overwrite any existing roles of the same name as those you import or add any new roles to the system, select Overwrite Existing Roles. This option does not affect any roles that are not listed in the spreadsheet or included in the import. 7. Click Import. 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 enables role synchronization. Enterprise Role Management is set as the system for role resource.

September 2008

183

5 Compliant User Provisioning Roles 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. After downloading the spreadsheet, populate the fields with your own roles, and then import the information. Recommendation SAP recommends that you edit the downloaded template with your additional roles. Use the data format of the values represented in the dummy role. However, you must delete the dummy role in the template before using it. Do not modify the sheet name and header names. Business process, subprocess, functional area, company, and system must exist in Compliant User Provisioning before the roles can be successfully uploaded. If they do not exist, attempting to import them fails. These attributes are added through the Roles > Attributes screen. To download the role import template: 1. Click Download Template, and then click Save to save the template to your system. Be sure to save the template in a location where it is for you to find later. 2. Open the template, and enter values for the roles you want to import. 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 Importing Roles.

184

September 2008

5 Compliant User Provisioning Roles

Role Import/Export Template Details The following table describes the items in the import template spreadsheet. Role Import Template Spreadsheet Role Import Column Description Connector Type Name of the connector type. Only one connector type is allowed. Technical name of the role. Select Single or Composite. Only one value is allowed. Date of the roles last reaffirm. Required format is MM/DD/YY. Technical name of the system in which the role resides. The system must exist as a connector. List as many systems as you want, separated by commas. CaseMandatory Sensitive Yes Yes upper case letters Yes No MM/DD/YY Yes, upper case letters No

RoleName Type Last Reaffirm Date System

Yes Yes Yes Yes, at least one system is required

RoleApprover

User ID of the roles approvers. Several role No approvers can be included, separated by commas. Alternate approvers follow the approver and are separated by a pipe symbol (|). Lead Approver designation follows the alternate approver separated by a pipe symbol (|). Format: Roleappr|alternative|Y,roleapprover|alternate Example: WONG|BLAW|Y,CPERKINS MWONG is the role approver, BLAW is MWONGs alternate approver and MWONG is the Lead Approver. CPERKINS is the second role approver, no alternate and is not the lead approver.

Functional Area

Functional area of the role. This is the technical name of the functional area, and it must expire in the system before the role is uploaded successfully. Several functional areas are permitted, separated by commas. Company associated with the role. This is the technical name of the company, and it must expire in the system before the role is uploaded successfully. Several companies are permitted, separated by commas Options are either Role or Profile.

Yes at least one functional area is required

Yes

Company

Yes Yes at least one Company is required Yes No

RoleProfileIndicator

September 2008

185

5 Compliant User Provisioning Roles

Role Import Template Spreadsheet Role Import Column Description Responsibilityid This field is no longer used but it remains in the template for backward compatibility. It is a number used to represent the responsibility ID. Enter zero if not using this functionality. Comments Mandatory Options are Yes or No. Yes Yes use upper case letters Yes or mixed Yes. CaseMandatory Sensitive Yes use a N/A zero if not using this functionality

ParentRoleOwner

This field is no longer used as part of Compliant User Provisioning but it remains in the template for backward compatibility. Options are Yes or No. Select No, if not using this functionality.

No Yes Choose No if not using this functionality No No

Description_de

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

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

No

No

Hungarian short description. Required only if No your users want to use Access Control in Hungarian. No

No

DetailDescription_hu Hungarian detailed description. Required only if your users want to use Access Control in Hungarian. Description_ja

No

Japanese short description. Required only if No your users want to use Access Control in Japanese. No

No

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

No

No

No

DetailDescription_it

No

No

186

September 2008

5 Compliant User Provisioning Roles

Role Import Template Spreadsheet Role Import Column Description Description_ es Spanish short description. Required only if your users want to use Access Control in Spanish. CaseMandatory Sensitive No No

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

No

No

Portuguese short description. Required only No if your users want to use Access Control in Portuguese. No

No

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

No

No

No

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

No

No

DetailDescription_fr

French detailed description. Required only if No your users want to use Access Control in French. The technical name of the business process, Yes which must exist in the system before the role is uploaded successfully. Only one business process is allowed per role. The technical name of the subprocess, which must exist in the system and be assigned to the business process listed in the Business Process column on this spreadsheet before the role is uploaded successfully. Only one subprocess is allowed per role. Yes

No

BusinessProcess

Yes use upper case letters Yes, use upper case letters

Subprocess

CriticalLevel

Options are Critical, High, Medium, and Low. Yes

No, suggest using mixed case letters as displayed in the description column

September 2008

187

5 Compliant User Provisioning Roles

Role Import Template Spreadsheet Role Import Column Description ReaffirmPeriod The number of months that a role needs to be reaffirmed. For example, enter a reaffirm period of one year or 12 months as 12. This column contains all custom role attributes for the role. CaseMandatory Sensitive Yes N/A enter a number N/A

Custom Attributes (Custom Fields for the Role)

No

Verification Training This column contains all system name for System your verification/training system.

No

Yes, use upper case letters

Changing Existing Roles with the Export/Import Spreadsheet You can make mass changes to roles using a spreadsheet. Use the Search Role functionality to export the selected roles and create a spreadsheet with the existing roles and their role attributes. You can then change these attributes on the spreadsheet and import them back into the system using the Overwrite Existing Role option. Role Creation The Create Role option creates a role within Compliant User Provisioning. You cannot use this option to create roles in your SAP system. The Role Details screen displays certain fields, which are pre-configured on the Role Attributes screen. To access the Role Attributes screen, on the Configuration tab, navigate to Roles > Attributes. Then click each role attribute name to access its configuration screen. Each role configuration screen contains the following fields: Business Process Subprocess Systems Functional Area Company Creating Roles Procedure To create a role: 1. On the Configuration tab, navigate to Roles > Create Role. The Role Details screen appears. 2. In the Role Name field, enter the name of the new role. 3. In the Description field, enter the description of the new role. 4. In the Type dropdown list, select the type of role. The options are Single or Composite. 5. From the Role/Profile dropdown list, select Role or Profile for the new role.

188

September 2008

5 Compliant User Provisioning Roles When the role is displayed throughout Compliant User Provisioning, the standard SAP icon 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 it remains in the template for backward compatibility. It represents the responsibility ID. 8. From the Business Process dropdown list, select the business process to which the new role applies. 9. From the Subprocess dropdown list, select the sub-business process to which the new role applies. 10. In the Reaffirm Period field, enter the date range for reaffirming the new role. This is number of months after which you must reaffirm a role. Enter one year as 12 (months). 11. In the Last Reaffirm field, enter the date for reaffirming the new role. Enter the date in the format mm/dd/yyyy, or use the calendar icon to select a date. For more information, see the section Reaffirm Role. The Due field displays the date of the next reaffirmation. This display field is calculated based on the date of the last reaffirmation and the number of months specified for the reaffirm period. 12. From the Comments Mandatory dropdown list, select Yes or No. If Yes, select the check box for Allow Role Comments on Roles > Role Selection to make comments available when a user enters the role on a request. 13. From the Consider ParentRole Owner for ChildRole dropdown list, select Yes or No. This field is no longer used as part of the Compliant User Provisioning, but it remains in the template for backward compatibility. Select No, if you do not want to use this functionality. 14. On the System tab, click the plus icon to add the appropriate system. A dropdown list appears, from which you can select the system. To delete a system, select the row the system is in, and click the minus icon. You can set role assignment validity by role and by system by performing the following: a. Click the Check icon to set role assignment validity date. b. Set role assignment validity date. Select the system name. Set the Validity. Select one of the following: o o o c. None Actual End Date Maximum Duration of Assignment

Set role status. Select one of the following: Enable roles you want to maintain but do not allow auto provisioning. Enable and Provision roles you want to maintain and allow auto provisioning when selected by a user.

September 2008

189

5 Compliant User Provisioning Roles Disable roles that are disabled and are not displayed when the end user 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 approver determinator is configured for escalation to alternative approvers. If escalation is not configured for escalation to alternative approvers, there is no need to add alternative approvers. 17. On the Functional Area tab, click the this new role. icon to add a functional area to associate with

A dropdown list appears from which you can select the name of the functional area. 18. On the Company tab, click the icon to add the company to associate to this new role.

A dropdown list appears from which you can to select the name of the company. 19. On the Custom Attributes tab, click the icon to add custom attributes to the role.

For more information about custom attributes, see the section Custom Field Creation. 20. In the Verification/Training System tab, click the plus icon to display the dropdown menu for each field. You can use this tab to check role(s) against a verification/training system. Select the training system this role is applicable to, indicate if it is verified upon the request submission, and if the training system is active or not. 21. Click Save. Role Search The Search Roles option queries for roles based on the criteria you specify. You can filter your query for role name, role description, system, business process, subprocess, functional area, and role owner. After you receive the search results, you can change or delete roles, or export the search results from spreadsheet format. The export feature is not available in Compliant User Provisioning, if you are using Enterprise Role Management to create and maintain roles. In addition, from the Roles Information screen's Search Results, you can begin the role creation process, if the role you are looking for does not exist.

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

190

September 2008

5 Compliant User Provisioning Roles

Field Role Name

Description Enter the role name you want to find. Enter the role name in upper case.

Role Description System Business Process Subprocess

Enter the role description you want to find. Enter the SAP system name where the role you want to find resides. Enter the business process associated with the role you want to find. Enter the business subprocess associated with the role you want to find.

Functional Area Enter the functional area associated with the role you want to find. Role Owner Enter the role owner associated with the role you want to find.

Alternatively, leave every field blank to view every role. 3. Click Search. The Roles Information screen displays the search results. Role Exporting You can download the role search results to your computer in spreadsheet format. This option make changes to the role information and then imports the file back into Compliant User Provisioning. For more information, see the section Import Roles. Exporting Role Information Procedure To export role information: 1. On the Roles Information, Search Results screen, click Export. A File Download dialog box appears. 2. Click Open to view the spreadsheet immediately, or click Save and select a location on your computer where you want to save the file. Role Selection The Role Selection option narrows the scope of the search results for roles to a particular subset. This option is useful when you have a large number of roles to search. To optimize the search function, you can limit the search criteria to specific attributes of a role. Configuring the scope of the search reduces the amount of time necessary for approvers and access requestors when searching for the correct role during the creation of a request. All roles are imported into Compliant User Provisioning. When you search for a role as part of a request, the search is actually querying Compliant User Provisioning, not SAP. There are several role attributes used as search criteria that are not stored in SAP.

September 2008

191

5 Compliant User Provisioning Roles 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 that searching a large set of roles can be time-consuming. Restrict Role Selection This allows approvers to search for a specific attribute. Use the dropdown list to select the attribute. 3. In the Access Requestor group, select one of the following settings: Allow All Roles This allows access requestors to search for all roles. Keep in mind that searching a large set of roles can be time-consuming. Restrict Role Selection This allows access requestors to search for a specific attribute. Use the dropdown list to select the allowed attribute. Allow Users to Select Roles Check this box to allow users to select their own roles. 4. In the Transaction Selection group, select one of the following settings: New Request Change Request 5. In the Role Comments group, you can enable the approver and access requestor to enter comments. You can also make comments required by selecting the appropriate checkbox. 6. In the Roles With No Approvers group, you can enable the Auto Approve Roles Without Approvers to approve roles with no defined approvers. When you enable the Approve Roles Without Approvers flag, it is applicable at any stage where the approval level is set to Role. Generally, you set the approval level to Role for those stages where the role is the approver determinator or when the stage is associated with Custom Approver Determinator (CAD) where the Role or Functional Area of Role is one of the attributes. Compliant User Provisioning then tries to determine approvers for each role. If there are no role owner defined in any of the roles of the request, then the request gives the error message, Approver not found . This exception is displayed in the previous stage when the approver approves the request. Enabling this flag automatically approves these roles without defined approves. However, there must be approvers for at least one role, otherwise the same error message is displayed. To avoid the Approver not found error message, configure an escape route or, if the stage has a Role as the approver determinator, use one of the detailed conditions (No Role Owners or Roles with No Role Owner). For more information, see the section Detour Paths.

192

September 2008

5 Compliant User Provisioning Roles

7. Click Save. Default Roles Configuration The Default Roles option configures a role for certain conditions. You configure default roles to be added to an access request depending on the attributes selected by the requestor. In addition, you can allow users to add default roles, add roles for the attributes you assign, and determine which user attributes to assign to default roles. When you configure these options, the system inserts a default role automatically into the access request, based on the value of the User Attributes field. In addition to configuring default roles, you can import default roles from another system and download a template that you can use to populate with your own default roles. Then you can import them into Compliant User Provisioning. To do so, import a spreadsheet file containing roles and role information from another system, which you can use as default roles. Finally, you can download a spreadsheet template file to your local system to use for importing default roles. After downloading the spreadsheet, populate the fields with your own default roles, and then import the information into Compliant User Provisioning. Example An example of using default roles is having an access request match the requirements that you configured using the Default Role Configuration screen, where you associate the company attribute with a role as a default. In this case, you set company name, SAP with the role, Z_AP_Payable. When a stage is set up to provision a role but only the company attribute is used in the request, the default role is determined by this association. Configuring a Default Role Procedure 1. On the Configuration tab, navigate to Roles > Default Roles. The Default Roles screen appears. 2. From the Consider Default Roles dropdown list, select Yes or No. 3. From the Default Role Level dropdown list, select Role or Request level. 4. From the User Attributes dropdown list, select the desired attribute. The choices you can make here depend on the default role level you select. 5. Click Save. 6. Click Create. The Define Default Roles screen appears. 7. From the User Attributes dropdown list, select the desired attribute. 8. In the Value field, enter a value for each user attribute. 9. Click the icon in the Role column.

A field appears in the Role column, and a dropdown list appears in the System column. 10. In the Role column, enter the role name to be inserted into the request automatically when the request has a matching User Attribute, Value, and System. 11. In the System field, click the dropdown list to select the desired system name.

September 2008

193

5 Compliant User Provisioning Roles 12. Click Save. Importing Default Roles from an External System Procedure Besides creating default roles from scratch, you can import a spreadsheet file containing roles and role information from another system, which you can use as default roles. To import default roles from an external system: 1. In the File Name field, enter the full path to the file, or click Browse to navigate to and select the file. 2. Click Import.

Downloading the Default Roles Template Procedure You can download a spreadsheet template to your local system to use for importing default roles into Compliance User Provisioning. After downloading the spreadsheet, populate the fields with your own default roles and then import them. To download the default roles template: 1. Click Download Template. 2. Click Save. Be sure to save the template in a location where it is easy for you to find later. 3. Open the template. 4. Enter values for User Attribute, Roles Value, Role Profile Name, System and ID. Recommendation SAP recommends that you edit the downloaded template with your additional roles. Do not modify the sheet name and header names. When importing default roles, use upper case for the role name, since Compliant User Provisioning is case-sensitive. 5. After adding all the default role information, save the file on your local system. For more information, see the section Importing Default Roles from an External System to import this information to Compliant User Provisioning. For Superuser Access, use the Super User Access request type and configure the firefighter role as the default role.

Role Mapping Option The Role Mapping option assigns roles to specific systems depending on the selected role in the request. Role mapping makes it easier for requestors when specifying a role on a particular SAP back-end system. They are automatically granted a role when they specify a certain SAP system. Example One example of using default roles is when you want Role A to be followed by Role B. For example, Role A (accounts payable manager) is always accompanied by Role B (accounts payable display). Also, there are times when you want a default role to

194

September 2008

5 Compliant User Provisioning Roles encompass many tasks or a single job, where one role is associated with a specific job. 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 define by adding a main role to the specified system. 4. To add a main role to a system and populate the Role Selected by User dropdown list for that system, click Add Main Role. The Select Main Role screen appears. 5. From the System dropdown list, select the desired system name. 6. Click Search. Any role names associated with the specified system name are displayed in the Search Results area. 7. Select a role name and click Add. The Role Mapping screen appears. The role name that you added now appears in the Role Selected by User field. After you finish adding main roles to the system, you can associate the main role with dependent roles that fall under the main roles umbrella. 8. In the System column, click Add. The Select Dependent Roles screen appears. 9. Make sure the system to which you want to add dependent roles appears in the System dropdown list, and then click Search. The Search Results screen appears. 10. Select one or more roles and click Add. The dependent role or roles now appear in the list below the main role.

Importing Role Mapping Procedure You can import files that already contain mapped roles. The files must be in spreadsheet format. In addition, Compliant User Provisioning provides a spreadsheet template that maps multiple roles and then imports the mapped roles into Compliant User Provisioning. 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Click Import. 3. Save the file to your local system. After mapping the roles, you can define the directory path to this file.

September 2008

195

5 Compliant User Provisioning Roles Downloading the Role Mapping Template Procedure To download the role mapping template: 1. Click Download Template. 2. Click Save. Save the template in a location where it is easy to find later. 3. Open the template and enter values for Main System, Main Role, Dependent System, and Dependent Role. Recommendation SAP strongly recommends that you edit the downloaded template with your own role mapping information. Do not modify the sheet name and header names. When importing role mapping, use upper case for the main role name and dependent role name as Compliant User Provisioning is case-sensitive. Save the file to your local system. After using the template to create role mapping, you can define the directory path to this file, and then import the file. For more information, see the section Importing Role Mapping.

Deleting Main Roles Procedure To delete a main role: 1. On the Configuration tab, navigate to Roles > Role Mapping. The Role Mapping screen appears. 2. From the Role Selected by User dropdown list, select the role name you want to delete. 3. Click Delete Main Role. A message appears stating that have you successfully deleted the main role. Enable and Remove Role Mappings After you create mapped roles, you can configure role mapping to be enabled or disabled for the system and whether role maps apply to removals. Role removal relates to whether the role mappings function in reverse. Enabling this option means that when the main role is added to the request to be removed from a user, the mapped roles are also added to the request to be removed from the user. These are the same roles that would be added to the request if the main role were added. If you do not enable this setting, the main role can be removed from the user without affecting the mapped roles. The mapped roles are not added to the request as removals.

Role Attributes Role Attributes are role categories that can be assigned to the role and or request to help the requestor find the desired roles, as well as to facilitate the workflow functionality. When the role attributes are assigned to the roles, they help the user select the roles when creating the request by filtering on these attributes.

196

September 2008

5 Compliant User Provisioning Roles For example, if a user wants a finance role and all the finance roles have been assigned to the Finance functional area, the requestor can display roles by selecting the functional area Finance. In addition, if the user selects functional area Finance on the request header, by default, when you click the Select Roles button, only the Finance roles are displayed. The predefined attributes in the following table are included in your installation. You can also define your own attributes to support your needs by adding custom fields. Although SAP suggests some attribute definitions, you can define them to suit your business.

Predefined Attributes Attributes Company Description Suggested definition: A global organization or division. Company can be assigned to a request and a role. Functional Area Suggested definition: The business unit, such as HR or Finance. Examples: Administration Sales and Distribution Marketing Production R&D Functional areas can be assigned at the request level and at the role level. Administration Sales and Distribution Marketing Production R&D

Application Area

Suggested definition: The system that contains the application. Application area is the top of the hierarchy for business process and subprocess. Application area is not required. Application area is defined only at the role level. Suggested definition: The process of the actual work, such as accounting. Business process is required at the role level. Suggested definition: A subprocess of the actual work, such as auditing. Subprocess is required at the role level and is a subprocess associated with a particular business process. Every subprocess can be assigned to only one business process.

Business Process Business Subprocess

September 2008

197

5 Compliant User Provisioning Roles

Predefined Attributes Attributes Functional Area and Company Description The name of the approver for the organization for the combination of functional area and company. Set the owner/role for the workflow stages in your approval path. This attribute is required only if one of your stages uses this option as an approver determinator. For more information, see the section Defining a Stage.

The definitions of these predefined attributes are suggestions and can be defined differently for your companys requirements. For example, Functional Area might be defined as a business function for one company and a location for another. When you have defined attributes using the Attributes option, the attributes appear in the dropdown lists whenever you go to the Access Request entry screens or the Select Roles screen, depending on whether the attribute can be defined at the request and role level or only the role level. On the Select Role screen, these attributes help the requestor to find the roles by filtering the role selection.

Configuring Company Attributes Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute selection screen appears. 2. Click Company. The Role Attribute, Company screen appears. 3. Click Create. Three empty fields appear for Company ID, Short Description, and Description. 4. In the Company ID field, enter the name of the organization. 5. In the Short Description field, enter a short description of the company. The information in the Short Description field appears in dropdown lists when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a longer description of the company. 7. Click Save. Changing a Company Attribute Procedure 1. On the Company screen, select the Company ID you want to change. 2. Click Change. The Company ID and Company Description fields become active. 3. Make any edits. 4. Click Save.

198

September 2008

5 Compliant User Provisioning Roles Configuring Functional Area Procedure To configure a functional area: 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute selection screen appears. 2. Click Functional Area. The Role Attribute, Functional Area screen appears. 3. Click Create. Three empty fields appear for Name, Short Description, and Description. 4. In the Name field, enter the name of the functional area. 5. In the Short Description field, enter a short description of the functional area. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a description of the functional area. 7. Click Save. Functional Area approvers are maintained on the Approvers > Point of Contact screen. Changing a Functional Area Procedure 1. On the Functional Area screen, select the functional area you want to delete or change. 2. Click Change. The Short Description and Description fields become active. 3. Make any edits. 4. Click Save. Configuring an Application Area Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute selection screen appears. 2. Click Application Area. The Role Attribute, Application Area screen appears. 3. Click Create. Four empty fields appear for a Name, Short Description, Description, and System. 4. In the Name field, enter the name of the application. 5. In the Short Description field, enter a short description of the application. 6. In the Description field, enter a description of the application.

September 2008

199

5 Compliant User Provisioning Roles 7. At the end of the System field, click the arrow icon to view a list of systems. The Select System screen appears. 8. Select a system from the list. 9. Click Select to populate the System field. 10. Click Save. Importing Application Area Attributes Procedure Compliant User Provisioning allows you to import files containing application area attributes. The files must be in spreadsheet format (.xls). To import application area attributes: 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Select the Overwrite Existing checkbox, if you want to overwrite existing files, 3. Click Import. Downloading the Application Area Attributes Template Procedure Compliant User Provisioning provides you with a spreadsheet template (.xls) to configure multiple application area attributes and then import into Compliant User Provisioning. To download the application area attributes template: 1. Click Download Template. 2. Click Save. Be sure to save the template in a location where you can find it later. 3. Open the template. 4. Enter values for Application Area, Short Description, Description, and System. Recommendation It is recommended that you edit the downloaded template with your own application area attributes. Do not modify the sheet name or header names. Areas are available for a short description and long description in the following languages: en = English es = Spanish de = German fr = French pt = Portuguese ja = Japanese The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. Click Save. After using the template to add application area attributes, you can define the directory path to this file, and then import the file using the instructions in the section Importing Application Area Attributes.

200

September 2008

5 Compliant User Provisioning Roles

Changing an Application Area Procedure 1. On the Application Area screen, select the application area you want to delete or change. 2. Click Change. The Application Area and Description fields become active. 3. Make any edits. 4. Click Save. Configuring Business Processes Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute screen appears. 2. Click Business Process. The Role Attribute, Business Process screen appears. 3. Click Create. Six empty fields appear for Name, Short Description, Description, Owner/Approver, Alternate Approver, and Application Area. 4. In the Name field, enter the name of the business process. 5. In the Short Description field, enter a short description of the business process. 6. In the Description field, enter a description of the business process. 7. In the Owner/Approver field, enter the name of the primary approver. You can use the Search icon to query for the desired user ID. 8. In the Alternate Approver field, enter the name of the secondary approver. You can use the Search icon to query for the desired user ID. 9. In the Application Area field, at the end of the System field, click the arrow icon to display a list of application areas. The Select Application Area screen appears. 10. Select an application area. 11. Click Select. 12. Click Save.

Importing Business Process Attributes Procedure Compliant User Provisioning allows you to import files containing business process attributes. The files must be in spreadsheet format (.xls). To import business process attributes:

September 2008

201

5 Compliant User Provisioning Roles 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Select the Overwrite Existing checkbox, if you want to overwrite existing files. 3. Click Import. Importing a Business Process Attributes Template Procedure Compliant User Provisioning provides you with a spreadsheet template (.xls) which you can use to configure multiple business process attributes and then import back into Compliant User Provisioning. To download the business process attributes template: 1. Click Download Template and then click Save to save the XLS template file to your system. Be sure to save the template in a location where it is easily found. 2. Open the template and then enter values for Business Process, Approver, Alternate Approver, Application Area, Short Description, and Long Description. Recommendation It is highly recommended that you edit the downloaded template with your own business process attributes. Do not modify the sheet name or header names. Areas are available for you to enter a short description and long description in the following languages: en = English es = Spanish de = German fr = French pt = Portuguese ja = Japanese The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. Save this file to your local system, where it is stored. After using the template to add application area attributes, you can define the directory path to this file, and then import the file using the instructions in the section Importing Business Process Attributes.

Changing a Business Process Procedure 1. On the Business Process screen, select the process you want to change. 2. Click Change to modify the selected business process. The Short Description, Description, Owner/Approver, Alternate Approver, and Application Area fields become active. Make any edits. 3. Click Save.

202

September 2008

5 Compliant User Provisioning Roles Configuring a Business Subprocess Procedure 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attribute screen appears. 2. Click Business Subprocess. The Role Attribute, Business Subprocess screen appears. 3. Click Create. Three empty fields appear for a Name, Short Description, and Description, and a dropdown list appears from which you can select a Business Process. 4. In the Name field, enter the name of the business subprocess. 5. In the Name field, enter the name of the business subprocess. 6. In the Short Description field, enter a short description of the business subprocess. 7. In the Description field, enter a description of the business subprocess. 8. In the Business Process dropdown list, select the desired business process name. 9. Click Save. Changing a Business Subprocess Procedure 1. In the Business Subprocess screen, select the business subprocess you want to change. 2. Click Change to modify the selected business subprocess. The Short Description and Description fields and the Business Process dropdown list become active. Make any edits. 3. Click Save.

Configuring the Functional Area and Company Attribute Procedure To configure the functional area and company attribute: 1. On the Configuration tab, navigate to Roles > Attributes. The Role Attributes screen appears. 2. Click Functional Area and Company. The Role Attribute, Functional Area and Company screen appears. 3. Click the icon.

Four empty fields appear under Functional Area, Company, Owner/Approver, and Alternate Approver. 4. In the Functional Area column, click the dropdown list to select the desired functional area. 5. In the Company column, click the dropdown list to select the desired company. 6. In the Owner/Approver column, click the Arrow icon to open the Approvers for Functional Area and Company screen, where you can query for approvers.

September 2008

203

5 Compliant User Provisioning Roles 7. Click the icon.

Two empty fields appear in the Approver and Alternate Approver columns. Use the Search icon to query for approvers. If you have more than one row of approvers, you must select a lead approver by clicking the option button at the end of the appropriate row. Lead approvers are also indicated by the Hat icon at the beginning of the row. 8. Click Save. The Owner/Approver and Alternate Approver fields are populated. 9. Click Save. Importing Functional Area and Company Attributes Procedure Compliant User Provisioning allows you to import files containing functional area and company attributes. The files must be in spreadsheet format (.xls). To import functional area and company attributes: 1. In the File Name field, enter the full path of the file, or click Browse to navigate to and select the file. 2. Select the Overwrite Existing checkbox, if you want to overwrite existing files. 3. Click Import.

Downloading the Functional Area and Company Attributes Template Procedure Compliant User Provisioning provides you with a spreadsheet template (.xls) which you can use to configure multiple functional area and company attributes and then import them into Compliant User Provisioning. To download the functional area and company attributes template: 1. Click Download Template. 2. Click Save. Be sure to save the template in a location where it is easy for you to find later. 3. Open the template. 4. Enter values for Functional Area, Company ID, Approver ID, Alternate Approver ID, and IS Lead. Recommendation It is highly recommended that you edit the downloaded template with your own business process attributes. Do not modify the sheet name or header names. Areas are available for you to enter a short description and long description in the following languages: en = English es = Spanish de = German fr = French

204

September 2008

5 Compliant User Provisioning Role Reaffirmation pt = Portuguese ja = Japanese The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. Click Save. After using the template to add application area attributes, you can define the directory path to this file and then import the file using the instructions in the section Importing Functional Area and Company Attributes.

Deleting the Functional Area and Company Attribute Procedure To delete the functional area and company attribute: 1. On the Functional Area and Company screen, select the Functional Area you want to delete by clicking anywhere in that row, outside any of the active fields. 2. Click the icon to delete the selected functional area.

Role Reaffirmation
Compliant User Provisioning allows you to an send automatic email reminders to any role approver responsible for reaffirming a role. Use the Reaffirm Role option to configure the number of days prior to the actual reaffirm date to send the email reminder. The Role Reaffirmation option is similar to User Access Review with role approver with the exception of Role Reaffirmation entails configuring the reaffirm date on roles.. For more information on configuring role reaffirmation, see Access Control 5.3 Application Help. You must schedule and run the Email Reminders background job to determine which roles are due for reaffirmation and send the email reminders to the role approvers. Recommendation SAP recommends that you run the Email Reminders background job once daily.

Configuring an Email Reminder for Role Reaffirm Procedure To configure the email reminder for reaffirming a role: 1. On the Configuration tab, navigate to Roles. This option expands to display Reaffirm Role. 2. Click Reaffirm Role. The Reaffirm Role screen appears.

September 2008

205

5 Compliant User Provisioning Background Jobs 3. In the Number of days prior to Reaffirm due date (to send email reminder) field, enter the number of days prior to the reaffirm date that you want to send the email reminder. The system sends an email notification to the approvers the specified number of days prior to the reaffirmation date set for each role. 4. Click Save. Remember to schedule and run the Email Reminders background job to analyze roles for 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 and based on the period, the due date is automatically calculated. You can later modify this setting, if required. For more information on configuring role reaffirmation, see the section, Role Creation in this guide.

Background Jobs
The Background Jobs option runs jobs against the data in Compliant User Provisioning. You can also configure it to take new actions. Example If there are changes to a new request or modifications in the approval stage in which an access 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 to run. 6. Click Save. 7. Click View Schedule to review the scheduled job.

206

September 2008

5 Compliant User Provisioning User Default Management

User Default Management

Managing user defaults allows you to link data fields that are automatically set for newly created users. After you configure user defaults, the data is transferred to the SAP back-end system as defaults. The User Defaults option assigns the following values: User Defaults Option Assignments Assignment Selecting a User Default System Description You must select an SAP back-end system to act as the default system where you can get the user defaults. The list of SAP systems in the dropdown list is based on the active SAP connections on the Connectors screen. For more information, see the section Selecting a User Default System. You must select a user default system before you create user defaults. Configuring User Defaults Use this option to assign user defaults in the SAP back-end system for new users. For more information, see the sections Configuring User Defaults and Changing User Defaults. You must select a user default system before you create user defaults. For more information, see the section Selecting a User Default System. Setting User Default Mapping Use this option to create, change, or activate/deactivate the user default. For more information, see the sections Setting User Default Mapping and Deleting a User Default Mapping.

Configuring User Defaults Procedure To configure user defaults: 1. On the Configuration tab, navigate to User Defaults > User Defaults. The User Defaults screen appears. 2. Click Create. The Create User Defaults screen appears. 3. In the Name field, enter the name for the default. 4. From the System dropdown list, select the system where you want the user defaults to be applied. You can apply multiple systems to the user default. 5. In the Short Description field, enter a short description of the default. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 6. In the Description field, enter a description of the default.

September 2008

207

5 Compliant User Provisioning User Default Management 7. In the Start Menu field, enter an SAP-specific (SU01) start menu. 8. From the Logon Language dropdown list, select the default language to be used during logon. 9. From the Decimal Notation dropdown list, select a decimal notation style for the default. 10. From the Date Format dropdown list, select a date format for the default. 11. From the Output Device dropdown list, select an output device for the default, such as a printer. 12. From the User Group dropdown list, select a default user group. 13. Select the Output Immediately checkbox, if you want the output to be immediately sent (to a printer, for example), rather than waiting to send output collectively in a batch job. 14. Select the Delete After Output checkbox, if you want the output to be deleted instead of stored. 15. In the Parameter ID (PID) Details group, click the value. You can add multiple parameters. 16. Click Save. icon to add a parameter and its

Setting User Default Mapping Example You can map a user default with one or many attributes (along with the associated conditions and values) so that when a submitted request meets the specified settings, the request is automatically assigned the user defaults. For instance, you map the user default to have the attributes, Request Type=New and Functional Area=Finance . Any request having these two attributes are automatically assigned the user defaults. Procedure To set user default mapping: 1. On the Configuration tab, navigate to User Defaults > User Default Mappings. The Available User Default Mapping screen appears. 2. Click Create. The Create User Default Mapping screen appears. 3. In the Name field, enter a name for the user default mapping. 4. In the Short Description field, enter a short description of the default mapping. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. In the Description field, enter the description of the default mapping. 6. From the User Defaults dropdown list, select a user default. The User Defaults in the dropdown list are created using the User Default option. For more information on creating these, see the section Configuring User Defaults.

208

September 2008

5 Compliant User Provisioning Attachments 7. From the Attribute dropdown list, select an attribute. This is a Compliant User Provisioning-specific attribute. 8. From the Value dropdown list, select a value. The values are automatically populated in the dropdown list based on the specified attribute. 9. From the Condition dropdown list, select a logical operator. 10. Click Add Attribute. The default mapping appears in the User Default Mapping Details screen. 11. Click Save. Selecting a User Default System Procedure To select a user default system: 1. On the Configuration tab, navigate to User Defaults > User Defaults System. The User Default System screen appears. 2. From the System dropdown list, select the desired SAP system. 3. Click Save.

Changing User Defaults Procedure 1. On the User Default screen, select the user default you want to change. 2. Click Change. The Change User Defaults screen appears. 3. Make any changes. 4. Click Save.

Deleting User Default Mapping Procedure To delete a user default mapping: 1. Select the user default mapping you want to delete from the User Default Mapping Details table. 2. Click Delete.

Attachments
The Attachments feature adds attachments at the request level. Attachments are not stored in Compliant User Provisioning due the amount of disk space they require. You must designate a network folder to store all attachments.

September 2008

209

5 Compliant User Provisioning System Log Monitoring Provide Folder For Request Attachments: By entering the folder in this field you are enabling the attachment feature. Leaving this field blank disables the Attachment feature and prohibits requestors from attaching external documents to the requests.

System Log Monitoring

The Monitoring option allows you to view the system log and see what applications are provisioned in Compliant User Provisioning.

210

September 2008

5 Compliant User Provisioning System Log Monitoring The Monitoring option provides access to the following logs: System Log Monitoring Access Log Monitored Description

System Log Use the System Log option to view the current log file. The system log contains such information as errors, sequence of operation, transaction flow, and exception reports. For more information, see the section Viewing the System Log. Application Log Use the Application Log option to view a users access history to applications with that users provisioning actions in Compliant User Provisioning. The application log displays the following types of actions: USER CREATE Action that indicates that a user was created in SAP by an Compliant User Provisioning approver. ROLE ADD USER LOCK USER UNLOCK ROLE DELETE USER DELETE For more information, see the section Viewing the Application Log.

Viewing the System Log Procedure To view the system log: 1. On the Configuration tab, navigate to Monitoring > System Log. The Application Trace screen displays the default system log file name. 2. Click Get Log. The system log appears.

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.

September 2008

211

5 Compliant User Provisioning HR Trigger Configuration 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 Configuration
The HR Triggers option creates rules in the SAP HR system and associates Compliant User Provisioning actions to those rules. When an event is triggered in the SAP HR system, such as the hiring of a new employee or an employee termination, rules are applied along with their corresponding HR Triggers. The system then performs an action in the form of a request. The HR Triggers option provides four tools to create and manage rules for HR Triggers: HR Trigger Configuration Tools Tool Actions Description This option creates actions. HR Triggers are associated with the following action types: 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 custom actions that were created using the Create Request Type screen. For more information on creating actions for HR Triggers, see the Creating an Action section 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 a Rule. Field Mapping This option maps fields to corresponding fields in the SAP HR system. For more information, see the section Mapping Fields Using the SAP HR System.

212

September 2008

5 Compliant User Provisioning HR Trigger Configuration

HR Trigger Configuration Tools Tool Process Log Description This option allows you to view all of the processes that are associated with HR Triggers. To view the Process Log, navigate to HR Trigger > Process Log on the Configuration tab. The Process Log screen appears. The approvers you define using this option appear throughout Compliant User Provisioning as part of the approval or workflow process. To use the HR Triggers option, configure the background daemons as a scheduled job. For more information, see the section Background Job Set Up. Recommendation SAP recommends that you set the HR Trigger Load Data job to 60 seconds. The HR Trigger Load Data background daemon retrieves HR data resulting from trigger rules/actions. Set the HR Triggers job to 80 seconds. The HR Trigger background daemon 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. The information in the Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited to 38 characters. 5. In the Description field, enter a description for the 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 the action.

September 2008

213

5 Compliant User Provisioning HR Trigger Configuration 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 user name 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 email address 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 the users telephone number to be updated in all corresponding SAP systems specified on the 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 the parameter ID to be updated in all corresponding SAP systems specified on the Systems tab. 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 user defaults 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 the user group to be updated in all corresponding SAP systems specified on the Systems tab. 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 takes effect. 6. In the Rule Short Description field, enter a short description for the rule.

214

September 2008

5 Compliant User Provisioning HR Trigger Configuration

The information in the Rule Short Description field appears in dropdown lists throughout Compliant User Provisioning when you perform a query. This field is limited 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 > Actions screen. For more information about creating HR trigger actions, see the section Creating 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 the sequence 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 columns become 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 info type 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 is stored 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 for your rule. If the $ symbol precedes the field value, it denotes the previous value for this field. For example, if the field is Admin and the value is $admin and uses the operator <> (not equal), your rule evaluates these two fields to be different. 19. From the And/Or/Not dropdown list, select the logical operators you need for additional attributes in your rule. 20. Click Save.

September 2008

215

5 Compliant User Provisioning HR Trigger Configuration Changing a Rule Procedure 1. On the Rules screen, select the rule name you want to change or delete. 2. Click Change. The fields under the Info Type, Sub Type, Field, Operator, Value, and And/Or/Not columns become active. 3. Make any modifications. 4. Click Save. 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 AE field. 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 on the specified info type. 7. Click Save. 8. Click Load Standard Field Mapping to upload the standard field mapping from the SAP HR system to Compliant User Provisioning. 9. Click Save. Schedule HR Trigger Background Jobs To get information from the SAP HR system to Compliant User Provisioning, you need to configure the background daemons to schedule HR Trigger jobs. The two jobs you need to schedule for the HR Trigger function are: HR Triggers Load Data It is recommended that you schedule this job for every 60 seconds. This job is scheduled to update CUP HR Trigger rules and actions to the AC RTA installed on the SAP HR system.

216

September 2008

5 Compliant User Provisioning Password Self Service

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 to specified rules to generate requests in CUP. For more details on job scheduling, see the Background Jobs section. View Process Log To view the process log, click Process Log. This page shows all HR Triggers-related requests. If the request number is displayed, the request is processed. If no request number is displayed, either there is an error or the request has not processed. The comments field provides a brief explanation of the request and its status.

Password Self Service

The Password Self Service option allows end users to reset their passwords in the SAP backend system without having the SAP Help Desk or the SAP Security Group involved. This tool saves the SAP Security Group time and expedites the password resetting process for the end user. The Password Reset via a CUA requires that the attribute for Inital Password is set to Everywhere in the CUA central system. You can use transaction SCUM to set the attribute. There are three options for Password Self Service: SAP HR Authentication: Requires the SAP HR module to be used for personnel information and personnel numbers linked to SAP user IDs, so that the user submitting the request for the password reset can be verified against their personnel data in the SAP HR system. Challenge Response: Allows the administrator to configure questions that the users can register their answers against. When a user enters a request to reset their passwords, they are asked to answer the questions as they have pre-registered them. Only on successful answering the questions will the passwords be reset. Peoplesoft HR Authentication: Requires the Peoplesoft HR module to be used for personnel information, so that the user submitting the request for the password reset can be verified against their HR data. When a user enters a request for a password reset, Compliant User Provisioning validates that user against the selected password self-service option. Once the user has been verified, the passwords are reset and an email is sent to the user based on the email address configured for that user. 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 includes configuration of which infotype, field, value combination in SAP HR personnel record is verified against the user. In configuration, select the infotype and field combination. When the user enters the request to reset their passwords, the user is asked to enter information based on the infotype field configured. The information they enter is matched against the users personnel record on that

September 2008

217

5 Compliant User Provisioning Password Self Service specific infotype value. If there is a match, the passwords are reset and sent to the email listed on the SAP HR personnel record. Compliant User Provisioning matches user IDs with HR personnel records using the Communication Infotype 0105 record subtype 01 Example Configuration is set to compare the users Social Security Number (SSN). The administrator selects the infotype and field combination where the SSN is stored in the HR personnel record. When the user requests a password reset, they are asked to enter their SSN. Based on the user ID, the HR personnel record is found and the SSN entered by the user is compared to the SSN listed on the HR record. If they match, the passwords are reset and an email sent to the user. Configuration can include one or multiple infotype/field combinations. The user could be asked to enter multiple responses which will be compared to the HR record. For instance, it can be configured that the user must enter their SSN, their national insurance number as well as their birth date. Procedure 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 working for SAPHR. 4. In the Info Type field, enter the info type, or click the search icon to query available info types. 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 from the System dropdown list. 11. Click Save. 12. On the Default System screen, select a system to authenticate passwords from the System 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 the users can choose from. The number of questions that the user must enter can also be configured. In addition to the questions, the administrator decides how many wrong answers

218

September 2008

5 Compliant User Provisioning Password Self Service are permitted before the user ID is locked. After this happens, a Compliant User Provisioning Administrator has to get involved to unlock the user ID. After configuration is complete, each user must self-register themselves, choose the questions they wish to answer and answer them. Their answers are then stored in Compliant User Provisioning. When a user enters a password reset request, they are asked to answer the questions they selected during self-registration. If they answer them correctly, their user IDs are reset and the 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. A notification email is sent to the user with password information. If the user logon fails after a number of attempts, the user is locked. The user must then click the Password Self Service link in the End User Form to access the Self-Registration screen. In this screen, the user can select the questions they would like to answer and submits the answers. Compliant User Provisioning verifies that the questions are correct, and if so, it sends a notification email to the user with a new password. Example As the administrator, you can create challenge questions for end users to select and answer. After creating these questions, you must activate them in order to display them when the end user accesses the Registration link from the End User Form. These questions should be generic and easy to answer. For instance, a simple challenge question may be, What is your favorite color?

Procedure To configure password self service for Challenge Response: 1. On the Configuration tab, navigate to 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 are reset. 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 their user 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 their user 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 End User 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.

September 2008

219

5 Compliant User Provisioning Miscellaneous Configuration 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 screen changes for the Type selected. 3. Specific table and field information must be entered in accordance with Peoplesofts HR module.

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 are displayed on this screen. Once searched, the users user ID, status and number of attempts to answer their challenge questions are displayed. If a user gets locked due to the number of unsuccessful attempts, the administrator must to unlock their user ID from this screen. Delete - deletes the users registration record. The user must perform self-registration again to choose and answer their challenge questions. Unlock - unlocks the user who has been locked due to unsuccessful attempts to answer the challenge questions. This feature is controlled by a User Management Engine permission. Users must self-register to answer their challenge questions. Users are also able to reregister anytime by choosing the re-register option on the Password Self-Service screen after they have answered their challenge questions.

Miscellaneous Configuration
The Miscellaneous Configuration screen defines system-level settings not associated with other features of Compliant User Provisioning. It establishes the workflow types to be integrated with the other GRC Access Control features and capabilities. You can configure the following settings from this screen: Language Configuration Log Level Configuration

220

September 2008

5 Compliant User Provisioning Miscellaneous Configuration Cache Job Interval Configuration Background Job Interval Configuration Configure Workflow Types Language Configuration When you initially log on to Compliant User Provisioning, three fields are displayed on the Welcome screen: User ID, Password, and Language. Although User ID and Password are required fields, Language is not. Set a default language in the Miscellaneous screen by selecting a language from the Language dropdown list and then clicking Save. Log off and then log back on for this change to take effect in the user interface. If a user selects a language from the Language dropdown list on the Welcome screen that differs from the default language specified on the Miscellaneous screen, the default language is overridden and the user interface appears in the end user-selected language.

To ensure proper display of object descriptions, you must create all objects in the default language. Objects created in a non-default language display descriptions in the default language even when logged on to a different language. When users log on to Compliant User Provisioning using the default language, they can create objects such as Initiator, Stage, Path, Approver, and the like. However, if they log on using a language from the Language dropdown list on the Welcome screen that differs from the default language specified in Miscellaneous Configuration, they can only use the Change option to modify the object settings. They cannot use the Create option to create a new object. By default, Compliant User Provisioning shows the default language description and allows the end user to modify the object with the corresponding language text. Log Level Configuration Each transaction that is performed generates a message and in some cases, multiple messages. Compliant User Provisioning automatically logs these messages. When you configure the log level setting, you specify which transaction messages it logs and which it ignores. There are four log levels: Debug logs all messages, regardless of type. Info logs all error, warning, and information messages. Warn logs all error and warning messages. Error logs all error messages (no warning or information messages). To set the log level, select the level from the Log Level dropdown list, and then click Save.

Cache Job Interval Configuration For a high standard of performance, Compliant User Provisioning maintains a store of system data in a cache. This allows access to key data without having to perform a database call. On start up, the system loads the data from its database into the cache, and it refreshes the data each time it performs a transaction.

September 2008

221

5 Compliant User Provisioning Miscellaneous Configuration To ensure that the cached data is current, even when Compliant User Provisioning is idle, the system periodically refreshes the cache. When you configure the cache job interval, you specify the amount of time that must elapse before the system automatically refreshes the cache data. You define the interval in seconds. To set the Cache Job Time Interval, enter the number of seconds that the application must wait before refreshing the cache into the Cache Job Time Interval in Seconds text field and then click Save. Configure Workflow Types The Configure Workflow Types feature establishes the workflow types to be integrated with the other GRC Access Control features and capabilities. Although some of the Workflow Type configuration is delivered with the initial system data, you must configure the additional fields and URLs for your system. Name is delivered by the Initial System Data XML file loads. Description and Short Description: Although these fields come populated by the System Data load, you cannot change these descriptions. The Short Description is displayed on screens and on dropdown lists throughout Compliant User Provisioning. Exit URL: This is the URL that Compliant User Provisioning uses to connect and communicate with this capability. MITICTRL:
http://<server>:<port>/VirsaCCWFExitService5_2Service/Config1?wsdl&style=document

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

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

RE http://<server>:<port>/AEWFExitServiceWS_5_2/Config1?wsdl&style=document User Name: This is the name of the user Compliant User Provisioning uses to access that capability. This user ID must have the appropriate User Management Engine permissions to perform the tasks that are required. Password: This is the password for the specified user name. Active: This value determines whether this workflow type is active or not for your system. If the checkbox is selected, it is active. If not, this workflow type is not active, it cannot be used in configuration, and it is not displayed in the Compliant User Provisioning screens and dropdown lists.

Configure the Background Job Interval Compliant User Provisioning uses a daemon process to run scheduled background jobs. The daemon runs periodically and executes all background jobs scheduled to run. Setting the background job interval determines how much time must elapse before the background job daemon is executed. To set the Background Job Time Interval, in the Background Job Time Interval in Minutes field, enter the number of minutes that Compliant User Provisioning waits before running the background job daemon. Then click Save.

222

September 2008

6 Enterprise Role Management Configuring Enterprise Role Management

6 Enterprise Role Management

Enterprise Role Management allows you to create and maintain roles to reflect your business model and requirements. You should set up a functional environment and test it thoroughly before attempting to use it in a production environment.

Configuring Enterprise Role Management

SAP recommends that you configure certain functions before others In Enterprise Role Management. Process The suggested order for configuring Enterprise Role Management is: 1. Set up initial logon to Enterprise Role Management 2. Import initial system data 3. Define system landscape 4. Configure management of role attributes 5. Configure management of condition groups 6. Set up role creation methodology 7. Configure management of naming conventions 8. Configure management of organizational value mapping 9. Configure Risk Analysis and Remediation 10. Configure workflow management 11. Configure Compliant User Provisioning

You can configure the following functions in any order: Enterprise Role Management system logs Management of background jobs Mass role import Other functions

Initial Logon to Enterprise Role Management

After installing Enterprise Role Management on a SAP NetWeaver server, use a Web browser to log on and access it. Typically the URL for Enterprise Role Management logon is: http://<server>:50000/RE/index.jsp This is where the SAP NetWeaver server, by default, runs (port number 50000). If you log on within the company firewall, the SAP system administrator can provide the server address. On the initial screen, select User Logon to display the Logon screen, and then use the REAdmin user name and password.

September 2008

223

6 Enterprise Role Management Initial System Data Importation

The REAdmin user name and password are created during the Access Control installation process. For more information, see the section Role Creation. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Initial System Data Importation

Before you configure Enterprise Role Management, you must import initial system data. This data is the default system data that is pre-packaged with the system. It is the minimum set of data required for the application to function and is imported from within the application itself. Import initial system data only if it was not done during the post-installation phase of the SAP GRC Access Control installation process as described in the section Role Creation. For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3.

Importing Initial System Data Procedure To import initial Enterprise Role Management configuration data: 1. On the Configuration tab, navigate to Initial System Data. The Import Data screen appears. 2. Click Browse. 3. Navigate to the directory containing the Enterprise Role Management installation files. 4. In the Browse window, double-click the appropriate XML file. 5. In the Enterprise Role Management content screen, click Import. The files you import are: RE_init_clean_and_insert_data.xml: Select Insert. RE_init_append_data.xml: Select Append. RE_init_methodology_data.xml: Select Append. This step is required only for a new installation or if you want to reload the default data originally shipped with Enterprise Role Management. Result Initial system data is now imported, and Enterprise Role Management is now ready for further configuration. Initial Background Job Executing initial background jobs for Org Value Sync, Transaction/Object/Field Sync, and Activity. Org Val Sync is a prerequisite for SAP role authorization data maintenance and organizational value mapping.

224

September 2008

6 Enterprise Role Management Managing Background Jobs

Managing Background Jobs

You use background jobs to synchronize information in Enterprise Role Management with the SAP back-end system and to perform mass maintenance. Enterprise Role Management provides two kinds of background job: Dynamic - Dynamic background jobs are scheduled by Enterprise Role Management users through mass role import and role mass maintenance. For more information see the sections Mass Role Import and Role Mass Maintenance. The following dynamic background jobs are available: Role Generation This job sends role information from Enterprise Role Management to the SAP back-end system. You can use the Mass Generation option to schedule the background job. Risk Analysis and Role Generation This job schedules role generation for a particular role. You use the Role Maintenance screen to schedule a background job. Risk Analysis This job schedules a risk analysis for a set of roles. You use the Mass Risk Analysis option to schedule the background job. Role Import This job uploads the roles from the SAP back-end system to Enterprise Role Management. You use the Mass Role Import screen to schedule a background job. Role Usage Synchronization This job synchronizes usage data. You use the Role Usage Synchronization screen to schedule a background job. Static - Static background jobs are scheduled by the Enterprise Role Management administrator and can be run immediately or periodically to synchronize the SAP system with Enterprise Role Management. The following static background jobs are available: o o o Org Value Sync: This job synchronizes the organizational values in Enterprise Role Management with the SAP ERP back-end system. Transaction/Object/Field Sync: This job synchronizes the Transaction, Object, and Field values with the SAP back-end system. Activity Val Sync: This job synchronizes Activity field values.

Using the Enterprise Role Management background job feature, you can: Create background jobs. Search for specific background jobs. Schedule background jobs to run immediately or at a specific time in the future. Edit existing background jobs. Delete background jobs. Activate or deactivate scheduled background jobs. View a background jobs history. You can schedule the number of background jobs you want to run concurrently by setting the count on the Miscellaneous screen. This setting allows only a fixed number of background jobs to run at one time. If the number of background jobs scheduled to run exceeds the

September 2008

225

6 Enterprise Role Management Managing Background Jobs number set on the Miscellaneous screen, the surplus jobs are queued and run in the order scheduled. For more information about scheduling the number of background jobs to run concurrently, see the section Configuring Miscellaneous Functions.

Creating a Static Background Job Procedure To create a static background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click Create. The Schedule Service screen appears. 3. In the Job Name field, enter the name you want to give the background job. 4. From the Task Name dropdown list, select the type of task you want to run. 5. From the Schedule Type dropdown list, select when you want the background job to run. Selecting any value other than Immediate displays a scheduling screen where, depending on the schedule you selected, you can schedule: The start and end date The time for the job to run The day, month, quarter, or year for the job to run The specific date for the job to run 6. Click Schedule. The system provides a Job ID number and places it in the top position in the Search Results screen of the Background Jobs screen. Editing a Background Job Procedure To edit a background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click the radio button next to the Job ID of the background job you want to change. 3. Click Edit. The Schedule Service screen appears. 4. Make any changes. 5. Click Schedule.

226

September 2008

6 Enterprise Role Management Managing Background Jobs 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. The Background Jobs screen appears. 2. Click the button next the Job ID of the background job you want to delete. 3. Click Delete. 4. Click OK to confirm the deletion. Activating/Deactivating a Background Job Procedure 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. The Background Jobs screen appears. 2. Click the button next to the Job ID of the background job you want to activate or deactivate. If a background job is active, the light bulb icon in the Active column appears as on. If the background job has been deactivated, the light bulb icon appears as off. 3. Click Activate or Deactivate. Searching for a Background Job Procedure To search for a background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Select your search criteria from the available dropdown lists. 3. Click Search. The results of your search appear in the Search Results screen. Viewing the History of a Background Job Procedure To view the history of a background job: 1. On the Configuration tab, navigate to Background Jobs. The Background Jobs screen appears. 2. Click the button next to the Job ID of the background job for which you want to view a history.

September 2008

227

6 Enterprise Role Management Configuration for Risk Analysis Integration with Risk Analysis and Remediation 3. Click Job History. The Background Job History screen appears.

Configuration for Risk Analysis Integration with Risk Analysis and Remediation
Enterprise Role Management works directly with Risk Analysis and Remediation to perform the 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 NetWeaver server. If it is on the same server, select Do not use Web Service and skip only the configuration for CC Risk Analysis in step 4. For this option, Enterprise Role Management integrates with Risk Analysis and Remediation using EJB service within the Web server to facilitate faster integration. Configuration for all other Web services in step 4 is still required. If it is not on the same server, select Use Web Service, and continue with step 4 to configure all Web services. 4. On the Configuration tab, identify the correct Risk Analysis and Remediation Web service URLs, and then enter each in its corresponding field on the following screens: Web Service Info. for CC Risk Analysis Web Service Info. for CC Transaction Usage Web Service Info. for Mitigation Control Web Service Info. for CC Functions To identify the correct Web service URL: a. Open a new browser session, and navigate to the Web Application Server http://<server>:50000/. b. In the new browser window, click Web Services Navigator to display the Web Services 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.

228

September 2008

6 Enterprise Role Management Configuration for Workflow Integration with Compliant User Provisioning 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 into the 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 CC screen's fields. Obtain the Web service user name and password for the Web services from your system administrator. This user communicates across the GRC capabilities through the Web services configured in each application. Use the same user name and password information from the connector and create a common Web user in the User Management Engine (UME) for all capabilities. Using the same user for all Web service configurations across the GRC capabilities helps avoid integration issues caused by incorrect user name, password, and/or authorizations. 6. Click Save.

Configuration for Workflow Integration with Compliant User Provisioning

Enterprise Role Management integrates with Compliant User Provisioning for the role approval workflow feature. During the approval phase, the role is submitted for approval using Compliant User Provisioning approval workflow.

Configuring Compliant User Provisioning Workflow for Enterprise Role Management Procedure You perform the workflow configuration activities for the Enterprise Role Management approval process in Compliant User Provisioning. To configure Compliant User Provisioning for use with Enterprise Role Management, you must have Compliant User Provisioning administrator privileges. For more information on completing the following procedure, see the section Workflow under Compliant User Provisioning. 1. On the Configuration tab of Compliant User Provisioning, navigate to Initial System Data. 2. Import the initial configuration data from the file AE_init_append_data_RE.xml into Compliant User Provisioning, using Append on the Import Initial Data screen. For more information, see the Compliant User Provisioning section of this guide. Import initial system data only if it was not done during the SAP GRC Access Control installation process as described in the section Role Creation.

September 2008

229

6 Enterprise Role Management Configuration for Workflow Integration with Compliant User Provisioning For more information, see the SAP GRC 5.3 Access Control Installation Guide on SAP Service Marketplace at http://service.sap.com/instguides -> SAP Solution Extensions -> SAP Solutions for GRC -> SAP GRC Access Control -> SAP GRC Access Control 5.3. After the initial configuration data is imported, you see RE in the dropdown list for workflow types during the following configuration steps. If you do not see the RE type, the initial data file was not imported successfully. 3. Select Request Configuration. 4. Create a Request Type for Enterprise Role Management requests. These requests are role approval requests from Enterprise Role Management. Make sure you activate the request type. The request Workflow Type must be set to RE. 5. Create a Priority for Enterprise Role Management requests. The priority Workflow Type must be set to RE. 6. Select Workflow. 7. Create an Initiator for Enterprise Role Management requests. a. Click Initiator. b. Click Create. c. Enter Initiator Name and Description

d. Set the initiator Workflow Type to RE. e. Select Condition And and Attribute Request Type. f. Select Value from the dropdown list. This should be the request type for Enterprise Role 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 Role Management 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 in the section Configuring Enterprise Role Management Web Services for Compliant User Provisioning. Expand the AEWFCADApproversServiceWS_5_2 folder to obtain the correct Compliant User Provisioning URI.

230

September 2008

6 Enterprise Role Management Configuration for Workflow Integration with Compliant User Provisioning The Web service user must be the same user you created for application integration in the earlier configuration step. 9. Create the Enterprise Role Management approver stage for the approval workflow process. Depending on your approval process, you can create an additional approval stage by creating another Custom Approver Determinator by repeating step 8. Using CAD Type Attribute. The Workflow Type must be set to RE. The approver determinator you select here is the custom approver determinator you created in step 8. 10. Create a workflow path for the Enterprise Role Management approval process: a. Click Path. b. Click Create. c. Enter Path Name and Description.

d. Set the Workflow Type to RE. 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. j. Select Miscellaneous to configure exit Web service for Enterprise Role Management approval workflow. Configure the exit Web service information for Enterprise Role Management approval workflow.

The Exit URL is the return path for role approval or rejection information from Compliant User Provisioning to Enterprise Role Management. To find the correct exit URL for Compliant User Provisioning, follow steps a through d in the section Configuring Enterprise Role Management Web Services for Compliant User Provisioning. Expand the AEWFExitServiceWS_5_2 folder to obtain the correct Compliant User Provisioning Exit Service URL. 11. Click Active. Configuring Enterprise Role Management Web Services for Compliant User Provisioning Procedure To configure Enterprise Role Management's Web services for Compliant User Provisioning: 1. On the Configuration tab in Enterprise Role Management, navigate to Miscellaneous. The Configuration screen appears. 2. Identify the correct Compliant User Provisioning Web service URL: a. Open a new browser session and navigate to the Web Application Server http://<server>:50000/. b. Click Web Services Navigator. The Web Services Navigator screen appears.

September 2008

231

6 Enterprise Role Management System Landscape Definition c. Expand the AEWFRequestSubmissionService_5_2 folder, and then click Document. The Web service URL is listed below the WSDL (Web Services Description Language) heading. d. Right-click Web Service URL and select Copy Shortcut from the context menu. 3. Return to Enterprise Role Management's Configuration screen, and paste the URL into the Workflow URL field in the Web Service Info. for AE Workflow section. 4. Click Save to save your selections.

System Landscape Definition

A system landscape is a configuration of systems where role definition, creation, testing, and risk analysis are performed. Prior to creating a landscape, you must define the systems, determine which system for which you plan to generate roles, and which system you plan to use for risk analysis purposes only. Then, you can create a system landscape where each system is associated with the actions to be used in the role management process. Any field name denoted with an asterisk (*) is required. If you adhere to change control procedures in your ERP application (where all roles are created in Development, then transported to Quality Assurance/Production), you should not have a production system in your landscape associated with Role Generation action. Example You have three systems (or connectors) in a landscape, in which to perform the role creation process: Test Development Production or Quality Assurance This landscape uses the test system to design, define, and test your roles. When you are comfortable with the role definition, generate the role in the development system for additional testing. When you have successfully tested it in the development system, transport the role to the quality assurance system and then to the production system, according to your existing ERP change control procedure by using ERP change control tools. For risk analysis to reflect your most realistic risk, the either the production system or the quality assurance system serves as the system of origin against which you perform risk analysis.

Defining Connectors for Enterprise Role Management.

You can set up different types of connectors in Enterprise Role Management. These include Enterprise, non-SAP, SAP, and SAP EP connectors. The Enterprise, non-SAP, and SAP EP connectors are descriptive connectors used to document the landscape to which each role belongs. The SAP connector is a live system connector that facilitates the transfer of data between Enterprise Role Management and other SAP ABAP systems. When setting up a landscape, you specify how you want Enterprise Role Management to communicate with the target systems by associating the connectors with predefined actions during the landscape creation process.

232

September 2008

6 Enterprise Role Management Defining Connectors for Enterprise Role Management.

The actions available for you to associate the connectors with are delivered with Enterprise Role Management. You cannot create your own actions. Access Control communicates with multiple systems; therefore SAP recommends using HTTPS communication protocol for secure communication. Configuring a Connector for SAP Your network administrator must provide information for completing the Create System screen. Procedure To create a connector for SAP ABAP systems: 1. Go to Enterprise Role Management > Configuration tab > System Landscape > Systems. The Available Systems screen appears. Until you create your first connector, the Available Systems screen is blank. 2. Click Create. The Create System screen appears. 3. In the System Type dropdown menu, select SAP. 4. Select the SLD Connector checkbox to activate the Standard Landscape Directory. 5. In the Name field, enter the target system name. This is the SAP connector name. The connector names are very important when integrating to other GRC products and the CUA. Make sure that the connector name for Access Control is the same as the one configured for CUA. 6. In the Description field, enter a detailed description of the system connector, such as HR QA System. 7. In the Application field, enter the name of the application or application server. 8. In the Application Server Host field, enter the host name of the application server. 9. In the System Number field, enter the number in the SAP system log. 10. In the Client field, enter the SAP client number. 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 used for load balancing of your SAP clustered environment. 15. In the Message Server Group field, enter the Logon Group name the message server belongs. 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 Role Management supports SAP 4.6c and higher. 18. Click Save.

September 2008

233

6 Enterprise Role Management Defining Connectors for Enterprise Role Management.

When you have created the new connector, click Test Connection to ensure that the connection 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 and non-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 System screen. 3. In the System Type dropdown menu, select Non SAP. 4. In the Name field, enter the name of the system. 5. In the Description field, enter a detailed description of the system. 6. Click Save. After you create the new connector, click Test Connection to ensure that the connection is valid.

Creating the Landscape A system landscape is a logical grouping of systems. A landscape contains more than one system and is populated by assigning systems and then associating them with a predefined action or actions. Associating actions with a system defines which action is performed in which system within a particular landscape. Example You can associate role risk analysis with a test system or a production system and a generation of roles to a development system. The predefined actions you can associate with a connector in a landscape are: Role risk analysis Generation of roles These predefined actions are delivered with Enterprise Role Management. You cannot create your own actions. Setting up a landscape allows you to associate role definitions that you create in Enterprise Role Management to multiple systems. The landscape can contain SAP and non-SAP systems. You can configure certain role definitions to be associated to a specific landscape.

234

September 2008

6 Enterprise Role Management Defining Connectors for Enterprise Role Management. Example You create a landscape that contains the system types SAP HR system, SAP FI system, and Oracle Application system (non-SAP). Each of these system types has a system for Development, Test, and Production. You name this landscape, Palo Alto Landscape. In Enterprise Role Management, go to the Role Management tab > Roles > Create to create a role definition and specify the landscape, Palo Alto Landscape. In the Role Generation phase of role creation, you can select the appropriate system (with Generation of Role action assigned) for the role generation. Automated Role Generation from Enterprise Role Management is applicable to SAP ABAP only. After completing the creation of role definitions, you must define the Web service URL that submits the role definitions to the approval workflow process in Compliant User Provisioning. Go to Configuration tab > Miscellaneous. In the Configuration screen, enter the Web service URL in the Web Service Info. for AE Workflow pane. In Compliant User Provisioning, a request is submitted to the approval workflow. This request is a RE (Role Expert) workflow type. Make sure that the RE workflow type is active by going to Compliant User Provisioning > Configuration tab > Miscellaneous. After the request is approved in the last stage in the workflow process, the role is saved to the Palo Alto Landscape.

Creating a Landscape Procedure 1. To create a landscape: 2. On the Configuration tab, navigate to System Landscape > Landscape. The Search System Landscape screen appears. 3. Click Create. The Create Landscape screen appears. 4. In the Name field, enter a name for the landscape. 5. In the Description field, enter a brief description for the landscape. 6. From the Status dropdown list, select Enable or Disable for the landscape. If the landscape is enabled, it is visible during the role creation process. 7. From the Type dropdown list, select a system type. 8. Click Save. Now you can assign systems to the landscape. For more information, see the section Assigning Systems to the Landscape.

Assigning Systems to the Landscape Procedure Before you can assign systems to a landscape, you must create the landscape. To assign systems to the landscape:

September 2008

235

6 Enterprise Role Management Defining Connectors for Enterprise Role Management. 1. On the Configuration tab, navigate to System Landscape > Landscape. The Search System Landscape screen displays available system landscapes. Search for the landscape on the search screen, or scroll down the landscape list. 2. Select the landscape you would like to perform system assignment to by selecting the checkbox next to the landscape name. 3. Click Change. The Change Landscape screen appears. 4. Click Assign Systems. The Assign Systems to Landscape screen appears. You can assign one or more systems to a landscape, depending on the actions you want the system to perform. 5. Click Add. All systems available for this landscape type appear on a dropdown list for the user to select. 6. Select a System from the dropdown list. 7. To assign more systems to the landscape, repeat steps 5 and 6. 8. Click Save. The systems are assigned to the landscape, and you can associate the systems with predefined actions. Associating Actions Procedure To associate actions with systems assigned to a landscape: The actions available to associate with the systems are delivered with Enterprise Role Management. You cannot create your own actions. 1. On the Configuration tab, navigate to System Landscape > Landscape. The Search System Landscape screen displays all available system landscapes. Search for a landscape on the search screen, or scroll down the landscape list. 2. Select the landscape you would like to perform system assignment to by selecting the checkbox next to the Landscape Name. 3. Click Change. 4. From the Change Landscape screen, click Assign Systems. 5. From the Assign Systems to Landscape, click Associate Actions. 6. From the Associate Actions screen, assign systems to actions. To activate a dropdown list from which you can select a connector for an action, click the Add icon under the action you want to associate. 7. Click Save. An Option button appears in the Default column. 8. To set a default system for the landscape, click the Option button to the right of the action you want to set as default.

236

September 2008

6 Enterprise Role Management Role Designer The system and its associated action are automatically saved in the landscape as the default connector. If you have associated more than one system with an action, you must set a default connector for that action. For example, systems A, B and C are assigned to the action Generation of Roles. By setting connector B as the default connector for that action, the system generates all roles created in this landscape with connector B. For individual role generation, you change the default or add more systems on the Role Generation screen. For mass role generation, the default system is always used and cannot be changed, unless you change the default in your system assignment configuration.

Role Designer
Role Designer provides you with a logical, step-by-step roadmap to support configuration of role master data for your Enterprise Role Management process. Following the outlined procedure ensures that major role master data configuration steps or data to be associated with each role are not missed. Features When you select the role designer step, the system takes you directly to the configuration task to allow you to: Define role building methodology Define naming conventions Define role attributes Define organizational value mapping Define approval criteria Analyze transaction usage for roles Managing Role Attributes Role attributes are the details that define a role during the role definition and creation process. You determine values for each attribute during Enterprise Role Management configuration and then assign or input the defined attributes when you create a role. Role attributes you can manage include: Business Processes Business Subprocesses Functional Areas Custom Fields Projects and Releases Managing Business Processes A business process is a collection of related activities that produces something of value for your organization or business and is categorized according to the organizational structure of your enterprise. A business process can be managerial, operational, or supporting, and can be defined narrowly or broadly, depending on your business needs. When you create a role in Enterprise Role Management, the business process you assign to the role is one of the roles defining attributes and determines which subprocesses you can assign to that role.

September 2008

237

6 Enterprise Role Management Role Designer

Any field name denoted with an asterisk (*) is required. Example Some examples of business processes are: Finance Accounts payable Policy and budget Procure to pay Creating a Business Process Procedure To create a business process: 1. On the Configuration tab, navigate to Role Attribute > Business Process. The Search Business Process screen appears. 2. Click Create. The Create Business Process screen appears. 3. In the Business Process ID field, enter a name for the business process. 4. In the Description field, enter a brief description for the business process. 5. In the Abbreviation field, enter an abbreviation for the business process. The abbreviation you provide is used as a bar label in the Role Library, Roles by Business Process bar graph on the Role Management tab. 6. Click Save. Your business process is saved and now appears in the list of business processes on the Search Business Process screen. Changing a Business Process Procedure To change a business process: 1. On the Search Business Process screen, select the checkbox next to the business process you want to modify. 2. Click Change. The Change Business Process screen appears with the Business Process ID dimmed, indicating that the ID itself cannot be changed. To change a business process ID, you must delete the business process and create a new one. 3. Make any changes to the description or abbreviation. 4. Click Save. Deleting a Business Process Procedure To delete a business process:

238

September 2008

6 Enterprise Role Management Role Designer

A business process can be deleted only if it is not associated with a role, business subprocess, approval criteria, or condition group. 1. On the Search Business Process screen, select the checkbox next to the business process you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion. Importing a Business Process Procedure You can either maintain the business processes in Enterprise Role Management manually or mass import your data using the import feature. 1. On the Search Business Process screen, click Import. The Import Business Process screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import. The system message Business Process saved successfully indicates that the data was imported successfully. Managing Business Subprocesses A business process can be divided into several business subprocesses, each with its own attributes. A business process typically contains one or more subprocesses. Any field name denoted with an asterisk (*) is required. Creating a Subprocess Procedure To create a subprocess: 1. On the Configuration tab, navigate to Role Attribute > Subprocess. The Search Subprocess screen appears. 2. Click Create. The Create Subprocess screen appears. 3. In the Subprocess ID field, enter a name for the subprocess. 4. In the Description field, enter a brief description for the subprocess. 5. In the Abbreviation field, enter an abbreviation for the subprocess.

September 2008

239

6 Enterprise Role Management Role Designer 6. Click Save. Your subprocess is saved and now appears in the list of subprocesses on the Search Subprocess screen. Deleting a Subprocess Procedure To delete a subprocess: A subprocess can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Search Subprocess screen, select the checkbox next to the subprocess you want to delete. 2. Click Delete. Click OK to confirm the deletion. Changing a Subprocess Procedure To change a subprocess: 1. On the Search Subprocess screen, select the checkbox next to the subprocess you want to modify. 2. Click Change. The Change Subprocess screen appears with the Subprocess ID dimmed, indicating that the ID cannot be changed. 3. Make any changes to the description or abbreviation 4. Click Save. Mapping Subprocesses to Business Processes Procedure During the role creation process, the subprocesses available for you to select as role attributes are determined by the business process to which the subprocess is mapped. To map a subprocess to a business process: 1. On the Configuration tab, navigate to Role Attribute > Business Process. The Search Business Process screen appears. 2. Select the business process to which you would like to map a subprocess, and then select Process Mapping. The Associate Business Subprocess to Business Process screen appears. If the business process you select already has an associated subprocess, the subprocess appears in the search results area of the screen. 3. Click Add. A dropdown list appears in the Subprocess ID column. 4. Select a subprocess from the dropdown list.

240

September 2008

6 Enterprise Role Management Role Designer Only those subprocesses not already assigned to a business process appear in the dropdown list. 5. Click Save. A business process can include more than one subprocess. Repeat steps 3 through 5 to map another subprocess to the same business process. Alternatively, select another business process from the Business Process dropdown list at the top of the screen, and then repeat steps 3 through 5. Importing Subprocesses Procedure You can manually maintain the subprocesses within Enterprise Role Management, or you can mass import your data using the import feature. 1. On the Search Subprocess screen, click Import. The Import Subprocess screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not check this box. 4. Click Import The system message Subprocess saved successfully indicates that the data was imported successfully. Managing Functional Areas A functional area is a classification of processes for a department or business process. Within SAP, a functional area is used to organize certain activities within a department or business process. In Enterprise Role Management, a functional area is a role attribute used to categorize roles and define the approval and role maintenance processes. In addition, a functional area is used to filter the results of a role search, identifying only those roles associated with a specific functional area. Any field name denoted with an asterisk (*) is required. Example Within your business you might have the business process Procurement, which contains the functional areas of Purchasing, Administration, and Receiving. However, one or more of these functional areas might also fall under the business process Finance.

September 2008

241

6 Enterprise Role Management Role Designer Creating a Functional Area Procedure To create a functional area: 1. On the Configuration tab, navigate to Role Attribute > Functional Area. The Search Functional Area screen appears. 2. Click Create. The Create Functional Area screen appears. 3. In the Functional Area ID field, enter a name for the functional area. 4. In the Description field, enter a brief description for the functional area. 5. In the Abbreviation field, enter an abbreviation for the functional area. 6. Click Save. Changing a Functional Area Procedure To change a functional area: 1. On the Search Functional Area screen, select the checkbox next to the functional area you want to modify. 2. Click Change. The Change Functional Area screen appears with the Functional Area ID dimmed, indicating that the ID cannot be changed. 3. Make any changes to the description or abbreviation. 4. Click Save. Deleting a Functional Area Procedure To delete a functional area: A functional area can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Search Functional Area screen, select the checkbox next to the functional area you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion. Importing a Functional Area Procedure You can manually maintain the functional areas within Enterprise Role Management, or you can mass import your data using the import feature. 1. On the Search Subprocess screen, click Import. The Import Functional Area screen appears.

242

September 2008

6 Enterprise Role Management Role Designer

Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import The system message Functional area saved successfully indicates the data was imported successfully. Managing Custom Fields Custom fields allow you to add attributes to a role that are specific to your company or organization. For example, if you want to distinguish a role by region, add a custom attribute and assign a specific region when you create the role. Any field name denoted with an asterisk (*) is required. Creating a Custom Field Procedure To create a custom field: 1. On the Configuration tab, navigate to Role Attribute > Custom Fields. The Custom Fields screen appears. 2. Click Create. The Create Custom Fields screen appears. 3. In the Name field, enter a name for the custom field. This name is a unique identifier for the field. 4. In the Description field, enter a brief description for the custom field. 5. In the Field Label field, enter a name for the custom field. This is the field name that appears on your Role Maintenance and Search screens. 6. From the Field Type dropdown list, select a field type. The field type can be either a dropdown list or a text field. If the field type is a dropdown list, select a data source from which to import the data for the custom field. There are two data sources: SAP and RE. o o If you select SAP, you can select a Source System and enter both a Table Name and a Field Name. If you select RE, you can enter multiple field values users can select from in the Custom Fields Values section.

If the field type is a text field, select a data type from the dropdown list. Available data types are: o o Date Numeric

September 2008

243

6 Enterprise Role Management Role Designer o Varchar2

If the data type is either Numeric or Varchar2, you must define the number of characters allowed in the custom field. Enter the data in the Data Length field. 7. Click Save. The custom field appears in the Available Custom Fields list. Changing a Custom Field Procedure To change a custom field: 1. On the Custom Fields screen, select the checkbox next to the custom field you want to modify. 2. Click Change. The Change Custom Fields screen appears with the name of the custom field dimmed, indicating that the name cannot be changed. 3. Make any changes. 4. Click Save. Deleting a Custom Field Procedure To delete a custom field: A custom field can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Custom Fields screen, select the checkbox next to the custom field you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion. Importing a Custom Field Procedure You can manually maintain the custom fields within Enterprise Role Management, or you can mass import your data using the import feature. 1. On the Custom Field screen, click Import. The Import Custom Fields screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select the Overwrite checkbox. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import.

244

September 2008

6 Enterprise Role Management Role Designer The system message Custom field saved successfully indicates that the data was imported successfully. Managing Projects and Releases The project or release can be a project name, release name, or release number that you want to associate with a particular role. The Project or Release ID field allows you to track and filter roles by project or release based on your organizations requirements. Any field name denoted with an asterisk (*) is required. Creating a Project or Release ID Procedure To create a project or release ID: 1. On the Configuration tab, navigate to Role Attribute > Project/Release. The Search Project/Release screen appears. 2. Click Create. The Create Project/Release screen appears. 3. In the Project/Release ID field, enter a project name, release name, or release number. 4. In the Description field, enter a description of the project or release. 5. Click Save. The project or release appears in the Project/Release ID column of Search Results area on the Search Project/Release screen. Changing Project or Release Information Procedure To change project or release information: 1. On the Search Project/Release screen, select the checkbox next to the project or release you want to modify. 2. Click Change. The Change Project/Release screen appears with the Project/Release ID dimmed, indicating that the ID cannot be changed. 3. Make any changes in the Project/Release Description field. 4. Click Save. Deleting a Project or Release Procedure To delete a project or release: A project or release name or number can be deleted only if it is not associated with a role, approval criteria, or condition group. 1. On the Search Project/Release screen, select the checkbox next to the project or release you want to delete. 2. Click Delete.

September 2008

245

6 Enterprise Role Management Role Status 3. Click OK to confirm your deletion. Importing a Project or Release You can manually maintain the project or releases within Enterprise Role Management, or you can mass import your data using the import feature. Procedure 1. On the Project/Release screen, click Import. The Import - Project/Release screen appears. Click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. If you want to overwrite all existing records with the new data in the import file, select Overwrite. New records in the file are added. If you do not want to overwrite existing records (if these records are in the import file), do not select this box. 4. Click Import. The system message Project/Release saved successfully indicates the data was imported successfully.

Role Status
During the role creation process, Role Status is a required field. You can set the status of the role to Development or Production. Development indicates that the role is not ready for production usage and is usually not transported to a production environment. Production indicates that the role is ready for production usage and usually is transported to a production environment. The role status is used by the system for integration with Compliant User Provisioning role synchronization, with Enterprise Role Management set as the role source. If the role status is set to Production, Enterprise Role Management synchronizes the role to Compliant User Provisioning for user provisioning. Therefore, role status is predefined and delivered with Enterprise Role Management. You can change the role status description only. Procedure To change the role status description: 1. From the Configuration tab, navigate to Role Status. The Role Status screen appears. 2. From the Description column, enter description text for the role status. 3. Click Update. Example You create 200 roles for a development system and 100 roles for a production system. When creating these roles on the Create Role screen, you set the role status to Development or Production for identification purposes. You can then easily search for the role status Development and retrieve the 200 roles.

246

September 2008

6 Enterprise Role Management Managing Condition Groups These roles are not automatically transferred to their respective systems but rather imported by using the Mass Role Import tool.

Managing Condition Groups

A condition group is defined from a set of role attributes (such as a business process, subprocess, functional area, role type, or role name) and is based on role values and conditions. After you create a condition group, the system applies it to a role creation process to override the default role creation process when the criteria from the condition group are met. You can apply multiple condition groups in one role creation process, but you cannot associate multiple processes to one condition group. Any field name denoted with an asterisk (*) is required.

Creating a Condition Group Procedure To create a condition group: 1. From the Configuration tab, navigate to Condition Groups. The Condition Groups screen appears. 2. Click Create. The Create Condition Group screen appears. 3. In the Condition Group ID field, enter a condition group ID. 4. In the Description field, enter a brief description for the condition group. 5. From the Status dropdown list, select Enable or Disable. If you select Enable, the condition group is available for association during the role methodology creation process. If you select Disable, it is not available. 6. To add role attributes to the condition group, click Add. Dropdown lists appear under Role Attributes and Condition. 7. In the Role Attributes column, select the attribute that you want to assign to the condition group. After you select a role attribute, a dropdown list or text field appears in the Value column. The values in the dropdown list are specific to the selected role attribute. 8. In the Value column, assign a value for the corresponding attribute. 9. In the Condition column, select a condition for the role attribute. 10. To add more role attributes to the condition group, repeat steps 6 through 9. 11. Click Save. Changing a Condition Group Procedure To change a condition group:

September 2008

247

6 Enterprise Role Management Managing Condition Groups 1. On the Condition Groups screen, select the checkbox next to the condition group you want to change. 2. Click Change. The condition group appears with the Condition Group ID dimmed, indicating that you can only change the condition groups attributes, not its name. 3. Make any changes to the condition group. 4. Click Save. Deleting a Condition Group Procedure To delete a condition group: 1. On the Condition Groups screen, select the checkbox next to the condition group you want to change. 2. Click Delete. 3. Click OK to confirm the deletion. A condition group can be deleted only if it is not associated with a methodology process. Role Creation Methodology Setup A role creation process consists of predefined methodology actions and the methodology steps associated with those actions. The steps then create a methodology process, which guides you through the process of defining, generating, and testing a role during role creation. Enterprise Role Management is delivered with the predefined role methodology process Virsa Default Process. You can also configure your own role creation process according to your organizations requirements. Methodology Steps Methodology steps are the steps to create a role during the role creation process. Based on these steps, you can tell which phase of the role creation process a role is in. Enterprise Role Management allows you to create methodology steps and associate them with predefined actions provided within Enterprise Role Management. After you associate the steps with the predefined actions, you can create a role methodology process. Any field name denoted with an asterisk (*) is required. Creating a Methodology Step Procedure To create a methodology step: 1. On the Configuration tab, navigate to Methodology > Step. The Steps screen displays the steps configured for your application. 2. Click Create. The Create Methodology Step screen appears. 3. In the Step ID field, enter a name for the step.

248

September 2008

6 Enterprise Role Management Managing Condition Groups 4. In the Description field, enter a brief description for the step. 5. From the Status dropdown list, select Enable or Disable. If you select Enable, the step is available for inclusion in a methodology process. If you select Disable, it is not available. 6. From the Associate Action dropdown list, select an action with which to associate the step. The actions you associate with your step are predefined in Enterprise Role Management. 7. Click Save. Changing a Methodology Step Procedure To change a methodology step: 1. On the Steps screen, select the checkbox next to the methodology step you want to change, 2. Click Change. The methodology step appears with the Step ID dimmed, indicating that you can only change the attributes of the step, not its name. 3. Make any changes to the methodology step. 4. Click Save. Deleting a Methodology Step Procedure To delete a methodology step: If a methodology step is already associated with a methodology process, neither the step nor the process can be deleted. 1. On the Steps screen, select the checkbox next to the methodology step you want to delete. 2. Click Delete. 3. Click OK to confirm the deletion. Methodology Actions Enterprise Role Management is delivered with predefined actions. Although you cannot create new actions, you can create steps to associate with the predefined actions and then use those steps to create a methodology process. Activities Clicking each action name on the Predefined Actions screen allows you to see which button triggers the associated action. To view Enterprise Role Management predefined actions, select Methodology Actions on the Configuration tab. Enterprise Role Management Predefined Actions

September 2008

249

6 Enterprise Role Management Managing Condition Groups

Action Approval of a Role Generation of a Role Initiating Risk Analysis Saving Role Definition

Description This action is associated with sending the role for approval through approval workflow. This action is triggered when you want to generate the role in the backend ERP system. This action is triggered when you want to perform risk analysis on a role. The risk analysis is based on the default analysis settings specified during configuration. This action is associated with saving the definition of a role. This excludes saving authorization data and risk analysis results.

Saving Test Results This action is triggered when you want to maintain test results after testing a role. Saving Role Authorization Data Saving Role Derivation This action is triggered when you want to maintain the authorization data for the role. This action is triggered when you want to maintain the role derivation data.

Methodology Process A methodology process consists of multiple steps and defines the order and flow of the role creation process through all of the associated steps. Any field name denoted with an asterisk (*) is required. Creating a Methodology Process Procedure To create a methodology process: 1. On the Configuration tab, navigate to Methodology > Process. The Process screen displays all of the processes configured for your application. 2. Click Create. The Create Process screen appears. 3. In the Process ID field, enter a name for the methodology. 4. In the Description field, enter a brief description for the methodology. 5. From the Status dropdown list, select Enable or Disable. If you select Enable, the methodology is available for a role by matching the attributes of the role in question with the condition group(s) associated with this process. If you select Disable, it is not available. 6. On the Detailed Description tab, enter a detailed description of the methodology. 7. On the Steps tab, click Add. 8. From the dropdown list, select a step for this process. You can use the up and down arrows to change the position of a step in the process.

250

September 2008

6 Enterprise Role Management Managing the Workflow 9. Repeat steps 7 through 8 to add more steps to the process. 10. On the Apply To tab, click Add. 11. From the dropdown list, select a condition group to apply to the process. 12. Repeat steps 10 through 11 to apply the process to more than one condition group. For more information, see the sections Managing Condition Groups and Changing a Condition Group. 13. Click Save. If more than one methodology process is configured in your system, select one process as the default. To set a default process, click the light bulb icon associated with the process you want to set as the default. All other processes are triggered based on condition group. Changing a Methodology Process Procedure To change a methodology process, do the following: 1. Select the checkbox next to the methodology process you want to change. 2. Click Change. The methodology process appears with the Process ID dimmed, indicating that you can only change the process attributes, not its name. 3. Make any changes. 4. Click Save. 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 is being used for role creation, or if it is the only process configured in Enterprise Role Management. 1. Select the checkbox next to the methodology process you want to delete, 2. Click Delete. 3. Click OK to confirm the deletion.

Managing the Workflow

Enterprise Role Management integrates with Compliant User Provisioning for role approval workflow. As part of the integration, a role approver is defined during the role creation process to be used by the approval workflow. During the role creation process, you can manually define approvers and alternate approvers for each role, or you can allow Enterprise Role Management to automatically assign approvers and alternate approvers to that role based on the approval criteria you create and the role attributes the user selects. To create approval criteria, you assign approvers and alternate approvers for a set of role attributes or conditions.

September 2008

251

6 Enterprise Role Management Managing the Workflow

Any field name denoted with an asterisk (*) is required. Prerequisites You must have Compliant User Provisioning installed and configured in order to use the workflow function. For more information, see the section Compliant User Provisioning.

Creating Approval Criteria for a Workflow Procedure To create approval criteria for approval workflow: 1. On the Configuration tab, navigate to Workflow > Approval Criteria. The Search Approval Criteria screen appears. 2. Click Create. The Create Approval Criteria screen appears. 3. In the Group Name field, enter the name of the group for which you want to create approval criteria. 4. Click Add on the Attribute screen. The Attribute screen appears. 5. From the dropdown list, select the attribute(s) required to specify your approval. 6. Click Assign Approvers. The Approval Criteria Values screen appears. 7. Click Assign Approvers. 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 9. Under the Approver table, click Add. 10. In the Approver column, click Search. The Approver Search window appears.

icon.

Alternatively, you can enter First Name and/or Last Name of approver to specifically search for an approver. 11. Click Search. A list of potential approvers appears. 12. Select the radio button next to the user ID of the user you want to assign as an approver. 13. Click Select.

252

September 2008

6 Enterprise Role Management Managing the Workflow The Approver Search window closes, and the Approver field on the Change Approval Criteria screen is populated. 14. Repeat steps 10 through 13 to select an alternate approver. 15. Click Add. 16. Repeat steps 10 through 14 to add more approvers and alternate approvers.

To remove an approver and alternate approver line record, click the 17. Click Save.

icon.

The Approval Criteria Values screen displays the Approver and Alternate Approver for the selected condition attributes. Changing Approval Criteria for a Workflow Procedure To change approval criteria: 1. On the Search Approval Criteria screen, select the checkbox next to the group for which you want to change approval criteria. 2. Click Change. The Approval Criteria Values screen for the group you selected appears. 3. You can add new approval criteria or change existing approval criteria to the group. To add new approval criteria, click Assign Approvers and then follow steps 7 and 8 in the section Creating Approval Criteria for a Workflow. To change existing approval criteria, select the checkbox next to the Approval Expression you want to change. Then click Change to make the changes. 4. Click Save. Deleting Approval Criteria for a Workflow Procedure To delete all approval criteria for a group: 1. On the Search Approval Criteria screen, select the checkbox next to the group whose approval criteria you want to delete. 2. Click Delete. 3. Click OK to confirm the deletion. 4. To delete specific approval criteria for a group: 5. Select the checkbox next to the group whose approval criteria you want to delete. 6. Click Change. 7. Select the checkbox next to the Approval Expression you want to delete. 8. Click Delete. 9. Click OK to confirm the deletion.

September 2008

253

6 Enterprise Role Management Managing Naming Conventions

Managing Naming Conventions

You create naming conventions to enforce role and profile naming standards during the role creation process. Naming conventions are specific to a system landscape and role type. The landscape and role type determine the attributes available to assign to a naming convention. Any field name denoted with an asterisk (*) is required. Example You can have different naming conventions for the Single role type in the development system landscape and the test system landscape. You can have different naming conventions for the Composite role type in the development system landscape and the test system landscape, and so on.

Creating a Naming Convention You create a naming convention by entering free text or text dynamically linked to your role attributes. The role attributes available for naming convention creation for all role types are Business Process, Subprocess, and Project/Release. For SAP derived roles, additional role attributes are available: Master Role Name, Derived Org Level, From Value, To Value. Procedure To create a naming convention: 1. On the Configuration tab, navigate to Naming Convention. The Configure Naming Conventions screen appears. 2. Click Create. The Create Naming Convention screen appears. 3. In the Name field, enter a name for the new naming convention. 4. From the System Landscape dropdown list, select a system landscape. 5. From the Role Type dropdown list, select a role type. The role type you select determines the attributes available to you in the next step. Available role types are: Single Composite Derived Profile 6. From the Enforced field dropdown list, select Disable or Enabled. Enabled - the naming convention is enforced and cannot be overridden by the user. Disable - the naming convention is suggested, but can be overridden by the user. The Expression field contains the format of the naming convention. It is auto-populated each time you assign an attribute and/or text character, but you decide the order and number of characters. The maximum number of characters allowed for a role name is 30 (with the exception of the profile name role type Profile which only allows 12 characters). Each time you add characters, the position of the assigned characters and number of characters still available is displayed on the right side of the Create Naming Convention screen.

254

September 2008

6 Enterprise Role Management Managing Organizational Value Mapping Two types of character appear in the Expression field: Variable characters represent the attribute value you select from the Attribute dropdown list and are represented in the Expression field as a dollar sign ($). When you create a user role, the Variable character is either auto-populated or changed, depending on your business needs. Free Text characters allow you to enter whatever text best fulfills your business needs, but it is typically based on valid characters for SAP role names. Free text is represented in the Expression field by either a dollar sign ($) or the actual text you enter in the Text field. 7. Populate the Expression field: a. Select an attribute from the Attribute dropdown list. b. Take one of the following actions: Enter the number of characters needed to represent the selected attribute in the No. of Chars field, and click the Add icon. Enter text in the Text field, and click Add. The characters that represent the variable or free text you enter appear in the Expression field, and the positions the characters hold in the expression appear in the screen on the right. In addition, you can see the number of characters that remain available for the naming convention. 8. Click Save. Changing a Naming Convention Procedure To change a naming convention: 1. Select the checkbox to the left of the naming convention you want to modify. 2. Click Change. The Edit Naming Convention screen appears. 3. Make the changes on the screen. 4. Click Save. Deleting a Naming Convention Procedure To delete a naming convention: 1. Select the checkbox to the left of the naming convention you want to delete. 2. Click Delete. 3. Click OK to confirm your deletion.

Managing Organizational Value Mapping

If you want to restrict user access by organizational area, you can use the organizational value mapping feature to map roles to different organizational levels. To define all associated organizational values, you can create an organizational value map for each organizational area (such as North America, Europe, and Asia Pacific).

September 2008

255

6 Enterprise Role Management Managing Organizational Value Mapping Prior to creating an organizational value map, you must run a background job to import existing organizational fields and values from your SAP ERP system. After the initial import, you can create a background job to schedule periodic synchronization to keep the data updated. For more information about background jobs, see the section Managing Background Jobs. You always create an organizational value map with a primary organizational level and value, because Enterprise Role Management uses that to store and search for the organizational value. You can create multiple maps for the same primary organizational level and value combination. After the primary organizational level and value are set, you can define the values for all child organizational levels within the map to complete the organizational value map creation. After you create the organizational value map, it can be used by all users as a basis to derive any master role. You must run the initial background jobs for Org Value Sync, Transaction/Object/Field Sync, and Activity Val Sync prior to configuring organizational value maps. These background jobs are a prerequisite for the organizational value mapping feature. Any field name denoted with an asterisk (*) is required. Example Create an organizational value map for North America with the primary organizational level as Company Code with value 1000 through 2000. Within Company Code 1000 through 2000, the child organizational levels, such as a plant or division, are set with the value of 100 through 200 (the location of the plant or division). When you derive a role using this North America map, the derived role assumes the primary organizational level values and all child organizational levels values 100 through 200.

Creating an Organizational Value Mapping Procedure To create an organizational value map: 1. On the Configuration tab, navigate to Org. Value Mapping. The Search Org. Value Mapping screen appears. 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.

256

September 2008

6 Enterprise Role Management Managing Organizational Value Mapping 9. Click Search. A list of values and their descriptions appears. 10. Select the button next to the value you want to use and click Select. The Value Search window closes, and the Org. Value To field is populated. 11. In the Description field, enter a description of the organizational value map. 12. Select the organizational level on which to base this new organizational value map by clicking Add on the Mapped Org. Levels screen. 13. In the Field column, select an organizational level from the dropdown list. 14. Select From and To values by clicking Search and then repeating steps 8 and 9. 15. Repeat steps 12 and 13 to add additional organizational level and values to the org value map. 16. Click Save. 17. To view all existing roles affected by this mapping, click Master Role Impact or Derived Role Impact. Changing an Organizational Value Mapping Procedure To change an organizational value mapping: 1. On the Search Org. Value Mapping screen, select the checkbox next to the Mapping Name you want to change. 2. Click Change. The Change Org. Value Mapping screen appears. 3. Make the desired changes. 4. Click Save. 5. To view and update the roles affected by this change, click Impacted Master Roles or Impacted Derived Roles. Deleting an Organizational Value Mapping Procedure To delete an organizational value mapping: 1. On the Search Org. Value Mapping screen, select the box next to the Mapping Name you want to delete. 2. Click Delete. 3. Click OK to confirm the deletion. Importing an Organizational Value Mapping Procedure You can manually maintain the organizational value map within Enterprise Role Management, or you can mass import your data using the import feature. To import organizational value mapping(s): 1. On the Search Org. Value Mapping screen, click Import.

September 2008

257

6 Enterprise Role Management System Logs A standard Windows Choose File dialog box appears. You can click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Locate the file you want to import. 3. Click Open to import the file. If the information was imported successfully, a success message appears. Exporting an Organizational Value Mapping After you create organizational value maps, you can export them to a directory on your computer in spreadsheet format (.xls). This feature uses the spreadsheet for reporting purposes, as well as for making changes to the information in the spreadsheet and then importing the file back into Enterprise Role Management. Enterprise Role Management also provides you with a template for importing and exporting organizational value maps. After you download the template into a directory, you can add your organizational value maps and then import those maps into Enterprise Role Management. You can use your own spreadsheet to import organizational value maps as long as you use the same column and header formatting as used in the Enterprise Role Management template. SAP recommends that you use the template provided with Enterprise Role Management for importing organizational value maps. Do not modify the column format or header names because those names affect how the template interacts with Enterprise Role Management. Procedure To export organizational value mapping(s): 1. On the Configuration tab, navigate to Org. Value Mapping. The Search Org. Value Mapping screen appears. 2. Click Export. 3. Click Open to view the spreadsheet or Save to save the spreadsheet to a directory on your computer. 4. After you make any changes to the information in the spreadsheet, use the Import function to import the changes back into Enterprise Role Management. For more information about importing organizational value maps, see the section Importing Organizational Value Map.

System Logs
System logs provide a history of role management actions and are used by administrators and developers for troubleshooting purposes. Activities You can view system logs by navigating to the System Logs screen and selecting Get Logs.

258

September 2008

6 Enterprise Role Management Transaction Import

Transaction Import
The transaction import feature of Enterprise Role Management imports non-SAP transactions (actions) into Enterprise Role Management to be used as authorization data during the role creation process. If you choose not to import the non-SAP actions, you must manually enter authorization data when documenting non-SAP roles. Procedure 1. On the Configuration tab, navigate to Transaction Import. The Transaction Import: Non-SAP ABAP screen appears. You can click the red arrow next to the Browse button to download a template that contains the format for the import file. 2. Click Browse to locate the file you want to import. 3. From the System Type field, select the appropriate system from the dropdown list. 4. Click Import. If the information was imported successfully, a Transactions imported successfully message appears. Importing Mass Roles For SAP systems, the mass role import feature of Enterprise Role Management synchronizes the SAP back-end systems with Enterprise Role Management by importing roles that already exist in the SAP ERP system. For non-SAP systems, the mass role import feature of Enterprise Role Management imports your roles and transactions/actions data from a spreadsheet based on the provided template format. Prerequisites Before you can use the mass role import functionality of Enterprise Role Management, you must: Ensure that connectors, a system landscape, and role attributes are configured within Enterprise Role Management. Ensure that role attribute master data on your import file matches the data in Enterprise Role Management. For SAP systems only, you must: Ensure that all background jobs, including Transaction/Object/Field Value, Org Value, and Activity Value synchronizations, are complete. Download a Bulk Download text file by executing the /VIRSA/RE_DNLDROLES transaction on that system. Run the /VIRSA/RE_DNLDROLES transaction as a background process. When executing the /VIRSA/RE_DNLDROLES transaction, save the Bulk Download file as a text file with .txt file extension to either your local computer or to the server on which Enterprise Role Management is installed. Specify a file name that is easily remembered. You can download single, composite, and derived roles in the same download file.

September 2008

259

6 Enterprise Role Management Transaction Import Create a role and attribute information file for the downloaded roles in Enterprise Role Management. This file contains required role attribute information specific to Enterprise Role Management. This information does not exist in the back-end SAP system. The information file must be in tab-delimited text format and contain the following role attributes with the corresponding role names: o o o Business Process Sub-Process Project/Release.

Enterprise Role Management provides a template for creating the information file. You can access the template by using the Mass Role Import screen on the Configuration tab. In the System Type field, select SAP from the dropdown menu. The Enterprise Role Management Information File field appears. Click the red download arrow to download the template. Here is an example of the information in tab-delimited text format: Z_AP_PAYABLE Z_AP_CLERK FINANCE FINANCE ACCOUNTS_PAYABLE ACCOUNTS_RECEIVABLE ALPHA_RELEASE BETA_RELEASE

You must use attribute IDs, rather than their descriptions, when populating the template. You can also download template files from Help on the main Enterprise Role Management application screen. For more information, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 5.3. If you import a derived role, its master role must exist in the same import file with the derived roles or it must already exist in Enterprise Role Management. You must also create a Primary Org Level file. Enterprise Role Management provides a template for this purpose. Access the template by clicking the red download arrow next to the Browse icon from the Mass Role Import screen.

Importing Multiple Roles Procedure To import multiple roles: Any field name denoted with an asterisk (*) is required. 1. On the Configuration tab, navigate to Mass Role Import. The Mass Role Import screen appears. 2. From the Source Connectors dropdown list, select the connector to which you want to import the roles. 3. From the System Type dropdown list, select the system type to which you want to import the roles. 4. From the System Landscape dropdown list, select the system landscape to which you want to import the roles. 5. From the Import Source dropdown list, select the source from which to import the roles.

260

September 2008

6 Enterprise Role Management Transaction Import The selection you make here depends on where you saved the import files. For SAP systems, select the location file source where you saved the Bulk Download text file you downloaded using the /VIRSA/RE_DNLDROLES transaction. If you saved the file to your local system, select Browser Upload. If you saved the file to the server, select Server Files. For more information about the /VIRSA/RE_DNLDROLES transaction, see the section Mass Role Import. 6. In the Bulk Download File field, either enter the server file path or click Browse to locate the files on your hard drive. For non-SAP systems, Enterprise Role Management provides a template for this purpose. Access the template by clicking the red download arrow next to the Browse icon. For SAP systems, this is the file you downloaded when you ran the /VIRSA/RE_DNLDROLES transaction. For more information about the Bulk Download file, see the section Mass Role Import. 7. (SAP systems only.) In the Enterprise Role Management Information File field, either enter the server file path or click Browse to locate the files on your hard drive. For more information about the Enterprise Role Management Information file, see the section Mass Role Import. 8. In the Primary Org Level File field, either enter the server file path or click Browse to locate the files on your hard drive. For more information about the Primary Org Level file, see the section Mass Role Import. 9. From the Overwrite Role if Exists dropdown list, select Yes to overwrite existing roles or No to prevent the roles from being overwritten. 10. Click Continue. 11. Select Foreground or Background. If you select Foreground, the Import Results screen displays the role name and import status. If you select Background, the system automatically schedules a background job and displays the message Background job for mass role import is successfully scheduled; job ID is ###. For more information, see the section Viewing the History of a Background Job. Role Usage Synchronization This feature allows you to synchronize role usage information by user from your SAP ERP system or to upload this information using the upload file template. For detailed information on format usage, see the section Role Usage Import Template. Role usage information is stored in Enterprise Role Management for integration with Compliant User Provisioning to provide 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 to synchronize the role usage.

September 2008

261

6 Enterprise Role Management Transaction Import

The systems configured in Enterprise Role Management are SAP systems. For nonSAP systems, use the manual upload feature described below. 3. Enter the Synchronization Start Date. This is the date when you want the synchronization to begin. If you leave this field blank, it defaults to the date of the last synchronization job. For the initial run, it uses todays date. Enterprise Role Management remembers the initial start date that you enter in this field for the first synchronization. When you synchronize the role usage for the second time, it compares data from the initial synchronization date to the data of the new start date. Enterprise Role Management updates only those records that are different. 4. Click Schedule. The system displays the message Role usage synchronization job scheduled successfully; 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 where the role usage information is being uploaded. The Upload Role Usage feature is primarily used for uploading the role usage synchronization data from a non-SAP system to Enterprise Role Management. 3. In the File Name field, click Browse to locate the file you want to import. You can click the red arrow next to the Browse button to download the Role Usage Import Template that contains the format for the import file. 4. Click Upload. Role Usage Import Template Field Name System (Name) User (ID) First Name Last Name Role (Name) Execution Count Last Executed Expired Definition Alphanumeric (20) Alphanumeric (40) Alphanumeric (50) Alphanumeric (50) Alphanumeric (100) Numeric Date (MM/DD/YYYY) Numeric (1= expired, otherwise leave blank. Blank= not expired.) Example QF6 Tchard1 Tom Chard Z_AP_Payable Number of times that the role was used. 08/27/2008 Any value other than 1 indicates that the role is not expired.

Enterprise Role Management compiles role usage data from SAP systems into the format used by the role usage import template. You use the same format for compiling role usage data from a non-SAP system and later upload to Enterprise Role Management.

262

September 2008

6 Enterprise Role Management Importing and Exporting Configuration Settings

Importing and Exporting Configuration Settings

This feature exports configuration settings from one Enterprise Role Management system and imports them into another. You must export the settings first and then use the generated file as the import source file for the other system. For example, after you configure the development system, you can export the configuration settings and import them into the production system, so you do not have to manually reconfigure the settings. Exporting Configuration Settings Procedure 1. On the Configuration tab of the configured system, navigate to Configuration Settings. The Import/Export Configuration screen appears. 2. In the Export Settings section, select the checkbox next to the attribute grouping to select a group of attributes, or select the checkbox in the top left corner of the section to select all attributes. 3. Click Export. 4. The system prompts you to Open or Save the file. Click Open to view the export file prior to saving it. Click Save to save the export file by specifying file name and file location. Remember where you save the file, so you can use it as an import file later. SAP does not recommend that you manually modify this file. Exporting System Data Procedure To export system data: 1. On the Configuration tab, navigate to Initial System Data. The Initialize DB screen appears 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, nonSAP, 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 the system before roles can be imported. Workflow Configuration This data includes all information from Initiator, Custom Approver 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 associated values and flag settings. 3. Click Export.

September 2008

263

6 Enterprise Role Management Miscellaneous

Role export does not export role attributes. Role attributes must exist in the system before roles can be imported. The export feature produces several zip files, which you can upload to another Access Control Compliant User Provisioning system for the initial load of the configuration data of that system. Importing Configuration Settings Procedure 1. On the Configuration tab of the system you have not yet configured, navigate to Configuration Settings. The Import/Export Configuration screen appears. 2. In the Import Settings section, click Browse to locate the export file you exported. 3. Click Import.

Miscellaneous
This section describes the configuration options you can configure from the Miscellaneous tab. On this tab, you can:

Option Allow Role Generation With Violations

Description Configure whether the role can be generated despite violations. If you set this option to No, you cannot generate the role unless all role violations are resolved. Configure whether the role can be generated on multiple systems. Configure whether the logged-in user credentials are used during role generation. If you set this option to No, the system uses the target back-end system user ID and password. Specify a default risk analysis level. If you set this option to Object, the risk analysis defaults to the Object or Permission level. If you set this option to Transaction, the risk analysis defaults to the Transaction Code or Action level. You can override the default setting at the time you perform risk analysis. Edit organizational level values for derived roles. If you set this option to No, you cannot edit organizational level values for derived roles during the authorization data step in the role creation process.

Allow Role Generation on Multiple Systems Use Logged-In User Credentials For Role Generation

Analysis Type

Allow Editing Org. Level Values For Derived Roles

264

September 2008

6 Enterprise Role Management Miscellaneous Option Allow Adding Function To Authorization Description If you set this option to Yes, it adds authorization data by retrieving a function from Risk Analysis and Remediation. Add objects to a role directly during the authorization data step of the role creation process. If you set this option to Yes, the system allows you to add objects directly to the role authorization data. If you set this option to No, you can add objects to a role only by adding functions and/or transactions. Specify whether you must enter a ticket number after making any additions or changes to the authorization data in a role. If you set this option to Yes, after you save any additions or changes made to the authorization data in a role, the system prompts you for a ticket number. If you set this option to No, the system does not prompt you for a ticket number. Configure whether the role can be opened and edited in PFCG. If you set this option to No, you cannot create or edit the role through PFCG integration. Set a default folder for all the files uploaded from Enterprise Role Management. Allows you to configure the log level. Set the default language. Limit the number of background jobs that can be run concurrently. Attach files to a role and to set the attachment file size (in KBs).

Add Objects To a Role

Ticket Number After Authorization Data Changes

Allow Editing Role Authorizations in PFCG

Upload Directory Log Level Debuginfowarnerror Default Language No of Concurrent Background Jobs Ability To Attach Files To Role Definition

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 the Welcome screen: User ID, Password, and Language. Although User ID and Password are required fields, Language is not. Therefore, you must set a default language in the Miscellaneous Configuration screen by selecting the appropriate language from the Language dropdown list and then clicking Save. You must log off and then log back on again in order for this change to take effect in the user interface.

September 2008

265

6 Enterprise Role Management Miscellaneous In addition, if an end user selects a language from the Language dropdown list on the Welcome screen that differs from the default language specified in Miscellaneous Configuration, the default language is overridden and the user interface appears in the end user-selected language. When the end user logs in using a language from the Language dropdown list on the Welcome screen that differs from the default language specified in Miscellaneous Configuration, they can use the Create option to create a new object. By default, Enterprise Role Management shows the default language description and allows the end user to create and modify the object with the corresponding language text.

266

September 2008

7 Access Control and Identity Manager Integration Miscellaneous

7 Access Control and Identity Manager Integration

Large corporations deal with personnel changes on a daily basis. There can be hundreds of new hires, terminations, and role changes on any given day. To handle this volume of activity, the IT organization uses an Identity Management (IdM) system to provision users in applications 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 governance and control policies. Some IdM systems lack an approval workflow mechanism and reporting capability for tracking and auditing purposes. Access Control can integrate with IdM systems. For instance, you can define policies and Segregation of Duties (SoD) rules for granting access to resources through Access Control. The integration between GRC Access Control and the IdM system ensures that user provisioning does not introduce unknown risk violations. Integration involves exposing Web services in both Access Control and the IdM system. You can call these Web services from either system to request user provisioning. This extends the IdM system by enabling Compliant User Provisioning. The Web service solution provides proactive enforcement of access policies, especially those that prevent SoD and risk violations. These Web services can alert you to potential SoD conflicts when assigning roles to users. With these Web services, the integration of Access Control and IdM also provides real-time access 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 this integration, 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 Web service and search operations for the Audit Trail Web service, see the section Integration with NetWeaver Identity Manager.

September 2008

267

7 Access Control and Identity Manager Integration Calling Web Services

Access Control and IdM system integration supports only Service Provisioning Markup Language (SPML) 1.0. SPML is the open standard protocol for integration of service provisioning requests. SPML is an OASIS standard. The Web services called from Access Control to an IdM system are SPML 1.0 compliant. However, the Access Control Web services exposed to an IdM system or other application are not SPML 1.0 compliant. The diagram below illustrates this point.

Other applications or other supported systems refer to any systems that are SPML 1.0 compliant. Non-ERP systems also fall into the category of other supported systems. There are several business reasons for integrating Access Control in order to provision to a heterogeneous environment. Each corporation has its own specific provisioning needs, but there are three general integration approaches for consideration. These approaches are: 1. Using the IdM system as the leading provisioning system where requests are submitted to Access Control for SoD compliance and provisioning to one or more ERP systems. For more information, see the section IdM System as a Leading Provisioning System. 2. Using Access Control as the leading provisioning system where requests are submitted to the IdM system for provisioning to one or more non-ERP systems. For more information, see the section GRC Access Control provisioning to non-ERP Systems. 3. Using Access Control as the leading provisioning system where requests are submitted to other supported systems via SPLM SOAP provisioning requests. For more information, see the section GRC Access Control provisioning to Other Supported Systems.

Calling Web Services

There are several business reasons for calling the Web services provided by GRC Access Control. Here are three examples:

268

September 2008

7 Access Control and Identity Manager Integration Calling Web Services IdM System as a Leading Provisioning System From the IdM system, you want to request access to an ERP system using the Submit Request Web service. This request is submitted to Access Control. Once the request is approved and provisioned, a status is sent back to the IdM system. You can also call the Submit Request Web service from Access Control to request a non-ERP system on the IdM system. Again, once the status is completed, a notification is sent to Access Control. To request the system and role, you must know what systems and roles are available. From the IdM system, you can perform specific actions, such as calling the Application Selection and Role Selection Web services, before calling the Request Submission Web service in Access Control.

September 2008

269

7 Access Control and Identity Manager Integration Calling Web Services

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, then the request follows two parallel paths. The non-ERP system portion of the request is submitted to the IdM system. The ERP system portion is processed by Access Control.

270

September 2008

7 Access Control and Identity Manager Integration Calling Web Services The following diagram illustrates this interaction.

For configuration steps applicable to this example, see the section Integrating with an Identity Management Solution.

September 2008

271

7 Access Control and Identity Manager Integration Calling Web Services

Access Control provisioning to Other Supported Systems via SMPL SOAP Access Control can provision to other target systems that are SPML SOAP compliant. Like the previous example, when an event occurs in SAP Human Resources (SAP HR), it triggers a request in Access Control. A request can also be triggered by a self-service creation process within Access Control. When the provisioning request is approved in Access Control, an SPML SOAP call is submitted to the target system for provisioning. The following diagram illustrates this interaction.

For configuration steps applicable to this example, see the section Provisioning to Other Target Systems with SPML SOAP Compliant Call.

272

September 2008

7 Access Control and Identity Manager Integration Access Control and IdM System Integration Architecture

Access Control and IdM System Integration Architecture

The integration of Access Control and the IdM system is coupled by the ability to call Web services that are unidirectional and bidirectional. The following diagram illustrates the logic when 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 in that you can call them either from IdM or from Access Control.

September 2008

273

7 Access Control and Identity Manager Integration Access Control and IdM System Integration Architecture

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 enables you to search for roles before submitting a request to Access Control. To refine your search, you can use a filtration function. o Role Details (SAPGRC_AC_IDM_ROLEDETAILS) - This Web service provides detailed information about the selected role.

Submit Request (to Access Control) (SAPGRC_AC_IDM_SUBMITREQUEST) - You use this Web service from the IdM system for compliant provisioning to Access Control. Risk Analysis (SAPGRC_AC_IDM_RISKANALYSIS) - This Web service enables you to perform Segregation of Duties (SoD) analysis. It returns any possible risk violations. Audit Trail (includes the Provisioning Log Web service) (SAPGRC_AC_IDM_AUDITTRAIL) - This Web service returns a comprehensive audit history. It allows the IdM system to retrieve an audit log from Access Control (for ERP provisioning) as well as provides an audit history of user provisioning to Access Control. Request Status (SAPGRC_AC_IDM_REQUESTSTATUS) - This Web service returns the status and detailed request information for the selected request. Web Services calls from IdM Submit Request to IdM (SAPGRC_AC_IDM_SUBMITREQUEST_TO_IDM) - This Web service is called by GRC to submit a request to IdM. The Web services are called: When a user is created or changed in an SAP HR system, a new request is submitted to IdM to create or remove users and their privileges. Example: An event occurs in SAP HR, such as the hiring of a new employee. This event initiates a request to enable the user have some basic privileges to perform their job function. The request might consist of both ERP and Non-ERP applications, thereby triggering a request to the IdM system for non-ERP system while GRC processes the request for the ERP systems. The audit logs and request status can be consolidated by calling the Audit Logs and Request Status web services. When a user requests non-ERP system from the GRC End User Form, GRC calls this service to submit a request to the IdM.

274

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services Audit Trail from IDM (SAPGRC_AC_IDM_AUDITTRAIL_FROM_IDM) This Web service returns a comprehensive detailed list of audit history. It enables GRC to retrieve the audit logs from IdM (for non-ERP provisioning).

Technical Definitions for Access Control IdM Web Services

When calling a Web service, you must provide technical definitions as part of your request. These definitions help in filtering the returned results and subsequent user provisioning. Select Applications (SAPGRC_AC_IDM_SELECTAPPLICATION) You can call this Web service from the IdM system to Access Control. It returns a list of resources which are available for user provisioning.

For bidirectional integration, the list of resources configured in the IdM system is maintained in Access Control. Before submitting a request, make sure that the non-ERP resources are configured in Access Control.

Function/Method getSystems (test.types.p2.GetSystems parameters) Input Parameters The following table shows the input parameters that are available for your request:

Field System Type

Description The resource type indicates whether the server is an SAP system or a non-SAP system. The resources are categorized by Production, Non-Production, QA, Test, and so on.

Possible Value(s)/Example The default is All. Example: SAP, Oracle, etc. The default is All. Example: Development, Production, Non-Production, QA, Test, etc. The default is EN.

Application Type

Locale

The language in which the information is to be returned.

September 2008

275

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Output Parameters This table shows the output parameters which are part of the returned message response. Field System ID Description System Category Example Q5F Q5F Dev System Development

276

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Search Role (SAPGRC_AC_IDM_SEARCHROLES) You can call this Web service to retrieve a list of roles within a selected source. It includes a filtration capability for refining the search. Function/Method getRoles (test.types.p3.GetRoles parameters) Input Parameters This table shows the input parameters that are available for your request: Field Application * Description The name of the application server that has the given role information. The criteria to use while searching. Roles You can search by role name and description. Transaction Code Enter the exact transaction code of the role search. Create Account Like Enter a role or account to create a new account that is similar to an existing account. Business Process The name of the business process which is used for the role search. The name of the business subprocess which is used for the role search. The name of the role used for the role search. The description of the role name used for the role search. The functional area of the role used for the role search. The company name of the role used for the role search. The default is All. Example: Finance The default is All. Example: Account Payable The default is All. Example: Z_AP_Accountant The default is All. Example: Accountant Role The default is All. Example: Finance Payables The default is All. Example: SAP Possible Value(s)/Example There is no default. Example: VA6 There is no default. Possible Values: Roles, Transaction Code, Create Account Like

Access Type *

Sub Process (Sub Process for the selected Business Process) Role Name

Role/Profile Description

Functional Area

Company (Name)

Transaction

September 2008

277

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services (Applicable for Access Type > Transaction Code only) The transaction code of the user is entered in this parameter if roles are searched using transaction code. User Info Group (Applicable for Access Type > Create Account Like only) User ID The ID of the user whose roles are displayed. There is no default. Example: CPerkins The default is All. Example: FB01

Applicable for all Access Types Locale Hit Count The language in which the information is returned. The count of the role information retrieved at a time. The default is EN. The default is 100. Example: 40

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered.

Output Parameters The following table shows the output parameters that are part of the returned message response: Field Application Role Name Role Type Role Description Valid From Valid To Lead Owner Example VA6 Z_AP_CLERK Single Role Z_AP_CLERK 05/07/1998 06/03/2017 Brian Law

278

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Role Details (SAPGRC_AC_IDM_ROLEDETAILS) You can call this Web service to retrieve the detailed description of the selected role. Function/Method roleDetails (test.types.p2.RoleDetails parameters) Input Parameters This table shows the input parameters that are available for your request: Field Role/Profile Name * Description The name of the Role/Profile whose details are returned. The name of application server that has the given role information. The language in which the information is returned. Possible Value(s)/Example There is no default. Example: Z_AP_Accountant The default is All. Example: CRM The default is EN. Example: EN, DE, JA, ES, FR, PT, IT, HU, ZH, RU, KO, PL

System

Locale

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered.

You can also search for Roles by using the Search Role Web service. Output Parameters The following table shows the output parameters that are part of the returned message response: Field Role Name Role Type Role Description Detail Description Business Process Sub Process Critical Level Reaffirm Period Last Reaffirm Date List System List CRM Example Z_AP_Accountant Single Role Z_AP_Accountant Accountant Role Finance Account Payable HIGH 0 05/05/2009

September 2008

279

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services Role Approver Alternate Approver List Functional Area List Company List Functional Area and Company Approver List Transaction Code F-02 Mark Horsten SAP Finance Payables

Brian Law Cheryl Jones

280

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Submit Request (to Access Control) (SAPGRC_AC_IDM_SUBMITREQUEST) You can call this Web service from the IdM system to submit a request in Access Control. Function/Method getSubmitRequest (test.types.p2.GetSubmitRequest parameters) Input Parameters This table shows the input parameters that are available for your request: Field Request Type * Description Refers to existing configured request types in the Compliant User Provisioning. It is used to determine what actions are performed to process the request. Iindicates the severity of the submitted request. Possible Value(s)/Example There is no default. Example: NEW, CHANGE, DELETE, LOCK, UNLOCK, etc.

Priority *

The default is HIGH. Example: HIGH, MEDIUM, LOW There is no default. Example: CRM

Applications *

The name of the application server in which the user is provisioned or the requested action is performed.

User Info Group (retrieves details from selected resources) User ID * The unique ID of the person for whom you are requesting access. The name of the person for whom you are requesting access. The e-mail address of the person for whom you are requesting access. The telephone number of the user for whom you are requesting access. The department of the user for whom you are requesting access. The location of the user for whom you are requesting access. The company name of the person for whom you are requesting access. There is no default. Example: mwong There is no default. Example: Mae Wong There is no default. Example: [email protected] There is no default. Example: 16501367006 There is no default. Example: Accounting There is no default. Example: Palo Alto There is no default. Example: SAP

User Name * (First Name and Last Name) Email *

Telephone Number

Department

Location

Company

September 2008

281

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services Employee Type

This is the status of the employee in the company.

There is no default. Example: NEW

Requestor Info Group (these parameters must match the existing data in the target authentication system) Requestor ID * The unique ID of the user who is submitting the request. The e-mail address of the user who is submitting the request. The name of the person who is submitting the request. The telephone number of the person who is submitting the request. There is no default. Example: sjones There is no default. Example: [email protected] There is no default. Example: Sandra Jones There is no default. Example: 16505551212

Requestor Email *

Requestor Name *

Telephone Number

Manager Info Group (these parameters must match the existing data in the target authentication system) Manager ID * The unique ID of the manager of the user who is submitting the request. There is no default. Example: BFAUST

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

Manager Name (First Name and Last Name) Manager Email

The name of the manager of the user who is submitting the request. The e-mail address of the manager of the user who is submitting the request. This is the managers telephone number. The reason for requesting access for the desired role is entered in this field. This parameter is the name of the Secure Network Communication (SNC). You use the SNC value for Single Sign-On to systems that run in an ABAP environment and use SAP GUI as the front-end client.

There is no default. Example: Bill Faust There is no default. Example: [email protected] There is no default. Example: 650 847-2000 There is no default. Example: New employee Example: CN=I801018, 0=SAPAG,C=DE

Manager Telephone

Request Reason

SNC Name

282

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

unsecurelogon

If this field is set to True, the user can log on without having a default SNC name for authentication. This field indicates the validity start date for a user. This field indicates the validity end date for a user

Example: True/False

validfrom

Example: 07/03/2009 Example: 09/05/2020

validto

Role Info Group (retrieves other details from Search Role Web service) System ID The name of the application server that contains the role information. The role ID of the submitted request. This determines what action is performed for the role (for example, add or remove the role for the user) This indicates the role validity start date for a user. The date when the user can start using the role. This indicates the role validity end date for a user. The date when the user can no longer use the role. There is no default. Example: VA6

Role ID

There is no default. Example: Z_AP_Clerks Example: ADD, REMOVE, KEEP

Add/Remove Action

Valid From

Example: 07/03/2009

Valid To

Example: 09/05/2020

Custom Fields Info Group Field Name The name of the additional custom field defined by your corporate policy. The value of the corresponding additional custom field defined by your corporate policy. There is no default. Example: Region There is no default. Example: EMEA

Value

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered. Output Parameters The following table shows the output parameters that are part of the returned message response:

September 2008

283

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services Field Request Number Status Example 1001 Open

284

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Risk Analysis (SAPGRC_AC_IDM_RISKANALYSIS) You can call this Web service to perform Segregation of Duties (SoD) analysis after submitting a request. You select specific roles and then check for any possible risk violation when the roles are assigned to users. Function/Method execute (test.types.p4.Execute parameters) Input Parameters The following table shows the input parameters that are available for your request:

If the Request ID value is entered, then the User ID and System parameters are optional and vice versa.

Field Request ID *

Description The unique identification number of an existing request.

Possible Value(s)/Example There is no default. The IDs of existing requests are possible values. Example: 1002

User ID *

The unique ID of the user to be provisioned. The name of the application server where risk analysis is executed. The language in which the information is returned.

There is no default. Example: mwong There is no default. Example: CRM The default is EN. Example: EN, DE, JA, ES, FR, PT, IT, HU, ZH, RU, KO, PL.

System *

Locale

This Web service call fails if any of the fields for Request ID, System, and User ID are not provided.

September 2008

285

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Output Parameters The following table shows the output parameters that are part of the returned message response: Field TCodeDetails Role Description System Transaction code description Transaction code ID Risk Details Org Rule Details Risk Risk Description Risk Level System Transaction codes Violation Count Risk Analysis Results Critical Tcode PFCG BUKRS P001 Create fictitious vendor and initiate payment to vendor HIGH Z_AP_Payables CRM Create Vendor FK01 Example

CRM FK01, FB01 2

286

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Audit Trail (SAPGRC_AC_IDM_AUDITTRAIL) You can call this Web service from either Access Control or the IdM system. When calling the Audit Logs Web service from the IdM system, it provides the request approval history. It returns the requests detail information such as when the request was created, who submitted it, and who approved it. All the provisioning service activity performed in Access Control is logged in the audit trail. When calling the Audit Logs Web service from Access Control, it returns the provisioning actions performed in the IdM system.

The GRC Audit Trail also displays the audit history provided by the IdM system for nonERP system provisioning. Function/Method getAuditLogs (test.types.p3.GetAuditLogs parameters) Input Parameters The following table shows the input parameters that are available for your request: Field Request ID Description The unique identification number of existing request. Possible Value(s)/Example Request ID of already submitted request. Example : 1002 User Info Group (retrieves details from selected resources) User ID The unique ID of the user for which audit information is retrieved. The first name of the user for which audit information is retrieved. The last name of the user for which audit information is retrieved. The starting date when the audit information is retrieved. The end date when the audit information is retrieved. This is the status of the request. The language in which the information is returned. Example : mwong

User First Name

Example: Mae

User Last Name

Example: Wong

From Date

Example: 05/03/2008

To Date Action

Example : 05/22/2008 Possible values are: OPEN, HOLD, REJECT, CLOSED, CANCEL. The default is EN. Possible values are: DE, JA, ES ,FR, PT, IT, HU, ZH, RU, KO, PL.

Locale

September 2008

287

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services Output Parameters The following table shows the output parameters that are part of the returned message response: Field Priority Status Created Date Request ID Submitted By Requested By Request History Path Stage ID CREATE_USER_PATH MANAGER 3485 Note: This is the parent ID for the action being performed. Q5F Example High OPEN 2008-05-05 1002 Sandra Jones Sandra Jones

Description Display String

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

User ID Request ID Action Date Action Value Dependent ID

05/05/2008 07:00 Z_AP_PAYABLE 3487 Note: This is the child ID for the action being performed.

288

September 2008

7 Access Control and Identity Manager Integration Technical Definitions for Access Control IdM Web Services

Request Status (SAPGRC_AC_IDM_REQUESTSTATUS) You can call this Web service from either Access Control or the IdM system. When you call the Request Status Web service from the IdM system, it checks the status of a request processed in Access Control including its detailed information. When you call the Request Status Web service from Access Control, it returns the status of the request within the IdM system. Function/Method getStatus (test.types.p2.GetStatus parameters) Input Parameters The following table shows the input parameters that are available for your request: Field Request ID * Description The unique identification number of the submitted request whose status is returned. The language in which the information is returned. Possible Value(s)/Example Example: 1002

Locale

The default is EN.

Parameters marked with an asterisk (*) are required fields. The Web service fails if the correct value is not entered. Output Parameters The following table shows the output parameters that are part of the returned message response: Field Request Status Request ID Status Approval Due Date User Name Stage Example

1002 Open 07/08/2008 Mark Wong Approver

All messages returned by the Web service consist of a response object comprising Message Type, Message Code, and Message Description.

September 2008

289

7 Access Control and Identity Manager Integration Integrating with an Identity Management Solution

Integrating with an Identity Management Solution

You can integrate Access Control with an IdM solution by performing configuration steps in the Compliant User Provisioning capability of Access Control. The procedures in this section describe the integration approach when Access Control is the leading provisioning system where provisioning requests are submitted to the IdM system. For more information, see the section Access Control as a Leading Provisioning System for the business case.

You also must perform configuration steps in the IdM solution. However, these steps vary from vendor to vendor. Therefore, this section does not provide specific configuration information required for the IdM system. The following diagram shows the configuration workflow required in Access Control to integrate with an IdM system:

290

September 2008

7 Access Control and Identity Manager Integration Defining Connectors for IdM Systems

Defining Connectors for IdM Systems

1. Go to Compliant User Provisioning > Configuration > Connectors > Create Connector. The Connectors screen appears. 2. In the Connector Type dropdown menu, select IDM. 3. In the Name field, enter a name for the connector. 4. In the Short Description field, enter a brief description of the connector. 5. In the Description field, enter a long text description of the connector. 6. In the Web Service URI field, enter the URI address of the Web service in the IdM. 7. In the User ID and Password fields, enter the user ID and password for the application server using this connection. The user ID must have the appropriate role to perform technical configuration tasks. 8. (Optional) In the System Language field, enter the system language of the target IdM system. If no language is selected, this field defaults to the language of the target IdM system. 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). You must physically obtain a copy of the SPML Schema file from the IdM vendor. This file contains action names and their required parameters. This includes the following: Create User Change User Delete User Lock/Unlock User Audit Logs Reset Password With this schema, you identify the action name so that you can map these actions to the corresponding actions of Access Control. For example, if an action is defined as an Object Class in the IdM schema, map it as: Create User:OC = BasicUser (where BasicUser is the name of the ObjectClassDfinition in the IdM schema). If an action is defined as an Extended Request Definition in the IdM schema, map it as: LOCK_USER:EXT = disableUser (where disableUser is the name of the ExtendedRequestDefinition in the IdM schema). The following table shows the parameters required to configure an IdM connector. These parameter values vary from one IdM vendor to another depending on the schema:

September 2008

291

7 Access Control and Identity Manager Integration Defining Connectors for IdM Systems

Action Map New Account (Create User) Asynchronous

Parameter Name CREATE_USER:OC

Parameter Value Name of user object class defined in the IdM schema For example, BasicUser. Async/Sync (depending upon the provisioning workflow the default is Sync) For more information on Async/Sync., see the section Sending Provisioning Request to an IdM System.

PROV_CALL

Change User Delete User Lock User

CHANGE_USER:OC DELETE_USER:OC LOCK_USER:EXT

Name of user object class for modifying user defined in the IdM schema For example, BasicUser. Name of user object class for deleting user defined in the IdM schema For example, BasicUser. Name of the object class /extended request for locking users defined in the IdM schema For example, disableUser. Name of the object class /extended request for unlocking users defined in the IdM schema For example, enableUser. Name of the object class /extended request for assigning role defined in the IdM schema For example, BasicUser. Name of the object class /extended request for resetting user password defined in the IdM schema For example, resetUserPassword.

Unlock User

UNLOCK_USER:EXT

Assign Roles

ASSIGN_ROLES:OC

Password Reset

RESET_PASSWORD:EXT

11. Click Save. 12. Click Test Connection.

You must create a connector for each resource that is configured in the IdM system.

Setting the Field Mapping You can maintain a map of the IdM fields that correspond to the Access Control fields. To configure the field mapping between Access Control and the IdM system, do the following: 1. Go to Compliant User Provisioning > Configuration > Field Mapping > Provisioning. Click Create. 2. The Field Mapping screen appears. In the Group Name field, enter a name for the group of connectors. 3. In the Short Description field, enter a brief description of the group. 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 the desired application connector defined for the IdM system.

292

September 2008

7 Access Control and Identity Manager Integration Defining Connectors for IdM Systems 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 the schema.

8. Click the Add icon to display the dropdown menu where you can select a name of the field for Access Control and Application (these are the IdM fields) in order to map the fields. Example: Access Control Field Email Address - STANDARD User FName - STANDARD User ID STANDARD User LName -STANDARD 9. Click Save. Application Field email firstname accountId lastname

Importing Roles You must import all roles for the IdM source to Access Control. These roles are then assigned to users when the Assign Roles Request Web Service is submitted to the IdM system. The role file is in a tab-delimited format. To import roles perform the following: 1. Go to Compliant User Provisioning > Configuration > Roles > Import Roles. The Import Roles screen appears. 2. Click Download Template and save the RoleImport.xls file to your local drive. This is a template for you to enter all of your role information for your organization. 3. Save your changes. You can rename the template if desired. 4. Select From File. 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 Overwrite Existing Roles indicator. 7. Click Import.

September 2008

293

7 Access Control and Identity Manager Integration Sending Provisioning Request to an IdM System

Sending Provisioning Request to an IdM System

After configuring Access Control to the IdM system, a provisioning request is sent from Access Control. Based on the action map of parameter, PROV_CALL (set as either asynchronous or synchronous); the provisioning request can take one of the two possible process flows. The diagram below illustrates how a provisioning request is sent to an IdM system to access a non-ERP application:

When a provisioning request is submitted in Access Control and the connector parameter setting PROV_CALL is set to asynchronous, the Submit Request Web service is immediately called without processing in the approval workflow. The provisioning request is submitted to the IdM system and processed in the provisioning workflow for access to a non-ERP system. If the provisioning workflow is not defined, it defaults to Synchronous. If PROV_CALL is set to synchronous, the provisioning request is sent to the approval workflow. Approving the provisioning request triggers an SPML SOAP provisioning request,

294

September 2008

7 Access Control and Identity Manager Integration Sending Provisioning Request to an IdM System which is submitted to the IdM system for processing within the provisioning workflow. The SPML SOAP request is submitted to the IdM system to perform the following operations: New Account (Create User) Change User Delete User Lock/Unlock User Assign/Remove Roles Password Reset The IdM system immediately returns a response message to Access Control before processing the provisioning request. Both the SPML SOAP provisioning request and the Submit Request Web service are SPML requests that groups its operations in a batch. Access Control always sends a service provisioning request as a batch. The batch request is for grouping of requests and is processed as a batch job. The batch request provides both synchronous and asynchronous processing of the request. The batch request will contain all the request types that you have defined during Request Creation process in Compliant User Provisioning. Here is a code snippet of the batch request that specifies the provisioning actions: Batch Request Example
<spml:batchRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" requestID="101530.017441490037271357" processing="urn:oasis:names:tc:SPML:1:0#sequential" onError="urn:oasis:names:tc:SPML:1:0#resume"> <!-SPML Request for Creating a USer format -->

<spml:addRequest> <spml:attributes> <dsml:attr name="objectclass"> <dsml:value>BasicUser</dsml:value> </dsml:attr> <dsml:attr name="accountId"> <dsml:value>ALL_ACTION_TEST3</dsml:value> </dsml:attr> <dsml:attr name="email"> <dsml:value>[email protected]</dsml:value> </dsml:attr> <dsml:attr name="lastname"> <dsml:value>doe</dsml:value> </dsml:attr> <dsml:attr name="firstname"> <dsml:value>john</dsml:value> </dsml:attr> <dsml:attr name="options.onlyResourcesUserPasswordRequired"> <dsml:value>true</dsml:value>

September 2008

295

7 Access Control and Identity Manager Integration Sending Provisioning Request to an IdM System
</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 Request For Changing User Attributes Format --> <spml:modifyRequest> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>ALL_ACTION_TEST3</spml:id> </spml:identifier> <spml:modifications> <dsml:modification name="firstname" operation="replace"> <dsml:value>srinivas</dsml:value> </dsml:modification> </spml:modifications> </spml:modifyRequest>

<!-- SPML Request For Deleting a User Format --> <spml:deleteRequest> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>ALL_ACTION_TEST3</spml:id> </spml:identifier> </spml:deleteRequest>

<!-- SPML Request For UNLOCKING a User Format -->

<spml:extendedRequest> <spml:operationIdentifier operationIDType="urn:oasis:names:tc:SPML:1:0#GenericString"> <spml:operationID>disableUser</spml:operationID> </spml:operationIdentifier> <spml:attributes> <dsml:attr name="accountId"> <dsml:value>ALL_ACTION_TEST3</dsml:value> </dsml:attr> </spml:attributes> </spml:extendedRequest>

<!-- SPML Request For LOCKING a User Format --> <spml:extendedRequest>

296

September 2008

7 Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call
<spml:operationIdentifier operationIDType="urn:oasis:names:tc:SPML:1:0#GenericString"> <spml:operationID>enableUser</spml:operationID> </spml:operationIdentifier> <spml:attributes> <dsml:attr name="accountId"> <dsml:value>ALL_ACTION_TEST3</dsml:value> </dsml:attr> </spml:attributes> </spml:extendedRequest> <!-- SPML Request For ASSIGNING ROLES for a User Format --> <spml:modifyRequest> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>ALL_ACTION_TEST3</spml:id> </spml:identifier> <spml:modifications> <dsml:modification name="roles" operation="add"> <dsml:value>Configurator Role</dsml:value> </dsml:modification> </spml:modifications> </spml:modifyRequest>

Provisioning to Other Target Systems with SPML SOAP Compliant Call

Access Control can provision to other systems that are SMPL SOAP compliant. The integration is similar to that used with an IdM or SAP Enterprise Portal. The procedures in this section describe the integration approach when Access Control is provisioning to other supported systems. For more information, see the section Access Control provisioning to other supported Systems via SMPL SOAP for the business case. Before performing configuration steps in Compliant User Provisioning, you must be able to: Use SPML SOAP with provisioning services Extract the SPML Schema parameter definitions

You also must perform configuration steps within the target system. These steps vary from system to system. Therefore, this section does not provide specific configuration information required for the target system.

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.

September 2008

297

7 Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call 2. The Connectors screen appears. In the Connector Type dropdown menu, select Others. 3. In the Name field, enter a name for the connector. 4. In the Short Description field, enter a brief description of the connector. 5. In the Description field, enter a long text description of the connector. 6. In the Web Service URI field, enter the URI address of the SPML SOAP provisioning request. 7. In the User ID and Password fields, enter the user ID and password for the application server using this connection. The user ID must have the appropriate role to perform technical configuration tasks. 8. In the System Language field, enter the system language. 9. In the Connector Category dropdown menu, select the type of connector category. 10. For the target system integration, obtain a copy of the SPML Schema file (XML file). You must physically obtain a copy of the SPML Schema file from the IdM vendor. This file contains action names and their required parameters, which includes the following: Create User Change User Delete User Lock/Unlock User Audit Logs Reset Password With this schema, you identify the action name so that you can map these actions to the corresponding actions of Access Control. For example, if an action is defined as an Object Class in the schema, map it as: Create User:OC = BasicUser (where BasicUser is the name of the ObjectClassDfinition in the schema). If an action is defined as Extended Request Definition in the schema, map it as: LOCK_USER:EXT = disableUser (where disableUser is the name of the ExtendedRequestDefinition in the schema). The following table shows example parameters for the connector configuration. These parameter values vary depending on the schema.

Action Map New Account (Create User) Asynchronous Change User Delete User Lock User

Parameter Name CREATE_USER:OC

Parameter Value Name of user object class defined in the IdM schema For example, BasicUser. Async/Sync (depending upon the provisioning workflow the default is Sync) Name of user object class for modifying user defined in the IdM schema For example, BasicUser. Name of user object class for deleting user defined in the IdM schema For example, BasicUser. Name of the object class /extended request for locking users defined in the IdM schema For example, disableUser.

PROV_CALL CHANGE_USER:OC DELETE_USER:OC LOCK_USER:EXT

298

September 2008

7 Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call

Unlock User

UNLOCK_USER:EXT

Name of the object class /extended request for unlocking users defined in the IdM schema For example, enableUser. Name of the object class /extended request for assigning role defined in the IdM schema For example, BasicUser. Name of the object class /extended request for resetting user password defined in the IdM schema For example, resetUserPassword.

Assign Roles Password Reset

ASSIGN_ROLES:OC RESET_PASSWORD: EXT

11. Click Save. 12. Click Test Connection.

Setting the Field Mapping You can maintain a map of the IdM fields that correspond with the Access Control fields. This configuration is performed in Compliant User Provisioning. To configure the field mapping between Access Control and the target system: 1. Go to Compliant User Provisioning > Configuration > Field Mapping > Provisioning. Click Create. 2. The Field Mapping screen appears. In the Group Name field, enter a name for the group of connectors. 3. In the Short Description field, enter a brief description of the group. 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 the desired 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 fields defined in the schema. 8. The field mapping screen for Access Control Fields and Application Fields appears. Click the Add icon to display the dropdown menu where you can select a name of the field for Access Control and Application (these are the parameter fields) to map the fields. Example: Access Control Field Email Address - STANDARD User FName - STANDARD User ID STANDARD User LName -STANDARD 9. Click Save. Application Field email firstname accountId lastname

September 2008

299

7 Access Control and Identity Manager Integration Provisioning to Other Target Systems with SPML SOAP Compliant Call Importing Roles You must import all roles for the IdM source to Access Control. These roles are then assigned to users when the Assign Roles Request Web service is submitted to the IdM system. The role file is in a tab-delimited format. 1. Go to Compliant User Provisioning > Configuration > Roles > Import Roles. The Import Roles screen appears. 2. Click Download Template. Save the RoleImport.xls file to your local drive. This is a template for you to enter all of your role information for your organization. 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 Overwrite Existing Roles. 7. Click Import.

300

September 2008

7 Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager

Integration with SAP NetWeaver Identity Manager

This section contains integration information for configuring: Provisioning Operations that are used for the Submit Request Web service to the NetWeaver Identity Manager. Search Operations that are used for Audit Trail Web service called from the NetWeaver Identity Manager. Provisioning Operations Depending on the nature and capabilities of the system, there are two execution modes for provisioning operations: asynchronous and synchronous SAP NetWeaver Identity Manager is an asynchronous system. The following steps outline the processing of provisioning request in asynchronous mode 1. Provisioning request is sent to Identity Services The SPML request contains field requested. Typically, the requestor sets the value for this field. 2. Identity Services accepts the request and returns the preliminary approval to the requestor Identity Services extracts the requestID from the request. If the value is not given by the requestor, the Identity Services generates a new value. The SPML response to the requested field are set to this value. Information about all subsequent processing of the request are stored together with the requested value discussed above. The requestor can now check the status of the operation using this value. 3. Identity Service handles the request Typically, these are multiple requests to managed applications for approvals and so forth. Occasionally, the requests are retry operations due to error conditions. 4. The requestor checks for the status of its provisioning request using the requestID value mentioned above.

September 2008

301

7 Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager

Adding person entry Operation properties Key Operation DN Value / Description SPML Add operation The unique id of the entry to be added. It is stored in the mskeyvalue attribute in the Identity Store Any set of the attributes available for the MX_PERSON. It is possible to add only person objects.

Attributes

Example SPML request

Supplied identifier: Simple User Supplied attributes and values givenname=Simple, sn=User, objectclass=MX_PERSON <SOAP-ENV:Body> <spml:addRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" requestID="add123"> <spml:identifier type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>Simple User</spml:id> </spml:identifier> <spml:attributes> <dsml:attr name="sn"> <dsml:value>User</dsml:value> </dsml:attr> <dsml:attr name="objectclass"> <dsml:value>MX_PERSON</dsml:value> </dsml:attr> <dsml:attr name="givenname"> <dsml:value>Simple</dsml:value> </dsml:attr> </spml:attributes> </spml:addRequest> </SOAP-ENV:Body>

SPML response Failure

<SOAP-ENV:Body> <spml:addResponse errorMessage="Insufficient access" requestID="add123" result="urn:oasis:names:tc:SPML:1:0#success" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core" xmlns:spml="urn:oasis:names:tc:SPML:1:0"/> </SOAP-ENV:Body>

Success
<SOAP-ENV:Body> <spml:addResponse requestID=add123 result=urn:oasis:names:tc:SPML:1:0#success xmlns:dsml=urn:oasis:names:tc:DSML:2:0:core xmlns:spml=urn:oasis:names:tc:SPML1:0/> </SOAP-ENV:Body>

302

September 2008

7 Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager

Modifying person entry Operation properties Key Operation DN Attributes Value / Description SPML Modify operation The unique id of the entry to be modified. Any set of the attributes available for the MX_PERSON. It is possible to modify only person objects.

Example SPML request

Supplied identifier: Simple User Supplied attributes and values: initials=SU [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 / Description

Operation Starting point

Example SPML request
Supplied identifier: Simple User

SPML Delete operation The unique id of the entry to be deleted.

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

September 2008

303

7 Access Control and Identity Manager Integration Integration with SAP NetWeaver Identity Manager
<spml:id>Simple User</spml:id> </spml:identifier> </spml:deleteRequest> </SOAP-ENV:Body>

304

September 2008

7 Access Control and Identity Manager Integration Search Operations

Search Operations
Checking the Result of Update Operation Since SAP NetWeaver Identity Manager operates in asynchronous mode, the requestor must regularly check the status of each provision operation by executing a special Identity Service operation. Operation Properties Key Operation Starting point Search type Attributes requested Filter Value / Description SPML Search operation operation= auditlog not relevant * (objectclass=*)

Returned Entry List of entries is returned. The identifiers of the returned entries are on the form cn = < mskeyvalue >, <used System Naming Context> Attribute requestoperation requestuserid requestid taskname Description The original update operation whose status is checked The user ID (mskeyvalue) of the entry which was updated The request ID for operation The name of the task that is executed as a result of the request. The ID of the task that is executed as result of the request. The status of the operation Date/time when the status of the audit entry is updated Additional message about the state of the request. Typically explanatory error message is shown here mskey of the entry that was the source of the operation in question The ID of the object in the audit table Value add, modify, delete

taskid

operationstatus timestamp message

OK, Error, Task initiated etc.

mskey

auditid

Example SPML request

Supplied identifier: auditlog (special IDS operation)

September 2008

305

7 Access Control and Identity Manager Integration Search Operations

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

306

September 2008

7 Access Control and Identity Manager Integration Search Operations

<dsml:value type="xsd:string">3</dsml:value> </dsml:attr> </spml:attributes> </searchResultEntry> </spml:searchResponse> </SOAP-ENV:Body>

Obtaining Entry Information At any time, you can obtain information about entries managed by the IDS. Usually, SPML does not offer the possibility to list multiple entries, but rather returns base level information, for example, information about a single entry. Identity Services implements additional operations to list multiple entries. Listing multiple entries Operation properties Key Operation Starting point Search type Attributes requested Filter Value / Descritpion SPML Search operation operation=list not relevant * OR any attribute subset (see available attributes below) The following must be present in the filter: (objectclass=MX_PERSON). In addition the filter can contain any valid filtering based on objects attributes

Detailed Search on Single Person Operation properties Key Operation Starting point Search type Attributes requested Filter Value / Description SPML Search operation The unique id of the entry to be listed. not relevant Or any valid attribute subset (objectclass=*) OR any valid filtering based on objects attributes

Example SPML request

<SOAP-ENV:Body> <spml:searchRequest xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"> <spml:searchBase type="urn:oasis:names:tc:SPML:1:0#GUID"> <spml:id>Simple User</spml:id> </spml:searchBase> <dsml:filter> <dsml:present name="objectclass"></dsml:present> </dsml:filter> </spml:searchRequest> </SOAP-ENV:Body> </SOAP-ENV:Envelope>Example SPML response

September 2008

307

7 Access Control and Identity Manager Integration Search Operations

308

September 2008

7 Access Control and Identity Manager Integration Search Operations

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=Simple User,ou=nwidm1,o=ids</spml:id></spml:identifier><spml:attributes><dsml:attr name="sn"><dsml:value type="xsd:string">User</dsml:value></dsml:attr><dsml:attr name="objectclass"><dsml:value type="xsd:string">MX_PERSON</dsml:value></dsml:attr><dsml:attr name="mskeyvalue"><dsml:value type="xsd:string">Simple User</dsml:value></dsml:attr><dsml:attr name="mskey"><dsml:value type="xsd:string">167</dsml:value></dsml:attr><dsml:attr name="mxdisabled"><dsml:value type="xsd:string">1</dsml:value></dsml:attr><dsml:attr name="givenname"><dsml:value type="xsd:string">Simple</dsml:value></dsml:attr></spml:attributes></searchR esultEntry></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=Simple User,ou=nwidm1,o=ids</spml:id></spml:identifier><spml:attributes><dsml:attr name="sn"><dsml:value type="xsd:string">User</dsml:value></dsml:attr><dsml:attr name="objectclass"><dsml:value type="xsd:string">MX_PERSON</dsml:value></dsml:attr><dsml:attr name="telephonenumber"><dsml:value type="xsd:string">+4711223344</dsml:value></dsml:attr><dsml:attr name="mskeyvalue"><dsml:value type="xsd:string">Simple User</dsml:value></dsml:attr><dsml:attr name="mskey"><dsml:value type="xsd:string">167</dsml:value></dsml:attr><dsml:attr name="mxdisabled"><dsml:value type="xsd:string">1</dsml:value></dsml:attr><dsml:attr name="initials"><dsml:value type="xsd:string">SU</dsml:value></dsml:attr><dsml:attr name="mail"><dsml:value type="xsd:string">[email protected]</dsml:value></dsml:attr><dsml:attr name="givenname"><dsml:value type="xsd:string">Simple</dsml:value></dsml:attr></spml:attributes></searchR esultEntry></spml:searchResponse> </SOAP-ENV:Body>

September 2008

309

Appendix A: Rule File Templates Business Process Template

Appendix A: Rule File Templates

This appendix describes the templates that upload SoD rules, critical actions, and critical permissions. You must use the format specified in these templates when you load rules. You can name your rule loading files anything you want, but use a naming convention that lets you identify which file contains which type of data. It is important to identify the system in the file name for function_action and function_permission files. For more information, see the section Rule Uploads.

Business Process Template

Business Process: ALL_business_processes.txt Field BUSINESS PROCESS ID LANGUAGE DESCRIPTION Type Data Length

CHAR 4 CHAR 2 CHAR 120

Function Template
Functions : ALL_business_function.txt Field FUNCTION ID LANGUAGE DESCRIPTION FUNCTION SCOPE Type Data Length Value Description

CHAR 8 CHAR 2 CHAR 120 CHAR 1 S = Single System C = Cross System

Function-Business Process Relationship Template

FunctionBusiness Process Relationship: ALL_function_bp.txt Field FUNCTION ID BUSINESS PROCESS ID Type CHAR CHAR Data Length 8 4

310

September 2008

Appendix A: Rule File Templates Function-Action Relationship Template

Function-Action Relationship Template

FunctionAction Relationship: <SYSTEM>_function_action.txt Field FUNCTION ID TRANSACTION STATUS Type CHAR CHAR NUMC Data Length 8 20 1 0=ENABLED 1=DISABLED Value Description

Function-Permission Relationship Template

FunctionPermission Relationship: <SYSTEM>_function_permission.txt Field FUNCTION ID T-CODE OBJECT FIELD FROM VALUE TO VALUE SEARCH TYPE STATUS Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR NUMC Data Length 8 20 10 10 40 40 3 1 AND/OR/NOT 0=ENABLED 1=DISABLED To load critical permission rules using the function-permission relationship, you can create a dummy entry in the t-code field for the load to work. The dummy value is ^!PERMISSION. For example, to load authorization object S_BDC_MONI as a critical permission type rule, enter ^!S_BDC_MONI in the t-code field of this file. Value Description

Rule Set Template

Rule Set: ALL_ruleset.txt Field RULE SET ID LANGUAGE Type Data Length CHAR 8 CHAR 2

RULE SET DESCRIPTION CHAR 132

September 2008

311

Appendix A: Rule File Templates Risk Definition Template

Risk Definition Template

Risk Definition: <SYSTEM>_risks.txt Field RISK ID FUNCTION 1 ID FUNCTION 2 ID FUNCTION 3 ID FUNCTION 4 ID FUNCTION 5 ID Type Data Length Value Description

CHAR 4 CHAR 8 CHAR 8 CHAR 8 CHAR 8 CHAR 8

BUSINESS PROCESS ID CHAR 4 PRIORITY NUMC 1 0=Medium 1=High 2=Low 3=Critical STATUS NUMC 1 0=ENABLED 1=DISABLED RISK TYPE CHAR 1 1=SoD 2=Critical Action 3=Critical Permission

Risk Description Template

Risk Description: <SYSTEM>_risks_desc.txt Field RISK ID LANGUAGE RISK DESCRIPTION Type Data Length

CHAR 4 CHAR 2 CHAR 132

DETAIL DESCRIPTION CHAR 1000 CONTROL OBJECTIVE CHAR 1000

312

September 2008

Appendix A: Rule File Templates Risk to Rule Set Relationship Template

Risk to Rule Set Relationship Template

Risk Rule Set Mapping: <SYSTEM>_risk _ruleset.txt Field RISK ID RULE SET ID Type CHAR CHAR Data Length 4 8

September 2008

313

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

Appendix B: Data Mapping Templates for Non-RTA Supported Systems

When you want to include non-RTA-supported systems in Risk Analysis and Remediation, use these templates to format data from those systems to ensure successful loading to Access Control. Tab-delimited text files are supported for uploading to Risk Analysis and Remediation.

User File Template

This template shows the required user information. When you download user information, the USERID field must be unique and not NULL. You should also ensure there are no duplicate records in the files and no blank records at the end of the file. User File Template Data Field Type String String Field Field Size Values Sorting 50 50

Field USERID FNAME

Req'd Description User ID First name (if not available, repeat User ID here) Last name (if not available, repeat User ID here) Email address Phone number (leave blank if unavailable) Department User Group (leave blank if unavailable)

Transformation Unique records only

CAPS Sort Yes Ascending Yes

LNAME

String

50

Yes

EMAIL PHONE

String String

250 40

No No

DEPARTMENT String USER-GROUP String

40 20 CAPs

No No

314

September 2008

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

User Action File Template

User Action File Template Data Field Field Field Type Size Values Sorting String 50

Field USERID

Req'd Description User ID

Transformation Unique record = The combination of columns 13 (User ID, Roles, and Action From) must be unique

Yes CAPS Sort Ascending Order 1

ROLES

String 49

Yes CAPS Sort Ascending Order 2 Yes CAPS sort Ascending Order 3 CAPS Yes

Access Role Name User Action

ACTIONFROM String 50

ACTIONTO

String 50

User Action, only applicable if User Action has range From/To Action Profile, if applicable. If not, repeat Role Name field. Composite role name, leave blank if not available.

If this value does not exist for the source system, leave blank

PROFILE

String 50

CAPS

Yes

If this value does not exist for the source system, repeat ROLE field from column 2 If this value does not exist for the source system, leave blank.

COMPOSITE ROLE NAME

String 50

CAPS

No

User Permission File Template

This file is required for legacy systems with configurable permission levels. User Permission File Template Data Field Field Field Type Size Values Sorting String 50

Field USERID

Req'd Description User ID

Transformation Unique record = The combination of columns 13 (User ID, Roles, and Action From) must be unique

Yes CAPS Sort Ascending Order 1

September 2008

315

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

User Permission File Template Data Field Field Field Type Size Values Sorting String 49

Field ROLE

Req'd Description Access Role Name User Permission (Permission Object/Field), required if applicable Query generated numerical sequence (1+ counter per user) Permission Value

Transformation

Yes CAPS Sort Ascending Order 2

PERMISSION String 100 CAPS Sort Yes Ascending Order 3

ACTION and PERMISSION field that use | | with no space in between

PRMGRP

String 20

Generate after sorting

Yes

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

FROMVALUE String 50 TOVALUE String 50

CAPS CAPS

Yes Yes

If this value does Permission not exist for source value, only system, leave blank applicable if User Action has range From/To User Permission Profile, if applicable. Composite role name, leave blank if not available. If this value does not exist for source system, repeat ROLE field from column 2 If this value does not exist for source system, leave blank.

PROFILE

String 50

CAPS

Yes

COMPOSITE String 50 ROLE

CAPS

No

If a single permission in the PRMGRP field contains multiple fields, the PRMGRP value must be the same for the different fields, if they are within the same authorization. Using the SAP security model as an example, say you have permission F_BKPF_KOA which contains two fields, Activity and Authorization Group. If a user has this permission in multiple roles, each roles authorization should have the same PRMGRP value for Activity and Authorization Group for F_BKPF_KOA. For example:

316

September 2008

Appendix B: Data Mapping Templates for Non-RTA Supported Systems Role File Template User ID - 12345 - Jane Doe Role A Authorization Object F_BKPF_KOA Field Activity 01 Field Auth Group AA Role B Authorization Object F_BKPF_KOA Field Activity 02 Field Auth Group BB The file layout is: UserID 12345 12345 12345 12345 Role Role A Role A Role B Role B Permission F_BKPF_KOA||ACTVT F_BKPF_KOA||BEGRU F_BKPF_KOA||ACTVT F_BKPF_KOA||BEGRU PRMGRP 1 1 2 2 FROMVALUE 01 AA 02 BB

Role File Template

This file is required for non-SAP security structures. Role File Template Data Field Type String String Field Field Size Values Sorting 50 100 CAPS Sorted Ascending

Field ROLE ROLE DESCRIPTION

Req'd Description Transformation Yes Yes Access Role Name Role Description

Role Action File Template

This file is required for non-SAP security structures. Role Action File Template Data Field Type Field Field Size Values Sorting

Field ROLE

Req'd Description Transformation Role Name

String 50

CAPS Sort Yes Ascending/ Sort Order 1 CAPS Sort Yes Ascending/ Sort Order 2 No

ACTIONFROM String 50

Role Action

ACTIONTO

String 50

Role Action If this value does not exist for source system, leave blank.

September 2008

317

Appendix B: Data Mapping Templates for Non-RTA Supported Systems Role Permission File Template

Role Action File Template Data Field Type Field Field Size Values Sorting CAPS

Field PROFILE

Req'd Description Transformation Yes Security Profile If this value does not exist for source system, repeat ROLE field from column 2

String 50

Role Permission File Template

The role permission file is required for non-SAP systems that include permission level data. Role Permission File Template Data Field Type Field Field Size Values Sorting

Field ROLE

Req'd Description Role Name

Transformation

String 50

Yes CAPS Sort Ascending Order 1

PERMISSION String 100 CAPS Sort Ascending Order 2

Object/Field

Concatenate ACTION and PERMISSION fields that use | | with no space in between Extractor/query generates this value. The value is generated after the data is sorted.

PRMGRP

String 20

Generate after sorting

Yes

Query generated numerical sequence (1++ counter per user) Permission Value Permission value, only applicable if User Action has range From/To Role Profile, if applicable.

FROMVALUE String 50 TOVALUE String 50

CAPS CAPS

Yes Yes

If this value does not exist for source system, leave blank

PROFILE

String 50

CAPS

Yes

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

Profile File Template

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

318

September 2008

Appendix B: Data Mapping Templates for Non-RTA Supported Systems Profile Action File Template

Profile File Template Data Field Type String String Field Field Size Values Sorting 50 100 CAPS Sorted Ascending

Field PROFILE PROFILE DESCRIPTION

Req'd Description Transformation Yes Yes Access Profile Name Profile Description

Profile Action File Template

This file is required for non-SAP security structures that use Profiles. Profile Action File Template Data Field Type Field Field Size Values Sorting

Field PROFILE

Req'd Description Transformation Profile Name Profile Action Profile Action If this value does not exist for source system, leave blank.

String 50

Yes CAPS Sort Ascending/ Sort Order 1 Yes CAPS Sort Ascending/ Sort Order 2 No

ACTIONFROM String 50

ACTIONTO

String 50

Profile Permission File Template

The profile permission file is required for non-SAP systems that include permission level data. Profile Permission File Template Data Field Type Field Field Size Values Sorting

Field PROFILE

Req'd Description Profile Name

Transformation

String 50

Yes CAPS Sort Ascending Order 1

PERMISSION String 100 CAPS Sort Ascending Order 2

Object/Field

Concatenate ACTION and PERMISSION fields that use | | with no space in between

September 2008

319

Appendix B: Data Mapping Templates for Non-RTA Supported Systems

Profile Permission File Template Data Field Type Field Field Size Values Sorting Generate after sorting

Field PRMGRP

Req'd Description Yes Query generated numerical sequence (1++ counter per user) Permission Value Permission value, only applicable if User Action has range From/To

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

String 20

FROMVALUE String 50 TOVALUE String 50

CAPS CAPS

Yes Yes

If this value does not exist for source system, leave blank

Action Permission Objects Template

Action Permission Objects Template Data Field Type Field Field Size Values Sorting CAPS Sort Ascending Order 1 CAPS Sort Ascending Order 3 CAPS CAPS

Field ACTION

Req'd Description Yes Action

Transformation

String 20

PERMISSION String 10

Yes

Permission

ACTVT

String 10

Yes Yes

Permission Object Field Permission Object Field Value Permission If this value does Object Value not exist for source system, leave blank

FROMVALUE String 50

TOVALUE

String 50

CAPS

No

Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File)
The ACT_PRM_FLD_VAL file loads descriptive text for actions, permissions, fields, and values. All values are included in one table, and the text is identified by the text in the second

320

September 2008

Appendix B: Data Mapping Templates for Non-RTA Supported Systems Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File) 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 Action text is required in this file. Sample File

Action Template This table shows the format for the action description section of the ACT_PRM_FLD_VAL description file. Action Template Data Field Type Field Field Size Values Sorting Req'd Description

Field Leave Blank

Transformation

Mandatory field. Leave Blank Required by load format 3 CAPS Hard code ACT Hard coded as value for this value ACT file Mandatory field. Leave Blank Required by load format String 50 2 CAPS CAPS Yes Action Sorted Ascending

ACT

Leave Blank

TCODE EN

Hard code EN Hard coded as value for this value EN field Yes Action Description

TCODE DESCRIPTIONS

String

<100

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

September 2008

321

Appendix B: Data Mapping Templates for Non-RTA Supported Systems Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File) Data Field Type

Field Leave Blank

Field Field Size Values Sorting Req'd Description Mandatory field. Required by load format 3 CAPS

Transformation Leave Blank

PRM

Hard coded Hard code PRM: as value value PRM for this file Mandatory field. Required by load format Leave Blank

Leave Blank

PERMISSION EN

String

50 2

CAPS CAPS

Yes

Permission

Sorted Ascending

Hard code EN Hard coded as value for this value EN field Yes Permission Description

PERMISSION DESCRIPTIONS Field Template

String

<100

This table shows the format for the field section of the ACT_PRM_FLD_VAL description file. Field Template Data Field Field Field Type Size Values Sorting Req'd Description Transformation Mandatory Leave Blank field. Required by load format CAPS Hard code FLD: as value for this file Yes Hard coded value FLD

Field Leave Blank

FLD

ACTVT

String 50

CAPS

Mandatory Leave Blank field. Required by load format Permission object field If this field does not exist for the source system, use hard coded ACTVT in this column

PERMISSION/PERMISSION VALUE

String <100 CAPS

Yes

EN

CAPS

Hard code Hard coded value EN as value EN for this field

322

September 2008

Appendix B: Data Mapping Templates for Non-RTA Supported Systems Description File Templates for Action, Permission Fields, and Values (ACT_PRM_FLD_VAL File)

Field Template Data Field Field Field Type Size Values Sorting Req'd Description Transformation String <100 Yes Permission Object Description

Field OBJECT FIELD DESCRIPTION Value Template

This table shows the format for the VAL_DESCR section of the ACT_PRM_FLD_VAL description file. Value Template Data Field Type Field Field Size Values Sorting Req'd Description Transformation Mandatory field. Required by load format CAPS Leave Blank

Field Leave Blank

VAL

Hard coded value VAL Hard code VAL: as value for this file Mandatory field. Required by load format Leave Blank

Leave Blank

PERMISSION/ PERMISSION VALUE

String <100 CAPS

Yes

Permission value field

Concatenate PERMISSION AND PERMISSION VALUE fields with hard coded /. Insure that no space is added before and after / character Hard coded value EN

EN

CAPS

Hard code EN as value for this field Yes Permission Value Description

PERMISSION VALUE DESCRIPTION

String <100

September 2008

323

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal Creating an iView

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal
You can retrieve master data from the SAP Enterprise Portal, which is a component of the SAP NetWeaver J2EE engine. Risk Analysis and Remediation is configured to connect to SAP Enterprise Portal through Web services, which in turn call the real-time agent (RTA) to retrieve master data. Before you install the RTA, sap.com~grc~ccsapeprta.sda, you must install the SAP Enterprise Portal component on the SAP NetWeaver J2EE engine and configure it for Risk Analysis and Remediation. For more information, see the following sections: Creating an iView Creating an iView Role Assigning an iViews to a Role Retrieving Master Data Creating a Function in Risk Analysis and Remediation for iView Creating a Portal Connection Verifying Portal RTA Creating a Function in Risk Analysis and Remediation for iView Creating a Function in Risk Analysis and Remediation for User Management Engine Actions

Creating an iView
An iView is an executable unit in the SAP Enterprise Portal content of SAP NetWeaver. In Risk Analysis and Remediation, it is equivalent to an action in the SAP system. An iView allows you to group fields in a header area. It can be used in multiple tabs of an application. For further information about creating iViews in SAP NetWeaver, see the SAP NetWeaver documentation on SAP Help Portal at http://help.sap.com.

Creating an iView Role

An iView Role allows users to access or perform an action on an assigned iView. Procedure To create an iView role: 1. Go to Content Administration > Portal Content >New >Role. 2. The Role Wizard appears. In Step 1: General Properties, enter the role name, role ID, Prefix of ID, master language, and a description of the iView Role. 3. Click Next. Example: iView Name Role1

324

September 2008

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal Assigning an iView to a Role iView ID ID Prefix Master Language Description Role1_ID (leave blank) English text description

Assigning an iView to a Role

After creating an iView, you must assign it to a role in order for users to use the iView. Procedure To assigning an iView to a role: 1. Open the Property Editor for the role you created. In this case, the role is Role1. 2. Highlight the iView that you want to assign. In this case, the folder is SAPSearch. Right mouse click to display the dropdown menu. An iView can be added to a role either by Delta Link or Copy. For this example, select Delta Link. 3. Accept the defaults in the Property Editor. The iView is automatically assigned to the role. The PCD location ID of the assigned iView to a role is used as the Action ID in Risk Analysis and Remediation.

Retrieving Master Data

The master data is a list of text objects to be uploaded for Risk Analysis and Remediation. Procedure To retrieve the master data: 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 click Test. The CCRTAWS Web services test page appears and displays a list of operation methods. 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. This file is a text object data and contains the master data. You can then upload the master data to Risk Analysis and Remediation.

September 2008

325

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal Verifying Portal RTA

Verifying Portal RTA

The Portal Real-Time Agent (RTA) that you must deploy on your NetWeaver J2EE server is sap.com~grc~ccsapeprta.sda. After deploying this component, verify that is it correctly installed and working. Procedure To verify the Portal RTA: 1. Open Access Control Risk Analysis and Remediation. 2. Make sure that the Web services for the RTA are exposed. Ensure that Web service, CCRTAWS is displayed in the Web Service Navigator. 3. Make sure that the portal service is deployed in the portal server. Example: Logon to the portal server. http://<IP Address>:<port>/irj/portal 4. Go to System Administrator/Support/Portal Runtime 5. In the Portal Anywhere Admin Tools pane, click Administration Console. 6. In the Archive Deployment Checker dropdown menu, make sure that the portal service, CCRTAWS is displayed. This confirms that the portal RTA is deployed properly. 7. Test that the portal connector is working. Open the CCDebugger screen. Example: http://<IP Address>:<port number>/webdynpro/dispatcher/sap.com/ grc~ccappcomp/CCDebugger c. The CCDebugger screen appears. In the Debugger dropdown menu, select the connector 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 roles from the portal server appears. This confirms that the connectors are working properly.

Creating a Function in Risk Analysis and Remediation for iView

Before you create a function in Risk Analysis and Remediation, download the Master Data from the portal server and upload it to the Risk Analysis and Remediation database. All PCD Location IDs of the Portal Content (Roles, iViews, Pages, Workset, Layout, Folder) are available in Risk Analysis and Remediation. Procedure To create a function in Risk Analysis and Remediation for Portal Risk Analysis: 1. Open Access Control Risk Analysis and Remediation. 2. Select the Rule Architect tab. 3. In the navigation bar, click Function > Create. The Create Function screen appears.

326

September 2008

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal Creating a Function in Risk Analysis and Remediation for User Management Engine Actions 4. Enter information in the following fields: For information on these fields, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User -> Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 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 the dropdown menu and select the connector name defined for the Portal RTA. 6. In the Action field, select the Search icon to display the Search window. Search for the iView that you created. Example: SAPSearch is the iView name. 7. A list of assigned iViews appears along with PCD locations or IDs. Select the required iView and save the function. 8. On the Permissions tab, the Function Information screen displays the values for the following fields: Field defaults to PERM Value From can be Full Control, Owner, Read/Write, Read, None (based on the permission set in the portal) 9. Set the Status to ENABLE, to enable the permission. 10. Complete this function as required for generating rules or creating risk.

Creating a Function in Risk Analysis and Remediation for User Management Engine Actions
For User Management Engine (UME) role-based analysis, you must create function(s) in Risk Analysis and Remediation. These functions contain UME actions for risk rules generation and subsequent role assignments. Before you can create a function, verify that the master data is loaded into the Risk Analysis and Remediation database. If it is not, download the master data from the portal server and upload it to the Risk Analysis and Remediation database. Procedure To create a function in Risk Analysis and Remediation for User Management Engine Actions: 1. Open Access Control Risk Analysis and Remediation. 2. Select the Rule Architect tab. 3. In the navigation bar, select Function > Create. 4. The Create Function screen appears. Enter information in the following fields: For more information on these fields, see the SAP GRC Access Control 5.3 Application Help on SAP Help Portal at http://help.sap.com/ -> SAP Business User ->

September 2008

327

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal Creating a Function in Risk Analysis and Remediation for User Management Engine Actions Governance Risk & Compliance -> SAP GRC Access Control -> SAP GRC Access Control 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 dropdown menu and select the connector name defined for the Portal RTA. 6. In the Action field, enter the User Management Engine action. Example: Function ID - AEACTION Description - SearchRequestView Business Process - Business Process Analysis Scope - Single System Actions tab: o o System - SAP EP Action - AE.ViewSearchRequestAll

6. Create a second function. Example: Function ID - CCACTION Description - SearchRequestView Business Process - Business Process Analysis Scope - Single System Actions tab: o o System - SAP EP Action - com.virsa.cc.RunAuditReports

7. Create a risk and generate rules based on functions created above. Go to Rule Architect tab. In the navigation bar, go to Risks > Create. The Create Risk screen appears. Example: Risk ID - UMER Description - User Management Engine actions risk of AC Risk Type - Segregation of Duties Risk Level - Medium Business Level - Finance Status - Enable Conflicting Functions tab: Function o o SearchRequestView - (AEACTION) RunAuditReports (CCACTION)

328

September 2008

Appendix C: Configuring Risk Analysis and Remediation for SAP Enterprise Portal Creating a Function in Risk Analysis and Remediation for User Management Engine Actions 8. In SAP Enterprise Portal, create a role based on the User Management Engine actions that you previously assigned for functions. Go to User Administration > Identity Management. For detailed information on these fields, see the SAP Enterprise Portal documentation. Example: Role Name - CC_AE_ROLE Actions o o SearchRequestView - (AEACTION) RunAuditReports (CCACTION)

9. Assign the role to the User ID. Go to User Administration > Identity Management. Example: User ID - dow_jones 10. In Risk Analysis and Remediation, perform a risk analysis on the User ID defined in the previous step. If a risk occurs, then the SoD violation is displayed.

September 2008

329