Virsa Access Enforcer For SAP 5.2 - Configuration - User Guide

Configuration Guide
Virsa Access Enforcer Version 5.2
COPYRIGHT Copyright 2006 SAP AG. All rights reserved. SAP Library document classification: PUBLIC 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, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. Virsa, Virsa Systems, Virsa Access Enforcer, ComplianceOne, Compliance Calibrator, Confident Compliance, Continuous Compliance, Firefighter, Risk Terminator, Role Expert, the respective taglines, logos and service marks are trademarks of SAP Governance, Risk and Compliance, Inc., which may be registered in certain jurisdictions. 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 information 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.
SAPImportant Disclaimers SAP Library document classification: PUBLIC This document is for informational purposes only. Its content is subject to change without notice, and SAP does not warrant that it is error-free. SAP MAKES NO WARRANTIES, EXPRESS OR IMPLIED, OR OF MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. Coding Samples Any software coding and/or code lines/strings (Code) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or were grossly negligent. Internet Hyperlinks The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint where to find supplementary documentation. SAP does not warrant the availability and correctness of such supplementary documentation or the ability to serve for a particular purpose. SAP shall not be liable for any damages caused by the use of such documentation unless such damages have been caused by SAPs gross negligence or willful misconduct. Accessibility The information contained in the SAP Library documentation represents SAPs current view of accessibility criteria as of the date of publication; it is in no way intended to be a binding guideline on how to ensure accessibility of software products. SAP specifically disclaims any liability with respect to this document and no contractual obligations or commitments are formed either directly or indirectly by this document. This document is for internal use only and may not be circulated or distributed outside your organization without SAPs prior written authorization.
CONTENTS
Preface About this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Alert Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Documentation Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Installation Guide, Configuration Guide, User Guide, and Release Notes . . . . . . . . . . . . . . . . . . . .11 Contacting SAP GRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 1 Administration Overview Preparing to Configure and Administer Virsa Access Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Completing the Pre-configuration Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Identifying Role Provisioning Processes to be Converted to Workflows . . . . . . . . . . . . . . . . . . . . .14 About Virsa Access Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Virsa Access Enforcer Basic Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Key Virsa Access Enforcer Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Virsa Access Enforcer Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Virsa Access Enforcer Administration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 2 Managing Workflows About Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Workflow Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 The Workflow Creation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 Example Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Basic Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Detour Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Workflow Escape Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Forked Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Parallel Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Workflow-specific Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Custom Approver Determinators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Virsa Access Enforcer 5.2 Configuration Guide
Setting up e-mail Reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Auto Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Configuring the CUA System Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Identifying the SMTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Creating New Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Creating Initiators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Defining Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Creating Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Configuring Escape Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Creating Forked Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 3 Setting Up Virsa Access Enforcer About Setting Up Virsa Access Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Initial Login to Virsa Access Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Mapping Virsa Access Enforcer Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 Where to Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Initializing the System DataInitialize DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Exporting System Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Defining Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Using Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Defining User Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 Defining Request Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Configuring Request Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Configuring Request Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Configuring Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 Configuring Employee Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Defining Number Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Defining Available Request Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84 Defining the Requestor Authentication Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Defining Approvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Defining Security Leads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87 Defining Points of Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Defining Application Approvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Setting Up Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90 Setting Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Identifying Technical Support Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 Setting Up the Service Level Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94 Configuring Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
6
Contents
Importing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97 Creating Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Searching Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Exporting Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 Selecting Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104 Configuring Default Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 Mapping Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108 Enabling and Removing Role Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111 Defining Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 Configuring Company Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112 Configuring Functional Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Configuring Application Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Configuring Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Configuring Business Sub-processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122 Configuring the Functional Area and Company Attribute . . . . . . . . . . . . . . . . . . . . . . . . .124 Reaffirming a Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Managing User Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Selecting a User Default System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127 Configuring User Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128 Setting User Default Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130 Monitoring Virsa Access Enforcer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 Viewing the System Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 Viewing the Application Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 Configuring HR Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135 Creating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135 Creating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 Configuring Field Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 Viewing the Process Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .145 Setting Up LDAP Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146 Defining Password Self Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Setting Up Background Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149 Creating Custom Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150 Miscellaneous Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .152 Configuring the Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Configuring the Log Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Configuring the Cache Job Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Configuring the Background Job Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
PREFACE
TOPICS
COVERED IN THIS PREFACE

About this Guide Conventions Alert Statements Product Documentation Documentation Formats Installation Guide, Configuration Guide, User Guide, and Release Notes Contacting SAP GRC
About this Guide

Conventions
The following conventions are observed throughout this document:

Bold sans-serif text is used to designate file and folder names, dialog titles, names of
buttons, icons, and menus, and terms that are objects of a user selection. Bold text is used to indicate defined terms and word emphasis. Italic text is used to indicate user-specified text, document titles, and word emphasis. Monospace text (Courier) is used to show literal text as you would enter it, or as it would appear onscreen.
Alert Statements
The alert statementsNote, Important, and Warningare formatted in the following styles:
Note Information that is related to the main text flow, or a point or tip provided in addition to the previous statement or instruction. Advises of important information, such machine or data error that could occur should the user fail to take or avoid a specified action. Requires immediate action by the user to prevent actual loss of data or where an action is irreversible, or when physical damage to the machine or devices is possible.
Important
Warning
10
Product Documentation Preface
Product Documentation
Documentation Formats
Documentation is provided in the following electronic formats:
Adobe Acrobat PDF files
You must have Adobe Reader installed to read the PDF files. Adobe Reader installation programs for common operating systems are available for free download from the Adobe Web site at www.adobe.com.
Installation Guide, Configuration Guide, User Guide, and Release Notes

You can download the Installation Guide, Configuration Guide, and User Guide, and Release Notes in PDF format.
11
Contacting SAP GRC

For information on contacting SAP Governance, Risks, and Compliance (SAP GRC), go to the SAP Support Portal which can be found on the SAP Service Marketplace at: service.sap.com. In order to use the SAP Support Portal you will need to log in using your SAP user account. If you do not already have an existing SAP user account, you must first create a new account. At the bottom right area of the SAP Service Marketplace page, under the Questions Regarding Login? heading, click the New User? Register here! link. You will be prompted for a Customer Number or Installation Number which you can get from your SAP Basis Administrator. (In an SAP system you can find your installation number under System -> Status -> SAP System data.) To submit your support request(s) from the SAP Support Portal, use the quick-link Messages and follow the SAP Message Wizard procedure. All support requests should be logged under the following SAP GRC support components:

GRC-SAE Virsa Virsa Access Enforcer GRC-SCC Virsa Compliance Calibrator GRC-SFF Virsa Firefighter for SAP GRC-SRE Virsa Role Expert
For more information on the SAP Support Portal, use the quick-links provided below:

SAP Notes Search Here you can search for reference material and possible solutions for any questions regarding the GRC components. Messages Here you can create Support Messages for the GRC components. Software Download Here you can download installations, upgrades, and support packages. SAP Service Channel - Your Inbox Here you can monitor the status of your open messages.
12
1
ADMINISTRATION OVERVIEW
TOPICS
COVERED IN THIS CHAPTER

Preparing to Configure and Administer Virsa Access Enforcer Completing the Pre-configuration Checklist Identifying Role Provisioning Processes to be Converted to Workflows About Virsa Access Enforcer Virsa Access Enforcer Basic Functionality Key Virsa Access Enforcer Concepts Virsa Access Enforcer Users Virsa Access Enforcer Administration Tasks
13
Preparing to Configure and Administer Virsa Access Enforcer

Before you can begin to configure Virsa Access Enforcer, you need to complete the Virsa Access Enforcer installation process. This includes not only the software installation, but also certain one-time configuration procedures, including creating the initial Virsa Access Enforcer user, and importing the Virsa Access Enforcer user roles. You can find all of these procedures in the Virsa Access Enforcer 5.2 Installation Guide.
Important If you have not already read the Virsa Access Enforcer 5.2 Installation Guide and completed the procedures it lists, you should do so at this time.
Completing the Pre-configuration Checklist

To ensure that your Virsa Access Enforcer installation is ready to be configured, complete the pre-configuration checklist:
___ Ensure that all SAP transports have been applied to all Virsa Access Enforcer systems ___ Choose the authentication system and ensure that all necessary the user accounts exist within it. ___ Verify that all Virsa Access Enforcer directories have the correct permissions set.
Identifying Role Provisioning Processes to be Converted to Workflows

Once you have configured Virsa Access Enforcer, you are ready to begin modeling your provisioning processes. Virsa Access Enforcer 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 should contain What authorizations a role should include Who should be required to approve that access
You will find it simple to create the appropriate workflow. The key is to know the details of the provisioning process you want to reflect before you begin creating the workflow. For more information about workflows, see About Workflows on page 22. Preparing to create workflows requires you to conduct a certain amount of research. Typically, you build a profile or spreadsheet of each provisioning process for which you want to create a workflow. Only after you have completed a profile that details each step of the process can you create and deploy a workflow that implements that process. Among the information included in a provisioning process would be:
What specific condition initiates the request. Each workflow follows a different path, specific to the role or roles 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 may also depend on the department, the business unit to which the user belongs,
14
Preparing to Configure and Administer Virsa Access Enforcer Chapter 1 Administration Overview
or other criteria. You need to identify the details of the condition that calls each workflow.
How many levels of approval the request requires. Each organization has unique requirements for how many people must approve a user access request. In addition, some user roles may require only one or two approvers, while others may require three or more. This typically depends on the nature and sensitivity of the requested user role. For each of your provisioning processes, you need make a note of how many levels of approval should be required.
For each level of approval, who is authorized to approve the request. For each step in the process, you need to determine who should be responsible for approving or denying a request. This can be an individual user or, in some cases, it can be any one of a group of users.
What happens if any of the assigned approvers chooses to deny the request. You need to determine what action Virsa Access Enforcer should take if a designated approver denies the request. This can include steps to mitigate risk, to provision only the approved portion of the request, or to abort the provisioning process entirely.
What happens if any of the assigned approvers fail to respond to the request within a specified period of time. To expedite the provisioning process, you can set a limit to how long an approver has to approve or deny a request. You must also decide what should happen to the request if an approver does not act within the specified period.
Whether or not partial approval is acceptable for the request. If a request includes more than one user role, its possible that one role in the request could be approved, and another denied. You need to define how the process should behave in that situation.
In the event that the request is ultimately approved, whether or not Virsa Access Enforcer should automatically initiate provisioning. Virsa Access Enforcer doesnt 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 may need to determine whether or not to automatically begin provisioning when a request is approved.
You need to capture all of this profile information for each provisioning process. In some cases, this research may be a bit time-consuming. Even so, preparing provisioning profiles will help you avoid creating conflicts, and make the process of creating the actual workflows much simpler.
15
About Virsa Access Enforcer

Virsa Access Enforcer simplifies the process of provisioning access to system users. You use it to assign user roles to new users, as well as to change role assignments for existing users. Fundamentally, Virsa Access Enforcer executes workflows to collect the information and approvals necessary to grant system access to SAP users. Virsa Access Enforcer administrators create these workflows within Virsa Access Enforcer, modeling the workflows after existing business processes to provision access. Once deployed, the workflows manage each provisioning request, beginning with the initial request, tracking the progress through the stages and gathering the necessary approvals. At the end of the workflow, the request has all of the approvals required to provision access for a user. Virsa Access Enforcer can then pass the collected information to the person or department responsible for the provisioning, or automatically use a remote function call to launch the actual provisioning process.
Virsa Access Enforcer Basic Functionality

You can classify Virsa Access Enforcer functionality into three basic categories:

Creating Requests Approving/Denying Requests Administration
Both creating requests and approving/denying requests are requestor/approver functions. Virsa Access Enforcer supports these functions by providing a Web-based interface for requestors, and interacting with approvers via email. For details about Virsa Access Enforcers user functions and how to use them, see the Virsa Access Enforcer 5.2 User Guide. This guide describes Virsa Access Enforcers administration function, which enables you to create and deploy the workflows that manage the provisioning request process. Put more simply, requestors and approvers follow pre-defined paths to assign user permissions; administrators define those paths. As an administrator, you will both configure Virsa Access Enforcer and use Virsa Access Enforcer to create and deploy workflows. When you configure Virsa Access Enforcer you define the many details encompassed by a workflow. When you create a workflow, you create an automated path to collect the information and approvals required to provision access for a user.
Key Virsa Access Enforcer Concepts

Throughout the course of this administration guide, you will see many references to certain terms. These terms represent key concepts that are intrinsic to Virsa Access Enforcer. In order to fully comprehend the descriptions and instructions you will find later in the guide, it is important that you familiarize yourself with these concepts now. The concepts are provisioning access, roles/role assignment, risk analysis/mitigation, and workflow.
16
About Virsa Access Enforcer Chapter 1 Administration Overview
Provisioning Access
When you provision access for a user, you make it possible for that user to connect to a specific business module. That is, you allow a specific user account and password combination to log into that module. The access you grant to the user can beand in most cases will berestricted to the tasks that user needs to be able to perform. Access may also be restricted to certain systems or applications. When appropriate, you also use the provisioning process to change or remove a users access. In Virsa Access Enforcer, provisioning always refers to the process of defining the modules and systems to which a user has access. The phrase provisioning access has the same meaning.
Roles and Role Assignment
Virsa Access Enforcer supports provisioning for ERP systems in which user access is rolebased. A role is a predefined set of access permissions. In this model, access is not granted to individual users, but rather to roles. To provision access for a user to a financials application, you must assign to that user a role that has access to the application. If the user has the requisite role, they automatically have access to the application. Because different users may need to access the same module or application, but may 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 both to which applications the user has access, and the level of access the user has. Role assignment is the fundamental starting point for the provisioning process. A request (see Request and Approval on page 18) defines a user and the role or roles that are to be assigned to the user.
Risk Analysis and Mitigation
One key element of provisioning in Virsa Access Enforcer is the identification and mitigation of risk. In Virsa Access Enforcer, a risk is a conflict between roles assigned to a user. For example, in most organizations the roles Receiving, Inventory, and Accounts Payable are mutually exclusive. To prevent the risk of fraud, a person responsible for cataloguing deliveries cannot also have the ability catalogue inventory, nor can they have the power to authorize payment for a delivery. Virsa Access Enforcer lets you automatically review and evaluate whether or not a request poses a risk of conflicting roles. This is risk analysis. If analysis determines that a provisioning request poses a risk, you may have several possible ways to mitigate the risk. Risk mitigation refers to the action or actions you take to lessen or remove an identified risk. When you define the provisioning process for a role, you have the option of including risk mitigation options for some of your approvers. The approvers can then choose to take action to mitigate a risk, or even to deny the provisioning request entirely.
Workflow
In Virsa Access Enforcer, a workflow defines the steps required to approve the assignment of one or more roles to a specific user. The workflow catalogues the steps of the process and identifies the people who will be required to approve the request. In theory, workflows are intended to model the business processes your organization already has in place to authorize access. In practice, however, you may want to rethink your approval processes as you create your workflows (preferably beforehand).
17
Once you create and deploy a workflow, other Virsa Access Enforcer requestors and approvers use it to request access for other users.
Request and Approval
Administrators are responsible for creating workflows, but it is typically others who actually use the workflows. They do so either by making requests or by granting or denying approval. In Virsa Access Enforcer, a request is an official message asking to provision access to a user. The term we use for this is initiating a request, and the person who does so is the initiating requestor or just requestor. A requestor is any authenticated SAP user who initiates a request on their own behalf or on behalf another user.
Note Depending on the needs of your organization, you may also be able to configure which types of access a requestor can request, or even whether or not a requestor can select specific access types at all.
Once a request has been initiated, it must be approved. Requestswhich is to say workflowsare made up of one or more stages. At each stage, the request requires the approval of the person (approver) designated in the workflow for that stage. Being familiar with these terms and concepts will help you as you work through this guide to configure your implementation of Virsa Access Enforcer and create workflows.
Virsa Access Enforcer Users

There are three types of Virsa Access Enforcer users, each corresponding with one of Virsa Access Enforcer basic functions. These users are:
Requestor Requestors create provisioning requests, asking that a specific user be assigned one or more user roles. Each request initiates a workflow, a process requesting approval of the role assignment from designated approvers.
Approver Approvers either approve or deny provisioning requests. Virsa Access Enforcer interacts with approvers via email. At each stage of a workflow, one user is designated as the approver for that stage, and that user receives an approval email generated by Virsa Access Enforcer. The email includes two links, one to approve the request, and one to deny it. The approver clicks the appropriate 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. It is the responsibility of the administrators to ensure that the workflows they create accurately reflect the correct process, designate the correct approvers, and achieve the correct provisioning result.
Each of these users must themselves be assigned the appropriate roles, and the roles determine who has the authority to act in which capacity. Only users with the requestor role can create new requests; only administrators can create and deploy workflows.
18
Virsa Access Enforcer Administration Tasks Chapter 1 Administration Overview
Virsa Access Enforcer Administration Tasks

Once you have ensured that Virsa Access Enforcer is correctly installedand have collected and documented the business processes your organization follows to provision user accessyou are ready to begin performing administration tasks. These tasks fall into two categories:

Configuring Virsa Access Enforcer in preparation for creating and deploying workflows Workflow management, including creating, validating, modifying, deploying, and deleting.
The primary Virsa Access Enforcer administration task is creating the workflows that implement the user access provisioning processes. As an administrator, you define the workflows used by the requestors and approvers. By their nature, workflows incorporate a great deal of information. Among many other details, you need to identify the request condition that initiates a specific workflow, you need to determine who are the approvers, what are the roles, and what permissions are associated with each role. You can define each of these details for each workflow as you create it. However, you will find it much more efficientand your roles and permissions will be much more consistentif you define as many of the details as possible before you begin creating workflows. Thus, your other administrative task will be to configure Virsa Access Enforcer. When you configure Virsa Access Enforcer, you define the details of the components that are the building blocks for workflows.
Important Before you begin configuring Virsa Access Enforcer or creating workflows, you need to complete your pre-configuration due diligence.
You need to:

Work with your business process owners to capture and record the approval requirements for each user role Complete the pre-configuration checklist
Once you have completed these tasks, you are ready to begin the configuration process, Virsa Access Enforcer setup.
Virsa Access Enforcer Setup
Setting up Virsa Access Enforcer involves configuring or defining connectors, data sources, security settings, Web service, and many other objects. You will use these objects when you create your workflows. You can find a list of all Virsa Access Enforcer setup tasks and detailed instructions on how to perform them in Chapter 3, Setting Up Virsa Access Enforcer on page 61.
19
Workflow Management
Workflow management comprises creating, modifying, deploying, activating, deactivating, and deleting workflows. Each workflow should replicate one of your organizations exiting provisioning processes. You can find a list of all workflow management tasks and detailed instructions on how to perform them in Chapter 2, Managing Workflows on page 21.
20
2
MANAGING WORKFLOWS
TOPICS

About Workflows Workflow Components The Workflow Creation Process Example Workflows Workflow-specific Configuration Tasks Custom Approver Determinators Setting up e-mail Reminders Auto Provisioning Configuring the CUA System Setting Identifying the SMTP Server Creating New Workflows Creating Initiators Defining Stages Creating Paths Configuring Escape Routes Creating Forked Workflows
21
About Workflows
As previously described, a workflow defines the steps required to approve the assignment of one or more roles to a specific user. Each provisioning request specifies a distinct condition. When a request comes in to Virsa Access Enforcer, it triggers the specific workflow designed to manage requests with that particular condition. Though neither the requestor nor the approvers ever see the actual workflow, it is the workflow that determines the approval process. 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 comprises two basic tasks:

Obtaining all of the required approvals for those role assignments Carrying out the actual provisioning process within SAP
Virsa Access Enforcer uses workflows to automate the collection of approvals, and can also automate the provisioning process.
Workflow Components
Each workflow is called by a specific initiator, and contains one or more stages. It can be described as a kind of chain reaction, a definition of what causes the workflow to begin, and at each point, what should happen next. When you create a workflow, you define three elements: the initiator, one or more stages, and the path.
Stages
A stage is a decision point in a workflow. Workflows are composed of stages. At each stage, one approver is required to approve or deny the request. The stage defines who must approve, and also determines what happens next based on the decision of the approver. At each stage of the request process, Virsa Access Enforcer sends an e-mail message to the person required to approve or deny the request. The request process cannot continue until the approver approves the request.
Paths
A path defines the sequence of stages in a workflow. When you create a workflow, you begin by creating each of its stages. By themselves, though, 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.
Initiators
An initiator is an Virsa Access Enforcer object that defines a single, precise request condition, and identifies the single, unique workflow designed to handle that specific type of request. Initiators and workflows function as matched pairs. Each initiator can call only one workflow, and each workflow must be called by one (and only one) initiator. An initiator is not considered to be part of the actual workflow it calls. The workflow is defined by its stages and the path that determines the sequence of the stages. Even so, a workflow can only be triggered by its assigned initiator.
22
About Workflows Chapter 2 Managing Workflows
The Workflow Creation Process

The process for creating a workflow involves both planning and execution. In most cases, planning a workflow is far more time-consuming than creating it in Virsa Access Enforcer. Creating a workflow in Virsa Access Enforcer is a straightforward process of creating or selecting the necessary components and then creating a path to bind them. It is the planningdetermining how you want the workflow to functionthat requires some consideration.
Workflow Planning
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 those approvers need to be, and specify the appropriate sequence for those approvals. You may also need to determine what should happen to a request if one of the assigned approvers denies it. You need to determine all of these details before you begin creating the workflow in Virsa Access Enforcer.
Workflow Definition
Once you have carefully planned the workflow, you define it within Virsa Access Enforcer. The fundamental process is:
1
Create any new stages you need for your workflow. The stages in a workflow define the approvers for the request. If you need to use a stage that does not exist in Virsa Access Enforcer, you will need to create it. Because you can use the same stage in several different workflows, you only need to create a new stage if the stage you need doesnt already exist. For this reason, your first step is to evaluate your existing stages to see if you want to use any of them in your workflow, then create the ones you need that dont yet exist.
Create the necessary initiator to call your workflow. The initiator determines which requests will use the workflow. Only requests that have the same attributes as those you assign to the initiator will call the workflow.
Create and activate the path. The path is the structure and framework of the workflow; it binds the various components into a cohesive process. When you define the path, you create an association between the workflow and its initiator, identify the workflows stages and the sequence in which they are called, determine whether or not the workflow should automatically launch provisioning, and activate the finished workflow.
Once you save and activate the workflow, it goes into effect. Any subsequent request that matches its initiator calls the workflow, which then manages the approval process.
Note Workflows manage the approval process behind the scenes, the users who initiate and approve access requests never see the workflow itself; they interact with Virsa Access Enforcer via e-mail.
23
Important
When you first begin creating and saving workflows, you should review them carefully before you activate them. You can delete a workflow only if no access request has ever called it. Once a workflow has managed a request, it cannot be deleted. Thus, you should not activate a workflow until you are certain it reflects its intended approval path.
Example Workflows
At this point, you may think of each workflow as a single approval process, granting access rights to a single user for a single role. In many cases, this is an accurate perception...but not always. In fact, Virsa Access Enforcer supports several variations of workflows:
You can create a single initiator for multiple roles. While many enterprises choose to create their workflows such that each one defines the approval process for a single role, this is by no means mandatory. 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 can be used to approve several different roles. In this case, 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 need to 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 will be times when the roles requested 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 need to determine what Virsa Access Enforcer should do with the request. Do you want to abort the request? 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.
To setup Virsa Access Enforcer provisioning for your enterprise, you need to understand and use all of these workflow variations. They are described in the sections that follow:

Basic Workflows on page 25 Detour Workflows on page 26 Workflow Escape Routes on page 26 Forked Workflows on page 27
24
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 often called a main workflow. It defines request approval as a linear process, starting with the initiator, and ending with approval at the final stage. Figure 1 illustrates this basic path:
Figure 1
Sample Workflow with Three Stages
The example 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, including:

Application Business Process Company Employee Type Functional Area Request Priority Request Type Role
Most of the workflows you create in Virsa Access Enforcer will be main workflows. For instructions for creating workflows, see Creating New Workflows on page 41.
25
Detour Workflows
Detours are stand-alone 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. Instead, if the state of a request meets certain 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. That is to say, 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 may want the remainder of the request to proceed. Thus, 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.
Note When 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 is very similar to that 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 interface that you use to create a main workflow. For instructions for creating workflows, see Creating New Workflows on page 41. To learn how to define a jump from a main workflow to a detour, see Creating Paths on page 50.
Workflow Escape Routes
An escape route is a shortcut mechanism you add to a workflow that causes a request to bypass one or more stages of the workflow. In other words, it causes the request to jump ahead in the workflow path.
Note Because an escape route is an attribute of a workflow, you must create a workflow before you can add an escape route to it.
Escape routes have the following limitations:

A workflow can apply an escape route only at the first stage of the workflow path. A workflow can apply its escape routes only if it receives an approver not found message at the stage.
Approver not found is a very specific condition. It informs you that the workflow could not derive the identity of the designated approver, because the attributes of the approver are either ambiguous or inadequate. Virsa Access Enforcer cannot determine to whom it should send the approval e-mail, and so it responds with approver not found message. For more information about escape routes, along with instructions about how to create them, see Configuring Escape Routes on page 55.
26
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 pathsor bothdepending on the condition of the request. You 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, and the decision itself is based on whether the requested access is for an SAP application, or for an application external to SAP.
Note 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.
For example, you can create an initiator that calls a workflow to manage all user access requests where the user will have 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 doesnt distinguish between SAP and non-SAP applications; regardless of the applications included in the request, submitting the request calls the same initiator. If the workflow forks, the attributes of the request determine how the workflow manages the request:

If only SAP applications are requested, the path configured to manage SAP application approvals manages the request. If only non-SAP applications are requested, the path configured to manage non-SAP application approvals manages the request. If both SAP and non-SAP applications are requested, 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 have the choice of either creating two different initiators, one for each application type, with each workflow handling requests for one of the application types. Alternatively, you can create a single initiator that calls a forked workflow. To learn how to created a forked workflow, see Creating Forked Workflows on page 58.
Parallel Workflows
It is possible for a single request to call multiple initiators, and trigger multiple workflows. When this occurs, Virsa Access Enforcer processes all the triggered workflows simultaneously and in parallel. Figure 2 illustrates how Virsa Access Enforcer can process two workflows in parallel. In this case, each workflow has three identical stages, in the same sequence: Manager, Role Owner, and Security. The user for whom the request has been submitted will have two different roles, and those roles have different role owners. Even so, the user will have only one manager.
27
Figure 2
Parallel Workflow Processing
When the requestor submits the request, both workflows call for the manager to be the first approver. Since in both paths the manager turns out to be the same person, Virsa Access Enforcer send only one approval e-mail to that person, who only needs to make single decision. Presuming the approver approves the request, Virsa Access Enforcer proceeds to the next stage for each workflow. Here, even though both workflows call for the role owner to approve the requested access, the actual approvers are different people. Virsa Access Enforcer generates two different e-mails, one for each identified approver. Virsa Access Enforcer then waits for both approvers to take action. When both approvers have approved the request, Virsa Access Enforcer moves on to the next stage for both workflows. In this example, the final stage for both workflows is security, and this again resolves to a single approver. Virsa Access Enforcer therefore sends a single approval e-mail to the security approver, who can then approve or deny the request.
Note If at any point, any approver denies the request, Virsa Access Enforcer stops handling the workflows in parallel, and manages each workflow in the manner dictated by that workflow.
28
Workflow-specific Configuration Tasks Chapter 2 Managing Workflows
Workflow-specific Configuration Tasks

The configuration tasks described in this section relate directly to the creation of workflows. You will need to complete these configuration tasks before you begin migrating your provisioning processes into Virsa Access Enforcer. Workflow-specific configuration tasks include:
Custom Approver Determinators Virsa Access Enforcer uses approver determinators to identify approvers at workflow runtime. Virsa Access Enforcer provides a collection of default determinators, and you may find that these are sufficient for your needs. However, your enterprise may also need to use custom combinations of attributes as determinators. If so, you will need to create these custom determinators before you can begin to create your workflows. You can learn more about custom approver determintors and how to define them in the section Custom Approver Determinators on page 30.
Setting up e-mail Reminders As Virsa Access Enforcer processes a request through a workflow path, it sends approval e-mails to the designated 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 e-mails, Virsa Access Enforcer generates notification e-mails to all interested parties at submission and at final approval. In addition, you can configure Virsa Access Enforcer to automatically send e-mail reminders to approvers who have failed to act upon requests within a specified time period. This can help to ensure that the approval process does not get sidetracked. You can learn more about e-mail reminders and notifications, along with how to define them in the section Setting up e-mail Reminders on page 32.
Auto Provisioning Virsa Access Enforcer automates the process of collecting approvals for provisioning requests, ensuring that the correct supervisors approve or deny all requests in a timely fashion. In addition, you can configure Virsa Access Enforcer to automatically launch the actual provisioning request. This allows you to streamline the provisioning process from start to finish. Everything becomes an automated cycle. Users are only required to submit requests, and approvers must only click a link to approve or deny. Virsa Access Enforcer can manage the rest of the process. You can find out how to switch on automatic provisioning in the section Auto Provisioning on page 34.
Configuring the CUA System Setting Many enterprise environments use a single host system to manage all user administration. This system is typically referred to as the Central User Administration (CUA) system or host. Because Virsa Access Enforcer manages the provisioning process, and also must authenticate the users with whom it interacts, Virsa Access Enforcer needs to communicate directly with the CUA. Thus, if your enterprise uses a CUA, you must define the CUA within Virsa Access Enforcer before
29
you can begin creating workflows. You can find the procedure for defining the CUA in the section Configuring the CUA System Setting on page 38.
Identifying the SMTP Server Virsa Access Enforcer interacts with approvers via e-mail, andif configured to do so also sends e-mail notifications to all interested parties. For this reason, you must identify the SMTP server that Virsa Access Enforcer will use. You can find the procedure for defining the SMTP server in the section Identifying the SMTP Server on page 40
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 person to be the approver for a stage. Instead, you configure a determinator that Virsa Access Enforcer uses to identify the appropriate approver. This determinator comprises the attributes of the person who can approve the request at this stage, typically based on the attributes of the request. For example, you might create a stage named Manager, and include it in all workflows where you need the users prospective manager to sign off on every request for access. As you define the stage, you specify that the department manager is the approver for the stage. Since your enterprise has countless departments and managers, you cannot identify any specific person to act as approver for the Manager stage. Instead, you define that the manager of the users department is the approver. When the user submits their request, that request includes the department in which the user will work, and that department become an attribute of the request. Then, when the request arrives at the manager stage, Virsa Access Enforcer sees from the requestderiveswhich is the correct department, and identifies who is the actual person that manages the department. Thus, the determinator is department manager. This is a simple example, and department manager is one of the default determinators provided with Virsa Access Enforcer. However, your enterprise may have several branches of the same department in different locations, each with a different manager. In that case, the determinator needs to include not only the position of the approver (department manager), but also the location of the branch. For example, a user requesting access in New York needs to be approved by the manager in New York. The submitted request will include the necessary information, both department and location, but there isnt a default Virsa Access Enforcer determinator that combines these two attributes. Thus, in order to create the Manager stage, you also need to create a custom determinator that enables Virsa Access Enforcer to derive who is the correct approver based on the request.
X To Create a Custom Determinator: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Custom Approver Determinators.
Figure 3
Virsa Access Enforcer Configuration Tab Navigation Menu
The Approver Determinator page appears.

30
In the Approver Determinator pane, click Create. The Create Approver Determinator page appears.
Figure 4 3
Create Approver Determinator Page
In the appropriate fields, enter a name, short description, and long description for the new determinator.
Note The information you type into the Short Description field appears in dropdown lists throughout Virsa Access Enforcer when you perform a query. The information you provide in this field is limited to 20 characters.
From the CAD type dropdown list, select the Custom Approver Determinator type. The CAD types you can select are Attribute or Web Service. If you select Attribute, a list of attributes that Virsa Access Enforcer uses to determine the appropriate approver at runtime appears. If you select Web Service, the fields in which you can enter Web service details such as URL, User Name and Password appear.
Figure 5 5
Create Approver Determinator Attributes
Select the appropriate attributes or type in the Web service details, and then click Save. You see the following success message:
31
Figure 6
Custom Approver Determinator Saved Successfully
Whether or not you need to create custom determinators depends on the needs of your enterprise. In this sense, custom determintors are optional. If you decide that they are not necessary, you dont need to create any. However, many enterprises do require custom determinators to properly employ Virsa Access Enforcer. You first need to evaluate your existing approval processes and create a strategy for recreating them within Virsa Access Enforcer. Determining who will approve requests at each stage is a fundamental part of the strategy. Only when you have established who will be approvers can you determine whether or not you need to create custom determinators.
Setting up e-mail Reminders

Virsa Access Enforcer uses e-mail messages to communicate with approvers. You can also configure Virsa Access Enforcer to send request progress notifications to interested parties, and reminders to approvers who have failed to act within a specified time period. The setup process is the same for both reminders and notifications, as shown in the following procedure.
X To Set Up an Email Reminder or Notification: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, click Workflow > Email Reminder.
Figure 7
The Email Reminder page appears, displaying the Reminder tab.

32
Figure 8 2
Reminder Tab of the Email Reminder Page
Click the tab appropriate to the message you want to define. If you want to define a reminder message, remain on the Reminder tab. If you want to create a submission notification message, click the Submission tab. If you want to create a request approved message, click the Closing tab.
In the Days field, enter the number of days after the event that Virsa Access Enforcer should wait before generating the message. Typically, this only applies to reminders. In most cases, notifications should be generated immediately upon submission or completion.
In the Subject and Comment fields, enter the desired text.
33
Figure 9 5
Email Reminder: Subject and Content
Under Notification Configuration select to whom you would like to send the reminder, and then click Save. You see the following success message:
Figure 10
Email Reminder Success Message
Auto Provisioning
Virsa Access Enforcer allows you to not only automate the collection of access approvals, but also to automatically launch the actual process of provisioning access. Autoprovisioning can be done either globally or, at a more granular level, by system.
Important Autoprovisioning from within Virsa Access Enforcer is optional. However, whether or not you choose to autoprovision, you need to ensure that you have configured this setting correctly.
If you want Virsa Access Enforcer to employ autoprovisioning, you must configure it to do so. How you configure Virsa Access Enforcer to autoprovision depends on whether or not your enterprise uses the SAP HR module:
If you do not use SAP HR, you must use Direct provisioning.
34
This method empowers Virsa Access Enforcer to directly modify the users master record, changing the users assigned permissions as defined in the Virsa Access Enforcer request.
If you do use SAP HR, you can use either Direct or InDirect provisioning. In InDirect provisioning, Virsa Access Enforcer sends a provision request to the SAP HR module, and it is SAP HR that performs the actual provisioning.
If you do not want Virsa Access Enforcer to launch the provisioning process, you must define this setting as Do Not Autoprovision.
X To Configure Global Settings for Autoprovisioning in Virsa Access Enforcer: 1
From the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Auto Provisioning.
Figure 11
The Provision Configuration page appears, displaying the Global tab.
35
Figure 12 2
Global tab of the Provision Configuration page
In the Auto Provisioning - Status area, select the appropriate status:
To begin provisioning when all of the workflow paths in the submitted request have been completely approved, select Auto Provision At End of Request. To provision the access requested for each path as the path is approved, select Auto Provision At End of Each Path. To turn off autoprovisioning, select No Auto Provision, and then click Save.
If you selected and saved No Auto Provision, you are finished with this task. Otherwise, continue.
3
In the Default Role Provisioning Type of the Auto Provisioning - Configuration area, select the either Direct or InDirect.
36
You should only select InDirect if your SAP environment includes the SAP HR module, and you want to use SAP HR to perform provisioning. Otherwise, you should select Direct. If you select InDirect, you must then select the type of HR object Virsa Access Enforcer needs to transmit to the HR module. There are three possible object types: Position, Orgtype, and Job.
4
In the Create if user does not exist drop-down list of the Auto Provision - Change Request area, select either Yes or No. This setting is used only for requests of type Change, and only where there is no record of the user.

Select Yes if you want the provisioning process to automatically create the user. Select No if you do not want the provisioning process to automatically create the user.
5 6
In the Provisioning - Old Roles Delimit Duration fields, enter a length of time for transitioning from an old position to a new position. In the Password Expiration for ORAAPPS area, select whether the password should expire after a certain number of days, a certain number of 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. In the Provisioning - Role Assignment area, select Yes for the provisioning to take place immediately, or No for the provisioning to take place at a later time. Click Save.
7 8 X
To Configure Autoprovisioning in Virsa Access Enforcer by System: 1
In the Provision Configuration page, click the By System tab. The By System configuration pane appears.
Figure 13
The By System tab of the Provision Configuration page.
37
Click Create. Dropdown lists appear at the bottom of the By System tab pane, from which you can make the following choices:

System - this is the system in which you want to enable autoprovisioning. Default Role Provisioning Type - there are two choices to select from: Direct and InDirect.
You should only select InDirect if your SAP environment includes the SAP HR module, and you want to use SAP HR to perform provisioning. Otherwise, you should select Direct. If you select Direct, the InDirect Provisioning Type dropdown list appears dimmed and you are unable to select an HR object type. If you select InDirect, you must then select the type of HR object Virsa Access Enforcer needs to transmit to the HR module from the Indirect Provisioning Type drop-down list.
Indirect Provisioning Type - There are three possible indirect provisioning types: Jobs, Position, and OrgType. Create user for change request - Select either Yes or No.
Select Yes if you want the provisioning process to automatically create the user and No if you do not want the user automatically created.
Immediate - Select either Yes or No.
Select Yes if you want the provisioning process to be in effect immediately, or No if you do not.
3
Click Save. You see the following success message:
Configuring the CUA System Setting

This setting applies only to SAP implementations that employ a Central User Administration (CUA) system. If your system uses a CUA, you need to identify the CUA host to Virsa Access Enforcer. If your system does not have a CUA, you need to ensure that this setting is not configured for a CUA.
X To Configure the CUA System Setting: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > CUA System.
38
Figure 14
The CUA System pane appears.
Figure 15 2
The CUA System Pane
In the Systems drop-down list of the Select System area, specify the correct CUA system.
If your environment uses a CUA system, select the CUA host from the list. For more information on CUA systems, see Configuring the CUA System Setting on page 29. If your environment does not use a CUA system, make sure that there is no host selected. The Systems drop-down list should show --Select-- in the field. Click Save.
If your system does not use a CUA, you are finished. If your system does use a CUA, continue.
3
In the Function Template fields of both the CUA User Provisioning Configuration area and the CUA Role Provisioning Configuration area, select either Standard or Custom. Most Virsa Access Enforcer users will select Standard here. You only need to select Custom if you have developed custom CUA BAPIs. If you are using custom BAPIs, you should contact Virsa Technical Support to ensure that your BAPIs integrate correctly with Virsa Access Enforcer.
39
If you select Custom in either area, the Function Template Name field appears in which you can type a name for your custom template.
4
Click Save.
Identifying the SMTP Server

Configuring Virsa Access Enforcer to use the correct mail server is fundamental for creating workflows. Virsa Access Enforcer communicates with approvers via e-mail messages. If this setting is not properly configured, the entire approval process will fail.
X To Configure the Virsa Access Enforcer SMTP Server: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > SMTP Server.
Figure 16
The SMTP Server pane appears.
Figure 17 2 3
The SMTP Server Pane
In the e-mail Server Name field, enter the name of the SMTP server that Virsa Access Enforcer will use to transmit messages. Click Save.
40
Creating New Workflows Chapter 2 Managing Workflows
Creating New Workflows

The following sections describe how to create a workflow or path. Each workflow defines how Virsa Access Enforcer manages the approval process for a specific access request. The procedure for creating the workflow itself is quite simple: you create a path, name it, determine its initiator and stages, and then activate it. Provided that the initiator and stages you need already exist in Virsa Access Enforcer, you can create a workflow in a couple of minutes. There are two issues, however, that make creating workflows a more involved process. First, you need to ensure that the initiators and stages you require exist in Virsa Access Enforcer. In some cases, you may be able to use default Virsa Access Enforcer objects to construct workflows, but you will also need to create your own custom stages, and you will definitely need to define your initiators. Initiators and stages are the building blocks you use to construct workflows, and you will need to define them before you actually define a path. The second issue you need to address before you begin creating workflows is more fundamental. Before you create the initiators and stages you want to use in your workflows, you need to identify them. You do this by planning your workflows outside of Virsa Access Enforcer before you begin to create them within it. These issues are discussed in greater detail in the section About Workflows on page 22.
Important Before you begin creating initiators, stages, and paths, you should plan not only individual workflows, but also a comprehensive approval strategy. Only when you have a good idea of the stages and initiators you will need should you begin creating these objects.
Once you are familiar with the Virsa Access Enforcer workflow concepts, and have created a strategy on which to base your workflows, you are ready to begin the definition process. You start by identifyingbased on your strategythe initiators you require, and then creating them in Virsa Access Enforcer. You can find the procedure for creating initiators in the section Creating Initiators on page 42. Next, you create the stages you need for your workflows. Again, identify these stages in your strategy before you create them in Virsa Access Enforcer. It is likely that at least some of the stages you require already exist as default Virsa Access Enforcer objects. Compare the stages you need with the stages you have available to you, and create any new ones that you need. You can find the procedure for creating stages in the section Defining Stages on page 44.
Note 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. The procedure for creating a path is described in the section Creating Paths on page 50. You can use these procedures to create all of your main workflows. Once you have done so, you can add escape routes to your workflows (see Configuring Escape Routes on
41
page 55) and create multi-path workflows, based on the applications included in the access request (see Creating Forked Workflows on page 58). The concepts underlying escape routes and forked workflows are described in greater detail in the section About Workflows on page 22.
Creating Initiators
Initiators are collections of request attributes that act as templates. When a user submits a request, Virsa Access Enforcer compares the attributes of that request to all active initiators. If the attributes of the request match the attributes of an initiator, Virsa Access Enforcer uses the initiator to trigger a workflow.
Important Each initiator must have a unique combination of attributes. While every submitted request should match one initiator, it should be impossible for a request to match more than one initiator.
To Create an Initiator: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Initiators.
Figure 18
The Initiators pane appears.

2
Click Create. The Create Initiator pane appears.
42
Figure 19 3
The Create Initiator Pane
In the appropriate fields of the Initiator area, give the new initiator a name, short description, and long description.
From the Workflow Type drop-down list, select a workflow type.

Note The Workflow Type option is available only if Virsa Access Enforcer is integrated with Virsa Compliance Calibrator or Virsa Role Expert and you have enabled the Workflow Types on the Miscellaneous Configuration page.
In the Attribute drop-down list, select an attribute to apply to the initiator. The attributes available for you to select are based on the workflow type you select. Each initiator must have at least one attribute, and typically two or more. Choose attributes that, when combined, match all requests that should trigger this initiator, and at the same time exclude requests that should trigger a different initiator.
Choose 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 choose to
43
give the attribute a value of Finance. Thus, in order 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 choose 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 (Functional Area = Finance) but also other attributes that you specify. If you select OR, a request needs to match either this attribute or any other that you specifybut not necessarily bothto trigger the initiator.
Figure 20 7 8
The Select Attributes Pane
Click Attributes to add the attribute and its value and condition to the initiator. 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.
When you have finished adding attributes, click Save. Virsa Access Enforcer saves the new initiator and you see the following success message:
Figure 21
Initiator Successfully Saved Message
You can create initiators as you need them to create workflows, but you may find it helpful to create several initiators at a time.
Defining Stages
There are two procedures for creating a stage:
Defining the stage The primary purpose of any stage is to pass a request on to a specific approver. Thus, when you create a stage, your basic task is to define the person who will be called upon to approve or deny a request when the request reaches that stage. When you define a stage, you specify the approver for that stage.
Configuring the stage There are various optional configurations you can add to a stage that allow you to specify notifications, require risk analysis, and manage security. When you configure a stage, you determine which of these options to apply.
44
To Define a Stage: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Stages.
Figure 22
The Work Flow Stages pane appears.

2
Click Create. The Stage Configuration page appears.
45
Figure 23 3
Stage Configuration page
In the Stage Details area of the Stage Configuration page, enter a name, short description and description for the new stage in the appropriate fields.
The name you give the stage must be unique.
46
From the Workflow Type drop-down list, select a workflow type for the stage.
From the Approver Determinator drop-down menu, select the determinator for the stage. It is important to select the correct determinator. Virsa Access Enforcer uses the determinator at runtime to derive the approver for the stage.
Note If you select No Stage as the Approver Determinator, the system automatically approves requests for certain roles. In other words, users can be provisioned with certain basic roles with no approval involved.
In the Request Wait Time fields, enter the amount of time you want Virsa Access Enforcer to wait at this stage for an approver to respond to a request. You only need to set wait time values 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.
From the Escalation Configuration drop-down list, select how you would like Virsa Access Enforcer to handle a request when an approver fails to respond within the time allotted during stage definition. There are four escalation options:
No Escalation (default setting) causes Virsa Access Enforcer to wait for the
expected response, even after the specified wait time passes. Virsa Access Enforcer does not take steps to resolve the stalled request. Either the designated approver approves or rejects the request, or an Virsa Access Enforcer administrator manually resolves the problem.
Forward to Next Stage causes Virsa Access Enforcer to ignore the expected approval at this stage, and proceed to the next stage in the path. If you select this option, the fact that the designated approver does not respond to the request wont prevent the request from being ultimately approved. Forward to Alternate Approver provides a fallback option if the designated approver does not respond within the time allotted. In this case, Virsa Access Enforcer reassigns the approver and restarts the wait time Forward to Administrator if the request is security based and the approver fails to respond within the time allotted.
Figure 24
Stage Successfully Created Message
47
At this point, you have created the stage, and can include it in one or more workflows if you choose. When you return to the Work Flow Stages pane, you see the new stage listed there. You can now proceed to configure the stage, if appropriate for your needs. There are three configuration areas:
Notification Configuration
Figure 25
Notification Configuration pane
Configure notification for a stage to determine whether and to whom Virsa Access Enforcer sends notifications about the actions taken at this stage. There are three possible actions:

The approver approves the request. The approver rejects or denies the request. The approver fails to respond to the request within the allotted wait time.
The users you select next to each possible action are notified when that action takes place. Additionally, you can compose a different, rich text or HTML message for each action you select, to accompany the notification. Simply click the tab that corresponds with the notification action you select and then type your message in the field provided.
48
Additional Configuration
Figure 26
Additional Configuration Pane
You use the operators in the Additional Configuration pane to refine the behavior of the stage. The Additional Configuration options available to you depends on the Workflow Type you select when initially defining your Stage. For more information on Workflow Types see Step 4 on page 43 of To Define a Stage:.
Additional Security Configuration (Approval Reaffirm)
Figure 27
Additional Security Configuration
The Additional Security Configuration pane allows you to specify whether the approver needs to confirm their identity to take an action at this stage. Approvers confirm their identitiesreaffirm their decisionsby entering their password at a prompt when they take an action. The actions that can be configured to require reaffirmation are:

Approval Rejection Creation of a new user
To Configure a Stage: 1
In the Work Flow Stages pane, click the name of the stage. The Stage Configuration pane for that stage appears. In the Notification Configuration area, define the notifications that Virsa Access Enforcer should generate at this stage. Select which users should receive e-mails for each possible action, and compose the message to accompany the notification.
In the Additional Configuration area, define any additional functionality required at this stage.
49
Some of the functionality you can configure for the stage includes:
Whether it is mandatory for the approver to perform a risk analysis before approving the request. Whether an approver has the authority to change the content of the request. Whether the approver has the authority to reject the request Whether all potential approvers at this stage must approve the request, or if only one approver is required to approve. Whether the approver has the authority to re-route the request to a previous stage as an alternative to rejecting the request entirely. Re-routing doesnt apply if the approver chooses to approve the request. Whether Virsa Access Enforcer should send a notification to an e-mail distribution list identifying the actions taken at this stage. Whether the approver has the authority to forward the request to someone else for approval. Whether the approver is required to enter comments when approving or denying the request.
In the Additional Security Configuration area, 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:

Approval Rejection Automatic creation of a new user record
Once you finish configuring the stage, click Save.
Creating Paths
At this point, you have already created and configured your initiators and stages. You are ready to begin creating your workflow paths. There are three different procedures associated with creating paths:
X
To Create a Main Path: on page 50 To Create a Detour Path: on page 52 To Add a Detour to a Main Path: on page 54
To Create a Main Path: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Path.
50
Figure 28
The Work Flow Paths pane appears.

2
Click Create. The Create Path area appears at the bottom of the pane.
Figure 29 3
The Create Path Area
Enter the details of the path in the fields provided:
Enter a name and description in the appropriate fields. The name of the path needs to be unique. It may also be useful to give the path both a name and a description that are intuitive to you. Give the path a Short Description. The short description appears in drop-down lists in different places throughout Virsa Access Enforcer as an option when you perform a query. The short description is limited to 20 characters. Give the path a Description. The description is longer than the short description and, therefore, can contain more detailed information. Select a Workflow Type.
The Workflow Type option is available only if Virsa Access Enforcer is integrated with Virsa Compliance Calibrator or Virsa Role Expert and you have enabled the Workflow Types on the Miscellaneous Configuration page.
Note
In the No. of stages field, enter the number of stages you want to include in the path. From the Initiator drop-down menu, select the initiator that will trigger the workflow to which the path belongs. Select the Active check box to make the path active upon successful save.
Make sure that the Detour check box is not selected. If you save the path with this check box selected, the path will be a detour. Even though you have selected an initiator, the path will not respond to request submissions.
Important
51
When you have finished entering these details, you will see a graphical representation of the path at the bottom of the pane.
o
Figure 30 4 Path Definition with Graphical Representation
Figure 31
Path Successfully Saved Message
When you return to the Work Flow Paths pane, you see the new path listed there.
Figure 32 X
Work Flow Paths Pane Displaying New Path
To Create a Detour Path: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Path.
Figure 33
The Work Flow Paths pane appears.

2
Click Create. The Create Path area appears at the bottom of the pane.
52
Figure 34 3
The Create Path Area
Enter the details of the detour path in the fields provided:
Enter a name and description in the appropriate fields. The name of the path needs to be unique. It may also be useful to give the detour both a name and a description that are intuitive to you. Give the path a Short Description. The short description appears in drop-down lists in different places throughout Virsa Access Enforcer as an option when you perform a query. The short description is limited to 20 characters. Give the path a Description. The description is longer than the short description and, therefore, can contain more detailed information. Select a Workflow Type. The only workflow type available here is Access Enforcer. In the No. of stages field, enter the number of stages you want to include in the detour path. Ensure that there is no value selected in the Initiator drop-down list. Select the Active check box to make the path active upon successful save. Select the Detour check box to specify that this path is a detour.
When you have finished entering these details, you will see a graphical representation of the detour path at the bottom of the pane.
Figure 35 4
Path Definition with Graphical Representation
Figure 36
Path Successfully Saved Message
53
When you return to the Work Flow Paths pane, you see the new path listed there.
X To Add a Detour to a Main Path: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Detour/Fork.
Figure 37
The Work Flow Stage Detour pane appears.
Figure 38 2
Work Flow Stage Detour Pane
Click Create to display the fields for configuring a detour from a main path.
Figure 39 3
Detour Configuration Fields
Enter the details of the connection between the main path and the detour path. Working from left to right:
54

Note
From the Path drop-down list, select the main path to which you wish to connect the detour. From the Stage drop-down list, select the stage of the main path from which the request should jump to the detour. From the Action drop-down list, select Save. From the Condition drop-down list, select the condition that must occur to execute the detour. From the Value drop-down list, select either Yes or No to specify whether the detour should execute in the presence of the condition defined in the fourth drop-down list, or in its absence. If you select Yes, the detour will execute only when the specified condition occurs. If you select No, the detour will execute only when the condition does not occur.
From the Detour Path drop-down list, select the detour path to which you wish to connect the main path.
Figure 40 4
Detour Configuration Fields with Detour Configuration Data
Click Save. You see a success message, and the detour configuration is listed in the Work Flow Stage Detour pane.
Figure 41
Detour Successfully Created Message
Configuring 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 the escape route is to prevent a request from being trapped in an irreconcilable situation. When you configure a stage, you can specify the amount of time that a request should wait at that stage for a response from the designated approver. You can configure the stage to take action if the approver does not respond within that time frame, even if the
55
specified action is to continue to wait for a response. Even though the request is not currently progressing through the workflow, the workflow has been instructed how to handle the situation. This is not true, however, if Virsa Access Enforcer cannot derive who is the correct approver. In this situation, Virsa Access Enforcer cannot send the approval request. The wait time and escalation actions never take effect, because they depend on the timestamp of the approval request sent to the approver. Thus, if a request arrives at a stage and Virsa Access Enforcer cannot derive the approver, the request is trapped, and the escalation mechanism cannot resolve the problem. This is the purpose of the escape route. If Virsa Access Enforcer generates an Approver Not Found error for a workflow that has a configured escape route, receipt of that error causes the escape route to execute. The escape route causes the request to skip at least one stagethe current oneand continue its progress along the workflow path. When you create the escape route, you determine how many stages the request should skip. From there, the workflow manages the request as if the request has been approved to that point in the path.
Note Because passing on a request that has not actually been approved at the first stage may 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.
To Configure an Escape Route: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Escape Route.
Figure 42
56
The Escape Routes pane appears.
Figure 43 2
The Escape Routes Pane
In the Escape Route - Conditions area, specify the details of the escape route:

Note
The Condition drop-down list displays Approver Not Found. This is the only condition that triggers an escape route, and you cannot change this value. From the Path drop-down list, select the path (or workflow) for which you wish to define an escape route. From the Stage drop-down list, select the first stage in the path.
From the Escape Routing Enabled drop-down list, select Yes.
Figure 44 4
Escape Routes Pane with Defined Escape Route
Click Save.
57
You see the following success message.
Figure 45
Successfully Saved Escape Route Configuration Message
Creating Forked Workflows

In most cases, we use the terms workflow and path interchangeably. This is 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. Virsa Access Enforcer provides forked workflows to manage requests for access to both SAP and non-SAP applications. You create a workflow fork if:
You have created a single workflow and initiator that can be triggered by an access request for either an SAP or a non-SAP application (or both) and
You want Virsa Access Enforcer 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 different application type. However, having 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 wish to create includes paths that do not exist, you need to create the paths before you can create the fork.
58
You can find the procedure for creating a main path in the section To Create a Main Path: on page 50, and the procedure for creating a detour path in the section To Create a Detour Path: on page 52.
X To Create a Forked Workflow: 1
In the navigation menu of the Virsa Access Enforcer Configuration tab, select Workflow > Detour/Fork.
Figure 46
The Work Flow Stage Detour pane appears.

2
Click the Fork Path tab.
Figure 47 3
Fork Path tab of the Work Flow Stage Detour Pane
Click Create to display the drop-down lists for configuring a workflow fork.
Figure 48
Workflow Fork Configuration Fields
59
Enter the details of the fork. Working from left to right:

From the Workflow Type drop-down list, select a workflow type. From the Initiator drop-down list, select the main path on which you wish to base the fork. From the Action drop-down list, select Save. From the Condition drop-down list, select the condition that must occur to execute the forked path. From the Value drop-down list, select either Yes to specify if the workflow should occur in the presence of the condition defined in the third drop-down list, or No to specify if the workflow should fork in its absence. If you select Yes, the request will follow the fork only when the specified condition occurs. If you select No, the request follows the fork only when the condition does not occur.
From the Fork Path drop-down list, select the alternative path you want to join to the primary path in order to form the fork.
Figure 49 5
Workflow Fork Configuration Fields with Configured Fork
Click Save. You see a success message, and the new fork is listed in the Path Fork tab of the Work Flow Stage Detour pane.
60
3
SETTING UP VIRSA ACCESS ENFORCER
TOPICS

About Setting Up Virsa Access Enforcer Initial Login to Virsa Access Enforcer Mapping Virsa Access Enforcer Roles Where to Start Initializing the System DataInitialize DB Defining Connectors Using Connectors Defining User Data Source Defining Request Configuration Configuring Request Types Configuring Request Priorities Configuring Applications Configuring Employee Types Defining Number Ranges Defining Available Request Attributes Defining the Requestor Authentication Source Defining Approvers Defining Security Leads Defining Points of Contact Defining Application Approvers Setting Up Risk Analysis Setting Mitigation 61
Identifying Technical Support Contacts Setting Up the Service Level Period Configuring Roles Importing Roles Creating Roles Searching Roles Selecting Roles Configuring Default Roles Mapping Roles Enabling and Removing Role Mappings Defining Attributes Reaffirming a Role Managing User Defaults Configuring User Defaults Setting User Default Mapping Selecting a User Default System Monitoring Virsa Access Enforcer Viewing the System Log Viewing the Application Log Configuring HR Triggers Creating Actions Creating Rules Configuring Field Mapping Viewing the Process Log Setting Up LDAP Mapping Defining Password Self Service Setting Up Background Jobs Creating Custom Fields Miscellaneous Configuration Configuring the Language Configuring the Log Level Configuring the Cache Job Interval Configuring the Background Job Interval
62
About Setting Up Virsa Access Enforcer Chapter 3 Setting Up Virsa Access Enforcer
About Setting Up Virsa Access Enforcer

Before using Virsa Access Enforcer, you need to create a usable environment for requestors and approvers who are the end-users. As an Administrator, you have the ability to configure Virsa Access Enforcer in a way that best meets your business requirements. It is vital that you gather all essential information before proceeding to set up Virsa Access Enforcer. Virsa Access Enforcer is a flexible tool that allows you to modify your configuration at any time to reflect your current business model. However, it is imperative that you correctly configure Virsa Access Enforcer before using it in a production environment.
Initial Login to Virsa Access Enforcer

After installing Virsa Access Enforcer on an SAP NetWeaver Server, use a web browser to login and access Virsa Access Enforcer. Typically, the URL address is: http://<server_name>:<port_ number>/AE where the NetWeaver server by default runs on port number, 50000. The SAP System Administrator should be able to provide you with the address if you login within the company firewall.
Important The administration roles are defined in User Management Engine (UME). Use the appropriate administrator credential to log in.
Mapping Virsa Access Enforcer Roles

When defining Virsa Access Enforcer roles it is best that you map the roles with the existing SAP roles listed in the User Management Engine (UME). The UME is the SAP Security tool for managing access to NetWeaver environment. You can log in to UME by using the URL address: http://<server_name>:<port_ number> This is the SAP NetWeaver Server Index Page. Click User Management. The following are the roles that Virsa Access Enforcer provides out-of-the-box, however, you can create or modify these roles according to your business practices:

AEADMIN AEApprover AESecurity
63
Where to Start
Based on real-world implementations, it is recommended that you set up the components in Virsa Access Enforcer in the following order:

Initializing the System DataInitialize DB Defining Connectors Defining Request Configuration Defining Request Numbering Defining Available Request Attributes Defining the Requestor Authentication Source Defining the User Data Source Defining Approvers Setting Up Risk Analysis Defining Mitigation Defining Attributes Identifying Technical Support Contacts Setting Up the Service Level Period Defining Available Role Attributes Defining Password Self-Service Setting Up Background Jobs Creating Custom Fields
64
Initializing the System DataInitialize DB Chapter 3 Setting Up Virsa Access Enforcer
Initializing the System DataInitialize DB

You can import initial system data in .xml file format and then download it into Virsa Access Enforcer. You do this by using the Initial System Data option. You can also use the Initial System Data option to load new or modified system data. Once the data is loaded, you can verify it by using the Request Configuration option.
X To Initialize System Data: 1
In the navigation menu of the Configuration tab, select Initial System Data. The Initialize DB page appears.
Figure 50 2 3
Initial DB page
In the File Name field, type the name of the .xml file or click Browse to navigate to the file. Select the Insert option the first time you import an .xml file. Otherwise, select the Append option to add information to an existing file or enable the Clean and Insert option to overwrite any existing .xml files with new or modified system data. Click Import.
65
Exporting System Data

You can export system data in .xml file format to other Virsa Access Enforcer instances. You do this by using the Initial System Data option.
X To export System Data: 1
From the navigation menu of the the Configuration tab, select Initial System Data. The Initialize DB page appears.
Figure 51 2 3
Initial DB page
Under Export Data, select the desired system data name. Click Export.
66
Defining Connectors Chapter 3 Setting Up Virsa Access Enforcer
Defining Connectors
One of the first things you need to do after installing Virsa Access Enforcer, is configure the interactions with the appropriate database(s) within your backend systems. Virsa Access Enforcer can connect to a Lightweight Directory Access Protocol (LDAP) and/or an SAP business system.
Using Connectors
Connectors facilitate the transfer of data between Virsa Access Enforcer and SAP systems, LDAP, and/or Oracle Applications (server), systems. By setting up the connectors, you specify how you want to Virsa Access Enforcer to communicate with these backend systems. Once you have defined a connector, Virsa Access Enforcer allows you to:

Import SAP Roles Search on users or roles Authenticate User ID
Virsa Access Enforcer supports multiple LDAPs. They include:

X
Microsoft Active Directory Sun Microsystems SunOne Novell E-Directory IBM Tivoli
To Configure Connectors for SAP: 1
From the navigation menu of the Configuration tab, select Connectors > Create SAP. The Connectors page appears. Initially, the Connectors page contains no connector information.
67
Figure 52
Note
Create SAP Connectors Page
Any field name denoted with an asterisk (*) indicates that it is a mandatory field.
Enter connection information in the following fields.

Important You will need your Network Administrator and BASIS Administrator to provide connection information in completing the Connectors page
Table 1
Fields
SAP Connection Fields

Description
Name Short Description
The SAP connector name. Note, this name will appear to the end-user as the system name. This is a short description of the connector that appears in drop-down lists throughout Virsa Access Enforcer wherever its appropriate to select a connector. This field is limited to 20 characters. The longer, more informative description of the new SAP connector. The name of the application or application server, which is the system name that you would use when configuring for an RFC. This is the host name of the application server. This is the number in the SAP system log.
Description Application
Application Server Host System Number
68
Table 1
Fields
SAP Connection Fields (Continued)

Description
Client User Id Password System Language Message Server Name Message Server Group Message Server Host SAP Version HR System SLD Connector (check box) Connector Category Role
This is the SAP client. This is the SAP user name. This is the password for the SAP user The BASIS administrator will provide this information. This is the name of the message server, which is used for load balancing of your SAP clustered environment. This is the group to which the message server belongs. Your BASIS administrator will provide this information. This is the host name of your message server. Your BASIS administrator will provide this information. Use the drop-down list to select the appropriate SAP version. Virsa Access Enforcer only supports SAP 4.5b and higher. Use the drop-down list to select Yes or No to indicate if an SAP HR system is used or not. Select this checkbox to enable the Standard Landscape Directory. Select the category to which the connector belongs.
Role Expert or the SAP Backend.
Select whether or not role information comes from Virsa
Click Create.
Important Once you have created the new connector, click Test Connection to ensure that the connection is valid.
To Configure Connectors for LDAP: 1
From the navigation menu of the Configuration tab, select the Connectors > Create LDAP. The Connectors LDAP page appears.
69
Figure 53
Note
Create LDAP Connectors page
Any field name denoted with an asterisk (*) indicates that it is a mandatory field. You will need your Network Administrator and BASIS Administrator to provide connection information to complete the LDAP Connectors page.
Important
Table 2
Fields
LDAP Connector Fields

Description
Name
This is the LDAP connector name. Note, this name will appear in Virsa Access Enforcer. It is a virtual name to your system. This is a short description of the connector that appears in drop-down lists throughout Virsa Access Enforcer wherever its appropriate to select a connector. This field is limited to 20 characters. This is the description of the new LDAP connector. The name of the LDAP server. The domain name of where all the tables containing the role types, codes, and other details are located. The number of the LDAP port. This is the user name to access this connection. This is the password to access this connection. This is a directory path specific for the User. This is a directory path specific for Group.
Short Description
Description Server Name Domain Port User Principal Name Password User Path Group Path
70
Table 2
Fields
LDAP Connector Fields (Continued)

Description
LDAP Type Password Encryption Connector Category
Use the drop-down list to select either Sun One or Active

Directory.
Use the drop-down list to select the type of encryption to apply to the connector password. Use the drop-down list to select either Production, or NonProduction connector type. This selection is used to help classify the servers into the appropriate categories in the Access Request forms.
Click Create.
To Configure Connectors for Oracle Applications: 1
From the navigation menu of the Configuration tab, select Connectors > Create ORAAPPS. The Connectors ORAAPPS page appears.
Figure 54
Note
Create ORACLE APPS Connectors Page
Any field name denoted with an asterisk (*) indicates that it is a mandatory field. You will need your Network Administrator and Oracle DBA to provide connection information to complete the Connectors page.
Important
71
Table 3
Fields
Oracle Apps Connector Fields

Description
Name
This is the Oracle Application Server connector name. Note, this name will appear in Virsa Access Enforcer. It is a virtual name to your system. This is a short description of the connector that appears in drop-down lists throughout Virsa Access Enforcer wherever its appropriate to select a connector. This field is limited to 20 characters. This is the description of the new Oracle Application Server connector. The name of the Oracle Application Server. The Oracle System Identifier (SID) refers to the instance of the Oracle database running on the server. This property is mutually exclusive with the ServiceName property. The default is ORCL, which is the default SID that is configured when installing your Oracle database. The number of the Oracle port. This is the user name to access this connection. This is the password to access this connection.
Short Description
Description Host SID
Port User ID Password
Click Create.
72
Defining User Data Source Chapter 3 Setting Up Virsa Access Enforcer
Defining User Data Source

Use the User Data Source option to increase the scope of SAP backend systems that you configured in the Connectors page. The User Data Source page is where you define the primary source for extracting user data. Mapping the data source allows Virsa Access Enforcer to search for all users, managers, and approvers. However, it is important to 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, there is no need to perform any additional configuration for mapping the User ID. Virsa Access Enforcer 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 fetch additional information of the user.
X To Configure the User Data Source: 1
From the navigation menu of the Configuration tab, select User Data Source. The User Data Source page appears.
Figure 55 2 3 4 5
User Data Source page
From the Data Source Type drop-down list of the Search Data Source pane, select a data source. Possible data source types include SAP, SAPHR, SAPUME, and LDAP. From the System Name drop-down list, select the appropriate system. Click Save. From the Details Source Type drop-down list, of the User Details Data Source pane, select the data source type. Available data source types include SAP, SAPHR, SAPUME, and LDAP. From the System Name drop-down list, select the appropriate system.
73
From the Function Template drop-down list, select to use a custom or standard template.
Note If you select Custom from the Function Template drop-down list, the Function Template Name field appears, in which you can type a name for the custom template.
Click Save.
Note Using UME as the User Data Source: The SAP User Management Engine (UME) is the most common data source to find User and Approver data in an enterprise portal environment or when UME is used 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 Virsa Access Enforcer. 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.
74
Defining Request Configuration Chapter 3 Setting Up Virsa Access Enforcer
Defining Request Configuration

The Request Configuration option allows you to customize the Request page. Customize, in this case, means defining the fields you want to appear. You can customize Request Types, create a new Request Category, Request Reason, and provide a range of values that will appear when a New Request is made. The Request Configuration page contains configuration tabs for request creation you must define to meet the range of request cases that are entered in your system. The configuration values are dependent on your business requirements. The Request Configuration page includes:

Configuring Request Types Configuring Request Priorities Configuring Applications Configuring Employee Types
Configuring Request Types

The Request Type tab allows you to configure the request type(s) that an end-user specifies during the request process. Request types are reference points for initializing a workflow. Virsa Access Enforcer provides a standard set of Request Types that cannot be deleted. These Request Types are:

New Change Delete Lock Unlock
These standard Request Types represent some actions that occur in the SAP backend systems. For example, if the Request Type is New, it relates to the creation of a new account in the SAP backend system. You can also create custom Request Types for your business needs. You can also use the Request Type as an attribute in the Initiator/ Workflow selection process.
Note The standard set of Request Types in Virsa Access Enforcer is loaded during the installation process from an XML basic configuration file.
75
To Create a Custom Request Type: 1
From the navigation menu of the Configuration tab, select Request Configuration > Request Type. The Request Configuration Request Type page appears.
Figure 56 2
Request Type page
Click Create. The Create Request Type pane appears beneath the Request Type pane.
Figure 57
Note
Create Request Type pane
In the Type column, enter the name of the new request type.
76
In the Short Desc field type a short description of the request type.
Note The information you type into the Short Desc field appears in dropdown lists throughout Virsa Access Enforcer when you perform a query. The information you provide in this field is limited to 20 characters.
5 6
In the Description field, type the description of the new request type. In the Sequence Order field, type the sequence number. Assigning a sequence order value to request types defines the order in which request types appear on the Request Access page.
Note If you assign the number 0, the request type will not appear on the Request Access page.
Figure 58 7
Request Access Page
From the WorkfFlow Type drop-down list, select a workflow type.

8 9
To make the request type active, click the Active check box. In the End User Description field, type a description of the request type.
10 Click Save.
77
To Change a Custom Request Type: 1 2 3
In the Request Configuration page, select the Request Type you wish to change. Click Change to modify the selected Request Type. The request type name and description fields become active. Make your modifications. Click Save.
Configuring Request Priorities

You can create a priority for a request, which will determine how quickly a request is approved. The Priority tab allows you to create and maintain priorities that are used during the request creation process. The Priority option allows a manager to oversee the processing functions of a specific organization 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, keep in mind that it is a mandatory field, which the end-user will use when defining the request. Therefore, this priority attribute will affect the workflow by the determining the time rate for the approval process. Additionally, the priority attribute can determine where to route a request to the appropriate group of approvers.
X To Create a Request Priority: 1
From the navigation menu of the Configuration tab, select the Request
Configuration > Priority.
The Request Configuration Priority page appears.
Figure 59 2
Priority pane
Click Create. The Create Priority pane appears beneath the Priority pane.
78
Figure 60
Note
Create Priority pane
3 4
In the Priority field, type the name of the new priority. In the Short Desc field, type a short description of the new priority.
Note The information you type into the Short Desc field appears in dropdown lists throughout Virsa Access Enforcer when you perform a query. The information you provide in this field is limited to 20 characters.
5 6 X
In the Description field, type the description for the new priority. Click Save.
To Change or Delete a Request Reason: 1
In the Priority page, select the Priority you wish to change and then click Change. The Modify Priority pane appears.
Figure 61 2 3
Modify Priority pane
Make your modifications. Click Save.
Configuring Applications
The Application Configuration tab allows you to add selection options for non-SAP systems, which appear as part of the Access Request approval process. It also lists all SAP systems (in a read-only mode). Once you define an application, the end-user will see the listed application name and description when using the Search function to find available applications. Upon selection, the end-user can submit a request for a non-SAP system.
X To Configure an Application: 1
From the navigation menu of the Configuration tab, select Request Configuration > Application Configuration.
79
The Request Configuration Application Configuration page appears.
Figure 62 2
Application Configuration pane
Click Create. The Create Application pane appears beneath the Application Configuration pane.
Figure 63
Note
Create Application pane
3 4
In the Application field, enter the name of the new application. In the Short Description field, type a short description of the new application.
5 6 7
In the Description field, enter the description for the new application. In the System ID field, enter the system identification for the application. In the Client field, enter the client credentials for the application.
80
8 X
Click Save.
To Change an Application Configuration: 1 2
In the Application Configuration page, select the application name you wish to change. Click Change to modify the selected application. The Modify Application pane appears beneath the Application Configuration pane.
Figure 64 3
Modify Application pane
Make your modifications and then click Save.
Configuring Employee Types

The Employee Type Configuration tab allows you to define an employment status for an end-user. This feature allows you to set up business rules that differentiate between employee types, such as Full-Time from Part-Time employees, or employees of Division A from 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. You can use this attribute when creating a report. Once you have configured an employee type, the name will appear in a drop-down selection list in the Access Request page.
X To Configure an Employee Type: 1
From the navigation menu of the Configuration tab, select Request Configuration > Employee Type Configuration. The Request Configuration Employee Type Configuration page appears.
81
Figure 65 2
Employee Type Configuration pane
Click Create. The Create Employee Type pane appears.
Figure 66 3 4
Create Employee Type pane
In the Employee Type field, type the name of the new employee type. In the Short Description field, type a short description of the employee type.
5 6 X
In the Description field, type the description for the new employee type. Click Save.
To Change an Employee Type: 1 2
In the Employee Type Configuration page, select the Employee Type you wish to change or delete. Click Change to modify the selected Employee Type.
82
Defining Number Ranges Chapter 3 Setting Up Virsa Access Enforcer
The Modify Employee Type pane appears.
Figure 67 3
Modify Employee Type pane
Make your modifications and then click Save.
Defining Number Ranges

The requests in Virsa Access Enforcer are uniquely identified through a system of distinct numbers. You use the Number Ranges option to define a range of unique request numbers. Virsa Access Enforcer uses these numbers for invoices or identification.
Important It is important to create multiple Number Ranges that map to your business requirements, however, make sure that individual ranges do not overlap. For example, do not have a number range with 1001000 and another range with 500 2000.
To Configure the Number Ranges: 1
From the navigation menu of the Configuration tab, select Number Ranges. The Number Ranges page appears.
Figure 68
Number Ranges page
83
2 3 4 5 6
Click Create. Two empty fields appear under the From Number and To Number columns. In the From Number field, enter the starting number. In the To Number field, enter the ending number. Click Save. Click the Match icon to activate the new number range.
If there is a request number that is currently used, then the number will appear in the Current Number field.
X To Change a Number Range: 1 2 3 4
In the Number Ranges page, select the range of numbers you wish to change. Click Change to modify the number range. The From Number and To Number fields become active. Make the appropriate change to the number range. Click Save.
Note You can have only one number range active at one time. You may want multiple number ranges, for instance, when you want to differentiate requests between a production or development environment, or to have different number ranges for a fiscal period. Virsa Access Enforcer does not activate the number ranges automatically. You must activate the number range after a number range has reached it last invoice number.
Defining Available Request Attributes

The Attributes page provides a standard list of attributes that the end-user can select as part of the access request process. Use the Attributes option to select attributes to appear in the Access Request page (listed in the drop-down list or text field). Attributes provide the end-user with the convenience to accurately input of valid information when requesting access.
Note The standard list of Attributes is very basic in every business model. There should be no reason to 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.
To Configure Attributes: 1
From the navigation menu of the Configuration tab, select Attributes. The Attributes page appears. In this page, the standard Attributes list is displayed. Ensure that all Enabled checkboxes are selected.
84
Defining the Requestor Authentication Source Chapter 3 Setting Up Virsa Access Enforcer
Figure 69 2 3
Attributes page
Click Save. To disable an attribute, de-select the corresponding checkbox and then click Save.
Defining the Requestor Authentication Source

The Authentication option verifies the Requestors identity from the selected system. After you have set the Connectors and Authentication attributes, Virsa Access Enforcer will confirm the User ID and password that the Requestor uses during login.
Note The Approver are always authenticated and authorized using User Management Engine (UME).
To define Authentication: 1
From the navigation menu of the Configuration tab, select Authentication. The Authentication System page appears.
Figure 70
Authentication System Page
85
In the Authentication System field, click on the drop-down list to select the appropriate authentication system. The selections are SAP, SAP UME, LDAP, and SAPHR. In the System Name field, click on the drop-down list to select the appropriate system name. This list is populated with the valid values. Select the End User Verification Required checkbox to make the verification mandatory. Click Save.
3 4 5 X
To define Multiple LDAP Authentication: 1
From the navigation menu of the Configuration tab, select Authentication. The Authentication System page appears.
Figure 71 2 3
Authentication SystemAccess Requestors for Multiple LDAP Page
In the Authentication System drop-down list, select MULTIPLE LDAP. Order the sequence of LDAPs you want authenticated by clicking on the drop-down list and selecting the number 1 to 9, where one (1) is the highest and zero (0) is to deselect.
Note Select the End User Verification Required box to enable the verification of a user ID.
Click Save.
86
Defining Approvers Chapter 3 Setting Up Virsa Access Enforcer
Defining Approvers
The Approvers option allows you to define a User ID as a primary approver. You can define the primary approver in the following three categories:

Defining Security Leads Defining Points of Contact Defining Application Approvers
The Approvers that you define with this option will be part of the workflow approval process. This option also allows you define an alternate Approvers, which is used for workflow escalation process. Make sure that the User IDs for the approver and alternate exist in whatever Data Source that you have configured.
Defining Security Leads

The Security Lead option allows you to define a group e-mail address, a primary Security Lead, and alternate Security Lead. The Security Lead is a standard Approver Determinator that is available for selection during the creation of any stage.
X To Configure a Security Lead: 1
From the navigation menu of the Configuration tab, select Approvers > Security Lead. The Security Lead Approvers page appears.
Figure 72 2 3
Security Lead Approver page
In the Group Email Address field, enter the security group e-mail address. 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. In the Alternate Approver ID field, enter the User ID you want to assign as the alternate Security Lead. Click Save.
4 5
87
Defining Points of Contact

Once you have defined a Functional Area, you can then assign a Point of Contact (POC) Approver to this business module. The Point of Contact option allows you to map a Functional Area to a User ID, designated as the primary contact, and an alternate approver. The Functional Area is one of the standard fields on the Access Request page. During the request access process, when the end-user 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. The list of Functional Areas (in the drop-down list) can be configured in the Roles>Attribute page.
X To Configure a Point of Contact Approver: 1
From the navigation menu of the Configuration tab, select Approvers > Point of Contact. The Point of Contact, Approver Information page appears.
Figure 73 2
Point of Contact, Approver Information page
Click Create. At the bottom of the Functional Area column, a drop-down list is activated and two empty fields appear under the Point of Contact and Alternate Point of Contact columns.
Figure 74
Create Point of Contact fields
88
Defining Approvers Chapter 3 Setting Up Virsa Access Enforcer
3 4
In the Functional Area column, select a functional area from the drop-down list. In the Point of Contact column, enter the User ID to assign a primary POC Approver. You can click the Search icon to query for the desired User ID. icon to query for the desired User ID. In the Alternate Point of Contact column, enter the User ID to assign the alternate POC Approver. You can click on the Search Click Save.
6 X
To Change a POC Approver: 1 2 3
In the Point of Contact page, select the POC Approver you wish to change. Click Change to modify the selected POC Approver. The primary POC Approver name and alternate POC Approver fields become active. Make your modifications. Click Save.
Defining Application Approvers

You use the Application Approvers option to define the primary approver and alternates. The Application Approver is a standard Approver Determinator that is available for selection during the creation of any stage. The list of Applications (in the drop-down list) was previously configured in the Request
Configuration page.
To Configure an Application Approver: 1
From the navigation menu of the Configuration tab, select Approvers > Application. The Application Approver, Approver Information page appears.
Figure 75
Application Approvers page
89
2 3 4
Click Create. A drop-down list and two empty fields become active under the Application, Approver ID, and Alternate Approver ID fields. From the Application drop-down list, select the desired application. In the Approver ID field, click the Search ID as the primary approver. icon to query for the appropriate user icon to query for the
5 6 X
In the Alternate Approver ID field, click the Search appropriate user ID of the secondary approver. Click Save.
To Change an Application Approver: 1 2 3
In the Application Approver page, select the application name you wish to delete or change. Click Change to modify the selected application name. The Application Name and Approver ID fields become active. Click Save.
Setting Up Risk Analysis

The Risk Analysis option allows you to select the options for performing the actual Risk Analysis. You can identify the level of risk analysis and specify the Compliance Calibrator version for processing risks.
X To Configure Risk Analysis: 1
From the navigation menu of the Configuration tab, select Risk Analysis. The Risk Analysis page appears.
90
Setting Up Risk Analysis Chapter 3 Setting Up Virsa Access Enforcer
Figure 76 2
Risk Analysis page
In the Select Options pane, in the Default Analysis Type field, use the drop-down list to select the analysis type. There are two types:

Transaction Level This type is used to find conflicts among roles (in SAP). Object Level This type is used to find conflicts at the data level (permission or
policies).
3 4 5
Select the Consider Mitigation Controls option to consider the mitigation controls before performing risk analysis. Click Save. In the Select Compliance Calibrator Version pane, from the Version drop-down list, select the version of Compliance Calibrator.
Note There are two selectable versions of Compliance Calibrator. If you select 5.0 Web Service, three additional fields appear (URI, User Name, and Password). For the URI field, you need to navigate to the SAP NetWeaver Web Application Server Home page > Web Services Navigator > CCRiskAnalysisService > WSDLs > Standard link of Document, where you will see a list of all web services in the server. Select the desired URI address. If you select Compliance Calibrator 4.0, there is no need to connect to a URI address.
6 7 8 9
In the URI field, enter the appropriate URI address for the web services. In the User Name field, enter your User ID. Your User ID must have security access to web service. In the Password field, type your password. Select the Perform Org Rule Analysis option to perform org. rule analysis at risk analysis time.
91
10 Click Save. 11 In the Risk Analysis on request submission pane, from the Perform Risk Analysis
on request drop-down list, select either Yes or No to enable or disable automatic
risk analysis upon submission of a request.

12 Click Save.
Setting Mitigation
The Mitigation option allows an Approver to approve a request when SOD violations are found during Risk Analysis. If this option is not enabled, the Approver cannot approve the request if role conflicts are discovered. At this point, the Approver can either reject some roles and perform Risk Analysis again to check for violations or mitigate the existing violations to proceed.
X To Configure Mitigation: 1
From the navigation menu of the Configuration tab, select Mitigation. The Mitigation, Select Options page appears.
Figure 77 2 3 4 5 6 7
Mitigation page
De-select the Allow Approvers to approve access despite conflicts check box to enable mitigation control. In the Default Duration (in days) for the Mitigation Control field, enter the number of days you want the mitigation control to be active. In the Mitigation URI field, enter the URI address of the system that contains mitigation controls. In the Risk Search URI field, enter the URI address of the system used for searching risk violations. In the Org Rule Search URI field, enter the URI address of the system used for searching org. rules. Click Save.
92
Identifying Technical Support Contacts Chapter 3 Setting Up Virsa Access Enforcer
Identifying Technical Support Contacts

The Support option allows you to define a primary contact person for Virsa Access Enforcer, including e-mail and phone information.
X To Define Contact Information: 1
From the navigation menu of the Configuration tab, select Support. The Support page appears.
Figure 78 2 3 4 5 6
Support page
In the Contact Information pane, in the System Administrator field, type the User ID of the primary contact person. This person is usually a system administrator. In the Email Address field, enter the e-mail address of the contact person. In the Phone field, enter the phone number of contact person. Click Save. In the Support pane, in the File Name field, type the URL of the technical support Web page you would like to import. After importing, this technical support page is accessed by clicking Support on the initial Virsa Access Enforcer page.
93
Figure 79
Initial Virsa Access Enforcer page
Setting Up the Service Level Period

The Service Level option allows you to set the time frame for a task to be completed. Service level agreements can be between departments in an organization or between external users.
Note Service Levels, in general, are useful data points for generating performance reports (Service Level for Requests report).
To Configure a Service Level: 1
From the navigation menu of the Configuration tab, select Service Level. The Service Levels page appears.
94
Setting Up the Service Level Period Chapter 3 Setting Up Virsa Access Enforcer
Figure 80 2
Service Levels page
Click Create. The Create Service Level page appears.
Figure 81 3
Create Service Level page
In the Name field, type the name of the service.
95
In the Short Description field, type a short description of the service.

5 6
In the Description field, enter the description of the new service. In the Workflow Type field, select a workflow type.
7 8 9
In the No. of Days field, enter the number of days in which this new service must be processed. From the No. of Hours drop-down list, select the number of hours in which this new service must be processed. From the Attribute drop-down list, select an attribute.
10 From the Value drop-down list, select a value. 11 From the Condition drop-down list, select a condition. You can select OR, NOT, or
AND value logical operators for the selected attribute.

12 Click Add Attributes. The attributes are displayed in the Service Level Details
pane.
13 Repeat Steps 6 through 9 for each attribute you want to add to the Service Level
Details List.
14 Click Save. X To Change a Service Level: 1 2 3
In the Service Level page, select the service level you wish to change. Click Change to modify the selected service level. The days and hour fields become active. Make your modifications. Click Save.
96
Configuring Roles Chapter 3 Setting Up Virsa Access Enforcer
Configuring Roles
The Roles option allows you to configure Roles within Virsa Access Enforcer. A role is a key component in accessing information for the end-users to perform their jobs. A role can be specific to an individual end-user or a group of users. The role description must match their specific tasks for accessing information or application systems. The Role option provides the following:

Importing Roles Creating Roles Searching Roles Selecting Roles Configuring Default Roles Mapping Roles Enabling and Removing Role Mappings Defining Attributes
Importing Roles
Virsa Access Enforcer provides several methods to load roles. One of these methods is to import the roles from an SAP business system. Another method is to import roles from a spreadsheet file (.xls) on yours or another system.
Note When importing roles, it is best to load only the roles that you need. Importing a large number of roles can be overwhelming when scrolling through roles to find the appropriate one. Also, deleting roles can be time consuming, when thousands of roles are in one system.
To Import Roles: 1
from the navigation menu of the Configuration tab, select Roles > Import Roles. The Import Roles page appears.
97
Figure 82 2 3 4
Import Roles page
From the System drop-down list, select the system that contains the roles you want to import. From the Role Source drop-down list, select to import roles from the SAP backend, or from Virsa Role Expert. Select the appropriate setting in which to import your roles:
All Roles Use this setting to import all the roles from the specified system,
which includes all predefined roles.
All Roles Except SAP Predefined Roles Use this setting to import all the roles except any predefined roles within the specified SAP system. Selected Roles Use this setting for individual roles. You should know the role names you want to import. Enter the roles one at time in the Role Name field. From File Use this setting to load roles from a spreadsheet. This file can be on your local host or another system. You can use Browse to navigate to the appropriate file.
5 6
Select the Overwrite Existing Roles option to overwrite any existing roles of the same name as those you import. Click Import.
98
To Download a the Role Import Template:
You can downlownload a spreadsheet (.xls) template to your local system to use for importing roles into Access Enforcer. After downloading the spreadsheet, populate the fields with your own roles and then import the information into Access Enforcer.
Note It is highly recommended 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 within the template. Do not modify the sheet name and header names. When importing roles, use uppercase for the role name. Virsa Access Enforcer is case-sensitive. The Business Process and Sub-Process also need to be associated with the role. Business Process, Sub-Process, Functional Area, Company, and System need to exist in Master data. If they do not, then add them from Roles > Attributes.
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 easily found when you need it.
Open the template and then enter values for the following:

RoleName Type Last Reaffirm System RoleApprover FunctionalArea Company RoleProfilendIndicator ResponsibilityID CommentsMandatory (yes or no) ParentRoleOwner (yes or no) Description_en (English) DetailDescription_en (English) Description_es (Spanish) DetailDescription_es (Spanish) Description_de (German) DetailDescription_de (German) Description_fr (French DetailDescription_fr (French) Description_pt (Portuguese) DetailDescription_pt (Portuguese) Description_ja (Japanese) DetailDescription_ja(Japanese)
99
BusinessProcess SubProcess CriticalLevel ReaffirmPeriod
Save and close the template with the new information. Now you can import the role information into Access Enforcer. For more information on importing roles, see the section, To Import Roles: on page 97.
Creating Roles
The Create Role option allows you to create a role within Virsa Access Enforcer.
Note You cannot use Virsa Access Enforcer to create roles in SAP.
The Role Details page displays certain fields, which are pre-configured by accessing the Role Attributes page. Access the Role Attributes page by selecting Roles > Attributes in the navigation menu of the Configuration tab and then click each role attribute name to access its configuration page. The fields are:
X
Business Process Sub Process Systems Functional Area Company
To Create a Role: 1
From the navigation menu of the Configuration tab, select Roles > Create Role. The Role Details page appears.
100
Figure 83 2 3 4 5 6 7 8 9
Role Details page
In the Role Name field, enter the name of the new role. In the Description field, enter the description of the new role. From the Type drop-down list, select the type of role. A role group is a composite or single role. From the Role/Profile drop-down list, select either role or profile for the new role. From the Critical Level drop-down list, assign a level of criticality to the new role. In the ID field, enter a unique ID number. For Oracle, this is the Responsibility ID and for SAP, this is an identifier for the role. From the Business Process drop-down list, select the business process to which the new role will apply. From the Sub-Process drop-down list, select the sub-business process to which the new role will apply.
Note For more information on Role Reaffirm, see the Virsa Access Enforcer Users Guide.
10 In the Reaffirm Period field, enter the date range for reaffirming the new role. 11 In the Last Reaffirm field, enter the date for reaffirming the new role. Use the date
format of mm/dd/yyyy. You can also use the Calendar

12 In the Due field, enter the due date for reaffirming.
icon to select a date.
13 From the Comments Mandatory drop-down list, select Yes or No to make
comments are mandatory or not.
101
14 From the Consider ParentRole Owner for ChildRole drop-down list, select Yes or
No to consider the parent role owner for the child role or not.
15 In 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.
16 In the Detailed Description tab, type a description of the new role. 17 In the Role Approver tab, enter the primary and alternate approvers. You can use the
Search
icon to query for approvers.
18 In the Functional Area tab, click the Plus
icon to add the functional area to associate with this new role. A drop-down list appears from which you can select the name of the functional area.
19 In the Company tab, click the Plus
icon to add the company you want to associate this new role. A drop-down list appears from which you can to select the name of the company. icon to add custom attributes to the role. For more information about custom attributes see the section Creating Custom Fields on page 150.
20 In the Custom Attributes tab, click the Plus
21 Click Save.
Searching Roles
The Search Roles option allows you to query for roles based on the criteria you select. You can filter your query for role name, role description, system, business process, sub process, functional area, and role owner. Once you receive the search results, you can change or delete roles, or export the search results from Virsa Access Enforcer into spread sheet format.
Note The export feature is not available in Virsa Access Enforcer if you are using Virsa Role Expert to create and maintain roles.
Additionally, from the Search Results, Roles Information page you can begin the role creation process if the role you are looking for does not exist.
X To Search for a Role: 1
From the navigation menu of the Configuration tab, select Roles > Search Role. The Search Roles page appears.
102
Figure 84 2
Search Roles page
In the Role Name field, enter the role name you want to search.
Note When entering the Role Name as the search criteria make sure it is in all uppercase.
3 4 5 6 7 8 9
In the Role Description field, enter the description of the role you want to search. In the System field, enter the name of the SAP system on which your role resides. In the Business Process field, enter the business process associated with the role you want to search. In the Sub-Process field, enter the business sub-process associated with the role you want to search. In the Functional Area field, enter the functional area associated with the role you want to search. In the Role Owner field, enter the role owner associated with the role you want to search. Click Search. The Roles Information page appears with the search results.
Note Alternatively, leave every field blank and then click Search to view every role in Virsa Access Enforcer.
103
Figure 85
Roles Search Results page
Exporting Roles
Once you receive your role search results, you can download them to your computer in spreadsheet format. This allows you to make changes to the role information and then import the file back into Virsa Access Enforcer. For more information on importing role information into Virsa Access Enforcer, see Importing Roles on page 97.
X To Export Role Information 1 2
On the Roles Information, Search Results page, click Export. A File Download dialog box appears. Click Open to view the spreadseet immediately, or click Save and then select a location on your computer to save the file.
Selecting Roles
The Role Selection option allows you to narrow the scope of the search results for roles to a particular subset. This option is useful when you have a large number of roles to search. To optimize the search capability, you can limit the search criteria to specific attributes of a role. By configuring the scope of the search, it reduces the amount of time necessary for
104
Approvers and Access Requestors when searching for the correct role during the creation of a request.
Note All roles are imported into Virsa Access Enforcer, therefore, when you search for a role (using the Search Role option) as part of a request, the search is actually querying in Virsa Access Enforcer and not in SAP. There are several role attributes used as search criteria that are not stored in SAP.
To Configure Role Selection: 1
From the navigation menu of the the Configuration tab, select Roles > Role
Selection.
The Role Selection page appears.
Figure 86 2
Role Selection page
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 a large set of roles can be time consuming. Restrict Role Selection This allows Approvers to search only for a specific attribute. Use the drop-down list to select the allowed attribute.
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 a large set of roles can be time consuming. Restrict Role Selection This allows Access Requestors to search only for a specific attribute. Use the drop-down list to select the allowed attribute. Allow Users to Select Roles Check this box to allow users to select their own
roles.
105
In the Transaction Selection, select either:

New Request Change Request
In the Role Comments group, you can enable the Approver and Access Requestor to enter comments. You can also make comments mandatory by selecting the appropriate check box. Click Save.
Configuring Default Roles

The Default Roles option allows you to configure a role for certain conditions. You configure default roles to be added to an access request depending on the attributes selected by the Requestor. Additionally, you can configure whether to add default roles, configure which user attributes to assign to default roles, and finally add roles for the attributes you assign.After configuring a default role, it is automatically inserted into the access request, based on the User Attributes field. In addition to configuring default roles, you can import default roles from another system and download a template in which you can
X To Configure a Default Role: 1
From the navigation menu of the Configuration tab, select Roles > Default Roles. The Default Roles page appears.
Figure 87 2
Default Roles page
In the Consider Default Roles field, click the drop-down list to select Yes or No.
106
3 4 5 6
From the Default Role Level drop-down list, select to configure the default role at the Role or Request level. From the User Attributes drop-down list, select the desired attribute. The choices you can make here depend on the default role level you select. Click Save. Click Create. The Define Default Roles page appears.
Figure 88 7 8 9
Define Default Roles page
From the User Attributes drop-down list, select the desired attribute. In the Value field, type a value for each user attribute. Click the Plus icon, beneath the Role column. A field appears in the Role column and a drop-down list appears in the System column. when the request has a matching User Attribute, Value, and System.
10 In the Roles field, type the Role name to be inserted into the request automatically 11 In the System field, click the drop-down list to select the desired system name. 12 Click Save. X To Import Default Roles from an External System:
Besides creating default roles from scratch, you can import an Excel file containing roles and role information from another system, which you can use as default roles.
1 2 X
In the File Name field, enter the full path of the file name or click Browse to navigate to the file. Click Import to load the file.
To Download the Default Roles Template:
You can download a spreadsheet (.xls) template to your local system to use for importing default roles into Access Enforcer. After downloading the spreadsheet, populate the fields with your own default roles and then import the information into Access Enforcer
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 easily found.
107
Open the template and then enter values for User Attribute, Roles Value, Role
Profile Name , System, and ID.
Figure 89
Note
Download Default Role Template
It is highly recommended that you edit the downloaded template with your additional roles. Do not modify the sheet name and header names. When importing default roles, use uppercase for the role name as Virsa Access Enforcer is case-sensitive.
After adding all the default role information, save this file to your local system. Follow the instructions in the section To Import Default Roles from an External System: on page 107 to import this information to Access Enforcer.
Mapping Roles
The Role Mapping option allows you to assign roles to specific systems depending on the selected role in the request. Role mapping make it easier for requestors when specifying a role on a particular SAP backend system. They are automatically granted a role when they specify a certain SAP system. One example of having default roles, is when you want a role (A) to be followed by another role (B). In this case, role A is an AP Manager, which is always accompanied by role B, an AP Display. Also there are times when you want a default role to encompass many tasks or a single job, where one role is associated with a specific job.
X To Map a Role to a System: 1
From the navigation menu of the Configuration tab, select Roles > Role Mapping. The Role Mapping page appears.
108
Figure 90 2 3
Role Mapping page
From the System drop-down list, select the desired system name. From the Role Selected by User drop-down list, select the desired role name. Initially, this drop-down list is empty. You populate this list with role names that you define by adding a main role to the system you selected. To add a main role to a system and populate the Role Selected by User drop-down list for that system, click Add Main Role. The Select Main Role page appears.
Figure 91
Select Main Role page
109
5 6 7
From the System drop-down list, select the desired system name. Click Search. Any role names associated with the specified system name are displayed in the Search Results area. Select a role name and then click Add. The Role Mapping page appears. The role name that you added now appears in the Role Selected by User field. Once you finish adding main roles to the system, you can associate the main role with dependent roles that fall under the main roles umbrella.
Under the System column, click Add. The Select Dependent Roles page appears.
Figure 92 9
Select Dependant Roles page.
Make sure the system to which you want to add dependant roles appears in the System drop-down list and then click Search. dependant role or roles now appear in the list beneath the main role.
10 In the Search Results pane, select one or more roles and then click Add. The
To Import Role Mapping:
Virsa Access Enforcer allows you to import files containing already mapped roles. The files must be in Excel spreadsheet (.xls) format. Additionally, Access Enforcer provides you with an .xls template which you can use to map multiple roles and then import the mapped roles into Access Enforcer.
1 2
In the File Name field, enter the full path of the file, or click Browse to navigate to the file. Click Import to load the file.
110
Save this file to your local system, where it will be stored. After mapping the roles, you can define the directory path to this file.
To Download the Role Mapping 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 easily found. Open the template and then enter values for Main System, Main Role, Dependant
System, and Dependant Role.
Figure 93
Note
Role Mapping Template
It is highly recommended 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 uppercase for the main role name and dependant role name as Virsa Access Enforcer is case-sensitive.
Save this file to your local system, where it will be stored. After using the template to to create role mapping, you can define the directory path to this file, and then import the file using the instructions under the section, To Import Role Mapping: on page 110.
To Delete a Main Role: 1 2 3
From the navigation menu of the Configuration tab, click Roles > Role Mapping. The Role Mapping page appears. From the Role Selected by User drop-down list, select the role name you want to delete. Click Delete Main Role. A message appears stating that have you successfully deleted the main role.
Enabling and Removing Role Mappings

Once you have mapped roles, you can configure them to be enabled and, if applicable to remove them. Role removal relates to whether the default Role Mappings will function in reverse. Enabling this option means that when the Parent Role is deleted, then the Child Role (that was automatically added with the Parent), is also automatically deleted. The Parent-Child relationship is not bi-directional, when the Child Role is deleted independently from the Parent Role, the Parent Role is not automatically deleted.
111
To Configure Role Mapping: 1
From the navigation menu of the Configuration tab, select Roles > Role Mapping Configuration. The Role Mapping Configuration page appears.
Figure 94 2 3 4
Role Mapping Configuration page
From the Enable Role Mapping drop-down list, select either Yes or No. From the Applicable to Role Removals drop-down list, select either Yes or No. Click Save.
Defining Attributes
The Attributes option allows you to define the following properties:

Company This can be a global organization or division. Functional Area This is the business unit, such as HR or finance. Application Area This is the system that contains the application. Business Process This is the process of the actual work, such as accounting. Business Sub Process This is a sub-process of the actual work, such as auditing. Functional Area and Company This is where you define owner/role for the organization. You want to set the owner/role for the workflow stages in your approval path.
Once you have defined attributes using this option, the attributes appear in the dropdown list selections in the Request for Approval > Select Roles page. These attributes also appear in the Access Request page, in the drop-down lists.
Configuring Company Attributes
X To Configure a Company Attribute: 1 2
From the navigation menu of the Configuration tab, select Roles > Attributes. The Role Attribute selection page appears.
112
Figure 95 3
Role Attribute selection page
Click Company. The Role Attribute, Company page appears.
Figure 96 4 5 6
Role Attribute, Company page
Click Create. Three empty fields appear for Company ID, Short Description, and Description. In the Company ID field, enter the name of the organization. In the Short Description field, type a short description of the company.
113
7 8 X
In the Description field, type a description of the company. Click Save.
To Change a Company: 1 2 3
In the Company tab page, select the Company ID you wish to change. Click Change to modify the selected Company ID. The Company ID and Company Description fields become active. Make the appropriate edits. Click Save.
Configuring Functional Areas

X To Configure a Functional Area: 1
Figure 97 2
Click Functional Area. The Role Attribute, Functional Area page appears.
114
Figure 98 3 4 5
Role Attribute, Functional Area page
Click Create. Three empty fields appear for Name, Short Description, and Description. In the Name field, enter the name of the functional area. In the Short Description field, type a short description of the functional area.
6 7 X
In the Description column, type a description of the functional area. Click Save.
To Change a Functional Area: 1 2 3
In the Functional Area page, select the functional area you wish to delete or change. Click Change to modify the selected Functional Area. The Short Description and Description fields become active. Make the appropriate edits. Click Save.
Configuring Application Areas

X To Configure an Application Area: 1
115
Figure 99 2
Click Application Area. The Role Attribute, Application Area page appears.
Figure 100 Role Attribute, Application Area tab page 3 4
Click Create. Four empty fields appear for a Name, Short Description, Description, and System. In the Name field, type the name of the application.
116
In the Short Description field, type a short description of the application.

6 7
In the Description field, type a description of the application. At the end of the System field, click the Arrow Select System page appears. icon to view a list of systems. The
Figure 101 Select System page 8 9 X
Select a system from the list and then click Select to populate the System field. Click Save.
To Import Application Area Attributes:
Virsa Access Enforcer allows you to import files containing application area attributes. The files must be in Excel spreadsheet (.xls) format.
1 2
In the File Name field, enter the full path of the file name or click Browse to navigate to the file. Select the Overwrite Existing check box if you want to overwrite existing files and then click Import to load the file.
To Download the Application Area Attributes Template:
Access Enforcer provides you with an Excel spreadsheet (.xls) template which you can use to configure multiple application area attributes and then import into Access Enforcer.
1
Click Download Template and then click Save to save the .xls template to your system. Be sure to save the template in a location where it is easily found
117
Open the template and then enter values for Application Area, Short Description,
Long Description, and System.
Figure 102 Application Area Template

Note It is highly 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 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 you type into the Short Description field appears in dropdown lists throughout Virsa Access Enforcer when you perform a query. The information you provide in this field is limited to 20 characters.
Save this file to your local system, where it is stored. After using the template to to add application area attributes, you can define the directory path to this file, and then import the file using the instructions under the section, To Import Application Area Attributes: on page 117.
To Change an Application Area: 1 2 3
In the Application Area page, select the application area you wish to delete or change. Click Change to modify the selected Application Area. The Application Area and Description fields become active. Make the appropriate edits. Click Save.
Configuring Business Processes

X To Configure a Business Process 1 2
From the navigation menu of the Configuration tab, select Roles > Attributes. The Role Attribute page appears.
118
Figure 103 Role Attribute selection page 3
Click Business Process. The Role Attribute, Business Process page appears.
Figure 104 Role Attributes, Business Process page 4 5
Click Create. Five empty fields appear : Name, Short Description, Description, Owner/Approver, Alternate Approver and Application Area. In the Name field, type the name of the business process.
Note You can use mix characters case when you enter text in the Business Process field. However, once you save your input, this field will display uppercase characters.
119
In the Short Description field, type a short description of the business process.
7 8
In the Description field, type a description of the business process. In the Owner/Approver field, type the name of the primary approver. You can use the Search icon to query for the desired User ID. icon to query for the desired User ID. icon In the Alternate Approver field, enter the name of the secondary approver. You can use the Search
10 In the Application Area field, At the end of the System field, click the Arrow
to view a list of application areas. The Select Application Area page appears.
Figure 105 Select Application Area page 11 Select an application area and then click Select to populate the Application Area
field.
12 Click Save. X To Import Business Process Attributes
Virsa Access Enforcer allows you to import files containing business process attributes. The files must be in Excel spreadsheet (.xls) format.
1 2
120
To Download the Business Process Attributes Template:
Access Enforcer provides you with an Excel spreadsheet (.xls) template which you can use to configure multiple business process attributes and then import into Access Enforcer.
1
Click Download Template and then click Save to save the .xls template to your system. Be sure to save the template in a location where it is easily found. Open the template and then enter values for Business Process, Approver, Alternate Approver, Application Area, Short Description, and Long Description.
Figure 106 Business Process Template

Note 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
Save this file to your local system, where it is stored. After using the template to to add application area attributes, you can define the directory path to this file, and then import the file using the instructions under the section, To Import Business Process Attributes on page 120.
To Change a Business Process: 1
In the Business Process page, select the Business Process you wish to change.
121
Click Change to modify the selected Business Process. The Short Description, Description, Owner/Approver, Alternate Approver, and Application Area fields become active. Make the appropriate edits. Click Save.
Configuring Business Sub-processes

X To Configure a Business Sub-process: 1
From the navigation menu of the Configuration tab, select Roles > Attributes. The Role Attribute page appears.
Click Business Sub Process. The Role Attribute, Business Sub Process page appears.
122
Figure 108 Role Attribute, Business Sub Process page 3
Click Create. Three empty fields appear for a Name, Short Description, and Description, and a drop-down list appears from which you can select a Business Process. In the Name field, type the name of the business sub-process.
Note You can use mix characters case when you enter text in the Business Process field. However, once you save your input, this field will display uppercase characters.
In the Short Description field, type a short description of the business sub-process.
6 7 8 X
In the Description field, type a description of the business sub-process. From the Business Process drop-down list, select the desired business process name. Click Save.
To Change a Business Sub-process: 1 2
In the Business Sub Process page, select the business sub-process you wish to change. Click Change to modify the selected business sub-process. The Short Description and Description fields, and the Business Process dropdown list become active. Make the appropriate edits. Click Save.
123
Configuring the Functional Area and Company Attribute

X To Configure the Functional Area and Company Attribute: 1
From the navigation menu of the Configuration tab, select Roles > Attributes. The Role Attributes page appears.
Click Functional Area and Company . The Role Attribute, Functional Area and Company page appears.
Figure 110 Role Attributes, Functional Area and Company page 3
Click the Plus
icon. Four empty fields appear under Functional Area, Company,
Owner/Approver, and Alternate Approver.
124
4 5 6
In the Functional Area column, click the drop-down list to select the desired functional area. In the Company column, click the drop-down list to select the desired company. In the Owner/Approver column, click the Arrow icon to open the Approvers for Functional Area and Company page where you can query for approvers.
Figure 111 Approvers For Functional Area and Company page 7
Click the Plus icon. Two empty fields appear in the Approver and Alternate Approver columns. icon to query for approvers. If you have more than one row of Use the Search approvers, you must select a lead approver by clicking the radio button at the end of the appropriate row. Lead approvers are also indicated by the Hat beginning of the row. icon at the
Click Save. The Owner/Approver and Alternate Approver fields are populated. Click Save.
9 10 X
To Import Functional Area and Company Attributes:
Virsa Access Enforcer allows you to import files containing functional area and company attributes. The files must be in Excel spreadsheet (.xls) format.
1 2
125
To Download the Functional Area and Company Attributes Template:
Access Enforcer provides you with an Excel spreadsheet (.xls) template which you can use to configure multiple functional area and company attributes and then import into Access Enforcer.
1
Click Download Template and then click Save to save the .xls template to your system. Be sure to save the template in a location where it is easily found. Open the template and then enter values for Functional Area, Company ID, Approver ID, Alternate Approver ID, and IS Lead.
Figure 112 Functional Area and Company Attributes Template

Note 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
Save this file to your local system, where it is stored. After using the template to to add application area attributes, you can define the directory path to this file, and then import the file using the instructions under the section, To Import Functional Area and Company Attributes: on page 125.
To Delete the Functional Area and Company Attribute: 1
In the Functional Area and Company page, select the Functional Area you wish to delete by clicking anywhere in that row, outside any of the active fields.
126
Managing User Defaults Chapter 3 Setting Up Virsa Access Enforcer
Click the Minus
icon to delete the selected functional area.
Reaffirming a Role
Virsa Access Enforcer allows you to an send automatic e-mail reminders to any person 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 e-mail reminder.
X To configure the e-mail reminder for Reaffirming a Role: 1 2
In the Configuration tab, select the Roles option. This option expands to display Reaffirm Role. Click Reaffirm Role. The Reaffirm Role page appears.
Figure 113 Roles Reaffirm Email Reminder Page 3
In the Number of days prior to Reaffirm due date (to send email reminder), enter the number, in days, prior to the reaffirm date that you want to send the e-mail reminder. Click Save.
Managing User Defaults

Managing user defaults allows you to link data fields that are automatically set for new users created in Virsa Access Enforcer. Once you have configured User Defaults, the data is transferred to the in the SAP backend system (SU01) as defaults. The User Defaults option assigns the following:

Selecting a User Default System Configuring User Defaults Setting User Default Mapping
Selecting a User Default System

You must select an SAP backend system to act as the default system from which you can get the user defaults. The list of SAP systems in the drop-down list are based on the active SAP connections in the Connectors page.
Important You must select a user default system before you create user defaults.
127
To Select a User Default System: 1
From the navigation menu of the Configuration tab, select User Defaults > User Defaults System. The User Default System page appears.
Figure 114 User Default System page 2 3
In the System field, click the drop-down list to select the desired SAP system. Click Save.
Configuring User Defaults

This option allows you to assign user defaults in the SAP backend system (SU01) for new Virsa Access Enforcer users.
Important You must select a user default system before you create user defaults. For more information on selecting user default systems, see Selecting a User Default System on page 127.
To Configure User Defaults: 1
From the navigation menu of the Configuration tab, select User Defaults > User Defaults. The User Defaults page appears.
Figure 115 User Defaults page 128
Click Create. The Create User Defaults page appears.
Figure 116 Create User Defaults page 3 4
In the Name field, enter the name for the default. In the Short Description field, type a short description of the default.
5 6 7 8 9
In the Description field, type a description of the default. In the Start Menu field, type an SAP-specific (SU01) start menu. From the Logon Language drop-down list, select the default language used during login. From the Decimal Notation drop-down list, select a decimal notation style for the default. From the Date Format drop-down list, select a date format for the default. as a printer.
10 From the Output Device drop-down list, select an output device for the default, such 11 From the User Group drop-down list, select a default user group.
129
12 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.
13 Select the Delete After Output check box if you want the output to be deleted
instead of storing the output.

14 In the Parameter ID (PID) Details group, click the Plus
icon to add a parameter
and its value. You can add multiple parameters.

15 Click Save. X To Change a User Default: 1 2 3
In the User Default page, select the user default you wish to change. Click Change to modify. The Change User Defaults page appears. Make the appropriate edits. Click Save.
Setting User Default Mapping

Use this option to create, change and activate or deactivate the user default.
X To Set User Default Mapping: 1
From the navigation menu of the Configuration tab, select User Defaults > User Default Mappings. The Available User Default Mapping page appears.
Figure 117 User DefaultsAvailable User Default Mapping page
130
Click Create. The Create User Default Mapping page appears.
Figure 118 Create User Default Mapping page 3 4
In the Name field, type a name for the user default mapping. In the Short Description field, type a short description of the default mapping.
5 6
In the Description field, type the description of the default mapping. From the User Defaults drop-down list, select a user default.
Note The User Defaults in the drop-down list are created using the User Default option. For more information on creating user defaults, see the section, To Configure User Defaults: on page 128.
7 8
From the Attribute drop-down list, select an attribute. This is a Virsa Access Enforcer-specific attribute. From the Value drop-down list, select a value. The values are automatically populated in the drop-down list based on the attribute you select.
From the Condition drop-down list, select a logical operator: AND, OR, NOT. The default mapping appears in the User Default Mapping Details pane.
10 Click Add Attribute to add the attribute to the User Default Mapping Details table.
131
11 Click Save. X To Delete a User Default Mapping: 1 2
Select the user default mapping you wish to delete from the User Default Mapping
Details table.
Click Delete.
Monitoring Virsa Access Enforcer

The Monitoring option allows you to view the system log and see what applications are provisioned in Virsa Access Enforcer. The Monitoring option provides access to the following logs:

Viewing the System Log Viewing the Application Log
Viewing the System Log

Use the System Log option to view the current log file. The system log file contains such information as errors, sequence of operation, transaction flow, exception reports.
X To View the System Log: 1
From the navigation menu of the Configuration tab, select Monitoring > System Log. The Application Trace page appears with the default system log file name displayed.
Figure 119 System LogApplication Trace page 2
Click Get Log to view the system log.
Viewing the Application Log

Use the Application Log option to view a specific end-users access history to Applications (backend SAP systems) and that users provisioning activities in Virsa Access Enforcer. The Application Log displays the activity of the following action types:
132
USER CREATE Action that signifies that a user was created in SAP by an Virsa Access Enforcer Approver. ROLE ADD USER LOCK
Monitoring Virsa Access Enforcer Chapter 3 Setting Up Virsa Access Enforcer
USER UNLOCK ROLE DELETE USER DELETE
To View the Application Log: 1
From the navigation menu of the Configuration tab, select Monitoring > Application Log. The Application Log page appears.
Figure 120 Application Log page 2
In the User field, enter the User ID who requested access to an application. Click the
Search
icon to search for a valid user ID. icon to search for a valid user ID.
In the Changed By field, enter the User ID that changed an access request. Click the
Search
In the Roles field, enter the role associated with the access request. Click the Search icon to view all valid roles. In the From Date field, enter the date that the access request was first submitted. icon to select a date from a calendar. Click on the Calendar In the To Date field, enter the date that the access request was provisioned. Click the Calendar icon to select a date from a calendar. Click Search. The search returns the Application Log page.
5 6 7
133
Figure 121 Application LogSearch Results page
The Search Results shows the following fields for a single request:

User ID This is the user who created the request. Request Number This is the number assigned to the request. System Name This is the name of the target system. Date This is the date when the transaction occurred. Changed By This is user ID that made changes to the request. Action This is the action that occurred in the named target system. New Values This is the new values that were created based on the action. Description This is a short description of the transaction
134
Configuring HR Triggers Chapter 3 Setting Up Virsa Access Enforcer
Configuring HR Triggers
The HR Triggers option allows you to create rules in SAP HR system and associate Virsa Access Enforcer 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 leaving, rules are applied along with its corresponding HR Triggers. Virsa Access Enforcer then performs an action in a form of a request. The HR Triggers option provides four tools to create and manage rules for HR Triggers:

Creating Actions Creating Rules Configuring Field Mapping Viewing the Process Log
The approvers that you define using this option will appear throughout Virsa Access Enforcer either as part of the approval or workflow process.
Important In order to use the HR Triggers option, it is mandatory that you configure the background daemons as a scheduled job. See Setting Up Background Jobs on page 149 for more information on how to schedule the jobs. It is recommended that you set the HR Trigger Load Data job to 60 seconds. The HR Trigger Load Data background daemon is used to schedule to retrieve HR data resulting from trigger rules/actions. Set the HR Triggers job to 80 seconds. The HR Trigger background daemon is used to schedule the HR Trigger rules to perform the actions to the request.
Creating Actions
The Action option allows you to create an action in Virsa Access Enforcer. HR Triggers are associated with the following action types:
X
New (this can be a New Hire) Lock Unlock Delete Change
To Create an Action: 1
From the navigation menu of the Configuration tab, select HR Triggers > Actions. The Actions page appears.
135
Figure 122 HR Triggers ActionsAvailable Actions page 2
Click Create. The Actions Details page appears.
Figure 123 ActionsAction Details page 3
In the Action ID field, type a name for the action.
136
In the Short Description field, type a short description of the action.

5 6 7
In the Description field, type a description for the action. From the Type drop-down list, select an action type. From the Priority drop-down list, select a priority for the action. This Priority can be High, or Low.
System tab
8
Click the System tab. The System pane appears.
Figure 124 HR Triggers System tab 9
Click the Plus icon to add a new system. Repeat this step as necessary, to add more than one system to the action. the action.
10 From the System drop-down list, select the SAP system you want to associate with 11 In the Valid From field, click the Calendar 12 In the Valid To field, click the Calendar
icon to select a valid start date. icon to select a valid end date.
Address tab
13 Click Address tab.
The Address pane appears.
137
Figure 125 HR Triggers Address tab 14 From the Name drop-down list, select Yes or No to indicate whether you want the
user name to be updated in all corresponding SAP systems that were selected in the Systems tab.
15 From the the Email drop-down list, select Yes or No to indicate whether you want
the e-mail address to be updated in all corresponding SAP systems that were selected in the Systems tab.
16 From the Telephone drop-down list, select Yes or No to indicate whether you want
the users telephone number to be updated in all corresponding SAP systems that were selected in the Systems tab.
Parameter ID tab
17 Click Parameter ID tab. The parameter ID configuration page appears.
Figure 126 HR Triggers Parameter ID tab 18 From the Parameter ID drop-down list, select Yes or No to indicate whether you
want the parameter ID to be updated in all corresponding SAP systems that were selected in the Systems tab.
Default tab
19 Click Default tab. The default configuration page appears.
138
Figure 127 HR Triggers Default tab page 20 From the Default drop-down list, select Yes or No to indicate whether you want the
user defaults to be updated in all corresponding SAP systems that were selected in the Systems tab.
User Group tab
21 Click User Group tab. The user group configuration page appears.
Figure 128 HR Triggers User Group tab 22 From the User Group drop-down list, select Yes or No to indicate whether you want
the user group to be updated in all corresponding SAP systems that were selected in the Systems tab.
23 In the User Group Name field, type the name of the user group. 24 Click Save.
Creating Rules
The HR Trigger, Rules option allows you to create HR rules that are stored in the SAP HR system.
X To Create a Rule: 1
From the navigation menu of the Configuration tab, select HR Triggers > Rules. The Rules page appears.
139
Figure 129 HR Triggers RulesAvailable Rules page 2
Click Create. The Rules, Rules Details page appears.
Figure 130 HR Trigger Rules, Rule Details page 3
From the HR System drop-down list, select the desired HR system. This is the HR system where the events occur (initiating HR Triggers).
140
4 5 6
In the Rule ID field, type the name of the rule. In the Effective From field, click the Calendar the rule will take effect. icon to select the date from which
In the Rule Short Description field, type a short description for the rule.
Note The information you type into the Rule Short Description field appears in dropdown lists throughout Virsa Access Enforcer when you perform a query. The information you provide in this field is limited to 20 characters.
7 8
In the Rule Description field, type a description for the rule. In the Action field, click the Arrow page.
Note
icon to display the Select HR Trigger Actions
The Action IDs in this list are the actions that you created using the HR Trigger, Actions option. For more information about creating HR Trigger actions, see To Create an Action: on page 135.
Figure 131 Select HR Trigger Actions page 9
Select the actions you want to associate with the rule. You can select one or multiple actions. If you select more than one action, you must set the sequence in which the actions will be 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 Plus
icon to add a new attribute. The fields under the Info Type, Sub Type, Field, Operator, Value, and And/Or/Not columns become active.
141
Figure 132 HR Triggers Attributes tab 12 In the Info Type field, click the Search
icon to select the info type for your rule.
The Available Info Types page appears.
Figure 133 HR Triggers, Available Info Types page 13 Scroll through the list to locate the appropriate info type, and then click the radio
button next to the info type you want to select.

14 From the Select Sub Type drop-down list, select the desired sub type. The Sub Type
drop-down list is populated based on the Info Type you select. However, some Info Types may not have an associated Sub Type.
15 From the Select Info drop-down 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 drop-down list is populated based on the Sub Type you select.
16 Click Continue. The Attribute tab page reappears with the information that you have
configured.
17 From the Operator drop-down list, select the desired operator. The operators
include: =, <, >, and <>.
142
18 In the Value field, type a value, which will be compared with the value in the Field
column for your rule.

Note If the $ symbol precedes the field value, then it denotes the previous value for this field. For example, if the Field is admin and the Value is $admin, and uses the Operator of not equal (<>), then your rule will consider these two fields to be different.
19 From the And/Or/Not drop-down list, select And, Or, Not logical operators to
consider additional attributes in your rule.

20 Click Save. X To Change or Delete a Rule: 1 2
In the Rules page, select the rule name you wish to change or delete. To delete the rule, click Delete. Otherwise, click Change to modify the selected rule. The fields under the Info Type, Sub Type, Field, Operator, Value, and And/Or/Not columns become active. Make your modifications.
Click Save.
Configuring Field Mapping

The Field Mapping option allows you to map Virsa Access Enforcer fields to corresponding fields in the SAP HR system.
X To Map Fields Using the SAP HR System: 1 2
In the Configuration tab, select the HR Triggers option. This option expands to display Field Mapping. Click Field Mapping. The Field Mapping page appears.
143
Figure 134 HR Triggers Field Mapping page 3 4 5
In the SAP HR System field, click the drop-down list to select the desired HR system. The field mapping for that particular HR system is displayed. In the AE Field column, click the drop-down menu to select the Virsa Access Enforcer-specific field that you want to map. In the Field Type column automatically select either Custom or Standard depending on the AE Field. In the Info Type column, click on the Search types.
Note
icon to query for all available info
The Sub Type and Field Name columns are automatically populated, depending on the info type selection.
7 8 9
Click Save. Click Load Standard Field Mapping to upload the standard field mapping from SAPHR system to Virsa Access Enforcer. Click Save.
144
Viewing the Process Log

The Process Log option allows you to view all the processes that occurred within Virsa Access Enforcer that are associated with HR Triggers.
X To View the Process Log: 1
From the navigation meny of the Configuration tab, select HR Trigger > Process
Log.
The Process Log page appears.
Figure 135 Process Log Details page
145
Setting Up LDAP Mapping

The LDAP Mapping option allows you to map Virsa Access Enforcer fields to corresponding fields in an LDAP database. You can also add additional Access Enforcer fields and then map them to attributes that already exist in your companys LDAP database by selecting those attributes in the Additional Fields pane. For example, you can map fields in an LDAP table using F_Field to the Virsa Access Enforcer field FirstName_Field.
X To Map an LDAP System: 1
From the navigation menu of the Configuration tab, select LDAP Mapping option. The LDAP Mapping page appears.
Figure 136 LDAP Mapping page 2 3 4 5 6 7 8 9
From the System drop-down list, select the appropriate LDAP system. In the Employee ID field, type the employees user ID that you want to map with the LDAP system. In the First Name field, type the employees first name. In the Last Name field, type the employees last name. In the Email field, type the employees e-mail address. In the Department field, type the employees department name. In the Telephone field, type the employees phone number. In the Object Class field, type the object class associated with the employee.
10 In the Location field, type the location of the employee. 11 In the Location Country field, type the country code for the country in which the
employee is located.
12 In the UniqueLDAPKey field, type a unique identifier for the LDAP mapping. 146
Setting Up LDAP Mapping Chapter 3 Setting Up Virsa Access Enforcer
13 In the Manager field, type the name of the name of the employees manager. 14 Click Save. X To Create Additional Fields for LDAP Mapping: 1
Click the Plus
icon at the bottom of the Additional Fields pane.
A drop-down list and field become active in the AE Fields and LDAP Fields columns.
Figure 137 LDAP Mapping Additional Fields pane 2 3 4
From the drop-down list in the AE Fields column, select an Access Enforcer field name. In the field in the LDAP Fields column, type the name of the LDAP attribute to which you want to map. Click Save.
147
Defining Password Self Service

The Password Self Service option allows the ability for the end-user to reset their password 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 reset process for the end-user.
Note Once the end-user has reset their password, the reset password is e-mailed to the end-user.
To Define Password Self Service: 1
From the navigation menu of the Configuration tab, select Password Self Service. The Password Self Service page appears.
Figure 138 Password Self Service page 2
Click Create. The fields under the Info Type, Sub Type, Field, and Description columns become active. You need to complete these fields in order to authenticate the password. In the Info Type field, enter the appropriate info type or click the Search to query for all available info types. In the Sub Type field, enter the associated sub type. In the Field field, enter the field name for authentication. In the Description field, enter a description of the verification. From the Status drop-down list, select to make the status Active or InActive. icon to
3 4 5 6 7
148
Setting Up Background Jobs Chapter 3 Setting Up Virsa Access Enforcer
8 9
Click Save. In the Verification Data Source group, select a system in the System field. Click the drop-down list to select the system that you want to authenticate from.
10 Click Save. 11 In the Default System group, select a system in the System field. Click the drop-
down list to select the system that you want to authenticate to.
12 Click Save.
Setting Up Background Jobs

The Background Jobs option allows you to run jobs against the data in Virsa Access Enforcer. You can also configure it to take new actions. For example, if there are changes to a New Request being made or modifications in the approval stage that an access request is currently being processed.
X To Set Up a Background Job: 1
From the navigation menu of the Configuration tab, select Background Jobs. The Schedule Service page appears.
Figure 139 Schedule Service page 2
From the Task Name drop-down list, select the desired task. The page displays the configuration group for that particular task name.
Figure 140 Schedule ServiceConfigure Email Dispatcher page 3
In the Description field, enter the description of the task.

149
In the Schedule Type field, click the drop-down list to select the job frequency. The appropriate Task Recurrence group appears.
5 6 7
Enter the desired time you want the scheduled job to run. Click Save. Click View Schedule to review the scheduled job.
Creating Custom Fields

The Custom Fields option allows you to create customized fields that are required for additional information or security, for example. Custom fields can be used to determine the workflow of the request or to extend the current attributes for the organizations requirements. Custom fields will appear at the end of the Access Request page.
X To Create a Custom Field: 1
From the navigation menu of the Configuration tab, select Custom Fields. The Custom Fields page appears.
Figure 141 Custom Fields page 2
Click Create. The Create Custom Fields page appears.
150
Creating Custom Fields Chapter 3 Setting Up Virsa Access Enforcer
Figure 142 Create Custom Fields page 3 4 5 6 7 8 9
In the Name field, enter the name of the new custom field. In the Description field, enter the description of the new custom field. In the Field Label field, enter the name you want to label the field. In the Workflow field, click the drop-down list to select either Yes or No to indicate whether to allow this field to appear as a drop-down selection option. In the Mandatory field, click the drop-down list to select either Yes or No to indicate whether to require the end-user to enter information into this field. From the Applicable To drop-down list, select whether this field is is applicable to a Role, or Request. From the Field Type drop-down list, select either Dropdown or Text. If you select Dropdown, a Data Source drop-down list appars from which you must select a data source. If you select Text, a Data Type drop-down list appears from which you must select a data type.
10 In the Data Type field, click the drop-down list to select the type of data to be
entered. You can choose one of the following:

Date Numeric Varchar2
If you select either Numeric or Varchar2, a Data Length field appears in which you must enter the number of characters allowed for the data type.
11 In the Data Length field, enter the length of the data. 12 In the Data Source field, click the drop-down list to select either SAP or Virsa Access
Enforcer (AE) as the data source. If you select SAP, you must provide information for Source System, Table Name, and Field Name. Continue to Step 13.
Important Both Table Name and Field Name are case sensitive.
If you select AE, you need to provide information for Field Value. Skip to Step 16.
151
13 In the Source System field, click the drop-down list to select the SAP source system. 14 In the Table Name field, enter the name of the table to be used in the SAP source
system.
Important The Table Name value is case sensitive.
15 In the Field Name field, enter the name of the field within the table you selected in
Step 13.
Important The Field Name value is case sensitive.
16 Click Save. 17 The Custom Field Values group appears. Enter the valid field values for your
custom field. Use the Plus

18 Click Save. X
icon or Minus
icon to add or delete fields.
To Change or Delete a Company: 1 2 3
In the Custom Fields page, select the custom field name you want to change. Click Change to modify the selected custom field. The Change Custom Fields page appears. Make the appropriate edits. Click Save.
Miscellaneous Configuration
The Miscellaneous Configuration page allows you to define system-level settings not associated with other features of Virsa Access Enforcer. You perform these miscellaneous configurations on the Miscellaneous Configuration pane, as shown in Figure 143:
Figure 143 Miscellaneous Configuration Parameters Pane
There are four settings you can configure:

Languages Log Level Cache Job Time Interval in Seconds
152
Miscellaneous Configuration Chapter 3 Setting Up Virsa Access Enforcer
Background Job Time Interval in Seconds
Each of these settings is described in the following sections.
Configuring the Language

When you initially log on to Virsa Access Enforcer you see three fields on the User Login page: User ID, Password, and Language. While User ID and Password are required fields, Language is not. Therefore, you must set a default language for Virsa Access Enforcer here in Miscellaneous Configuration by selecting the appropriate language from the Language drop-down list and then clicking Save.
Note You must log off and then log back on again in order for this change to take effect in the user interface.
Additionally, if you select a language from the Language drop-down list on the initial login page that differs from the default language selected here in Miscellaneous Configuration, the default language is overridden and the user interface appears in the language selected when logging in.
Configuring the Log Level

Each transaction that Virsa Access Enforcer performs generates a message of some kind, and in some cases, can generate multiple messages. Virsa Access Enforcer automatically logs some or all of these messages. When you configure the log level setting, you specify which transaction messages Virsa Access Enforcer should log, and which (if any) it should ignore. There are four log levels:

Debug Causes Virsa Access Enforcer to log all messages, regardless of type. Info Causes Virsa Access Enforcer to log all error, warning, and information messages. Warn Causes Virsa Access Enforcer to log all error and warning messages. Error Causes Virsa Access Enforcer to log alland only error messages.
To set the log level, select the appropriate item from the Log Level drop-down list and then click Save.
Configuring the Cache Job Interval

In order to ensure a high standard of performance, Virsa Access Enforcer maintains a store of system data in a cache. This allows Virsa Access Enforcer to access key data without having to perform a database call. When Virsa Access Enforcer starts up, it loads the data from its database into the cache, and refreshes the data each time it performs a transaction. In order to ensure that the cache data is current even when Virsa Access Enforcer is idle, Virsa Access Enforcer also periodically refreshes the cache. This refresh is the cache job, and Virsa Access Enforcer performs it automatically.
153
When you configure the cache job interval, you specify the amount of time that must elapse before Virsa Access Enforcer refreshes the cache data. You define the interval in seconds.
Note When Virsa Access Enforcer performs a transaction, it automatically refreshes the data in the cache, and in the process resets the cache job clock to 000 seconds.
To set the Cache Job Time Interval, enter the number of seconds that Virsa Access Enforcer should wait before refreshing the cache into the Cache Job Time Interval in Seconds text field and then click Save.
Configuring the Background Job Interval

Virsa Access Enforcer uses a daemon process to run scheduled background jobs. The daemon runs periodically, and executes all background jobs that are due to run. Setting the background job interval determines how much time must elapse before Virsa Access Enforcer runs the background job daemon. To set the Background Job Time Interval, enter the number of seconds that Virsa Access Enforcer should wait before running the background job daemon into the Background Job Time Interval in Seconds text field and then click Save.
154
INDEX
A
About Access Enforcer, ?? 18 Key Concepts, 16 About Setting Up Access Enforcer, 63 About Workflows, 22 28 Example Workflows, 24 28 Basic Workflows, 25 Detour Workflows, 26 Forked Workflows, 27 Parallel Workflows, 27 Workflow Escape Routes, 26 The Workflow Creation Process, 23 Workflow Components, 22 Workflow Creation Process, The, 23 Access Enforcer About Setting Up, 63 About Workflows, 22 Configuring HR Triggers, 135 Configuring Roles, 97 Configuring User Defaults, 128 Creating Custom Fields, 150 Creating New Workflows, 41 Creating Roles, 100 Creating Rules, 139 Defining Approvers, 87 Defining Attributes, 112 Defining Connectors, 67 Defining Number Ranges, 83 Defining Password Self Service, 148 Identifying Technical Support Contacts, 93 Importing Roles, 97 Initial Login, 63 Initialize DB, 65 Initializing the System Data, 65 Key Concepts, 16 Managing User Defaults, 127 Mapping Roles, 63, 108 Preparing to Configure, 14 Setting Mitigation, 92 Setting Up Background Jobs, 149 Setting Up LDAP Mapping, 146 Setting Up Risk Analysis, 90 Setting Up the Service Level Period, 94 Using Connectors, 67 Where to Start, 64 Workflow-specific Configuration Tasks, 29 Access Enforcer Administration Tasks, 19 20 Access Enforcer, About, 16 Actions Creating, 135 Application Approvers Defining, 89 Application Areas Configuring, 115 Application Log Viewing the, 132 Applications Configuring, 79 Approvers Defining, 87 Attributes Configuring Company, 112 Defining, 112 Auto Provisioning, 34
B
Background Jobs Setting Up, 149 Basic Workflows, 25 Business Processes Configuring, 118 Business Sub-processes
155
Configuring, 122
Using, 67 Creating Actions, 135 Creating Custom Approver Determinators, 30 Creating Custom Fields, 150 Creating Forked Workflows, 58 Creating Initiators, 42 Creating New Workflows, 41 ?? Configuring Escape Routes, 55 58 Creating Forked Workflows, 58 ?? Creating Initiators, 42 44 Creating Paths, 50 55 Defining Stages, 44 50 Creating Paths, 50 Creating Roles, 100 Creating Rules, 139 Custom Fields Creating, 150
C
Company Attributes Configuring, 112 Configuring Application Areas, 115 Applications, 79 Business Processes, 118 Business Sub-processes, 122 Default Roles, 106 Employee Types, 81 Escape Routes, 55 Functional Areas, 114 HR Triggers, 135 Priorities, 78 Request Types, 75 the Functional Area and Company Attribute, 124 User Defaults, 128 Configuring Access Enforcer Preparing to, 14 Configuring Application Areas, 115 Configuring Applications, 79 Configuring Business Processes, 118 Configuring Business Sub-processes, 122 Configuring Company Attributes, 112 Configuring Default Roles, 106 Configuring Employee Types, 81 Configuring Escape Routes, 55 Configuring Functional Areas, 114 Configuring HR Triggers, 135 Configuring Priorities, 78 Configuring Request Types, 75 78 Configuring Roles, 97 Configuring the CUA System Setting, 38 Configuring the Functional Area and Company Attribute, 124 Configuring User Defaults, 128 Connectors
D
Default Roles Configuring, 106 Defining Attributes, 112 Defining Application Approvers, 89 Defining Approvers, 87 Defining Attributes, 112 Defining Available Request Attributes, 84 Defining Connectors, 67 Defining Number Ranges, 83 Defining Password Self Service, 148 Defining Points of Contact, 88 Defining Request Configuration, 75 Defining Security Leads, 87 Defining Stages, 44 Defining the Requestor Authentication Source, 85 Defining User Data Source, 73 Detour Workflows, 26
156
Index
E
Employee Types Configuring, 81 Enabling and Removing Role Mappings, 111 Escape Routes Configuring, 55 Example Workflows, 24 Basic Workflows, 25 Detour Workflows, 26 Forked Workflows, 27 Parallel Workflows, 27 Workflow Escape Routes, 26
L
LDAP Mapping Setting Up, 146
M
Managing User Defaults, 127 Managing User Defaults, 127 Mapping Access Enforcer Roles, 63 Mapping Roles, 108 Mitigation Setting, 92 Monitoring Access Enforcer Access Enforcer Monitoring, 132
F
Forked Workflows, 27 Creating, 58 Functional Area and Company Attribute Configuring the, 124 Functional Areas Configuring, 114
N
Number Ranges Defining, 83
H
HR Triggers Configuring, 135
P
Parallel Workflows, 27 Password Self Service Defining, 148 Paths Creating, 50 Points of Contact Defining, 88 Preparing to Configure and Administer Access Enforcer, 14 15 Priorities Configuring, 78 Process Log Viewing the, 145
I
Identifying Role Provisioning Processes to be Converted to Workflows, 14 15 Identifying Technical Support Contacts, 93 Identifying the SMTP Server, 40 Importing Roles, 97 Initial Login to Access Enforcer, 63 Initializing the System Data, 65 Initiators Creating, 42
R K
Key Access Enforcer Concepts, 16 18 Reaffirming Role, 127
157
Request Attributes Defining Available, 84 Request Configuration Defining, 75 Request Types Configuring, 75 Requestor Authentication Source Defining the, 85 Risk Analysis Setting Up, 90 Role Mappings Enabling and Removing, 111 Role Selection, 104 Roles Configuring, 97 Configuring Default, 106 Creating, 100 Importing, 97 Mapping, 108 Searching, 102 Selecting, 104 Rules Creating, 139
Setting User Default Mapping, 130 SMTP Server, identifying, 40 Stages Defining, 44 System Log Viewing the, 132
T
Technical Support Contacts Identifying, 93
U
User Data Source Defining, 73 User Default Mapping Setting, 130 User Default System Selecting a, 127 User Defaults Configuring, 128 Managing, 127 Using Connectors, 67 72
S
Searching Roles, 102 Security Leads Defining, 87 Selecting a User Default System, 127 Selecting Roles, 104 Service Level Period Setting Up the, 94 Setting Mitigation, 92 Setting Up Access Enforcer, About, 63 Setting Up Background Jobs, 149 Setting up Email Reminders, 32 Setting Up LDAP Mapping, 146 Setting Up Risk Analysis, 90 Setting Up the Service Level Period, 94
158
V
Viewing the Application Log, 132 Viewing the Process Log, 145 Viewing the System Log, 132
W
Workflow Components, 22 Workflow Creation Process, The, 23 Workflow Escape Routes, 26 Workflows About, 22 Configuring Escape Routes, 55 Creating Forked Workflows, 58 Creating Initiators, 42 Creating New, 41 Creating Paths, 50
Index
Defining Stages, 44 Example Workflows, 24 Basic Workflows, 25 Detour Workflows, 26 Forked Workflows, 27 Parallel Workflows, 27 Workflow Escape Routes, 26 The Workflow Creation Process, 23 Workflow Components, 22 Workflow-specific Configuration Tasks, 29 40 Automatic Provisioning, 34 37 Configuring the CUA System Setting, 38 40 Custom Approver Determinators, 30 32 Identifying the SMTP Server, 40 Setting up Email Reminders, 32 34
159
160

Virsa Access Enforcer For SAP 5.2 - Configuration - User Guide

Uploaded by

Copyright:

Available Formats

You might also like

Virsa Access Enforcer For SAP 5.2 - Configuration - User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Virsa Access Enforcer For SAP 5.2 - Configuration - User Guide

Uploaded by

Copyright:

Available Formats

Configuration Guide

Virsa Access Enforcer Version 5.2

Virsa Access Enforcer 5.2 Configuration Guide

Virsa Access Enforcer 5.2 Configuration Guide

COVERED IN THIS PREFACE

Virsa Access Enforcer 5.2 Configuration Guide

About this Guide

Product Documentation Preface

Adobe Acrobat PDF files

Installation Guide, Configuration Guide, User Guide, and Release Notes

Virsa Access Enforcer 5.2 Configuration Guide

Contacting SAP GRC

COVERED IN THIS CHAPTER

Virsa Access Enforcer 5.2 Configuration Guide

Preparing to Configure and Administer Virsa Access Enforcer

Completing the Pre-configuration Checklist

Identifying Role Provisioning Processes to be Converted to Workflows

Virsa Access Enforcer 5.2 Configuration Guide

About Virsa Access Enforcer

Virsa Access Enforcer Basic Functionality

Creating Requests Approving/Denying Requests Administration

Key Virsa Access Enforcer Concepts

About Virsa Access Enforcer Chapter 1 Administration Overview

Virsa Access Enforcer 5.2 Configuration Guide

Virsa Access Enforcer Users

Virsa Access Enforcer Administration Tasks Chapter 1 Administration Overview

Virsa Access Enforcer Administration Tasks

You need to:

Virsa Access Enforcer 5.2 Configuration Guide

COVERED IN THIS CHAPTER

Virsa Access Enforcer 5.2 Configuration Guide

About Workflows Chapter 2 Managing Workflows

The Workflow Creation Process

Virsa Access Enforcer 5.2 Configuration Guide

About Workflows Chapter 2 Managing Workflows

Sample Workflow with Three Stages

Virsa Access Enforcer 5.2 Configuration Guide

Escape routes have the following limitations:

About Workflows Chapter 2 Managing Workflows

Virsa Access Enforcer 5.2 Configuration Guide

Parallel Workflow Processing

Workflow-specific Configuration Tasks Chapter 2 Managing Workflows

Workflow-specific Configuration Tasks

Virsa Access Enforcer 5.2 Configuration Guide

Custom Approver Determinators

Virsa Access Enforcer Configuration Tab Navigation Menu

The Approver Determinator page appears.

Workflow-specific Configuration Tasks Chapter 2 Managing Workflows

Create Approver Determinator Page

Create Approver Determinator Attributes

Virsa Access Enforcer 5.2 Configuration Guide

Custom Approver Determinator Saved Successfully

Setting up e-mail Reminders

Virsa Access Enforcer Configuration Tab Navigation Menu

The Email Reminder page appears, displaying the Reminder tab.

Workflow-specific Configuration Tasks Chapter 2 Managing Workflows

Reminder Tab of the Email Reminder Page

In the Subject and Comment fields, enter the desired text.