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

7/31/2019 Exploring the Integration Between IBM Tivoli Identity Manager and IBM Tivoli Access Manager for Enterprise Single

1/24

Copyright IBM Corp. 2007. All rights reserved. ibm.com/redbooks 1

Redpaper

Exploring the Integration between IBM Tivoli

Identity Manager and IBM Tivoli AccessManager for Enterprise Single Sign-On

There is a standard integration provided between IBM Tivoli Identity Manager and IBMTivoli 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 ofTivoli 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 thecomponents in the integration and how they interact.

This IBM Redpaper looks at the integration from end-to-end and details the components andtheir interaction.

Axel Buecker

David Edwards
http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/


2/24

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

Single sign-on, provisioning, and identity management

IBM Tivoli Access Manager for Enterprise Single Sign-on (TAM E-SSO) is a product thatprovides desktop single sign-on for Windows users. It is a re-branding of the Passlogix vGOsuite of products.

The product uses a lockbox approach; it holds the user IDs and passwords for the user andpresents 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:

Astandalone deployment, where the Tivoli Access Manager for Enterprise Single Sign-onagent 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 andcentral components (the Tivoli Access Manager for Enterprise Single Sign-on Repository

and Tivoli Access Manager for Enterprise Single Sign-on Console) are deployed to acentral 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 maintainthe 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-onprovisioning. This is the same as for the multi-user deployment, but also has the TAME-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 tothe multi-user deployment but user credentials are distributed from Identity Managerthrough the TAM E-SSO: Provisioning Adapter to the E-SSO Repository.


3/24

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

Figure 1 shows the components in all of the models.

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) tothe 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 updatedcredentials when they synchronize with the Tivoli Access Manager for Enterprise Single

Sign-on Repository.

Tivoli Identity Manager manages the synchronization of passwords between the targetsystems 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-onConsole) 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.

TAM E-SSO Repository

TAM E-SSO

Agent TAM E-SSO

Agent

TAM E-SSO

Agent

TAM E-SSO

Provisioning

Adapter

TAM E-SSO

Console

Identity Manager

SYNCHS

YNCH

SYNCH

MANAGE

PROVISION

PROVISION
http://-/?-http://-/?-


4/24


Tivoli Access Manager for Enterprise Single Sign-on and theTivoli Provisioning Manager

This section describes the Tivoli Access Manager for Enterprise Single Sign-on deploymentmodels 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 EnterpriseSingle 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 asoftware 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 TivoliAccess Manager for Enterprise Single Sign-on core. This is thecode 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 TivoliAccess Manager for Enterprise Single Sign-on Authentication Adapterto

support other forms of user authentication, such as certificates or biometrics.

The TivoliAccess Manager for Enterprise Single Sign-on Kiosk Adapterto supportmulti-user workstations where automated logoff and other multi-user security functions arerequired.

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 andSettings\\Application Data\passlogix\secrets with an .sso extension.

Note that where the TAM E-SSO: Provisioning Adapteris being used (either by itself or with

Tivoli Identity Manager) the Tivoli Access Manager for Enterprise Single Sign-on agent alsoincludes the TAM E-SSO: Provisioning Adapter client to allow the synchronization of user

credentials.


5/24


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 AccessManager 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-onAdministrative 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 EnterpriseSingle 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 avariety 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 isneeded by the agent. This includes the application-supported list, mainframe/host

application supported list, first-time use setup instructions, Password Policies, and AdminOverrides. All of these settings control agent behavior.

The SSO user containerholds the SSO user information, such as SSO credentials. This

can be separate from the normal OS user container (as shown with theOU=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 eachuser object in the CN=Users container.


6/24


Figure 3 SSO Users under normal User container

For details about how to use the console and repository schema, see the Tivoli AccessManager 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 withcentralized 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 forEnterprise Single Sign-on Agent to synchronize the user credentials.

We describe the components in the following sections.
http://publib.boulder.ibm.com/tividd/td/IBMTivoliAccessManagerforEnterpriseSingleSign-On6.0.htmlhttp://publib.boulder.ibm.com/tividd/td/IBMTivoliAccessManagerforEnterpriseSingleSign-On6.0.htmlhttp://publib.boulder.ibm.com/tividd/td/IBMTivoliAccessManagerforEnterpriseSingleSign-On6.0.html


7/24


The TAM E-SSO: Provisioning Adapter serverThe TAM E-SSO: Provisioning Adapter serveris basically a console for managing the entriesheld in the Tivoli Access Manager for Enterprise Single Sign-on Repository. It runs onMicrosoft 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


8/24


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 repositorytype, server, root DN, and user path to define all the users that can be provisioned withSSO credentials.

2. The application list. You configure the TAM E-SSO: Provisioning Adapter with therepository container that includes the application list for which the users can have SSOcredentials. This is the OU=SSOConfig container listed previously.


9/24


The main function of the console is to manage users and their credentials. Figure 6 shows theuser 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 othertwo users have credentials for both the Adobe Acrobat Reader application and the BasicAuth application.

The Users page of the console is displaying (and managing) the user and credential entriesheld 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 managedcentrally through the console.

The TAM E-SSO: Provisioning Adapter ClientThis is also called the TAM E-SSO: Provisioning Adapter Support for SSO Agent. It isinstalled 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: ProvisioningAdapter to be securely sent to and accepted by the Tivoli Access Manager for EnterpriseSingle Sign-on Agent.


10/24


The TAM E-SSO: Provisioning Adapter Client CLIThe 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 CLIis 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 andconnectors 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 EnterpriseSingle Sign-on.

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

TAM E-SSO: Provisioning Adapter.

Figure 7 TAM E-SSO: Provisioning Adapter components

Data

IIS

TAM ESSO

Provisioning

Adapter Server

TAM ESSO

ProvisioningAdapter

Client CLI

Config

Data

SSO Creds

Workstation

TAM ESSOAgent

TAM ESSOPA Client

Config Data &

SSO Creds

/vGO PM Console/

/vGO PM Service/


11/24


Central to the entire provisioning model is the Tivoli Access Manager for Enterprise SingleSign-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 SSOcredentials. This is the UI aspect of the TAM E-SSO: Provisioning Adapter Server that is theASP.NET application running on Microsoft Internet Information Services (IIS). It has two

interfaces: the console interface (/vGO PM Console/) and the Web services interface (/vGOPM 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 securelysynchronizes 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 forEnterprise Single Sign-on provisioning

The previous section discussed how the TAM E-SSO: Provisioning Adapter components canperform 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 anSAP 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 tochange their password for SAP? You can change the password through Tivoli Access

Manager for Enterprise Single Sign-on, where Tivoli Access Manager for Enterprise SingleSign-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 andin 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 Managerfor 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 forEnterprise 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 thestrength of features (role-based provisioning or business process integration through

workflow) that Tivoli Identity Manager does. So, it makes sense to deploy both Tivoli AccessManager for Enterprise Single Sign-on and Tivoli Identity Manager for enterprise identity

management.


12/24


This is the networked deployment with IBM Tivoli Identity Manager provisioningmodel thatwe mentioned previously. Figure 8 illustrates how the products work together.

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

Basically, Tivoli Identity Manager pushes credentials to Tivoli Access Manager for EnterpriseSingle 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 AccessManager 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 wherethat 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 toget 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 distributeTivoli Access Manager for Enterprise Single Sign-on credentials.

Identity Manager LDAP

Identity Manager

Server

Identity Manager DB

Target Target

Target

Provisioning


13/24


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 A person object represents a real world person, such as an employee

or contractor.

Account An account a person can have on a target system, such as anoperating system or application. An account object has a set of

attributes, such as the account ID and password. One person objectcan have zero or more account objects. One account object must have

one and only one person object.

Service The Tivoli Identity Manager definition of a target system user repository

(such as the OS user registry or application user datastore). Theservice object defines how to access the target (such as URL/port for

the Tivoli Identity Manager adapter) and other information for accessingthe user repository (such as the DN of the user store in a directory).

Organizational role A grouping of people objects based on some role definition (for

example, programmer, clerk, or helpdesk). A person object can belongto zero or more roles, and a role can be attached to zero or morepeople.

Provisioning policy This object defines the entitlement for people to have accounts ontarget systems. A provisioning policy defines that Role A can have anaccount 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 organizationalrole), then Tivoli Identity Manager can create an account for you on the target defined by theservice (including provisioning the account down to that target system).

Tivoli Access Manager for Enterprise Single Sign-on objectsWithin Tivoli Access Manager for Enterprise Single Sign-on, there are two levels of dataobjects 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 tothe operating system user for the desktop environment to which you are logging in. You might

be defined asJohn Smith as a person in Tivoli Identity Manager, but you log in to theWindows domain asjsmith 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, ifJohn Smith has a Lotus Notes account ofJohn Smith/Australia/MyCo defined in TivoliIdentity Manager, and John uses Tivoli Access Manager for Enterprise Single Sign-on to loginto Notes, then Tivoli has a Notes SSO credential (including the user ID and password)


14/24


defined in Tivoli Access Manager for Enterprise Single Sign-on that is mapped to the TivoliIdentity Manager account.

Figure 9 shows the user and account object relationships (assuming AD is the domain userregistry and the Tivoli Access Manager for Enterprise Single Sign-on repository).

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 totheir targets: AD, Notes, and SAP.

There is also a relationship between the AD account (in AD), the AD account in Tivoli IdentityManager 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 userentry. 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 (butwith the same user ID as the AD entry). The Notes and SAP SSO credentials are under theSSO 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. TheMaps To link inFigure 9 indicates the logical mapping. The next section discusses this topic.

John Smith

Person

(erPersonItem)

jsmith

AD Account

(erAccountItem)

John Smith/...Notes Account

(erAccountItem)

jasmith

SAP Account

(erAccountItem)

jsmith

AD User

(person)

jsmith

SSO User

(vGOUserData)

John Smith/...Notes SSO Creds

(vGOSecret)

jasmith

SAP SSO Creds

(vGOSecret)

PROVISIONEDTO

RECONCILEDFROM

MAPS

TO

MAPS

TO

MAPS

TO

Notes

SAP

Notes

Account

SAP

Account


15/24


Physically mapping user objectsTivoli 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 userobjects to their Tivoli Access Manager for Enterprise Single Sign-on counterparts:

Extending the TivoliIdentity Manager accountobjectclass (erAccountItem) to includeTivoli 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 vgossouseridattribute is used.

Extending the TivoliIdentity Manager service objectclass (erServiceItem) to include aseries 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 associatedJavaextensions) to take account changes and extract the relevant Tivoli Access Manager forEnterprise Single Sign-on information before passing it to the TAM E-SSO: ProvisioningAdapter 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 AdapterCLI:

vgoadminid The account used to log into the TAM E-SSO: Provisioning

Adapter service.

vgoadminpwd The password for the vgoadminid.

vgoapplicationdescriptionmeta The description for the SSO application.

vgoapplicationidmeta The title (label) of the application, this must be the same asdefined in Tivoli Access Manager for Enterprise SingleSign-on.

vgoapplicationuseridmeta The metadata that describes the SSO credential (forexample, the account ID that is passed to the backendapplication). In this case it is replaced by eruid for the

account in the workflow.

vgossouseridmeta The metadata that describes the SSO user to which this

SSO credential maps. In this case, it is replaced by the uidfrom the person object.


16/24


Figure 10 Modified erServiceItem object in Tivoli Identity Manager

The service form is modified to include these vgo* attributes for each service that is definedas 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 theNotes service.

Notice that the vgoapplicationmeta attribute seems to map to the application name as shownin 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 thisservice as the root service.

This is so the workflow operations can differentiate between the creation or deletion of theSSO user entry and the SSO credentials. The root service is the one where the Tivoli AccessManager 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 accountdeleted, or an account restored). A number of configuration changes have been made toTivoli Identity Manager to allow it to provision to Tivoli Access Manager for Enterprise SingleSign-on:

Many of the standard account operational workflows have been extended to include callsto 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 Adapterfrom the modified workflows.


17/24


We describe these changes in the following sections.

Add Account operational workflowFigure 11 illustrates the modifiedAdd Accountoperational workflow.

Figure 11 Tivoli Identity Manager modified Add Account operational workflow

The standard Add Account operational workflow only has one node: the CREATEACCOUNTExtension 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 theservice 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 rootserviceaccounts.

checkSSO This Script node runs on a successful CREATEACCOUNT operation. Itretrieves and checks (parse) all of the SSO data before setting the values

on the current account (in relevant data).

setSSO This Extension node runs the AddPasslogixCredential operation with an

argument of Account and the account object (from relevant data). If theoutcome of this modification is that the RootService has been set, then theowner's Person object is updated.

modPerson 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 standardmodifyPerson extension.

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 SSOcredentials that match this account.


18/24


Change Password operational workflowFigure 12 illustrates the modified Change Passwordoperational 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 theCHANGEPASSWORD operation. It retrieves the relevant data and checks

the application ID, SSO user ID and application user ID. If the data passesthe parsing, it is set on the current account object and a flag set to continuethe processing.

setSSO This Extension node runs the ChangePasslogixPassword operation with anargument of Account and the account object (from relevant data).

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

Delete Account operational workflowFigure 13 shows the modifiedDelete Accountoperational workflow.

Figure 13 Tivoli Identity Manager modified Delete Account operational workflow

The standard workflow only has theDELETEACCOUNTExtension node.


CheckRootService This Script node checks to ensure that user ID, SSO application ID andSSO admin ID/password are set before deleting the SSO user. The linkout 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 anargument of Account and the account object (from relevant data). Even

if this step fails, the workflow continues to delete the account on thetarget.


19/24


CheckSSO This Script node runs if the delete was successful and the application isnot 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.

setSSO This Extension node runs the DeletePasslogixCredential operation with

an argument of Account and the account object (from relevant data).

If a Root Service account is being deleted, the Tivoli Access Manager for Enterprise SingleSign-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 workflowFigure 14 illustrates the modifiedModify Accountoperational workflow.

Figure 14 Identity Manager modified Modify Account operational workflow

The standard workflow only has theMODIFYACCOUNTExtension node.


checkSSO This Script node retrieves, checks (Parse) and sets the SSO attributes on

the current account object (relevant data).

setSSO This Extension node runs the ModifyPasslogixCredential operation with anargument 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 workflowFigure 15 shows the modifiedRestore Accountoperational workflow.

Figure 15 Identity Manager modified Restore Account operational workflow

The standard workflow only has theRESTOREACCOUNTExtension node.


20/24



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 thepassword has been changed.

checkSSO This Script node retrieves, checks (Parse) and sets the SSO attributes onthe current account object (relevant data). It is only run if the isSSO flag istrue (for example, password has been changed).

setSSO This Extension node runs the ChangePasslogixPassword operation with anargument of Account and the account object (from relevant data). It is onlyrun if the isSSO flag is true (for example, password has been changed).

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

Suspend Account operational workflowThere are no changes to the Suspend Accountoperational workflow.

Custom extensions in operational workflowTable 1 shows the custom workflows use the custom extensions.

Table 1 Custom extensions in operational workflow

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 ServerenRole.ear directory (for example, the Tivoli Identity Manager application code tree). This isalso called the Tivoli Identity Manager Provisioning Workflow Interface Connector.

This .jar file includes a configuration file: PMClientConfiguration.properties. Among thesettings 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 This is the URL to which the server service is listening (forexample, http://adserver/v-GO PM Service/UP.asmx).

javaCLI.serviceuser The administrative user that is used to access the service(for example, odi\tamespa).

javaCLI.serviceuserpassword 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 ApplicationServer.

The next section summarizes how the components work together.

Extension Argument Used in

AddPasslogixCredential Account Add Account (setSSO)

ChangePasslogixPassword Account Change Password (setSSO),

Restore Account (setSSO)

DeletePasslogixUser Account Delete Account (DeleteSSOUser)

DeletePasslogixCredential Account Delete Account (setSSO)

ModifyPasslogixCredential Account Modify Account (set SSO)


21/24


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.

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 IdentityManager directory. Changes to accounts trigger operational workflows that have been

customized to make calls out to the Tivoli Identity Manager Provisioning Workflow InterfaceConnector (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 ClientCLI libraries to make API calls to the TAM E-SSO: Provisioning Adapter Server.

Tivoli Identity Manager ApplicationPMAPIInvoker-6.0.jar

AddPasslogixCredential

ChangePasslogixPassword

DeletePasslogixUser

DeletePasslogixCredential

ModifyPasslogixCredential

call

PMClientConfiguration.properties

call

PMAPI.jar(and assoicated

TAM ESSO PA

Client CLI

libraries)

/vGO PM Service/

Service

- Service attribs.- vGO SSO attribs

Account

- Account attribs.- vGO SSO attribs

Service

- Service attribs.- vGO SSO attribs

Service

- Service attribs.

- vGO SSO attribs

Account

- Account attribs.- vGO SSO attribs

Account

- Account attribs.

- vGO SSO attribs

Tivoli Identity Manager Directory

(LDAP)


22/24


The complete picture

Figure 17 shows all components involved in the integration (combining Figure 7 on page 10

and Figure 16 on page 21).

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 relevantExtension 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 l ibraries and

the server definitions in the PMClientConfiguration.properties file to send a Web servicescall to the TAM E-SSO: Provisioning Adapter Server.

The server adds the credentials (and optionally adds the SSO user entry) to the SSORepository.

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. Ifthere have been problems with the extensions, the API calls or the TAM E-SSO: ProvisioningAdapter Server, and the error messages are recorded in the transaction history.

This completes the discussion of the Tivoli Identity Manager and Tivoli Access Manager forEnterprise Single Sign-on provisioning integration.

Tivoli Identity Manager ApplicationPMAPIInvoker-6.0.jar

AddPasslogixCredential

ChangePasslogixPassword

DeletePasslogixUser

DeletePasslogixCredential

ModifyPasslogixCredential

call

PMClientConfiguration

.properties

call

PMAPI.jar

(and assoicated

TAM ESSO PA

Client CLI

libraries)

Service- Service attribs.

- vGO SSO attribs

Account- Account attribs.

- vGO SSO attribs

Service

- Service attribs.

- vGO SSO attribs

Service- Service attribs.

- vGO SSO attribs

Account

- Account attribs.

- vGO SSO attribs

Account- Account attribs.

- vGO SSO attribs

Tivoli Identity Manager Directory

(LDAP)

/vGO PM Service/


23/24

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

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. Consultyour 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 IBMproduct, program, or service may be used. Any functionally equivalent product, program, or service that doesnot infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility toevaluate 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. Thefurnishing of this document does not give you any license to these patents. You can send license inquiries, inwriting, 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 suchprovisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATIONPROVIDES 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 ofexpress 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 madeto the information herein; these changes will be incorporated in new editions of the publication. IBM may makeimprovements and/or changes in the product(s) and/or the program(s) described in this publication at any timewithout notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 withoutincurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirm theaccuracy of performance, compatibility or any other claims related to non-IBM products. Questions on thecapabilities 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 themas 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 businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programmingtechniques 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 applicationprograms conforming to the application programming interface for the operating platform for which the sampleprograms 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.


24/24

Redpaper

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:

[email protected] Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400 U.S.A.

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

Adobe, Acrobat, and Portable Document Format (PDF) are either registered trademarks or trademarks ofAdobe 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, othercountries, or both.

Active Directory, Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in theUnited States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.
http://www.redbooks.ibm.com/http://www.ibm.com/redbooks/http://www.redbooks.ibm.com/contacts.htmlhttp://www.redbooks.ibm.com/contacts.htmlhttp://www.ibm.com/redbooks/http://www.ibm.com/redbooks/http://www.redbooks.ibm.com/