With IBM Tivoli Identity Manager (ITIM) companies can manage their users and accounts centrally accross all their heterogeneous IT environment including SAP ressources. ITIM can do user provisioning to SAP systems, connected via SAP CUA or standalone or a combination of both.
For SAP user management, SAP provides tools in the form of transactions like "SU01" for user master record creation and maintenance. For large and complex environments, especially when spanned in different business units, managing users and following company policies is difficult because each SAP instance has its own user repository (which again is necessary to gain access to a specific SAP system). To avoid duplicated effort, users can either be managed centrally or get synchronized across all instances. To achieve this on SAP only, SAP customers can use the SAP module Central User Administration (CUA).
Some SAP CUA characteristics
- available with SAP R/3 release 4.6
- should be a separate SAP instance for the sole purpose of user administration for all other R/3 instances
- uses a standard SAP R/3 transaction-based user interface
- suffered initially from stability issues in its first releases, but SAP has improved its quality and it is now a more robust utility (so you can confidently use the latest version)
- requires that a person have the same user ID on all managed instances (in some cases company policy prohibits the use of the same user ID across all instances)
Before implementing CUA the customer needs to decide
- whether or not to enable local user management at the instance level. Once the decision has been made to grant local administration privileges to a certain field, it cannot be managed centrally, and vice versa.
- if SAP HR should be used to drive user administration based on HR roles. Using CUA and HR for position-based user administration can lead to system conflicts and unpredictable system behaviour when installing and using CUA.
However, creation of a flexible environment, in which users of several instances are managed centrally and local administrators still have full control over their instances for certain user management tasks, cannot be solved with CUA.
With ITIM one can manage such an combined environment, having CUA in place for some SAP systems and managing local SAP systems that can't be connected via CUA.
Pros and Conns of having CUA in an ITIM environment
Implementing CUA in an environment with ITIM has some advantages:
- it reduces the number of ITIM Adapters (without CUA an adapter is required for every SAP instance)
- it performs central SAP role management (like creating roles; ITIM just uses existing roles)
Reasons for not having CUA for certain SAP systems in an ITIM environment might include:
- requirements for different user IDs on specific SAP instance,
- local user administration required on certain SAP instances,
- when the target system is running SAP HR and entries are to be managed as infotype 105,
- being flexible, for future changes.
With ITIM, one has the flexibility of deciding whether to have CUA in place or not.
ITIM vs Transaction SU01
The decision to use ITIM vs SAP transaction SU01 for user management (in an SAP only environment!) comes down to 2 behaviours:
1. Conn for ITIM, Pro for SAP Transaction SU01
The ITIM Adapter for SAP R/3 currently does not support all possible SAP user account attributes. But it supports the majority, and has attempted to cater for all critical attributes. The attributes that are not supported, are usually not important, none are mandatory, and they are only available in SAP transaction SU01 via sub-forms under transaction SU01.
2. Pro for ITIM, conn for SAP Transaction SU01
Using ITIM allows password synchronization, whereas SAP transaction SU01 doesn't. The only password that transaction SU01 will distribute in a CUA environment is the initial password. What this means is that after every password change, the user must change their password on the first log-on after the change. If the password is changed via ITIM, this password reset functionality is disabled.
In a SAP CUA environment, when a password change is made by the administrator using transaction SU01, it is distributed to the logical systems assigned to that user account. In fact the SAP password change dialog lets you select which logical systems you want the password distributed to. The password that is distributed is what SAP terms the "initial password". SAP forces the user to change the password again on the first log-on to an assigned logical system, after the distributed password change.
ITIM with CUA or non-CUA - a decision based on flexibility requirements
Still, this doesn't really come into play when deciding to use SAP CUA or SAP non-CUA. The key point is that ITIM allows the customer to run whatever SAP configuration they want to. They could set up a maze of SAP CUA and non-CUA environments, and ITIM would manage all of them. ITIM would allow the same Identity/Person to use the same Log-on ID or different Log-on IDs across all the SAP systems, and still be able to synchronize the password. The only systems ITIM would not manage directly are the SAP CUA child systems, although ITIM manages these systems indirectly via the SAP CUA master system.
From an ITIM perspective, each ITIM entitlement (in the Provisioning Policy) matches directly to a SAP non-CUA system, or a SAP CUA Master system. Using multiple ITIM provisioning policies - each assigned to a specific ITIM Role, each with its target ITIM entitlements (SAP systems) - gives the end ITIM administrator a lot of power and flexibility to control account assignment for any SAP environment. For example, assigning a single ITIM Role to an ITIM Identity/Person can cause an account to be created in every SAP system in the managed SAP environment.
More on IBM Tivoli Identity Manager can be found at
http://www.ibm.com/software/tivoli/products/identity-mgr/
IBM Tivoli Identity Manager (ITIM)
IBM Tivoli Identity Manager provides a secure, automated and policy-based user management and provisioning solution. It supports central user administration and automation of user data. ITIM can integrate and automate business processes through workflow, central management, self-service interfaces and password management.
ITIM supports more than 70 target systems and applications to integrate with its identity management functions. To connect with these systems, ITIM typically use an XML based protocol, Directory Services Markup Language (DSML), as a communications mechanism.
IBM Tivoli Identity Manager can also integrate mySAP applications in a corporate user administration environment. To integrate with SAP there are two adapters available: the ITIM Adapter for SAP R/3 and the ITIM Adapter for SAP UME (e.g. used for SAP Enterprise Portal user administration).
IBM Tivoli Identity Manager is SAP certified.
ITIM Adapter for SAP R/3
The SAP R/3 Adapter is designed to perform user management from an ITIM server to a SAP R/3 system. The adapter supports SAP Central User Administration (CUA) and non-CUA systems.
Using traditional ITIM agent architecture, based on ADK (Agent Development Kit), the adapter is deployed as a service on Windows systems or as a daemon on Unix systems.
The adapter uses C implementation of SAP’s RFC API to access SAP R/3 systems. For actions where standard RFC is not available, custom RFC’s are implemented and packaged in SAP transport file format. Those transport files must be installed on the SAP systems as part of the installation process. The communication between the ITIM server and SAP R/3 Adapter are assured through DAML over SSL, with the x509 based client authentication.