Embed Size (px)
Citation preview
Tivoli® Identity Manager
Planning for Deployment Guide
Version 4.6
SC32-1708-00
���
Tivoli® Identity Manager
Planning for Deployment Guide
Version 4.6
SC32-1708-00
���
Note:
Before using this information and the product it supports, read the information in Appendix C, “Notices,” on page 97.
First Edition (June 2005)
This edition applies to version 4.6 of Tivoli Identity Manager and to all subsequent releases and modifications until
otherwise indicated in new editions.
This product includes Adaptx, a free XSLT Processor. (C) 1998-2002 Keith Visco and Contributors.
© Copyright International Business Machines Corporation 2005. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Preface . . . . . . . . . . . . . . . v
Who should read this book . . . . . . . . . v
Publications and related information . . . . . . v
Tivoli Identity Manager library . . . . . . . v
Prerequisite product publications . . . . . . vii
Related publications . . . . . . . . . . viii
Accessing publications online . . . . . . . ix
Accessibility . . . . . . . . . . . . . . ix
Support information . . . . . . . . . . . ix
Conventions used in this book . . . . . . . . ix
Typeface conventions . . . . . . . . . . ix
Chapter 1. Getting started with identity
management . . . . . . . . . . . . . 1
How Tivoli Identity Manager fits in the IBM Tivoli
security portfolio . . . . . . . . . . . . . 1
How Tivoli Identity Manager fits in a comprehensive
security solution . . . . . . . . . . . . . 3
Capabilities of Tivoli Identity Manager . . . . . 5
Identity foundation . . . . . . . . . . . 6
Password management . . . . . . . . . . 7
Account access management . . . . . . . . 7
Workflow and life cycle automation . . . . . 8
Auditing and reporting . . . . . . . . . . 9
Distributed administration . . . . . . . . . 9
Role-based access control . . . . . . . . . 10
Self-regulating user administration . . . . . . 11
Benefits of identity management capabilities . . . 11
Professional certification programs . . . . . . 12
Chapter 2. Tivoli Identity Manager
entities and processes . . . . . . . . 15
Identity management paradigm . . . . . . . 15
People . . . . . . . . . . . . . . . 16
Authorization . . . . . . . . . . . . 17
Resources . . . . . . . . . . . . . . 18
Entities . . . . . . . . . . . . . . . . 20
Organization tree . . . . . . . . . . . . 20
Structure of the organization tree . . . . . . 21
Entity relationships . . . . . . . . . . . 21
Access management items . . . . . . . . 23
Reports and auditing . . . . . . . . . . . 24
Reconciliation . . . . . . . . . . . . . 24
Chapter 3. Planning your Tivoli Identity
Manager installation . . . . . . . . . 27
Tivoli Identity Manager configurations . . . . . 27
Tivoli Identity Manager components . . . . . 27
Configuration options . . . . . . . . . . 29
Security planning . . . . . . . . . . . . 32
Security mechanisms . . . . . . . . . . 33
Security zones . . . . . . . . . . . . 33
Performance and availability planning . . . . . 36
Configuration planning . . . . . . . . . . 37
Customization planning . . . . . . . . . . 39
Ensuring secure communication with custom
applications . . . . . . . . . . . . . . 40
Deployment planning . . . . . . . . . . . 42
Chapter 4. Planning to deploy Tivoli
Identity Manager . . . . . . . . . . 45
Creating a project implementation plan . . . . . 45
Why create a project implementation plan? . . . 45
Project team members . . . . . . . . . . 47
Establishing project management guidelines . . 48
Deployment life cycle . . . . . . . . . . . 48
Assessment and planning . . . . . . . . . 48
Solution definition, design, and implementation
plan . . . . . . . . . . . . . . . . 49
Solution implementation . . . . . . . . . 51
Solution adjustments . . . . . . . . . . 52
Defining a customization plan . . . . . . . . 52
Statement of work . . . . . . . . . . . . 54
Determining which identity capabilities to
implement . . . . . . . . . . . . . . . 54
Identity foundation . . . . . . . . . . . 54
Password management . . . . . . . . . 55
Account access management . . . . . . . . 56
Workflow and life cycle automation . . . . . 57
Auditing and reporting . . . . . . . . . 58
Distributed administration . . . . . . . . 59
Role-based access control . . . . . . . . . 60
Self-regulating user administration . . . . . 61
Determining the implementation approach:
top-down or bottom-up . . . . . . . . . . 62
Top-down implementation approach . . . . . 62
Bottom-up implementation approach . . . . . 64
Advantages and disadvantages of the top-down
and bottom-up implementation approaches . . . 66
Deploying Tivoli Identity Manager in phases, using
a bottom-up implementation approach . . . . . 67
Phase 1: Identity foundation, password
management, and account access management . 67
Phase 2: Workflow and life cycle automation,
auditing and reporting, and distributed
administration . . . . . . . . . . . . 68
Phase 3: Role-based access control . . . . . . 69
Phase 4: Self-regulating user administration . . 69
Chapter 5. Preparing data for the initial
identity feed . . . . . . . . . . . . 71
Designing the organization tree . . . . . . . . 71
Usability . . . . . . . . . . . . . . 73
Delegated administration . . . . . . . . . 73
Inheritance of Tivoli Identity Manager objects . . 74
Workflow . . . . . . . . . . . . . . 74
Administrative domains . . . . . . . . . 75
Preparing the person data for the initial identity
feed . . . . . . . . . . . . . . . . . 75
© Copyright IBM Corp. 2005 iii
Loading the data during the initial identity feed . . 76
Reconciling existing accounts with identities loaded
in the initial identity feed . . . . . . . . . . 77
Chapter 6. Post installation planning
considerations . . . . . . . . . . . 79
Reconciliation, self registration, and account
adoption . . . . . . . . . . . . . . . 79
Transfer of knowledge . . . . . . . . . . . 79
Staffing . . . . . . . . . . . . . . . . 80
System tuning . . . . . . . . . . . . . 80
System availability . . . . . . . . . . . . 81
Appendix A. Sample project plan . . . 83
Appendix B. Support information . . . 93
Searching knowledge bases . . . . . . . . . 93
Search the information center on your local
system or network . . . . . . . . . . . 93
Search the Internet . . . . . . . . . . . 93
Obtaining fixes . . . . . . . . . . . . . 94
Contacting IBM Software Support . . . . . . . 94
Determine the business impact of your problem 95
Describe your problem and gather background
information . . . . . . . . . . . . . 95
Submit your problem to IBM Software Support 96
Appendix C. Notices . . . . . . . . . 97
Trademarks . . . . . . . . . . . . . . 98
Glossary . . . . . . . . . . . . . 101
Index . . . . . . . . . . . . . . . 107
iv IBM Tivoli Identity Manager: Planning for Deployment Guide
Preface
The IBM® Tivoli® Identity Manager Planning for Deployment Guide describes the
issues that your organization should consider before installing and integrating the
Tivoli Identity Manager product into your production environment.
Who should read this book
This book is intended for individuals who are responsible for understanding,
overseeing, and managing the integration of a major software product into the
organization’s production environment. These individuals might or might not be
involved in the hands-on tasks that implement the product functions.
Publications and related information
Read the descriptions of the Tivoli Identity Manager library. To determine which
additional publications you might find helpful, read the “Prerequisite product
publications” on page vii and the “Related publications” on page viii. After you
determine the publications you need, refer to the instructions in “Accessing
publications online” on page ix.
Tivoli Identity Manager library
The publications in the Tivoli Identity Manager technical documentation library are
organized into the following categories:
v Release information
v Planning for installation, configuration, and customization
v Online user assistance
v Server installation and configuration
v Problem determination
v Technical supplements
v Adapter installation and configuration
Release Information:
v IBM Tivoli Identity Manager Release Notes
Provides software and hardware requirements for Tivoli Identity Manager, and
additional fix, patch, and other support information.
v IBM Tivoli Identity Manager Documentation Read This First Card
Lists the Tivoli Identity Manager publications.
Planning for installation, configuration, and customization:
IBM Tivoli Identity Manager Planning for Deployment Guide describes the
components, functions, and capabilities of the product, explains how the product
can impact the infrastructure of an organization, recommends guidelines for
managing the implementation of the product, and recommends strategies for
integrating identity management capabilities into a production environment.
Online user assistance:
© Copyright IBM Corp. 2005 v
Provides online help topics and an information center for all Tivoli Identity
Manager administrative tasks. The information center includes information that
was previously provided in the IBM Tivoli Identity Manager Configuration Guide and
the IBM Tivoli Identity Manager Policy and Organization Administration Guide.
Server installation and configuration:
IBM Tivoli Identity Manager Server Installation and Configuration Guide for WebSphere
Environments provides installation and configuration information for Tivoli Identity
Manager.
Configuration information that was previously provided in the IBM Tivoli Identity
Manager Configuration Guide is now included in either the installation guide or in
the IBM Tivoli Identity Manager Information Center.
Problem determination:
IBM Tivoli Identity Manager Problem Determination Guide provides problem
determination, logging, and message information for the Tivoli Identity Manager
product.
Technical supplements:
The following technical supplements are provided by developers or by other
groups who are interested in this product:
v IBM Tivoli Identity Manager Performance Tuning Guide
Provides information needed to tune Tivoli Identity Manager Server for a
production environment. It is available on the Web at:
http://publib.boulder.ibm.com/tividd/td/tdprodlist.html
Click the I character in the A-Z product list, and then, click the IBM Tivoli
Identity Manager link. Browse the information center for the Technical
Supplements section.
v Redbooks and white papers are available on the Web at:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliIdentityManager.html
Browse to the Self Help section, in the Learn category, and click the Redbooks
link.
v Technotes are available on the Web at:
http://www.redbooks.ibm.com/redbooks.nsf/tips/
v Field guides are available on the Web at:
http://www.ibm.com/software/sysmgmt/products/support/Field_Guides.html
v For an extended list of other Tivoli Identity Manager resources, search the
following IBM developerWorks Web site:
http://www.ibm.com/developerworks/
Adapter installation and configuration:
The Tivoli Identity Manager Server technical documentation library includes
documentation for the adapter components of a Tivoli Identity Manager
implementation. Locate adapter documentation on the Web at:
http://publib.boulder.ibm.com/tividd/td/tdprodlist.html
vi IBM Tivoli Identity Manager: Planning for Deployment Guide
Click the I character in the A-Z product list, and then, click the IBM Tivoli
Identity Manager link.
Locate Tivoli Identity Manager adapters on the Web at:
http://www.lotus.com/services/passport.nsf/WebDocs/Passport_Advantage_Home
Skills and training:
Education solutions for Tivoli Identity Manager cover these topics:
v Planning
v Basic and Advanced Administration
v Installation and Configuration
v Workflows
You also have the option of requesting custom training that is tailored to your
needs. For more information, road maps, and schedules, access this IBM Tivoli
Education Web site:
http://www.ibm.com/software/tivoli/education
You can also e-mail these education delivery addresses:
v Americas: [email protected]
v Asia Pacific: [email protected]
v Europe, the Middle East, and Africa (EMEA): [email protected]
Additional skills and technical training information might be available at these
Web sites
v IBM Professional Certification
http://www.ibm.com/certify/
Search on ″identity manager″ to locate available classes and certification
offerings.
v Virtual Skills Center for Tivoli Software on the Web at:
http://www.cgselearning.com/tivoliskills/
v Tivoli Technical Exchange on the Web at:
http://www.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html
Prerequisite product publications
To use the information in this book effectively, you must have knowledge of the
products that are prerequisites for Tivoli Identity Manager Server. Publications are
available from the following locations:
v Operating systems
– IBM AIX®
http://www16.boulder.ibm.com/pseries/en_US/infocenter/base/aix52.htm
– Sun Solaris
http://docs.sun.com/db?q=solaris+9
– Red Hat Linux™
http://www.redhat.com/docs/
Preface vii
– Microsoft® Windows Server™ 2003
http://www.microsoft.com/windowsserver2003/proddoc/default.mspxv Database servers
– IBM DB2 Universal Database™
- Support: http://www.ibm.com/software/data/db2/udb/support.html
- Information center:
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
- Documentation: http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8pubs.d2w/en_main
- DB2® product family: http://www.ibm.com/software/data/db2
- Fix packs:
http://www.ibm.com/software/data/db2/udb/support/downloadv8.html
- System requirements:
http://www.ibm.com/software/data/db2/udb/sysreqs.html– Oracle
http://www.oracle.com/technology/documentation/index.html
http://otn.oracle.com/tech/index.html
http://otn.oracle.com/tech/linux/index.html
– Microsoft SQL Server 2000
http://www.msdn.com/library/
http://www.microsoft.com/sql/v Directory server applications
– IBM Tivoli Directory Server Version 5.2: http://publib.boulder.ibm.com/tividd/td/IBMDS/IDSapinst52/en_US/HTML/ldapinst.htm Version 6.0: http://publib.boulder.ibm.com/infocenter/tiv2help/index.jsp?toc=/com.ibm.IBMDS.doc/toc.xml
– Sun ONE Directory Server
http://docs.sun.com/app/docs/coll/S1_DirectoryServer_52v IBM WebSphere® Application Server
Additional information is available in the product directory or Web sites. http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp http://www.redbooks.ibm.com/
v WebSphere embedded messaging
http://www.ibm.com/software/integration/wmq/
v IBM HTTP Server
http://www.ibm.com/software/webservers/httpservers/library.html
Related publications
Information that is related to Tivoli Identity Manager Server is available in the
following publications:
v The Tivoli Software Library provides a variety of Tivoli publications such as
white papers, datasheets, demonstrations, redbooks, and announcement letters.
The Tivoli Software Library is available on the Web at:
http://www.ibm.com/software/tivoli/literature/
viii IBM Tivoli Identity Manager: Planning for Deployment Guide
v The Tivoli Software Glossary includes definitions for many of the technical terms
related to Tivoli software. The Tivoli Software Glossary is available from the
Glossary link of the Tivoli Software Library Web page at:
http://publib.boulder.ibm.com/tividd/glossary/tivoliglossarymst.htm
Accessing publications online
IBM posts publications for this and all other Tivoli products, as they become
available and whenever they are updated, to the Tivoli software information center
Web site. Access the Tivoli software information center at the following Web
address:
http://publib.boulder.ibm.com/tividd/td/tdprodlist.html
Click the I character in the A-Z list, and then click the IBM Tivoli Identity
Manager link to access the product library.
Note: If you print PDF documents on other than letter-sized paper, set the option
in the File → Print window that allows Adobe Reader to print letter-sized
pages on your local paper.
Accessibility
The product documentation includes the following features to aid accessibility:
v Documentation is available in convertible PDF format to give the maximum
opportunity for users to apply screen-reader software.
v All images in the documentation are provided with alternative text so that users
with vision impairments can understand the contents of the images.
Support information
If you have a problem with your IBM software, you want to resolve it quickly. IBM
provides the following ways for you to obtain the support you need:
v Searching knowledge bases: You can search across a large collection of known
problems and workarounds, Technotes, and other information.
v Obtaining fixes: You can locate the latest fixes that are already available for your
product.
v Contacting IBM Software Support: If you still cannot solve your problem, and
you need to work with someone from IBM, you can use a variety of ways to
contact IBM Software Support.
For more information about these ways to resolve problems, see Appendix B,
“Support information,” on page 93.
Conventions used in this book
This reference uses several conventions for special terms and actions and for
operating system-dependent commands and paths.
Typeface conventions
This guide uses the following typeface conventions:
Bold
Preface ix
v Lowercase commands and mixed case commands that are otherwise
difficult to distinguish from surrounding text
v Interface controls (check boxes, push buttons, radio buttons, spin
buttons, fields, folders, icons, list boxes, items inside list boxes,
multicolumn lists, containers, menu choices, menu names, tabs, property
sheets), labels (such as Tip:, and Operating system considerations:)
v Keywords and parameters in text
Italic
v Words defined in text
v Emphasis of words (words as words)
v New terms in text (except in a definition list)
v Variables and values you must provide
Monospace
v Examples and code examples
v File names, programming keywords, and other elements that are difficult
to distinguish from surrounding text
v Message text and prompts addressed to the user
v Text that the user must type
v Values for arguments or command options
x IBM Tivoli Identity Manager: Planning for Deployment Guide
Chapter 1. Getting started with identity management
Tivoli Identity Manager is a key component in a suite of products that control
costs, automate and streamline processes and procedures, improve stakeholder
satisfaction, and mitigate risk throughout an organization. Tivoli Identity Manager
alone does not address all aspects of a comprehensive security architecture.
However, when implemented as one of a suite of security products, Tivoli Identity
Manager plays a key role in:
v Ensuring that resources are accessible only to authorized persons
v Safeguarding the accuracy and completeness of information processing methods
v Ensuring that authorized users have access to information and associated assets
when needed or required
Use this guide to understand how Tivoli Identity Manager can centralize and
streamline the provisioning of resources in a secure environment, and how to
prepare your environment to begin using Tivoli Identity Manager in an efficient
and cost-effective manner.
This chapter describes:
v “How Tivoli Identity Manager fits in the IBM Tivoli security portfolio”
v “How Tivoli Identity Manager fits in a comprehensive security solution” on
page 3
v “Capabilities of Tivoli Identity Manager” on page 5
v “Benefits of identity management capabilities” on page 11
v “Professional certification programs” on page 12
How Tivoli Identity Manager fits in the IBM Tivoli security portfolio
A comprehensive security solution can be understood as a hierarchy of security
elements, where each element in the hierarchy provides a level of protection that
enables the next level to extend the scope of the security solution. Figure 1 on page
2 illustrates how IBM Tivoli security products work together to build a
comprehensive security solution.
© Copyright IBM Corp. 2005 1
The base of the hierarchy represents critical data resources, including directories
and databases, that contain sensitive and confidential information. The IBM Tivoli
Risk Manager and IBM Tivoli Security Compliance Manager products help
establish a front-line defense against unauthorized users and hackers. These
products provide the tools that help you monitor and respond to the everyday,
ongoing invasion of these data resources. This level of security is fundamental to
enabling your organization to focus and address more complex security
management issues.
The next level of the security hierarchy is represented by the identity data
infrastructure. The products shown at this level, IBM Tivoli Directory Integrator
and IBM Tivoli Directory Server, enable your organization to standardize the
different formats of data repositories that are located throughout your organization.
By providing a means for standardizing these disparate data formats, these
products can help you create a virtual directory of user information that is
centrally maintained and used by the suite of identity applications.
The next level of the security hierarchy is represented by the integrated identity
applications, IBM Tivoli Access Manager, IBM Tivoli Identity Manager, and IBM
Tivoli Privacy Manager.
IBM Tivoli Access Manager enables your organization to use centralized security
policies for specified user groups to manage access authorization throughout the
network, including the vulnerable, internet-facing Web servers. IBM Tivoli Access
Manager can be tightly coupled with IBM Tivoli Identity Manager to reconcile user
groups and accounts managed by IBM Tivoli Access Manager with the identities
managed by Tivoli Identity Manager to provide an integrated solution for resource
access control.
IBM Tivoli Identity Manager centralizes user access to disparate resources in an
organization and implements additional policies and features that streamline
operations associated with user-resource access. As a result, your organization
realizes numerous benefits, including:
IBM TivoliFederated Identity Manager
IBM Tivoli Directory Server
IBM Tivoli Directory Integrator
IBM TivoliIdentity Manager
Identityapplications
Identity datainfrastructure
IBM TivoliRisk Manager
IBM TivoliSecurity Compliance
Manager
IBM TivoliAccess Manager
IBM TivoliPrivacy Manager{
{
Figure 1. IBM Tivoli security products
2 IBM Tivoli Identity Manager: Planning for Deployment Guide
v Enhanced user experience; users can self-administer their passwords using the
rules of a password management policy and the implementation of a single
sign-on to access multiple applications
v Reduced help desk costs
v Increased access security through the reduction of orphaned accounts
v Reduced administrative costs through the provisioning of users using software
automation
v Reduced costs and delays associated with approving resource access to new and
changed users
v Increased auditing capability to help your organization comply with various
internal and governmental auditing requirements
IBM Tivoli Privacy Manager extends the auditing capability of IBM Tivoli Identity
Manager to include real-time monitoring of access attempts to personally
identifiable information (PII). This level of auditing capability enables your
organization to control, record, and document unauthorized access attempts on key
data repositories, and meet the strict requirements for privacy management
required by the Health Insurance Portability and Accountability Act (HIPAA).
The highest level of the security hierarchy represents a broadened scope of identity
management. IBM Tivoli Federated Identity Manager enables your organization to
share services with business partner organizations and obtain trusted information
about third-party identities, such as, customers, suppliers, and client employees.
You can obtain user information without having to create, enroll, or manage
identity accounts with the organizations that provide access to services used by
your organization. Consequently, users are spared from having to register at a
partner site, and from having to remember additional logins and passwords. The
result is improved integration and communication between your organization and
your suppliers, business partners, and customers. These efficiencies lower your
enterprise costs, improve productivity and operational efficiency, and enhance the
user experience.
How Tivoli Identity Manager fits in a comprehensive security solution
To better understand the role of identity management in a security solution,
consider the complexity and breadth of security issues for your organization.
Information in your organization can be compromised in the following ways:
v Identity theft is constantly attempted in unprotected zones of your network.
Tivoli Security Compliance Manager enables your organization to monitor for
and correct security noncompliances, such as user IDs and passwords that do
not conform with the requirements of your security policies.
v Internet traffic is inadequately monitored and regulated, increasing system load
and virus attacks.
Tivoli Risk Manager monitors for attacks, threats, and exposures from the Web
and generates risk alerts and uses detection systems and vulnerability-scanning
tools to increase security.
v Users with multiple accounts compromise security through inadequate credential
management.
Tivoli Identity Manager and Tivoli Access Manager centralize credential
management for user accounts on disparate resources and reconcile these
accounts according to identity policies.
Chapter 1. Getting started with identity management 3
v Users have multiple aliases that are not systematically coordinated and
reconciled to their owners, increasing the potential for orphaned accounts that
have invalid identities and credentials.
Tivoli Identity Manager and Tivoli Access Manager manage and reconcile
associations among users, their aliases, and their accounts, identify orphaned
and invalid accounts, and assign these accounts to owners according to
provisioning policy rules.
v Diverse resources, each with their own user identity and credential rules,
impede thorough accountability for user credentials.
Tivoli Identity Manager and Tivoli Access Manager coordinates and centralizes
the management of identities and accounts on diverse resources, enabling
accountability according to your security policies.
v Multiple user repositories exist that are not reconciled, increasing administrative
complexity and the potential for outdated or orphaned accounts.
Tivoli Directory Server, Tivoli Directory Integrator, and Tivoli Identity Manager
work together to synchronize the management of user repositories and enable
user-resource management from a central location in the network. Managed
accounts are reconciled to the Tivoli Identity Manager directory and orphaned
accounts are identified and assigned to new owners according to provisioning
policy rules.
v Geographical constraints segment administration and increase the potential for
gaps in the management of identities.
Tivoli Identity Manager enables your organization to securely manage identities
on remote resources across geographical boundaries.
v Inadequate detection points in business processes create security gaps that are
not detected by standard auditing monitors.
Tivoli Identity Manager provides built-in and configurable auditing for various
points in the life cycle operations of users.
v Affiliated organizations are not integrated into a security monitoring program.
Tivoli Federated Identity Manager enables your organization to implement
identity management between your organization and partner organizations.
v Personally identifiable information, such as a person’s address and social
security number, is not monitored or audited for access compliance with existing
laws or organizational policy.
Tivoli Privacy Manger enables your organization to monitor, record, and block
access attempts on personally identifiable information, according to specified
privacy policies.
v The organization’s security policy is fragmented, complex, out-dated, or
inadequate.
IBM professional services consultants can work with your organization to create
a comprehensive security solution that meets the needs and goals of your
organization.
To address these and other security issues, create and follow a security
implementation plan using these steps:
1. Survey your entire IT environment to generate a blueprint of your IT
architecture. This information is critical to understanding the security
vulnerabilities of your organization at the physical level.
2. Review all security aspects of your organization, not just your IT security, to
produce a security architecture blueprint that identifies the security areas where
your organization needs to focus.
4 IBM Tivoli Identity Manager: Planning for Deployment Guide
3. Based on the information gathered in the first two steps, create a
comprehensive security policy document that includes the security
requirements and processes that the organization needs to apply internally, as
well as to affiliated organizations and customers.
4. Acquire the software products, in addition to Tivoli Identity Manager, that can
implement a security solution that meets the bulk of your security requirements
or meets the most important security requirements.
For more information about these steps, see Chapter 4, “Planning to deploy Tivoli
Identity Manager,” on page 45. To help you identify the security issues that lead to
a solid security architecture and a reliable security policy, use a methodology, such
as the Method for Architecting Secure Solutions (MASS). By applying a
comprehensive methodology, you ensure that the security practices that you adopt
are based on relevant and current research and experience. For more information
about MASS, see Enterprise Security Architecture using IBM Tivoli Security Solutions,
SG24-6014, available through the following IBM Redbooks Web site:
www.redbooks.ibm.com
Capabilities of Tivoli Identity Manager
Tivoli Identity Manager provides an integrated software solution for managing the
provisioning of services, applications, and controls to employees, business partners,
suppliers, and others associated with your organization. Tivoli Identity Manager
provides an infrastructure for managing these diverse entities across platforms,
organizations, and geographies.
You need to carefully prepare a roll-out plan that implements the capabilities of
Tivoli Identity Manager in controlled phases that are consistent with your overall
security objectives. By implementing Tivoli Identity Manager functions in phases,
your organization can quickly realize immediate, short-term benefits of some
capabilities, while systematically introducing more expansive functions that
increase the scope of the product capabilities. In addition, a phased integration
plan ensures that security and system administrators, as well as users, work more
efficiently, adjust readily to each new capability, and execute their responsibilities
more reliably.
To roll out the capabilities of Tivoli Identity Manager in phases, you need to
understand how the various capabilities are related and how each capability builds
upon and uses the other capabilities. You can conceptualize the incremental
capabilities of an identity management solution as a pyramid, as illustrated in
Figure 2 on page 6.
Chapter 1. Getting started with identity management 5
At the base of the pyramid are the resources (users, systems, applications) that you
want to manage with Tivoli Identity Manager. The Tivoli Identity Manager Server
and adapters provide the identity foundation layer upon which all other
capabilities are built.
The Tivoli Identity Manager capabilities include:
v “Identity foundation”
v “Password management” on page 7
v “Account access management” on page 7
v “Workflow and life cycle automation” on page 8
v “Auditing and reporting” on page 9
v “Distributed administration” on page 9
v “Role-based access control” on page 10
v “Self-regulating user administration” on page 11
Identity foundation
The identity foundation capabilities include the representation of the users,
accounts, and resources that you intend to manage in Tivoli Identity Manager.
Additionally, these users, accounts, and resources must be updated using a
bidirectional data flow between the Tivoli Identity Manager Server and those
resources.
Identity foundation
Password management
Account access management
Workflow and life cycle automation
Auditing and reporting
Distributed administration
Role-based access control
Self regulatinguser administration
Managed resources: users, systems, applications
Figure 2. Identity management hierarchy of capabilities
6 IBM Tivoli Identity Manager: Planning for Deployment Guide
To establish the identity foundation data, you must plan, prepare, and configure
the users, organization, and accounts in the Server. Chapter 5, “Preparing data for
the initial identity feed,” on page 71 provides more information about planning for
the initial loading of identity data.
To establish a secure means for communicating with resources in your organization
after the initial data is loaded, Tivoli Identity Manager uses adapters to read, write,
and change user account information both internally as well on the managed
resources. Tivoli Identity Manager provides adapters for many types of accounts,
including LDAP-based user repositories, databases, operating systems, and
pervasive applications, such as IBM Tivoli Access Manager or IBM Lotus Notes®.
You need to incrementally increase the scope of resources that you want to
provision and the order in which you want to bring those resources under an
identity management solution. If your implementation plan requires adapters that
are not provided, IBM professional services consultants can work with you to
create custom adapters that meet your needs.
The greater the number of users, including internal and external users, and the
greater the number of accounts that can be managed, the broader the scope of your
identity management solution. In turn, as you implement each phase of your
implementation plan, the greater the benefits that your organization realizes from
the capabilities of the identity management solution.
Password management
As organizations deploy more and more resources that require access controls, the
number of required passwords increases. This increase poses a risk to your
organization because more users have a tendency to write down the passwords in
order to keep track of them. Additionally, users become frustrated with the
expanded overhead of password management. Password management is the ability
to control password quality and to change passwords throughout an environment.
A costly side effect of increased password management is the load that your help
desk personnel incur to reset forgotten and misplaced passwords. Typically, 40
percent of help desk activity is related to resetting forgotten passwords. Reducing
this help desk load might yield significant cost savings for your organization;
consequently, you can implement a solution for self-administration of passwords
early in your implementation plan for Tivoli Identity Manager.
Requiring substantial password strength ensures data security. Hackers use
effective tools and techniques to discover poorly constructed passwords. Tivoli
Identity Manager password management enables your organization to require,
enforce, and propagate effective password policies, and enables users to manage
the passwords themselves for their accounts. Users can use a Web-based interface,
authorize themselves, and reset or synchronize their passwords on their accounts.
Account access management
An effective account access management solution allows your organization to track
precisely who has access to what information across the organization. Access
control is a critical function of a centralized, single-point provisioning system. In
addition to protecting sensitive information, access controls expose existing
accounts that have unapproved authorizations or are no longer necessary.
Inappropriate accounts can pose one of the most serious threats to your
organization’s security because they cannot be detected as active attacks on
information.
Chapter 1. Getting started with identity management 7
Orphan accounts are active accounts that cannot be associated with valid users.
Improperly configured accounts are active accounts that are associated with valid
users but have been granted improper authorization. These accounts can occur at
any time if your organization allows local administrators to add or modify users
outside of Tivoli Identity Manager.
To control orphan accounts, the provisioning system links together account
information with authoritative information about the users who own the accounts.
Authoritative user identity information is typically maintained in the databases
and directories of human resources.
The ability to control improper accounts is much more difficult. It requires a
comparison of “what should be” with “what is” at the account authority level. The
existence of an account does not necessarily expose its capabilities. Accounts in
sophisticated IT systems include hundreds of parameters defining the authorities;
these are the details that must be controlled by your provisioning system.
Workflow and life cycle automation
When a user becomes affiliated (for example, becomes an employee) with an
organization, the life cycle of the user begins. Your business policies and processes,
whether manual or semi-automated, are then used to provision the user with
access to certain resources based on his role and responsibilities. Over time, the
role and functions of the user change, and your business policies and processes
provision the resources that should now be available to the user. Eventually, the
user becomes unaffiliated with the organization, associated accounts are suspended
and later deleted, and the user’s life cycle in the organization is finished. Tivoli
Identity Manager provides a comprehensive software solution for managing the
life cycle of users in your organization. Using workflows and life cycle rules, Tivoli
Identity Manager ensures that user accounts are managed and documented
accurately and consistently, in a cost-effective manner, in accordance with the
business policies and security goals of your organization.
In order to implement life cycle management, Tivoli Identity Manager operations
must provide two-way information updating at all points in the cycle. For
example, if a local administrator removes a person from an organizational role,
Tivoli Identity Manager must be able to execute the required approval workflows
and make the appropriate changes to the associated accounts on all affected
managed resources. Conversely, if a local administrator changes the parameters of
an account, the reconciliation processes of Tivoli Identity Manager must be able to
detect and judge whether the changes made to the account are consistent with the
rules of the governing policies.
Workflows define activities that implement the business processes of your
organization. You use workflows to customize how accounts are provisioned and
to customize the life cycle management of users and accounts, such as adding,
removing, and modifying users and accounts.
One example of how workflows implement your business processes is access
request approval, which is key to rapidly and accurately changing user access
rights. These parts of workflows enforce your organization’s chain of authority for
allowing access to critical resources. The security architect uses your organization’s
business policies and processes for approving access requests, both manual and
semi-automated, to determine where improvements are needed, and to create the
workflows that replace the slower, less accurate, more costly manual procedures.
8 IBM Tivoli Identity Manager: Planning for Deployment Guide
A complete provisioning workflow system automatically routes requests to the
proper approvers and preemptively escalates to alternate approvers if actions are
not taken on the requests. Request approval workflows can also issue requests for
further information before an end-user request (or a mid-chain approver) can
proceed with the approval request. This automation can transform a process that
takes typically a week to complete to one that takes only minutes, depending on
how the policy is defined.
Some organizations require that information about accounts or background
information is added to the request as it flows through the process. This
information hides unnecessary details from users in the request and approval
process. This information can come from users involved in the process or be
computed or extracted from other systems.
Auditing and reporting
Organizations typically conduct regular audits to ensure the safe, secure, and
legitimate operations of all departments. Internal security audits are part of every
organization, whether conducted by internal security audit teams or by external
auditors analyzing formal bookkeeping. If your organization’s record keeping is
incomplete, inaccurate, or stored in multiple locations, these audits can consume
extensive time and human effort to conduct. To support independent audits of
security practices and procedures in your organization, you must be able to create
centralized audit trails of access requests.
In addition to conducting internal audits, many enterprises must audit business
processes to prove that they are meeting certain requirements that arise from
legislation or other legal actions. The Sarbanes-Oxley act, for example, establishes
that enterprises must maintain information disclosure controls and procedures. In
order to comply with these legal requirements, organizations can implement
software-based auditing controls that enable them to automatically detect and
report access activities to mission-critical or data-sensitive resources. If your
organization is subject to external auditing requirements, the auditing and
reporting capability can enable your organization to implement audit points in
critical information flows, and produce standard and custom reports that
document the use of access controls.
Among the items audit teams look for are orphan accounts or inappropriate access
privileges that exist on mission-critical or data-sensitive systems. These audits
occur from once a quarter to once a week depending on your type of enterprise.
The audit trails that are generated capture all aspects of the administration of
access rights, from access requests to changes in account details.
All organizations depend on reports to understand how effectively their operations
are conducted and how successful they are at meeting their goals and objectives.
Tivoli Identity Manager provides a flexible, robust, and customizable reporting
capability to help you review and respond to the critical information issues that
propel your organization. For detailed information about the Tivoli Identity
Manager reporting capability, refer to the IBM Tivoli Identity Manager Information
Center.
Distributed administration
To increase revenue and remain competitive in an increasingly volatile market
place, enterprises often restructure and form closer ties with business partners and
suppliers. In many cases, competitive enterprises merge, creating the need to
reevaluate business structures and processes to maximize operational efficiencies.
Chapter 1. Getting started with identity management 9
Each time an organization restructures some or all of its operations, it must
consider the impact to its business processes and determine the best ways to
execute the changes. The distributed administration capability directly addresses
the user administration issues of organizational restructuring by providing the
means to implement the access controls that optimize user administration.
Most organizations already realize the benefits and cost savings of user self-service,
such as ATM machines and Internet account access for banking customers.
However, your business process analyses might reveal multiple internal procedures
that involve a cumbersome, time-consuming approval process. For example, some
administrative procedures might be executed manually, where a software solution
would provide a more consistent, responsive, and cost-effective approach to
managing the tasks. To plan for effective distributed management, you must
consider the trade-offs between configuring an end-to-end solution that might
involve customization statements of work, changing the authority structure for
granting user access, and implementing a solution that quickly or more gradually
encompasses your ultimate target user population.
Distributed administration capabilities include the secure distribution of
provisioning tasks, whether manual or automatic, among various organizations.
When you distribute administrative tasks in your organization, you improve the
accuracy and effectiveness of administration and improve the balance of the
organization’s work load. To achieve a high degree of task distribution, your
security solution must support delegated administration and user authentication.
In distributing administrative tasks, where business policy allows, tasks should be
delegated all the way through your organization to the individual level for
self-service and self-enrollment. Delegated administration allows the
responsibilities for using and changing certain access privileges to be pushed down
the organization hierarchy in a controlled manner, and on a need-to-know basis.
Access requests for users, change approvals, and the setting of local policies for
access rights are assigned to individuals within the framework created by the
higher levels of the organization.
If individuals in remote locations administer changes affecting the access rights of
others, your organization must protect access to sensitive and critical resources
through well-defined user authentication policies. For example, remote interfaces
that are accessible to users over the Internet might require stronger authentication
methods than users who operate in trusted security zones. In addition to user
name and password authentication, you might need to implement authentication
tools such as secure sockets layer (SSL) certificates, security tokens, or data
encryption to ensure adequate security.
Role-based access control
In large and expanding organizations, the task of administering user access in a
secure environment is growing more complex and more costly. International
organizations face even greater challenges in administering users across
organizational boundaries and geographies. Access control lists, the standard
administrative tool for grouping users, become more numerous and more
fragmented, increasing the complexity of user-resource management and increasing
the vulnerability of your security solution. The role-based access control capability
can significantly reduce the cost and complexity of user-resource administration for
both internal (intranet) and external (Internet) users by implementing a
comprehensive, policy-based solution that provisions users with resources
according to the security requirements of your organization.
10 IBM Tivoli Identity Manager: Planning for Deployment Guide
Role-based access control uses roles and provisioning policies to evaluate, test, and
enforce your business processes and rules for granting access to users. Key
administrators create provisioning policies and assign users to roles and that define
sets of entitlements to resources for these roles. The role to which a user is
assigned reflects the responsibilities and scope of influence of the user in the
organization.
Role-based access control evaluates changes to user information to determine if the
changes alter the role membership for the user. If a change is needed, policies are
reviewed and changes to entitlements are put in place immediately. Likewise, a
change in the definition of the set of resources in a policy can also trigger a change
to associated entitlements.
Role-based access control includes the following features:
v Mandatory and optional entitlements, where optional entitlements are not
automatically provisioned but can be requested by a user in a group.
v Prerequisite services, where specific services must be granted before certain
access rights are set. For example, Windows NT® rights must be granted prior to
granting Microsoft Outlook® rights.
v Entitlement defaults and constraints, where each characteristic of an entitlement
can be set to a default value, or its range can be constrained, depending on the
capabilities of the entitlement to be granted.
v A single account with multiple authorities governed by different policies can be
created.
v Private, filtered views of information about users and available resources can be
created.
v User authentication approaches that are consistent with internal security policies.
v Distribution of provisioning system components securely over WAN and
Internet environments, which includes the crossing of firewalls.
v User IDs are created using consistent, user-defined algorithms.
Self-regulating user administration
When your organization starts to provision resources across all internal
organizations, you have implemented the self-regulating user administration
capability. In this environment, a change in a user’s status is automatically
reflected in access rights across organization boundaries and across geographies.
Benefits of identity management capabilities
Your organization realizes greater benefits as each identity management capability
is integrated into the production environment. For example, when you implement
distributed administration for key resources, you extend the cost savings that were
realized by password management because you reduce the amount of time
required to provision user accounts. Table 1 shows the amount of time lost by
manually provisioning activities for different internal and external users.
Table 1. Average time for internal and external user provisioning
Elapsed time* Actual time** Time lost
Internal users
Add 10 hours 1 hour 9 hours
Move 14 hours 1 hour 13 hours
Change 9 hours 1 hour 15 minutes 7 hours 45 minutes
Chapter 1. Getting started with identity management 11
Table 1. Average time for internal and external user provisioning (continued)
Elapsed time* Actual time** Time lost
Delete or Disable 10 hours 1 hour 9 hours
External users
Add 10 hours 40 minutes 9 hours 20 minutes
Move 29 hours 1 hour 40 minutes 27 hours 20 minutes
Change 6 hours 40 minutes 5 hours 20 minutes
Delete 8 hours 30 minutes 7 hours 30 minutes
*Elapsed time denotes the period of time from request through resolution using a manual
process.
**Actual time denotes the time spent by the administrator to complete the task.
By carefully implementing and building the capabilities of Tivoli Identity Manager,
your organization can realize numerous benefits, such as:
v Reduced help desk costs and improved service through the self-service of
password changes and access requests.
v Eliminated security threat from active accounts that have no valid owner or
unapproved configurations.
v Improved security and scaling of administrative staff through the division of
workload among administrators that have an accurate knowledge of user access
needs.
v Reduced security risk and auditing costs through the establishment of a
system-of-record for access changes and approvals.
v Improved accuracy and reduced costs associated with the creation and
revocation of user access rights to internal resources and to resources that are
external to your organization.
Professional certification programs
Although you can follow the advice of this guide and use your own knowledge of
your environment to design and implement an identity management solution, you
will likely require assistance from IBM professional services or IBM partner
organizations. For more information about IBM assistance programs, go to the
following Web site, or ask your IBM representative.
www.ibm.com/services/us/index.wss/home
If you desire help in developing in-house identity management expertise, consider
designating one or more individuals to train towards certification. Following are
two examples of certification programs that are developed and used by IBM
professional services and IBM Tivoli partner organizations:
IBM Certified Solution Designer
An IBM Certified Solution Designer can help your organization:
v Create the theoretical and detailed technical design for an application,
solution, infrastructure, or associated project that matches the business
requirement.
v Develop expertise to evaluate and choose between alternative solutions,
and assists with balancing costs with capabilities and priorities.
12 IBM Tivoli Identity Manager: Planning for Deployment Guide
v Identify products, technologies, and processes to be used, and
determines points of required integration and customization.
v Identify sizing and capacity issues, as well as conflicts with existing
processes or environments.
IBM Certified Deployment Professional - Tivoli Identity Manager
An IBM Certified Deployment Professional can help your organization:
v Plan for product installation, configuration, and data management.
v Troubleshoot problems in the roll-out and maintenance of product
functions.
Ask your IBM representative about professional certification programs or go to the
professional certification Web site:
www.ibm.com/certify/certs/tv_index.shtml
Chapter 1. Getting started with identity management 13
14 IBM Tivoli Identity Manager: Planning for Deployment Guide
Chapter 2. Tivoli Identity Manager entities and processes
At its highest level, an identity management solution automates and centralizes the
process of provisioning resources, such as operating systems and applications, to
people in, or affiliated with, an organization. To implement a flexible and scalable
identity management solution, Tivoli Identity Manager uses specific types of
entities and processes to represent identity resources and the relationships between
those resources.
This chapter introduces the terms and concepts that are used to describe Tivoli
Identity Manager entities and processes. Your acquired knowledge of these
concepts and the interactions between Tivoli Identity Manager components will
help you understand how to implement a phased roll-out of Tivoli Identity
Manager capabilities.
This chapter describes:
v “Identity management paradigm”
v “Entities” on page 20
v “Organization tree” on page 20
v “Reports and auditing” on page 24
v “Reconciliation” on page 24
Identity management paradigm
The paradigm for enabling identity automation has three parts: people,
authorization, and resources (see Figure 3 on page 16).
v People are those users that need to use an organization’s resources, such as
employees and contractors. For more information, see “People” on page 16
v Authorization represents the components and processes that manage the way in
which people use these resources. For more information, see “Authorization” on
page 17
v Resources represent the processes and components that manage the resources.
For more information, see “Resources” on page 18
© Copyright IBM Corp. 2005 15
People
Everyone in an organization requires access to resources. Some individuals in your
organization need access to the resources that are managed by Tivoli Identity
Manager. Still other individuals need to be granted permission to use Tivoli
Identity Manager to configure, customize, and administer the entities and
processes that link users to resources.
In Tivoli Identity Manager, identities are used to represent users that need access to
the various resources in the organization. These resources might or might not
include access to Tivoli Identity Manager, which is another resource. Tivoli Identity
Manager uses the following people-related entity types:
Person
A person is someone in an organization (typically an employee) that
requires access to one or more resources. You add users to Tivoli Identity
Manager in order to provision resources to them.
The identifiers associated with a person are defined as attributes on the
person object. For example, this information can include a person’s first,
last, and full name, phone numbers, employee number, supervisor, and
e-mail address.
A person can be located anywhere in the organization tree, which
represents the structure, or hierarchy, of the users of a company. See
“Organization tree” on page 20 for more information.
Business partner person
A business partner person is an individual affiliated with your organization
who is not an employee, such as a contractor or consultant. Typically,
fewer attributes are needed to define a business partner person.
Business partner person sponsor
A business partner person is assigned a sponsor, who administers the
business partner person in Tivoli Identity Manager. Typically, the sponsor
is the manager of the business partner person. The sponsor is assigned to a
business partner person the same way a supervisor is assigned to a person.
Custom person and custom business partner person
A custom person extends the attributes associated with a person. You can
Person
Provisioning policy Workflow
ServiceOrganizationalrole
Entitlement
Identitypolicy
Adapter
Passwordpolicy
People Authorization Resources
Figure 3. Identity automation paradigm: linking people to the resources that they require
16 IBM Tivoli Identity Manager: Planning for Deployment Guide
create a custom person if the attributes of the standard person object do
not adequately define the user types in your organization.
Account
In Tivoli Identity Manager, an account is a set of attributes, for example,
user ID and password, that enable an account owner, such as person, to
access a resource. Account attributes are specific to the managed resource
with which they are associated.
Outside of Tivoli Identity Manager, the privileges that users have are
defined by their memberships in groups. These groups might be for
UNIX® systems, Windows domains, SAP® groups or profiles, or even the
Tivoli Identity Manager application itself. A group is associated with an
account using the group attribute on the account. Tivoli Identity Manager
updates the group lists that are associated with accounts using the
reconciliation function. For information about the benefits of account
management, see “Account access management” on page 7
Groups are defined and managed outside of Tivoli Identity Manager by the
local administrators or application owners using the native system or other
user access tools, such as Tivoli Access Manager, or another access control
mechanism. Tivoli Identity Manager does not create or delete groups on
managed resources, nor does it manage access control lists (ACLs) or
resource access on managed resources.
Authorization
The authorization components and processes enable an organization to grant and
manage user access to resources.
Organizational role
Identities, such as person and business partner person, are added to
organizations and entities that are subsidiaries to an organization:
organizational unit, location, or business partner organization. To control
access to managed resources, such as databases and applications, identities
are assigned to organizational roles.
Organizational roles are a key component in role-based access control. In
Tivoli Identity Manager, organizational roles should be built around your
organization’s needs to efficiently provision people with the tools that they
require. For information about the benefits of role-based access control, see
“Role-based access control” on page 10.
Provisioning policy
A provisioning policy maps people in organizational roles to services that
represent corresponding resources in Tivoli Identity Manager, and then sets
the entitlements that people have when accessing the services.
The provisioning policies you implement must reflect your organization’s
identity management policies in your security plan. In order to implement
effective provisioning policies, you must analyze and document existing
business approval processes in your organization, and determine what
adjustments should be made to those processes to implement an
automated identity management solution.
A provisioning policy provides a key part of the framework for the
automation of identity life cycle management. For more information about
life cycle management, see “Workflow and life cycle automation” on page
8.
Chapter 2. Tivoli Identity Manager entities and processes 17
Entitlement
An entitlement specifies which services are associated with the policy, and
what conditions apply to the entitlement. For example, an entitlement can
specify whether an associated role has access to all instances of a service or
just one specific instance of a service. Entitlements can also have associated
workflows that implement your organization’s approval procedures for
granting access to services.
Workflow
A workflow defines a business process. In an automated identity
management solution, workflows are the primary engines because they
implement access request approval procedures, trigger access to key
resources, generate events for auditing, and enable the tracking of the
status of identities in identity life cycle operations.
You can define two types of workflows: entitlement workflows that apply
to provisioning activities, and operational workflows that apply to entity
types. Entitlement workflows define the business logic that is tied
specifically to the provisioning actions of provisioning policies. A
provisioning policy entitlement ties provisioning actions to entitlement
workflows. Operational workflows define the business logic for the life
cycle processes for entity types and entities. Creating workflows that are
specific to your environment will require programming expertise in
JavaScript and an acquired knowledge of your organization’s identity
management goals. For more information about workflows, see “Workflow
and life cycle automation” on page 8.
Resources
Resources illustrate the relationship between the components and policies that
enable an organization to represent and manage resources in Tivoli Identity
Manager.
Service
Services represent resources, such as operating system platforms, database
applications, or other applications in Tivoli Identity Manager. A service type
defines the schema for a group of managed resources with the same
attributes, for example, Windows 2000 machines or Lotus Notes
applications. You must create service types before you can create a service
for a specific managed resource, even if you only intend to define a single
instance of that service type.
A service type is made available for provisioning in Tivoli Identity
Manager after an adapter and its service profile are installed. The service
profile corresponds to a specific type of adapter, which performs the
administration of accounts on the target systems and applications. For
example, you configure a single Lotus Notes profile for the Lotus Notes
adapter that is installed to communicate with Lotus Notes applications.
Tivoli Identity Manager itself is a service (ITIM Service) and must be
provisioned like any other service to enable people to access and manage
their own Tivoli Identity Manager accounts and personal information. If an
identity is not provisioned with the ITIM Service, that identity cannot
access information in Tivoli Identity Manager.
Adapter
An adapter is a software component that provides an interface between a
managed resource and the Tivoli Identity Manager Server. An adapter
functions as a trusted virtual administrator on the managed resource,
18 IBM Tivoli Identity Manager: Planning for Deployment Guide
performing such tasks as creating user IDs, suspending user IDs, and other
functions that administrators typically perform.
Adapters can reside on the managed resource as an agent-based adapter, or
on the Tivoli Identity Manager Server, as an agentless adapter. Whether an
adapter is agentless or agent-based depends on the type of managed
resource with which the server is communicating.
Adapter-to-server communication typically uses HTTPS to ensure secure
data transmission; however, an adapter can be designed to use other
protocols, such as FTP.
Adapters perform the key function of using the API of a managed resource
to set account attributes and access privileges, as well as retrieving this
information for account reconciliation.
Tivoli Identity Manager provides numerous adapters that are designed to
meet the needs of many enterprises; however, your environment might
require the creation of new adapters. Work with IBM professional services
consultants to determine, plan, and manage the creation and
implementation of new adapters that meet your needs.
Adapters are critical to implementing the following identity management
capabilities:
v “Password management” on page 7
v “Account access management” on page 7
v “Workflow and life cycle automation” on page 8
v “Role-based access control” on page 10
Identity policy
An identity policy specifies the rules for generating user IDs. These rules
enable your organization to ensure that the user IDs for managed resources
are always unique for each managed resource. An identity policy
automatically generates a unique user ID for the services to which it is
applied.
In determining the rules you want to use to automate the identity policies
of your organization, consider the trade-offs between preserving what
might be resource-specific policy rules with which users are familiar, and
implementing a global policy that automatically creates login IDs. Some
services might require the use of rules that you do not want to apply to
other services. In this case, you must apply an identity policy to those
services that override the global identity policy.
An identity policy is defined dynamically using standard JavaScript
functions and programming constructs like loops and conditional branches.
As part of your project planning, consider the programming skills that are
required to implement identity policies.
Tivoli Identity Manager allows you to retain existing policies, establish new
policies for individual services or service types (service policies), and
establish a global identity policy.
Password policy
A password policy sets the rules that all passwords must meet, such as
length, type of characters allowed and disallowed, and the expiration
interval. You can establish password policies to apply to one or more
service types or to all services.
Chapter 2. Tivoli Identity Manager entities and processes 19
After users access services, they can be allowed or required to change the
temporary passwords they are supplied. Their new passwords must then
conform to the rules of the password policy. If your organization uses
different password policies for different types of services, the password
policy function can use combined password rules for all accounts that are
specified.
The first step in implementing comprehensive, automated password
management is determining the existing password rules of your
organization. You can then use this information to decide the password
rules and guidelines for all users that are managed by Tivoli Identity
Manager. For more information about password management, see
“Password management” on page 7.
Entities
An entity is an object for which information is stored. An entity has a unique
name, an associated entity type, and various attributes. The attributes of an entity
are specified and modified in Tivoli Identity Manager, and reflect the organization
and capabilities of the entity. Tivoli Identity Manager allows system administrators
to customize system entities by selectively mapping entity attributes to custom
LDAP class attributes and by creating or modifying entity operations.
Tivoli Identity Manager also allows system administrators to create new operations
for entities and entity types. An operation is a type of action that can be performed
on the entity. Each entity type can have specific operations performed on them.
Operations that are defined for a specific entity type are used by all entities of that
type. However, if an operation is locally defined for a specific entity, the locally
defined operation takes precedence over the entity type operation. The processes
by which these operations are performed are defined as operational workflows.
Refer to the IBM Tivoli Identity Manager Information Center for information about
configuring operational workflows.
Organization tree
One of the most important steps in integrating Tivoli Identity Manager into your
environment is defining an optimal organizational structure. In Tivoli Identity
Manager, the organizational structure is referred to as the organization tree. The
organization tree holds the entities described in “Entity relationships” on page 21.
The organizational structure can influence the overall performance of the IT system
as well as your ability to adapt the structure, if needed, as your business changes.
As much as possible, the organization tree should reflect the organization of the
people responsible for administering the system as well as the mappings between
users and the resources they require.
Depending on the current structure of your organization and your business
objectives, the organization tree that you define in Tivoli Identity Manager might
or might not reflect your current business structure. For example, if you have an
organization structured primarily according to functional requirements, where
users are grouped according to the resources they require, the organization tree
that you define in Tivoli Identity Manager might largely reflect your organization.
If, however, your organization is structured for other purposes, such as levels of
responsibilities, the organization tree in Tivoli Identity Manager might not reflect
that structure on a broad scale.
20 IBM Tivoli Identity Manager: Planning for Deployment Guide
Structure of the organization tree
Tivoli Identity Manager defines the highest branch of an organization tree as
organization. Depending on the desired structure, you can add subsidiary nodes in
any amount, combination, or order in the hierarchy. For example, a location can
either follow or precede an organizational unit. In addition, the organizational
structure can be as deep or as flat is needed.
An organization can contain the following subsidiary nodes:
Organizational unit
Typically this item is used to define a subnode of a higher node in an
organization branch or a location. For example, organizational units can
represent departments in larger organizations or groups of resources.
Business partner organization
Typically this item is used to define an affiliated organization or group of
users that are not employees of the primary organization.
Location
Typically this item is used to group users on the basis of where they are
located, as opposed to how they are affiliated with other users.
Administrative domain
This item is used just as the other organizational structure items are used;
however, the purpose of an administrative domain is to set administration
privileges for domain administrators. One or more domain administrators
can be assigned to an administrative domain; however, only one user can
be assigned administrative privileges to an organizational unit, business
partner organization, or location.
Entity relationships
Figure 4 on page 22 illustrates the logical relationships between the primary
entities that are maintained in the organization tree. See “Identity management
paradigm” on page 15 for more information about these entities and how they are
used to implement identity management capabilities. The following list briefly
describes each entity and its relationship to the other entities.
Chapter 2. Tivoli Identity Manager entities and processes 21
Identity
The identity entity represents a user (such as person and business partner
person) who requires access to resources in your organization. An identity
owns an account to a service and can be associated with one or more roles.
Organizational role
An organizational role entity is assigned to one or more identities when
you implement role-based access control for the resources that are
managed by Tivoli Identity Manager. An organizational role is controlled
by a provisioning policy.
Account
An account entity has a set of attributes, for example, user ID and
password, and is owned by an identity, for example, a person or business
partner person. An account controls access to the specific resource with
which it is associated.
Policy The policy entity represents a set of organizational rules and supplies the
logic that the Tivoli Identity Manager Server uses to manage entities. The
types of policies include provisioning policy, identity policy, and password
policy.
Service
The service entity represents a type of resource, such as an operating
system, or an application, in Tivoli Identity Manager. Access to a service is
controlled through accounts that specify required user credentials.
Workflow
The workflow entity represents a business process that is associated with
an action of a policy. A workflow implements the steps that are required to
approve or disapprove a request, such as a request to provision a person
with a new account.
Organization tree
Organization
Organizationalunits
Locations
Locations
manager, developer user ID, password
operating systems,applications
new employee - regular
apply tocontrolaccess to
apply to
start
assigned to own
Roles Accounts
Services
Workflows
Policies
Identities
A
A
BC
C
CONTAINS:
Figure 4. Tivoli Identity Manager entities and their logical relationships
22 IBM Tivoli Identity Manager: Planning for Deployment Guide
Access management items
The following items are used to manage access to Tivoli Identity Manager
functions:
ITIM user
An ITIM user is a person that has a Tivoli Identity Manager account. In
order for an ITIM user to use Tivoli Identity Manager in any capacity, that
ITIM user must be assigned to an ITIM group.
ITIM group
An ITIM group is a user group in the system to which ITIM users are
assigned. A person cannot be assigned to an ITIM group without first
being assigned a Tivoli Identity Manager account. An ITIM group can
perform designated tasks based on privileges that are granted by an access
control item (ACI). ITIM groups perform management functions on
entities, and on the attributes containing information about entities.
Access control item (ACI)
ITIM groups are granted various types of access to Tivoli Identity Manager
tasks through ACI definitions. An ACI can be applied to an ITIM group or
to a supervisor. It defines three items:
v Types of functions that are granted to the ITIM group or supervisor
v Organization or subsidiary entity types upon which the granted
functions may be performed
v Level in the organizational hierarchy at which the granted functions may
be performed
Supervisor
A supervisor is an individual that automatically has access control over the
current level to which he is assigned in the organization tree, as well as all
of the subnodes of the current level of the organization tree. A person,
organizational unit, or location can be assigned to a supervisor.
Domain administrator
A domain administrator is an ITIM user that is the member of an
administrative domain. The domain administrator serves only the people
and resources in that domain. This user can perform administrative and
provisioning tasks, but is not authorized to perform configuration tasks,
such as create workflows.
Administrator ITIM group
Administrator is the only predefined ITIM group has access to all items
including the associated subunits, policies, and services. Each ITIM user
that is assigned to an administrator ITIM group becomes a system
administrator for your entire organization. The individuals in this group
should have a thorough understanding of the Tivoli Identity Manager
concepts and tasks that are required to integrate the product into your
organization.
ITIM manager
ITIM manager is the only predefined account in Tivoli Identity Manager,
and it has total access to the functions and tasks of Tivoli Identity
Manager. Carefully consider who has access to this account. This account
can be used to create the administrators, ITIM users, and ITIM groups that
control access to Tivoli Identity Manager functions and tasks.
Chapter 2. Tivoli Identity Manager entities and processes 23
Reports and auditing
Reports help address the auditing requirements of outside organizations, such as
the federal government, as well as the auditing requirements of your organization.
For example, the privacy and information disclosure requirements of the Health
Insurance Portability and Accountability Act (HIPAA) might mandate that your
organization maintain certain auditing measures and provide the capability to
document disclosure information.
In addition to meeting auditing requirements, reports provide timely and useful
information for ongoing business operations. To help you meet your reporting and
auditing requirements, the reporting function of Tivoli Identity Manager provides a
large set of default reports and software tools that enable you to create custom
reports. However, your knowledge of the report and audit requirements can be
used to create a custom implementation plan for auditing and reporting.
Your auditing requirements depend largely on your type of enterprise, the types of
regulatory acts that apply to your business, and the specific internal auditing
requirements of your business. Tivoli Identity Manager is designed to enable you
to incorporate detection points in key processes that automatically capture relevant
data, such as the type of activity that occurred, its status, and the time the activity
occurred.
System administrators can view the details about a specific request at any time,
including data that is captured in the audit trail about each approval process for a
specified service.
Audit trails can be customized in workflow designs. JavaScript extensions enable
you to generate the appropriate audit data that signal key points in an overall
process, such as starting and completing a request for services, as well as signal
when specific events in a process have occurred.
Tivoli Identity Manager provides APIs that interface to information about
provisioning policies defined in Tivoli Identity Manager, and interface to the access
granted to an individual task. These APIs can be used effectively to generate audit
data.
Reconciliation
The reconciliation function synchronizes Tivoli Identity Manager user account
information with the user account information maintained in the network of
managed resources (systems and applications). The reconciliation function in Tivoli
Identity Manager allows you to identify areas in your organization that are not
compliant with security policies. For example, the reconciliation process for
accounts on managed resources and accounts that are represented in Tivoli Identity
Manager can reveal orphan accounts as well as improperly configured accounts.
Users can have multiple aliases on various managed resources, and Tivoli Identity
Manager systematically coordinates and reconciles these aliases to their owners. If
you are managing identities for multiple user repositories, the reconciliation
process reduces administrative complexity and the potential for outdated or
orphaned accounts.
When a provisioning policy is defined, the reconciliation function enables the
enforcement of the policy rules and keeps the participating systems (both the Tivoli
24 IBM Tivoli Identity Manager: Planning for Deployment Guide
Identity Manager Server and the repositories of the managed resources) from
potentially becoming a single point of failure.
Refer to the IBM Tivoli Identity Manager Information Center for a description of the
reconciliation process and for information about setting up reconciliation
schedules.
Chapter 2. Tivoli Identity Manager entities and processes 25
26 IBM Tivoli Identity Manager: Planning for Deployment Guide
Chapter 3. Planning your Tivoli Identity Manager installation
This chapter describes issues that you should consider and plan to address before
you attempt to deploy Tivoli Identity Manager into your environment. These issues
include resource planning to:
v Change your existing network infrastructure to configure Tivoli Identity
Manager
v Place Tivoli Identity Manager components according to the security requirements
of your organization
v Maximize system responsiveness and data throughput
v Customize Tivoli Identity Manager to meet the specific identity management
needs of your organization
v Test and deploy Tivoli Identity Manager
This chapter describes:
v “Tivoli Identity Manager configurations”
v “Security planning” on page 32
v “Performance and availability planning” on page 36
v “Customization planning” on page 39
v “Deployment planning” on page 42
Tivoli Identity Manager configurations
This section provides a brief, high-level description of Tivoli Identity Manager
components and prerequisite products, including an overview of basic
configurations that you must consider before installing Tivoli Identity Manager.
Tivoli Identity Manager components
Tivoli Identity Manager manages the life cycle of user accounts on remote
resources, using adapters to communicate with the resources. See “Identity
management paradigm” on page 15 for a description of adapters. The Tivoli
Identity Manager product:
v Runs in a WebSphere Application Server environment, either in a single-server
or clustered configuration
v Stores historical and pending data in a database server
v Stores user account and organizational data in an LDAP directory server
v Provides administration from a client interface in a Web browser that
communicates through an HTTP server, such as IBM HTTP Server, and a
WebSphere Web Server plug-in
A basic configuration is similar to Figure 5 on page 28.
© Copyright IBM Corp. 2005 27
For information about the supported database server, directory server, and HTTP
server products, see the IBM Tivoli Identity Manager Release Notes. For more
information about WebSphere Application Server products, see the additional
documentation cited in “Prerequisite product publications” on page vii.
WebSphere Application Server products
The WebSphere Application Server is the primary component of the WebSphere
environment. The WebSphere Application Server runs a Java virtual machine,
providing the runtime environment for the enterprise application code. The
application server provides containers that specialize in enabling the execution of
specific Java application components.
The Tivoli Identity Manager application runs on a single-server configuration with
the WebSphere Application Server base product. Tivoli Identity Manager
application also runs in a larger cluster configuration that is composed of one or
more WebSphere Application Servers and a deployment manager that manages a
cluster.
Additional server processes run in a WebSphere Application Server environment,
such as the Java Message Service (JMS, sometimes called the jmsserver process or
the JMS server) that provides the WebSphere embedded messaging. The JMS server
enables the Tivoli Identity Manager application to exchange information with other
applications by sending and receiving data as messages.
Database server products
Tivoli Identity Manager stores transactional and historical data in a database
server. For example, the Tivoli Identity Manager provisioning processes use a
relational database to maintain their current state as well as their history.
Tivoli Identity Managerdatabase
IBM HTTP ServerWebSphere WebServer Plug-in
WebSphere Application ServerTivoli Identity Manager ServerJDBC driver
Managed resourceTivoli Identity Manageradapter
Client(browser) } }
}
LDAPdata store
Figure 5. Tivoli Identity Manager components
28 IBM Tivoli Identity Manager: Planning for Deployment Guide
Computers that communicate with the database require a Java Database
Connectivity driver (JDBC driver). A JDBC driver is used to connect a Java-based
application to a database. For example, a JDBC driver enables a Tivoli Identity
Manager Server on a local computer or on another computer to communicate with
the data source. Tivoli Identity Manager supports JDBC driver types that connect
to corresponding databases.
Directory server products
Tivoli Identity Manager stores the current state of the managed identities in an
LDAP directory, including user account and organizational data.
HTTP server and WebSphere Web Server plug-in
An HTTP server, such as IBM HTTP Server, and a WebSphere Web Server plug-in
enable access to the Tivoli Identity Manager Server. The WebSphere Web Server
plug-in is a component that is installed onto an HTTP server to handle incoming
requests and transport them to the appropriate Web resource. The plug-in allows
the Web server to communicate requests for dynamic content, such as servlets, to
the WebSphere Application Server.
E-mail server
An e-mail server is not a required component for the initial installation of Tivoli
Identity Manager Server; therefore it is not shown in Figure 5 on page 28. The
Tivoli Identity Manager Server can send e-mails to users through an e-mail server.
For example, workflow events can trigger e-mail notices for new and modified
users and user accounts. The Tivoli Identity Manager Server uses the simple mail
transport protocol (SMTP) to connect to the e-mail server. If you intend to send
e-mail notices, you need to plan how you want to use the e-mail servers in your
organization to help implement an identity management solution.
Configuration options
Before you install the Tivoli Identity Manager application, you must determine
how to configure WebSphere Application Server, either in a single-server or a
cluster configuration.
Single-server configurations
A single-server configuration includes the WebSphere Application Server base
product and other required applications on one computer. You must ensure that
the computer has the required memory, speed, and available disk space to meet
the workload. Depending on the size and complexity of your environment, a
single-server configuration might not be appropriate to implement a
comprehensive identity management solution. Table 2 on page 36 provides
categories of data that are processed by Tivoli Identity Manager Server. IBM
professional services consultants can use these figures to help you assess your
computing requirements.
Chapter 3. Planning your Tivoli Identity Manager installation 29
A single-server configuration requires the following components and products:
v WebSphere Application Server base product, which includes the WebSphere
embedded messaging server and client
v Tivoli Identity Manager Server
v An HTTP server
v The WebSphere Web Server plug-in
v A directory server
v A database server
v A JDBC driver
Optionally, you can install the WebSphere Application Server base product and the
Tivoli Identity Manager Server on one computer and install all other required
applications on one or more additional computers, in a configuration similar to
Figure 7.
In this configuration, the computer that has the Tivoli Identity Manager Server
requires the following components and products:
v WebSphere Application Server base product, which includes the WebSphere
embedded messaging server and client
v A JDBC driver
The following components and products run on additional computers:
WebSphere Application ServerTivoli Identity Manager ServerIBM HTTP ServerWebSphere Web Server plug-inLDAP data storeTivoli Identity Manager databaseJDBC driver
}
Figure 6. Single-server configuration on one computer
IBM HTTP ServerWebSphere Web Server plug-in
WebSphere Application ServerTivoli Identity Manager ServerJDBC driver
Tivoli Identity Managerdatabase LDAP
data store
}
Figure 7. Single-server configuration on multiple computers
30 IBM Tivoli Identity Manager: Planning for Deployment Guide
v A database server
v A directory server
v An HTTP server
v A WebSphere Web Server plug-in
For tuning recommendations that place applications on separate computers, refer
to the IBM Tivoli Identity Manager Performance Tuning Guide technical supplement.
For more information about a single-server configuration, refer to the IBM Tivoli
Identity Manager Server Installation and Configuration Guide for WebSphere
Environments.
Cluster configuration
A cluster configuration contains WebSphere Application Server nodes, which are
logical groups of one or more application servers on a computer. Nodes reside
within an administrative domain called a cell, which the deployment manager
manages. A node agent manages all managed processes on the node by
communicating with the deployment manager to coordinate and synchronize the
configuration. The deployment manager is the administrative process that provides
a centralized management view and control for all elements in the cell, including
the management of clusters.
Tivoli Identity Manager does not support:
v Vertical cluster configuration that has more than one cluster member within a
WebSphere Application Server node
v Functional cluster configuration that separates workflow processing and user
interface processing on separate machines
In a configuration such as Figure 8 on page 32, each computer shape represents
one WebSphere Application Server node on one computer. The configuration
specifies the deployment manager on one computer. The remaining applications
are configured on additional computers.
WebSphere Application Server also permits you to install both the WebSphere
Application Server base product and the deployment manager on the same
computer. You must ensure that the computer has the required memory, speed,
and available space to meet the additional load.
The following describes the cluster configuration in Figure 8 on page 32:
v On the computer where you want to have the deployment manager, install the
following components and products:
– The deployment manager
– The Tivoli Identity Manager Server
– A JDBC driverv A cluster member is an instance of a WebSphere Application Server in a cluster.
On each cluster member, install the following components and products:
– WebSphere Application Server base product, which includes the WebSphere
embedded messaging server and client
– Tivoli Identity Manager Server
– A JDBC driverv On one or more additional computers that are not in the cluster, install the
following components and products:
– A database server
Chapter 3. Planning your Tivoli Identity Manager installation 31
– A directory server
– An HTTP server and the WebSphere Web Server plug-in
This is an example configuration only. An alternative topology might configure
these components on computers that are all inside the cluster.
For more information about configuring clusters, refer to the IBM Tivoli Identity
Manager Server Installation and Configuration Guide for WebSphere Environments.
Security planning
This section describes:
v Mechanisms that are used to ensure data access and data flow security
v Network security zones that are used in an enterprise environment
v Placement options within network security zones for Tivoli Identity Manager
components
Because Tivoli Identity Manager is designed to integrate into various types and
sizes of IT environments, it is not possible to cover all security scenarios. However,
in general, the security zones described in this section can be easily applied to
various types of security environments.
The placement of Tivoli Identity Manager components within network zones
should reflect the trade-offs of user convenience, system performance, your
existing and planned network infrastructure, and the levels of trust among the
computing components that are required to meet your security requirements.
Although these requirements can seem complex, by understanding the general
existing and desired security requirements of your organization you should be able
to integrate the Tivoli Identity Manager components without difficulty.
Tivoli Identity Manager cell
Tivoli Identity Manager cluster
WebSphere Application Server baseTivoli Identity Manager ServerJDBC driver
}
}
}
IBM HTTP ServerWebSphere Web
Server plug-in
WebSphereApplication ServerNetwork DeploymentJDBC driver
}
LDAP data store
Tivoli Identity Managerdatabase
Figure 8. Cluster configuration on multiple computers
32 IBM Tivoli Identity Manager: Planning for Deployment Guide
Security mechanisms
Because Tivoli Identity Manager can be deployed over untrusted or unsecured
networks, it uses three basic security mechanisms:
Authentication
Tivoli Identity Manager supports the use of X.509 and PKI-based
certificates for secure sockets layer (SSL) authentication. Most Tivoli
Identity Manager components can present unique certificates to any other
component as proof of identity. You can use PKI certificates as well as
X.509 certificates that are issued by a certificate authority.
Certificates are not supplied with this product. Ensure that you plan for
the acquisition, installation, configuration, and updating (certificates expire)
of certificates before you implement Tivoli Identity Manager in a
production environment. To test secure connections between the Tivoli
Identity Manager Server and other components and products that use SSL
authentication, you can use self-signed certificates. Refer to the IBM Tivoli
Identity Manager Information Center for detailed information about
configuring SSL authentication.
Data encryption
After the successful negotiation of an SSL connection, all information is
encrypted before it is sent on the connection. The information can only be
decrypted by the intended recipient using its private key. Database
connections to DB2 UDB do not use SSL authentication; however, the
connection can be configured to use encryption. Refer to the IBM Tivoli
Identity Manager Server Installation and Configuration Guide for WebSphere
Environments for information about configuring the database connection to
use encryption.
Authorization
Because any application can open a connection to a component and present
its own certificate, Tivoli Identity Manager uses privileged user names and
passwords to help ensure that applications (or users) are who they claim to
be. A user name should be known only to two components, because the
authorization user name and password is not sent until an encrypted
session has been established.
The major Tivoli Identity Manager components support these security mechanisms;
however, the mechanisms you configure should depend on where the component
is deployed within the security architecture. Typically, components deployed in
areas of the security infrastructure that have very limited (controlled) access are
less likely to require the strongest security options. Components deployed in less
secure zones, such as an Internet ISP segment or a corporate DMZ, require
stronger security, such as authorization, two-way SSL encryption, and
authentication between the components. In most multiple-DMZ environments, you
can also require that a different port be used to cross each firewall boundary. Using
different ports creates another barrier for intruders wanting to access the most
secure parts of a network segment.
Security zones
The following list describes some types of network security zones that can be
applied to an organization.
Internet (uncontrolled zone)
Typically, the uncontrolled zone is the portion of the global Internet that is
outside the boundaries of your organization. The untrusted zone is the
Chapter 3. Planning your Tivoli Identity Manager installation 33
most vulnerable to security breaches because there might be few or no
controls in place to block intrusions to your intellectual property.
Do not install Tivoli Identity Manager components in an uncontrolled part
of the network. Do not allow Tivoli Identity Manager components to
communicate with one another across an uncontrolled network without
using secure communication mechanisms such as SSL authentication.
Internet DMZ (controlled zone)
The Internet DMZ is an Internet-facing controlled zone that contains
components with which clients may directly communicate. The Internet
DMZ provides a buffer between the uncontrolled internet and your
internal networks. This zone is typically bounded by two firewalls, which
enable you to control:
v Incoming traffic from the internet to hosts in the DMZ
v Outgoing traffic from hosts in the DMZ to the internet
v Incoming traffic from internal networks to hosts in the DMZ
v Outgoing traffic from hosts in the DMZ to internal networks.
Access control software can be deployed in the DMZ to control and
monitor user access to resources in restricted and other controlled zones.
Tivoli Identity Manager integrates with access control software, such as
Tivoli Access Manager, to protect access to the HTTP server that is used by
the Tivoli Identity Manager Server. The access manager product you
implement should work with the bounding firewalls to enable secure
connectivity to Web clients without directly exposing Tivoli Identity
Manager components to potential attacks from the internet. For example, a
user should be able to authenticate to the access management server, and
the access management server then determines which Web applications the
user is authorized to use.
If you do not intend to use integrated software to control access to the
Tivoli Identity Manager Web server, you can increase data security using
reverse proxy servers in each Internet DMZ. Each reverse proxy server can
connect across a firewall to the Web server, which resides in a more
restricted intranet zone.
Production network (restricted zone)
A restricted zone supports functions to which access must be strictly
controlled; direct access from an uncontrolled network should not be
permitted. In a large enterprise, several network zones might be designated
as restricted. As with an internet DMZ, a restricted zone is typically
bounded by one or more firewalls that filter incoming and outgoing traffic.
Plan to place your Tivoli Identity Manager Server components as well as
your back-end servers (that do not directly interact with users) in a
restricted zone.
Intranet (controlled zone)
Typically, a controlled zone, such as a corporate intranet behind one or
more firewalls, is not heavily restricted in use, but an appropriate span of
control is in place to assure that network traffic does not compromise the
operation of critical business functions.
You might need to place certain Tivoli Identity Manager components, such
as the database server or directory server, in the intranet network to
maximize the performance of data throughput or the availability of certain
34 IBM Tivoli Identity Manager: Planning for Deployment Guide
components or applications. In such cases, ensure that you do not
compromise security in accessing these components or in the data flow
between the components.
Management network (secured zone)
In a secured zone, access is tightly controlled and available to only to a
small number of authorized users. Access to one area of the zone does not
necessarily apply to another area of the zone.
Depending on your security requirements, you can establish a secured
zone that allows certain personnel to access specific Tivoli Identity
Manager functions and tasks.
Figure 9 illustrates how Tivoli Identity Manager can be deployed in an enterprise
environment with different security zones. In this illustration, an access control
product, such as Tivoli Access Manager, controls access to Tivoli Identity Manager
functions that are made available through the Web server. In this scenario, the
Tivoli Identity Manager Server uses back-end servers to store data in a different
security zone. In this case, the communication link should use encryption and
authentication to protect the data flow.
For more information about security planning, see Enterprise Security Architecture
using IBM Tivoli Security Solutions, SG24-6014, available through the IBM Redbooks
Web site.
www.redbooks.ibm.com
Managedresource
WebServer
TivoliIdentityManagerServer
Internet(uncontrolled zone)
Intranet(controlled zone)
Internet DMZ(controlled zone)
Production network(restricted zone)
Firewalls
Databaseserver
Admins
Users
Accesscontrolproduct
Directoryserver
Figure 9. Tivoli Identity Manager deployed in an access controlled environment
Chapter 3. Planning your Tivoli Identity Manager installation 35
Performance and availability planning
Tivoli Identity Manager is designed to manage identities and resources that span
different geographies, operating systems, databases, applications, and primary
information repositories, such as human resource directories. Bringing these
elements together within a single identity management framework requires that
you plan for the availability and performance of the key resources without
significantly compromising your security requirements. In such complex networks,
your performance and security experts need to work together to identify the
potential bottlenecks that are caused by application intervention, such as
authorization checking and privacy monitoring, as well as data channeling within
application components and between applications.
Depending on the size and complexity of the resources that are managed by Tivoli
Identity Manager, deploying multiple components and products on a single server
might not allow sufficient data throughput to achieve acceptable performance.
However, for many environments, a single-server configuration can provide a
practical and cost-effective means to incrementally test and introduce Tivoli
Identity Manager functions into the production environment.
For tuning purposes, a cluster can be viewed as a group of single servers.
Depending on the network load that you incur after deploying Tivoli Identity
Manager, it might be feasible to increase processing concurrency and data
throughput using clustering.
To ensure that the considerations for the availability and tuning of Tivoli Identity
Manager are adequately addressed, consult with individuals who have an in-depth
knowledge of:
Java 2 platform and Enterprise Edition (J2EE) application servers
Because Tivoli Identity Manager operates as an application instance in
WebSphere Application Server, thousands of settings are available to help
tune the application server environment for balanced data throughput,
resource availability, and security.
System resource management, including memory, disk, and processor resources
Efficient identity management heavily depends on optimizing the physical
resources available. These experts can be critical in setting a wide range of
resources, including memory buffer pool sizes, page sizings, and thread
limits.
Tivoli Identity Manager application
IBM professional services consultants can work with your organization to
build expertise in tuning Tivoli Identity Manager to maximize
performance. To help determine the processing power required to achieve
acceptable data throughput and system response, you can supply IBM
professional services with the data shown in Table 2. Your estimates of this
data are used to compute the recommended hardware sizings.
Table 2. User and administrator actions that determine processing requirements
Managing person information
Type of task
Number of times
performed
Period (day,
week, month,
quarter, year)
Add person
Change person
36 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 2. User and administrator actions that determine processing requirements (continued)
Delete person
Managing passwords
Change password (password expiration)
Reset password (person forgets password)
Provisioning
Provisioning roles: change a role after the initial
implementation
Provisioning policies: change a policy after the initial
implementation
Administrator, ITIM user, and ITIM group tasks
Reconciling accounts: comparisons of target accounts
to Tivoli Identity Manager accounts
Searching for information: Tivoli Identity Manager
searches, including all queries and lookups, such as
finding a person in the Tivoli Identity Manager
directory
Operating environment
Category Integer value
Number of person information records to be stored in Tivoli Identity
Manager
Number of holidays observed for the entire company
Number of hours in the business day spanning all time zones
Number of target systems for which Tivoli Identity Manager will
provision accounts or manage passwords
Percentage of all users (represented by person information in Tivoli
Identity Manager) whose accounts on target systems are managed by
Tivoli Identity Manager
Number of months that audit data is kept online before it is archived
Number of users, on average, that will log into Tivoli Identity Manager
concurrently (if this is not known, IBM professional services will
estimate a low concurrency and a high concurrency)
Database and directory servers
These repositories play critical roles in maximizing data throughput and
system availability. Hundreds of tuning parameters are available to help
maximize performance.
For more information about tuning Tivoli Identity Manager, refer to the IBM Tivoli
Identity Manager Performance Tuning Guide technical supplement.
Configuration planning
Following is the order of configuration tasks that are performed to set up Tivoli
Identity Manager after installation. These configuration tasks are performed to
integrate Tivoli Identity Manager into any enterprise. For any given configuration
task, you might have to establish a project plan for designing and implementing a
customization task that meets the objectives of your security implementation plan.
For example, establishing the organizational structure used by Tivoli Identity
Manager might require you to implement a data feed channel to establish the
Chapter 3. Planning your Tivoli Identity Manager installation 37
initial organization from the most authoritative database source in your
organization. Typically, this source is the human resources database because it
ensures that all persons are uniquely identified with appropriate credentials.
Consider the time and resources required to complete these steps (including any
customization tasks you identify) as part of your automated identity management
solution:
1. Define the organization tree using the organization, organizational unit,
business partner organization, and location entities.
2. Populate the organization tree with identities, accounts, and account aliases.
3. Create the ITIM groups and access control items that are needed to manage
access to Tivoli Identity Manager functions and tasks.
4. Configure the password self-service, rules, and request and response capability.
5. Define the services that represent the resources, for example, DB2 UDB and
Windows NT, that are managed.
6. Create the provisioning policies and organizational roles that link identities to
the services.
To complete these configuration steps, you must:
v Implement published Tivoli Identity Manager adapters, including defining the
forms and entitlements.
v Design and construct:
– Organization tree
– Person and custom person directory schema
– Business partner organizations
– Administrative domains
– Identity policies
– Services
– Password policies
– ITIM groups including the domain administrators and the administrator ITIM
group
– Access control items
– Organizational roles
– Provisioning policies
– Workflows
– Challenge and responsev Set up reconciliation schedules
In order to provide an enhanced user experience, you can configure Tivoli Identity
Manager and Tivoli Access Manager to use a single sign-on, whereby only one
user ID and password are required to access managed resources from the Web.
Refer to the IBM Tivoli Identity Manager Information Center for information about
configuring Tivoli Identity Manager and Tivoli Access Manager to implement
single sign-on.
38 IBM Tivoli Identity Manager: Planning for Deployment Guide
Customization planning
To fully integrate an automated end-to-end identity management solution, it might
be necessary to determine, plan, and implement various customization tasks that
are tailored to your environment, and which complete the configuration tasks
described in “Configuration planning” on page 37.Tivoli Identity Manager can be
customized at different levels. You can also perform programming tasks that allow
key applications to access Tivoli Identity Manager Server functions using available
APIs. Refer to the IBM Tivoli Identity Manager Information Center for a list of
available APIs. Examples and documentation of the APIs are included in the
ITIM_HOME/extensions/examples and ITIM_HOME/extensions/docs directories.
Customization tasks require additional expertise, such as programming skills and
consultants who have in-depth product knowledge, to complete. Customization
tasks must be designed and planned, and each customization task varies in
complexity and scope. IBM professional services consultants can work with you to
determine which APIs are used to meet your identity management objectives, and
to determine what Java programming resources and process expertise are required
to introduce modifications that use one or more APIs.
Use the following guidelines in planning customization projects within your
overall identity management solution:
v Use an experienced Tivoli Identity Manager customization consultant to assure
that your assessments correctly and completely reflect your goals.
v Advise the affected users about the schedules and implications of customization
projects through formal correspondence.
v Develop scope statements and a statement of work (SOW) and have the Tivoli
Identity Manager customization consultant review these documents for question
and answer work sessions.
v Assign experienced subject matter experts (SMEs) to work with the Tivoli
Identity Manager customization consultant to design and implement the
customization projects.
v Use IBM consultants or other suitably qualified technical consultants to develop
and test the customization code.
Some typical customization tasks that are used to implement identity management
capabilities include:
Identity feed from an authoritative source
The identity feed, described in Chapter 5, “Preparing data for the initial
identity feed,” on page 71, establishes the means to populate, update, and
reconcile the Tivoli Identity Manager database directory that is used to
manage identities and associated entities and policies. The identity feed
can be used to populate the database directory with some or all of the
identities and account aliases.
Technical skills required: IBM Tivoli Directory Integrator assembly line
programming and Tivoli Identity Manager customization training
Reports
Default reports can be modified to meet the documentation needs of your
organization. Additionally, you can design and create new custom reports
using report table data and user-defined filters.
Technical skills required: Tivoli Identity Manager built-in report designer,
or a third-party report designer, such as Crystal Reports Designer
Chapter 3. Planning your Tivoli Identity Manager installation 39
Auditing
Audit points that generate audit events can be incorporated into the
workflows and workflow extensions to capture critical-path audit data.
Technical skills required: Knowledge of JavaScript and Tivoli Identity
Manager implementation principles
Workflows and workflow extensions
Workflow programming tools enable you to automate key aspects of the
provisioning life cycle, specifically the approval processes that your
organization uses.
Technical skills required: Knowledge of JavaScript and Tivoli Identity
Manager implementation principles
Self registration
Self-registration is the capability to create an identity in Tivoli Identity
Manager through a Web interface without having to log in to Tivoli
Identity Manager. This task is performed by an administrator if the identity
is not initially created during the identity feed.
Technical skills required: Knowledge of JavaScript, the use of the
programming APIs in a Java environment, and Tivoli Identity Manager
implementation principles
Custom adapters
Custom adapters are required if you need to provision accounts or manage
passwords on target systems for which Tivoli Identity Manager does not
provide default adapters. IBM Tivoli Directory Integrator is often used to
develop custom adapters because of its flexibility and ease of
implementation.
Technical skills required: Knowledge of the account structure and
operations of the target system, IBM Tivoli Directory Integrator assembly
line programming, Java programming skills, and Tivoli Identity Manager
customization training
Ensuring secure communication with custom applications
If you develop custom applications to access the Tivoli Identity Manager Server,
these applications must adhere to the programming guidelines described in this
section. These guidelines ensure that:
v Security boundaries built into the Tivoli Identity Manager Server are observed
strictly
v Only authorized APIs are used for communication between the server and
custom applications
v Appropriate roles are assigned to users and user groups that use custom
applications to access Tivoli Identity Manager functions
Tivoli Identity Manager shields its core functionality with a layer of manager
enterprise Java beans (EJBs). These EJBs reside in an unprivileged layer of the
Tivoli Identity Manager Server that is illustrated in Figure 10 on page 41.
When the Tivoli Identity Manager Server communicates with a client application,
every manager EJB method takes a signed token from the caller to verify the
caller’s identity, except when the method itself does the authentication. The caller
40 IBM Tivoli Identity Manager: Planning for Deployment Guide
obtains this signed token after authenticating with the Tivoli Identity Manager
Server.
The following types of custom applications can be created to communicate with
the Tivoli Identity Manager Server:
Stand-alone Java client
Deployed as a WebSphere Application Server thin client.
Web application
Deployed outside of WebSphere Application Server. A Web application can
invoke only a specific subset of Tivoli Identity Manager Server APIs.
Enterprise application, same JVM
Deployed in the same server instance (enrole.ear) as the Tivoli Identity
Manager Server.
Enterprise application, separate JVM
Deployed on the same machine as the Tivoli Identity Manager Server, but
runs as a separate JVM process.
Servlets
Deployed on a separate machine running WebSphere Application Server.
Servlets are not deployed in the context of a Web application.
When developing custom applications to communicate with the Tivoli Identity
Manager Server, use the following rules to ensure secure communication:
v Allow only published application programming interfaces (APIs) to access only
the manager EJBs in the unprivileged area.
v Allow custom applications to use only the functions that the APIs provide.
WebSphere Application ServerTivoli Identity Manager
Server (EJB server)
Webcontainer
Web application(JSPs/servlets)
Browser
EJBcontainer
Managed(unprivileged)
EJBs
logic
TivoliIdentity
Managercore
PrivilegedEJBs
Custom application
Tivoli Identity Manager APIs
Tivoli IdentityManager APIs
Figure 10. Security layers in Tivoli Identity Manager
Chapter 3. Planning your Tivoli Identity Manager installation 41
v Ensure that the computer on which the Tivoli Identity Manager Server runs is
always secure.
WebSphere Application Server uses roles to manage authorization for application
components and other objects, including user and group names. Use the guidelines
described below for assigning roles in custom applications that interface with
Tivoli Identity Manager.
Tivoli Identity Manager Server uses the following EJB roles:
ITIM_SYSTEM
This role is defined when the Tivoli Identity Manager Server is deployed
into WebSphere Application Server. ITIM_SYSTEM is used by Tivoli
Identity Manager Server components; it is authorized to call all EJB
methods in both privileged and unprivileged layers. Do not assign any
principal names or user IDs to this role without prior consultation with an
IBM Tivoli representative.
ITIM_CLIENT
This role is authorized to call only manager EJB methods in the
unprivileged layer. Map to this role the users, and user group names, and
other principals that perform less restricted tasks in the Tivoli Identity
Manager Server.
Deployment planning
Before you deploy Tivoli Identity Manager, create a test and deployment plan that
enables your organization to incrementally verify that the functions and
capabilities of Tivoli Identity Manager are adequately installed, configured, and
tested before they are introduced to your production environment. “Solution
implementation” on page 51 describes the phases used to migrate an identity
management implementation from the test environment to the production
environment. The test plan should include details about:
v Hardware levels on which the components are installed.
v Software levels and applied patches.
v Order in which the components are installed, configured, are connected.
v SSL configuration and secure communication testing between the products and
components using SSL authentication.
v Instructions to test for and capture data throughput statistics to ensure that
potential bottlenecks are detected and the appropriate tuning parameters are
adjusted.
v Order of steps taken to install and configure adapters and corresponding service
profiles.
v Order of steps taken to perform administrative tasks that can involve multiple
steps.
v Order of steps taken to enable specific capabilities, such as password
management.
v Instructions for transferring test data from test repositories to production
repositories. For example, if you create a script to move LDAP data from a test
server to a production server, ensure that the associated steps for using the
script are well documented.
Ensure that the individuals who implement the test and deployment steps
document their procedures and make notes concerning potential sticking points in
42 IBM Tivoli Identity Manager: Planning for Deployment Guide
the process. Also, have your administrators begin documenting the procedures
they follow to configure the server to implement specific capabilities and to
perform specific tasks. This documentation will serve as the training materials for
new users and administrators, and save your organization considerable time and
money in transforming your business culture to use the new capabilities of an
identity management solution.
The IBM Tivoli Identity Manager Information Center provides information about how
to use the import and export features to migrate configuration data from a test
environment to a production environment. The export feature creates a Java
archive (JAR) file that contains the information for most of the functions that are
used by an administrator to set up the Tivoli Identity Manager Server after
installation is completed.
The export function does not recreate the organization tree that was used in the
test environment; however, the dependencies associated with the data (such as the
parent-child relationships that are reflected in the placement of the objects in the
tree) are included in the exported information to help you recreate a organization
tree in the production environment that is functionally equivalent to the
organization tree in the test environment.
Chapter 3. Planning your Tivoli Identity Manager installation 43
44 IBM Tivoli Identity Manager: Planning for Deployment Guide
Chapter 4. Planning to deploy Tivoli Identity Manager
A successful, cost-effective implementation of an identity management solution
requires thoughtful, in-depth planning at multiple levels, because the degree and
scope of the changes can fundamentally change the way your organization
operates. Within your organization you must:
v Identify what issues are addressed by the capabilities of the identity
management solution
v Prioritize those capabilities according to the order in which you want to address
your identity management issues
v Select the people who can play key roles in changing your current environment
to use the new capabilities
v Create a phased plan to configure, test, and implement the solution
This chapter provides guidelines on how to start, develop, and complete an
identity management solution, and emphasizes the need to deploy Tivoli Identity
Manager in a controlled, phased manner to ensure that each capability meets its
objectives and to ensure that the impact of the changes on your personnel are
effectively managed.
This chapter describes:
v “Creating a project implementation plan”
v “Deployment life cycle” on page 48
v “Defining a customization plan” on page 52
v “Determining which identity capabilities to implement” on page 54
v “Determining the implementation approach: top-down or bottom-up” on page
62
v “Deploying Tivoli Identity Manager in phases, using a bottom-up
implementation approach” on page 67
Creating a project implementation plan
To prepare a comprehensive implementation plan, use a systematic approach to
analyzing and understanding your security environment, such as the Method for
Architecting Secure Solutions (MASS). Based on the conceptual model produced by
a systematic approach, you can determine the design objectives for an identity
management system that is tailored to the needs of your organization. These
design objectives form the basis of your project implementation plan for deploying
Tivoli Identity Manager.
Why create a project implementation plan?
The automation of identity management in an organization can have a dramatic
impact on the organization’s personnel, their responsibilities, and the procedures
and processes they follow. By centralizing the allocation and management of
identities and accounts, an organization commits to transforming the
organizational culture, because people (employees, customers, business partners,
suppliers) change their understanding of the way in which they complete their
various functions.
© Copyright IBM Corp. 2005 45
Many key resources are impacted by the changes that are needed to implement an
effective identity management solution:
v Administrators at all levels begin to use standardized procedures for managing
user credentials. Some levels of administration can be reduced or eliminated,
depending on the breadth of the provisioning management solution.
v User self-care is increased, thereby pushing additional responsibilities and policy
awareness to your users.
v Approval processing is unified and streamlined, affecting the duties and
responsibilities of multiple layers of management.
v Password management is automated, thereby increasing the responsibilities of
users at all levels to observe adopted guidelines for the privacy and protection
of their information.
v User-application interaction can be customized, and procedures for provisioning
resources might be changed to accommodate automated provisioning.
v Auditing protocols might be unified to focus on the Tivoli Identity Manager
auditing log and the managed resources. As a result, the roles of auditing
personnel can undergo significant changes.
v Organizational structure can be altered to better accommodate the provisioning
policies and procedures. However, the organization tree used for provisioning
resources does not necessarily reflect the managerial structure of an
organization.
v Business partners and suppliers might need to adopt new procedures that can
impact their business processes.
The breadth of the transformation that occurs in an organization reflects the design
and scope of the Tivoli Identity Manager implementation. For example, if a
primary goal is to automate all processes associated with the life cycle of user
accounts throughout a large enterprise, administrators and users across separate
locations will need to be trained to follow the same or similar business procedures
that are related to account management. If a primary goal is to reduce costs by
transferring password management responsibilities to your users, you might
change only those business procedures that are associated with implementing that
change.
Consider these reasons why your organization should carefully plan to integrate
Tivoli Identity Manager into your environment:
v Implementing an automated identity management solution standardizes the use
of terms, concepts, and procedures. Security administrators will need training in
the use of the software and your users will be required to follow new
procedures.
v Authoritative data repositories might be required to feed user information in to
Tivoli Identity Manager. Integrating each repository might require a separate
roll-out plan for testing and integration that minimizes the impact to all affected
individuals.
v Configuration and customization tasks might be required to automate and
integrate mission-critical applications into the identity management solution.
Statements of work and roll-out plans should be created for each application
configuration task to minimize the impact to all stakeholders in the enterprise.
v Users and administrators must be trained to use the new system. Training
should be funded, planned, and delivered from the very beginning to ensure
that your production deployment is anticipated and well-supported. The amount
of training you provide can directly impact the speed and acceptance of the new
tasks and procedures that affect your user community.
46 IBM Tivoli Identity Manager: Planning for Deployment Guide
v A phased implementation is a best practice. Starting the project with a
reasonably achievable milestone, such as password management, and following
with phased roll-outs of other capabilities will deliver manageable change to
your organization.
Project team members
The relative success of a project implementation plan in meeting your
organization’s objectives depends largely on the people involved with creating,
designing, and implementing the plan. Ensure that you assign the right people to
oversee and implement the various phases of the implementation tasks. Also,
ensure that you involve those people with the appropriate knowledge to provide
critical feedback on the technical aspects of the implementation.
During the assessment and planning phases of the solution design process, you
will involve many knowledgeable individuals that understand your business
operations as well as individuals responsible for the IT operations. The following
individuals should be involved to help with IT analyses:
Project manager
Designate one person to manage and maintain the coordination between
all the people involved, set schedules, track and report issues, and ensure
that the project stays on track. This person also acts as a focal point for
concerns that flow between your site and any IBM consultants that are
involved. This individual should be strong in enlisting the help of those
who demonstrate an understanding of the project scope and who are
supportive of the implementation plans. This individual must also be
aware of any influences outside the project that can affect the expectations
of the team.
Project owner
Designate a project owner to drive the requirements for the proposed
solution. Others, such as technical owners, can contribute to an
understanding of the need for the requirements. The project owner ensures
that the project team understands, agrees to, and executes the tasks that
delineate the definition and design phases of the project. To ensure that
potential blocks to the implementation are overcome quickly and
responsibly, this person should be a strong advocate for the solution and
adept at working with various personality types.
Technical owners
Assign one or more individuals that understand the complexity and
technical issues of the plan architecture. These individuals are the main
consultants that understand the structure and purpose of a solution
architecture. As such, these individuals should be able to evaluate and
judge the trade-offs between making changes to the design and
implementation plan and preserving the architecture of the solution.
Subject matter experts
Assign specialists that have the most detailed grasp of the elements and
tasks associated with implementing a plan. Ensure that they are well
trained by IBM and own the deployment throughout each phased-in
function. If possible, minimize the number of subject matter experts who
install and configure the applications. If numerous subject matter experts
are involved, encourage communication flow between them. See
“Professional certification programs” on page 12 for information about
obtaining certification in identity management solution design.
Chapter 4. Planning to deploy Tivoli Identity Manager 47
Trainers
Assign an individual to oversee the training of users and administrators.
This individual coordinates the training schedule, generates the initial
training materials, assigns instructors as needed to teach the transition
from existing processes, procedures, and tools to the new processes,
procedures, and tools.
Project auditors
Many organizations use auditors to review projects and assist as subject
matter experts on project internal controls. A project auditor can also
provide advice on the security policies, practices, and goals of the
organization.
Establishing project management guidelines
To prevent initial deployment problems, consider providing a variation of the
following planning activities that are appropriate for your site, in advance of
installing Tivoli Identity Manager and subsequent cumulative fixes:
v Establish the rules and guidelines for governing the project information.
v Establish a working practice that provides comprehensive and relevant Tivoli
Identity Manager information to all of the specialists who install middleware.
For example, have the team meet regularly to enumerate their problems and
share their capabilities.
v Provide a comprehensive library or list of FTP or Web sites for prerequisite
installation and configuration information.
v Ensure that the specialists installing Tivoli Identity Manager have root or
administrator authority for the prerequisite middleware.
v Ensure that all elements of the system or solution have sufficient privileges to
provide accounts.
v Support a centralized problem and solution database that identifies
troubleshooting actions and assigns action owners to resolve installation and
configuration issues.
v Create a change control database that coordinates all customization activities.
v Set up a working practice in which specialists provide a record of critical values
in the worksheets similar to those provided in the IBM Tivoli Identity Manager
Installation and Configuration Guide. Ensure that all specialists have access to and
use a common worksheet that centralizes the information.
Deployment life cycle
Implementing an identity management solution has the following major phases.
Note that these phases are described in the context of a comprehensive security
solution.
1. “Assessment and planning”
2. “Solution definition, design, and implementation plan” on page 49
3. “Solution implementation” on page 51
4. “Solution adjustments” on page 52
Assessment and planning
The requirements for implementing an identity management solution might also
include your requirements for implementing other phases of your overall security
solution. Assessment and planning is performed as follows:
48 IBM Tivoli Identity Manager: Planning for Deployment Guide
1. Conduct an enterprise-wide review and inventory of the IT security
environment in order to document the IT security architecture. This review
reveals the associated business security requirements, functionality
requirements, usability requirements, and nonfunctional requirements. The
architecture will detail the requirements for each managed endpoint.
2. Conduct an enterprise-wide security architecture review that examines all
security issues, not just IT security issues. This project produces your
organization’s security policy documentation, which defines the security
architecture that should be applied throughout your enterprise, including
employees, customers, suppliers, and business partners. The identity and
credentials subsystem is a key component of the overall security architecture.
3. Identify the security problems (including the identity management problems)
and the key business drivers for resolving these problem, and a cost structure
to address these security problems.
Solution definition, design, and implementation plan
In this stage, the comprehensive security solution is defined, detailed, and planned
for roll-out. The security solution definition, design, and implementation plans are
created as follows:
1. Identify the candidate solution approaches to address the security problems.
The documentation should include business processes, organizational impact,
technical capabilities, and costs associated with each candidate solution.
Prioritize the capabilities and create a transitional plan for implementing the
leading candidate security solution, which includes the identity management
solution.
2. Create a detailed definition for each security solution you will implement. Each
solution definition should include the business processes, organizational
impact, and technology architecture of the solution.
3. Create detailed solution design documents for each security solution that needs
to be implemented. These documents, which include the IT architecture,
security architecture, and requirements specification, identify the business
background, the business need for a security solution that includes identity
management, and the business and technical requirements for the security
solution. For more information about creating architecture documents and
requirements specifications for a security solution, refer to the IBM Redbook
Identity Management Design Guide with Tivoli Identity Manager, SG24-6996, at the
IBM Redbook Web site:
www.redbooks.ibm.com
4. Create a detailed project implementation plan for each security solution. The
project implementation plan describes the project details for implementing the
preferred identity management solution. It includes the business processes,
organizational impact, technology architecture of the solution, and the detailed
requirements for the solution. To generate this information, the project team
should interview and meet with the key people and teams involved in identity
management. The persons involved can include the CIO, IT executive, security
management and administration team, operations personnel, help desk
personnel, key technical teams (for example, the operating system
administrators), application development teams, and business managers. These
interviews and meetings will enable the team to develop a comparison of how
the system currently works and how it can be improved.
In determining the goals and objectives of the project implementation plan,
ensure that the project team clearly differentiates its requests from the genuine
requirements. The project owners should drive the requirements for the
Chapter 4. Planning to deploy Tivoli Identity Manager 49
proposed plan, although others may contribute to an understanding of the need
for the requirements. It is critical that the project owner and the project team
agree on the current state of the identity issues and the requirements for
implementing an identity management solution before starting the project
deployment.
Using the information gathered from the security solution documentation,
interviews, and workshops, the project team produces the documents that are
used to execute the project implementation plan. These documents should
include:
v Project charter for identity management
v Statements of work (SOW)
v Project definition report
v Requirements document
v Functional specifications
v Existing system analysis
v Phased implementation plan
v Training plan
These documents should address the following identity-related topics:
Identity feed processes
Specifies the processes used to populate the Tivoli Identity Manager
organization tree with the users and accounts that are managed, and
the processes used to reconcile the users and accounts in the
organization tree with the users and accounts defined on the managed
resources. This document also specifies the authoritative sources of
information if authoritative sources are maintained outside of Tivoli
Identity Manager.
User management procedures
Specifies the procedures for managing users, who manages the users,
and what is required of the solution for managing users.
Password management procedures
Specifies the procedures for managing account passwords, who
manages the passwords, and what is required of the solution for
managing passwords.
Access control management procedures
Specifies the procedures for managing access control, who manages the
access control definition, and what is required of the solution for
managing access control.
Security policy
Specifies the corporate security policy definitions for users, accounts,
passwords, and access control.
Targeted managed resources
Identifies the current system environment (including operating systems,
databases, applications, the network, firewalls, physical locations, and
access control) and the system requirements of the solution.
Interfaces
Identifies the interfaces to the current identity management
mechanisms and procedures and the integration requirements of the
solution.
50 IBM Tivoli Identity Manager: Planning for Deployment Guide
Auditing and reporting procedures
Specifies the procedures for auditing and reporting, who is involved in
the auditing and reporting of users and their access, the audit
requirements for the solution, and the reporting requirements for the
solution
Technical requirements
Specifies any other technical requirements for the solution, such as
availability and recovery.
An example scenario that describes how to create an identity management project
implementation plan is described in the IBM Redbook Deployment Guide Series: IBM
Tivoli Identity Manager, SG24-6477, available at the IBM Redbook Web site:
www.redbooks.ibm.com
Solution implementation
In this stage, the identity management solution is tested, piloted, and deployed.
Ensure that each unit of work is appropriately sized for a single delivery team. In
some cases, the overall delivery time line can be reduced by using multiple teams
to complete units of work in parallel.
The solution implementation has three phases:
Solution build
The solution build phase develops detailed configurations for the identity
management solution based on the design specified in the preceding
phases of the life cycle. The solution build is performed in a limited-scope
test and development environment that represents a production
environment but does not impact your actual production environment.
During this phase the implementation team develops installation and
configuration scripts or procedures, builds detailed product and tool
configurations, and prepares the required educational materials and other
supporting documentation, such as performance metrics. This phase also
establishes the supporting processes and organizational changes required
by the identity management solution.
Pilot The pilot phase validates the systems and implementation procedures in
the limited-scope production environment. For example, the
implementation team can apply a pilot implementation at a single site, on
a single floor in a building, or to a subset of the systems and applications
in a production environment. The purpose is to deploy and test the new
design and implementation procedures and user training in a production
environment, but in a limited scope that allows the team to make
adjustments with minimal impact to your operations. In selecting the
environment, the deployment team should also determine that enough
variety exists to ensure that all aspects of the design are tested prior to the
production deployment. During this phase the deployment team makes all
required adjustments to either the implementation procedures or to the
design, and validates the tools, data, measurements, documentation, and
staffing levels. The ultimate challenge for the team is to implement an
end-to-end identity management solution in a portion of your production
environment.
Deployment
The deployment phase fully implements the new design in the production
environment. The implementation team uses the results of the pilot
Chapter 4. Planning to deploy Tivoli Identity Manager 51
deployment to create an enterprise-wide roll-out plan with high-level
details. A more detailed plan is then documented as the first step of the
actual deployment transpires. At the commencement of deployment, any
outstanding equipment procurement is finalized. The metrics developed in
the solution build phase should be used to measure the success of the
implementation as it proceeds. If projections were made during the design
engagement, the deployment team should also take measurements to test
their accuracy. Towards the end of the first step of initial deployment, prior
to the hand-over to formal production, begin the required training for the
operations and support staff. When deployment is completed, your
organization will have a fully functional and documented production
environment based on the new design.
Solution adjustments
Regardless of how well you design a plan, after the plan is implemented you are
likely to make adjustments to the implementation that should also be documented
as part of the design. Organizational changes, performance issues, new
technologies, or other factors can affect the design or implementation of your
identity management solution. When you make adjustments to the plan, document
the changes as part of a change control system that can be accessed and referenced
by the appropriate members of the project team.
Defining a customization plan
To reduce the impact to your users and to ensure a smooth integration of the new
functions into your IT environment, you must carefully plan the creation, test, and
implementation of any customization projects that enhance your implementation of
Tivoli Identity Manager.
Your team must decide, based on the business plans and requirements, how much
to customize Tivoli Identity Manager. For example, a large enterprise might require
a phased roll-out plan for workflows and custom adapters that is based on a time
line for incrementally provisioning applications that are widely used across
geographies. Another customization plan might provide for two or more
applications to be provisioned across an entire organization, after successful
testing.
A customization plan can be thought of as a microcosm of the identity
management project implementation plan. Many of the steps associated with
planning the implementation of identity capabilities apply to creating and
implementing a customization plan. Key customization tasks include:
Select the appropriate people
Because customization is specific to your environment, you need to ensure
that you assign your best subject matter experts (SMEs) to the project and
ensure that they can communicate effectively with the IBM consultants.
Having your most knowledgeable personnel involved in the project will
help ensure that you determine the best possible technical requirements
and test and implementation steps.
Assess the need for customization
During the assessment and planning phases of the identity management
life cycle, the project planning team determines which customization tasks
are required to meet the organization’s identity management goals. The
team must ask and answer the following questions.
Defining the customization tasks
52 IBM Tivoli Identity Manager: Planning for Deployment Guide
v Which identity management capabilities do we implement and
in what order?
v Which capabilities require customization?
v What functions will each customization task implement?
v What is the scope of each customization task?
Resource and impact planning
v How does the organization determine the size and composition
of the customization team?
v What resources can the organization provide towards the
project?
v What functions will each customization task implement?
v What are the risks associated with each customization task?
v How will the customization impact other configuration and
customization tasks; what are the dependencies?
v How will the customization be maintained and supported after
implementation?
v Does the customization need to be delivered in incremental
phases?
Cost estimating and sizing
You will likely partner with IBM Tivoli to implement one or more
customizations. The following questions apply to working with
outside consultants.
v How many customization tasks require a statement of work
(SOW)?
v Are the services hired to implement the customization plans
billed by time and material or are some services billed by fixed
price?
v What are the rates?
v What are the key milestones of each customization?
Create an implementation plan
The implementation plan can contain:
v Software purchase requirements
v Business tasks (cost-benefit analysis and budget)
v Project management tasks (schedules, resource allocation spreadsheets,
and risk management procedures)
v Technical tasks (design and build) that are required to execute a
customization plan
v Training tasks required to educate your key users and administrators
v Stakeholder analyses and coordination with SMEs
v Details on how to minimize the impact of implementation to users and
other affected stakeholders
v Details on how communication will flow within the implementation
team and between the team and the stakeholders
v Details on risk assessment and a risk response plan
v Test and implementation roll-out schedules
v Quality management plan to troubleshoot potential problems
Create a test plan
The test plan should contain:
Chapter 4. Planning to deploy Tivoli Identity Manager 53
v Test participants and their skill levels
v Test scenarios with the stated scope and objectives of each test scenario
v Test scripts that describe:
– Who performs the task
– Expected results
– Who signs off on the test
– Documentation of the test completion
– Completion acknowledgements, including signatures
Statement of work
A statement of work (SOW) describes what your organization can expect from the
IBM professional services consultants that help you identify and design
customization projects. An SOW establishes the following guidelines:
Scope Describes the scope of the implementation, including functions, features,
and interfaces.
Configuration changes and software versions
Describes the configuration changes that are related to the customization
project and the affected software and software levels.
Project assumptions
Specifies areas that require an explicit understanding between your
organization and IBM Tivoli, for example, processes or procedures that are
not well understood prior to starting the customization project.
Responsibilities
Defines the tasks for which IBM Tivoli is responsible and those tasks for
which your organization is responsible, and includes the implications of
ongoing support and support responsibilities.
Deliverables
Specifies the deliverables and the completion criteria of the project.
Determining which identity capabilities to implement
During the assessment and planning phase of the identity management life cycle,
you evaluate the costs, impacts, and benefits of the identity management
capabilities. Your analyses should lead to an implementation plan that specifies
and prioritizes the identity management capabilities that you intend to implement
and the order in which they will be implemented. Use the information and
checklists for each capability in the following sections in your analyses to consider
the trade-offs between the benefits of the listed item and the cost of implementing
that capability.
Identity foundation
The organization tree, identities, accounts, services and other entities form the
identity foundation of all capabilities. The scope of the identity capabilities that
you choose to implement are governed by the ability to:
v Integrate the users and user credentials, including employees, business partners,
suppliers, and customers using a metaview that combines the sources of these
user data
v Access and manage controlled systems and applications through bidirectional
data-flow connections (adapters)
54 IBM Tivoli Identity Manager: Planning for Deployment Guide
Consider the costs, resources, personnel, and time tables needed to build the
central repository of the users, accounts, and resources that you want to control
using Tivoli Identity Manager.
For more information about the identity foundation capability, see “Identity
foundation” on page 6.
Table 3 presents a checklist of possible capabilities for implementing a solid
identity foundation.
Table 3. Checklist of items for developing adapters
Capability Required Optional Priority
Roll-out
date
Use adapters to communicate with all
resources (systems, databases, directories,
and applications) that need to be managed.
Use adapter development tools and
developer resources for in-house or
unsupported managed resources.
Use adapter communications over
bidirectional, secure links (encrypted using
SSL) to ensure that updates, transactions,
and the reporting of changes to local
resources are managed effectively.
Use and protect authentication credentials
when using adapters to log in to managed
resources.
Use adapters that can communicate with
managed resources that are available only
over bandwidth-constrained networks.
Use adapters that operate on remote
resources without having to be physically
located on the remote resources.
Use adapters without interfering with the
day-to-day operation of the managed
resource, especially those resources with
limited available processing capabilities.
Password management
The password management capability enables your organization to:
v Maintain user accounts securely
v Control help desk costs related to password management
v Improve the user experience in managing his or her own passwords.
If these are serious issues for your organization, consider an early implementation
of this lower identity capability.
For more information about the password management capability, see “Password
management” on page 7.
Table 4 on page 56 presents a checklist of possible items for implementing a solid
password management capability.
Chapter 4. Planning to deploy Tivoli Identity Manager 55
Table 4. Checklist of items that implement the password management capability
Capability Required Optional Priority
Roll-out
date
Access user self-service through the Web
without logging on to the network.
Use a challenge-response system to
authenticate a user who forgot his
password by using shared secrets, either
system-defined or user-defined.
Implement password formation rules to
enforce password strength across the
organization and to resolve password
policy conflicts.
Synchronize passwords for multiple
systems to the same value to reduce the
number of different passwords that users
must remember.
Deliver success and failure status for
password changes to the requestor.
Securely deliver passwords to users for
new accounts.
Use adapters without hampering the rights
of the local administrator or placing
limitations on the abilities of the managed
resource.
Account access management
The account access management capability enables your organization to:
v Control costs related to maintaining user accounts
v Protect sensitive information
v Detect potential security breaches through orphan accounts and improper
accounts
For more information about the account access management capability, see
“Account access management” on page 7.
Table 5 presents a checklist of possible items for implementing the account access
management capability.
Table 5. Checklist of items that implement the account management capability
Capability Required Optional Priority
Roll-out
date
Use flexible mechanisms to connect to
multiple data stores that contain accurate
information about users.
Load identity store information in bulk on
a scheduled basis.
Detect and respond to identity store
changes in near real-time.
56 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 5. Checklist of items that implement the account management capability (continued)
Capability Required Optional Priority
Roll-out
date
Retrieve account information from
managed resources on a scheduled basis
both in bulk or in filtered subsets to
preserve network bandwidth.
Allow local administrators to maintain the
rights to create, delete, and change
accounts directly on resources, with
changes being detected and reported in
near real-time.
Compare changes made by local
administrators against systems-of-record of
account states to determine if changes
comply with approved authorities and
policies.
Notify designated personnel of access
rights changes made outside the
provisioning system.
Compare account user IDs with valid users
to determine accounts without owners
(orphans).
Automatically suspend or delete a detected
orphan account.
Automatically suspend or roll back a
reconfigured account that violates a policy.
Examine reports on orphan accounts.
Assign discovered orphan accounts to a
valid user.
View accounts associated with a users or a
resource.
Workflow and life cycle automation
The workflow and life cycle automation capability enables your organization to:
v Control costs related to managing user life cycles: account creation, modification,
and deletion
v Streamline the implementation of business policies and processes
v Reduce the time required to establish and provision user accounts
Workflow and life cycle automation extends the reach of identity management to
create an end-to-end software solution for managing user accounts. It builds on the
account access management capability.
For more information about the workflow and life cycle automation capability, see
“Workflow and life cycle automation” on page 8.
Table 6 on page 58 presents a checklist of possible items for implementing the
workflow and life cycle automation capability.
Chapter 4. Planning to deploy Tivoli Identity Manager 57
Table 6. Checklist of items that implement the workflow and life cycle automation capability
Capability Required Optional Priority
Roll-out
date
Use a Web-based mechanism for requesting
access to a system.
Automatically route approvals to the
appropriate persons according to the
system access requested and the
organizational structure.
Use defined organizational information (for
example, roles) to dynamically determine
the routing of approvals.
Delegate approval authority to another.
Escalate a request to an alternative
approver if an allotted time elapses.
Enable different personnel to view different
levels of information based on their job
responsibilities.
Request information from approval
participants to define account-specific
information during the process.
Enable the system to change account
information in the managed resources of
your specific organization.
Request information from specific
participants in the workflow process.
Determine services where physical
accounts should be created.
Request information from external
functions, applications, or data stores
during the workflow process.
Auditing and reporting
The auditing and reporting capability enables your organization to:
v Generate and store historical records of critical activities, such as account access
changes
v Generate and maintain secure audit trails of information
v View different levels of information according to access controls
v Gather, review, and document various activities, such as approval requests and
account changes
The resources you will need to dedicate to this capability depend on the auditing
requirements and reporting needs of your organization. For example, your
organization might need to establish new business processes that enable you to
meet governmental auditing requirements or you might need to plan to use
resources to generate custom reports that supplement the default reports.
For more information about the auditing and reporting capability, see “Auditing
and reporting” on page 9 and “Reports and auditing” on page 24.
58 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 7 presents a checklist of possible items for implementing the auditing and
reporting capability.
Table 7. Checklist of items that implement the auditing and reporting capability
Capability Required Optional Priority
Roll-out
date
Generate and store time-stamped records of
every access change request, approval and
denial, justification, and change to a
managed resource.
Generate and store time-stamped records of
all administrative and policy-driven
changes to access rights.
Generate and store time-stamped records of
any detected orphan accounts and bypasses
of administrative systems.
Conveniently produce reports showing
audit trails for users, systems,
administrators, and time periods.
Maintain audit trails in a secure,
tamper-proof environment.
Distributed administration
The distributed administration capability enables your organization to:
v Implement user account self-service, which helps control user management costs
and improves user satisfaction
v Move the delegation of authority to administrators who are closer to the source
of the requests
Within the range of identity management capabilities, distributed administration is
the precursor to role-based access control using policy automation. Considerable
planning and resource allocation is required to implement distributed
administration.
For more information about the distributed administration capability, see
“Distributed administration” on page 9.
Table 8 presents a checklist of possible items for implementing the distributed
administration capability.
Table 8. Checklist of items that implement the distributed administration capability
Capability Required Optional Priority
Roll-out
date
Define organizational structures based on
the access-granting authorities of an
organization.
Delegate each administrative task with
fine-grain control (for example, approval
authority, user creation, workflow
definition).
Delegate administrative tasks to specified
levels of depth in the organization.
Chapter 4. Planning to deploy Tivoli Identity Manager 59
Table 8. Checklist of items that implement the distributed administration
capability (continued)
Capability Required Optional Priority
Roll-out
date
Access delegated capabilities over the Web
without having to install client software on
the managed resources.
Create private, filtered views of
information about users and available
resources.
Incorporate Web access control products to
include the provisioning system in the Web
single sign-on (SSO) environment.
Incorporate user authentication approaches
that are consistent with internal security
policies.
Distribute provisioning system components
securely over WAN and Internet
environments, which includes the crossing
of firewalls.
Role-based access control
The access control policy automation capability enables you to realize the full
potential of implementing role-based access control for end-to-end access
management in your organization. By implementing role-based access control you
can:
v Reduce administrative costs through automated procedures for governing user
provisioning
v Improve security by automating security policy enforcement
v Streamline and centralize user life cycle management and resource provisioning
for large user populations
The costs and resources you allocate to implement role-based access control will
depend on the costs of implementing the other capabilities of the identity
management solution, the type of implementation approach you choose
(bottom-up versus top-down), and the percentage of your business operations to
which you apply the identity management solution.
For more information about the role-based access control capability, see
“Role-based access control” on page 10.
Table 9 presents a checklist of possible items for implementing the role-based
access control capability.
Table 9. Checklist of items that implement the role-based access control capability
Capability Required Optional Priority
Roll-out
date
Associate access rights with roles in the
organization.
Assign users to one or more organizational
roles.
60 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 9. Checklist of items that implement the role-based access control
capability (continued)
Capability Required Optional Priority
Roll-out
date
Implicitly define subsets of access to be
unavailable to a role.
Explicitly assign users with individual
access rights.
Dynamically and automatically change
access rights that are based on changes in
user roles.
Define implicit access rights that are
available to users in a role upon their
request and approval.
Use defined organizational information to
dynamically determine the routing of
approvals.
Detect, evaluate, and respond to user
authority changes made directly to a
managed resource.
Report on roles, rights associated with
roles, and users associated with roles.
Set designated times for changes in access
rights or policies.
Create unique user IDs that are consistent
with policies, not in the current user
population, and not previously used by the
organization.
Create user authorizations for an existing
account.
Self-regulating user administration
With self-regulating user administration you can realize the advantages and
benefits of provisioning users across organizational boundaries. By implementing
self-regulating user administration across organizational boundaries you can:
v Reduce provisioning costs
v Streamline the access and approval processes
The costs and resources you allocate to implement self-regulating user
administration will depend on the existing business structures and processes that
are already established, and the degree to which they must be modified to adapt
an identity management solution to cross organizational boundaries.
For more information about the self-regulating user administration capability, see
“Self-regulating user administration” on page 11.
Table 10 on page 62 presents a checklist of possible items for implementing the
self-regulating user administration capability.
Chapter 4. Planning to deploy Tivoli Identity Manager 61
Table 10. Checklist of items that implement the self-regulating user administration capability
Capability Required Optional Priority
Roll-out
date
Set standards that can be adopted by all
areas in the organization.
Securely transmit changes across the public
Internet.
Protect private user information through
secure facilities and sound processes.
Generate reports and audit trails of user
rights in all (or most) systems across
organizational boundaries and geographies.
Determining the implementation approach: top-down or bottom-up
During the assessment and planning stages of your identity management solution
deployment, you will evaluate:
v Which of the various Tivoli Identity Manager capabilities to integrate into your
environment
v When and where these capabilities should be deployed to ensure the greatest
return on your investment
Regardless of the results of your evaluation, you will need to integrate the desired
capabilities into your environment incrementally, in phases, because the
deployment of each capability requires substantial planning and significantly
impacts the way your organization operates. Each capability you implement can be
conceptualized, planned, and incorporated into your environment as a separate
implementation phase within your overall product deployment. Depending on
your objectives, you can combine the roll-out of one or more capabilities in a single
phase of implementation (see “Deploying Tivoli Identity Manager in phases, using
a bottom-up implementation approach” on page 67). How you choose to
implement identity management capabilities will be unique to your environment,
but a goal of your planning should be to transition to the new capabilities with
minimal disruption to your organization.
If you approach integrating Tivoli Identity Manager into your environment from
the standpoint of meeting your organization’s specific needs (as opposed to simply
implementing the product’s functions and features), you can realize the benefits of
specific capabilities in accordance with the objectives that are established by your
research. The following sections describe two contrasting approaches to
implementing Tivoli Identity Manager capabilities in phases: top-down approach
and bottom-up approach.
Top-down implementation approach
The top-down approach to implementing an identity management solution focuses
on implementing identity management capabilities for an individual managed
resource, such as an application. In the top-down approach, your organization
strives to realize higher-level capabilities for a more narrowly focused group of
users, such as those who are closely associated with the managed application. For
example, you might want to realize the advantages of the following identity
management capabilities as soon as possible for one group using one application at
one location:
62 IBM Tivoli Identity Manager: Planning for Deployment Guide
v Password management
v Orphan account control
v Automated process request approval through workflows
v Automated provisioning through role-based access control
By planning for the implementation of the role-based access control capability, you
effectively plan to implement all of the supporting capabilities required to enable
role-based access control. All of the identity management capabilities are not
shown in Figure 11 because you will likely want to implement only a portion of
the features that comprise each capability (see “Determining which identity
capabilities to implement” on page 54).
With the top-down approach, after implementing several identity management
capabilities for a single managed resource, you incrementally expand the solution
to more applications, users, and platforms. See Figure 11.
In Figure 11, most of the appropriate work is performed in the planning phase to
set the requirements, participants, and documents that leads to the roll-out of
role-based access control for a specific managed resource, such as a critical
application and a subset of users and administrators who use the application in
their every day activities. The plans must be extensive to specify the
implementation of all the desired capabilities.
Business analysis forpassword management
and account provisioning
Identity feed:- People- Organization tree information
Configure managed resource
ReconciliationPassword management
RolesProvisioning policies Workflow
Yes Additionalresource
Figure 11. Top-down implementation approach
Chapter 4. Planning to deploy Tivoli Identity Manager 63
In the first phase of the implementation, the identity foundation is created to set
up the Tivoli Identity Manager Server, and the service is configured for the
managed application. The number and locations of users that are represented in
the organization tree depend on the requirements set forth in the project
implementation plan.
In the next phase, the reconciliation process between the Tivoli Identity Manager
Server and the managed resource is completed and the password management
capability is configured, tested, and implemented.
In the next phase, access approval workflows are implemented concurrently with
the configuration of roles and provisioning policies. The purpose, scope, and users
affected by these workflows, roles, and provisioning policies have been carefully
defined during the planning phase. In this example:
v The user population that is represented and managed in Tivoli Identity Manager
is sufficiently broad that the next step can be to configure a service for another
resource.
v After the role-based access control is successfully implemented for a single
application, you can expand the scope of the capabilities to include other
resources in your organization, such as another application, or other platforms
for which you have already begun to represent users and accounts in the
organization tree.
The top-down implementation approach is not generally recommended because it
can require customization work to establish the appropriate workflows for
approvals and to establish the communication link to the application. Although
you can gain product knowledge more rapidly, you might not realize the benefits
of the solution relative to the amount of time, expertise, and money that you invest
in the preceding phases of the roll-out.
Bottom-up implementation approach
The bottom-up approach to implementing an identity management solution
reduces the tasks of the initial planning phase to include only the requirements,
participants, and documents needed to implement the identity foundation and one
or two capabilities, such as password management. After these capabilities are
rolled out for the specified resources, you can prepare additional plans to
implement more capabilities, including role-based access control.
In the bottom-up approach, your organization strives to realize a quick return on
investment for a broader base of users and managed resources. For example, you
might want to realize the cost savings that are associated with user self-service of
passwords for a large user population across multiple operating systems, which
you can achieve by implementing the password management capability.
Consequently, you:
v Plan for and include a large user population when you implement the identity
foundation capability
v Roll out the password management capability platform by platform
After you have met your objectives for implementing the password management
capability, you create the plans for implementing any other capabilities that are
needed to meet your objectives, which can include role-based access control. See
Figure 12 on page 65.
64 IBM Tivoli Identity Manager: Planning for Deployment Guide
In Figure 12, the planning phase focuses only on establishing the identity
foundation and the password management capability. Because the goal is to
implement password management for a large user population, the plans will
specify what managed resources and users are affected by the roll-out of these
capabilities.
In the first phase of the implementation, the identity foundation is established for
the user population that will be enabled to perform self-service through the
password management capability. This population is likely to be much larger than
the initial user population that is represented in the top-down approach because
the intent is to implement password management for as many users as possible,
rather than for a subset of users that use a specific application.
Business analysis forpassword management
Identity feed:- People- Organization tree information
Configure managed resource
Business analysis foraccount provisioning
ReconciliationPassword management
RolesProvisioning policies Workflow
Yes
Yes Additionalresource
Additionalresource
Figure 12. Bottom-up implementation approach
Chapter 4. Planning to deploy Tivoli Identity Manager 65
In the next phase, the reconciliation process between the Tivoli Identity Manager
Server and a single managed resource, such as a set of systems that use a specific
operating system, is completed and the password management capability is
configured, tested, and implemented for that set of users. These procedures are
then repeated for more resources until the desired user population is enabled to
use the password management capability.
In the next phase, your planning focuses on integrating additional capabilities that
lead to implementing role-based access control for a specified set of user accounts.
The background documents and participants might or might not need to be
updated to implement these additional capabilities.
In the next phase, access approval workflows are implemented concurrently with
the configuration of roles and provisioning policies, just as they are implemented
using the top-down approach. However, each roll-out might target different sets of
users and resources.
The bottom-up approach is usually recommended for most organizations that want
to realize cost savings in key areas, such as password management and user
self-administration, without having to first design and implement customization
plans for managed applications. You can design the project implementation plan to
bring various applications, operating systems, and workflows into the identity
management solution on a time table that is consistent with the most critical
factors that your analyses yield.
Advantages and disadvantages of the top-down and
bottom-up implementation approaches
The top-down and bottom-up approaches to deploying your identity management
solution are provided to help you decide the best way to integrate identity
management capabilities into your environment. Each approach has distinct
advantages and disadvantages, as shown in Table 11.
Table 11. Pros and cons of the top-down and bottom-up implementation approaches
Bottom-up approach Top-down approach
Summary
v High deployment coverage in early
phases
v Earlier return on investment
v High visibility of organizational changes
v Higher impact to organization
v Tactical, limited coverage
v Delayed return on investment
v Lower impact to overall organization
v Higher deployment costs
Advantages
66 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 11. Pros and cons of the top-down and bottom-up implementation
approaches (continued)
Bottom-up approach Top-down approach
v User and business awareness of the
product. Benefits are realized in the early
phases.
v You can replace many manual processes
with early automation.
v You can implement password
management for a large number of users.
v You do not have to develop custom
adapters in the early phases.
v Your organization broadens identity
management skills and understanding
during the first phase.
v Tivoli Identity Manager is introduced to
your business with less intrusion to your
operations.
v Your organization realizes a focused use of
resources from the individual managed
application.
v The first implementation becomes a
showcase for the identity management
solution.
v When the phases are completed for the
managed application, you have
implemented a deeper, more mature
implementation of the identity
management solution.
v Operation and maintenance resources are
not initially impacted as severely as with
the bottom-up approach.
Disadvantages
v The organizational structure you establish
might have to be changed in a later
roll-out phase.
v Because of the immediate changes to
repository owners and the user
population, the roll-out will have a higher
impact earlier and require greater
cooperation.
v This strategy is driven by the existing
infrastructure instead of the business
processes.
v The solution provides limited coverage in
the first phases.
v A minimal percentage of user accounts are
managed in the first phases.
v You might have to develop custom
adapters at an early stage.
v The support and overall business will not
realize the benefit of the solution as
rapidly.
v The implementation cost is likely to be
higher.
Deploying Tivoli Identity Manager in phases, using a bottom-up
implementation approach
This section describes the capabilities that can be included in each phase of a
bottom-up implementation of Tivoli Identity Manager. The bottom-up approach is
well-suited to organizations that need to realize a quicker return on investment.
The steps taken by your organization and the scope of each step can vary
somewhat from this approach; however, the capability levels do build on one
another. The scope of a capability implementation, the costs and difficulty of
implementing a capability, and the benefits of a particular capability will drive
each phase of your roll-out plan.
Phase 1: Identity foundation, password management, and
account access management
Phase one implements the identity foundation, password management, and
account access management capabilities. Although extensive configuration is
required, you do not have to plan and initiate customization tasks to realize the
benefits of the phase one implementation.
In phase one your organization establishes:
Chapter 4. Planning to deploy Tivoli Identity Manager 67
v Bidirectional data feeds to the user repositories that are used to uniquely
identify the users in your enterprise. For most organizations, the human
resources directory is the most pervasive, central repository for maintaining
persons and person credentials.
v The organization tree that models the structure of users and services according
to the rules and controls that your business analyses determine are best for
identity management purposes. You can model the personnel structure and the
resources they use in multiple ways, according to the needs of your
organization.
v Person, custom person, and business partner person directory schema. This
organization of people might or might not reflect your current organizational
structure.
v Adapters for operating systems and applications that are already supported by
Tivoli Identity Manager. After adapters are established, you can configure user
accounts to the connected systems and applications.
v Reconciliation schedules that synchronize Tivoli Identity Manager user account
information with the user account information maintained in the network of
managed resources (systems and applications).
v Password policies that reflect the goals and objectives of password management
that you determine during your business process analyses.
v Access control item definitions that manage access to Tivoli Identity Manager
tasks, including default reports.
After phase one configuration is complete, Tivoli Identity Manager administrators
and users can perform numerous tasks, including:
v Synchronize and reset user passwords according to password policy rules
v Self-service passwords across managed systems
v Create, suspend, and close user accounts
v Identify orphan accounts
v Run some of the default reports
Phase 2: Workflow and life cycle automation, auditing and
reporting, and distributed administration
Phase two builds on the capabilities of phase one and implements the workflow
and life cycle automation, auditing and reporting, and distributed administration
capabilities. For example, the data feed that you establish from the human
resources directory identifies new users in the organization and the access request
approval capability initiates the processes that approve (or reject) resource
provisioning for the new users. Distributed administration is also initiated, where
various levels of approvers perform only designated tasks as part of the approval
process.
In phase two, your organization:
v Configures access request approval, which includes defining basic workflows
v Expands the audit trail that tracks user provisioning procedures
The workflows you define depend on the business process analyses that you
perform early in the creation of the project implementation plan. These analyses
identify:
v Procedures that are required to approve user life cycle changes, such as adding,
changing, and deleting user accounts to various resources, such as systems and
applications
68 IBM Tivoli Identity Manager: Planning for Deployment Guide
v Personnel involved in approving and delegating request approvals
With the completion of phase two:
v Your organization has begun an effective streamlining of the administrative
activities involved in processing and maintaining user accounts. After a
successful implementation on a subset of users or a subset of systems and
applications, you can expand the capabilities to include a larger user population
and more approval workflows, if needed. Alternatively, you can implement
phase three capabilities for the same users and resources under phase two
implementation, before you expand the scope of phase two.
v Users, systems, and applications that have been brought under the identity
management umbrella can now be tracked for inconsistencies and
noncompliances. Among the items audit teams look for are orphan accounts or
inappropriate access privileges that exist on mission-critical or data-sensitive
systems. You can now generate and archive reports related to user account
activity.
Phase 3: Role-based access control
Phase three builds on the capabilities of phases one and two by implementing the
role-based access control capability. This capability represents a large step in
implementing greater software automation control throughout an organization
because you introduce identity administration by role management.
In phase three your organization uses its business process analyses to implement:
v Rule sets that are used in automating the creation and deletion of user accounts
v Rule sets that apply to organizational boundaries in the organization
v Roles that categorize users according to their characteristics and resource needs
v Provisioning policies that implement rule sets for granting access to resources
through entitlements
These tasks establish role-based access control to resources, which extends the
identity management solution to use software-based processes and reduce user
manual interaction in the provisioning process.
Because role-based access control uses software-based processes to implement and
execute key organizational functions, you must:
v Obtain input and buy-in from application and system owners and administrators
v Efficiently design and implement data channels and user organizations
v Provide for consistent and high quality updating of users and user credentials
through the identity data feed
v Exercise flexibility in implementing and refining the organizational roles and
policy rules
To implement phase three, build the role-based access control capability
incrementally by starting with a small user population. After testing and
refinement, expand the capability to other user populations in the organization
tree.
Phase 4: Self-regulating user administration
Phase four extends the capabilities of the first three phases and implements the
self-regulating user administration capability.
In phase four your organization:
Chapter 4. Planning to deploy Tivoli Identity Manager 69
v Begins the roll-out of one or more customizations that expand the scope of the
identity management solution to include systems and applications that are not
supported by default by Tivoli Identity Manager. These implementations might
include all phases (design, test, and integration into a production environment),
or your organization might already have begun some or all of the design and
test of the customizations during the first three phases. Customization projects
include those for operating system platforms and well as applications. See
“Defining a customization plan” on page 52 for more information about
customization projects.
v Extends the organizational umbrella to include all user accounts that are still
outside of the scope of Tivoli Identity Manager. This step might include
implementing projects to include new data feeds of users or business partners
that were not included in earlier phases.
v Extends the scope of workflows to support all authorization management levels
that were not included in the earlier phases, including associated organizations
that are outside of your organizational boundaries. Typically, these organizations
are represented in the identity management organization tree as business partner
organizations. See “Designing the organization tree” on page 71 for more
information about designing your organization tree for effective identity
management.
v Modifies roles and provisioning policies as needed, in accordance with changes
that arise from testing the expansion of role-based access control provisioning to
include customizations.
v Creates the custom reports that might be needed to support all requirements for
documenting user access and approval activities.
At the completion of phase four:
v All significant resources and user credentials in your immediate organization
should be included under the control of Tivoli Identity Manager and its services.
v All administration of user accounts should be handled by Tivoli Identity
Manager.
v One interface, the Tivoli Identity Manager interface, should be used by all
administrators.
v All reports should be in place to meet all auditing requirements.
70 IBM Tivoli Identity Manager: Planning for Deployment Guide
Chapter 5. Preparing data for the initial identity feed
Tivoli Identity Manager manages several types of information that are related to
provisioning activities. The two main types of information are person data and
account data. Person data represents the people whose accounts Tivoli Identity
Manager is managing. Account data represents the credentials of the persons and
the managed resources to which the persons have been granted access.
For Tivoli Identity Manager to provision or manage an account, it must first be
associated with a person in the organization tree. Each person in Tivoli Identity
Manager is stored in a person entity, business partner person entity, or a subclass
of each of these entities as a custom person or custom business partner person. An
administrator defines these entities in Tivoli Identity Manager before the people in
your organization are loaded into the LDAP directory server.
The most important initial task in a Tivoli Identity Manager deployment is the
loading of identities and the organization tree. The process of loading the initial
person data into the organization tree is referred to as the identity feed.
Your organization will likely need to customize some person data attributes to
define multiple person categories that represent regular employees, business
partners, temporary employees, contractors, and other types of users.
Consequently, you need to plan the identity feed processes based on the
organization tree, the types of users to be loaded, and the method you will use to
load Tivoli Identity Manager with user information from an authoritative source
(such as the human resources repository).
During an identity feed, placement rules are used to specify where person identities
are placed in the organization tree. An IBM professional services consultant can
work with your organization to design the organization tree, loading methodology,
and placement rules needed to create the tree in Tivoli Identity Manager.
This chapter describes:
v “Designing the organization tree”
v “Preparing the person data for the initial identity feed” on page 75
v “Loading the data during the initial identity feed” on page 76
v “Reconciling existing accounts with identities loaded in the initial identity feed”
on page 77
Designing the organization tree
Most likely, you will deploy Tivoli Identity Manager in phases. Depending on your
implementation approach, you can create an organization tree that represents the
part of your user population that is managed by Tivoli Identity Manager. You can
then expand and modify the organization tree as you implement more identity
management capabilities. If you use the bottom-up phased implementation, you
will likely create an organization tree that represents a large portion of your user
population.
Consider the following guidelines for designing an organization tree:
1. Create the organization tree as an LDAP directory.
© Copyright IBM Corp. 2005 71
2. As much as possible, map the organization tree to the structure of your
resources. Organizations are always reorganizing; the more your organization
reflects resource requirements, the less likely you need to reflect those changes
in your organization tree.
3. Use a simple structure to implement the lower capabilities, such as password
management. You do not need complex access control models, and you do not
need to represent the entire organizational structure.
4. Base the people branch of the organization tree on a common unit of data,
such as the surname (family name). This model is easy to deploy, requires
very little placement rule encoding for the identity feed, and is very usable.
5. Anticipate future changes to the organization tree as much as is practical.
6. Carefully consider how you organize and place services and other objects in
the organization tree. It is easy to move users around in the tree, but it is
more difficult to move services and policies.
7. To facilitate the management of objects in the organization tree, divide the
administrative domains for people and services that are high in the
organization tree.
8. Avoid creating organizations in the tree that contain people, but no
supervisors or access control item (ACI) definitions. If this is the case, you can
probably merge the organization with another organization.
9. Map provisioning policies to a distinct portion or level of the organizational
hierarchy.
10. If the initial user population is small (tens or hundreds of users), consider
loading all users into a single organizational container and then manually
moving them into their correct containers. For a large user population, plan to
load users into their correct organizational containers based on the user
attributes from the authoritative source, such as the human resources
repository. If you only have employee numbers or surnames, you might need
to use them to build the containers.
11. If you plan to use an automated identity feed mechanism from an
authoritative source, administrators do not need to navigate the organization
tree to locate and update users. Administrators need only a simple structure to
enable them to locate and work with users. Users that will only use Tivoli
Identity Manager to reset their passwords do not see the organization tree.
12. If your organization determines that the organization tree must be updated
dynamically from an authoritative source, the complexity of the operation will
likely require you to define inheritance and access control items close to the
root of the organization tree.
13. If possible, plan to define supervisors (or managers) as part of the identity
feed. Load all the identities in one feed, then with a second feed, you can
define the supervisors for each identity.
14. If your organization uses one or more JavaScript scripts to perform tasks that
use organization tree containers, ensure that you consider the impact of using
these scripts on the design of your organization tree.
You might decide to establish a considerably different organization tree from the
existing organizational structures that you currently have in place. In this case, it is
more important that you design and build the organization tree in a test
environment to ensure that it is viable and manageable.
The following topics can impact the design of the organization tree:
v “Usability” on page 73
72 IBM Tivoli Identity Manager: Planning for Deployment Guide
v “Delegated administration”
v “Inheritance of Tivoli Identity Manager objects” on page 74
v “Workflow” on page 74
v “Administrative domains” on page 75
These topics are described in detail in Organization Chart Design for IBM Tivoli
Identity Manager, REDP-3920, available through the IBM Redbook Web site:
www.redbooks.ibm.com
Usability
Consider that users of varying technical abilities might use Tivoli Identity Manager
to perform the necessary tasks. Therefore, the presentation of information and the
methods used to access identities can be important. Consider the following
usability issues:
The effort required to accomplish a task
An example of the measure of effort is the number of mouse clicks that are
required to access a screen or perform a simple task. A relatively flat
organization tree enables the administrator to reach the destination in the
organization tree quickly; however, the administrator might have to scroll
constantly to get to the needed organizational unit if the organization is
large.
The number of items (or lines) that are displayed
The number of lines that can be displayed is configurable. The type of
monitor that is used can impact how many times the administrator must
scroll to reach the desired screen. If the administrator navigates the tree
rather than using the search function, keep the number of objects that are
associated with an organizational unit to an acceptable minimum.
The response time of the system
The response time is how long the administrator has to wait for something
to happen. Numerous factors can impact system response, such as the
amount of system memory and the degree to which the system is tuned
for data throughput. The following organization tree design issues can also
affect system response latency:
Number of users in an organizational unit
The more users that exist in an organizational unit, the longer it
takes to retrieve and present the users.
Number of subunits under a given organizational unit
The more subunits that exist in an organizational unit, the longer it
takes to retrieve and present the data.
Number of lines displayed on a screen
The more lines that are displayed, the longer it takes to retrieve
and present the data.
Delegated administration
The design of the organization tree is impacted by the way you use access control
items to set up administrative roles, the scope of the roles, and who will belong to
the roles. Try to keep the administrative structure from becoming too complex.
Use the following guidelines to create access control items that meet your
objectives:
Chapter 5. Preparing data for the initial identity feed 73
Design for distributed administration
Consider where similar administrator roles apply to different parts of the
organization.
Design for different levels of administration
Consider where administrators have the same scope of users but different
levels of access.
Design for manageability
Consider access control to other types of objects in the organization (not
just identities), including policies and organization roles.
Use administrative domains to simplify access control
Consider how administrative domains can be used in place of, and as a
supplement to, access control items and organizational structure items to
simplify access control. See “Administrative domains” on page 75.
Inheritance of Tivoli Identity Manager objects
The scope of influence is a key tool in designing the organization tree. Scope of
influence can be used to control access at the current level only, or to all
subsequent levels below the current level in the tree.
Scope of influence can be specified for the following items:
Provisioning policies, organization roles, and services
Services must be located at or below the level of the policy, while roles and
identities can be located anywhere in relation to policies, services, and
other identities.
Static and dynamic roles
Static roles can be located anywhere in the organization tree and any
identity can be associated with a static role. The scope of a dynamic role is
relative to its position in the organization tree; organizational units inherit
the dynamic roles of units above them as well as dynamic roles that are
applied to the same level.
Service selection policies
A service selection policy extends the function of a provisioning policy by
enabling the provisioning of accounts based on person attributes. A service
selection policy is enforced when it is defined as a target of a provisioning
policy. A service selection policy uses a JavaScript script to determine
which service to use, and defines provisioning based on the instructions in
the script. The logic in the JavaScript typically uses person object attributes
to determine which service to use, which is often the person’s location in
the organization tree.
Identity policies and password policies
These types of policies must be placed at the same level or a higher level
than the services to which they are applied.
Workflow
Workflows can be placed anywhere in the organization tree. A workflow does not
have to be associated with a higher level in the organization tree than the identities
to which it applies.
A workflow object in the organization tree can contain one or more participants
and escalation participants. A participant is a signature authority that approves or
rejects a provisioning request. A participant can be one or more specified
74 IBM Tivoli Identity Manager: Planning for Deployment Guide
individuals. You can map an object, such as an ITIM user, to a participant, or you
can map dynamic participant types, which are determined when the workflow is
executed.
To effectively implement workflows, develop an understanding of how they are
used in the identity management solution. Some examples of questions to answer
include:
v Do you need common workflows that apply to all parts of the organization? If
so, workflows that use generic participant types (requestor, requestee, service
owner, and system administrator) might meet your objectives.
v How will you define approvers? For example, will each person’s manager
(supervisor) be defined on the person object, or will the manager be defined on
the organizational unit? If the manager is defined on the person object, then the
placement of the manager does not impact the organizational structure. If you
assign the manager to an organizational unit, the structure must reflect the scope
of the manager. However, managing the supervisors of containers, such as
organizational units, creates far less overhead than managing the supervisors
that are associated with each individual. An exception to this guideline applies if
you are using an identity feed that includes the line management to populate
and update the organization tree.
Administrative domains
You can use administrative domains to establish the scope of access control for
people, policies, and services. On a broad scale, administrative domains can be
used in two distinctive ways, which are not mutually exclusive and can be used
together:
Manage access to services and provisioning policies
This model separates users from resources in resource access control.
Administrative domains set direct access controls on the services and
provisioning policies that map users to resources. Changes to
organizational roles that group users according to their resource needs are
outside the scope of the administrative domain. This model is suitable for
enterprises where access to resources is not separated on a geographical or
regional basis.
Manage access to organizational units or locations
This model integrates the domain administration control in the
organizational structure of the people resources. Organizational access
control items and provisioning access control items can be established only
for the people in the scope of the domain.
Preparing the person data for the initial identity feed
The first requirement for planning the design of an identity feed is to determine
the authoritative sources for the identities. Typically, the best authoritative source is
the human resources (HR) repository, but you might need to use multiple sources
to pull together the required attributes for a single identity. For example, HR can
provide basic identity information, but a person’s contact data is maintained in a
separate directory. In addition, your organization might also have other key
repositories of identities, such as directories with person information that is not
maintained in the HR repository, and directories or databases that maintain
identities for business partners, contractors, and customers.
Next, you need to determine what information to use from your identity sources as
the required attributes of a person. To help you determine which user attributes
Chapter 5. Preparing data for the initial identity feed 75
that need to be included in the initial identity feed, consider the identity manager
capabilities that you plan to implement. For example, if person attributes exist in
the data repositories that can be mapped to roles, and your organization has
planned to implement the role-based access control capability, you might include
those attributes as part of the initial identity feed.
Minimally, Tivoli Identity Manager requires the following information to manage
an identity:
v Common name (LDAP CN)
v Last name (LDAP SN)
v Whatever is part of the distinguished name for the identity (LDAP DN).
Beyond the required minimal information (CN, SN, DN), the administrator can
add other information as needed to the policies used in the solutions, such as the
following LDAP attributes:
v Title or job description
v Organizational unit (LDAP OU)
v Employee number
v Department information
v E-mail address
v Manager
Supplying only the required information in the initial identity feed might prove
inadequate depending on the amount of information that is included in the
distinguished name (DN). For example, if a person identity is assigned an
organizational unit (OU) that is not in the organization tree, or if the DN does not
contain an OU, the identity is assigned to the root organization. An administrator
can then assign the person to the appropriate organization after the identity feed
completes. However, if you are loading thousands of users in the initial identity
feed, you will want to plan the organizational structure and placement rules
carefully to ensure that the organization tree is loaded as completely and
adequately as possible to minimize cleanup work after the identity feed is
completed.
In Tivoli Identity Manager, identities are stored in an LDAP directory;
consequently, a person’s uniqueness is identified using the DN. Choosing a
common way to determine a person’s distinguished name is important to avoid
duplication of identities. For example, if multiple user IDs (LDAP UID attributes)
are assigned to a single person, the UID attribute might not be the solution to
uniquely identify persons. Multiple UIDs are handled by the IBM Tivoli Directory
Integrator LDIF parser; however, your organization needs to determine which UID
to use to uniquely identify a person in the Tivoli Identity Manager organization
tree.
Loading the data during the initial identity feed
After you determine what person attributes to load and the sources of this data,
you must plan how to load the person data into the organization tree. Your
organization can use any of several methods to load person data into the
organization tree:
v Manually define identities using the Tivoli Identity Manager interface.
76 IBM Tivoli Identity Manager: Planning for Deployment Guide
For large organizations, manually loading person data is not a practical method
because thousands of users must be defined. However, the interface is used to
add one or more persons after the initial identity feed is completed.
v Load the identities by reconciling against a DSML file or an IBM Tivoli Directory
Integrator data feed.
Loading identities by reconciling against a DSML file or using an IBM Tivoli
Directory Integrator data feed is the preferred method for loading person data.
This process loads users either by reading from a DSML-formatted file or by
querying the IBM Tivoli Directory Integrator application JNDI. Tivoli Identity
Manager uses a Directory Services Markup Language version 2 (DSMLv2)
service provider to listen for JNDI requests to add, delete, and modify users in
the organization tree.
v Load the identities through the Java Naming and Directory Interface (JNDI) API,
using an external custom application.
In most cases, users are loaded using the JNDI service provided with Tivoli
Identity Manager. An example of how to use the JNDI interface to create a
custom application for self-registration is provided in the Tivoli Identity
Manager /extensions/examples directory.
v Use an external custom application to call the published self-registration APIs.
The methods and technologies that you use to load the data depends on the type
of data sources, tools available to extract information from those sources, policies
in place that govern access to the data sources, and the programming expertise and
other knowledge sources that can be made available to create a solution for
extracting the appropriate data. For example, if your authoritative identity sources
are separate and use different data schemas and different APIs to access the data,
you can work with IBM professional services to create an identity feed solution
that uses the IBM Tivoli Directory Integrator. The IBM Tivoli Directory Integrator
can be programmed to parse information from separate sources, including (but not
limited to) LDAP directories, CSV files, and XML files, and produce an identity
feed that meets your identity management requirements.
Reconciling existing accounts with identities loaded in the initial
identity feed
When Tivoli Identity Manager is deployed in an environment where accounts are
already created, it might associate existing accounts with identities through the
alias attribute, or through a custom script based on other person attributes
provided in the identity feed. If you choose to use the alias attribute you can use
the IBM Tivoli Directory Integrator or other custom-designed scripts to associate
aliases with person identities during the initial data feed. Person-alias associations
that can be programmed as part of the initial identity feed will not have to be
manually configured after the identity feed is finished. If you use an IBM Tivoli
Directory Integrator data feed service, you can also define add-user and delete-user
functions to reconcile the identities with existing accounts.
Ideally, all possible aliases for a given identity are included in the identity feed.
The more aliases the better, but for large organizations, it might be impossible to
determine all user aliases for all accounts. The larger the number of users and user
accounts, the more programming that is required to provide aliases in an initial
identity feed.
After the initial identity feed is completed, test to ensure that all the identities are
loaded correctly. The first implementation phase will likely reveal inconsistencies in
Chapter 5. Preparing data for the initial identity feed 77
person and account data. The amount of cleanup that is needed will depend on
how well your organization prepares the identity feed data for the initial load.
78 IBM Tivoli Identity Manager: Planning for Deployment Guide
Chapter 6. Post installation planning considerations
Because your organization will implement Tivoli Identity Manager in phases, and
because this product impacts your business processes, user population,
organization, and network, you need to plan for ongoing configuration, training,
system tuning, and other tasks. This chapter introduces some tasks that are
performed after the initial installation and configuration of Tivoli Identity
Manager; however, your organization will plan for other tasks, depending on your
objectives and the identity management capabilities that you plan to implement.
This chapter describes:
v “Reconciliation, self registration, and account adoption”
v “Transfer of knowledge”
v “Staffing” on page 80
v “System tuning” on page 80
v “System availability” on page 81
Reconciliation, self registration, and account adoption
You can configure Tivoli Identity Manager to reconcile identities from authoritative
sources after changes are made to the external identity data. Using IBM Tivoli
Directory Integrator, you can set up a DSML event handler to receive the search
requests from Tivoli Identity Manager and provide the results. Examples of
reconciliation scripts are provided in the Tivoli Identity Manager
/extensions/examples directory.
You can also design a self-registration process that allows external users to request
to be added to Tivoli Identity Manager. A predefined operation workflow for self
registration can be used to process approvals for users requesting registration. If
needed to meet the requirements of your environment, you can develop a
customized application that uses the application APIs to add users to Tivoli
Identity Manager. Examples and documentation are provided in the /examples
directory. Note that any custom solutions you develop are not supported by IBM
Tivoli technical support.
Tivoli Access Manager accounts can be imported into the Tivoli Identity Manager
database using a reconciliation process. If you are using Tivoli Access Manager,
certain system accounts must be excluded, and should not be adopted into the
Tivoli Identity Manager database. Accounts can be excluded from automatic
adoption based on the profile of the service. To exclude accounts, the account
names must be entered into the LDAP directory that is used for the Tivoli Identity
Manager database. The accounts can be entered manually, or an LDIF file can be
used for the reconciliation.
Transfer of knowledge
The project manager should ensure that the implementation knowledge that you
acquire during the product test cycle (installation, configuration, tuning,
customization, if applicable, and troubleshooting) is well documented and used to
streamline the roll-out into your production environment. Because you are
implementing a phased roll-out of an comprehensive identity management
© Copyright IBM Corp. 2005 79
solution, knowledge can be developed over an extended period, across multiple
team members, and in some cases, across sites. Therefore, it is critical to put a plan
in place that coordinates and distributes the acquired expertise as you progress.
Consider developing and maintaining these knowledge repositories during each
phase of implementation:
v Documentation on user and administrator operational tasks, including hints and
tips that are specific to your implementation. For example, password
self-administration, if implemented, will require adequate online documentation
to help users perform the associated tasks.
v Documentation on troubleshooting problems that are discovered and resolved
during the testing phase of the roll-out. Include the messages, scenarios, and
steps taken to resolve the issues.
v Controlled documentation on implementation specifics, such as organizational
structure, policies, ACIs, and workflows. This documentation should be kept on
a critical path that ensures it is updated and approved as changes are made in
the production environment.
Staffing
Closely related to the documentation that you maintain to ensure a smooth transfer
of knowledge is a plan to appropriately staff each implementation phase of the
roll-out. Some of the key team members who are involved in the design of the
identity management solution, as described in “Project team members” on page 47,
might or might not continue to play important roles during the test and
production phases; therefore, each major transition will require your organization
to develop expertise on the new features and functions, as well as an
understanding of the impact to the user environment.
If you have acquired and implemented new middleware components or new
hardware components, ensure that IT staff is available to support these new
components. For example, if you are increasing security between components,
ensure that personnel are adequately trained to configure secure connections and
to troubleshoot any security-related issues.
Carefully consider the administrator positions. These individuals should have a
solid understanding of your organization’s identity management objectives, and be
empowered to make the organizational assignments and changes that meet those
objectives.
Other staffing requirements can be impacted with each roll-out phase. For example,
password self-administration can reduce the burden on help desk personnel but
require the development of documentation to help users perform
self-administrative tasks.
System tuning
Depending on the size and complexity of the implementation, you will need to
tune the software components that are used by Tivoli Identity Manager. WebSphere
Application Server and DB2 UDB (or other supported database) provide numerous
parameters to help increase data throughput, reduce system response latency, and
minimize deadlock conditions. For information about configuring tuning
parameters specifically for Tivoli Identity Manager, review the Tivoli Identity
Manager Tuning Guide technical supplement.
80 IBM Tivoli Identity Manager: Planning for Deployment Guide
System availability
To help ensure that the system software is operating at maximum efficiency, and to
minimize the potential for system failures, create a schedule for checking for
software updates to the critical components of the identity management solution.
Related software includes the following:
v Tivoli Identity Manager Server
v Database server
v Directory server
v HTTP server
v IBM Tivoli Directory Integrator
v Operating system platforms that support these products
Ensure that your organization puts in place a schedule to back up and, if needed,
recover critical Tivoli Identity Manager data when the affected systems are
operating under minimal load (typically late night). This data includes the
directory server and databases that are used by Tivoli Identity Manager.
If you use LDIF files to import backed-up directory information, stop the
WebSphere Application Server in which the Tivoli Identity Manager Server is
running before you begin importing the directory information. If the LDIF import
modifies workflows or operations, ensure that all workflows are complete before
you start the import. For more information about importing LDIF files, refer to
your directory server documentation.
Chapter 6. Post installation planning considerations 81
82 IBM Tivoli Identity Manager: Planning for Deployment Guide
Appendix A. Sample project plan
This appendix provides a sample detailed project plan. The purpose of this sample
is to demonstrate the items that can be considered and included for tracking to
conclusion during a phased roll-out of Tivoli Identity Manager.
Note the following about the layout of this plan:
v Start and finish times and criticality dependencies are omitted because these
items can vary significantly from project to project.
v Subtasks are indented.
v The predecessor task uses standard project notation, for example, 13FS-1 day
indicates that task number 13 must finish no later than 1 day after the current
task begins. 14FS+1 day indicates that task number 14 must finish 1 day before
the current task begins.
Table 12 contains the abbreviations used throughout Table 13.
Table 12. Sample identity management project implementation plan
Legend
Admin Administrator
C-PM Your organization’s assigned project manager
C-Tech System administrator or other technically qualified personnel within your
organization
Eng Engineer knowledgeable in the specified task
PM IBM Professional Services or other suitably qualified project management
consultant
TCons IBM Professional Services or other suitably qualified identity management
solution consultants
Table 13. Sample identity management project plan
Task
no. Task Resource
Predecessor
task
1 Pre-implementation
2 Analyze and verify project goals
3 Review and recap proposals and contracts PM
4 Assess project opportunities and risks PM 3
5 Identify constraints and extraordinary obstacles PM 3
6 Identify requisite nonhuman resources PM 3
7 Review scope with the project manager PM, C-PM 3, 4, 5, 6
8 Identify the success criteria PM 7
9 Project high-level scope set 8
10 Assemble core project team 2
11 Identify needed skills from IBM PM
12 Identify needed skills from organization PM, C-PM
13 Analyze staff availability PM, Admin 11, 12
© Copyright IBM Corp. 2005 83
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
14 Nominate prospective members Admin 13FS-1 day
15 Review team’s availability PM, C-PM 7FS-1 day
16 Team members accept assignment 14FS+1 day
17 Establish project goals
18 Review project goals and plans with team members PM 10
19 Develop project plan with resources identified PM 2, 10
20 Design test strategy PM, C-PM 2
21 Project communications 10
22 Publish communications plan
23 Identify and publish status update schedule PM
24 Publish problem and issue tracking instructions PM
25 Publish change control instructions PM
26 Publish team schedules PM
27 Publish team status reporting rules PM
28 Publish Tivoli Identity Manager and expense
reporting rules
PM
29 Identify and publish position functional
responsibilities
PM 16
30 Project kick-off 2, 10, 17
31 Confirm work space suitability PM, C-PM 34FS-2 days
32 Confirm IBM and organization teams are in place PM, C-PM 34FS-2 days
33 Confirm resources are suitable and in place PM, C-PM 34FS-2 days
34 Conduct kick-off meeting PM, C-PM
35 Project preliminaries in place 2, 10, 21, 30
36
37 Implementation 35
38 Design and analysis
39 Analyze and design organizational units
40 Analyze and design organizational roles PM
41 Analyze and design provisioning policies and
workflows
PM
42 Analyze and design Tivoli Identity Manager
security (ACIs and ITIM groups)
PM
43 Analyze and design password policies PM
44 Analyze and design identity policies PM
45 Analyze and design high level data import
methods
TCons
46 Document hardware and software architecture TCons
47 Set up development and test environments
48 Identify and set up hardware
49 Configure hardware C-Tech
84 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
50 Verify system size requirements C-Tech
51 Establish interconnect to network C-Tech
52 Produce hardware and software architecture
diagram
TCons
53 Review Architecture with client PM
54 Install software C-Tech 48
55 Install or validate operating systems and patches C-Tech
56 Install or validate database engine and patches C-Tech
57 Install or validate Web proxy TCons
58 Install or validate directory server TCons
59 Install Tivoli Identity Manager systems 54
60 Install Tivoli Identity Manager server TCons
61 E-mail notification installation and configuration
62 Install or configure SMTP on the server TCons
63 Install adapters 61
64 Adapter 1
65 Install adapter 1 TCons
66 Configure adapter 1 TCons 65
67 Review and approve adapter 1 installation TCons 66
68 Adapter 2
69 Install adapter 2 TCons
70 Configure adapter 2 TCons 69
71 Review and approve adapter 2 installation TCons 70
72 Configure Tivoli Identity Manager
73 Configure adapter forms
74 Configure adapter 1 form
75 Identify required variables TCons
76 Modify standard forms TCons 75
77 Obtain customer signoff on forms
development
TCons 76
78 Configure adapter 2 form
79 Identify required variables TCons
80 Modify standard forms TCons 79
81 Obtain customer signoff on forms
development
TCons 80
82 Configure organizational roles 118
83 Configure organizational roles PM
84 Test organizational roles PM 83
85 Configure provisioning policies
86 Configure provisioning policies PM
Appendix A. Sample project plan 85
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
87 Configure workflow 86
88 Test provisioning policies and workflow PM 87
89 Configure Tivoli Identity Manager security
(ACIs and groups)
90 Create ITIM groups PM
91 Configure Tivoli Identity Manager security
(ACIs)
PM
92 Test Tivoli Identity Manager security (ACIs
and groups)
PM 91
93 Configure password policies
94 Configure password policies TCons
95 Test password policies PM 94
96 Configure identity policies
97 Configure identity policies TCons
98 Test identity policies PM 97
99 Review and approve Tivoli Identity Manager
configuration
PM, C-PM 98
100 Develop data import methods
101 Full HR data load
102 Design data extraction method PM, TCons
103 Obtain schema and file layout PM
104 Get access to sample data PM 103
105 Map data to Tivoli Identity Manager data TCons 104
106 Get test file PM 103FS+3
days
107 Load test data TCons,
C-Tech
106
108 Review results and approve PM, C-PM 107
109 Incremental HR data load
110 Design data extraction method PM, TCons
111 Obtain schema and file layout 110
112 Get access to sample data PM 111FS+2
days
113 Code incremental load routines TCons 112
114 Get test file PM 111FS+3
days, 113
115 Load test data TCons 114
116 Automate incremental load TCons 115
117 Review results and approve PM, C-PM 116
118 Load and configure organization tree
119 Design extraction method PM
120 Obtain schema and file layout PM 119
86 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
121 Map data to Tivoli Identity Manager schema TCons 120
122 Get access to test data TCons 121
123 Execute test TCons 122
124 Review results and approve TCons
125 Load full set of organization chart info TCons 124
126 Review results and approve C-PM 125
127 Test overall Tivoli Identity Manager processes 107
128 Test Tivoli Identity Manager security policies
129 Test proper access for Tivoli Identity Manager
administrators
TCons
130 Test proper exclusion from administrative
tasks for non-administrators
TCons
131 Test manual registration
132 Add user TCons
133 Delete user TCons 132
134 Transfer user between organizational units TCons 133
135 Test modification of user data TCons 134
136 Test provisioning policies (repeat for each policy)
137 Test automatic provisioning on import from
HR feed (repeat for each organization role)
TCons
138 Test manual provisioning (repeat for each
organization role)
139 Test for exclusion based on organizational
role
TCons
140 Test for inclusion based on organizational
role
TCons
141 Test workflow
142 Test approvals TCons
143 Test rejections TCons
144 Test adapter (repeat for each adapter)
145 Add accesses TCons
146 Change accesses TCons
147 Suspend accesses TCons
148 Restore accesses TCons
149 Reset passwords TCons
150 Change passwords TCons
151 Delete accesses TCons
152 Run reconciliations TCons 145, 146,
147, 148,
149, 150, 151
153 Setup and test reconciliation schedule TCons
154 Review and approve test results TCons
Appendix A. Sample project plan 87
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
155 Prepare production systems
156 Train Tivoli Identity Manager administrator
157 Ensure hardware is available
158 Configure hardware 157
159 Receive and inventory hardware C-Tech
160 Install hardware C-Tech 159
161 Execute manufacture’s check list C-Tech 160
162 Verify manufacture’s check list OK C-Tech 161
163 Verify hardware requirements 162
164 Verify disk space size to requirements TCons
165 Verify memory size to requirements TCons
166 Verify network capabilities to requirements TCons
167 Prepare software environment 163
168 Install or validate operating systems and patches C-Tech
169 Install or validate database engine and patches C-Tech
170 Install or validate Web proxy TCons
171 Install or validate directory server TCons
172 Hardware and software environment tuning and testing 167
173 Tune system for performance C-Tech,
TCons
174 Test system including network interconnections C-Tech,
TCons
175 Assess impact on network traffic C-Tech,
TCons
176 Review results and sign off C-Tech,
TCons
175, 173, 174
177 Install Tivoli Identity Manager systems 167
178 Tivoli Identity Manager Server installation TCons
179 Install and configure database TCons
180 Install and configure directory server TCons
181 Install Tivoli Identity Manager TCons
182 Review and approve PM, C-PM 179, 181
183 E-mail notification installation and configuration 178
184 Install SMTP on the server TCons
185 Install adapters 178
186 Adapter 1
187 Install adapter 1 TCons
188 Configure adapter 1 TCons 187
189 Review and approve adapter 1 installation TCons 188
190 Adapter 2
88 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
191 Configure adapter 2 TCons
192 Configure adapter 2 TCons 191
193 Review and approve adapter 2 installation TCons 192
194 Configure Tivoli Identity Manager 127 ,178, 185
195 Configure adapter forms
196 Configure adapter 1 form
197 Modify standard forms TCons
198 Configure adapter 2 form
199 Modify standard forms TCons
200 Test adapter forms configuration TCons
201 Configure organizational roles 233
202 Configure organizational roles PM
203 Test organizational roles PM 202
204 Configure provisioning policies and
workflow
205 Configure provisioning policies PM
206 Configure workflow TCons 205
207 Test provisioning policies and workflow PM 206
208 Configure Tivoli Identity Manager security
(ACIs and groups)
209 Create ITIM groups PM
210 Configure Tivoli Identity Manager security
(ACIs)
PM 209
211 Create Tivoli Identity Manager
administrator accounts
210
212 Test Tivoli Identity Manager security (ACIs
and groups)
PM 211
213 Configure password policies
214 Configure password policies TCons
215 Test password policies PM 214
216 Configure reconciliation schedule
217 Configure reconciliation schedule TCons
218 Test reconciliation schedule PM 217
219 Configure identity policies
220 Configure identity policies TCons
221 Test identity policies PM 220
222 Review and approve Tivoli Identity Manager
configuration
PM, C-PM 195, 201,
204, 208,
213, 216, 219
223 Test production system for regression 177, 107
224 Re-run random subset of test cases TCons
Appendix A. Sample project plan 89
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
225 Clean up test data TCons
226 Coordinate with client’s change control process
227 Analyze the client’s process PM
228 Develop Tivoli Identity Manager considerations
document
PM
229 Publish process procedures for team PM
230 Load production data 178
231 Load full set of HR data TCons
232 Configure and test incremental data loading
routines
TCons
233 Load or configure full set of organization chart
information
TCons
234 Review results and obtain signoff PM 233
235 Reconcile production adapters 231
236 Reconcile adapter 1 TCons
237 Reconcile adapter 2 TCons
238 Review results TCons
239 Advise on cleanup procedures TCons
240 Setup production recon schedule TCons
241 Verify schedule works properly TCons
242 Create audit trails reports 235
243 Analyze needs TCons
244 Develop specifications TCons
245 Develop reports TCons
246 Test reports TCons
247 Review and obtain signoff PM 246
248 Fine tune Tivoli Identity Manager system performance 155
249 Advise customer on operating system performance
issues
TCons
250 Advise customer on database performance issues TCons
251 Advise customer on network performance issues TCons
252 Turn over Tivoli Identity Manager and client-specific
documentation
PM 155
253 Acceptance testing 155
254 Select test cases from test plan PM
255 Execute acceptance tests TCons 254
256 Correct problems TCons 255
257 Review and obtain signoff PM 256
258 Clean up production environment of acceptance
test data
TCons 257
259 Training 253
90 IBM Tivoli Identity Manager: Planning for Deployment Guide
Table 13. Sample identity management project plan (continued)
Task
no. Task Resource
Predecessor
task
260 Tivoli Identity Manager administrator
261 Conduct end-user and help desk education
262 Get Tivoli Identity Manager ready for production 258
263 Roll to production environment 257
264 Schedule turn over to IBM support PM
265 Schedule move to production PM
266 Coordinate move with change control processes TCons
267 Migrate Tivoli Identity Manager to production TCons 262, 266
268 Check conformance to plans PM
269 Document quality management processes and
license list
PM
270 Obtain customer signoff PM 267
271 Tivoli Identity Manager implemented in production 263
272
273 Customize adapters (if any) 271
274 Custom adapter A
275 Analyze customization requirements TCons
276 Compare customization to standard adapter (if one
exists)
TCons 275
277 Present alternatives to client TCons, PM 276
278 Decide if customization needed PM 277
279 Develop custom adapter 278
280 Design custom adapter functional specifications TCons
281 Review and approve specifications Eng 280
282 Develop custom adapter Eng 281
283 Test and QA Eng 282
284 Review test results and signoff TCons, PM 283
285 Deliver custom adapter to client 284
286 Schedule installation with remaining adapters 285
287
288 Project close 273
289 Conduct post-implementation survey PM
290 Sign-off (final acceptance) PM
Appendix A. Sample project plan 91
92 IBM Tivoli Identity Manager: Planning for Deployment Guide
Appendix B. Support information
This section describes the following options for obtaining support for IBM
products:
v “Searching knowledge bases”
v “Obtaining fixes” on page 94
v “Contacting IBM Software Support” on page 94
Searching knowledge bases
If you have a problem with your IBM software, you want it resolved quickly. Begin
by searching the available knowledge bases to determine whether the resolution to
your problem is already documented.
Search the information center on your local system or
network
IBM provides extensive documentation that can be installed on your local
computer or on an intranet server. You can use the search function of this
information center to query conceptual information, instructions for completing
tasks, reference information, and support documents.
Search the Internet
If you cannot find an answer to your question in the information center, search the
Internet for the latest, most complete information that might help you resolve your
problem. To locate Internet resources for your product, open one of the following
Web sites:
v IBM Tivoli Identity Manager Performance Tuning Guide
Provides information needed to tune Tivoli Identity Manager Server for a
production environment. It is available on the Web at:
http://publib.boulder.ibm.com/tividd/td/tdprodlist.html
Click the I character in the A-Z product list, and then, click the IBM Tivoli
Identity Manager link. Browse the information center for the Technical
Supplements section.
v Redbooks and white papers are available on the Web at:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliIdentityManager.html
Browse to the Self Help section, in the Learn category, and click the Redbooks
link.
v Technotes are available on the Web at:
http://www.redbooks.ibm.com/redbooks.nsf/tips/
v Field guides are available on the Web at:
http://www.ibm.com/software/sysmgmt/products/support/Field_Guides.html
v For an extended list of other Tivoli Identity Manager resources, search the
following IBM developerWorks Web site:
http://www.ibm.com/developerworks/
© Copyright IBM Corp. 2005 93
Obtaining fixes
A product fix might be available to resolve your problem. You can determine what
fixes are available for your IBM software product by checking the product support
Web site:
1. Go to the IBM Software Support Web site
(http://www.ibm.com/software/support).
2. Under Products support pages A to Z, select the letter for your product name.
3. In the list of specific products, click IBM Tivoli Identity Manager.
4. Under Self help, you find a list of fixes, fix packs, and other service updates
for your product.
5. Click the name of a fix to read the description and optionally download the fix.
To receive weekly e-mail notifications about fixes and other news about IBM
products, follow these steps:
1. From the support page for any IBM product, click My support in the upper-left
corner of the page.
2. If you have already registered, skip to the next step. If you have not registered,
click register in the upper-right corner of the support page to establish your
user ID and password.
3. Sign in to My support.
4. On the My support page, click Edit profiles in the left navigation pane, and
scroll to Select Mail Preferences. Select a product family and check the
appropriate boxes for the type of information you want.
5. Click Submit.
6. For e-mail notification for other products, repeat Steps 4 and 5.
For more information about types of fixes, see the Software Support Handbook
(http://techsupport.services.ibm.com/guides/handbook.html).
Contacting IBM Software Support
IBM Software Support provides assistance with product defects.
Before contacting IBM Software Support, your company must have an active IBM
software maintenance contract, and you must be authorized to submit problems to
IBM. The type of software maintenance contract that you need depends on the
type of product you have:
v For IBM distributed software products (including, but not limited to, Tivoli,
Lotus, and Rational products, as well as DB2 and WebSphere products that run
on Windows or UNIX operating systems), enroll in Passport Advantage in one
of the following ways:
– Online: Go to the Passport Advantage Web page
(http://www.lotus.com/services/passport.nsf/WebDocs/
Passport_Advantage_Home) and click How to Enroll
– By phone: For the phone number to call in your country, go to the IBM
Software Support Web site
(http://techsupport.services.ibm.com/guides/contacts.html) and click the
name of your geographic region.v For IBM eServer software products (including, but not limited to, DB2 and
WebSphere products that run in zSeries, pSeries, and iSeries environments), you
can purchase a software maintenance agreement by working directly with an
IBM sales representative or an IBM Business Partner. For more information
94 IBM Tivoli Identity Manager: Planning for Deployment Guide
about support for eServer software products, go to the IBM Technical Support
Advantage Web page (http://www.ibm.com/servers/eserver/techsupport.html).
If you are not sure what type of software maintenance contract you need, call
1-800-IBMSERV (1-800-426-7378) in the United States or, from other countries, go to
the contacts page of the IBM Software Support Handbook on the Web
(http://techsupport.services.ibm.com/guides/contacts.html) and click the name of
your geographic region for phone numbers of people who provide support for
your location.
Follow the steps in this topic to contact IBM Software Support:
1. Determine the business impact of your problem.
2. Describe your problem and gather background information.
3. Submit your problem to IBM Software Support.
Determine the business impact of your problem
When you report a problem to IBM, you are asked to supply a severity level.
Therefore, you need to understand and assess the business impact of the problem
you are reporting. Use the following criteria:
Severity 1 Critical business impact: You are unable to use the program,
resulting in a critical impact on operations. This condition
requires an immediate solution.
Severity 2 Significant business impact: The program is usable but is
severely limited.
Severity 3 Some business impact: The program is usable with less
significant features (not critical to operations) unavailable.
Severity 4 Minimal business impact: The problem causes little impact on
operations, or a reasonable circumvention to the problem has
been implemented.
Describe your problem and gather background information
When explaining a problem to IBM, be as specific as possible. Include all relevant
background information so that IBM Software Support specialists can help you
solve the problem efficiently. To save time, know the answers to these questions:
v What software versions were you running when the problem occurred?
v Do you have logs, traces, and messages that are related to the problem
symptoms? IBM Software Support is likely to ask for this information.
v Can the problem be re-created? If so, what steps led to the failure?
v Have any changes been made to the system? (For example, hardware, operating
system, networking software, and so on.)
v Are you currently using a workaround for this problem? If so, please be
prepared to explain it when you report the problem.
The Tivoli Identity Manager serviceability tool assists in gathering information for
working with an IBM Software Support representative. The tool collects Tivoli
Identity Manager related log files, performs a check of the product JAR files,
gathers some limited configuration details, and creates a compressed file that
contains this information. The compressed file can then be transferred or e-mailed
to a support representative.
Appendix B. Support information 95
777777
Use this tool only when directed to by your support representative. For more
information, refer to the IBM Tivoli Identity Manager Problem Determination Guide.
Submit your problem to IBM Software Support
You can submit your problem in one of two ways:
v Online: Go to the ″Submit and track problems″ page on the IBM Software
Support site (http://www.ibm.com/software/support/probsub.html). Enter
your information into the appropriate problem submission tool.
v By phone: For the phone number to call in your country, go to the contacts page
of the IBM Software Support Handbook on the Web
(http://techsupport.services.ibm.com/guides/contacts.html) and click the name
of your geographic region.
If the problem you submit is for a software defect or for missing or inaccurate
documentation, IBM Software Support creates an Authorized Program Analysis
Report (APAR). The APAR describes the problem in detail. Whenever possible,
IBM Software Support provides a workaround for you to implement until the
APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the
IBM product support Web pages daily, so that other users who experience the
same problem can benefit from the same resolutions.
For more information about problem resolution, see Searching knowledge bases
and Obtaining fixes.
96 IBM Tivoli Identity Manager: Planning for Deployment Guide
77
Appendix C. 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.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
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.
© Copyright IBM Corp. 2005 97
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged should contact:
IBM Corporation
2ZA4/101
11400 Burnet Road
Austin, TX 78758
U.S.A.
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled
environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
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.
Trademarks
The following terms are trademarks or registered trademarks of International
Business Machines Corporation in the United States, other countries, or both: IBM,
IBM logo, AIX, DB2, Domino, Lotus, SecureWay, Tivoli, Tivoli logo, Universal
Database, WebSphere.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
Intel, Intel Inside (logos), MMX and Pentium are trademarks of Intel Corporation
in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a trademark of Linus Torvalds in the U.S., other countries, or both.
SAP is a trademark or registered trademark of SAP AG in Germany and in several
other countries.
98 IBM Tivoli Identity Manager: Planning for Deployment Guide
Java and all Java-based trademarks are trademarks of Sun
Microsystems, Inc. in the United States, other countries, or
both.
Other company, product, and service names may be trademarks or service marks
of others.
Appendix C. Notices 99
100 IBM Tivoli Identity Manager: Planning for Deployment Guide
Glossary
A
access. (1) The ability to read, update, delete, or
otherwise use a resource. Access to protected resources
is usually controlled by system software. (2) The ability
to use data that is stored and protected on a computer
system.
access control. In computer security, the process of
ensuring that the resources of a computer system can
be accessed only by principals in authorized ways. See
also principal.
access control list. In computer security, a list that is
associated with a resource that identifies all the
principals that can access the resource and the
permissions for those principals. See also permission
and principal.
access control item (ACI). Data that (a) identifies the
permissions of principals and (b) is assigned to a
resource.
account. An entity that contains a set of parameters
that define the application-specific attributes of a
principal, which include the identity, user profile, and
credentials.
ACI target. The resource for which you define the
access control items. For example, an ACI target can be
a service.
activity. The smallest unit of work in a workflow. See
also workflow.
adapter. (1) A set of software components that
communicate with an integration broker and with
applications or technologies in order to perform tasks,
such as executing application logic or exchanging data.
(2) A transparent, intermediary software component
that allows different software components with
different interfaces to work together.
administrative domain. A logical collection of
resources that is used to separate responsibilities and
manage permissions. See also permission.
adopt. To assign an orphan account to the appropriate
owner.
adoption rules. The set of rules that determine which
orphan accounts belong to which owners. See also
orphan account.
agent. A process that manages target resources on
behalf of a system in order to respond to requests.
aggregate message. A collection of notification
messages that are combined into a single e-mail, along
with optional user defined text.
alias. In identity management, an identity for a user,
which might match the user ID. The alias is used
during reconciliation to determine who owns the
account. A person can have several aliases, for example,
GSmith, GWSmith, and SmithG.
application server. A server program in a distributed
network that provides the execution environment for
an application program.
application user administrator. A type of person who
uses Tivoli Identity Manager to set up and administer
(a) the services that are managed by Tivoli Identity
Manager or (b) the Tivoli Identity Manager users of
those services.
approval. A type of workflow activity that allows
someone to approve or reject a request. See also
workflow.
audit trail. A chronological record of events or
transactions. You can use audit trails for examining or
reconstructing a sequence of events or transactions,
managing security, and for recovering lost transactions.
authentication. The process of verifying that an entity
is the entity that it claims to be, often by verifying a
user ID and password combination. Authentication
does not identify the permissions that a person has in
the system. See also authorization.
authorization. The process of granting a user either
complete or restricted access to an object, resource, or
function. See also authentication.
authorization owner. A user who can manage access
control items (ACIs) for a resource.
C
Certificate Authority (CA). An organization that
issues certificates. The CA authenticates the certificate
owner’s identity and the services that the owner is
authorized to use, issues new certificates, renews
existing certificates, and revokes certificates that belong
to users who are no longer authorized to use them.
challenge-response authentication. An authentication
method that requires users to respond to a prompt by
providing information to verify their identity when
they log in to the system. For example, when users
forget their password, they are prompted (challenged)
with a question to which they must provide an answer
© Copyright IBM Corp. 2005 101
(response) in order to either receive a new password or
receive a hint for specifying the correct password.
Common Criteria. A standardized method, which is
used by international governments, the United States
federal government, and other organizations, for
expressing security requirements in order to assess the
security and assurance of technology products.
connector. A plug-in that is used to access and update
data sources. A connector accesses the data and
separates out the details of data manipulations and
relationships. See also adapter.
credentials. Authentication information that is
associated with a principal. See also authentication and
principal.
D
DAML. See Directory Access Markup Language.
data model. A description of the organization of data
in a manner that reflects the information structure of an
enterprise.
data warehouse. (1) A subject-oriented collection of
data that is used to support strategic decision making.
(2) A central repository for all or significant parts of the
data that an organization’s business systems collect.
delegate (noun). The user who is designated to
approve requests or provide information for requests
for another user.
delegate (verb). (1) To assign all or a subset of
administrator privileges to another user, such that the
user can perform all or a subset of administrator
activities for a specific set of the users. (2) To designate
a user to approve requests or provide information for
requests for another user.
delegate administrator. The user who has all or a
subset of administrator privileges over a specific set of
users.
delegate administration. The ability to apply all or a
subset of administrator privileges to another user (the
delegate administrator), such that the user can perform
all or a subset of administrator activities for a specific
set of the users.
deprovision. To remove a service or component. For
example, to deprovision an account means to delete an
account from a resource. See also provision.
digital certificate. An electronic document that is used
to identify an individual, server, company, or some
other entity, and to associate a public key with the
entity. A digital certificate is issued by a certification
authority and is digitally signed by that authority. See
also Certificate Authority.
Directory Access Markup Language (DAML). An
XML specification that extends the functions of
Directory Services Markup Language (DSML) 1.0 in
order to represent directory operations. In Tivoli
Identity Manager, DAML is mainly used for server to
agent communications. See also Directory Services
Markup Language v2.0.
directory server. A server that can add, delete, change,
or search directory information on behalf of a client.
Directory Services Markup Language v1.0 (DSMLv1).
An XML implementation that describes the structure of
data in a directory and the state of the directory. DSML
can be used to locate data into a directory. DSMLv1 is
an open standard defined by OASIS. Contrast with
Directory Services Markup Language v2.0.
Directory Services Markup Language v2.0 (DSMLv2).
An XML implementation that describes the operations
that a directory can perform (such as how to create,
modify, and delete data) as well as the results of those
operations. Whereas DSMLv1 can be used to describe
the structure of data in a directory, DSMLv2 can be
used to communicate with other products about that
data. DSMLv2 is an open standard defined by OASIS.
Contrast with DSMLv1.
distinguished name (DN). The name that uniquely
identifies an entry in a directory. A distinguished name
is made up of name-component pairs. For example,
CN=John Doe, O=My Organization, C=US.
domain administrator. The owner of an
administrative domain. See also administrative domain.
dynamic content tags. A set of XML tags (based on
the XML Text Template Language (XTTL) schema) that
allows the administrator to provide customized
information in a message, notification, or report. See
also XML Text Template Language.
dynamic organizational role. An organizational role
that is assigned to a person by using an LDAP filter.
When a user is added to the system and the LDAP
filter parameters are met, the user is automatically
added to the dynamic organizational role. See also
organizational role.
E
entitlement. In security management, a data structure,
service, or list of attributes that contains externalized
security policy information.
entitlement workflow. A workflow that defines the
business logic that is used when provisioning a policy.
For example, an entitlement workflow is used to define
approvals for managing accounts. See also workflow.
102 IBM Tivoli Identity Manager: Planning for Deployment Guide
entity. A person or object about which you want to
store information or manage. For example, a person
and an organization are both entities.
entity type. Categories of managed objects. See also
entity.
escalation. The process that defines what happens and
who acts when an activity has not been completed in
the specified amount of time.
escalation limit. The amount of time, for example,
hours or days, that a participant has to respond to a
request, before an escalation occurs.
event. The encapsulated data that is sent as a result of
an occurrence, or situation, in the system.
F
failover. An operation that switches a system to a
redundant or standby system when services fail.
FESI extension. A Java extension that can be used to
enhance JavaScript code and then be embedded within
a FESI script.
Free EcmaScript Interpreter (FESI). An
implementation of the EcmaScript scripting language,
which is an ISO standard scripting language that is
similar to the JavaScript scripting language.
G
group. A collection of Tivoli Identity Manager users.
H
help desk assistant. A person who uses Tivoli Identity
Manager to assist users and managers with managing
their accounts and passwords.
I
identity. The subset of profile data that uniquely
represents a person or entity and that is stored in one
or more repositories.
identity feed. The automated process of creating one
or more identities from one or more common sources
of identity data.
identity policy. The policy that defines the user ID to
be used when creating an account for a user.
IIOP (Internet Inter-ORB Protocol). A protocol that is
used for communication between Common Object
Request Broker Architecture (CORBA) object request
brokers (ORBs).
ITIM group. A list of Tivoli Identity Manager
accounts. Membership within an ITIM group
determines the access to data within Tivoli Identity
Manager.
ITIM user. A user who has a Tivoli Identity Manager
account.
J
JDBC (Java Database Connectivity). An industry
standard for database-independent connectivity
between the Java platform and a wide range of
databases. The JDBC interface provides a call-level API
for SQL-based database access.
join directive. The set of rules that define how to
handle attributes when two or more provisioning
policies are applied. Two or more policies might have
overlapping scope, so the join directive specifies what
actions to take when this overlap occurs.
L
LDAP (Lightweight Directory Access Protocol). An
open protocol that uses TCP/IP to provide access to
directories that support an X.500 model and that does
not incur the resource requirements of the more
complex X.500 Directory Access Protocol (DAP). For
example, LDAP can be used to locate people,
organizations, and other resources in an Internet or
intranet directory.
LDAP directory. A hierarchical directory of names that
can reflect an organization’s structure or geography and
that is accessed using LDAP.
LDAP filter. A search filter that narrows the results
from an LDAP search.
LDIF (LDAP Data Interchange Format). A file format
that is used to describe directory information as well as
changes that need to be applied to a directory, such
that directory information can be exchanged between
directory servers that are using LDAP.
life cycle. Passage or transformation through different
stages over time. For example markets, brands, and
offerings have life cycles.
life cycle rules. A set of rules in a policy that
determine which operations to use when automatically
handling commonly occurring events, such as
suspending an account that has been inactive for a
period of time.
location. An entity that is a subdivision of an
organization, usually based on geographical area.
Glossary 103
M
mail. A type of workflow activity that sends a
notification to one or more users about a request.
managed resource. An entity that exists in the runtime
environment of an IT system and that can be managed.
manager. A type of person who uses Tivoli Identity
Manager to manage their own accounts and passwords
or the accounts and passwords of those people that
they supervise.
manual service. A type of service that requires
manual intervention by the service owner to complete
the provisioning request.
N
namespace. (1) The set of unique names that a service
recognizes. (2) Space reserved by a file system to
contain the names of its objects.
nested group. A group that contains another group.
See also group.
notification. A message that is sent to a user and that
explains the actions that were taken for a request.
O
operation. An action that can be performed against an
object; for example, add, modify, or delete.
operational workflow. A workflow that defines the
lifecycle process for accounts, persons, and other
entities. See also workflow.
organization. A hierarchical arrangement of
organizational units, such that each user is included
once and only once. See also organizational unit.
organization tree. A hierarchical structure of an
organization that provides a logical place to create,
access, and store organizational information.
organizational container. An organization,
organizational unit, location, business partner unit, or
administration domain.
organizational role. In identity management, a list of
account owners that is used to determine which
entitlements are provisioned to them. See also dynamic
organizational role and static organizational role.
organizational unit. A type of organizational
container that represents a department or similar
grouping of people.
orphan account. On a managed resource, an account
whose owner cannot be automatically determined by
the provisioning system.
P
participant. In identity management, an individual, a
role, a group, or a JavaScript script that has the
authority to respond to a request that is part of a
workflow. See also workflow.
password. In computer and network security, a
specific string of characters that is used by a program,
computer operator, or user to access the system and the
information stored within it.
password retrieval. The method of retrieving a new or
changed password by accessing a designated Web site
and specifying a shared secret. See also shared secret.
password strength rules. The set of rules that a
password must conform to, such as the length of the
password and the type of characters that are allowed
(or not allowed) in the password.
password strength policy. A policy that defines the
password strength rules. A password strength policy is
applied whenever a password is set or modified.
password synchronization. The process of
coordinating passwords across services and systems
such that only a single password is needed to access
those multiple services and systems.
permission. Authorization to perform activities on
resources, such as reading and writing local files,
creating network connections, and loading native code.
person. An individual in the system that has a person
record in one or more corporate directories.
plug-in. A software module that adds function to an
existing program or application.
policy. A set of considerations that influence the
behavior of a managed resource or a user.
post office. A component that collects notifications
from the appropriate workflow activities and
distributes those notifications to the appropriate
workflow participants.
principal. A person or group that has been granted
permissions.
privilege. See permission.
profile. Data that describes the characteristics of a
user, group, resource, program, device, or remote
location.
provision. (1) To set up and maintain the access of a
user to a system. (2) To create an account on a
managed resource.
provisioning. The process of providing, deploying,
and tracking a service or component.
104 IBM Tivoli Identity Manager: Planning for Deployment Guide
provisioning policy. A policy that defines the access
to various managed resources, such as applications or
operating systems. Access is granted to all users, users
with a specific role, or users who are not members of a
specific role.
R
reconciliation. The process of synchronizing data in a
central data repository with data on a managed
resource.
registration. The process of accessing a system and
requesting an account on that system.
registry. A repository that contains access and
configuration information for users, systems, and
software.
relationship. A defined association between two or
more data entities, which is used when defining a Free
EcmaScript Interpreter (FESI) extension or when
customizing the graphical user interface.
relevant data. The data that is used to complete a
workflow activity in a workflow operation at runtime.
See also workflow.
repository. A persistent storage area for data and
other application resources. Common types of
repositories are databases, directories, and file systems.
request. The item that initiates a workflow and
instigates the various activities of a workflow. See also
workflow.
request for information (RFI). A workflow activity
that requests additional information from the specified
participant. See also workflow.
resource. A hardware, software, or data entity. See
also managed resource.
restore. To activate an account that was suspended.
rights. See permission.
rule. A set of conditional statements that enable
computer systems to identify relationships and execute
automated responses accordingly.
S
schema. The fields and rules in a repository that
comprise a profile. See also profile.
scope. In identity management, the set of entities that
a policy or an access control item (ACI) can affect.
secure socket layer (SSL). A security protocol that
provides communication privacy. SSL enables
client/server applications to communicate in a way that
is designed to prevent eavesdropping, tampering, and
message forgery.
security. The protection of data, system operations,
and devices from accidental or intentional ruin,
damage, or exposure.
security administrator. A type of person who sets up
and administers Tivoli Identity Manager for users,
managers, help desk assistants, and application user
administrators.
self-registration. See registration.
service. A representation of a managed resource,
application, database, or system.
service owner. A role that identifies the person who
owns and maintains a particular service in Tivoli
Identity Manager. See also service.
service selection policy. A policy that determines
which service to use in a provisioning policy. See also
provisioning policy.
service type. A category of related services that share
the same schemas. See also service.
shared secret. An encrypted value that is used to
retrieve the initial password of a user. This value is
defined when the personal information for the user is
initially loaded into the system.
single signon (SSO). The ability of a user to log on
once and access multiple applications without having
to log on to each application separately.
static organizational role. An organizational role that
is manually assigned to a person. See also
organizational role.
supervisor. A role that identifies the person who
supervises another set of users and who is often
responsible for approving or rejecting requests that are
made by those users.
suspend. To deactivate an account so that the account
owner cannot access the service.
system administrator. A role that identifies the person
who is responsible for the configuration,
administration, and maintenance of Tivoli Identity
Manager.
T
tenant. In a hosted service environment, a virtual
enterprise instance of an application. Each tenant can
share directory servers or relational databases while
remaining completely separate service instances.
Glossary 105
to-do list. A collection of outstanding activities. See
also activity.
topic. The subject of a notification message, which
allows messages to be grouped together based on the
same task.
transition. A connection between two workflow
elements. See also workflow.
U
universally unique identifier (UUID). The 128–bit
numerical identifier that is used to ensure that two
entities do not have the same identifier. The identifier is
unique for all space and time.
user. Any individual, organization, process, device,
program, protocol, or system that uses the services of a
computing system.
V
view. A collection of graphical user interfaces that
represent the set of tasks that a particular type of user
is allowed to perform. Administrators can customize
views to contain different collections of graphical user
interfaces.
W
workflow. The sequence of activities performed in
accordance with the business processes of an enterprise.
See also activity.
work order. A workflow activity that requires a
participant to perform an activity outside of the scope
of the system.
X
XML Text Template Language (XTTL). An XML
schema that provides a means for representing dynamic
content within a message, notification, or report. The
XML tags are also called dynamic content tags. See also
dynamic content tags.
106 IBM Tivoli Identity Manager: Planning for Deployment Guide
Index
Aaccess control
item 23
list 17
management procedure 50
managing 23
organizational role 17
role-based 10
access request approval 8
accessibilitypdf format, for screen-reader software ix
statement for documentation ix
text, alternative for document images ix
account access management capabilitychecklist 56
deployment phase 67
description 7
accountsadoption 79
assign to person 71
data 71
description 17
entity 22
orphan 7, 57
Tivoli Access Manager 79
ACI definition 23
adapterscustomizing 40
identity foundation 7, 55
resource 18
types of 18
administrationaccess control 23
delegated in organization tree 73
self-regulating users 11
administrative domainorganization tree 21
organization tree design 75
administrator ITIM group 23
agent-based adapter 18
agentless adapter 18
APIs for customization 39
application serverJ2EE 36
WebSphere Application Server 28, 36
applicationscustom 41
samples directory 79
securing custom applications 40
architecture, security 33, 49
assessment, IT environment 48
audience, who should read this book v
auditingaudit trail 58
customization 40
events 18
procedures, defining 51
requirements 24
auditing and reporting capabilitychecklist 58
deployment phase 68
auditing and reporting capability (continued)description 9
authentication 33
authoritative source for identity feed 39
authority, delegating 59
authorizationentitlement 18
identity management paradigm 17
organizational role 17
provisioning policy 17
security 33
workflow 18
availabilityplanning 36
system 81
Bbackup LDIF file, importing 81
bidirectional data flow 54
bookssee publications ix
bottom-up implementation approach 64
business partnerorganization 21
person entity 16, 71
person sponsor entity 16
Ccapabilities
account access management 7
auditing and reporting 9
description 5
distributed administration 9
identity foundation 6
implementing 54
password management 7
role-based access control 10
self-regulating user administration 11
workflow and life cycle automation 8
cells, WebSphere Application Server 31
certification programs in identity management 12
checklistsaccount access management capability 56
auditing and reporting capability 59
distributed administration capability 59
identity foundation capability 55
password management capability 55
role-based access control capability 60
self-regulating user administration capability 61
workflow and life cycle automation capability 57
cluster, WebSphere Application Server 31
common name, LDAP 76
configurationoptions 29
overview 27
tasks 38
Tivoli Identity Manager components 27
© Copyright IBM Corp. 2005 107
configuration (continued)WebSphere Application Server
regular-cluster 31
single-server 29
controlled zone 34
conventionstypeface ix
used in this document ix
cost estimation 53
CSV files in identity feed 77
custom applicationssecuring 40
supported types 41
custom business partner persons 16
custom persons 16
customer supportsee Software Support 94
customizationAPIs 39
guidelines 39
plan contents 53
plan definition 52
planning 39, 52
risk response plan 53
statement of work 54
tasksadapters 40
auditing 40
identity feed from an authoritative source 39
reports 39
self registration 40
workflows 40
test plan 53
test scripts 54
Ddata
flow, bidirectional 54
historical, on database 29
transactional, on database 29
database serveravailability 81
Tivoli Identity Manager configuration 29
databasesDB2 UDB 80
historical data 29
Tivoli Identity Manager 79
transactional data 29
WebSphere 80
delegated administration 73
delegation of authority 59
deploymentapproaches to implementation 62
configuration 27
course 13
life cycleassessment and planning 48
documents produced 50
identity-related topics 50
implementation plan 49
solution adjustments 52
solution definition and design 49
solution implementation 51
overview 27
phase, solution implementation 51
phases of identity management 67
deployment (continued)planning 42
test plan 42
deployment manager, WebSphere Application Server 31
designated user 23
directory serversdefinition 29
system availability 81
directory, LDAP 71, 76
disabilities, using documentation ix
distinguished name, LDAP 76
distributed administration capabilitychecklist 59
deployment phase 68
description 9
DMZ internet zone 34
documentsrelated viii
Tivoli Identity Manager library v
domain administrators 23
DSMLevent handler 79
identity feed 77
Ee-mail servers 29
encryption, data 33
enterprise applications, custom 41
entitiesaccount 17, 22
adapter 18
business partner person 16
custom person 16
description 20
entitlement 18
identity 16, 22
identity policy 19
operations 20
organizational role 17, 22
password policy 19
person 16
policy 22
relationships between 21
service 18, 22
types 21
workflow 18, 22
entitlement workflows 18
entitlements 18
event handler, DSML 79
events 18
exporting configuration data 43
Ffeeds, identity 71
filesCSV 77
LDIF 79
XML 77
firewalls in security zones 34
fixes, obtaining 94
functional cluster configuration, limitation 31
108 IBM Tivoli Identity Manager: Planning for Deployment Guide
Ggroups
access control 17
membership 17
names 17
guidelines, project management 48
HHTTP server
definition 29
system availability 81
WebSphere Web Server plug-in 29
IIBM Certified Deployment Professional 13
IBM Certified Solution Designer 12
identity entitiesaccount 17
business partner person 16
custom person 16
person 16
identity feedsauthoritative source 39
CSV files 77
define manually 76
DSML file 77
initial 71
JNDI 77
load methods 77
person data 75
placement rule 71
process, defining 50
reconcile accounts 77
self-registration API 77
XML files 77
identity foundation capabilitychecklist 54
deployment phase 67
description 6
identity loading 71
identity managementadapters 18, 54
benefits 11
capabilities 5
certification courses 12
configuration planning 37
customization planning 39
deployment life cycle 48
deployment phases 67
description 1
entities 15
getting help in designing 12
implementation 54
paradigm 15
processes 15
products 1
resources impacted 46
solution, defining 1
identity policies 19, 74
implementation approachesadvantages and disadvantages 66
bottom-up 64
determining 62
top-down 62
implementation plan, project 45
importing LDIF file 81
information centers, searching to find software problem
resolution 93
information typesaccount data 71
person data 71
inheritance in organization tree 74
interfaces, defining 50
internet zones 33
Internet, searching to find software problem resolution 93, 94
intranet controlled zone 34
ITIM group 23
ITIM manager 23
ITIM user 23
ITIM_CLIENT role 42
ITIM_SYSTEM role 42
JJ2EE application server 36
Java componentsEJBs 40
JVM 41
servlet 41
JavaScript scriptsexamples directory 39
workflows 18
JDBC driver 29
JMS server, WebSphere embedded messaging 28
JNDI in identity feed 77
Kknowledge bases, searching to find software problem
resolution 93
Llast name, LDAP 76
LDAPattributes 76
class attribute 20
directory 71, 76
directory server 29
distinguished name 76
LDIF parser 76
UID 76
LDIFfile 79, 81
parser 76
life cycle automationSee workflow and life cycle automation capability
life cycle deploymentSee deployment, life cycle
limitations of clustering 31
loading organization tree 75
locations, organization tree 21, 75
Mmanaged resources, adapter 18
management network zone 35
management procedure, defining 50
Index 109
manualssee publications ix
MASS 5
Method for Architecting Secure Solutions 5
models, organization 20
Nnodes, WebSphere Application Server 31
Oobject inheritance in organization tree 74
online publicationsaccessing ix
operational workflows 18
organization treesadministrative domains 21
business partner organizations 21
designadministrative domains 75
considerations 71
delegated administration 73
object inheritance 74
usability 73
workflows 74
load person data 75
locations 21
managing 23
organizational units 21
structure 21
organizational roles 17, 22
organizational unitsaccess 75
description 21
LDAP 76
orphan accounts 7
Pparser, LDIF 76
password management capabilitychecklist 55
deployment phase 67
description 7
password management procedure, defining 50
passwordspolicy 19, 74
rules 20
pdf format, for screen-reader software ix
people, identity management paradigm 16
performancedistributed environment configuration 31
planning 36
personsattributes 76
custom person 16
data 71
data in organization tree 75
identity entity 16
phases of deployment, identity management 67
pilot phase, solution implementation 51
placement rules 71
plansactivities, project 48
availability 36
plans (continued)configuration 37
customization 39, 52
deployment 42
performance 36
project implementation 45
risk response 53
sample project plan 83
security 32
test plan, customization 53
policiesaccess control 60
entity 22
identity 19
organization tree design 74
password 19
provisioning 17
role-based access control 69
security 50
problem determinationdescribing problem for IBM Software Support 95
determining business impact for IBM Software Support 95
submitting problem to IBM Software Support 96
professional certification programs 12
project manager 47
project owner 47
project planscustomization 52
implementation plan 45, 53
management guidelines 48
planning activities 48
resources 53
risk response 53
sample plan 83
teamsauditor 48
project manager 47
project owner 47
subject matter expert 47
technical owner 47
trainer 48
transferring knowledge 79
provisioningaccounts 71
policy 17, 74
user 60
publicationsaccessing online ix
related viii
Tivoli Identity Manager library v
Rreconciliation
after configuration 79
description 24
identity feed 77
Redbooks Web site 5
registration, self 40
regular cluster, definition 31
reporting procedure, defining 51
reportsauditing 24
customizing 39
resourcesadapter 18
disk 36
110 IBM Tivoli Identity Manager: Planning for Deployment Guide
resources (continued)identity management paradigm 18
identity policy 19
memory 36
password policy 19
processor 36
service 18
restricted zone 34
risk response plan 53
role-based access control capabilitychecklist 60
deployment phase 69
description 10
role, organizational 17, 22
rolesITIM_CLIENT 42
ITIM_SYSTEM 42
organization tree design 74
static and dynamic 74
runtime environment, WebSphere Application Server 28
Ssample project plan 83
secured management zone 35
securityarchitecture 49
authentication 33
authorization 33
comprehensive solution 3
data encryption 33
IBM products 1
mechanisms 33
planning for 32
policy, defining 50
zones 33
self-registrationafter configuration 79
API 77
customizing task 40
self-regulating user administration capabilitychecklist 61
deployment phase 69
description 11
serversdatabase 37, 81
directory 37, 81
e-mail 29
HTTP 19, 81
Tivoli Identity Manager 81
service selection policy 74
servicesaccess control 74
entity 22
resource 18
single sign-onconfiguring 38
distributed administration capability 60
single-server, definition 29
sizing implementation costs 53
SMTP 29
Software Supportcontacting 94
describing problem for IBM Software Support 95
determining business impact for IBM Software Support 95
submitting problem to IBM Software Support 96
solutionadjustments 52
build phase 51
definition and design 49
deployment phase 51
design course 12
implementation 51
pilot phase 51
SSL authentication 33
staffingafter installation 80
before project implementation 47
stand-alone Java client custom application 41
statement of work 54
structure, organization tree 21
subject matter experts 47
supervisor 23
supported custom applications 41
systemavailability 81
resource management 36
tuning 37, 80
Ttargeted managed resources, defining 50
technical owners 47
technical requirements, defining 51
testplan, customization 53
plan, deployment 42
product life cycle 79
scripts, customization 54
text, alternative for document images ix
Tivoli software information center ix
top-down implementation approach 62
trainers 48
tree, organizationSee organization trees
tuninginformation 80
recommendations 37
typeface conventions ix
UUID, LDAP 76
uncontrolled internet zone 33
user administration, self-regulatingSee self-regulating user administration capability
user ID, create 61
user management procedure, defining 50
Vvertical cluster configuration, limitation 31
WWeb application 41
WebSphere Application Serverconfiguration
regular-cluster 31
single-server 29
definition 28
Index 111
WebSphere Application Server (continued)embedded messaging, WebSphere MQ 28
Java Message Service 28
rolesITIM_CLIENT 42
ITIM_SYSTEM 42
WebSphere Web Server plug-indefinition 29
HTTP server 29
workflow and life cycle automation capabilitychecklist 57
deployment phase 68
description 8
workflow, participant 58
workflowsapproval 8
customizing 40
entitlement 18
entity 22
life cycle automation 57
operational 18
organization tree design 74
XXML files in identity feed 77
112 IBM Tivoli Identity Manager: Planning for Deployment Guide
����
Program Number: 5724–C34
Printed in USA
SC32-1708-00
