Tivoli IAM Install Provision PDF

User provisioning with Tivoli Identity ManagerManage user accounts across multiple computers with ease

Skill Level: Intermediate

Christopher Hockings ([email protected])Advanced Customer Engineering Team Member

12 Sep 2003

The process of creating user accounts and permissions for employees on a diversearray of computers can potentially consume much of an IT department's time andresources. In this tutorial, you'll learn how IBM Tivoli Identity Manager, working inconjunction with other Tivoli products, can help streamline the user provisioningprocess. You'll build a sample application that automatically creates user accountswith appropriate permissions based on data entered into a human resourcesdatabase. The resulting environment also helps the establishment of single sign-onauthentication for the newly provisioned users.

Section 1. Before you start

About this tutorial

This tutorial provides an implementation solution for provisioning of users to acompany's intranet platforms. The solution makes use of the Tivoli Security productsto provide an integrated solution for doing so. Specifically, it highlights an integrationscenario common to many customers environment, where a HR repository controlsthe lifecycle of a user within an organization, and the Tivoli security portfolio providesthe provisioning framework for accounts on internal systems.

In many internal customer environments, a single HR repository holds the masterdefinition of a user. The advantage of deploying Tivoli Identity Manager (TIM)

User provisioning with Tivoli Identity Manager Trademarks© Copyright IBM Corporation 2003. All rights reserved. Page 1 of 16

mailto:[email protected]

http://www.ibm.com/developerworks/ibm/trademarks/

http://www.ibm.com/legal/copytrade.shtml

architecture is that it provides this repository. However, in many situations, the HRrepository is not controlled directly by an organization's identity management team(IMT). This causes the IMT to require a feed of user data from this repository onregistration and de-registration of the user. This tutorial presents a practical solutionto such a scenario using IBM products as follows:

• Tivoli Identity Manager (TIM) - responsible for provisioning of useraccounts for a newly created user.

• IBM Directory Integrator (IDI) - provides a feed of the data from the HRdatabase to the Identity Manager solution.

• Tivoli Access Manager (TAM) - the end point for provisioning ofaccounts for a particular user.

• IBM Directory Server (IDS) - used as the LDAP repository for TIM andTAM as well as for the purposes of simulating a HR feed to the TIMserver through IDI.

Although this tutorial presents a solution for a single scenario, it introduces conceptsthat can be applied to varying customer problems around user provisioning. By theend of the tutorial, you should have a good understanding of the value of the TivoliSecurity portfolio for solving varying customer requirements for user provisioning.

Should I take this tutorial?

Anyone interested in the integration capabilities of the Tivoli Security products (usingTIM and IDI specifically) may be interested in taking this tutorial. It provides you withan overview of many of the concepts surrounding identity management and userprovisioning, and provides an example implementation that makes use of the TivoliSecurity portfolio.

You should have the following skills before you start this tutorial:

• Tivoli Access Manager installation and configuration: This will allowyou to implement a simple agent that provisions user accounts withinTAM.

• Tivoli Identity Manager installation: This tutorial requires you to installand configure the TIM product.

• Simple programming skills: The TIM and IDI products require a basicunderstanding of JavaScript coding. Although this tutorial has minimalcoding requirements, if you want to extend the capabilities of the tutorial'ssample implementation, these skills will be required.

• TIM agent installation and configuration: You should have some

developerWorks® ibm.com/developerWorks




knowledge of installing and configuring TIM agent software.

Prerequisites

In order to successfully complete the steps as demonstrated in this tutorial, you willneed the following:

• A client machine hosting the software for providing the HR data feed tothe TIM infrastructure, which includes the following components:

• IBM Directory Server: This is IBM's LDAP Directory product. Withinthe solution two instances of the IBM Directory Server are deployed:One for simulating the HR feed for TIM, and the other for the directoryto be used by the TIM and TAM products. .

• IBM Directory Integrator: To obtain this software, please consultyour Tivoli sales specialist.

• IBM Tivoli Identity Manager infrastructure. To obtain this software, contactyour local Tivoli sales representative. This infrastructure includes thefollowing software:

• IBM Directory Server is the user data store for TIM and TAM.

• IBM WebSphere MQ is for user provisioning workflow within TIM.

• IBM WebSphere hosts the TIM application.

• Tivoli Access Manager 4.1 Agent is also required within this tutorial forshowing the provisioning capabilities of the TIM product. Agent softwarecan be obtained from your Tivoli sales team.

• You'll also need Access Manager Infrastructure, which includes thefollowing:

• IBM Tivoli Access Manager Base and Policy Server

• IBM Tivoli Access Manager WebSEAL

Note that the TIM and TAM infrastructure will share the IBM Directory for user andgroup storage.

Assumptions

In order to limit the scope of the solution while demonstrating as many concepts aspossible, we've made a number of assumptions about our hypothetical environment:

ibm.com/developerWorks developerWorks®


http://www.ibm.com/software/tivoli/products/directory-server/

http://www.ibm.com/software/tivoli/products/directory-integrator/



• The customer uses an HR database store that can alert othercomponents when updates occur. In this tutorial, we'll use the IDS for theHR store, and use the changelog functionality provided by IDS to notifythe Identity Manager solution when an update occurs.

• Many customers will have their own solution for data feeds out of their HRsystems. In this tutorial we use IDS and IDI to simulate the creation of anaccount and subsequent HR feed to the TIM product.

Section 2. Concepts used in this tutorial

Introduction

Before we launch into our sample application, you should be familiar with someterms. The following sections outlines some concepts that you'll need to understandbefore you can build the architecture outlined in the subsequent sections.

Provisioning

Within TIM, user provisioning is the process of activating and deactivating useraccounts within an organization. The actual provisioning of accounts can be done inone of two ways:

• Automatic provisioning involves the automatic activation of a user'saccount within a managed platform. This activation occurs because theuser's definition satisfies a given set of requirements for such an account.These requirements are set within what TIM calls its provisioning policy.

• Manual provisioning involves the pre-authorization of a user for anaccount on a managed platform. The user satisfies a given set ofauthorization requirements linked to their organizational role. A user is notprovisioned with this account until an administrator creates the accountmanually.

Singlesign-on

Single sign-on (SSO) has different interpretations for different computingenvironments. Within a Web environment, SSO is the ability for a user to





authenticate once and gain access to many different applications. Theseenvironments may have different authentication requirements. Often the concept ofSSO within a Web environment is difficult to achieve, but the introduction of aproduct such as TAM WebSEAL can greatly simplify the problem. As the diagramshows below, WebSEAL has the ability to provide authentication credentials for auser to different applications, thereby removing the need for a user to authenticatemore than once to the Web infrastructure.

This definition is somewhat different in the intranet environment, where manyunrelated, non-Web based platforms require login information to access theirservices. These platforms require vastly different authentication credentials and theplatforms do not share a common protocol, such as HTTP, for client access. Hencethe target for SSO within this type of environment is the ability for a user to have asingle username and password pair for accessing each application. The user is stillrequired to login at each environment, however, this username and passwordmanagement is centralized within the user provisioning software. Likewise, thecreating and deletion of the account is also offloaded, thereby reducing the risk ofdefunct accounts on platforms. TIM attempts to provide SSO for intranet applicationsuch as these through the management of a single username and password for allmanaged platforms.

Once TIM is deployed, the end user is able to change their password within thecentral TIM server from a Web browser. The TIM server will then push this passwordchange out to each of the managed platforms the user has an account on.Thereafter, the management of passwords for intranet platforms is offloaded to theTIM server.

Although this tutorial does not address specifically the SSO capabilities of the twoproducts, the above diagrams may give you an understanding of the SSO conceptaddressed by the Tivoli products.

Agents

Agents are lightweight applications, usually written in C, that run on a managedendpoint. They provide TIM with the capability to manage user-provisioningendpoints. Agents are used for provisioning, de-provisioning, and modification of theuser accounts on the managed platforms. A command-line agent development kit isavailable in release 4.4 of TIM. The TIM server communicates with each configuredagent using a dialect of XML called DAML (see Resources for the DAMLspecification). The diagram below shows the operations that can be delegated to anagent. For debugging purposes, the administrator can view the format of messagesbetween agent and server by enabling debug trace within the agent software.Consult the TIM Agent administration guides for details on how to do this.





HR feed

In most customer environments, the business has a legacy HR system that isseparate from their provisioning software. This software generally contains functionsfor sending user information to an application target. Many HR vendors attempt tosell Identity Management products based on this concept only. This tutorial uses anIDI connector to TIM to illustrate how data from a simulated HR database can feedan identity management product.

TIM requires specific attributes to be prefilled in order to automatically create suchaccounts. These can be extracted from the HR system as required. Although thistutorial illustrates the use of IBM LDAP as the feed mechanism, it is left as anexercise for the HR system to provide the feed required by the TIM service.

Workflow

A workflow defines an authorization process for provisioning of user accounts withina computing environment. Consider an example: when a user is to be provisionedwith a new account, a manager or the owner of that infrastructure needs to approvethe creation of the account. The Identity Manager product contains this functionalityand leverages the strong workflow capabilities provided by IBM MQ Workflow.

The following diagram shows a typical organization's workflow process, where auser is requesting permission for an account with the Tivoli Access Managerinfrastructure. In this workflow definition, the TAM administrator is required toauthorize the creation of a new account.





The process flow is as follows:

1. The HR administrator requests the creation of an account.

2. The TIM server recognizes that a workflow is configured for the provisionof accounts to the TAM service. The LDAP server is queried for theworkflow details. The TIM server uses MQ Workflow for enforcement ofworkflow process.

3. The TIM server sends a request to the SMTP mail server to notify theTAM administrator that a create account request has been initialized.

4. The TAM administrator receives an e-mail message that contains anHTTPS link to the approval page within TIM.

5. The TAM administrator accepts the request by authorizing the creation ofaccount.

6. The TIM server now provisions the account by sending a DAML createcommand to the agent.

7. The user is now able to administer his TAM account within TIM, providedhe already has a TIM account.

Assembly line





An assembly line is a term used within IDI, and is a collection of processes thatoperate sequentially when a particular event is triggered. In this tutorial, theassembly line is made up of the following components:

An assembly line can be made up of any number of connectors. The order of theconnectors is defined within the assembly line. The above example illustrates aninput connector, followed by an iterator, followed by an output connector. Ourexample will illustrate an assembly line equivalent to the one diagrammed above.

Section 3. Example implementation overview

Example customer scenario

This tutorial outlines a solution for a company that requires provisioning of accountsto a Web-based intranet environment as well as a desktop environment. Thecustomer has a HR system that uses IBM LDAP as the user store. A user isrepresented within this system as a simple inetorgperson object. The customerrequires that the HR data not be used directly by any other system, and that the IMTuse a data feed from this HR environment to extract modified information. The IMT isusing TIM for the identity management solution. This system feeds accounts into theWeb-based intranet, which is controlled by Tivoli Access Manager, and also into aWindows NT domain. The system resembles the diagram below (the payroll systemor the NT domain agent are not discussed in this tutorial).

As an example of how SSO is achieved once user provisioning occurs, the followingdiagram shows how a TAM infrastructure can provide SSO as a result of theprovisioning of the account on the TAM agent. Integration of the Siebel and SAPAgents within the solution, accounts can be set-up on these infrastructures so thatSSO can be performed more easily by WebSEAL.

In addition to the TIM SSO enablement, by using the TAM for WebLogic and TAMfor WebSphere products, SSO is enhanced further. User management on theseplatforms is offloaded from TAM to TIM and results in the following.

For more information about the integration solutions certified within Tivoli, go to theTivoli Integration Factory Web site (see Resources).





Section 4. Preparing your systems

Configuringthe changelog on the LDAP server

IBM Directory Server provides the capability to notify clients of changes to LDAPdata. This capability requires the configuration of the changelog within the directory.After successfully configuring the LDAP directory in accordance with normalinstallation procedures, follow these instructions to configure the changelog for clientnotification:

1. Run the IBM Directory Server Configuration tool.

2. Select Create the DB2 Directory Database and click Next.

3. Check Change Log support within the resulting dialog and click Next.

4. Ensure that the configuration completes successfully.

The directory is now set up to send changelog updates to subscribed clients. In thefollowing sections you'll configure TIM and IDI to take advantage of thesenotifications to provision accounts.

Installation requirements on the IDI machine

The IDI JNDI feed components require the availability of a number of jar files:

• enroleagent.jar

• sslj.jar

• xerces.jar

You can find these files on the TIM server. Copy them to the following directory onthe IDI machine:

C:\Program Files\IBM\IBMDirectoryIntegrator\_jvm\lib\ext

Configuring TAM





The TAM installation will operate seamlessly with the TIM LDAP server; thus, in theexample that follows, we use this server to configure the TAM environment. Followthe installation guides for TAM to configure this product.

This tutorial does not show the agent configuration for TAM. However, theprovisioning policy is described.

The next few sections outline the configuration of the TIM services and provisioningpolicies to enable automatic provisioning of TIM and TAM accounts on the managedplatforms.

Section 5. Configuring Tivoli Identity Manager

Configuring the DSML HR feed service

The following image shows the definition of the identity feed service. This service isdefined to accept a JNDI connection from an external provider -- in our case, the IDIfeed from LDAP. The IDI product will take a changelog request from an LDAPserver, and then send the user data to the TIM server over a JNDI connection.

After accepting the DSML feed type as shown above, the defaults may be accepted,as illustrated in the following image. Note also that this service is created at the IBM





level of the hierarchy. The placement policy is hence null.

Configuring the Access Manager service and provisioningpolicy

The Access Manager service is configured at the root of the organization in theexample (IBM). At the same location in the tree, the provisioning policy is set up toautomatically provision accounts for users in all organizational roles. It is expectedthat the service be installed and automatic provisioning be setup before procedingwith the tutorial. The only addition to the basic configuration is the addition ofautomatic provisioning entitlements parameters.

The following diagram shows the provisioning parameter list for these serviceentitlements. This configuration enables automatic assignment of required fields forthe TAM Agent. Note that no workflow is used in this example.

Section 6. IDI assembly line configurationcomponents

Assembly line definition





In the sections that follow, we'll configure an assembly line with the followingcomponents into the IDI framework:

• A changelog event handler for IBM Directory Server that feeds theconnectors that follow.

• A changelog input connector for triggering the assembly line intooperation. This is known as an iterator connector.

• A lookup connector that searches for the entry that triggered the changelog trigger. This is known as a lookup connector.

• A JNDI connector that feeds the TIM server with the attribute data. This isknown as an output connector.

The following image shows the connectors and event handlers used within thisassembly line.

The following sections outline the configuration of each of the connectors describedabove. Be sure to complete the steps in Preparing your systems before you proceedwith the rest of the tutorial.

The mapping of user attribute data is left as an exercise for you. Within this tutorialthe mapping is basic; however it will give you examples that you can translate to





your specific customer requirements. You can download TIMFeed.xml, the XML IDIfile to assist in your understanding of the assembly line and to give you a startingpoint for implementation of this example. (Note that the XML supplied in this file isslightly different from that shown within the tutorial. The XML file is from a replicatedtest environment, whereas many of the diagrams within this document are sourcedfrom the original proof-of-concept type activity used in developing the tutorial).

Changelog event handler

The following image shows the configuration of the event handler for changelognotifications from IBM Directory Server. Notice that the DN that is used in the HRsystem directory example is c=au,ou=bluepages,o=ibm.com .

The event handler passes the event data to the assembly line, as we'll see in thefollowing panels.

Input data from the LDAPchangelog

The image below shows the definition of the Directory Integrator feed that will beused for provisioning of accounts within Identity Manager. Section 5 showed thedefinition of theDSML Feed service that will accept the data sent from the IDI feedshown below.

A changelog input connector must be defined so that the IDI can subscribe to theIBM LDAP servers changelog updates. This connector is called automatically whena change of data occurs within the LDAP server. As you can see from theconfiguration below, the LDAP server is on the local machine. After configuringchange log support as outlined previously, IBM Directory Server will notify the IDIclient of any changes that occur within LDAP server.

The data must be mapped and passed along the assembly line using the work andconn parameters. Consult the XML file for more information on what is done withinthis example.

Lookup connector configuration on IDI

Once the changelog supplies the DN of the entry that has changed, we need tosearch the LDAP server for the data within that entry. The following image shows thelookup connector within IDI.



TIMFeed.xml



Any data retrieved from the lookup in this connector must be passed to the JNDIconnector to feed the TIM HR service. Once again, consult the XML file what wasdone here.

JNDIconnector as output connector from IDI

Once the required object is found within LDAP, develop an output connector to feedthe data to the TIM server. The following image shows the configuration of a JNDIconnector for the JNDI feed. Note the values used for the JNDI feed parameters.

Section 7. Testing the implementation

Add an LDAP entry





To test the configuration, perform an LDAP add operation within the HR LDAPserver. The following image illustrates how to add an entry within the LDAP serverusing the Directory Management Tool.

Enter user data

Fill in the data for a user and submit as shown in the image below.

In order to test the configuration, check that the user who you just provisioned hasshown up within the TIM server in accordance with the placement rules (in this case,at the base of the hierarchy). The user should also be provisioned automatically witha TAM account to log in to WebSEAL. Use the browser to load the home page of theWebSEAL server, and authenticate using the username and password chosenwithin the automatic provisioning policy of the TAM service definition.

Section 8. Summary

After reading this tutorial, you should have a better picture of the offerings Tivoli haswithin the identity management arena. You saw these products interacting in anexample customer environment. Tivoli Identity Manager performs a central role inthe enablement of user accounts within the environment, while TAM enforcessecurity during system runtime. All of the products come together to form a strongidentity management solution.





Resources

Learn

• The following sites might be useful when considering the products used in thistutorial:

• Directory Integrator home page

• IBM Directory Server home page

• Tivoli Identity Manager home page

• Tivoli Access Manager home page

• Check out Sun's JNDI site

• Learn more about DAML

• Stay current with developerWorks technical events and Webcasts.

Get products and technologies

• Build your next development project with IBM trial software, available fordownload directly from developerWorks.

Discuss

• Participate in the discussion forum for this content.

About the author

Christopher HockingsChristopher Hockings is a member of the Advanced CustomerEngineering team working in the Tivoli Security Business Unit (part ofthe IBM Software Group). He is an expert in providing architecture andintegration solutions for customers using the Tivoli Access Managerproduct suite. This includes building specialized development modulesfor customers based on the Access Manager product suite. Chris was amember of the DASCOM team when it was acquired by IBM. He hasattained bachelor of engineering and bachelor of information technologydegrees from Queensland University of Technology in Australia.



http://www.ibm.com/software/tivoli/products/directory-integrator/

http://www.ibm.com/software/tivoli/products/directory-server/

http://www.ibm.com/software/tivoli/products/identity-mgr/

http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/

http://java.sun.com/products/jndi/

http://www.daml.org

http://www.ibm.com/developerworks/offers/techbriefings/?S_TACT=105AGX14&S_CMP=tut

http://www.ibm.com/developerworks/downloads/?S_TACT=105AGX14&S_CMP=tut

http://www-128.ibm.com/developerworks/community/



Documents

Tivoli IAM Install Provision PDF