Enterprises have to be highly flexible to adapt to change and take advantage of new business opportunities. This creates pressure to rapidly deploy new applications and systems, and expose them internally and externally to employees, partners, and customers. In such an environment, information on identities — employees, partners, and customers — relevant for business processes and applications is spread across heterogeneous and incompatible sources coming with different data formats and access protocols. This lack of a central source for identity information leads to inconsistent and out-of-date information, which in turn weakens overall information security and reduces efficiency of key processes, such as on-boarding of employees or provisioning of required access permissions to customers and business partners. The prime objective of identity management (IDM) is to overcome these deficiencies, centrally manage all identity data, and ensure high data quality. Another important requirement enterprises must meet is to comply with regulations such as the Sarbanes-Oxley Act, which deals with identification and prevention of access- and authorization-related risks. These legal requirements directly affect provisioning of access privileges to business applications. You need to implement appropriate mechanisms to prevent access to business transactions that in combination represent a violation of segregation of duties (SoD) risks. These mechanisms require complex and detailed rules for risk identification in complex business applications from multiple vendors such that they remain beyond the scope of IDM solutions. Consequently, there is currently no single product for compliant IDM available in the market delivering efficient provisioning of identity data and access privileges as well as Sarbanes-Oxley compliance across a heterogeneous system landscape. However, you can combine SAP BusinessObjects Access Control 5.3 with IDM solutions to provide an efficient solution for Sarbanes-Oxley-compliant IDM across a heterogeneous system landscape. After an overview of the product capability Compliant User Provisioning (CUP) and its Web service-based interface to IDM solutions, I’ll continue with an introduction to SAP NetWeaver Identity Management 7.1, which represents a powerful combination of the meta-directory and virtual directory concepts. Using the example of SAP NetWeaver Identity Management, I’ll describe a scenario in which you can combine these SAP products to create a highly automated and SAP ERP Human Capital Management (HCM)-integrated solution for Sarbanes-Oxley-compliant IDM. Let’s start with a couple of technical concepts upon which most IDM solutions are based.

IDM Solution Technical Possibilities

Several vendors have developed IDM solutions that have reached a solid level of maturity. Two different technical concepts for IDM solutions are predominant in the market:

• Meta-directory: Solutions based on the meta-directory approach synchronize identity data from existing data sources into a central repository, which is in many cases a directory server accessible through the LDAP protocol. Meta-directory solutions often support complex operations to provision users and access privileges over a heterogeneous system landscape. Disadvantages of the meta-directory approach are additional costs for implementation and ownership of a central repository and the dependence of data actuality on the synchronization frequency.
• Virtual directory: Virtual directory-based solutions provide real-time access to the existing data sources without moving the data out of the original repository and don’t require data synchronization. They provide a single access point using a standard protocol such as LDAP to heterogeneous data sources and present the information in a virtual directory tree. They are capable of providing different views to internal and external clients based on their requirements, access permissions, and data privacy policies. Virtual directory solutions depend on the data sources to which they connect.

Whether a meta-directory- or virtual directory-based solution is the best choice depends on the requirements for service quality, performance, network topology, and policies for security and data privacy. Combined solutions are also available in the market and offer additional flexibility.

SAP BusinessObjects Access Control 5.3

SAP BusinessObjects Access Control 5.3 is a solution for identification, management and mitigation of access, and authorization-related risks in a system landscape that includes SAP and non-SAP solutions to ensure Sarbanes-Oxley compliance. SAP BusinessObjects Access Control 5.3 consists of four application capabilities: Risk Analysis and Remediation (RAR), Enterprise Role Management (ERM), Superuser Privilege Management (SPM), and CUP. Relevant for the compliant identity management use case are the RAR and CUP components in combination with the following Web services that come standard with SAP BusinessObjects Access Control:

• SAPGRC_AC_IDM_SUBMITREQUEST
• SAPGRC_AC_IDM_SELECTAPPLICATION
• SAPGRC_AC_IDM_RISKANALYSIS
• SAPGRC_AC_IDM_SEARCHROLES
• SAPGRC_AC_IDM_ROLEDETAILS
• SAPGRC_AC_IDM_AUDITTRAIL
• SAPGRC_AC_IDM_REQUESTSTATUS

Any IDM product can consume these Web services to submit requests into CUP, select applications connected to CUP, search and retrieve detail information of roles available in CUP, and request results of risk analysis, status, and audit trail information of access requests submitted in CUP. SAP BusinessObjects Access Control 5.3 can also call Web services offered by IDM solutions for request submission as long as they are Service Provisioning Markup Language (SPML) 1.0 compliant. This Web service-based interface supports two different scenarios:

• IDM driven: Initial request creation in the IDM solution and subsequent request submission in CUP for risk analysis, approval, and auto-provisioning for ERP access to SAP and non-SAP systems
• CUP driven: Initial request creation in CUP and subsequent request submission in IDM solution for non-ERP access such as mail account or corporate network

Both scenarios involve submission of requests in CUP at a certain point. Scenarios with a direct interface between the IDM solution and RAR for risk analysis are currently not supported by SAP BusinessObjects. In both scenarios, access requests consist of a combination of entitlements in ERP (both SAP and non-SAP) systems and entitlements in non-ERP systems (e.g., Microsoft Active Directory, Microsoft Exchange, and Sun ONE directory). The ERP entitlements contained in the access request require a detailed risk analysis in CUP before they can be provisioned. Let’s drill a bit deeper into the IDM-driven scenario, where the IDM solution calls SAP BusinessObjects Access Control 5.3 for request submission (Figure 1). Here the request is initiated in the IDM solution by an identity source, which can be as simple as a request form filled in by a requester in a self-service scenario or more complex involving other systems such as SAP ERP HCM. Depending on the configuration in the IDM solution the request is approved in IDM and the non-ERP entitlements are auto-provisioned whereas the ERP entitlements are submitted as new requests into CUP where approvers conduct a thorough risk analysis before they approve the request and CUP performs the auto-provisioning. To support this scenario, the IDM solution has to be able to call SAP BusinessObjects Access Control 5.3’s Web service interface accordingly. If the IDM solution takes advantage of all available Web services, then more advanced features, such as request status tracking and holistic audit trails in IDM (including audit information from CUP), are possible. In the alternative CUP-driven scenario it is CUP calling the IDM solution for request submission (Figure 2). In this example, the request is initiated in CUP. The non-ERP entitlements exist in CUP as roles belonging to the IDM system connector that has to be configured in CUP. The ERP roles undergo a risk analysis during their approval. Request approval in CUP triggers auto-provisioning of the ERP entitlements via the CUP system connectors. Non-ERP entitlements are submitted as requests into the IDM solution via the IDM system connector, where they may need another approval before the IDM solution triggers their provisioning. A technical requirement for this scenario to work is an SPML 1.0-compatible Web service on the IDM side that CUP can call for request submission. At a first glance, the IDM-driven scenario seems to be the more logical approach, but experience shows that the approach to IDM can be very different in different companies. For organizational reasons, customers may opt for a GRC-driven implementation approach. It is important to understand that SAP BusinessObjects Access Control has a focus on delivering Sarbanes-Oxley compliance and cannot replace an IDM solution (Figure 3). It can only provision to SAP and non-SAP systems, but not to directory servers, operation or email systems, or other system components of a heterogeneous IT environment.   On the other hand, IDM solutions cannot deliver compliance on a very granular level that includes detailed analysis of each target system’s authorization concept. Most IDM solutions keep references to entitlements in their target systems (e.g., role names and group names), but do not dig deeper into their content in terms of detailed authorization field values and other parameters.

SAP NetWeaver Identity Management 7.1

SAP NetWeaver Identity Management 7.1 is a full-fledged IDM solution that, unlike former SAP Central User Administration (CUA), does not focus on SAP-only environments (Figure 4).   It comes with a large variety of connectors to SAP and non-SAP target systems such as SAP ABAP as well as Java stack-based business applications, diverse operation systems, databases, email systems, and Web and legacy applications (Figure 5). It is also possible for customers to develop additional connectors that do not come with the product. A key component of SAP NetWeaver Identity Management is a central identity store that contains all identity data pulled together from and kept in synch with its source systems. Changes of employee data in an SAP ERP HCM system, or manually via self-service and automated workflows, can automatically trigger provisioning of users and access privileges. SAP NetWeaver Identity Management 7.1 also allows for rule-based provisioning (e.g., the presence of configurable attributes at a given identity object) to trigger provisioning of access privileges in one or multiple target systems. Another useful product capability is a password management component permitting end users in a self-service scenario to reset their passwords. The solution also comes with user-friendly Web Dynpro-based UIs for access requests, monitoring and accessing detailed audit trails.   As depicted in Figure 6, SAP NetWeaver Identity Management 7.1 consists of two main components: Identity Center (IC) and Virtual Directory Server (VDS). IC is a meta-directory-based component, whereas VDS is a virtual directory solution. There are use cases in which only one of these two components needs to be installed — they run independently from each other. Each component can connect to a large variety of source systems via connectors depending on the specific use case.   The VDS can expose IDM functionality to external clients or applications through identity services. Identity services, accessible via the LDAP or SPML protocol, provide a standards-based single access point for querying and managing identity information across the system landscape. IC contains the identity store, which is either an MS SQL server or an Oracle database, and controls the provisioning operations. VDS can connect to the identity store via the JDBC interface to retrieve or update identity data as requested by external clients or business applications through identity services. The opposite connectivity is also possible: VDS can take the role of a target system for provisioning controlled by IC and allow at the same time real-time access to the data in the source systems that are connected to the VDS.

Identity Center

IC is the primary component used for IDM. It includes functions for identity provisioning, workflow, password management, logging, and reporting (Figure 7). IC retrieves the data from various repositories, consolidates it, transforms it into the necessary formats, and publishes it back to the various decentralized repositories when synchronization is necessary. IC uses a database called the identity store to store all data related to identity objects, configuration, and audit trails.   The workflow UI is based on Web Dynpro Java and is used by requesters and approvers for request submission and approval. The monitoring UI is based on the same UI technology and provides administrators access to monitoring, audit trails, and status information of ongoing provisioning processes in IC. Both the workflow UI and the monitoring UI are deployed either on SAP NetWeaver 7.0 Application Server Java or on SAP NetWeaver Composition Environment 7.1 enhancement package 1. The management console is a snap-in for the Microsoft Management Console and is used to connect target systems, define workflow processes, and configure processing logic of IC. By its nature, it requires a Microsoft Windows operating system. The dispatcher runs in a runtime engine that executes provisioning and synchronization tasks. You can use multiple pairs of dispatcher/runtime engines to run specific types of jobs and allow for scalability of the solution. You can configure an event agent to take action based on changes performed directly in one of the target systems. The event agent detects changes and submits information to the IC. The dispatcher then executes a given job to react to the detected change. This mechanism is optional and its only purpose is to initiate synchronization based on changes in repositories in addition to the scheduled operations. The concept of business roles represents another important feature of IC. Business roles can contain one or multiple technical roles and also other business roles (Figure 8). Technical roles are references to roles or privileges in the source systems. They are uploaded from their source systems and represented in IC as privileges. In their source systems, the roles contain bundles of authorizations or access permissions, but this role content is not available in IC. Business roles are usually defined in the context of a business process and contain all privileges required to execute certain business tasks of an employee in multiple systems. They facilitate requesting and approving access by less-experienced end users.  

Virtual Directory Server

VDS provides a single access point supporting standard protocols such as LDAP or SPML for clients retrieving or updating data in multiple data repositories coming with different data formats or access protocols. It can represent the data in a virtual directory tree and supports different views of the information based on the requirements and access permissions of the requesting user or application. In a very simple case, VDS can represent data from a relational database in a virtual directory tree and provide access to it via the LDAP protocol. A single access point via a standard protocol facilitates accessibility of the data for applications and end users considerably. It reduces configuration and administration efforts and requires less specialized skills resulting in a lower total cost of ownership. Because data is kept in their source repositories rather than copied to other locations, data privacy is protected and real-time access to the data is ensured. The data owner continues keeping control over the data. VDS can perform schema adaptations such as attribute mappings and attribute manipulations such that the data from multiple sources is presented in a seamless fashion in a virtual directory tree. In a similar way, you can join data across multiple sources and update it in a single operation. Many different use cases exist for VDS. Now I’ll show you a combined use case for VDS and IC, which is applicable to system landscapes containing an SAP ERP HCM system.

Use Case: Identity Life Cycle with SAP ERP HCM Integration

A particular strength of SAP NetWeaver Identity Management is the capability for tight integration with SAP Business Suite applications. I’ll explain a scenario in which events in the employee life cycle taking place in a SAP ERP HCM system can trigger provisioning and de-provisioning actions in SAP NetWeaver Identity Management. This increases automation in IDM for employees and saves costs. Another example for the integration with SAP Business Suite applications is the capability for business partner creation and provisioning of assignments between users and business partners in SAP Customer Relationship Management (CRM), which is required to fully enable new users in the SAP CRM application context. In the scenario shown in Figure 9, employee data is maintained in SAP ERP HCM. SAP ERP HCM uses the build-in LDAP connector technology to replicate employee data as needed to the VDS using its identity services interface. IC, or more precisely its identity store database, is connected with the VDS as a data repository through the JDBC connector. The VDS writes the employee data received through the identity services interface into the identity store. This replication mechanism also supports a configurable delta replication: Only changes of relevant attributes of employees are delivered through the VDS to the identity store. Also, time-dependent values are supported and you can schedule provisioning actions to take place at a future date when a particular change becomes effective (e.g., an internal transfer or promotion).   IC can now initiate rule-based provisioning of business roles. For example, new entries tagged as employees can be provisioned automatically the business role Employee. In the example in Figure 9, this includes the creation of an entry in the LDAP directory serving as a user source for SAP applications running on an SAP NetWeaver Application Server Java such as the SAP NetWeaver Portal. The business role Employee may contain further privileges in multiple SAP and non-SAP target systems. These could be group memberships in the LDAP directory granting access to a portal role tailored for employees, user IDs, and authorization roles in SAP ABAP stack-based systems such as SAP ERP HCM or SAP ERP for self-services, access to the corporate network, and an email account. Communication data created during the provisioning process (e.g., user ID, email account, or data entered later through Web-based employee self-services) will be added as an attribute to the identity entry in the identity store. You can even write it back to the employee master record in SAP ERP HCM, if permitted by HR data owners.

A Solution for Compliant IDM

The integration of SAP BusinessObjects Access Control 5.3 and SAP NetWeaver Identity Management 7.1 provides a highly integrated solution for HR-driven compliant IDM. It has recently been made available in SAP IDES demo systems and can be booked by SAP sales contacts and presented live to customers. Figure 10 shows the flow of this scenario in eight steps, which runs in a highly automated fashion with minimal human interaction:

1. Employee actions executed by the HR department trigger provisioning in SAP NetWeaver Identity Management. The example shows the on-boarding of a new employee, but you can support other employee actions (e.g., position change or contract termination) in a similar fashion.
2. The LDAP connector is scheduled to run once per day and replicates changes to the employee master data to VDS.
3. VDS connects to the identity store and creates a new identity object for the new employee.
4. Attribute data identifies the new entry as an employee working in the procurement department. This triggers rule-based provisioning in SAP NetWeaver Identity Management of the two business roles Employee and Procurement – Default. The business roles contain privileges for an email account in Microsoft Exchange and an account in Microsoft Active Directory with group memberships for the security groups Employee and Procurement – Default, which lead to an allocation of the corresponding roles in the SAP NetWeaver Portal. They also contain privileges for a user ID in the SAP ERP HCM and SAP ERP systems with authorization roles for employee self-services and order management, respectively. Because these systems are both ERP-like systems, SAP NetWeaver Identity Management creates through the Web service interface a request in SAP BusinessObjects Access Control to conduct a risk analysis prior to provisioning.
5. After SAP NetWeaver Identity Management creates a user ID and email address for the new employee in compliance with the applicable naming conventions, it automatically connects via RFC back to SAP ERP HCM and updates the master record of the new employee, adding to the communication data infotype the user ID (subtype 0001) and the email address (subtype 0010). A correctly maintained communication infotype is a prerequisite for many workflow-driven business scenarios in SAP business solutions.
6. SAP NetWeaver Identity Management automatically submits a request to CUP containing the authorization roles for employee self-services in the SAP system and for order management in the SAP ERP system, respectively.
7. A compliance manager receives the CUP request and performs a risk analysis before she or he approves it.
8. Request approval triggers auto-provisioning in CUP: A new user is created in the SAP ERP HCM and SAP ERP systems and the authorization roles are assigned.

  If the SAP NetWeaver Portal is configured for single sign-on (SSO) with Windows Kerberos, then the new employee, Peter Paddler, finds a user-friendly system environment waiting for him on this first day:

• His manager provides him with the initial password to log on to the Active Directory and the corporate network
• He has an email account in Microsoft Exchange
• He has an icon on his desktop for the corporate portal that does not require further authentication
• He finds in his portal landing page all he needs: Company information and employee self-services under the Company tab, his workflow inbox, an Identity Management tab to request additional access, an Order Management tab for the required transaction in the procurement department (Figure 11), and collaboration features

  If Peter requires additional business roles, he can submit a request with additional business roles to SAP NetWeaver Identity Management. Access privileges for ERP systems contained in the selected business roles again lead to creation of a corresponding request for risk analysis and approval in CUP.