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
1
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.
2
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
MANAGE
PROVISION
Identity Manager
PROVISION
TAM E-SSO
Agent
TAM E-SSO
Provisioning
Adapter
H
NC
SY
TAM E-SSO
Agent
SYNCH
SY
NC
H
TAM E-SSO Repository
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
3
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.
4
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
5
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.
6
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
7
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.
8
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
9
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
SSO Creds
Data
Data
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
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 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.
Service
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).
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)
P
RE RO
CO VIS
NC IO
ILE NED
D
FR TO
OM
jsmith
SSO User
(vGOUserData)
MAPS
TO
John Smith/...
Notes SSO Creds
(vGOSecret)
John Smith
Person
(erPersonItem)
jsmith
AD Account
(erAccountItem)
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
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 as
defined in Tivoli Access Manager for Enterprise Single
Sign-on.
vgoapplicationuseridmeta
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.
vgossouseridmeta
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.
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.
checkSSO
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).
setSSO
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.
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 standard
modifyPerson 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 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.
setSSO
This Extension node runs the ChangePasslogixPassword operation with an
argument of Account and the account object (from relevant data).
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
18
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.
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.
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 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
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 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).
setSSO
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).
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
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)
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
This is the URL to which the server service is listening (for
example, 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 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
call
ModifyPasslogixCredential
PMClientConfiguration
.properties
PMAPIInvoker-6.0.jar
Tivoli Identity Manager Application
Service
Service
Serviceattribs.
- Service
- Service attribs.
- Service
attribs.
- vGO
SSO attribs
- vGO SSO attribs
- vGO SSO attribs
Account
Account
Accountattribs.
- Account
- 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/
ChangePasslogixPassword
PMAPI.jar
(and assoicated
TAM ESSO PA
Client CLI
libraries)
DeletePasslogixUser
call
DeletePasslogixCredential
call
ModifyPasslogixCredential
PMClientConfiguration
.properties
PMAPIInvoker-6.0.jar
Tivoli Identity Manager Application
Service
Service
Serviceattribs.
- Service
- Service attribs.
- Service
attribs.
- vGO
SSO attribs
- vGO SSO attribs
- vGO SSO attribs
Account
Account
Accountattribs.
- Account
- 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