Tivoli IAM Install Provision PDF

User provisioning with Tivoli Identity Manager
Manage user accounts across multiple computers with ease

Skill Level: Intermediate Christopher Hockings (hockings@au1.ibm.com) Advanced Customer Engineering Team Member
12 Sep 2003 The process of creating user accounts and permissions for employees on a diverse array of computers can potentially consume much of an IT department's time and resources. In this tutorial, you'll learn how IBM Tivoli Identity Manager, working in conjunction with other Tivoli products, can help streamline the user provisioning process. You'll build a sample application that automatically creates user accounts with appropriate permissions based on data entered into a human resources database. The resulting environment also helps the establishment of single sign-on authentication for the newly provisioned users.
Section 1. Before you start

About this tutorial
This tutorial provides an implementation solution for provisioning of users to a company's intranet platforms. The solution makes use of the Tivoli Security products to provide an integrated solution for doing so. Specifically, it highlights an integration scenario common to many customers environment, where a HR repository controls the lifecycle of a user within an organization, and the Tivoli security portfolio provides the provisioning framework for accounts on internal systems. In many internal customer environments, a single HR repository holds the master definition of a user. The advantage of deploying Tivoli Identity Manager (TIM)
User provisioning with Tivoli Identity Manager Copyright IBM Corporation 2003. All rights reserved.
Trademarks Page 1 of 16
developerWorks
ibm.com/developerWorks
architecture is that it provides this repository. However, in many situations, the HR repository 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 on registration and de-registration of the user. This tutorial presents a practical solution to such a scenario using IBM products as follows: Tivoli Identity Manager (TIM) - responsible for provisioning of user accounts for a newly created user. IBM Directory Integrator (IDI) - provides a feed of the data from the HR database to the Identity Manager solution. Tivoli Access Manager (TAM) - the end point for provisioning of accounts for a particular user. IBM Directory Server (IDS) - used as the LDAP repository for TIM and TAM as well as for the purposes of simulating a HR feed to the TIM server through IDI. Although this tutorial presents a solution for a single scenario, it introduces concepts that can be applied to varying customer problems around user provisioning. By the end of the tutorial, you should have a good understanding of the value of the Tivoli Security 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 (using TIM and IDI specifically) may be interested in taking this tutorial. It provides you with an overview of many of the concepts surrounding identity management and user provisioning, and provides an example implementation that makes use of the Tivoli Security portfolio. You should have the following skills before you start this tutorial: Tivoli Access Manager installation and configuration: This will allow you to implement a simple agent that provisions user accounts within TAM. Tivoli Identity Manager installation: This tutorial requires you to install and configure the TIM product. Simple programming skills: The TIM and IDI products require a basic understanding of JavaScript coding. Although this tutorial has minimal coding requirements, if you want to extend the capabilities of the tutorial's sample implementation, these skills will be required. TIM agent installation and configuration: You should have some
User provisioning with Tivoli Identity Manager Copyright IBM Corporation 2003. All rights reserved. Trademarks Page 2 of 16
developerWorks
knowledge of installing and configuring TIM agent software.
Prerequisites
In order to successfully complete the steps as demonstrated in this tutorial, you will need the following: A client machine hosting the software for providing the HR data feed to the TIM infrastructure, which includes the following components: IBM Directory Server: This is IBM's LDAP Directory product. Within the solution two instances of the IBM Directory Server are deployed: One for simulating the HR feed for TIM, and the other for the directory to be used by the TIM and TAM products. . IBM Directory Integrator: To obtain this software, please consult your Tivoli sales specialist. IBM Tivoli Identity Manager infrastructure. To obtain this software, contact your local Tivoli sales representative. This infrastructure includes the following 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 for showing the provisioning capabilities of the TIM product. Agent software can be obtained from your Tivoli sales team. You'll also need Access Manager Infrastructure, which includes the following: 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 and group storage.
Assumptions
In order to limit the scope of the solution while demonstrating as many concepts as possible, we've made a number of assumptions about our hypothetical environment:
developerWorks
The customer uses an HR database store that can alert other components when updates occur. In this tutorial, we'll use the IDS for the HR store, and use the changelog functionality provided by IDS to notify the Identity Manager solution when an update occurs. Many customers will have their own solution for data feeds out of their HR systems. In this tutorial we use IDS and IDI to simulate the creation of an account 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 some terms. The following sections outlines some concepts that you'll need to understand before you can build the architecture outlined in the subsequent sections.
Provisioning
Within TIM, user provisioning is the process of activating and deactivating user accounts within an organization. The actual provisioning of accounts can be done in one of two ways: Automatic provisioning involves the automatic activation of a user's account within a managed platform. This activation occurs because the user'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 an account on a managed platform. The user satisfies a given set of authorization requirements linked to their organizational role. A user is not provisioned with this account until an administrator creates the account manually.
Singlesign-on
Single sign-on (SSO) has different interpretations for different computing environments. Within a Web environment, SSO is the ability for a user to
developerWorks
authenticate once and gain access to many different applications. These environments may have different authentication requirements. Often the concept of SSO within a Web environment is difficult to achieve, but the introduction of a product such as TAM WebSEAL can greatly simplify the problem. As the diagram shows below, WebSEAL has the ability to provide authentication credentials for a user to different applications, thereby removing the need for a user to authenticate more than once to the Web infrastructure. This definition is somewhat different in the intranet environment, where many unrelated, non-Web based platforms require login information to access their services. These platforms require vastly different authentication credentials and the platforms do not share a common protocol, such as HTTP, for client access. Hence the target for SSO within this type of environment is the ability for a user to have a single username and password pair for accessing each application. The user is still required to login at each environment, however, this username and password management is centralized within the user provisioning software. Likewise, the creating and deletion of the account is also offloaded, thereby reducing the risk of defunct accounts on platforms. TIM attempts to provide SSO for intranet application such as these through the management of a single username and password for all managed platforms. Once TIM is deployed, the end user is able to change their password within the central TIM server from a Web browser. The TIM server will then push this password change out to each of the managed platforms the user has an account on. Thereafter, the management of passwords for intranet platforms is offloaded to the TIM server. Although this tutorial does not address specifically the SSO capabilities of the two products, the above diagrams may give you an understanding of the SSO concept addressed by the Tivoli products.
Agents
Agents are lightweight applications, usually written in C, that run on a managed endpoint. They provide TIM with the capability to manage user-provisioning endpoints. Agents are used for provisioning, de-provisioning, and modification of the user accounts on the managed platforms. A command-line agent development kit is available in release 4.4 of TIM. The TIM server communicates with each configured agent using a dialect of XML called DAML (see Resources for the DAML specification). The diagram below shows the operations that can be delegated to an agent. For debugging purposes, the administrator can view the format of messages between agent and server by enabling debug trace within the agent software. Consult the TIM Agent administration guides for details on how to do this.
developerWorks
HR feed
In most customer environments, the business has a legacy HR system that is separate from their provisioning software. This software generally contains functions for sending user information to an application target. Many HR vendors attempt to sell Identity Management products based on this concept only. This tutorial uses an IDI connector to TIM to illustrate how data from a simulated HR database can feed an identity management product.
TIM requires specific attributes to be prefilled in order to automatically create such accounts. These can be extracted from the HR system as required. Although this tutorial illustrates the use of IBM LDAP as the feed mechanism, it is left as an exercise 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 within a computing environment. Consider an example: when a user is to be provisioned with a new account, a manager or the owner of that infrastructure needs to approve the creation of the account. The Identity Manager product contains this functionality and leverages the strong workflow capabilities provided by IBM MQ Workflow. The following diagram shows a typical organization's workflow process, where a user is requesting permission for an account with the Tivoli Access Manager infrastructure. In this workflow definition, the TAM administrator is required to authorize the creation of a new account.
developerWorks
The process flow is as follows: 1. 2. The HR administrator requests the creation of an account. The TIM server recognizes that a workflow is configured for the provision of accounts to the TAM service. The LDAP server is queried for the workflow details. The TIM server uses MQ Workflow for enforcement of workflow process. The TIM server sends a request to the SMTP mail server to notify the TAM administrator that a create account request has been initialized. The TAM administrator receives an e-mail message that contains an HTTPS link to the approval page within TIM. The TAM administrator accepts the request by authorizing the creation of account. The TIM server now provisions the account by sending a DAML create command to the agent. The user is now able to administer his TAM account within TIM, provided he already has a TIM account.
3. 4. 5. 6. 7.
Assembly line
developerWorks
An assembly line is a term used within IDI, and is a collection of processes that operate sequentially when a particular event is triggered. In this tutorial, the assembly line is made up of the following components: An assembly line can be made up of any number of connectors. The order of the connectors is defined within the assembly line. The above example illustrates an input connector, followed by an iterator, followed by an output connector. Our example 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 accounts to a Web-based intranet environment as well as a desktop environment. The customer has a HR system that uses IBM LDAP as the user store. A user is represented within this system as a simple inetorgperson object. The customer requires that the HR data not be used directly by any other system, and that the IMT use a data feed from this HR environment to extract modified information. The IMT is using TIM for the identity management solution. This system feeds accounts into the Web-based intranet, which is controlled by Tivoli Access Manager, and also into a Windows NT domain. The system resembles the diagram below (the payroll system or the NT domain agent are not discussed in this tutorial). As an example of how SSO is achieved once user provisioning occurs, the following diagram shows how a TAM infrastructure can provide SSO as a result of the provisioning of the account on the TAM agent. Integration of the Siebel and SAP Agents within the solution, accounts can be set-up on these infrastructures so that SSO can be performed more easily by WebSEAL. In addition to the TIM SSO enablement, by using the TAM for WebLogic and TAM for WebSphere products, SSO is enhanced further. User management on these platforms is offloaded from TAM to TIM and results in the following. For more information about the integration solutions certified within Tivoli, go to the Tivoli Integration Factory Web site (see Resources).
developerWorks
Section 4. Preparing your systems

Configuringthe changelog on the LDAP server
IBM Directory Server provides the capability to notify clients of changes to LDAP data. This capability requires the configuration of the changelog within the directory. After successfully configuring the LDAP directory in accordance with normal installation procedures, follow these instructions to configure the changelog for client notification: 1. 2. 3. 4. Run the IBM Directory Server Configuration tool. Select Create the DB2 Directory Database and click Next. Check Change Log support within the resulting dialog and click Next. Ensure that the configuration completes successfully.
The directory is now set up to send changelog updates to subscribed clients. In the following sections you'll configure TIM and IDI to take advantage of these notifications 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 on the IDI machine:
C:\Program Files\IBM\IBMDirectoryIntegrator\_jvm\lib\ext
Configuring TAM
developerWorks
The TAM installation will operate seamlessly with the TIM LDAP server; thus, in the example that follows, we use this server to configure the TAM environment. Follow the installation guides for TAM to configure this product. This tutorial does not show the agent configuration for TAM. However, the provisioning policy is described. The next few sections outline the configuration of the TIM services and provisioning policies to enable automatic provisioning of TIM and TAM accounts on the managed platforms.
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 is defined to accept a JNDI connection from an external provider -- in our case, the IDI feed from LDAP. The IDI product will take a changelog request from an LDAP server, 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
developerWorks
level of the hierarchy. The placement policy is hence null.
Configuring the Access Manager service and provisioning policy

The Access Manager service is configured at the root of the organization in the example (IBM). At the same location in the tree, the provisioning policy is set up to automatically provision accounts for users in all organizational roles. It is expected that the service be installed and automatic provisioning be setup before proceding with the tutorial. The only addition to the basic configuration is the addition of automatic provisioning entitlements parameters. The following diagram shows the provisioning parameter list for these service entitlements. This configuration enables automatic assignment of required fields for the TAM Agent. Note that no workflow is used in this example.
Section 6. IDI assembly line configurationcomponents

Assembly line definition
developerWorks
In the sections that follow, we'll configure an assembly line with the following components into the IDI framework: A changelog event handler for IBM Directory Server that feeds the connectors that follow. A changelog input connector for triggering the assembly line into operation. This is known as an iterator connector. A lookup connector that searches for the entry that triggered the change log trigger. This is known as a lookup connector. A JNDI connector that feeds the TIM server with the attribute data. This is known as an output connector. The following image shows the connectors and event handlers used within this assembly line.
The following sections outline the configuration of each of the connectors described above. Be sure to complete the steps in Preparing your systems before you proceed with the rest of the tutorial. The mapping of user attribute data is left as an exercise for you. Within this tutorial the mapping is basic; however it will give you examples that you can translate to
developerWorks
your specific customer requirements. You can download TIMFeed.xml, the XML IDI file to assist in your understanding of the assembly line and to give you a starting point for implementation of this example. (Note that the XML supplied in this file is slightly different from that shown within the tutorial. The XML file is from a replicated test environment, whereas many of the diagrams within this document are sourced from 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 changelog notifications from IBM Directory Server. Notice that the DN that is used in the HR system 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 the following panels.
Input data from the LDAPchangelog

The image below shows the definition of the Directory Integrator feed that will be used for provisioning of accounts within Identity Manager. Section 5 showed the definition of theDSML Feed service that will accept the data sent from the IDI feed shown below. A changelog input connector must be defined so that the IDI can subscribe to the IBM LDAP servers changelog updates. This connector is called automatically when a change of data occurs within the LDAP server. As you can see from the configuration below, the LDAP server is on the local machine. After configuring change log support as outlined previously, IBM Directory Server will notify the IDI client of any changes that occur within LDAP server. The data must be mapped and passed along the assembly line using the work and conn parameters. Consult the XML file for more information on what is done within this example.
Lookup connector configuration on IDI

Once the changelog supplies the DN of the entry that has changed, we need to search the LDAP server for the data within that entry. The following image shows the lookup connector within IDI.
developerWorks
Any data retrieved from the lookup in this connector must be passed to the JNDI connector to feed the TIM HR service. Once again, consult the XML file what was done here.
JNDIconnector as output connector from IDI

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

Add an LDAP entry
developerWorks
To test the configuration, perform an LDAP add operation within the HR LDAP server. The following image illustrates how to add an entry within the LDAP server using 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 has shown 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 with a TAM account to log in to WebSEAL. Use the browser to load the home page of the WebSEAL server, and authenticate using the username and password chosen within 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 has within the identity management arena. You saw these products interacting in an example customer environment. Tivoli Identity Manager performs a central role in the enablement of user accounts within the environment, while TAM enforces security during system runtime. All of the products come together to form a strong identity management solution.
developerWorks
Resources
Learn The following sites might be useful when considering the products used in this tutorial: 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 for download directly from developerWorks. Discuss Participate in the discussion forum for this content.
About the author

Christopher Hockings Christopher Hockings is a member of the Advanced Customer Engineering team working in the Tivoli Security Business Unit (part of the IBM Software Group). He is an expert in providing architecture and integration solutions for customers using the Tivoli Access Manager product suite. This includes building specialized development modules for customers based on the Access Manager product suite. Chris was a member of the DASCOM team when it was acquired by IBM. He has attained bachelor of engineering and bachelor of information technology degrees from Queensland University of Technology in Australia.

Tivoli IAM Install Provision PDF

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tivoli IAM Install Provision PDF

Hochgeladen von

Copyright:

Verfügbare Formate

User provisioning with Tivoli Identity Manager

Manage user accounts across multiple computers with ease

Section 1. Before you start

Should I take this tutorial?

knowledge of installing and configuring TIM agent software.

Section 2. Concepts used in this tutorial

Section 3. Example implementation overview

Section 4. Preparing your systems

Installation requirements on the IDI machine

Section 5. Configuring Tivoli Identity Manager

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

Configuring the Access Manager service and provisioning policy

Section 6. IDI assembly line configurationcomponents

Changelog event handler

Input data from the LDAPchangelog

Lookup connector configuration on IDI

JNDIconnector as output connector from IDI

Section 7. Testing the implementation

Enter user data

About the author

Das könnte Ihnen auch gefallen