Redpaper

Axel Buecker David Edwards

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On
There is a standard integration provided between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-on by provisioning credentials through the IBM Tivoli Access Manager for Enterprise Single Sign-on Provisioning Adapter. A number of Tivoli Access Manager for Enterprise Single Sign-on product manuals cover the installation and configuration of the various components. However, there is no overview of all of the components in the integration and how they interact. This IBM Redpaper looks at the integration from end-to-end and details the components and their interaction.

Copyright IBM Corp. 2007. All rights reserved.

ibm.com/redbooks

Single sign-on, provisioning, and identity management

IBM Tivoli Access Manager for Enterprise Single Sign-on (TAM E-SSO) is a product that provides desktop single sign-on for Windows users. It is a re-branding of the Passlogix vGO suite of products. The product uses a lockbox approach; it holds the user IDs and passwords for the user and presents them to the backend application on behalf of the user. There are a number of implementation models that Tivoli Access Manager for Enterprise Single Sign-on can support: A standalone deployment, where the Tivoli Access Manager for Enterprise Single Sign-on agent components are deployed to a single users' desktop and that user manages the credentials that are held. A networked deployment, where multiple agents are deployed to user desktops and central components (the Tivoli Access Manager for Enterprise Single Sign-on Repository and Tivoli Access Manager for Enterprise Single Sign-on Console) are deployed to a central server. In this model the repository holds the application profiles that the agents use, and the individual SSO users and their credentials. The console is used to maintain the repository and application profiles (the SSO credentials are synchronized from the Tivoli Access Manager for Enterprise Single Sign-on Agents). A networked deployment with Tivoli Access Manager for Enterprise Single Sign-on provisioning. This is the same as for the multi-user deployment, but also has the TAM E-SSO: Provisioning Adapter (or Tivoli Provisioning Manager in Passlogix terminology) that is used to centrally manage SSO users and their credentials. A networked deployment with IBM Tivoli Identity Manager provisioning. This is similar to the multi-user deployment but user credentials are distributed from Identity Manager through the TAM E-SSO: Provisioning Adapter to the E-SSO Repository.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Figure 1 shows the components in all of the models.

TAM E-SSO Console

Identity Manager

TAM E-SSO Repository

PROVISION

TAM E-SSO Provisioning Adapter

SY NC H

TAM E-SSO Agent

TAM E-SSO Agent

TAM E-SSO Agent

Figure 1 Overview of TAM E-SSO components in provisioning

For end-to-end provisioning, user accounts are created in Tivoli Identity Manager and provisioned to the various targets (such as operating systems, databases and applications). For applications that are defined in Tivoli Access Manager for Enterprise Single Sign-on, Tivoli Identity Manager provisions the same account credentials (user ID and password) to the Tivoli Access Manager for Enterprise Single Sign-on Repository through the TAM E-SSO: Provisioning Adapter. The Tivoli Access Manager for Enterprise Single Sign-on Agents receive the updated credentials when they synchronize with the Tivoli Access Manager for Enterprise Single Sign-on Repository. Tivoli Identity Manager manages the synchronization of passwords between the target systems and the credentials held by Tivoli Access Manager for Enterprise Single Sign-on. The applications defined in the Tivoli Access Manager for Enterprise Single Sign-on Repository (and managed through the Tivoli Access Manager for Enterprise Single Sign-on Console) are duplicated in Tivoli Identity Manager. The following sections describe the Tivoli Access Manager for Enterprise Single Sign-on-only models and the Tivoli Access Manager for Enterprise Single Sign-on and Tivoli Identity Manager integration details.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

PROVISION
H NC SY

MANAGE SYNCH

Tivoli Access Manager for Enterprise Single Sign-on and the Tivoli Provisioning Manager
This section describes the Tivoli Access Manager for Enterprise Single Sign-on deployment models where Tivoli Identity Manager is not used.

Tivoli Access Manager for Enterprise Single Sign-on stand-alone deployment model
In the single-user deployment model, stand-alone Tivoli Access Manager for Enterprise Single Sign-on agents are deployed to users' desktops. All application definitions are created locally on the desktop. Software and application definitions could be distributed using a software distribution tool, but the definitions would need to be first created on a Tivoli Access Manager for Enterprise Single Sign-on agent. The agent contains the Tivoli Access Manager for Enterprise Single Sign-on core. This is the code that detects that the user is performing a login and either passes credentials (if the application is defined) or allows the user to define the application. It can also include: The Tivoli Access Manager for Enterprise Single Sign-on Authentication Adapter to support other forms of user authentication, such as certificates or biometrics. The Tivoli Access Manager for Enterprise Single Sign-on Kiosk Adapter to support multi-user workstations where automated logoff and other multi-user security functions are required. The agent saves its information in a set of encrypted files (not the registry). In Tivoli Access Manager for Enterprise Single Sign-on V6, these can be found in the c:\Documents and Settings\<username>\Application Data\passlogix\secrets with an .sso extension. Note that where the TAM E-SSO: Provisioning Adapter is being used (either by itself or with Tivoli Identity Manager) the Tivoli Access Manager for Enterprise Single Sign-on agent also includes the TAM E-SSO: Provisioning Adapter client to allow the synchronization of user credentials.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Tivoli Access Manager for Enterprise Single Sign-on networked deployment model
The networked deployment model is for customers where multiple agents are required and it makes sense to centrally manage the application profiles. In addition to the Tivoli Access Manager for Enterprise Single Sign-on Agents that are deployed to the users' desktops, there is a central repository and the Tivoli Access Manager for Enterprise Single Sign-on Administrative Console (as shown in Figure 2).

Figure 2 TAM E-SSO Console

The console is used for managing many aspects of a Tivoli Access Manager for Enterprise Single Sign-on deployment, but from a provisioning perspective it is concerned with defining Applications (or application profiles) and mapping Applications to SSO users. The repository contains all of the application and user to application mapping. There are a variety of repositories supported (directories, databases and files) but most customers share the domain Active Directory. There are two key containers in the repository: The configuration container, OU=SSOConfig, holds all configuration information that is needed by the agent. This includes the application-supported list, mainframe/host application supported list, first-time use setup instructions, Password Policies, and Admin Overrides. All of these settings control agent behavior. The SSO user container holds the SSO user information, such as SSO credentials. This can be separate from the normal OS user container (as shown with the OU=People,OU=TAMES container in Figure 2). It can also be shared with the OS user container. Figure 3 shows the latter, with the SSO user information residing within each user object in the CN=Users container.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Figure 3 SSO Users under normal User container

For details about how to use the console and repository schema, see the Tivoli Access Manager for Enterprise Single Sign-on Administrative Console Help Files, which you can download from: http://publib.boulder.ibm.com/tividd/td/IBMTivoliAccessManagerforEnterpriseSingleS ign-On6.0.html

Tivoli Access Manager for Enterprise Single Sign-on networked deployment with TAM E-SSO: Provisioning Adapter model
This model is the networked deployment model that we described in the previous section with centralized credential provisioning added. The additional components are: The TAM E-SSO: Provisioning Adapter Server, which is an ASP.NET application that runs on Microsoft Internet Information Services. The TAM E-SSO: Provisioning Adapter Client CLI, which allows other applications (such as Tivoli Identity Manager) to communicate with the Provisioning Adapter. The TAM E-SSO: Provisioning Adapter Client that allows the Tivoli Access Manager for Enterprise Single Sign-on Agent to synchronize the user credentials. We describe the components in the following sections.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

The TAM E-SSO: Provisioning Adapter server

The TAM E-SSO: Provisioning Adapter server is basically a console for managing the entries held in the Tivoli Access Manager for Enterprise Single Sign-on Repository. It runs on Microsoft Internet Information Services and requires the Microsoft Web Services Extensions to support some Web services protocols. There are two application entry points, as shown in Figure 4: /v-GO PM Console/ is the administrative interface /v-GO PM Service/ is used by the CLI to communicate with the server (for example, the Web services interface)

Figure 4 TAM E-SSO: Provisioning Adapter Web modules in Internet Information Services Manager

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

You can use the administrative console, shown in Figure 5, to configure the TAM E-SSO: Provisioning Adapter.

Figure 5 TAM E-SSO: Provisioning Adapter settings page

Two key configuration items are: 1. The user base. You configure the TAM E-SSO: Provisioning Adapter with the repository type, server, root DN, and user path to define all the users that can be provisioned with SSO credentials. 2. The application list. You configure the TAM E-SSO: Provisioning Adapter with the repository container that includes the application list for which the users can have SSO credentials. This is the OU=SSOConfig container listed previously.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

The main function of the console is to manage users and their credentials. Figure 6 shows the user management panel.

Figure 6 TAM E-SSO: Provisioning Adapter Users page

In Figure 6, there are three users defined with SSO credentials: Administrator, mstevens, and ttimson1. The Administrator has SSO credentials for the Basic Auth application. The other two users have credentials for both the Adobe Acrobat Reader application and the Basic Auth application. The Users page of the console is displaying (and managing) the user and credential entries held in the person container (such as OU=People) in the Tivoli Access Manager for Enterprise Single Sign-on branch (such as OU=TAMES) in the user repository. The SSO users and their credentials are stored in the Tivoli Access Manager for Enterprise Single Sign-on Repository, as with the basic networked model, but now they can be managed centrally through the console.

The TAM E-SSO: Provisioning Adapter Client

This is also called the TAM E-SSO: Provisioning Adapter Support for SSO Agent. It is installed on the users' desktop along with the Tivoli Access Manager for Enterprise Single Sign-on Agent to enable credentials that are created by the TAM E-SSO: Provisioning Adapter to be securely sent to and accepted by the Tivoli Access Manager for Enterprise Single Sign-on Agent.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

The TAM E-SSO: Provisioning Adapter Client CLI

The TAM E-SSO: Provisioning Adapter Server provides a Web service that allows integration with other third-party provisioning systems. The TAM E-SSO: Provisioning Adapter Client CLI is used to communicate with this Web service. You can use it as a traditional scripting tool or, if preferred, you can use the SDK library to develop more complex integration solutions and connectors for the TAM E-SSO: Provisioning Adapter Server. This component is the component used by third-party Identity Management products, such as Tivoli Identity Manager, to provision credentials into Tivoli Access Manager for Enterprise Single Sign-on.

The complete TAM E-SSO: Provisioning Adapter picture

Figure 7 shows the key components and their interaction for a networked deployment with the TAM E-SSO: Provisioning Adapter.

/vGO PM Console/ /vGO PM Service/

TAM ESSO Provisioning Adapter Server
TAM ESSO Provisioning Adapter Client CLI

IIS

Config Data
Data

SSO Creds

Config Data & SSO Creds

TAM ESSO Agent

TAM ESSO PA Client

Workstation

Figure 7 TAM E-SSO: Provisioning Adapter components

10

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Central to the entire provisioning model is the Tivoli Access Manager for Enterprise Single Sign-on Repository that includes, among other things, the configuration data (such as the application profiles) and the SSO credentials for the SSO users. The Tivoli Access Manager for Enterprise Single Sign-on Console manages the configuration information. The TAM E-SSO: Provisioning Adapter console manages the SSO users and their SSO credentials. This is the UI aspect of the TAM E-SSO: Provisioning Adapter Server that is the ASP.NET application running on Microsoft Internet Information Services (IIS). It has two interfaces: the console interface (/vGO PM Console/) and the Web services interface (/vGO PM Service/) that is used by the TAM E-SSO: Provisioning Adapter CLI interface. The other component is the TAM E-SSO: Provisioning Adapter Client that resides on the user workstation with the Tivoli Access Manager for Enterprise Single Sign-on Agent and securely synchronizes the SSO credentials with the Tivoli Access Manager for Enterprise Single Sign-on Repository. The next section looks at how Tivoli Identity Manager fits into this architecture.

Tivoli Identity Manager and Tivoli Access Manager for Enterprise Single Sign-on provisioning
The previous section discussed how the TAM E-SSO: Provisioning Adapter components can perform provisioning of SSO credentials from a central point to the users' workstations. The missing piece to this puzzle is how to manage and synchronize the target system passwords with the SSO credentials for that target system. For example, if you configure an SAP system within Tivoli Access Manager for Enterprise Single Sign-on so that when a user connects to that SAP system, Tivoli Access Manager for Enterprise Single Sign-on supplies the login information to SAP on the user's behalf, what happens when a user needs to change their password for SAP? You can change the password through Tivoli Access Manager for Enterprise Single Sign-on, where Tivoli Access Manager for Enterprise Single Sign-on changes the password at SAP and holds the new one. What happens when an administrator needs to change the user's password? Then, it has to be changed in SAP and in Tivoli Access Manager for Enterprise Single Sign-on. It could be changed in SAP and given to the user so when the user logs in, the password can be changed in Tivoli Access Manager for Enterprise Single Sign-on. A better solution is to use a tool that synchronizes passwords. So an administrative action to change the SAP password also cascades that new password into Tivoli Access Manager for Enterprise Single Sign-on. This synchronization is where Tivoli Identity Manager comes into the picture. The TAM E-SSO: Provisioning Adapter cannot manage passwords outside Tivoli Access Manager for Enterprise Single Sign-on (such as the SAP target), nor does it have the strength of features (role-based provisioning or business process integration through workflow) that Tivoli Identity Manager does. So, it makes sense to deploy both Tivoli Access Manager for Enterprise Single Sign-on and Tivoli Identity Manager for enterprise identity management.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

11

This is the networked deployment with IBM Tivoli Identity Manager provisioning model that we mentioned previously. Figure 8 illustrates how the products work together.

Identity Manager Server

Identity Manager DB

Identity Manager LDAP

Provisioning

Target Target Target

Figure 8 TAM E-SSO: Provisioning Adapter and Identity Manager components

Basically, Tivoli Identity Manager pushes credentials to Tivoli Access Manager for Enterprise Single Sign-on through the TAM E-SSO: Provisioning Adapter CLI. We discuss the details of this process in the next section.

Configuration in Tivoli Identity Manager for Tivoli Access Manager for Enterprise Single Sign-on provisioning
The challenge with the integration is to ensure that changes made to account IDs and passwords are synchronized to Tivoli Access Manager for Enterprise Single Sign-on where that account is defined in Tivoli Access Manager for Enterprise Single Sign-on. The integration involves changes to both the data held in Identity Manager and the plumbing to get this data to Tivoli Access Manager for Enterprise Single Sign-on. This section looks at the data objects that are involved in the integration and the operational changes to distribute Tivoli Access Manager for Enterprise Single Sign-on credentials.

12

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Data Objects involved in the integration

This section looks at the data held in Tivoli Identity Manager, the data held in Tivoli Access Manager for Enterprise Single Sign-on, and how they are related.

The Tivoli Identity Manager data objects related to provisioning

The core data objects involved in provisioning are: Person Account A person object represents a real world person, such as an employee or contractor. An account a person can have on a target system, such as an operating system or application. An account object has a set of attributes, such as the account ID and password. One person object can have zero or more account objects. One account object must have one and only one person object. The Tivoli Identity Manager definition of a target system user repository (such as the OS user registry or application user datastore). The service object defines how to access the target (such as URL/port for the Tivoli Identity Manager adapter) and other information for accessing the user repository (such as the DN of the user store in a directory).

Service

Organizational role A grouping of people objects based on some role definition (for example, programmer, clerk, or helpdesk). A person object can belong to zero or more roles, and a role can be attached to zero or more people. Provisioning policy This object defines the entitlement for people to have accounts on target systems. A provisioning policy defines that Role A can have an account on Service Z, possibly with some restrictions on attribute values. So if you have a person object defined in Tivoli Identity Manager, and you have a provisioning policy that entitles you to an account on a specific service (perhaps through an organizational role), then Tivoli Identity Manager can create an account for you on the target defined by the service (including provisioning the account down to that target system).

Tivoli Access Manager for Enterprise Single Sign-on objects

Within Tivoli Access Manager for Enterprise Single Sign-on, there are two levels of data objects relating to users: The SSO user entry The SSO credentials with application, account ID and password settings A single SSO user entry can have multiple credentials related to it. An SSO user is similar to a person in Tivoli Identity Manager, except that it maps directly to the operating system user for the desktop environment to which you are logging in. You might be defined as John Smith as a person in Tivoli Identity Manager, but you log in to the Windows domain as jsmith because that is your Active Directory username for that domain. The SSO credentials map to the Tivoli Identity Manager accounts where those accounts are defined to the Tivoli Access Manager for Enterprise Single Sign-on system. For example, if John Smith has a Lotus Notes account of John Smith/Australia/MyCo defined in Tivoli Identity Manager, and John uses Tivoli Access Manager for Enterprise Single Sign-on to login to Notes, then Tivoli has a Notes SSO credential (including the user ID and password)

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

13

defined in Tivoli Access Manager for Enterprise Single Sign-on that is mapped to the Tivoli Identity Manager account. Figure 9 shows the user and account object relationships (assuming AD is the domain user registry and the Tivoli Access Manager for Enterprise Single Sign-on repository).

jsmith AD User (person)

jsmith SSO User (vGOUserData)

P RE RO CO VIS NC IO ILE NED D FR TO OM

John Smith Person (erPersonItem)

MAPS TO

jsmith AD Account (erAccountItem)

John Smith/... Notes SSO Creds (vGOSecret)

MAPS TO

John Smith/... Notes Account (erAccountItem)

Notes Account

Notes

jasmith SAP SSO Creds (vGOSecret)

MAPS TO

jasmith SAP Account (erAccountItem)

SAP Account

SAP

Figure 9 TAM E-SSO and Tivoli Identity Manager user and account data objects

In this figure there are four objects in Tivoli Identity Manager; the person object and three associated accounts (AD, Notes, and SAP). Each of these account objects are provisioned to their targets: AD, Notes, and SAP. There is also a relationship between the AD account (in AD), the AD account in Tivoli Identity Manager and the SSO user entry. If the normal user container in AD is shared by Tivoli Access Manager for Enterprise Single Sign-on, then the SSO user entry is under the AD user entry. If there is a separate container used to hold the SSO users (for example, OU=People,OU=TAMES,), then there is a unique SSO user entry under this container (but with the same user ID as the AD entry). The Notes and SAP SSO credentials are under the SSO user entry (for example, associated with) in the same way that the Notes and SAP accounts in Tivoli Identity Manager are related to the person object. We have not described how the Tivoli Access Manager for Enterprise Single Sign-on data objects and Tivoli Identity Manager data objects are physically mapped. The Maps To link in Figure 9 indicates the logical mapping. The next section discusses this topic.

14

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Physically mapping user objects

Tivoli Access Manager for Enterprise Single Sign-on V6.0 integration with Tivoli Identity Manager V4.6 uses the following modifications to physically link Tivoli Identity Manager user objects to their Tivoli Access Manager for Enterprise Single Sign-on counterparts: Extending the Tivoli Identity Manager account objectclass (erAccountItem) to include Tivoli Access Manager for Enterprise Single Sign-on user and credential attributes (vgo*). You can find the attributes on the eraccountitem object in the V3.modifiedschema file. Note that most of these attributes are not used in the current integration implementation. Only the vgossouserid attribute is used. Extending the Tivoli Identity Manager service objectclass (erServiceItem) to include a series of Tivoli Access Manager for Enterprise Single Sign-on attributes to allow information to be passed to the TAM E-SSO: Provisioning Adapter CLI. Some custom operations (modified operational workflows and associated Java extensions) to take account changes and extract the relevant Tivoli Access Manager for Enterprise Single Sign-on information before passing it to the TAM E-SSO: Provisioning Adapter CLI. Figure 10 shows a modified service definition that includes information that is passed to Tivoli Access Manager for Enterprise Single Sign-on through the TAM E-SSO: Provisioning Adapter CLI: vgoadminid vgoadminpwd vgoapplicationidmeta The account used to log into the TAM E-SSO: Provisioning Adapter service. The password for the vgoadminid. The title (label) of the application, this must be the same as defined in Tivoli Access Manager for Enterprise Single Sign-on. The metadata that describes the SSO credential (for example, the account ID that is passed to the backend application). In this case it is replaced by eruid for the account in the workflow. The metadata that describes the SSO user to which this SSO credential maps. In this case, it is replaced by the uid from the person object.

vgoapplicationdescriptionmeta The description for the SSO application.

vgoapplicationuseridmeta

vgossouseridmeta

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

15

Figure 10 Modified erServiceItem object in Tivoli Identity Manager

The service form is modified to include these vgo* attributes for each service that is defined as an application in Tivoli Access Manager for Enterprise Single Sign-on. So, continuing our previous example, there would be vgo* attributes defined on both the SAP service and the Notes service. Notice that the vgoapplicationmeta attribute seems to map to the application name as shown in Figure 2 on page 5 and Figure 6 on page 9. However the one defined in Tivoli Identity Manager has a leading asterisk (*Basic Auth). This naming convention is done to flag this service as the root service. This is so the workflow operations can differentiate between the creation or deletion of the SSO user entry and the SSO credentials. The root service is the one where the Tivoli Access Manager for Enterprise Single Sign-on entries are held (in this example it is Active Directory). We describe the operational workflow components in the next section.

Operational components involved in the integration

Tivoli Identity Manager needs to provision changes to Tivoli Access Manager for Enterprise Single Sign-on whenever accounts that are associated with a SSO-enabled service are changed (that is, when an account is created, an account or password changed, an account deleted, or an account restored). A number of configuration changes have been made to Tivoli Identity Manager to allow it to provision to Tivoli Access Manager for Enterprise Single Sign-on: Many of the standard account operational workflows have been extended to include calls to the TAM E-SSO: Provisioning Adapter Client through the CLI, including the custom Java classes used to call the API from the workflow nodes. Custom Java extensions have been written to call the TAM E-SSO: Provisioning Adapter from the modified workflows.

16

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

We describe these changes in the following sections.

Add Account operational workflow

Figure 11 illustrates the modified Add Account operational workflow.

Figure 11 Tivoli Identity Manager modified Add Account operational workflow

The standard Add Account operational workflow only has one node: the CREATEACCOUNT Extension node. The custom nodes that are added are: add_ssoid This Script node checks the relevant data to ensure a valid application ID and SSO user ID have been passed (metadata mapping defined in the service definition). If the data is present and can be parsed, then set a true flag for the rest of the processing. It also sets the owner for rootservice accounts. This Script node runs on a successful CREATEACCOUNT operation. It retrieves and checks (parse) all of the SSO data before setting the values on the current account (in relevant data). This Extension node runs the AddPasslogixCredential operation with an argument of Account and the account object (from relevant data). If the outcome of this modification is that the RootService has been set, then the owner's Person object is updated. This node modifies the person object if this is a root service. It sets/updates the uid attribute as set in the checkSSO Script node. It uses the standard modifyPerson extension.

checkSSO

setSSO

modPerson

In essence this workflow first creates the account (provisioned to the target system), then it creates the SSO user object (if this is a root service), and finally it creates the SSO credentials that match this account.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

17

Change Password operational workflow

Figure 12 illustrates the modified Change Password operational workflow.

Figure 12 Tivoli Identity Manager modified Change Password operational workflow

The standard workflow only has the CHANGEPASSWORD Extension node. The custom nodes added are: CheckSSO This Script node is run on the successful completion of the CHANGEPASSWORD operation. It retrieves the relevant data and checks the application ID, SSO user ID and application user ID. If the data passes the parsing, it is set on the current account object and a flag set to continue the processing. This Extension node runs the ChangePasslogixPassword operation with an argument of Account and the account object (from relevant data).

setSSO

This workflow first updates the password on the target system, and then it updates the password in the SSO credentials in Tivoli Access Manager for Enterprise Single Sign-on.

Delete Account operational workflow

Figure 13 shows the modified Delete Account operational workflow.

Figure 13 Tivoli Identity Manager modified Delete Account operational workflow

The standard workflow only has the DELETEACCOUNT Extension node. The custom nodes added are: CheckRootService This Script node checks to ensure that user ID, SSO application ID and SSO admin ID/password are set before deleting the SSO user. The link out of the node checks for Root Service and if it is a root service it runs the DeleteSSOUser node. DeleteSSOUser This Extension node runs the DeletePasslogixUser operation with an argument of Account and the account object (from relevant data). Even if this step fails, the workflow continues to delete the account on the target.

18

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

CheckSSO

This Script node runs if the delete was successful and the application is not a Root Service and there is an SSO account to process. It retrieves, validates and sets (on the current account object) the application ID, the user ID and the admin ID/password. It also sets a flag to drive the last step. This Extension node runs the DeletePasslogixCredential operation with an argument of Account and the account object (from relevant data).

setSSO

If a Root Service account is being deleted, the Tivoli Access Manager for Enterprise Single Sign-on user and credentials will be deleted prior to the target account being deprovisioned (incase the SSO data is being held under the target user object). Otherwise, it will delete the SSO credentials after the target account is de-provisioned.

Modify Account operational workflow

Figure 14 illustrates the modified Modify Account operational workflow.

Figure 14 Identity Manager modified Modify Account operational workflow

The standard workflow only has the MODIFYACCOUNT Extension node. The custom nodes added are: checkSSO setSSO This Script node retrieves, checks (Parse) and sets the SSO attributes on the current account object (relevant data). This Extension node runs the ModifyPasslogixCredential operation with an argument of Account and the account object (from relevant data) if there is an SSO credential defined for this user on this service.

This is basically the same as the Change Password operation.

Restore Account operational workflow

Figure 15 shows the modified Restore Account operational workflow.

Figure 15 Identity Manager modified Restore Account operational workflow

The standard workflow only has the RESTOREACCOUNT Extension node.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

19

The custom nodes added are: checkPWDChg This Script node checks to see if the password has been changed as part of the restore operation. If so it sets a flag (isSSO); true means the password has been changed. checkSSO This Script node retrieves, checks (Parse) and sets the SSO attributes on the current account object (relevant data). It is only run if the isSSO flag is true (for example, password has been changed). This Extension node runs the ChangePasslogixPassword operation with an argument of Account and the account object (from relevant data). It is only run if the isSSO flag is true (for example, password has been changed).

setSSO

The SSO aspects of this workflow are only concerned with password changes as a result of reactivating an account.

Suspend Account operational workflow

There are no changes to the Suspend Account operational workflow.

Custom extensions in operational workflow

Table 1 shows the custom workflows use the custom extensions.
Table 1 Custom extensions in operational workflow Extension AddPasslogixCredential ChangePasslogixPassword DeletePasslogixUser DeletePasslogixCredential ModifyPasslogixCredential Argument Account Account Account Account Account Used in Add Account (setSSO) Change Password (setSSO), Restore Account (setSSO) Delete Account (DeleteSSOUser) Delete Account (setSSO) Modify Account (set SSO)

These Extensions are located in the PMAPIInvoker-6.0.jar file (for Tivoli Access Manager for Enterprise Single Sign-on V6.0) which is installed into the WebSphere Application Server enRole.ear directory (for example, the Tivoli Identity Manager application code tree). This is also called the Tivoli Identity Manager Provisioning Workflow Interface Connector. This .jar file includes a configuration file: PMClientConfiguration.properties. Among the settings in this file are three related entries to how the TAM E-SSO: Provisioning Adapter client contacts the TAM E-SSO: Provisioning Adapter server: javaCLI.serviceurl javaCLI.serviceuser javaCLI.serviceuserpassword This is the URL to which the server service is listening (for example, http://adserver/v-GO PM Service/UP.asmx). The administrative user that is used to access the service (for example, odi\tamespa). The password for the administrative user that is used to access the service.

Each of the Java modules are built on the TAM E-SSO: Provisioning Adapter Client CLI calls. These are in the pmcli.jar file that is defined into a shared library in WebSphere Application Server. The next section summarizes how the components work together.

20

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Provisioning from Tivoli Identity Manager to Tivoli Access Manager for Enterprise Single Sign-on
Figure 16 summarizes the calls from Tivoli Identity Manager into the Tivoli Access Manager for Enterprise Single Sign-on Client CLI.

AddPasslogixCredential
ChangePasslogixPassword

/vGO PM Service/

PMAPI.jar (and assoicated TAM ESSO PA Client CLI libraries)

DeletePasslogixUser

call

DeletePasslogixCredential ModifyPasslogixCredential

call

PMClientConfiguration .properties

PMAPIInvoker-6.0.jar

Tivoli Identity Manager Application

Service Service Service - Service attribs. - Service attribs. - Service attribs. - vGO SSO attribs - vGO SSO attribs - vGO SSO attribs Account Account Account - Account attribs. - Account attribs. - Account attribs. - vGO SSO attribs - vGO SSO attribs - vGO SSO attribs

Tivoli Identity Manager Directory (LDAP)

Figure 16 Tivoli Identity Manager calls into the TAM E-SSO: Provisioning Adapter Client CLI

The additional SSO data is held on the account and service objects in the Tivoli Identity Manager directory. Changes to accounts trigger operational workflows that have been customized to make calls out to the Tivoli Identity Manager Provisioning Workflow Interface Connector (for example, custom Java extensions for the SSO function). These extensions use the definitions in the configuration file and the TAM E-SSO: Provisioning Adapter Client CLI libraries to make API calls to the TAM E-SSO: Provisioning Adapter Server.

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

21

The complete picture

Figure 17 shows all components involved in the integration (combining Figure 7 on page 10 and Figure 16 on page 21).

AddPasslogixCredential

/vGO PM Service/ PMAPI.jar (and assoicated TAM ESSO PA Client CLI libraries)

ChangePasslogixPassword

DeletePasslogixUser

call

DeletePasslogixCredential ModifyPasslogixCredential

call

PMClientConfiguration .properties

PMAPIInvoker-6.0.jar

Tivoli Identity Manager Application

Service Service Service - Service attribs. - Service attribs. - Service attribs. - vGO SSO attribs - vGO SSO attribs - vGO SSO attribs Account Account Account - Account attribs. - Account attribs. - Account attribs. - vGO SSO attribs - vGO SSO attribs - vGO SSO attribs

Tivoli Identity Manager Directory (LDAP)

Figure 17 Compete Tivoli Identity Manager and TAM E-SSO integration

We can use a use case of Create Account to describe the flow through the integration: An administrator logs into Tivoli Identity Manager and creates a new account for a person. This account is for a service that has SSO defined. The Add Account operational workflow is invoked. This workflow provisions the new account to the target system but also calls the relevant Extension nodes to create the SSO user (if it is a root service) and the SSO credentials (such as user ID and password). The Java extensions use the TAM E-SSO: Provisioning Adapter Client CLI libraries and the server definitions in the PMClientConfiguration.properties file to send a Web services call to the TAM E-SSO: Provisioning Adapter Server. The server adds the credentials (and optionally adds the SSO user entry) to the SSO Repository. The Tivoli Access Manager for Enterprise Single Sign-on Agent synchronizes with the SSO Repository and retrieves the SSO credentials. The user can be SSO'd to the target system. An administrator can use the TAM E-SSO: Provisioning Adapter console to see whether the credentials have been successfully sent from Tivoli Identity Manager to the SSO Repository. The outcome of the client calls are recorded with the Tivoli Identity Manager transactions and are viewable through the View Completed Requests panel in the Tivoli Identity Manager UI. If there have been problems with the extensions, the API calls or the TAM E-SSO: Provisioning Adapter Server, and the error messages are recorded in the transaction history. This completes the discussion of the Tivoli Identity Manager and Tivoli Access Manager for Enterprise Single Sign-on provisioning integration.

22

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On

Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

23

This document REDP-4325-00 was created or updated on June 18, 2007. Send us your comments in one of the following ways: Use the online Contact us review Redbooks form found at: ibm.com/redbooks Send your comments in an e-mail to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A.

Redpaper

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:
Redbooks (logo) IBM Lotus Notes Lotus Notes Tivoli WebSphere

The following terms are trademarks of other companies: SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries. Adobe, Acrobat, and Portable Document Format (PDF) are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both. Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Active Directory, Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

24

Exploring the Integration between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single Sign-On