Identity Management Design Guide

Front cover
Identity Management
Design Guide
with IBM Tivoli Identity Manager
Enterprise integration for identity
management
Complete architecture and
component discussion
Tivoli Access Manager
integration
Axel Bcker
Andrew Camp
Rick Cohen
David Edwards
Collin Penman
Thomas Santana
ibm.com/redbooks
International Technical Support Organization

Identity Management Design Guide with IBM Tivoli
Identity Manager
July 2003
SG24-6996-00
Note: Before using this information and the product it supports, read the information in
Notices on page xi.
First Edition (July 2003)

This edition applies to Version 4.4 of IBM Tivoli Identity Manager and Version 4.1 of IBM Tivoli
Access Manager for e-business.
Copyright International Business Machines Corporation 2003. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Part 1. Architecture and design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Business context for Identity and Credential Management . . . 3
1.1 Security policies, risk, due care, and due diligence. . . . . . . . . . . . . . . . . . . 4
1.2 Centralized user management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Single interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Security policy enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Central password management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.4 Delegation of administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.5 Multiple repository support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.6 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.7 Centralized auditing and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Simplify user management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Automation of business processes . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Automated default and validation policies . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Single access control models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.4 Ubiquitous management interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.5 Integration of other management architectures . . . . . . . . . . . . . . . . 11
1.4 Access control models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 The Role Based Access Control model . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Other access control models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.3 Which model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.4 Selection process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.5 Roles vs. groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.6 Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5 Identity management vs. Meta Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 2. Architecting an Identity and Credential Management solution37
2.1 Solution architectures, design, and methodologies . . . . . . . . . . . . . . . . . . 38
2.1.1 Overview and terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Copyright IBM Corp. 2003. All rights reserved.
iii
2.1.2 Implementation flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.1.3 Definition of an Identity Management solution . . . . . . . . . . . . . . . . . 43
2.1.4 Design of an Identity Management solution . . . . . . . . . . . . . . . . . . . 44
2.2 Identity Management design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.1 MASS and Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.2 Developing security architectures using MASS . . . . . . . . . . . . . . . . 52
2.2.3 Integration into the overall solution architecture . . . . . . . . . . . . . . . . 54
2.3 Business processes and Identity Management . . . . . . . . . . . . . . . . . . . . . 58
2.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapter 3. Identity Manager component structure . . . . . . . . . . . . . . . . . . 61
3.1 Logical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.1 Web User Interface Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1.2 Application Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.1.3 Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.1.4 LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.6 Resource connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2 Physical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.2.1 Component configuration and placement . . . . . . . . . . . . . . . . . . . . . 71
3.2.2 Network zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.3 Integrating with Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Chapter 4. Detailed component design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1 IBM Tivoli Identity Manager entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.1.1 Users, accounts, and attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.1.2 Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.3 Group membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.4 Managed systems and applications . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2 Identity Manager management entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.1 Organizational tree and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2.2 Identity Manager roles and ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.3 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.4 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2.5 Audit logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2.6 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.7 Entity relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.3 IBM Tivoli Identity Manager functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.1 User self-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.2 Password management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.3 Manage users and accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3.4 Apply policy to user and account management . . . . . . . . . . . . . . . . 94
4.3.5 Reconcile accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
iv
Identity Management Design Guide with IBM Tivoli Identity Manager
4.3.6 Approval workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.3.7 Produce reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.4 User interface and access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.4.1 Administrator roles, Identity Manager roles, and ACIs . . . . . . . . . . 106
4.5 Identity Manager schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.5.1 Scheduling of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.5.2 Scheduling of reconciliations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.5.3 Time limits on workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.5.4 Historical reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.6 Detailed component analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.6.1 Physical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.6.2 Software and hardware requirements . . . . . . . . . . . . . . . . . . . . . . . 117
4.6.3 IBM Identity Manager application layout . . . . . . . . . . . . . . . . . . . . . 120
4.6.4 API Javadoc (..\Identity Manager\extensions\api\ . . . . . . . . . . . . . . 123
4.6.5 LDAP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.6.6 DB2 table analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.7 Common customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.7.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.7.2 Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.8 Agent connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.9 IBM Directory Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.9.1 CSV file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.9.2 Windows NT 4 and Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.9.3 IBM Directory Integrator password synchronizer plug-in . . . . . . . . 139
4.9.4 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.9.5 IBM MQSeries and JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.9.6 JNDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.9.7 LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Chapter 5. Tivoli Access Manager integration . . . . . . . . . . . . . . . . . . . . . 145
5.1 Functional overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.2 Managing Access Manager with Identity Manager . . . . . . . . . . . . . . . . . 147
5.2.1 Creating an Access Manager service . . . . . . . . . . . . . . . . . . . . . . . 147
5.2.2 Setting up an Access Manager specific policy . . . . . . . . . . . . . . . . 149
5.2.3 Managing Access Manager groups. . . . . . . . . . . . . . . . . . . . . . . . . 154
5.2.4 Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.2.5 Automatic provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.2.6 Delegated user administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.3 Separation of duties: resource vs. user management . . . . . . . . . . . . . . . 167
5.3.1 Different types of administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.3.2 Resource management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.3.3 Identity management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.4 Integration with Tivoli Access Manager WebSEAL . . . . . . . . . . . . . . . . . 169
Contents
5.4.1 Managing LDAP attributes used by WebSEAL . . . . . . . . . . . . . . . . 169

5.4.2 Setting up Web single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.5 Access Manager for Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.5.1 Managing Access Manager accounts in sequence with UNIX . . . . 176
Part 2. Customer environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Chapter 6. Tivoli Austin Airlines Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6.1 Company profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.1.1 Geographic distribution of TAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.1.2 Organization of TAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.1.3 HR and personnel procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.2 Current IT architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.2.1 Overview of the TAA network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.2.2 TAAs e-business initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.2.3 Security infrastructure for the e-business initiative . . . . . . . . . . . . . 187
6.2.4 Secured e-business initiative architecture. . . . . . . . . . . . . . . . . . . . 188
6.2.5 Identity management and emerging problems . . . . . . . . . . . . . . . . 191
6.3 Corporate business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . 193
6.4 Project layout and implementation phases . . . . . . . . . . . . . . . . . . . . . . . 194
6.5 ROI study and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Chapter 7. Identity Management design . . . . . . . . . . . . . . . . . . . . . . . . . . 199
7.1 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
7.1.1 Phase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
7.1.2 Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
7.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
7.2.1 Extracting Phase I functional requirements. . . . . . . . . . . . . . . . . . . 201
7.2.2 Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
7.2.3 Summary of functional requirements . . . . . . . . . . . . . . . . . . . . . . . 208
7.3 Security design objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
7.3.1 Security Design Objectives: general concepts . . . . . . . . . . . . . . . . 210
7.3.2 Security Design Objectives: TAA specifics . . . . . . . . . . . . . . . . . . . 211
7.4 Design approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
7.5 Implementation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7.5.1 Logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
7.5.2 Physical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Chapter 8. Technical implementation: phase I . . . . . . . . . . . . . . . . . . . . . 227
8.1 TAAs requirement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
8.2 Initial steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
8.2.1 Initial install and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
8.2.2 Naming considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
8.3 Organization tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
vi
8.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

8.3.2 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
8.3.3 TAAs implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.4 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
8.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.5 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
8.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.5.2 Design consideration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8.6 Provisioning policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
8.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
8.7 Identity feed and HR synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
8.7.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.7.2 Using DSML identity feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
8.7.3 Design of the initial identity feed . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
8.7.4 Designing synchronization feeds . . . . . . . . . . . . . . . . . . . . . . . . . . 256
8.8 Administrator and user access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
8.8.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Chapter 9. Technical implementation: phase II . . . . . . . . . . . . . . . . . . . . 269
9.1 TAAs requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
9.2 New hire automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
9.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
9.3 User requested accounts with workflow . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
9.4 Role Based Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
9.4.1 Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
9.5 Provisioning to non-IT resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
9.5.1 Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Contents
vii

Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Appendix A. IBM Tivoli Identity Manager 4.4 installation cookbook . . . 305
Tivoli Identity Manager software overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Identity Manager component and process diagrams . . . . . . . . . . . . . . . . . . . 306
Recommended hardware and software configuration . . . . . . . . . . . . . . . . . . 308
Installation of DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Installing DB2 Version 7.2 FixPack 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Upgrading to DB2 FixPack 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
DB2 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Configuring DB2 for JDBC and JTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Confirm TCP/IP communications for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . 324
Identity Manager database creation and configuration . . . . . . . . . . . . . . . 324
Create database instance and test configuration . . . . . . . . . . . . . . . . . . . 326
Steps to uninstall DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Clean up directories and delete DB2Admin user . . . . . . . . . . . . . . . . . . . . . . 329
Install IBM Secureway LDAP 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Configuration of the IBM Secureway LDAP v4.1 . . . . . . . . . . . . . . . . . . . . . . 341
Starting the LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Change the LDAP port to support Active Directory . . . . . . . . . . . . . . . . . . . . 349
Install Identity Manager components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Create Identity Manager user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Installing Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Enter DB2 connection information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Enter LDAP connection information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Identity Manager System configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Install MQSeries 5.2 CSD05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Final configuration of Identity Manager processes . . . . . . . . . . . . . . . . . . . . . 369
Steps to run WebSphere as a service. . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Manual process to start WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Configure LDAP referential integrity plug-in with file option . . . . . . . . . . . 370
Verify Identity Manager installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Configure Windows "loopback" interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Uninstall all Identity Manager components. . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Appendix B. Corporate policy and standards . . . . . . . . . . . . . . . . . . . . . 377
Standards, practices, and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Practical example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
External standards and certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Industry specific requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Product or solution certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Nationally and internationally recognized standards . . . . . . . . . . . . . . . . . 382
viii
Legal requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Appendix C. ROI questionnaire . . . . . .
IBM Tivoli ROI analyst questionnaire . . . .
Part 1: Introduction . . . . . . . . . . . . . . .
Part 2: Tivoli Solutions . . . . . . . . . . . .
Part 3: Performance and availability . .
Part 4: Configuration and operations .
Part 5: Security management . . . . . . .
Part 6: Storage management . . . . . . .
Part 7: Additional information . . . . . . .
.......
.......
.......
.......
.......
.......
.......
.......
.......
......
......
......
......
......
......
......
......
......
.......
.......
.......
.......
.......
.......
.......
.......
.......
......
......
......
......
......
......
......
......
......
.
.
.
.
.
.
.
.
.
385
386
386
389
391
393
394
397
399
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Contents
ix
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
xi
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Access360
AIX
DB2 Connect
DB2 Universal Database
DB2
^
IBM
ibm.com
Lotus Notes
Lotus
MQSeries
Notes
Passport Advantage
Perform
RACF
Redbooks (logo)
Redbooks
SANergy
SP2
Tivoli Enterprise Console
Tivoli Enterprise
Tivoli
WebSphere
z/OS
The following terms are trademarks of other companies:

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure
Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks of others.
xii
Preface
Identity Management has always been an important factor in the systems
management discipline. Managing individual users with all their different
accounts on multiple platforms and applications in a timely manner is a crucial IT
task. In the emerging world of e-business and worldwide internet connectivity,
this discipline is becoming a major part of an enterprise security architecture.
Identity Management is the concept of providing a unifying interface to manage
all aspects related to individuals and their interactions with the business. It is the
process that enables business initiatives by efficiently managing the user life
cycle (including identity/resource provisioning for people (users)), and by
integrating it into the required business processes. Identity Management
encompasses all the data and processes related to the representation of an
individual involved in electronic transactions.
This IBM Redbook provides an approach for designing an Identity Management
solution with the IBM Tivoli Identity Manager Version 4.4. Starting from the
high-level, organizational viewpoint, we show how to define user registration and
maintenance processes using the Self Registration and Self Care Interfaces as
well as the Delegated Administration capabilities. Using the Integrated Workflow,
we automate the submission/approval processes for Identity Management
requests, and with the Automated User Provisioning, we will take workflow
output and automatically implement the administrative requests on the
environment with no administrative intervention.
This redbook is a valuable resource for security administrators and architects
who wish to understand and implement a centralized identity management and
security infrastructure.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.
xiii
Figure 1 From left to right: Collin, Andy, Thomas, Axel
Axel Buecker is a Certified Consulting Software I/T Specialist at the

International Technical Support Organization, Austin Center. He writes
extensively and teaches IBM classes worldwide on areas of Software Security
Architecture. He holds a degree in computer science from the University of
Bremen, Germany. He has 17 years of experience in a variety of areas related to
Workstation and Systems Management, Network Computing, and e-business
solutions. Before joining the ITSO in March 2000, Axel was working for IBM in
Germany as a Senior I/T Specialist in Software Security Architecture.
Andrew Camp is an IT specialist for the Tivoli Division of the IBM Software
Group in the UK. He has 15 years of experience in Systems and Network
Management and IT security. Prior to that, he served in the Royal Navy in
various roles including Unit Security Officer. He holds a degree in Mathematics
and Computing from the Open University. His special areas of expertise include
Identity Management, Security Organization, and Information Superiority.
Collin Penman is a Senior IT Specialist for IBM Tivoli Software Australia and
New Zealand. He has 12 years of experience within the Telecommunications
Industry and other related technology areas. He studied Electronic and
xiv
Telecommunications at the Northern Territory University and Electronic

Engineering at the Fremantle Institute of Technology. His special areas of
expertise include E-Business Applications, Corporate Security, SmartCards,
One-to-One Marketing, User Provisioning, and Management.
Thomas Santana is an IT specialist for Tivoli Software of the IBM Software
Group in Brazil. He has seven years of experience in System and Network
Management and IT Security. He holds a degree in Computer Science from the
University of Brasilia. His areas of expertise include System Management, Web
Development, and distributed systems. He has written extensively on other Tivoli
Software solutions.
Thanks to the following people for their contributions to this project:
Wade Wallace
International Technical Support Organization, Austin Center
Steve Henning, Tony Gullotta, Becky McKane, Robert Larson, Grey Thrasher,
Robert Adachi, Robert Schneider, Sean McDonald
IBM Tivoli Identity Manager development and marketing team
Sridhar Muppidi
IBM Security Architecture team
David Edwards
IBM Tivoli Services Australia
Stefaan Van daele
IBM Global Services Belgium
Lawrence Drenner, Melissa Griffith
IBM Austin
Eddie Hartman
IBM Norway
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You'll team with IBM technical professionals,
Business Partners and/or customers.
Preface
xv
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Send us your comments
about this or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:

redbook@us.ibm.com
Mail your comments to:

IBM Corporation, International Technical Support Organization
Dept. OSJB Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
xvi
Part 1
Part
Architecture
and design
In this part, we introduce the general components of the IBM Tivoli Identity
Manager 4.4 and what it has to offer in the identity and credential management
area of the overall security architecture. Identity Manager handles a multitude of
integration aspects with all sorts of IT infrastructures and application
environments, which are detailed throughout this part of the book. After talking
about architectures and design, Part 2, Customer environment on page 177
provides a more solution oriented, scenario based approach.
Chapter 1.
Business context for Identity

and Credential Management
As the world of e-business gains global acceptance, the traditional processes of
corporate user administration are no longer able to cope with the demands of
increased scale and scope expected from them. Identity Management is a super
set of older user provisioning systems that allows for the management of identity
and credential information for customers, partners, suppliers, automated
processes, corporate users, and others.
As organizations come to depend upon their IT assets to a greater extent than
previously, these assets attract the attention of accounting and reporting
standards. IT data and system assets will increasingly become balance sheet
line items, and therefore be subject to different audit and compliance rules.
Organizations must be able to demonstrate due care, due diligence, improved
security, and compliance with other financial rules. We should realize that any
entity using the IT systems run by an organization must be included in the scope
of Identity Management if we are to have any chance of achieving these goals.
In this chapter, we talk specifically about the business goals that drive the need
for Identity Management solutions. In addition, we also examine some of the
concepts surrounding Identity Management and how they impact upon costs and
business risk mitigation. The Role Based Access Control Model (RBAC) is
examined in greater depth, because it is creating both a valid Return On
Investment (ROI) and driving better control over the assets of an organization.
1.1 Security policies, risk, due care, and due diligence

The senior management team of an organization has to show due care in all their
dealings, including security related matters. Showing due care helps to create a
professionally managed organization, which in turn helps maintain shareholder
value. Due care can also be an important step towards avoiding claims of
negligence. From a security perspective, showing due care can be achieved by
having well thought out security policies.
Security policies have to balance a number of conflicting interests. It is easy to
write security policies that deny access, or make access controls so onerous that
either no business gain can be achieved, or the security policies are ignored in
order to make reasonable business gains. Security policies must set a sensible
level of control that takes into account not only the culture and experience of the
organization, but an appreciation of the risks involved. Security policies are
discussed in some more detail in Appendix B, Corporate policy and standards
on page 377.
Risk assessment is an important topic in its own right, but is outside the scope of
this redbook. Briefly, risk is usually assessed either formally or informally using
quantitative or qualitative methods. This can be as structured as a full external
risk assessment, or simply based on the intuition of members of an organization
who know and understand how their business is constructed and the risks
involved. Risk can be dealt with in one of four ways.
Transfer risk
The most common way of transferring risk is through

insurance. In the current economic environment, the
availability and cost of insurance is variable. Currently,
this method is more volatile than in the past.
Mitigate risk
Mitigation of risk can be achieved by identifying and

implementing the means to reduce the exposure to risk.
This includes the deployment of technologies that
improve the security cover within an organization.
Deploying an Identity Management tool mitigates the
security risks associated with poor identity management.
Accept risk
An organization may chose to accept that the impact of

the risk is bearable without transferring the risk or
mitigating the risk. This is often done where the risk or its
impact is small, or when the cost of mitigation is large.
Ignore risk
Often confused with risk acceptance, ignoring risk is all

too common. The main difference between accepting risk
and ignoring risk is that risk assessment is an implicit part
of risk acceptance. If no valid risk assessment has been
done, this should raise a warning flag. This flag points

towards the dangerous path of ignoring risk.
Understanding the risks that exist allows us to write appropriate security policies.
Having security policies shows the exercise of due care, but unless the policies
are implemented, due diligence cannot be shown. Many organizations write good
security policies only to fail at the implementation stage, because implementation
represents a difficult or costly challenge. In the next section, we show how a
centralized identity management solution can be used to enforce security
policies relating to identity management. This gives us demonstrable due
diligence with respect to identity management.
1.2 Centralized user management

The benefits of centralizing the control over user management, while still
allowing for decentralized administration, impacts two key business areas. First,
the cost of user management can be reduced, and second, security policies can
be enforced.
1.2.1 Single interface

Most large IT systems today are very complex. They consist of many
heterogeneous resources (operating systems, databases, Web application
servers, and so on). Individual user accounts exist in every database or user
identity repository. This means that an administrator has to master a different
interface on each platform or resource type in order to manage the user identity
repository. This can be compounded by having specialized administrators
focusing on specific platforms.
As the number and complexity of operations increases, the result is often an
increase in errors, due to mistakes, time delays, or coordination problems. This
situation can be resolved through the centralization of identity management and
implement role-based access control over the administration of users.
The centralization of the cross-environment management provides a common
interface for administration of user identity information, thus reducing education
and maintenance costs.
1.2.2 Security policy enforcement

Identity management policies should be implemented as part of the standards
and procedures that are derived from the corporate security policy. Implementing
identity management policies that comply with the corporate security policy is a
Chapter 1. Business context for Identity and Credential Management
key factor for a successful Identity and Credential Management system. Central
control makes it possible to accommodate the business and security policies,
enabling security administrators to implement them in an efficient and
enforceable way.
Without centralized identity management, it is almost impossible to enforce the
corporate policy in a complex environment dealing with a variety of target
platforms, different system specifications, and administrators.
1.2.3 Central password management

A user typically has multiple accounts and passwords. The ability to synchronize
passwords across platforms and applications provides ease of use for the user. It
can also improve the security of the environment because each user does not
have to remember multiple passwords and is therefore less likely to write them
down. Password strength policy can also be applied consistently across the
enterprise.
Centralized password resets enable a user or administrator to reset one or all
account passwords from a central interface. This prevents lost productivity due to
the inability to access critical systems.
If a users password changes on the target resource directly, it may be useful to
update the central system in some environments if the password conforms to the
password policy or the password change is not allowed. If password
synchronization is used, other accounts can be synchronized to maintain
consistency.
1.2.4 Delegation of administration

As the number and type of users within the scope of an organizations identity
management system changes, there will be increasing burdens on the system.
Any centralized system run by an IT department could face the burden of having
to manage users that are within other business units, or even within other partner
organizations.
A key feature of any centralized system is therefore the ability to delegate the
day to day management of users to nominated leaders in other business units or
partner organizations.
The extreme example of delegation is delegation to an individual to manage
some features of their own identity. Examples of this would be changing location
details or the password self-reset.
1.2.5 Multiple repository support

When we talk about repository support, we have to take a look at two types of
repositories:
User repositories
Endpoint repositories
User repositories
User repositories contain data about people, and most companies have many
user repositories and will continue to add new ones due to new and custom
applications. These can be:
Human resources systems
Applications
LDAP and other directories
Meta directories
Endpoint repositories
Endpoint repositories contain data about privileges and accounts, and most
companies have a great variety of these repositories implemented throughout
their environment. Some of these are:
Operating systems, such as Windows NT, AIX, or Linux
SecureID
Network devices
RACF
It is important, therefore, when considering centralized identity management
systems to be sure that the coverage of the system takes both types of
repositories into full account.
1.2.6 Workflow
Managing identity and account related data involves a great deal of approvals
and dependencies. It takes a lot of time and effort in order to collect the
necessary approvals and check for all sorts of dependencies between related
components. To reduce these often manually conducted chores, the identity
management system should have an automated workflow capability that allows
the system to:
Gather approvals
Reduce administrative workload
Reduce turn-on time for new managed identities (account generation,
provisioning, and so on)
Enforce completeness (do not do this task before everything else is
gathered.)
The workflow component is one of core value points within the identity
management solution.
1.2.7 Centralized auditing and reporting

Traditionally, many organizations have treated audit logs, on each of the
corporate repositories, as places to look for the cause of a security breach after
the fact. Increasingly, this will be seen as an inadequate use of the information
available to an organization, which could be exhibiting better due diligence if they
were to monitor and react to logged breaches in as near real time as possible.
This requirement can only be met using centralized threat management tools,
but an important step towards meeting this goal should be part of an identity
management solution. Centralized auditing and logging of all additions, changes,
and deletions made on target repositories should be part of any centralized
identity management solution.
Table 1-1 Summary of centralized identity management benefits
Centralized management
feature
Cost reduction impact
Security impact
Single interface
Lower skill set required to

add, modify, and delete
users.
Single interface leads to

less human interaction and
error.
Security policy
enforcement
Because the policy is

enforced centrally, less
time and cost is spent on
enforcement and auditing.
Security risks are reduced

because corporate
security policies are
controlled at the center.
Centralized management
feature
Cost reduction impact
Security impact
Central password
management
Users spend less time

managing multiple
passwords and
productivity gains are
therefore made.
Password strength is
uniformly applied across
the enterprise.
Delegated administration
This allows the

organization to off load
some of the day to day
workload and therefore
costs.
Changes made to
accounts by delegated
administrators still have to
conform to the security
policies in force.
Multiple repository support
Including all user

repositories in the
coverage of identity
management solutions
reduces cost of specialist
administrators.
Including all user and

account repositories in the
allows policy to be applied
uniformly.
Workflow
Reduced turn-on time and

reduced manual
administrative operations.
Approval enforcement.
Centralized auditing and

reporting
Reduced time spent on

audit trails on disparate
systems.
Centralized auditing
makes the tracing of
events more realistic and
therefore much more
secure
1.3 Simplify user management

This section talks about how to simplify the user management process. This is
largely achieved by having a clear security policy, a well organized
implementation of the policy, and sensible automation of the necessary
processes in place.
1.3.1 Automation of business processes

All user accounts have a life cycle: They are created, modified and deleted. It can
take a long time to get a new user on line, as administrators are often forced to
manually obtain approvals, provision resources, and issue passwords.
Generally, with manual work, there is the opportunity for human error and
management by mood. Self-service interfaces enable users to perform some of
these operations on their own information, such as password resets and

personal information updates.
Automating some of the business processes related to the user account life cycle
reduces the chance for error and simplifies operations.
Any centralized identity management solution needs to provide the means to
emulate the manual processes involved in provisioning requests, an approvals
workflow, and an audit trail, in addition to the normal provisioning tools.
1.3.2 Automated default and validation policies

When creating user account information, some characteristics are common to all
or a sub-set of users based on the context. Default policies, which fill in data
entry fields with pre-set values automatically if not specified, reduce the effort to
fill out those values for every account.
A validation policy ensures that information about an object complies with the
rules defined for that object in the enterprise. An example would be that the field
user name must be eight characters and start with a letter. Another validation
policy may be that every user must have at least one active group membership.
1.3.3 Single access control models

Defining an access control model for each type of resource (e-business,
enterprise and legacy platforms, and applications) in an organization can be
complex and costly. A single access control model provides a consistent way to
grant users access to the resources and control what access the user has for
that resource or across a set of resources.
For some organizations, a Role Based Access Control (RBAC) model is a good
thing to aim for, as this reduces cost and improves the security of identity
management. Access control models are discussed in 1.4, Access control
models on page 11.
1.3.4 Ubiquitous management interfaces

Work styles are changing and not everyone is office bound. Some people may
work in a different business location everyday or others may work from a home
office. Identity management interfaces should be ubiquitous to adjust to our work
styles. It may be necessary for users in partner organizations or customers to
self manage some of their account data. This means that the software on the
access device may not be under the control of the parent organization. Since a
Web browser interface is a pervasive interface available on most devices, it
10
makes sense that any identity management solution interface should be Web
based.
In order for administrators to perform their work tasks anytime from anywhere
with a network connection, the identity management solution needs to be Web
enabled and capable of being integrated with Internet facing access control
systems.
1.3.5 Integration of other management architectures

Identity management is one part of an overall security architecture. Many
organizations are experiencing the benefits of automating and centralizing
security administration. Integrating identity management with access control
solutions and the threat management architecture can help an organization to
deploy applications faster and pursue new business initiatives, while enforcing
policy compliance across the organization. Security management also needs to
integrate with systems management so that potential threats to an organization
can be detected and resolved. For example, if the threat management detects an
unpatched application server, operating system, and so on, then the systems
management tools should automatically distribute the required patch.
Within the field of identity management, the use of automated provisioning may
trigger workflows. Distributing software or updating the configuration of the users
workstation, using the software distribution functionality found in the systems
management architecture, is one example of the type of functionality required
from an identity management solution.
1.4 Access control models

This section looks at some of the access control models that are commonly
found or are planned for use with a centralized identity management solution.
Note: There are many resources available that address access control
models. For our discussion we are referring to CISSP All-in-One Exam Guide,
by Harris. Another source you might want to check out is the National Institute
of Standards and Technologies at http://www.nist.gov/.
1.4.1 The Role Based Access Control model

Role Based Access Control (RBAC), as its name suggests, is the granting of
access privileges to a user, based upon the work that they do within an
organization. This allows an administrator to assign a user to single or multiple
11
roles according to the work they are doing. Each role enables access to specific
resources.
RBAC examples
A new customer
Alex registers with an organization by completing a form

on a Web site. As a result of doing so, Alex may be
awarded the role of customer by the central user
administration system that in turn populates Alex's
account to all customer-facing resources.
A new employee
Betty, on starting with an organization, could be awarded

the role of basic user by the administrator and as a
result, her account information could be populated to the
network access system and to an e-mail system. Betty
may not yet have interacted with any of the systems, so in
this case, the administrator would have to assign the
accounts with a default password and ensure that each
system makes Betty change her password upon first
access.
A senior employee
Charles would already have the basic user role from the
time when he joined the organization. His work now
requires that access be granted to applications that are
not included within the basic user role. If he now needs
access to the accounts and invoicing systems, Charles
could be awarded the accounting role in addition to the
basic user role.
A manager
Dolly would already have the basic user role from the
time when she joined the organization and may also have
other roles. As she has been promoted to a management
post, so her needs to access other systems have
increased. It may also be, however, that her needs to
access some systems, as a result of her previous post,
are no longer appropriate in her management role. Thus if
Dolly had basic user and accounting as her roles
before promotion, it may be that she is granted the
manager, but has her accounting role rescinded. This
would leave her with the basic user and manager roles
suitable for her post.
1.4.2 Other access control models

There are two other access control models that are often found in use. These are
the Discretionary Access Control (DAC) and Mandatory Access Control (MAC)
models.
12
DAC
The DAC model is when the owner of a resource decides on whether to allow a
specific person access to their resource. This system is common in distributed
environments that have evolved from smaller operations into larger ones. When
it is well managed, it can provide adequate access control, but it is very
dependant upon the resource owner understanding how to implement the
security policies of the organization, and of all the models, it is most like to be
subject to management by mood. Ensuring that authorized people have access
to the correct resource requires a good system for the tracking of leavers,
joiners, and job changes. Tracking requests for change is often paper driven,
error prone, and can be costly to maintain and audit.
MAC
The MAC model is where the resources are grouped and/or marked according to
a sensitivity model. This model is most commonly found in military or government
environments. One example would be the markings of Unclassified, Restricted,
Confidential, Secret, and Top Secret. Users privileges to view certain resources
will be dependant upon that individuals clearance level.
1.4.3 Which model?

All three models discussed above have pros and cons associated with them.
Which model an organization uses will depend upon a number of factors,
including, but not limited to, externally mandated policies, maturity of existing
identity management processes, range of identity management target systems,
future requirements, number of users managed, and risk assessment and return
on investment statistics.
MAC
The key to this kind of system is the ability to use background security checking
of personnel to a greater level than that which would normally be carried out in a
business or non-governmental environment. It is also key for data of different
sensitivity to be kept segregated. For example, a user must not be able to cut
and paste information between documents of differing sensitivities. This has
traditionally been achieved by keeping data physically separate. In this
environment, therefore, a user may have a number of different workstations; one
for restricted, one for secret, and so on, each running on completely different and
separate architectures.
Conducting identity management across multiple sensitivity silos with one central
identity management system raises a number of issues. The central system itself
must be classified at the highest level, as it holds user rights to all sensitivity
silos. Normally in this environment, this would mandate that various security
13
certifications and accreditation processes have been completed and also that
any cryptographic keys are in hardware storage.
As the Web portal approach matures, this kind of multiple silo approach may
change, but in the short term, this would mean that a software only solution
would not be possible.
One further approach would be to treat each sensitivity silo as a discrete identity
management problem. This would mean that there is a distinct solution for each
silo and that the best access control model could be chosen from the other two.
For example, at the lowest sensitivity silo, there are likely to be many more users
that best fit an RBAC solution, while at the top level, there are fewer users and
other (physical, procedural, personnel, and technical) more rigorous controls, so
a DAC might be more appropriate.
Despite its limitations, this type of access control model will continue to be used
in military and government environments, because it provides the solid
foundation for segregation of information based upon sensitivity. Identity
management solutions for this space are probably best focused on the lower
sensitivity silo, unless approvals can be gained to connect all silos with a highly
secure management layer that includes identity management.
DAC
Discretionary Access Control is the model that is most likely to be used as a
default or evolved decentralized access control solution. Organizations are
familiar with the concept of each application administrator or owner being
responsible for granting access to the application or system owned or
administered by them. Key features of a centralized identity management system
that allows this to continue are the ability to specify over-arching corporate
security policies, combined with the ability to delegate responsibility for account
management to individual systems. A centralized identity management system
with these features allows for a reduction in the amount of management by
mood, but ensures that corporate security policies can be applied, while
allowing a degree of actual and real political ownership of the target resource.
The different access control models are compared in Table 1-2 on page 15.
14
Table 1-2 Access control model comparison and notes on desirable features
Access control model
Pros
Cons
MAC
1. Ideally suited to
military and
government security
requirements.
1. Costly to implement
because of personnel
vetting and data
segregation
requirements.
2. Highly secure.
2. Difficult to centrally
manage all identities
because of sensitivity
silos.
DAC
1. Likely to already be in
use.
1. Subject to
management by mood.
2. Easy to implement
centralized identity
management solution.
2. Policy enforcement
and audit costly.
3. Suited to most
commercial
organizations, prior to
centralized identity
management or during
conversion to RBAC.
RBAC
1. Useful for strong role

focused organizations.
2. Useful for
organizations with high
staff turnover and
reliance on temporary
or casual staff.
3. Centralized identity
management possible
but less return on
investment (ROI) than
single RBAC model.
1. RBAC design can be

difficult politically and
logically.
2. Strong policies
required particularly
where delegated
administration is used.
3. Recommended for
large user populations,
particularly where
users include
customers and partner
organizations.
Delegated administration
This allows the

organization to off load
some of the day to day
workload and therefore
costs.
Changes made to
accounts by delegated
administrators still have to
conform to the security
policies in force.
15
Access control model
Pros
Cons
Multiple repository support
Including all user

repositories in the
reduces the cost of
specialist administrators.
Including all user

repositories in the
allows policy to be applied
uniformly.
Centralized auditing and

reporting
Time spent on following

audit trails on disparate
systems is reduced.
Centralized auditing
makes the tracing of
events more realistic and
therefore much more
secure.
1.4.4 Selection process

The following questions and comments are some of the thought processes that
are used to help choose an access control model and centralized identity
management system. Figure 1-1 on page 17 and the questions following it
should show the path through the maze. Local, particularly non-functional
requirements, may modify the approach you need to take.
16
Start
Yes
Yes
11
25
Yes
12
26
No
3
21
No
No
14
No
No
9
15
No
Yes
24
Yes
No
17
23
Yes
5
No
22
27
16
4
No
Yes
No
Yes
Yes
Yes
10
28
6
30
No
Yes
7
No
18
19
20
29
Figure 1-1 Selection flow diagram
Key questions and comments:

1. Does your organization mandate the use of sensitivity silos (confidential,
secret, top secret, and so on)?
17
2. Your organization mandates the use of the sensitivity silos; does it approve
the use of one centralized identity management solution bridging all of the
sensitivity silos?
3. If you cannot bridge the sensitivity silos with one solution, the only option is to
treat each silo as a separate organization. Will your organization change its
policy on the single centralized identity management system to allow bridging
in the future?
4. Does your organization have a high staff turnover, or have a large number of
contractors or outsourced staff?
5. Is your organization large or does it have multiple geographies that are self
managing?
6. Does your organization already have a centralized or metadirectory in place
or is it planning one?
7. If your organization is already using the DAC model with resource
owners/administrators managing the identities of users, you could use a
centralized solution to imitate this or you could move to an RBAC solution. Do
you want to see further ROI and increased security?
8. If you chose a fully implement an RBAC model, will the political and business
structures within your organization fully support the design work involved?
9. DAC Design selected.
10.RBAC Design selected.
11.Implement a single centralized identity management system with users
assigned access rights based upon their approval to access one or many
sensitivity silos. This is a simple form of RBAC with one role per sensitivity
silo. It would be possible to make the silo model more granular, but this may
detract from the essentially simple nature of the implementation. It should be
noted that a user with access to one silo will gain access to all information
within that silo, and therefore, in its purest form, this architecture does not
address the issues of Privacy or Need to Know management.
12.You can implement an identity management solution in each sensitivity silo,
but should your organizations policy change, you will be able to place a
master Identity Manager over the existing silo Identity Managers to gain
maximum ROI. You should therefore select a centralized management
solution that is capable of supporting a hierarchy of identity management
systems.
13.If you have reached this point on the flowchart, then it is probably time for a
cup of coffee or a break. There is no step 13 on the flowchart.
14.Treat each sensitivity silo as a discrete problem and analyze the RBAC/DAC
requirements for each silo.
18
15.This selection is DAC. You will need to make sure that the centralized identity
management tool you selected has the capability to securely delegate the
administration of users to the resource owner through an interface that does
not require onerous training nor does it need a thick client to be distributed.
Administration of the users should be delegated to the owners of the
resources. Delegated resource control should be in line with corporate
policies. Centralized audit for non compliance reports should be submitted to
the resources owner regularly for their action.
16.Once deployed, assistance should be given to those business units that wish
to develop an RBAC model within their Owned space. In addition,
maintaining up to date business cases and continuing to win greater political
influence for the RBAC model should be attempted.
17.Has sufficient political ground been gained to implement an RBAC model?
18.Your organization has chosen to use DAC, which will not allow for some of
the ROI traditionally associated with RBAC. Other product features also show
savings, however, and you should favour products with good feature/function
coverage in these areas.
19.Workflow processing. The automation of the business processes for new
hires and so on should be seen as a priority. Reducing the waiting time for
provisioning new users will reduce productivity losses.
20.Even though DAC is the organizational model, it may still be possible to make
savings by using limited or default roles. For example, every new user would
automatically get LAN and e-mail accounts set up, while other systems
remain within the purview of the resource owners.
21.Has a period of more than 12 months passed since you last checked the
identity management system design?
22.Have any major infrastucture changes within your organizations operational
systems taken place?
23.Has the nature of the external threat you face as an organization changed
significantly?
24.A change has occurred within your operating environment or a long period of
time has passed since you last validated your identity management system
decisions. Run through the algorithm again to check on your design and
amend it, if appropriate.
25.You have selected a very simple type of RBAC to map onto the MAC model in
place within your organization. This means that you will also be placing
increased reliance upon the nature of your personnel and the vetting
processes applied to them. It is possible to improve the silo granularity, but it
will take time to design this granularity. Other software and hardware involved
with privacy management and networking, for example, may already be in
19
use within your organization. These should be factored into any design and
planning for the solution.
26.The selection flowchart seems to suggest that you will be treating each of the
sensitivity silos as a discrete identity management problem, but that you may
in the future get approval to bridge the silos. The suggested method is to use
a hierarchy, but if budgets and operational requirements allow, you could also
scrap the existing system and replace it with a single central identity
management model.
27.Reaching this point in the flowchart has meant that owing to political
limitations within your organization, you have been forced to use the DAC
model rather then the RBAC model, which you might naturally have selected.
Using DAC, however, should be seen as a stepping stone towards RBAC. In
simple terms, allowing the business owners to use the system may enable
them to create roles for their own systems. It may be possible to consolidate
these local roles into larger ones as time passes.
28.As you move into the real design and planning work involved in an RBAC
scenario, many of the customer business units will be asked for their input
into the role design problem. It may only be at this point, that customer
business units realize exactly the impact of what you are proposing upon their
rights to manage their own systems in their own way, regardless of the
organizations security policies or of the costs involved. If this happens, you
should return to question 8 and answer that question no.
29.The DAC has been selected and the focus has been on methods (other then
RBAC) of saving costs. You should not lose sight of the fact that having a
central tool also brings centralized audit capabilities that will improve the
security of an organization. This risk mitigation, while difficult to quantify, still
improves the viability of a business.
30.Wait one month before continuing. This ensures a revalidation of your identity
management strategy every month. The length of time chosen should be less
than one year, but is at the discretion of your organization, taking into account
all of the threat/risk/resource issues you face.
1.4.5 Roles vs. groups

One of the difficulties identity management system designers are facing is the
way in which the terms groups and roles are used, often interchangeably or
without a true understanding of their significance. They are defined as follows:
20
Roles
A role is specifically a description of a type of user that must be

provisioned to one or more service(s) or resource(s).
Groups
A group is specific to a target resource. It contains a subset of

the users provisioned to that resource and grants access rights
to a part of the resource.
Figure 1-2 shows the relationship between users, roles, services, and groups.
A user is assigned to a
role (or more than one
role).
A role contains the policy

for provisioning users to
a service (or more than
one service).
A service (or resource) is

the user repository that is
under the umbrella of the
identity management
system.
Groups
Groups
Groups
Groups
A group is a subset of users

who have been provisioned
to the service or resource. A
group confers access control
rights to those users for
specific parts of the service.
Groups
Groups
Figure 1-2 User/Role/Service/Group relationships
Many identity management systems allow the users to be assigned to roles and
hence provisioned to services. In addition, they can also provision users directly
to services complete with group membership.
You can therefore use these systems to merely provision users directly to
services, which is done in the absence of a valid RBAC design or in the case of
the use of pure DAC.
You can also design the RBAC system such that one service is represented by
one role. If each role represents only a single application, OS, database, and so
on, then it is technically still an RBAC system, but it is functionally closer to a
DAC system. This model is sometimes found within organizations that have not
been able to successfully overcome the underlying politics. They can therefore
claim to have upset no one and to have implemented a full RBAC system. The
21
down side to this is that you have spent the time and resources on implementing
an RBAC system that will not deliver the expected ROI. This model is therefore
pointless and not recommended unless political considerations are more
important than cost concerns.
1.4.6 Designs
The process of designing an RBAC system is fairly simple.
If we had only two services to access (Service A and Service B), then users
could be placed into one of three roles: Role 1 (Service A only), Role 2 (service B
only), and Role 3 (Service A & B).
In summary:
To access two services, the number of possible roles are three:
One role containing two services
Two roles containing one service
Similarly, to access three services, the number of possible roles are seven:
One role containing three services
Three roles containing two services
Three roles containing one service.
To access four services, the number of possible roles are 15:
One role containing four services
Four roles containing three services
Six roles containing two services
Four roles containing one service
As the number of services increases, so do the potential number of roles. By the
time twenty services are required (a lot less than the average number of services
in a standard organization), there are 1,048,575 possible roles. It is clearly not
practical to create all the possible roles and populate them. We must reduce the
number of roles to those required rather than to all those possible.
It seems that a common sense approach would be to list all the user repositories
and then to list all the users along with their account requirements. An example
of this kind of approach is shown in Table 1-3 on page 23.
22
Table 1-3 User to repository mapping

User
Repositories
NT
Internet
Customer
Application
SAP
E-mail
UNIX
Alwena
Yes
No
Yes
Yes
No
Brian
Yes
No
No
Yes
Yes
Claudette
No
Yes
No
No
No
Daphne
No
Yes
No
No
No
Elizabeth
Yes
No
No
Yes
No
Francesca
Yes
No
No
Yes
No
Geoff
No
Yes
No
No
No
Helen
Yes
No
No
Yes
No
Ian
Yes
No
No
Yes
No
Jolina
Yes
No
Yes
Yes
No
Katya
Yes
No
No
Yes
Yes
Lupe
No
Yes
No
No
No
Mike
Yes
Yes
Yes
Yes
Yes
Neil
Yes
No
Yes
Yes
No
Ondine
No
Yes
No
No
No
Peter
No
Yes
No
No
No
Queenie
Yes
Yes
Yes
Yes
Yes
Ray
Yes
No
Yes
Yes
No
Sarah
No
Yes
No
No
No
Thomas
Yes
No
No
Yes
Yes
Uist
Yes
No
No
Yes
No
Vera
No
Yes
No
No
No
William
Yes
No
No
Yes
Yes
Xerxces
Yes
Yes
No
Yes
No
23
User
Repositories
NT
Internet
Customer
Application
SAP
E-mail
UNIX
Yvette
Yes
No
No
Yes
No
Zach
Yes
No
No
Yes
Yes
Grouping these roles into similar access requirements reveals that there would
be six logical roles. So in this example, five services give rise to six roles instead
of all 31 possible roles, as shown in Table 1-4.
Table 1-4 User to repository mapping with roles
User
Role
Repositories
NT
Internet
Customer
Application.
SAP
E-mail
UNIX
Elizabeth
Basic
Yes
No
No
Yes
No
Francesca
Basic
Yes
No
No
Yes
No
Helen
Basic
Yes
No
No
Yes
No
Ian
Basic
Yes
No
No
Yes
No
Uist
Basic
Yes
No
No
Yes
No
Yvette
Basic
Yes
No
No
Yes
No
Mike
CEO
Yes
Yes
Yes
Yes
Yes
Queenie
CEO
Yes
Yes
Yes
Yes
Yes
Claudette
Customer
No
Yes
No
No
No
Daphne
Customer
No
Yes
No
No
No
Geoff
Customer
No
Yes
No
No
No
Lupe
Customer
No
Yes
No
No
No
Ondine
Customer
No
Yes
No
No
No
Peter
Customer
No
Yes
No
No
No
Sarah
Customer
No
Yes
No
No
No
Vera
Customer
No
Yes
No
No
No
24
User
Role
Repositories
NT
Internet
Customer
Application.
SAP
E-mail
UNIX
Xerxces
EMP &
CUST
Yes
Yes
No
Yes
No
Alwena
HR
Yes
No
Yes
Yes
No
Jolina
HR
Yes
No
Yes
Yes
No
Neil
HR
Yes
No
Yes
Yes
No
Ray
HR
Yes
No
Yes
Yes
No
Brian
System
Admin
Yes
No
No
Yes
Yes
Katya
System
Admin
Yes
No
No
Yes
Yes
Thomas
System
Admin
Yes
No
No
Yes
Yes
William
System
Admin
Yes
No
No
Yes
Yes
Zach
System
Admin
Yes
No
No
Yes
Yes
This is fine for 26 users and five services, but the next problem that emerges is
one of scale. The mere collection task involved for 1000 users and/or a larger
range of services becomes costly and, in larger cases, unrealistic. What is
needed is a single data source that is collected automatically and contains all
user/service information, which can be used for reporting and analysis. Many
centralized identity management solutions provide this kind of collection and
reporting facility. As we have seen in an earlier section, one way of countering
the political objections to RBAC is to implement centralized identity management
and progress towards RBAC as political support is developed. Once again,
deployment of a centralized identity management solution can be used as a tool
to develop a design for an RBAC model prior to the deployment of the RBAC
model itself.
There are a few other things to be careful of:
No matter how you collect the information, it has to be correct at the point of
collection. Examination of the user information in Table 1-4 on page 24 would
suggest that Queenie and Mike both have identical roles, in this case, CEO. In
25
practice, however, Queenie has the full access because she is the CEO, while
Mike has been with the organization since leaving school and acquired a
number of access permission, as he has moved jobs within the organization
and his access rights have not been rescinded. He is not the CEO.
Similarly, Uist and Yvette both have the basic role, but neither has worked for
the company for over a year. Both these cases highlight the need to carry out
a reality check audit as part of the process of designing an identity
management system (whether or not it is RBAC).
Some services may have no IT dependencies. If a service is provisioned and
the provisioning results in the involvement of a physical process (smart card
generation and issue, uniform manufacture, and so on), then care must be
taken not to include these potentially time delayed tasks into a workflow,
which could delay other provisioning requirements. An RBAC design should
take this type of service into account.
Up to now, we have talked about a service as if it were one repository. We
know, however, that repositories can have subsidiary groups. Most resource
targets can define at least two groups (administrators and users), so in
practical terms, the five services used in the 26 user example would be 10
services and have a potential 1023 possible roles.
Xerxces seems to be in a role of one person. He has picked up this unique
role because he is both a basic employee of the organization and he is also a
customer. We must therefore check with the security policy to see if he is
allowed this double role under one name. It makes sense in some
organizations to specifically separate Basic and Customer roles and disallow
the Emp & Cust role.
Even if an immediate RBAC design cannot be achieved, some roles should
be self-evident. A basic corporate employee user (with network and e-mail
access) and an eCustomer role (with e-business application access) are
examples. Implementation of these roles will serve to stimulate the RBAC
design process and reduce the scale of the problem.
In practice, given the likely scale of most RBAC designs, it is necessary to
include costing associated with the collection, clean up, and analysis of the
existing user/repository data. It is a strong recommendation that any centralized
identity management solution chosen should be capable of being deployed as a
tool to help with the design of the full RBAC model. While this RBAC design is in
preparation, some ROI can be gained from the automation of user provisioning
and workflow processes.
26
1.5 Identity management vs. Meta Directory

Identity management and user provisioning are often lumped together with
directory strategy and also meta directories. This problem arises because most
people have slightly differing definitions of each of these areas and, in addition,
each OEM vendor selects slightly different feature/function sets to be
implemented within their product or solution. This results in a lot of overlap and
confusion.
Figure 1-3 on page 32 shows how some of the features of both identity
management and directory strategy requirements map onto an idealized set of
products.
Typically, most organizations start with many directories and either a
requirement to reduce operating costs with user provisioning tools or a strategic
vision for a single universal directory/repository, like x.500 or Microsoft Active
Directory. These two approaches are typified by teams, such as the Strategic
Directory Team or the User provisioning Project. Their titles indicate the
direction they are likely to take.
Directory strategy teams are predisposed to recommend single directories
(x.500, RACF, MS Active Directory, and so on) as the solution to an
organizations needs, while user provisioning teams have a tendency to
recommend tools that are essentially best to address the help desk costs or user
password reset problems. Some organizations even appoint teams of both types.
They may or may not adequately communicate their plans with each other. This
can lead, in the worst cases, to political control battles for the ownership of the
space, or at best, in an agreement not to tackle the areas common to both
teams, thus leaving an unaddressed set of problems.
It is much better if organizations appoint a strategy/project team whose purview
spans both user repositories (directories and Meta Directory strategy) and the
tools needed to manage them effectively and efficiently (user provisioning and
identity management). It should go without saying that there needs to be
representative from an organizations security team appointed to this type of
project team.
Table 1-5 on page 28 and Figure 1-3 on page 32 describe some of the tool sets
that should be considered. OEM products or solutions may not map exactly to
this broad definition set, and organizations may not need to cover all these areas
in one deployment. What is key, however, is that consideration be given to all of
these areas as one integrated project and design exercise.
27
Table 1-5 Pros and cons of tools used in identity management and directory areas
Product/Solution
type
Notes
Pros
Cons
Single directory
A single repository
is mandated, for
example x.500,
RACF, and MS
Active Directory.
All users are

defined in one
place, and audit,
user management,
and reporting are
less costly.
A single directory
may require the
purchase of
administration and
management
toolkits.
Security policies
can be applied in
one place.
Many applications
may have to be
re-written or
customized to allow
authentication
and/or
authorization
against the
directory.
High degree of
flexibility.
Costly to manage.
Many directories
Normally, the state

of an organization
itself generates the
need to look
strategically at the
problem.
Little or no design
effort required.
The situation often

has evolved rather
than been
designed and
controlled.
Subject to
management by
mood.
Difficult to audit
and apply a
security policy.
More subject to
human error.
Longer
provisioning time
scales resulting in
decreased user
productivity.
Less secure
because of
orphaned
accounts.
28
Product/Solution
type
Notes
Pros
Cons
Meta Directory
A true Meta
Directory is
effectively a
complete copy of
all the user
repositories within
an organization
held in one place.
The copy is created
using a set of rules
contained within a
join engine.
This tool allows for

the creation of a
single user
directory from the
one already in
existence.
Still has multiple

points of
administration, so
costs are not
reduced.
It allows
applications written
to use a different
repository to
continue to do so.
It allows business
units to manage
users with the
existing tools, allow
the Meta Directory
to cope with the
creation of a
central directory.
Virtual Meta
Directory
The Virtual Meta

Directory is similar
to a Meta Directory,
but it does not
create a complete
copy of the multiple
user repositories;
rather, it relies
upon its join engine
to perform
organization wide
distributions of
changes detected
in the directories
under its control.
Has all the benefits

of a true Meta
Directory without
any of the same
performance
limitations.
Will be able to cope
with future
deployment of a
single directory.
The central
directory schema
definition and
creation of rule sets
can be complex
and therefore
costly.
Implementation
time scales and
future flexibility can
be unacceptable.
Can result in a
large,
non-performing
centralized
directory.
Still requires the
definition of a rule
set.
User management
tools maybe
limited.
May not have real
integration points
with identity
management tools.
May still require a
specialist to
maintain and
manage.
29
Product/Solution
type
Notes
Pros
Cons
User administration
User provisioning
tools can be
thought of as a tool
to perform a
one-way
automated push of
users held in a
central repository
(often LDAP) out to
target systems.
Some
implementations
have the ability to
manually retrieve
users, but this is
usually limited.
These kind of tools

have been around
longer than some
of the others. The
amount of user
experience is
therefore greater.
Usually based
upon a proprietary
framework that
may need to be
deployed.
Many of the other

tools, by definition,
have user
provisioning built
in. There may be
no need, therefore,
to consider this
type of product.
GUIs are often

thick client
applications.
Old technology that
is being supplanted
by more functional
Identity
Management
solutions.
Integration points
to the other parts of
the solution stack is
often limited.
May not be able to
cope with the
requirement for
Internet user
registration in
terms of scale.
30
Product/Solution
type
Notes
Pros
Cons
Identity
Management
Can be thought of
as user
provisioning plus.
The use of generic
protocols (http,
https, and so on), in
addition to better
integration with
other products,
makes this solution
the most fully
functional.
Widest range of
features based
upon modern
non-proprietary
standards.
Many solutions
(particularly those
in user provisioning
space) use this title
for their products.
This allows better

integration with
other tools (for
example, Virtual
Meta Directories)
and other pieces of
the security
architecture (for
example,
centralized
authentication and
authorization
systems).
Coverage of target
platforms must be
checked,
particularly where
no integration point
with Virtual Meta
Directories exists.
The GUI interface

is Web based,
which requires a
lower skill set user
for all interactions.
Self service and
delegated user
management,
allowing partners,
users, and
suppliers to self
manage their
information.
Approval workflow
engine to authorize
data changes.
31
User Provisioning
Policy Based Provisioning
Security Policy
Enforcement
Identity Management
Virtual Directories
User Administration
Join Engine
Virtual Meta Directory
Meta Directory
Mulitple Directories
Many directories
Centralized Directory
x.500
Process Workflows
Delegated Identity management
Self Service User management
Figure 1-3 Identity management features (blocks) mapped against solution types (arrows)
The section WEM Shipyards on page 33 gives a (fictitious) example of an

organization and three potential approaches to these problems to help clarify the
approaches to this problem set.
32
WEM Shipyards
WEM Shipyards are a small but growing ship builder. In recent years, new
management has bought more technology to the organization, which has
resulted in increased efficiency and more orders. They are currently working on
three vessels with orders for seven more. Those vessels are:
Naval Craft - HMS Nonesuch: A new Mine Counter Measures vessel that will
also have a patrol boat role. WEM Shipyards is the lead contractor for this
vessel, but much of the technology, sensors, and weapons systems are
designed and fitted by sub-contractors who need access to the WEM
Shipyards IT systems.
Americas Cup Yachts - Project Doris: A pair of 12 meter racing yachts
designed for competition in the next Louis Vuitton Cup and the Americas cup.
The customer requirements include a high level of secrecy surrounding the
design, particularly the hull below the waterline.
Traditional Gaff Cutter - Elizabeth Anne: A new yacht built, along the
traditional lines of a Bristol Pilot Cutter, but with modern electronic navigation,
communications, and control systems. Designed for safe long distance
cruising for two/three people. If successful, WEM Shipyards hopes to market
the design.
WEM Shipyards has noted that they need to continue to modernize their
technology and keep the cost of ownership to a minimum if they are to continue
to win orders. One part of this approach is to address the cost associated with IT
provisioning; in particular, user management is becoming a cost burden.
They tried using a directory strategy approach and then a user provisioning
approach. Both approaches revealed weaknesses and some of those are shown
below.
Directory strategy
Having defined the IT requirement for a single directory,

WEM Shipyards addressed a number of non functional
requirements and found that:
The team building the Elizabeth Anne had some
specialized sail making software that could not easily (and
therefore without cost) be configured to use the
designated single directory.
The same team also wanted to continue publishing
information and progress reports on the build on the Web,
but had plans to create an application to ask users to
register for access. This would be used to help market
future builds of this class. The potential for the number of
registered users from this Internet facing application was
thought to be large and management of these users must
33
be an IT function, as the build team did not have the skills

or resources. But IT was not comfortable allowing Internet
users direct access to their central directory for
authentication/authorization.
The team working on project Doris said that their
customer was uncomfortable with the use of a single user
repository particularly when some of the sub contractors
working upon HMS Nonesuch were also working on other
yachts competing for the next Americas Cup. They
required that the specialized hull design software and
therefore its data be treated separately from the single
directory approach.
The sub contractors assisting in the build of HMS
Nonesuch were happy with the idea of a single directory,
as it appeared to give them a more efficient working
interface with WEM Shipyards, while the management
overheads would be entirely borne by WEM Shipyards.
WEM Shipyards realized that they could not implement a
single central directory. At best, they could mange a
central directory with three others: the Sail Design
application repository, Internet LDAP directory, and the
Hull design repository for Doris. They concluded that in
any single directory implementation there would always
be external requirements that mandated multiple
directories and therefore, at best, an 80%/20% solution.
User Provisioning
This approach found that although there were some

improvements over the existing system of user
management, there were a number of things that stalled
the project.
The costs associated with managing sub-contractors
defined within the system still remained with WEM
Shipyards. More importantly, the customer for HMS
Nonesuch was concerned that there was no
workflow/approval process to register a user on the
system, and all that was required was a request from a
sub-contractor. Under the old system, a manual process
had been in place, but because of the automation, it was
easier for a user to be provisioned and bypass that
process.
User provisioning was one-way only. This meant that the
administrators of the target platforms, who might still
change user details locally, could corrupt the system
34
integrity, as there was no detection/synchronization

method within the solution set.
Holistic approach
WEM Shipyards came to the conclusion that this issue

was too large to address all at once. As a result, they
have chosen to address each issue one at a time. By
selecting two or possibly three solution set products and
implementing them over time, they are able to gain
maximum commercial advantage. The steps to
addressing this issues is as follows:
Step 1: Implement an Identity Management solution
(which shows the greatest ROI), as this allows them to
control their overhead.
Step 2: Integrate the system with a Virtual Meta Directory
as a second project, which would allow WEB Shipyards to
extend the scope of the solution.
Step 3: Consolidation towards a single user repository.
This latter step was not seen as being needed internally,
but it is likely that this project would start as a result of
external pressures, such as a customer requirement,
general changes to the global IT environment, or, more
realistically, as a result of a successful merger or take
over bid.
Reaching this conclusion was only possible because they took the holistic
approach and examined critically all the options. The selection of products will
have to be done on the basis that full integration, while not an immediate
requirement, is definitely mandated. Section 4.9, IBM Directory Integrator on
page 138 gives an example of the integration of an Identity Management product
with a Virtual Meta Directory product.
1.6 Conclusion
Let us finally take a look at some general goals of using a centralized Identity and
Credential Management infrastructure:
Easing compliance with security audits
Consolidating control of the user management processes
Eliminating inconsistencies from human error and "management by mood"
Reducing training costs and education requirements
Reducing help desk and overall administration costs
35
Involving less people in day-to-day management

Dividing work along organizational/departmental structures
Improving response to user changes
Leveraging user information in all business processes
Table 1-6 summarizes the business benefits of an Identity and Credential
Management solution.
Table 1-6 Identity Manager benefits
36
Features
Advantages
Benefits
Centralized Web (HTML)

administration interfaces
Provides ubiquitous
management interfaces,
and centralizes the
definition of users and
provisioning of user
services
Reduces the education

and training costs and
complexity associated with
managing from multiple
native interfaces, while
leveraging the
consolidated repository of
user information
Role-based delegated
administration
Enables delegation of
administrative privileges
along organizational and
geographical boundaries
Accommodates political or
distributed management
needs
Self-service interfaces
Enables users to perform

password resets,
password synchronization,
and modifications to
personal information
without administrative
intervention
Helps reduce help-desk

costs and eases the
burden of daily
administration on help
desk and IT staff
Embedded workflow
engine
Automates the submission

and approval processes for
access requests and
changes to user
information
Helps decrease the

potential errors and
inconsistency common to
manual business
processes
Embedded provisioning
engine and application
management toolkit
Automates the
implementation of
administrative requests on
the environment, and
provides a mechanism for
extending the
management model to
support new and custom
environments
Helps increase potential

productivity and reduce
administrative overhead,
while supporting new
business initiatives as the
company grows
Chapter 2.
Architecting an Identity and

Credential Management
solution
In order to design and architect general enterprise security solutions, you should
utilize proven methodologies and concepts. In this chapter, we discuss the
approach for architecting an Identity and Credential Management system as
being part of an overall enterprise security architecture as well as the aspects of
understanding and re-engineering enterprise business processes for managing
identities and credentials.
Background information on how to architect an enterprise security architecture
using IBMs Method for Architecting Secure Solutions (MASS) can be found in
the redbook Enterprise Security Architecture using IBM Tivoli Security Solutions,
SG24-6014. Details on business process management can be obtained from the
redbook Continuous Business Process Management with HOLOSOFX BPM
Suite and IBM MQSeries Workflow, SG24-6590.
37
2.1 Solution architectures, design, and methodologies

This redbook focuses on the design of an Identity and Credential Management
solution. In this section, we look at how to go about producing an Identity
Management solution design.
Building the design is just one part of the implementation of a solution. So we
look at the design as part of the implementation. Following that, we discuss the
Identity Management solution design and methodologies.
2.1.1 Overview and terminology

There is much confusion surrounding the terminology for architecture and
design. The terms architecture and design are often used interchangeably.
Within the generic term architecture, there are a number of terms used, including
functional architecture, operational architecture, physical architecture, logical
architecture, IT architecture, and systems architecture. While there are no
standard, universally accepted definitions, there are many good terms and many
of them mean roughly the same thing.
In Software Architecture in Practice, Second Edition, by Bass, et al, software
architecture is defined as follows:
The software architecture of a program or computing system is the structure or
structures of the system, which comprise software components, the externally
visible properties of those components, and the relationships among them.
Thus, an architecture can be thought of the bits and how they fit together.
Architectures will often be high-level, such as enterprise-wide, and not
concerned with product details. We are concerned with producing a document
detailing how a product-centric Identity Management solution will be
implemented, thus we are concerned with both the:
Architecture
Describing how the bits of the product fit together, and any
integration with external components, at an abstract level and at
a physical level
Design
How each of the bits, and any integration, are configured and/or
customized to meet the existing system environment and
solution requirements.
Architectures often present a number of views of the structures in a system. A

product-centric architecture, such as an Identity Management architecture, is
normally concerned with two architectural structures: the conceptual (or logical)
38
structure and the physical structure. Bass, et al., give the following definitions for
these:
Conceptual, or logical, structure The units are abstractions of the systems
functional requirements. These abstractions
are related by the shares-data-with relation.
This view is useful for understanding the
interactions between entities in the problem
space and their variation.
Physical structure
This view shows the mapping of software

onto hardware. It is particularly of interest in
distributed or parallel systems. The
components are hardware entities
(processors), and the links are
communication pathways. Relations
between the processors are
communicates-with. This view allows an
engineer to reason about performance,
availability, and security.
There are a number of other structures described by Bass, et al., which may be
relevant to a product-centric architecture, but we are only concerned with the
logical and physical structure.
The following terms will be used throughout this book. We attempt to be
consistent throughout this book (although this is not guaranteed to be consistent
with other IBM/Tivoli books).
Solution
This is the product-centric Identity Management

system we are designing.
Architecture
An architecture describes the structure of the system

and the relationships between components.
Logical architecture
The component, or logical, structure of the

architecture. This describes the components (both
product and external that interface to the product)
and the relationships between the products from a
data-exchange perspective. This is sometimes
referred to as the functional architecture.
Physical architecture
The physical structure of the architecture. This

describes the product placement, the hardware
requirements, the network-level design (including
communications protocols, firewall placement, and
port use) and other infrastructure components (such
as database placement and middleware use)
involved in the operational deployment of the
Chapter 2. Architecting an Identity and Credential Management solution
39
system. This is sometimes referred to as the

operational architecture.
Design
The configuration and/or customization of specific

components or sub-components within the solution
to adhere to an existing system environment and/or
solution requirements.
Be aware that different methodologies use different terminology. When

discussing the methodologies in the following section, other terms are used to be
consistent with the methodology.
2.1.2 Implementation flow

Any implementation will be part of a project and follow a standard set of steps or
phases. Most projects will be subject to methodologies defining the phase
execution and deliverables. There may be a number of methodologies involved,
such as a project management methodology (for example, IBMs WorldWide
Project Management Methodology (WWPMM)) and one or more design and
implementation methodologies (such as IBMs Method for Architecting Secure
Solutions (MASS)).
We are concerned with the product-centric architecture and design for an Identity
Management product. The project to produce the product-centric architecture will
normally follow one or more of the following:
An enterprise conducts an enterprise-wide Software Architecture project to
review the entire IT environment and produce an enterprise-wide IT
architecture. The resulting architecture may dictate the need for a solution
around Identity Management.
An enterprise conducts an enterprise-wide Security Architecture project. The
project will look at all security aspects of the enterprise (not just the IT
security). The resulting architecture will identify the security areas where the
enterprise needs to focus. This may include identifying the need for a solution
around Identity Management. This exercise will often also produce the
enterprise Security Policy document that dictates the security policy to be
applied to an enterprise, its employees, and customers.
An enterprise purchases an Identity Management solution based on specific
business needs, such as cost-cutting, audit compliance, and consistent
application of corporate standards.
These will lead to a project to deploy an Identity Management solution, which will
include developing a product-centric Architecture and Design document. This is
shown in Figure 2-1 on page 41.
40
Security
Architecture
Project
Security
Architecture
document
Enterprise
Architecture
Project
IT
Architecture
document
Need for an
Identity
Management
Product
RFP or other
requirement
specification
document
Product
selection and
purchase
Product-centric
Implementation
Project
Product-centric
Architecture and
Design document
Figure 2-1 High-level and product-specific projects
Most projects will involve business tasks (such as cost-benefit analysis and
budgeting), project management tasks (such as scheduling, resource allocation,
and risk management) and technical tasks (such as design and build). We
restrict our discussion to the technical tasks associated with the production of the
architecture and design document. Figure 2-2 on page 42 shows a set of generic
steps or phases that relate to the Architecture and Design document.
41
Initiation
Definition
Design
SoW or
Charter
Definition
Report
Architecture/
Design
Build
Figure 2-2 Generic implementation phases for a project
The steps are:

Initiation
This is the project initiation step. It will normally involve

identifying the project background and requirements at a
high level. The deliverable for this step will be some sort of
Statement of Work (SoW) or Project Charter. The
high-level requirements will have come from a preceding
project (such as an IT architecture or security architecture
project) or the software purchase requirements.
Definition
This is the project definition step, for example, where the

project is defined in detail. This involves gathering the
details; the existing systems, users, procedures, and
other information and the detailed requirements of the
solution. The deliverable for this step will be one or more
documents defining the project. These may include a
Project Definition Report, a Requirements document, a
Functional Specification, and an Existing System Analysis
document.
Design
This is the design step. It involves designing the solution.

The deliverable for this phase is the Architecture and
Design document.
Build
This is where the solution is built and implemented.
The focus of this redbook is on the design phase and production of the
Architecture and Design document (as highlighted in Figure 2-2). However, much
42
of the information required for the design will have been gathered and
documented in the Definition phase. The next section will look at this.
2.1.3 Definition of an Identity Management solution

The definition phase defines the project in detail, and involves detailing the
current environment, the problem to be solved by the solution, and the detailed
requirements for the solution.
The initial project definition will be based on the documentation that triggered this
project, such as the IT Architecture, Security Architecture, RFP, or equivalent.
These documents identify the business background, the business need for the
solution, and, normally, the business and technical requirements for the solution.
For an Identity Management solution, the following areas need to be defined in
this phase (in no particular order):
User management procedures: The procedures for managing users, who
manages users, and what is required of the solution for managing users
Password management procedures: The procedures for managing account
passwords, who manages passwords, and what is required of the solution for
managing passwords
Access control management procedures: The procedures for managing
access control, who manages access control definition, and what is required
of the solution for managing access control
Security policy: What the corporate security policy defines for users,
accounts, passwords, and access control
Target systems: The current system environment (including operating
systems, databases, applications, the network, firewalls, physical location,
and access control) and the system requirements of the solution
Interfaces: The interfaces to the current Identity Management mechanisms
and procedures and the integration requirements of the solution
Auditing and reporting procedures: 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: The other technical requirements for the solution,
such as availability and recovery
Gathering this information normally involves a series of interviews and
workshops with the people and teams involved in Identity Management. This may
include the CIO, IT executive, security management/administration team,
operations, help desk, key technical teams (NT admin, UNIX sysadmin, and so
43
on) any application development teams and business managers involved in the
project. The combination of these interviews and workshops will develop a
picture of how the system currently works and how it could be improved. It is
important to vet the wish-list from the genuine requirements. The project
owners should drive the requirements for the proposed system, although others
may contribute to an understanding of the need for the requirements.
A key component of delineating the definition and design phases is that the
existing system and solution requirements are agreed between the project owner
and the project team prior to the commencement of the design phase.
2.1.4 Design of an Identity Management solution

Eberhardt Rechtin, in Systems Architecting: Creating and Building Complex
Systems, suggests an approach for developing an architecture, differentiating
between the "system" (what is built), the "model" (a description of the system to
be built), the "system architecture" (the structure of the system), and the "overall
architecture" (an inclusive set consisting of the system architecture, its function,
the environment within which it will live, and the process used to build and
operate it).
For our Identity Management product-centric solution, the overall architecture is
the product-centric architecture, for example, the Architecture and Design
document for our Identity Management solution. However, as Identity
Management is a key player in the security space, the following discussion also
applies to the high-level security architecture.
Rechtin outlines the steps for creating a model as follows:
1. Aggregating closely related functions
2. Partitioning or reducing the model into its parts
3. Fitting or integrating components and subsystems together into a functioning
system
The security system model will be represented by the aggregation of security
functions, expressed in terms of subsystems and how the subsystems interact.
The security-related functions within a networked information system (NIS) can
be described as a coordinated set of processes that are distributed throughout
the computing environment. The notion of distributed security systems,
coordinated by design and deployment, meets the intuitive expectation that
security within an NIS should be considered pervasive. In an NIS environment,
security subsystems must be considered as abstract constructs in order to follow
Rechtin's definition.
The next sections look at the solution design process.
44
2.2 Identity Management design process

User and access control administration have been around for a few years now.
Tivoli has had the User Administration and Security Management products for
over five years. This means that there is already intellectual capital relating to the
architecture and design of the products. This could easily be extended, with the
information in the following chapters of this redbook, to produce an Identity
Manager architecture and design. The other approach is to start from the ground
up with an established methodology.
The redbook Enterprise Security Architecture using IBM Tivoli Security
Solutions, SG24-6014, introduces the Method for Architecting Secure Solutions
(MASS) as a methodology for developing a design for a security implementation.
Thus, to prepare an Identity Management Architecture and Design document, we
can:
Rely on past experience, existing intellectual capital, and a generic design
approach where we map customer environment and requirements to product
functionality
OR
Use a methodology, such as MASS
OR
Combine the approaches
However MASS is also very strong in preparing the high-level Security
Architecture. This is shown in Figure 2-3 on page 46.
45
Security
Architecture
Project
Security
Architecture
document
MASS
Need for an
Identity
Management
Product
Enterprise
Architecture
Project
IT
Architecture
document
RFP or other
requirement
specification
document
Product
selection and
purchase
Product-centric
Implementation
Project
Experience
& ICAP
Product-centric
Architecture and
Design document
Figure 2-3 Methodologies and projects
MASS is particularly strong on the high-level security architecture and where

there are multiple security functions covered by a solution. However, the MASS
components do not map exactly to the Tivoli security products. In particular, the
MASS Identity and Credential Management subsystem does not map well to a
pure Tivoli Identity Manager deployment, but may map to an integrated Identity
Manager and Access Manager deployment.
The following sections are extracts from the redbook Enterprise Security
Architecture using IBM Tivoli Security Solutions, SG24-6014, that apply to an
Identity Management solution design.
46
2.2.1 MASS and Identity Management

This section summarizes MASS and how it maps to Identity Management.
MASS subsystems
For this project, Common Criteria were considered to be the description of the
complete function of the security system model. The classes and families within
the Common Criteria represent an aggregation of requirements; however, after
careful review, it was determined that the class and family structures defined
within Common Criteria do not lend themselves to be used as part of a taxonomy
for pervasive security. The aggregation is more reflective of abstract security
themes, such as cryptographic operations and data protection, rather than
security in the context of IT operational function. To suit the objective of this
project, the Common Criteria functional criteria were re-examined and
reaggregated, removing the class and family structures. An analysis of the 130
component-level requirements in relation to their function within an NIS solution
suggests a partitioning into five operational categories:
Audit
Access control
Flow control
Identity and credentials
Solution integrity
A summary mapping of CC classes to functional categories is provided in
Table 2-1.
Table 2-1 Placing Common Criteria classes in functional categories
Functional category
Common Criteria functional class
Audit
Audit, component protection, and resource

utilization
Access control
Data protection, component protection, security

management, component access,
cryptographic support, identification and
authentication, communication, and trusted
path/channel
Flow control
Communication, cryptographic support, data

protection, component protection, trusted
path/channel, and privacy
47
Functional category
Common Criteria functional class
Identity/credentials
Cryptographic support, data protection,

component protection, identification and
authentication, component access, security
management, and trusted path/channel
Solution integrity
Cryptographic support, data protection,

component protection, resource utilization, and
security management
While redundancy is apparent at the class level, there is only a small overlap at
the family level of the hierarchy defined within Common Criteria and below. Much
of the overlap represents the intersection of function and interdependency
among the categories.
The component-level guidance of Common Criteria documents rules, decision
criteria, functions, actions, and mechanisms. This structure supports the
assertion that the five categories described in Table 2-1 on page 47 represent a
set of interrelated processes, or subsystems, for security. The notion of a security
subsystem has been proposed previously; the authors of Trust in Cyberspace
described functions within operating system access control components as
belonging to a decision subsystem or an enforcement subsystem. The five
interrelated security subsystems proposed here and depicted in Figure 2-4 on
page 49 expand the operating system-based concept and suggest that function
and interdependency of security-related functions, beyond centralized access
control, can be modeled as well.
48
Figure 2-4 MASS subsystems
In this redbook, we are primarily concerned with the Manage Identities and
Credentials section of MASS. This is detailed in the following section.
MASS Identity and Credential Management

The purpose of a credential subsystem in an IT solution is to generate, distribute,
and manage the data objects that convey identity and permissions across
networks and among the platforms, the processes, and the security subsystems
within a computing solution. In some applications, credential systems may be
required to adhere to legal criteria for creation and maintenance of trusted
identity used within legally binding transactions.
A credential subsystem may rely on other subsystems in order to manage the
distribution, integrity, and accuracy of credentials. A credential subsystem has,
potentially, a more direct link to operational business activities than the other
security subsystems, owing to the fact that enrollment and user support are
integral parts of the control processes it contains. From Common Criteria, a
credential subsystem may include the following functional requirements:
Single-use vs. multiple-use mechanisms, either cryptographic or
non-cryptographic
Generation and verification of secrets
49
Identities and credentials to be used to protect security flows or business

process flows
Identities and credentials to be used in protection of assets: integrity or
non-observability
Identities and credentials to be used in access control: identification,
authentication, and access control for the purpose of user-subject binding
Credentials to be used for purposes of identity in legally binding transactions
Timing and duration of identification and authentication
Life cycle of credentials
Anonymity and pseudonymity mechanisms
The closed loop process for a credential subsystem is represented in Figure 2-5
on page 51.
50
Figure 2-5 Identity and Credential Management subsystem
As you will see as you go through the Tivoli Identity Manager architecture and
design sections of this book, not all of the components of the MASS Identity and
Credential Management subsystem are covered by Identity Manager. When
using MASS, you have to be aware of what the method proscribes and what the
products provide. In some cases, you can ignore the discrepancy as it may not
apply. When the method proscribes a function that the implementation requires,
you may have to add additional products or develop custom functionality.
51
2.2.2 Developing security architectures using MASS

Chapter 2, Method for Architecting Secure Solutions, of Enterprise Security
Architecture using IBM Tivoli Security Solutions, SG24-6014, provides a detailed
example of developing a security architecture following the MASS methodology.
The steps defined by MASS for the security architecture development are:
1. Model business processes.
2. Establish security design objectives.
3. Select and enumerate subsystems.
4. Document conceptual security architecture.
These are discussed in the following sections.
Model business processes

In this step, you model the business processes to which the security architecture
must be applied. Note that these processes may not be the business processes
of the Identity Management solution (as discussed in 2.3, Business processes
and Identity Management on page 58).
Establish security design objectives

Define the design objectives for the security architecture, considering the
business processes. For example, the design objectives for an Identity
Management solution may include:
There is a need for passwords to be managed by both users and
administrators.
There is a need for roles to be managed centrally and cover all applications,
systems, and databases each role requires.
There is a need for all account logins for a user to be consistent across all
applications, systems, and database.
These design objectives will flow from the detailed requirements.
Select and enumerate subsystems

In this step, the design objectives are mapped to the MASS subsystems. For an
Identity Management solution, most design objectives will map to the Identity and
Credentials Management subsystem. For an extended solution (such as Identity
Manager and Access Manager), many of the subsystems may be involved. The
mapping includes identifying where a subsystem is required or is supplementary.
52
There may need to be multiple instances of each subsystem within a design. For
example, there may need to be independent Identity Management subsystems
for external (Internet) customers and employees. Or there may need to be
separate Identity Management subsystems for separately managed businesses.
Actual subsystem enumeration requires documented rationale.
Document conceptual security architecture

With the design objectives agreed and mapped to the subsystems, a conceptual
model for security within the IT solution can be created. The example in the
redbook Enterprise Security Architecture with IBM Tivoli Security Solutions,
SG24-6014 shows the conceptual model as a series of diagrams, with each
showing the system environment for a particular design objective and the
security subsystem components mapped to it. Other representations are
possible.
From the perspective of the enterprise deploying the solution, the security design
objectives will dictate where security functionality is desired; however, the
compliance to some or all of the security requirements may be limited by the
enforceability of policies beyond the boundaries of the enterprise. Whether and
how these credential subsystems and access control subsystems can be
integrated into the security architecture can have a major impact on the
trustworthiness of the solution as a whole. These issues and dependencies
should be considered and documented within architectural decisions.
This type of conceptual model forms the baseline for developing and evaluating a
"proof-of-concept" and further refinement of the functional aspects of security
within the target environment.
Summary
The design flow and work/items or deliverables for these steps are shown in
Figure 2-6 on page 54.
53
Design
Flow
Model
Business
Processes
Establish
Security
Design
Objectives
Select and
Enumerate
Subsystems
Document
Conceptual
Security
Architecture
Work Items/
Deliverables
Business
Process
Definitions
SDO SDOSDO
Mapping
Conceptual
Security
Architecture
MASS
Subsystems
Subsystem
Subsystem
Subsystem
Subsystem
Subsystem
Figure 2-6 Security architecture development using MASS
Once the conceptual model has been developed, it must be integrated into the
overall solution architecture.
2.2.3 Integration into the overall solution architecture

There are several steps involved in translating the conceptual security subsystem
functions into component-level specifications and integration guidance. These
include creating models of the solution environment, documenting architectural
decisions, developing use cases, refining the functional design, and integrating
security requirements into component architectures.
The following sections are extracts from the redbook Enterprise Security
Architecture using IBM Tivoli Security Solutions, SG24-6014.
Solution models
Creating an initial solution model is a critical step in the design process. With skill
and experience, one-of-a-kind solution models can be developed to fit a given set
of requirements. For complex solutions, the practice of using templates derived
from prior solutions is becoming commonplace.
54
The Enterprise Solutions Structure (ESS) provides a range of reference

architectures1 for e-business solutions.
Documenting architectural decisions

Previously, the notion of the duality of security design was described, that is,
ensuring correct and reliable operation and protecting against error and
maliciousness. Both motivations are based upon managing the business risks of
the solution and of the environment. Risks represent the likelihood that an
undesirable outcome will be realized from a malicious attack, unexpected event,
operational error, and so on. Risks are either accepted as a cost of operation,
transferred to some other party, covered by liability insurance, or mitigated by the
security architecture.
Architectural decisions will dictate how robust the security system architecture
should be, which security subsystems to incorporate into the system
architecture, which functions and mechanisms within each subsystem should be
deployed, where the mechanisms will be deployed, and how the deployment will
be managed.
Examples of architectural decisions include:
Viability of the countermeasures, including the threats addressed, the
limitations and caveats of the solution, and the resulting window of risk
Extensibility of the design, including whether or not the design will serve the
total population and if there will be separate designs for defined population
segments
Usability of the design, including whether or not the mechanisms integrate
with the technology base and the extent of the burden of compliance for users
Manageability of the design, including the extent of the burden of life-cycle
management
Use cases
Architectural decisions will also drive the evaluation of prototypes and models of
functions within the solution. One form of prototype is called a use case. Both
security threats and normal interactions and flows can be validated with use
cases.
There are many architectural decisions to be evaluated within each iteration of
the design. The effect on performance due to processing delays, plus the effect
of data collection and analysis on the overall operation of the solution, are
significant factors.
P. T. L. Lloyd and G. M. Galambos, Technical Reference Architectures, IBM Systems Journal 38, No. 1, 5175 (1999).
55
Refining the functional design

Walkthroughs of complete business processes, including exception conditions
and handling processes, assist in creating a viable solution outline and refining
requirements and interdependencies among the solution building blocks.
Integrating requirements into component architectures

The security functions within the design need to be apportioned throughout the
solution. However, many of the mechanisms and services within the IT solution
that implement security functionality operate within other than security
components, for example, database systems, application systems, clients,
servers, and operating systems.
The task of adopting security functions into the network, application, middleware,
security, systems management, and infrastructure architectures is shared by the
several architects and integration specialists involved in the design project. The
process involves a structured approach, considering the purposeful allocation of
functions and requirements throughout the component architectures by:
Mandate, based upon a legal or contractual compliance requirement
Best practice for security, or for balance of security and business process
Component capability, knowing the existence of a mechanism that supports
the required process or action
Location in the configuration, based upon interaction with components or
flows
Impact, considering the risk, security objective, or the component capacity to
perform
Necessity, because there may be no better alternative
Summary of the design process

This section has described the process for translating the conceptualized
security solution into a set of detailed specifications, for an integrated IT security
control system, using the security subsystem construct. The design is
documented, refined, and validated against the business processes through use
cases and scenarios. The detailed security requirements, expressed in terms of
Common Criteria component-level detail, are distributed throughout the
operational model for the IT solution. At this point, integration-level detail can be
finalized, and the implementation plan can proceed.
The entire solution architecture process is shown in Figure 2-7 on page 57. It
includes the security subsystem architecture development diagram (Figure 2-6
on page 54).
56
Design
Flow
Model
Business
Processes
Establish
Security
Design
Objectives
Select and
Enumerate
Subsystems
Document
Conceptual
Security
Architecture
Work Items/
Deliverables
Business
Process
Definitions
SDO SDOSDO
Mapping
Conceptual
Security
Architecture
MASS
Subsystems
Develop Security
Subsystem Architecture
Design Flow
Work Items/Deliverables
Develop
Solution
Model
Document
Architecture
Decisions
Define
Use
Cases
Initial
Solution
Model
Architecture
Decisions
Use
Cases
Refine
Functional
Design
Integrate
requirements
into component
architectures
Working
Functional
Models
Component
Architectures
(Architecture and
Design document)
Other Rqmts/
Design
Considerations
Figure 2-7 Developing an overall solution architecture
57
The security architecture design and the overall architecture design sections
both discussed business processes and how they are integrated into the design.
The next section discusses business processes in an Identity Management
solution.
2.3 Business processes and Identity Management

The Identity Management solution will comprise both business (or procedural)
and technical (security subsystem-specific) functionality. An implementation will
not just involve installing an Identity Management tool; there will be integration
with existing business procedures and perhaps some business process
re-engineering (BPR). Both technical (product-related) and business
(process-related) skills will be required in the definition and design phases.
To produce an effective Identity Management solution, the architect must
understand all identity processes involved in detail. Let us look at an example.
A new employee starts working for a company. How does their identity
information get created? Is there an HR database involved? How is that
connected to their salary and benefits? How does HR tie in with the IT
department? How does that person get access to the applications they need to
do their job?
The list of processes can include:
A person joining a company and being defined to the HR system

A person getting accounts to access applications
A person getting passwords to use the accounts
A person changing departments with bulk account changes
A person changing a role with subtle account changes
A person changing a surname and impacting accounts
A person changing passwords
A person resigning and being marched out, requiring locking of accounts
A person resigning but their account need to be accessed by others
A password being reset by an administrator
A locked account being unlocked
An account being locked
All accounts for a user being deleted
A set of accounts being moved from one system to another
An access control group being changed and impacting a number of users
This list is not exhaustive, but indicates the business process review exercise
that should be performed as part of the Project Definition phase.
58
Implementing an Identity Management solution may involve designing a solution

that complements the existing business processes or it may involve significant
business process re-engineering. The project requirements will indicate the level
of business process re-engineering.
Adoption of any re-engineered processes must involve analysis of the impact of
the solution on:
The system owners. For an Identity Management solution, this will be the
company executive (for example, the owners of the security policy) and the IT
Security department.
The system administrators. For an Identity Management solution, this will be
the security administrators, help desk staff, and technical support.
The system users. For an Identity Management solution, this will be everyone
defined as IT users in an organization.
Any changes to processes could potentially impact every person in a company.
These changes may drive the implementation of an Identity Management system
(for example reducing password-reset help desk calls by allowing users to
change their own passwords). If there are to be changes to the processes, the
architect and project team need to be cognizant of:
Usability: Users of various skill levels may be using the solution, so the
usability of the components must be appropriate to all levels of users.
Documentation: Process changes impacting a large number of users will
require greater documentation support than a change impacting a small
team. This may include procedure documents, intranet pages, and online
help.
Education: As with documentation, if you are deploying significant changes to
a large number of people, thought must be given to the education plan.
We are not going to discuss the business process re-engineering methodologies
in this redbook. There are many books and Web sites that contain such
information. The following Redbooks may be of interest:
Intra-Enterprise Business Process Management, SG24-6173
Business Process Reengineering and Beyond, SG24-2590
2.4 Conclusions
This chapter has examined the issues and circumstances that affect the design
of an Identity Management solution. It has outlined a system model and a
systematic process for security design with the Common Criteria international
standard at its foundation.
59
A key component of the Identity Management design is the understanding, and

possible re-engineering, of the business processes associated with Identity
Management.
The remainder of this book will present the architecture and design
considerations for Tivoli Identity Manager and will build on the concepts
presented in this chapter.
60
Chapter 3.
Identity Manager component

structure
Through the acquisition of Access360, IBM Tivoli has strengthened its identity
provisioning positioning and have gone to the market with the product offering of
IBM Tivoli Identity Manager Version 4.4.
Given that IBM Tivoli Identity Managers different architecture and non-reliance
upon Tivolis Management Framework, User Administration, and Security
Manager products, this chapter introduces the high level components and new
concepts for the design of an identity management solution.
This chapter provides you with an understanding of the following topics:
The high level logical component architecture for IBM Tivoli Identity Manager
The various internal modules and sub-processes of IBM Tivoli Identity
Manager
The high level physical architecture of IBM Tivoli Identity Manager
61
3.1 Logical component architecture

The logical component design of IBM Tivoli Identity Manager may be separated
into three layers of responsibility, which are depicted in the center of Figure 3-1.
They are:
The Web User Interface Layer
The Application Layer
The Service Layer
End User
B ro w s e r
A d m in is t r a t o r
B ro w s e r
S u p e r v is o r
B ro w s e r
U s e r /A d m in is t r a t o r r e q u e s t s /re s p o n s e s
E n tit y p u ts /
g e ts
W e b U s e r In t e r f a c e
LDAP
T r a n s a c tio n a l
in fo , s c h e d u le
r e a d s /w r it e s
A p p lic a t io n
D a ta b a s e
S e rv ic e
A c c o u n t p r o v is io n in g /r e c o n c ilia tio n
Agent
Agent
Agent
O p e r a tin g
S ys te m
RDBMS
A p p lic a t io n
Figure 3-1 IBM Tivoli Identity Manager logical architecture
The following sections cover each individual layer in more detail.
62
3.1.1 Web User Interface Layer

The Web User Interface module is a set of combined sub-processes that provide
the content to a users browser and initiating applets (both run on the client and
the server), such as the Workflow Design and the Form Creation. The Web User
interface is the interconnecting layer between that of the users browser and the
identity management application layer.
In Figure 3-1 on page 62, there are three types of user interaction points: the
end-user, supervisor, and administrator. These types are merely conceptual, as
IBM Tivoli Identity Manager allows the customer to define as many different types
of users with different permissions as they would like.
However, for this diagram, it is important to note that the system is built with a
general concept of the capabilities of the system users. For example, it is
assumed that the administrator needs advanced capabilities and requires a more
advanced user interface, possibly requiring a thicker client (applet). It is assumed
that the supervisor needs slightly less advanced capabilities but may still require
concepts like an organizational chart. Since the number of supervisors in an
enterprise may be great, a thick client is not practical. Lastly, there are no
assumptions made for the end user. The interface presented to the end user
must be a thin client with very basic and intuitive capabilities.
The Web User Interface subsystem contains all modules necessary to provide a
Web-based front end to the applications of the Applications subsystem. Below is
a brief description of each module shown in Figure 3-2.
Web User Interface

Form
Rendering
Search
Form Design
Organization
Tree
Desktop
Workflow
Design
Application
Interface
Interface
Menu System
Figure 3-2 Web User Interface module sub-processes
Menu System module

The Menu System module provides a consistent menu and short-cut
mechanisms that are used for navigation throughout the user interface.
Chapter 3. Identity Manager component structure
63
Organization Tree module

The Organization Tree module provides the graphical tree representation of the
organizational structure in which entities managed through the user interface are
logically stored.
Form Rendering module

The Form Rendering module provides the run-time interpreter to display the
customized forms designed in the Form Design module.
Desktop module
The Desktop module provides a framework for providing a consistent layout in
the pages displayed in the user interface. It is within this framework that products
of the other Web User Interface modules are displayed, such as the Menu
System and Organization Tree.
Search module
The Search module provides a framework for general and more specific search
interfaces to be used throughout the user interface.
Workflow Design module

The Workflow Design module provides a graphical workflow design environment.
A workflow process consists of a set of activities that are executed in an ordered
fashion according to conditional transitions. The designer provides a graphical
way of defining such a workflow process. This module makes use of applets for
its more flexible demands.
Form Design module

The Form Design module provides a near WYSIWYG (What You See Is What
You Get) user interface design environment for customizing the forms that
display information about the entities managed through the user interface. This
module makes use of applets for its more flexible demands.
3.1.2 Application Layer

The core of the IBM Tivoli Identity Manager system is the Application Layer.
Residing on an application server, the application layer provides the
management functionality of all other process objects.
The Application subsystem contains all modules that provide provisioning
specific capabilities, such as identity management, account management, and
policy management. Each application makes use of the core services in the
Services layer to achieve its goals. It is the Applications module that provides the
64
external interface to the provisioning platform. Below is a brief description of

each module, as well as a graphical overview, as shown in Figure 3-3.
Workflow
Management
Policy
Management
Identity
Management
System
Configuration
Entity
Management
Worklist
Management
Account
Management
Password
Management
Reporting
Data Join
Management
Platform
Applications
Figure 3-3 Applications module sub processes
Workflow Management module

The Workflow Management module provides the capabilities required to manage
workflow processes, such as their addition, modification, and removal. The ability
to view the status and details of active and historical processes is also provided
in this module.
Worklist Management module

The Worklist Management module provides the capabilities required to manage
an individuals workflow driven worklist, or assignments. This includes the
approval/disapproval of a request or the fulfillment of a Request For Information
(RFI).
Policy Management module

The Policy Management module provides the capabilities to manage the policies
in the system, including provisioning, password, service selection, and identity
policies.
Account Management module

The Account Management module provides the capabilities required to manage
accounts, such as their addition, removal, suspension, reinstatement, and
modification.
Identity Management module

The Identity Management module provides the capabilities required to manage
identities, such as their addition, removal, suspension, reinstatement, transferal,
and modification, including the changing of roles. The definition of roles,
including dynamic roles, is also included in this module.
65
Password Management module

The Password Management module provides the capabilities required to change
or synchronize passwords according to a defined set of password policies or
rules.
System Configuration module

The System Configuration module provides the capabilities required to manage
the IBM Tivoli Identity Manager system itself, such as defining behavioral
properties.
Reporting module
The Reporting module provides the canned report capabilities of the system.
This module provides the query and formatting of the reports driven from the
user interface.
Entity Management module

The Entity Management module provides the capabilities required to manage the
types of entities managed by the system, such as types of identities and
accounts. This includes the ability to define the schema for the entity type, the
operations the entity type can support, and the life cycle of the entity type.
Data Join Management module

The Data Join Management module provides the capabilities required to manage
the data join features of the system. This includes the creation, modification, and
deletion of data flows to be followed for joining data between changing identities
and accounts.
3.1.3 Service Layer

If the IBM Tivoli Identity Manager server is the application of complex rules that
have been developed, then the applications server is the engine that runs those
rules or objects. It is communicating not only to the user facing Web server, but
also to the agents residing on the managed services and to directories for
storage of information.
The Core Services subsystem contains all modules that provide general services
that can be used within the context of provisioning, such as authentication,
authorization, workflow, and policy enforcement. These services often make use
of other services to achieve their goals. A brief description of each module is
given below, as well as a graphical overview, as shown in Figure 3-4 on page 67.
66
Core Services
Authentication
Messaging
Policy
Remote
Services
Authorization
Scheduling
Workflow
Data Services
Workflow Database
Data Join
Customer
Datastore
Access Manager
Managed Services
Figure 3-4 Core Services module sub-processes
Authentication module
The Authentication module provides a set of authentication implementations that
can be used by clients of the service. Examples of these implementations are
simple password authentication and X.509 certificate authentication. The module
is designed as a framework that can be extended by customers to provide their
own implementations.
Authorization module
The Authorization module provides an interface to enforce authorization rules as
clients attempt operations in the system. These rules apply to accessing data
within the system, as well as to operations that can be applied to the system
data.
Mail module
The Mail module provides an interface for notifying users via a messaging
system, such as e-mail. The module is configurable to accommodate different
messaging systems.
Messaging module
The Messaging module provides guaranteed asynchronous messaging to and
between internal modules in the architecture. The module relies heavily on the
Java Message Service (JMS) specification to provide support for multiple
messaging middleware vendor implementations.
67
Scheduling module
The Scheduling module provides a timer that notifies clients of timed events that
they have subscribed for. The Scheduling module uses the Messaging module to
notify those clients.
Policy module
The Policy module enforces the policies that associate users with services. The
module ensures that provisioning requests conform to the policies that are
defined. The module resolves the appropriate policies that apply to a user and
determines the services for which that user is authorized. The module validates
and generates passwords. The module generates identities for users and
accounts.
Workflow module
The Workflow module executes and tracks transactions within the system. This
would include the provisioning/de-provisioning of a service, a user's status
change, the custom process associated with a provisioning request in the
system, or any other transaction that affects a user's, or group of users', access
to services. Each of these transactions is persistent for fault-tolerant execution
and historical auditing purposes. Clients can query the Workflow module for the
status of the transactions being executed.
Remote Services module

The Remote Services module provides the interaction with the external systems
for provisioning and de-provisioning services. The synchronization of service
information and user information is also performed within this module. The
module is designed as a framework that can be extended by customers to
provide their own implementations of provisioning and de-provisioning of
services. This allows the platform to easily support different protocols and APIs
that may be supported by the resources to be provisioned.
Data Services module

The Data Services module provides a logical view of the data in persistent
storage (LDAPv3 directory) in a manner that is independent of the type of data
source that holds the data. The model abstracts the details of the stored data into
more usable constructs, such as Users, Groups, and Services. The model also
provides an extendable interface to allow for customized attributes that
correspond to these constructs. Meta-Data information about the persistent data
can also be retrieved using this module.
68
Data Join module

The Data Join module provides the join engine capabilities of the platform,
including the distribution of changes between related identity and account
entities in the system. This module works at a lower level than the provisioning
logic, so it is not audited like other provisioning transactions. The join operations
are triggered as a result of the completed provisioning transactions.
3.1.4 LDAP Directory

The IBM Tivoli Identity Manager system uses an LDAPv3 directory server as its
primary repository for storing the current state of the enterprise it is managing.
This state information includes the identities, accounts, roles, organization chart,
policies, and workflow designs.
More details on the LDAP Directory and its schema is available in 4.6.5, LDAP
analysis on page 124.
3.1.5 Database
A relational database is used to store all transactional and schedule information.
Typically, this information is temporary for the currently executing transactions,
but there is also historical information that is stored indefinitely to provide an
audit trail of all transactions that the system has executed.
3.1.6 Resource connectivity

The back-end resources that are being provisioned by IBM Tivoli Identity
Manager are generally very diverse in their capabilities and interfaces. The IBM
Tivoli Identity Manager system itself provides an extensible framework for
adapting to these differences in order to communicate directly with the resource.
For a more distributed computing alternative, a built-in capability to communicate
with a remote agent is provided. The agents typically use an XML based
protocol, Directory Services Markup Language (DSML), as a communications
mechanism.
Note: Tivoli Identity Manager Version 4.4 currently uses a DSML-like protocol
called Directory Access Markup Language (DAML). It is Tivolis stated
intention that Version 4.5 of the product will support DSML.
Directory Services Markup Language connectivity

DSML provides a method for processing structured directory based information
as an XML document. DSML is a simple XML schema definition that enables
69
directories to publish profile information in the form of an XML document so that it

can be easily shared via IP protocols such as HTTP/S, as shown in Figure 3-5.
HTTP/S
Web Interface
DATA
Applications
DSML
Agent
DSML
File
IP
Network
DSML
File
Service
Core Services
Identity Manager
Server
Figure 3-5 DSML connectivity to a service
Transactions from the IBM Tivoli Identity Manager server are sent securely via
HTTPS to the service agent and then processed by the agent.
For example, if a service has just been connected to the IBM Tivoli Identity
Manager server, the accounts that already exist on the server may be reconciled
or pulled back in order to import the users details into the IBM Tivoli Identity
Manager LDAP directory. If a password change or a provisioning of a new user
occurs, the information is transferred to and then processed by the agent. The
agent deposits the new information within the application or operating system
that is managed.
IBM Directory Integrator connectivity

Due to the nature of support issues for every adaptor and the development costs
for new adaptors, it is becoming easier to use IBM Directory Integrator as the
data bus that transports information and data to the services. Using IBM Tivoli
Identity Managers JNDI API, it is possible to connect to just about any service,
application or endpoint, as shown in Figure 3-6 on page 71.
70
Identity Manager
Server
Service
Web Interface
DATA
JNDI
IDI
Connector
- CSV
- Parser
- Operating System
- LDAP
- Application
IP Network
Applications
Core Services
Data BUS
Figure 3-6 IBM Directory Integrator (IDI) service communication
By using IDI and IBM Tivoli Identity Manager, communications to resources such
as a CSV file or a Microsoft Excel spreadsheet containing contractor
employment details may be possible through a parser connector. Tivoli Identity
Manager would see this as a service that it manages and that can be
incorporated into its workflow.
3.2 Physical component architecture

An IBM Tivoli Identity Manager system is always deployed as part of an
enterprise environment. A goal of the physical component architecture is to be
flexible enough to support different configuration options. This section discusses
the different network zones that you find within an enterprise environment and
the placement options for the different Identity Manager components.
3.2.1 Component configuration and placement

It is possible to deploy Tivoli Identity Manager components within a single
network. While this kind of architecture may be reasonable for a lab or
development environment, it is generally not recommended for a production
setting.
71
We discuss how various Tivoli Identity Manager components relate to the

network configuration, and provide recommendations for how they should be
distributed in a typical architecture.
3.2.2 Network zones

We have to consider four types of network zones in our discussion of Tivoli
Identity Manager component placement:
Uncontrolled (the Internet)
Controlled (an Internet-facing DMZ)
Restricted (a production or management network)
Trusted (an intranet)
Since we will not place any components in an uncontrolled zone, we take a
closer look at the remaining three zones.
Internet DMZ (controlled zone)

The Internet DMZ is generally a controlled zone that contains components with
which clients may directly communicate. It provides a buffer between the
uncontrolled Internet and internal networks. Because this DMZ is typically
bounded by two firewalls, there is an opportunity to control traffic at multiple
levels:
Incoming traffic from the Internet to hosts in the DMZ
Outgoing traffic from hosts in the DMZ to the Internet
Incoming traffic from internal networks to hosts in the DMZ
Outgoing traffic from hosts in the DMZ to internal networks
As a typical Tivoli Identity Manager deployment would include integration with a
Tivoli Access Manager environment, we need to consider the placement of other
components such as WebSEAL, which could be used to protect access to the
HTTP server used by the Tivoli Identity Manager GUI server. The DMZ is an
appropriate location for the WebSEAL component of Tivoli Access Manager, and
in conjunction with the available network traffic controls provided by the bounding
firewalls, it provides the ability to deploy a highly secure Web presence without
directly exposing components that may be subject to attack by network clients.
Note: The latest information about IBM Tivoli Access Manager can be
obtained by reading the redbook Enterprise Business Portals with IBM Tivoli
Access Manager, SG24-6556 and Enterprise Business Portals II with IBM
Tivoli Access Manager, SG24-6885.
72
Production or management DMZ(s) (restricted zone)

One or more network zones may be designated as restricted, that is, they
support functions to which access must be strictly controlled, and of course,
direct access from an uncontrolled network should not be permitted. As with an
Internet DMZ, a restricted network is typically bounded by one or more firewalls
and incoming/outgoing traffic may be filtered as appropriate.
These zones typically would contain Tivoli Identity Manager server components
and Access Manager back-end servers that do not directly interact with users.
Intranet (trusted zone)

A trusted zone is one that is generally not heavily restricted in use, but an
appropriate span of control exists to assure that network traffic does not
compromise the operation of critical business functions. Corporate intranets may
be examples of such zones.
Depending on the specific level of trust existing in a trusted zone, it may be
appropriate to place certain Tivoli Identity Manager components within it.
Other networks
Keep in mind that the network examples we are using do not necessarily include
all possible situations. There are organizations that extensively segment
functions into various networks. Some do not consider the intranet a trusted zone
and treat it much like the Internet, placing a DMZ buffer between it and critical
systems infrastructure contained in other zones. However, in general, the
principles discussed here may be easily translated into appropriate architectures
for such environments.
Placement of various Tivoli Identity Manager components within network zones
is, on the one hand, a reflection of the security requirements in play, and on the
other, a choice based upon an existing/planned network infrastructure and levels
of trust among the computing components within the organization. While
requirement issues may often be complex, especially with regard to the specific
behavior of certain applications, determination of a Tivoli Identity Manager
architecture that appropriately places key components is generally not difficult.
With a bit of knowledge about the organizations network environment and its
security policies, reasonable component placements are usually easily
identifiable.
Figure 3-7 on page 74 summarizes the general Identity Manager component
type relationships to the network zones discussed above.
73
No Identity Manager
components should be
deployed in an uncontrolled
network. It is also generally
unsafe for Identity Manager
components to
communicate with one
another across an
uncontrolled network
without using secure
communication
mechanisms (such as SSL).
Possible location
for GUI servers
that service
external
customers.
The specific level of

trust in an internal
network dictates what
Identity Manager
components may be
deployed within them.
Organizations may set

up specialized
restricted zones for
production systems,
which could include
Identity Manager
component servers and
supporting
components, such as
DB2 LDAP and Web
servers.
Some organizations
set up special
networks to separate
various management
components from
production systems.
Some Identity
Manager componets,
such as the RMA
server, might be
installed in such a
network.
Uncontrolled
Zone
Controlled
Zone
Trusted
Zone
Restricted
Zone
Restricted
Zone
Internet
Internet DMZ
Intranet
Production
Network
Management
Network
LESS SECURE
MORE SECURE
Figure 3-7 Network zones for Identity Manager placement
As all the components of Tivoli Identity Manager have either information that
access should be restricted to, or support such resources, we recommend that
they all be placed in a restricted zone. An exception to this may be to place one
or more GUI servers in the DMZ to manage external requests from business
partners or customers if no general access control solution, such as Access
Manager WebSEAL, is in place.
3.2.3 Integrating with Access Manager

When integrating Tivoli Identity Manager with Access Manager, we have to
consider the placement of other components, such as the Access Manager
Policy Server and the WebSEAL server. WebSEAL would be used to protect the
Web server associated with the GUI server, as well as the other corporate Web
servers.
As depicted in Figure 3-8 on page 75, we recommend that WebSEAL servers
accessible via the Internet should be placed in a DMZ. WebSEAL in such a
setting should generally be in a network zone separate from those that contain
other Access Manager components upon which it relies, and from the Web
servers to which it is junctioned. In this case, it is not necessary to place the GUI
servers that service external users in the DMZ, as the WebSEAL server in the
74
DMZ acts as a proxy to the GUIs Web server, which should be placed in a
restricted zone. The Access Manager Policy Server may be placed in the trusted
zone if there is sufficient trust in those who can access that zone, and
communication is secure using SSL. However, in most cases, the most suitable
place for the Access Manager Policy Server would be in the restricted zone. The
Access Manager User registry should also be placed in the restricted zone.
No Access Manager
component should be
deployed in an uncontrolled
network. It is also generally
unsafe for Access Manager
components to
communicate with one
another across an
uncontrolled network
without using secure
communication
mechanisms (such as SSL).
Usually, only
WebSEAL or other
Access Manager
blades should be
placed in a
controlled network
zone.
The specific level of

trust in an internal
network dictates what
Access Manager
components may be
deployed within them.
Organizations may set

up specialized
restricted zones for
production systems,
which could include
Web and application
servers, and various
Access Manager
components, such as
the User Registry or
internally used
WebSEALs.
Some organizations
set up special
networks to separate
various management
components from
production systems.
The Access Manager
Policy Server might be
installed in such a
network.
Uncontrolled
Zone
Controlled
Zone
Trusted
Zone
Restricted
Zone
Restricted
Zone
Internet
Internet DMZ
Intranet
Production
Network
Management
Network
LESS SECURE
MORE SECURE
Figure 3-8 Network zones for Access Manager placement
Figure 3-9 on page 76 shows an example architecture for integrating Identity

Manager and Access Manager. Note that firewalls are introduced to separate the
networks and permit access only through specified ports. In this example, access
from the Internet is only allowed on the ports 80 and 443 to the WebSEAL server
in the DMZ, and the WebSEAL server is configured to access the back-end Web
servers through alternative ports, hence forcing all users requesting access to
the back-end Web servers to be authenticated by WebSEAL.
75
80/443
80/443
81/1443
81/1443
Port Access
Configuration
Port Open
Port Closed
Applications
Portal
Application
server
Mainframe
Firewall
Firewall
Firewall
IBM HTTP
server
Web server
Data
Web server
ITIM server
Browser
LDAP
Replica
Access
Manager
WebSEAL
LDAP
Replica
LDAP
Master
Production Network
Management Network
Web
server
Internet
ITIM server
Access
Manager
Policy
server
Internet DMZ
Figure 3-9 Integrated architecture for Access Manager and Identity Manager
Note: Port 80 is the default port for HTTP, and port 443 for HTTPS, through
which the browser connects to the Identity Manager GUI server.
If LDAP is being used for the user repository, the firewall could be configured to
allow access to the registry only via the WebSEAL server.
76
Chapter 4.
Detailed component design

This chapter looks at the design considerations and options for the main
configurable components. The target of this chapter is to give you the building
blocks for a detailed Identity Manager design.
The structure of the chapter is consistent with Chapter 3, Identity Manager
component structure on page 61 and covers:
IBM Tivoli Identity Manager Entities
IBM Tivoli Identity Manager Functions
IBM Tivoli Identity Manager User Interface and Access Control
IBM Tivoli Identity Manager Schedules
Detailed IBM Tivoli Identity Manager Component Analysis
Detailed DSML Connectivity
IBM Directory Integrator Introduction
In each section of this chapter, we try to take a consistent approach of breaking
each component into bite-sized chunks and then, for each chunk, looking at the
technical aspects of it (how does it work) before examining any design
considerations (how can I make it do what I need for this deployment). We
close each section with a summary that brings all the bite-sized chunks back
together from a design perspective.
77
4.1 IBM Tivoli Identity Manager entities

Identity Manager is concerned with managing users and their accounts.
Passwords, group memberships, and other attributes are associated with the
users and accounts. These all relate to managed systems and applications. To
enable management of users, accounts, and associated information, Identity
Manager uses an organizational tree and roles, Identity Manager roles and
ACLs, and policies. Identity Manager also contains workflow, audit logs, and
reports. These are described in the following sections.
The entities managed by Identity Manager are:
Users, accounts and attributes
Passwords
Group memberships
Managed systems and applications
4.1.1 Users, accounts, and attributes

A person can be classified as a Person, a Business Partner Person (BPPerson),
or custom Person. A Person is typically an employee of the company or
organization. A BPPerson is typically an individual who needs access to an
organization's Identity Manager system but who is not considered an employee.
All classes of users are managed in the same way. However, more information is
required when adding a Person than when adding a BPPerson. A custom Person
is used when the standard Person definition does not suit an organization and
has to be extended for the organization.
A person can be located anywhere in the Organization Tree, so the Organization
Tree represents the user structure of a company.
The personal information is defined as attributes on the person objects. This may
include first, last, and full names, phone numbers, employee number, supervisor,
and e-mail address.
The person corresponds to the iNetOrgPerson object and attributes (as
implemented by Netscape/iPlanet) and not the ePerson object (although the
object classes are similar).
An account is a person's access to Identity Manager or to a Service (managed
resource), such as NT, Solaris, SAP, and so on. Accounts have attributes that
are defined by the managed resource.
78
An Orphan account is an account that is not associated with a person. Orphan

accounts are generated when the reconciliation process cannot automatically
associate the account with a person.
4.1.2 Passwords
All accounts have passwords. Account passwords can be centrally managed by
their owners or administrators using the Identity Manager Web interface.
Passwords can be synchronized. The synchronization can be applied to all
accounts associated with a user or selected accounts. For most passwords, this
is a one-way synchronization. Identity Manager sets the password and pushes it
to the managed targets. Identity Manager cannot accept a password change
request from a target and push this to all associated accounts. The exception to
this is the Windows NT/2000 password synchronization function, which
intercepts a password change and passes it through Identity Manager. It is
Tivolis stated intention to extend this functionality to other platforms in the future.
Identity Manager can generate a random password. This can be displayed to an
administrator or mailed to a user.
Identity Manager uses a challenge/response function to verify a users identity if
they have forgotten their Identity Manager password. The challenge questions
can be from a standard list or enterable by the user. When a user logs into
Identity Manager for the first time, they enter the challenge questions (if
configured) and responses. On subsequent logins to Identity Manager, they can
select a "forgot password" option and a subset of the challenge responses are
used to verify the user.
4.1.3 Group membership

Accounts are given access on target systems and applications via some form of
group. These may be groups on UNIX systems or Windows domains, SAP
groups or profiles, or another access control grouping mechanism. Membership
is by a group attribute on accounts.
Group lists, for most managed targets, are updated with the reconciliation
function. Thus, administrators do not manually enter group names; they select
from a list that is in synch with the target.
Note that Identity Manager does not create or delete groups on managed targets.
Nor does it manage ACLs or resource access on the managed targets. This must
be performed by the local administrators or application owners using the native
system or application tools.
Chapter 4. Detailed component design
79
4.1.4 Managed systems and applications

Identity Manager manages users on many managed systems. These include
operating systems, such as many flavors of UNIX and Windows servers, and
applications, such as databases and business applications.
Identity Manager deploys an agent to perform the administration of accounts on
the system or application. Some agents are deployed to the system or
application and interact locally. Others can operate remotely and be deployed
anywhere in the network.
Agent to server communication normally uses HTTPS, but some older agents
use FTP. For example, the RACF agent communication can be secured using
secure FTP or using Securelink.
Each agent instance is defined as a service within the Identity Manager server.
Accounts are associated with specific services. For example, there is a service
for every HPUX server. The services are defined within the organization tree and
can have ACLs attached to control administrative access to functions performed
against the service. A service can only be defined for a pre-existing managed
target.
There is a service profile for every type of service. For example, there is one
service profile for HPUX services. The service profile defines the account
attributes for that type of service.
4.2 Identity Manager management entities

Identity Manager uses the following entities for management:
Organizational tree and roles
Identity Manager roles and ACLs
Policy
Workflow
Audit logs
Reports
These are discussed in the following sections.
80
4.2.1 Organizational tree and roles

Central to Identity Manager is the organization tree (or org tree). It defines the
structure for the organization that Identity Manager is being deployed into. The
tree consists of:
An organization: There is normally only one organization at the top of the org
tree.
One or more locations: These are locations defined by the business.
One or more organizational units: These are teams or departments as defined
by the business.
One or more business partner organizations: These are business partners as
defined by the business.
One or more admin domains: These are Identity Manager groupings for
administration.
The Tivoli Austin Airlines organization consists of a number of Region Based
Customer Service Locations (such as Center Region and East Region), Head
Office, Business Partners, and a AD_Corp admin domain. Each of these contain
further Sub Region organizational units, such as the Denver and Raleigh
Customer Service Locations, as depicted in Figure 4-1.
Figure 4-1 Identity Manager organization tree of Tivoli Austin Airlines
81
There is no technical difference between locations, organizational units, or

business partner organizations. They use different icons and allow the org tree to
be modelled as the administrators wish.
All people are attached to the org tree at a single point.
A policy is attached to points in the org tree and can apply to objects at that level
or to all objects at or below that level. This policy can control the provisioning of
accounts, account user ID generation and password strength. Thus, you could
have a corporate-wide password policy defined at the organization level in the
org tree and a specific password policy that applies to a specific branch or
department of the organization.
Identity Manager roles and ACLs are also attached to points in the org tree,
defining the scope of specific access rights within the Identity Manager product.
Organizational roles are used to model job roles within an organization. They can
be used to map users to a set of accounts that are granted through a
provisioning policy.
4.2.2 Identity Manager roles and ACLs

A user's access within Identity Manager, for example, the functions they can
perform in Identity Manager, is governed by the roles they belong to. These roles
are called Identity Manager groups.
Identity Manager governs user access rights using Access Control Information
(ACI). An ACI controls user access by defining the access privileges of an
Identity Manager group or ACI principal. Members of an Identity Manager group
or ACI principal can view and perform operations on attributes within a target
class (context) as defined by the scope of the ACI.
Note: Only Identity Manager groups can be assigned to an ACI.

Organizational roles cannot be assigned to an ACI. ACIs grant or deny the
ability to perform Identity Manager functions. Managers can provision and
manage a Person in their organizational unit based on their level of access.
This role-based access is for Identity Manager users assigned to the Identity
Manager groups. Identity Manager system administrators are not controlled by
ACIs because the administrator account, by default, has access to all functions in
the system. All other users, by default, do not have access to any functions or
features in the system.
82
4.2.3 Policy
Identity Manager supports four types of policy: provisioning policy, password
policy, identity policy, and service selection policy.
Provisioning policy
A provisioning policy confers access to many types of managed services
(Identity Manager, NT, Solaris, and so on) by granting a person access based on
an organization (for example, a person's location in the org tree, an
organizational role, or all people not in any organizational role). In other words,
access to a target managed service is either:
Granted to all persons in an organization
Granted only to persons assigned to a specified organizational role
Granted to persons not covered by any other provisioning policies on any of
the entitlement targets associated with the current policy
It is used to define what accounts can be created for a user and can, optionally
and automatically, create the accounts on those systems. It can also be used to
define a specific approval workflow process that has to be applied to the
accounts.
Service selection policy

A service selection policy extends the ability of the provisioning policies by
providing the ability to provision accounts based on personal attributes. In order
for a service selection policy to be enforced, a provisioning policy must target it.
The service selection policy then identifies the service type to target and defines
provisioning based on a JavaScript.
Identity policy
An identity policy defines how a user's ID is created. Identity Manager
automatically generates user IDs from the identity policy. Identity policies can be
set as a global policy or as a service specific policy. If the identity policy is not a
global policy, the policy can be assigned on a per service basis (for example, it
only applies to specific service types) or it can be assigned to a combination of
service types and/or instances. For example, if all user IDs must be composed of
the user's first initial and last name, a global identity policy must be created for
the organization. If all user IDs for a specific service must contain a certain
number, a service specific identity policy must be created for the service.
83
Password policy
A password policy sets parameters that all passwords must meet, such as
length, type of characters allowed and disallowed, and so on. You can set up
password policies to apply to any of the following:
Only one service instance or more than one service instances
All service instances of only one service type or multiple service types
All services, regardless of service type
4.2.4 Workflow
A workflow is the process by which a request is approved, rejected, or sent for
completion. The workflow process is defined by a workflow design. When a user
places a request for a new account, new access rights, or changes to an existing
account, the request must be approved by signature authorities defined by a
workflow design.
A workflow design can be added to an entitlement in a provisioning policy when
the entitlement is defined or at a later time.
Workflow designs are built using the Identity Manager GUI. The design created
by the visual programming Java applet in the GUI actually produces an XML
implementation under the covers.
4.2.5 Audit logs

Identity Manager has logging features that log the events during specific
transactions. This facilitates isolating and debugging of problems. There are
several types of logging available:
Installation log
Audit trail in the Web user interface
Identity Manager server log
Web server access log
Directory server log
The audit log for any activity can be viewed using the Identity Manager Web user
interface. Reports can also be run against the audit logs.
84
4.2.6 Reports
An authorized user can use the Identity Manager report system to create reports
based on the criteria you select. Identity Manager allows authorized users to
generate six different types of reports:
Operation: Lists Identity Manager operation requests by type of operation,
date, who requested the operation, and who the operation is requested for.
Service: Lists existing service instances by date, who requested the
operation, and who the operation is requested for.
User: Lists all Identity Manager operations by date, who requested the
operation, and who the operation is requested for.
Rejected: Lists requests denied by date, who requested the operation, and
who the operation is requested for.
Reconciliation: Lists the orphan accounts found since the last reconciliation
was performed.
Dormant: Lists services with no activity within the number of days selected.
Account: Lists people and their associated accounts and whether or not the
account is in compliance with current policies.
Identity Manager system administrators can also link other reports to the reports
menu. Access to any of the reports is defined by the report ACIs.
4.2.7 Entity relationships

As a summary, the key Identity Manager entities and their relationships are
shown in Figure 4-2 on page 86.
85
Organization
People w ho are governed by
ITIM policies
IBM Tivoli Identity M anager

Provisioning P olicy
O perating
System s
Defines level of access to one or m ore

S ervice (m anaged resources) for group
of users
O rganization
Roles
Service
P eople w ho are ITIM Users

and System Adm inistrators
Databases
Application s
IT IM System
Administrators
System Manag em ent

Au thority
Domain
Administrators
Access Control Information
P eople w ho are ITIM Users

and Dom ain Administrators
ITIM
G roups
People w ho are ITIM

Users
Figure 4-2 IBM Tivoli Identity Manager entities and their relationships
On the left of the figure is the organization (and subsidiary entities) with the
different types of people using Identity Manager, such as those that are governed
by policies, ordinary users, domain administrators, and system administrators.
Within the Identity Manager system are the entities described in the earlier
sections, such as the policies, organizational roles, and ACIs. Services map to
managed resources, such as operating systems, databases, and applications.
86
4.3 IBM Tivoli Identity Manager functions

The key Identity Manager functions are:
User self-service
Manage users and accounts
Apply policy to user and account management
Reconcile accounts
Apply approval workflow
Produce reports
All Identity Manager functions detailed in the following sections are performed
using the Identity Manager Web interface
4.3.1 User self-service

One of the key benefits of Identity Manager is the ability to empower users by
giving them the access they need to maintain their account passwords and other
personal information. The Identity Manager interface is Web-based, so there is
no need for client software (other than the standard Web browsers, such as
Microsoft Internet Explorer or Netscape).
Login functions
The login page is shown in Figure 4-3 below. It allows a user to log in with their
Identity Manager user ID and password.
Figure 4-3 IBM Identity Manager login page
There is also a "Forgot your password?" option that will use the
challenge/response function to verify the user before prompting for a password
reset.
87
Self-service functions
The self service section of Identity Manager, focused around the users home
page, allows a user to view and edit information that directly applies to him. Any
person who is granted access to view his own information can use the self
service section to manage his personal information and his action items. The
self-service functions are shown in Figure 4-4.
Figure 4-4 My Home Page of an Identity Manager administrator
The self-service functions are:

Manage passwords: Manage passwords for one, multiple, or all accounts
associated with the user.
Manage accounts: Manage account details for the accounts associated with
the user.
Access to-do list: Where a user is an approver, work items (requests) for
approval will appear in their to-do list.
View pending requests: Where the user is an administrator, and has
submitted work items (requests), any non-completed work items will show up
in the pending requests page.
Access personal information: Manage user details.
Delegate authority: Delegate authority to another Identity Manager user.
88
Password challenge response: Manage challenge response questions and

answers.
All users see these options. Access control can be used to restrict which of these
functions can be performed by each user.
The non-administrators also see the reports menu item, and can run reports if
they have the appropriate access.
4.3.2 Password management

The key function of benefit to users is the ability to manage their passwords. This
includes:
The ability to specify challenge/response information, so that if they forget
their password for Identity Manager, they can use the challenge/response info
to access their Identity Manager account and reset their passwords.
The ability to synchronize passwords across all accounts associated with a
user or select the accounts to synchronize.
Integration with the Windows domain login and password reset functionality,
in order to verify changed passwords meet the applicable password policy
and apply the changed password to other accounts associated with the user.
The challenge/response function is initialized for a user when they first log in to
Identity Manager. They are prompted to select a number of challenge questions
from a list, as shown in Figure 4-5 on page 90.
89
Figure 4-5 Challenge/response specification page
It is possible for the user to select the challenge/response questions and enter
the response to each challenge question, as depicted in Figure 4-6.
Figure 4-6 Users challenge/response details
90
If they subsequently forget their password, they can select the "Forgot your
password?" link on the login page and they will be prompted to supply their
responses before being asked to change their password.
4.3.3 Manage users and accounts

The Identity Manager Server gives system administrators the ability to manage a
company's employees (persons) from a central location. The Manage People
page is available through the My Organization tab of the Main Menu Navigation
Bar.
From the Manage People page, system administrators can:
Add a person (Person, BPPerson, or custom Person)
Delete a person
Suspend (deactivate) a person
Restore (activate) a person
Transfer a person (to a different container)
Manage People
Figure 4-7 on page 92 shows the Manage People dialog.
91
Figure 4-7 Manage People page for Tivoli Austin Airlines CorpHQ container
The Manage People page displays the names of the people in the selected
branch of the organization tree, their current status, and an additional attribute.
Account Management
The Account Management page is used to manage accounts for the person. An
account is a person's access to Identity Manager or to a Service (managed
resource), such as NT, Solaris, and so on. There are multiple ways to manage
accounts:
Select a specific person for whom to manage accounts
Select a service instance for which to manage accounts
Use the search function to search for specific accounts to manage
Figure 4-8 on page 93 shows the account management page for the user Scott
Tiger, who is defined in the Corp HQ organizational unit.
92
Figure 4-8 User (Scott Tiger) Account Management Page
The account management pages are customizable, but should only be changed
by an Identity Manager system administrator and are detailed in 4.7, Common
customization on page 131.
Search function
Identity Manager has a search function that can be used to locate any entity,
including users and accounts. The search page is shown in Figure 4-9 on
page 94.
93
Figure 4-9 IBM Tivoli Identity Manager search page
You can select any object type, such as Person, Business Partner Person, and
Account. Once an object type is selected, any of the object attributes can be
searched on (such as Full Name) with a search condition (such as Contains or Is
Less Than) and an argument. The search argument can include wild cards.
Delegate function
System administrators can select a delegate for a person. More than one
delegate can be selected for a person, but more than one delegate cannot be
selected for the same time period. To change the delegate for a specific time
period, the originally selected delegate must be deleted and a new delegate must
be added for that time period.
4.3.4 Apply policy to user and account management

Policy can be used to automate components of account provisioning and
de-provisioning, account ID creation, and password strength checking. The
policies provided with Identity Manager are:
Provisioning Policy: Dictates the accounts assigned to a user.
Identity Policy: Defines account name/user ID generation.
Password Policy: Defines password strength checking.
Service Selection Policy: Resolves conflicts in provisioning policy.
94
The use of the first three policies for identity management is discussed in the
next section.
Use of provisioning policy for account provisioning

Provisioning Policy is a powerful tool to control which accounts are provisioned
for each type of user. The policy maps sets of users to a set of entitlements. The
sets of users may be all users defined to Identity Manager, users defined to
particular organizational roles, or all users not covered by any other provisioning
policy on any of the entitlement targets associated with the current policy. The
set of entitlements define the accounts that are provisioned as part of the policy.
Provisioning is done to services via organizational roles and not to individuals
directly. Thus, a person must be defined to the appropriate organizational role
before the provisioning policy is invoked to create an account.
Thus, provisioning policy can be used as follows:
Where all users defined to Identity Manager need to have a specific account
type, for example, the Identity Manager account or a Windows domain
account, an organization-wide provisioning policy can be used.
Where the set of accounts a user gets is based on their job role or team, then
a provisioning policy can be based on job role and tied to specific items in the
org tree. For example, there may be a provisioning policy tied to the "UNIX
System Administrator" organizational role that provisions an account on all
UNIX servers. There may also be a provisioning policy tied to the "HR
Administrator" organizational role the provisions accounts on the HR
applications.
You may also need a provisioning policy to cover users that are not covered
by any other provisioning policy. For example, you have defined job
role-based provisioning policy for most of the organization, but you want any
other users to have a basic set of accounts.
Provisioning policy can be used to automatically provision accounts, or merely
control the accounts that can be manually provisioned by an administrator.
Where automatic provisioning is used, it can be configured so that when a user is
moved from one part of the organization (or one job role) to another part of the
organization (or job role) the old accounts are automatically de-provisioned and
new accounts are automatically provisioned (with common accounts
maintained).
The entitlements can also define default attribute values and JavaScript logic to
be applied to the provisioned accounts. This can be used to simplify account
creation. For example, you may hold a department or job role code in a Windows
2000 Active Directory account. You could add some entitlement logic that
95
determines the values for the account attributes and pre-fills the information. This
reduces the reliance on manual data entry.
The following figures (Figure 4-10, Figure 4-11, and Figure 4-12 on page 97)
show the provisioning policy definition for the default Identity Manager service.
This policy entitles all users in Identity Manager to an Identity Manager account.
Figure 4-10 Provisioning policy page: General Tab
Figure 4-11 Provisioning policy page: Membership Tab
96
Figure 4-12 Provisioning policy page: Entitlements Tab
The last tab shows the entitlements for the Identity Manager Service (for Identity
Manager accounts). Identity Manager accounts must be manually created (type
= manual) and there is no workflow associated with this policy.
There can be multiple services associated with each provisioning policy. For
example, a policy for provisioning all UNIX servers (for UNIX systems
administrators) could contain a service for every UNIX system. A user may be
subject to multiple provisioning policies, depending on the scope of the policies
and where the user is placed in the org tree.
Use of identity policy for account ID generation

Identity policies dictate how account logins or user IDs are generated. The
supplied default identity policy uses the first letter of the first name and the
surname. For example, the account ID for John Smith would by jsmith if there
were no other jsmith's defined.
You could have a single password policy that applies to all services, or set
specific policies for services with unique user ID requirements.
You can also have different sets of policy that apply to different parts of the
organization. For example, suppose that ACF/2 user IDs are dependant on
department. Users in department X have logins of T34xxxx and users in
department Y have logins of T77xxxx (where xxxx is built from the users initials).
You could build separate policies for ACF/2 for the different departments, or a
single ACF/2 policy that knows how to match departments to prefixes.
Identity policies are defined dynamically through the use of JavaScript. This
JavaScript function can make use of all standard JavaScript functions and
programming constructs like loops and conditional branches. The values of
personal attributes can also be retrieved with the Identity Manager specific
JavaScript functions. There is a supplied function to check if the generated
account ID is already in use in Identity Manager defined accounts.
97
Use of password policy for password strength enforcement

Password policies are used for enforcing password strength. This applies to any
password changes made through Identity Manager, and password changes
made through the Windows NT/2000 domain login when the integration is
installed.
Figure 4-13 shows the password policy dialog with options.
Figure 4-13 Password policy page: Rules Tab
Password policy can be set at the highest level in the org tree and apply to all
services. You can also have specific policies that apply to certain parts of the
organization or services.
4.3.5 Reconcile accounts

Reconciliation compares user information stored on a managed resource with
the equivalent data stored on the Identity Manager database. Reconciliation
collects all account information of users from the managed resource and
compares them with existing user data stored on the Identity Manager Server by
first looking for the account ownership within the Identity Manager system and,
secondly, looking for existing aliases defined for each account.
98
Aliases are only used to determine if an account on the managed resource can
be matched with a real person in the system. If there is a match of user login IDs
to an alias, the Identity Manager Server is updated with data from the service.
And, if set, the Identity Manager Server verifies that the accounts fit within the
constraints of a defined policy. If there is not a match, the Identity Manager
Server lists the unmatched accounts as orphaned accounts.
You run reconciliation for the following reasons:
Load access information into the Identity Manager directory
Monitor accesses granted outside of Identity Manager administration
4.3.6 Approval workflow

Workflow processes can be used to trigger requests for approval/rejection,
requests for further information, or custom workflow steps.
The notification means for each request is e-mail. If a process has an approval or
RFI step, an e-mail is sent to the appropriate person. When they log into Identity
Manager, they will have a request in the to-do list under their home page. While a
request is pending approval/RFI, it will show in the pending items menu item of
the requestee's home page. When the item has been acted upon, the next step
in the workflow is performed and may initiate further approval/RFI requests.
Once the work item has completely passed through the workflow process, it
shows up as completed in the completed items of the requester.
Figure 4-14 on page 100 shows the workflow Java applet and a workflow
process "W2K - Supervisor RFI + LAN Admin Approval". It applies to the
w2kprofile service profile. Thus, when it is attached to a w2k entitlement in a
provisioning policy, this process applies to all w2k accounts generated by this
policy.
Workflow design and construction is done through a simple to use drag and drop
user interface. It provides the ability to provision a user by using a workflow that
may require the approval of several managers or administrators and the
inclusion of information from various sources of data.
99
Figure 4-14 Screen Shot of the workflow user interface
The workflow consists of the following elements:

Start element
End element
Approval element
Loop element
Subprocess element
RFI element
Approved element
Rejected element
Start element
The Start element is used to start the workflow process and is automatically
placed into the work space upon the creation of the workflow. As the Start
element initiates the workflow, there can be only one that is allowed for each
workflow sequence.
100
End element
The End element is use to locally finish and terminate the sequence of events
within the designed workflow. Like the Start element, it is automatically placed
onto the work space upon creation of the workflow and can only have one End
element within the workflow.
Approval element
The Approval element is a node within the workflow that, upon initiation, will have
the underlying workflow send the appropriate participants or persons within a
role an e-mail to notify that their action is required within the workflow. The
Approval element may be designed for individual use or a combination of both
serial or parallel approval participants. The differences in parallel and serial
approvals is briefly described below.
Upon notification of the approval request, the participant may ether reject or
approve the provisioning action, which will continue the workflow sequence.
It is possible, with the Approval element, to isolate the approval request. For
example, there can be business or required service level requirements that state
that if the request hasnt been handled by the approval participants after a
determined time (which is possible if someone is on leave or sick and the
approval process is only serial), then the approval request may be sent to an
administrator or another person with a similar role of responsibility within the
organization.
Participant approval styles

Two different approval styles are available within the workflow definition, as
depicted in Figure 4-15 on page 102:
Parallel approval is the ability for a group of participants or approvers to be
allocated as part of the workflow that handles the request for approval. The
functioning of the approval only needs one of the participants to process the
request for the workflow to continue (which is a Boolean OR functionality).
Serial approval is the ability to enforce a sequence of participants that are
sequentially added to the workflow. Participants or roles have the ability to
sequentially process the request (which is a Boolean AND functionality).
101
OR
Parallel
Approval
Serial
Approval
AND
Figure 4-15 Parallel and Serial approvals
Workflow example
The workflow example in Figure 4-14 on page 100 shows an approval process
for LAN access. Here we step through the workflow for this example:
1. Prompt the requestee's supervisor (manager or team lead) to supply
additional information for the account, in this case, some Windows 2000
account information, such as their group and home directory.
2. Pass the request to the LAN admin team for approval.
The workflow process is triggered when a Windows 2000 account is created in a
branch of the org tree and a provisioning policy with this workflow attached
applies to that branch. The RFI node ("Supervisor RFI") sends an e-mail to the
supervisor of that branch indicating they have work to do. The supervisor logs
into Identity Manager and their "Access To Do List" page shows the pending
request. They enter in the required information and submit. The supervisor can
also reject the request.
The workflow proceeds to the Approval node ("LAN Admin Approval"). The
requestee's supervisor has specified additional information for the user; the LAN
admins need to sign-off on the request. An e-mail is sent to the service owner for
the Windows 2000 service. They log into Identity Manager, go to their to-do list,
and approve or reject the change. If approved, the new account is provisioned
and an e-mail sent to the requester. If rejected, the new account is backed out
and an e-mail sent to the requester.
102
This workflow process is reasonably simple. For examples of more complex

workflow processes, see the IBM Tivoli Identity Manager Policy and Organization
Administration Guide V4.4, SC32-1149.
This workflow has used standard variables for the approvers. The RFI step uses
the "supervisor" and the Approval step uses the "service owner". Every branch in
the org tree can have a supervisor defined and each service instance can have
an owner defined. This means that this workflow can be used across multiple
branches of the org tree without change. If you change the manager of a
department (supervisor) or the owner of a particular machine (service owner),
you do not need to change the workflow. This is a very powerful feature of the
workflow.
4.3.7 Produce reports

An authorized user can use the Identity Manager report system to create reports
based on the criteria you select. Identity Manager allows authorized users to
generate seven different types of reports:
Operation
Service
User
Rejected
Reconciliation
Dormant
Account
The report dialog is shown in Figure 4-16 on page 104.
103
Figure 4-16 Reports Page
The reports that can be run by a particular administrator depend on the access
control defined for each report. Most reports have screens to specify the report
details. The final report is published in Adobe PDF format and displayed in a new
browser window. The diagram in Figure 4-17 shows a dialog for creating an
Account Password Change for any person.
Figure 4-17 Selection of the Account Password Change
104
Figure 4-18 displays the resulting report.
Figure 4-18 Requested Account Password Change Report
Additional reports can be developed and added to the Identity Manager Web
user interface. Once a report is developed, it can be added to the Identity
Manager Web user interface by modifying an XML file. Details can be found in
the IBM Tivoli Identity Manager Policy and Organization Administration Guide
V4.4, SC32-1149.
4.4 User interface and access control

In this section, we focus on administration, the administrators, and controlling the
scope of administration. All access to Identity Manager is executed via the Web
interface. Thus, all administrators have the same basic Web user interface; the
non-administrative users only see the Home Page, Reports, and Help menu
items, while the administrators see all the menu items. We are also interested in
modifying the look and feel of the application for the administrators.
105
4.4.1 Administrator roles, Identity Manager roles, and ACIs

The business roles are defined in Identity Manager by the creation of Identity
Manager groups (attached to the appropriate ACIs). These groups are attached
to the appropriate ACIs to give the users in those groups access to resources.
These resources are the objects within Identity Manager, such as Person,
Account, Identity Manager User, Location, Business Partner Organization, and
so on.
Let us use an example to explain how we can define granular roles.
An organization has a central Head Office within a central IT Support Group and
Help Desk staff taking calls from both internal and external customers.
From an administration point, the Help Desk Operators are only allowed to reset
passwords, view, and modify user information.
IT Support Group has two identified levels of administrators within the
organization, which are:
Junior Administrators: Who have the same functionality as the Help Desk
operators, with the ability to create users.
Senior Administrators: Who have full control and are the approvers for all
workflow processes.
Figure 4-19 on page 107 shows these relationships.
106
DEPARTMENT
JOB ROLE
ACCESS RIGHTS
Full control
Senior
Administrator
Person
TIM
Acct
W2K
Acct
IT Support
Group
Limited Access
Junior
Administrator
Person
TIM
Acct
W2K
Acct
Limited Access
Help Desk
Operators
Help Desk
Person
TIM
Acct
W2K
Acct
Figure 4-19 An example of user to role mapping
Once the business functionality has been mapped to the role of the user, access
control information can be built up and placed on the objects been protected.
Extremely granular access control can be set, even down to specific managed
attributes within a page. The following access control information screen shots
show a basic level of access control; however, Figure 4-21 on page 109 depicts
specific attributes with access control placed on them.
The access control information placed onto a resource, as shown in Figure 4-20
on page 108, only allows the Help Desk Operator to perform a search on users
within the container and modify attributes.
107
Figure 4-20 Help Desk Operator access control information
If you require a tighter control of what the Help Desk Operators are allowed to
modify, Identity Manager can provide access control down to the attribute. This is
demonstrated in Figure 4-21 on page 109.
108
Figure 4-21 Detailed access control information on specific attributes
With the above ACIs in place, a Help Desk Operator can find a user and view the
users information, except the users Drivers Licence, Home Phone, and Home
Address. Note NONE has been selected next to the attributes that the Help Desk
Operator is not supposed to see.
The Help Desk Operator also is only allowed to modify the users Department
Number and Users Description. Note GRANT allows the modification of the
attributes.
4.5 Identity Manager schedules

Identity Manager will normally be used in real time or near-real time. However,
there are some time-based aspects to Identity Manager:
Scheduling of changes: Many changes made through the Web user interface
can be scheduled to occur at a specific date/time.
Scheduling of reconciliations: The reconciliation process can be scheduled to
occur periodically.
Time limits on workflow: Workflow is by nature asynchronous. The processes
can be configured to time out and escalate to ensure changes do not hang.
Historical reporting: Most reporting is historical.
109
4.5.1 Scheduling of changes

Most administrative changes in Identity Manager can be scheduled.
Even ordinary users can schedule a password change. Figure 4-22 shows a
password change scheduled to occur at 16:00 hours on 18 Feb 2003.
Figure 4-22 Scheduling a password change
Most of the administrative functions can be scheduled, including:

User (Person): Add, modify, suspend, resume, transfer, password reset, and
delete
Account: Add, modify, suspend, restore, password reset, and de-provision
Figure 4-23 on page 111 shows a suspend function for a person.
110
Figure 4-23 Scheduling a user suspension
All scheduled actions show up in the requestor's Pending Requests list.

Figure 4-24 on page 112 shows a pending suspension request.
111
Figure 4-24 Pending changes
As shown in the figure, a request that has been scheduled can be aborted, but
the scheduled date/time cannot be changed.
4.5.2 Scheduling of reconciliations

Reconciliations should be scheduled to run periodically. The aim of the
reconciliation is to determine any differences between the account information in
Identity Manager and the account information on a managed system or
application (service).
Reconciliation of individual services can be scheduled. You can schedule
reconciliations to run on an hourly, daily, weekly, or monthly basis. Figure 4-25 on
page 113 shows how to modify a reconciliation schedule.
112
Figure 4-25 Scheduling reconciliations
Administrators should also periodically check the orphaned account list for the
service and process the orphaned accounts.
4.5.3 Time limits on workflow

Workflow is an asynchronous mechanism. For example, when a request is
raised that triggers workflow, e-mails are sent to approvers who log into Identity
Manager and approve or reject the request. To ensure a request does not
languish in a workflow step waiting for an approver who is on leave, workflow has
two mechanisms for timeouts:
Escalation limits
Where an escalation approver can be specified and, if the first approver does
not act on the request, the request is bumped up to the escalation participant.
Loops
A step or set of steps in a workflow can repeatedly loop a set number of times
(with the escalation limits applying to the steps) and then expire.
Figure 4-26 on page 114 shows the Approval Node dialog with escalation limits.
113
Figure 4-26 Setting escalation limits in workflow
4.5.4 Historical reporting

Most reports available through the Report menu item can be configured to limit
the timeframe for a report.
For example, Figure 4-27 shows the parameters for running an operation report
for the System Administrator creating new users over a 24-hour period.
Figure 4-27 New user creation report parameters
The resulting report shows the timeframe, for example, Start Date and End Date.
This is shown in Figure 4-28 on page 115.
114
Figure 4-28 New User Report output
4.6 Detailed component analysis

IBM Tivoli Identity Manager is basically an application running on an application
server that communicates to the outside world, for example, to users, databases,
user stores, services, and endpoints.
The detailed component section is provided to better understand the different
communication options and not to dissect the internal product functions. We
discuss how to customize the interface, integrate into applications and platforms,
and how to architect a solution that best fits a customers requirements.
4.6.1 Physical architecture

Figure 4-29 on page 116 shows a simple physical architecture of the key IBM
Tivoli Identity Manager components.
115
BROWSER
BROWSER
HTTP(S)
ITIM Server
ITIM
Directory
HTTP(S)
BROWSER
HTTP(S)
Web server
LDAP
v3
ITIM Server
JDBC
(JMS)
Application
Server
Directory Server
ITIM
RDBMS
RDBMS Server
XML/HTTP(S) or FTP (encrypted)

AGENT
AGENT
Proxy System
AGENT
AGENT
AGENT
AGENT
AGENT
RDBMS
App
Protocol
Applications
AGENT
Operating Systems
Directories
Application
Figure 4-29 Physical architecture
The Web user interface is used for accessing Identity Manager via browsers
running on user's workstations. The browsers communicate with the Identity
Manager server via HTTP(S).
The Identity Manager server can contain the Web server, Identity Manager J2EE
application, and application server. The Web and application servers can be split
into two servers, one with the Web server (perhaps running in a DMZ) and the
other with the application server. The Identity Manager server communicates
with the Identity Manager Directory via LDAP protocols (over SSL) and with the
Identity Manager RDBMS via JDBC. The directory and RDBMS can also be local
to the Identity Manager server.
116
Most agents are deployed to the managed targets. Some can be deployed to a
"proxy" system and use the application communication protocols/APIs to
communicate. Most agents communicate with the Identity Manager server via
XML over HTTPS. Some of the older agents, such as the RACF agent, use FTP
with the data encrypted at the application level.
4.6.2 Software and hardware requirements

The following sections describe the software requirements for both supported
versions of the UNIX and Windows operating environments.
Database
An IBM DB2 database must be available to IBM Tivoli Identity Manager Server
and the following details have to be observed:
Application Heap Size: 256
A user called enrole must be created or assigned to manage the IBM Tivoli
Identity Manager DB2 database
Configured to use JBDC2 Drivers
DB2 Version 7 FixPack 7 (upgrading DB2 to level WR21331)
Important: If you are installing IBM DB2 on a computer separate from IBM
Tivoli Identity Manager Server, you must install the IBM Admin Server option
of IBM DB2 (or the IBM DB2 Connect Client) on the IBM Tivoli Identity
Manager Server computer.
For an all-in-one installation, use:
IBM DB2 Personal Edition Version 7.2 with FixPack 7
Note: If IBM DB2 Personal Edition is installed on a different computer than the
IBM Tivoli Identity Manager Server, then the IBM DB2 Connect Personal
Edition client program must be installed on the IBM Tivoli Identity Manager
Server.
For a clustered installation, use:
IBM DB2 Enterprise Edition Version 7.2 with FixPack 7
117
Note: If IBM DB2 Enterprise Edition is installed on a different computer than

the IBM Tivoli Identity Manager Server, then the IBM DB2 Connect Enterprise
Edition client program must be installed on the IBM Tivoli Identity Manager
Server.
Directory server
A directory server must be available to IBM Tivoli Identity Manager for Server.
You can use one of the following:
IBM Directory Server 4.1.0
IBM Directory Server 4.1.0 eFix 00A (also known as Fix Pack 1)
Borne or Bash shell 1.3.1 for UNIX Installations
Workflow engine
IBM MQSeries V5.2 is automatically installed as part of the IBM Tivoli Identity
Manager Server installation in both the single-server and cluster
configurations. You must upgrade this version to CSD5.
IBM MQSeries Support Pack MA88 is automatically installed as part of the
IBM Tivoli Identity Manager Server installation in both the single-server and
cluster configurations.
Application server
Use IBM WebSphere Application Server 4.0.4.
Single-Server configuration
WebSphere Advanced Edition Single Server 4.0.4 is automatically installed
as part of the IBM Tivoli Identity Manager Server installation.
PTF 4 for WebSphere Advanced Edition Server 4.0.4 is required.
Cluster configuration
WebSphere Advanced Edition Server 4.0.4 (must be installed separately
before installing IBM Tivoli Identity Manager Server).
PTF 4 for WebSphere Advanced Edition Server 4.0.4 is required.
AIX installations
The following sections identifies hardware and software requirements specific to
installing the IBM Tivoli Identity Manager Server on an AIX system.
118
Hardware
1 GB of memory
1 GB of free disk space
IBM 604e processor with clock speed of at least 375 MHz
Operating system
AIX Version 4.3.3
Maintenance Level 9 + APAR IY19277 or Maintenance Level 10
Refer to
http://techsupport.services.ibm.com/server/mlfixes/43/10/01to10.html
for more information about updating your version of AIX.
Additional notes
The temp directory (/tmp) must have at least 512 MB of space.
The following environment variable must be defined before installing the IBM
Tivoli Identity Manager Server:
DB2INSTHOME=/home/db2inst1
Solaris installations
installing the IBM Tivoli Identity Manager Server on a Solaris system.
Hardware
1 GB of memory
2 GB of free disk space
Solaris Sun4u Sparc processor with a clock speed of at least 375 MHz
Operating system
Solaris Version 2.8
Patches 108773-13, 108921-13, 108940-37, and 112003-02
Recommended Sun Solaris kernel configuration parameters:
set msgsys:msginfo_msgmap = 1026
set shmsys:shminfo_shmmax = <set to 90% of your physical memory>
set shmsys:shminfo_shmseg = 1024
set shmsys:shminfo_shmmin = 1
set semsys:seminfo_semaem = 16384
set semsys:seminfo_semvmx = 32767
119
set semsys:seminfo_semopm = 100

set semsys:seminfo_semume = 256
Additional notes
The temp directory (/tmp) must have at least 512 MB of space.
Windows installations
installing the IBM Tivoli Identity Manager Server on a Windows system.
Hardware
The minimum hardware configuration for running the IBM Tivoli Identity Manager
Server is:
256 MB of memory1
Processor: Pentium III
825 MB of free disk space:
IBM Tivoli Identity Manager Server (500 MB)
IBM WebSphere Application Server (220 MB)
IBM HTTP Server (20 MB)
IBM MQSeries (85 MB)
Operating system
Windows 2000 Advanced Server with Service Pack 2 (or greater)
Additional notes
The C: drive must have at least 1.1 GB of space.
Directory names can use the characters a-z, A-Z, 0-9, : (colon), . (period), _
(underscore), / (forward slash), and \ (backward slash).
Directory names cannot contain spaces.
4.6.3 IBM Identity Manager application layout

The following is a break down of the directory structure used by IBM Identity
Manager and an entry point for further information.
120
IBM DB2 database and directory server will require an additional 256 MB of memory.
Extensions
This is an index to the extensions features for IBM Identity Manager Versions
4.x. The extensions file structure is broken into three sections:
General Documentation: This includes general descriptions of extensions
features, such as authentication and single sign-on.
API Javadoc: This consists of detailed descriptions of published IBM Identity
Manager Java application program interfaces.
Examples: A series of examples of demonstrating IBM Identity Manager
extensions.
General documentation
Within the file structure of IBM Tivoli Identity Manager, there is useful information
that may provide assistance with application integration and general deployment.
The documentation basically cover the APIs for the sub-processes within the
Identity Manager application.
Authentication (..\Identity Manager\extension\doc\authentication)

This document describes the framework used within the authentication
component of IBM Tivoli Identity Manager and how it can be extended. The part
of the framework that can be extended by a client is called the Application
Programming Interface (API).
The authentication extensible framework and API has been developed to satisfy
two specific goals. One goal is to enable the use of different trusted identity
stores. So, for example, a customer may want to make use of the identity
information stored on a Windows NT domain server or an LDAP directory.
Another goal is to enable the use of different types of keys, typically passwords,
to unlock the application to the user. For example, the use of a SecureID token
could be used instead of the typical hashed password.
Data services (..\Identity Manager\extension\doc\dataservices)

The data services API has been developed to provide the developers of custom
extensions to Identity Manager a portable and backwards-compatible interface to
the Identity Manager data model.
The API consists of a set of Java classes that abstract the more commonly used
data model entities in the provisioning process, such as identities, accounts, and
services.
121
JavaScript (..\Identity Manager\extension\doc\javascript)

The JavaScript extensible framework and API is based on the use of the FESI
JavaScript interpreter. The purpose of extending the framework is not to alter the
capabilities of the interpreter necessarily, but to add additional objects and
functions to the interpreter's glossary so that clients can have more capabilities
available within their scripts interpreted by the FESI interpreter.
The API provided by the FESI JavaScript interpreter will allow a client to create
and register these additional objects and functions with the interpreter so they
can be executed at run time. Although the FESI interpreter is only one vendor's
implementation of a JavaScript interpreter, the API used to extend it is based on
a Netscape standard with the hopes of being portable to other vendors'
implementations if necessary.
Mail (..\Identity Manager\extension\doc\mail)

The mail extensible framework and API has been developed to satisfy the goal of
customizing the content, format, and recipients of notifications the platform sends
during its execution.
The Java-based framework that satisfies these goals is called by the provisioning
platform at any time it needs to send a notification to a user. The interface used
by the platform is abstracted so that any custom extensions would be hidden,
and therefore the presence of these extensions will have no impact on the overall
design of the platform itself. There are two primary audiences, or types of clients,
that will use this API.
One type of client makes notification requests to the framework, like the
provisioning platform. The other type of client extends the framework to
customize how the notification messages are constructed.
Service provider (..\Identity Manager\extension\doc\serviceprovider)

The provisioning connector API has been developed to provide the developers of
custom connectors that can be used from the Identity Manager provisioning
platform, or any other java-based provisioning platform that supports the same
interface. It is expected that the provisioning platform itself will perform all of the
operations needed to determine the operations and their parameters that are to
be executed against resources. The connector itself will be responsible for
executing those operations on the resource in whatever resource specific
manner required. The interface between the platform and the connector used to
implement this procedure is defined with this API.
Single sign-on (..\Identity Manager\extension\doc\singlesignon)

Some Identity Manager installations may be required to be integrated with third
party single sign-on providers. Typically, such single sign-on providers protect a
122
set of Web based resources using an authentication data store that is managed
separately from Identity Manager. The first time a client attempts to access any
protected resource, the single sign-on provider will authenticate and, if
successful, will pass a token indicating the identity of the authenticated user to all
subsequently accessed resources.
When using a single sign-on provider with Identity Manager, it will be necessary
to add a customized logon user interface specific to the single sign-on provider.
Typically, single sign-on providers intercept HTTP requests to a protected
resource, authenticate the user, and place authentication data into the HTTP
header before allowing access to the resource. In this case, the protected
resource is the Identity Manager user interface.
The standard logon user interface provided with Identity Manager will not be
appropriate, since it will prompt the user for a user ID and password. An Identity
Manager logon interface customized for a single sign-on logon provider will
typically collect user credentials from the sign-on provider, verify that the user
has a Identity Manager account, establish an Identity Manager session, and
forward the user into the Identity Manager system.
Logout and session timeouts are related problems that can also be addressed to
fit in with custom approaches.
4.6.4 API Javadoc (..\Identity Manager\extensions\api\

The API Javadoc lists and describes all the Java classes used within the IBM
Identity Manager Application.
Each class, interface, inner class, and inner interface has its own separate page.
Each of these pages has three sections consisting of a class/interface. Each
summary entry contains the first sentence from the detailed description for that
item. The summary entries are alphabetical, while the detailed descriptions are in
the order they appear in the source code. This preserves the logical groupings
established by the programmer.
Class inheritance diagram
Direct Subclasses
All Known Subinterfaces
All Known Implementing Classes
Class/interface declaration
Class/interface description
Inner Class Summary
Field Summary
123
Constructor Summary
Method Summary
Field Detail
Constructor Detail
Method Detail
Extension examples
(..\Identity Manager\extensions\examples\)
Authentication: An example of customizing the authentication process.
Model: An example of using the Model API to read information about identities
and their accounts.
ServiceProvider: An example of a custom connector that plugs directly into
the IBM Identity Manager provisioning platform.
Single sign-on: An example of integrating a single sign-on solution with the
IBM Identity Manager provisioning platform.
4.6.5 LDAP analysis

IBM Tivoli Identity Manager uses LDAP for a common store of user data and
hence, upon installation of the IBM Directory Server, it installs its own LDAP
suffix objects.
Figure 4-30 on page 125 shows a diagram of IBM Tivolis Identity Manager
directory mapping. A brief explanation of each containers operations is shown in
Table 4-1 on page 125.
124
IBM Tivoli Identity

Manager Root Node
ou=itim
(Application Inform ation)
ou=excludeAccounts
ou= CompanyNam e
o=organizationNam e
(Organization information)
ou=itim
(Service Inform ation)
ou=constraints
ou=orgChart
ou=policies
ou=formTemplates
erdictionaryname=
password
ou=w orkflow
ou=sysRoles
ou=objectProfile
ou=services
ou=orphans
ou=recycleBin
ou=accounts
ou=roles
ou=serviceProfile
ou=people
ou=system User
ou=0
ou=n
ou=0
ou=joinDirectives
ou=n
ou=challenges
Figure 4-30 IBM Tivoli Identity Manager basic LDAP schema

Table 4-1 Container descriptions
Container
Description
Root Node
The Root Node is where the Tivoli Identity Manager

Server is installed.
ou=Identity Manager
This container stores all pertinent information for

the Tivoli Identity Manager application.
ou=constraints
This container stores membership restrictions for

various roles and services.
erdictionaryname=password
This container stores invalid password entries for

use with password policies.
125
Container
Description
ou=CompanyName
Name of the company. This container is the parent

container for all information pertaining to the
company within the Tivoli Identity Manager system.
o=OrganizationName
This is the name of the organization as it appears in

the Organization Tree.
ou=orgChart
This container stores the definition of the

organizations and organizational units within Tivoli
Identity Manager.
ou=workflow
This container stores all the workflows designed for

use within the Tivoli Identity Manager system for the
company.
ou=services
This container stores information pertaining to the

services installed for use with the Tivoli Identity
Manager system.
ou=accounts
This container stores all accounts in the Tivoli

Identity Manager system.
ou=policies
This container stores all the defined policies.
ou=sysRoles
This container stores all information pertaining to

the Identity Manager Groups defined within Tivoli
Identity Manager.
ou=orphans
This container stores all orphan accounts retrieved

during a reconciliation.
ou=roles
This container stores all information for all

organizational roles defined within Tivoli Identity
Manager.
ou=people
This container stores all information about Persons

within Tivoli Identity Manager.
ou=enRole
This container is the parent container for system

specific information.
ou=challenges

the Password Challenge/Response feature.
ou=objectProfile

the object profile.
ou=serviceProfile
This container stores the service profiles required

for the system to recognize a managed resource as
a service.
126
Container
Description
ou=systemUser
This container stores information about system

users.
ou=formTemplate
This container stores information about the various

forms and the form templates used within the
system.
ou=joinDirectives
This container stores all the information about the

provisioning policy join directives.
ou=recycleBin
This container stores entities deleted from the

system using the graphical user interface.
Important: As a default, the LDAP directory has no Access Control Lists

(ACLs) around the branches and data within the directory. Depending on your
companys Security Policy, a combination of ACLs and the use of SSL for
secure network connectivity may be required.
Figure 4-31 shows an example on how to set an access control list on the LDAP
Server
Figure 4-31 Binding to LDAP server using a LDAP Client and cn=root as user
Enter the user DN to bind to the LDAP Directory.
127
Select dc=com and click on the ACL button, as shown in Figure 4-32.
Figure 4-32 Browsed Tree on LDAP Server
Change the access control list to deny any unauthorized user access to LDAP
and click OK to accept the changes, as depicted in Figure 4-33 on page 129. The
LDAP server has to be restarted for the changes to be committed.
128
Figure 4-33 ACL for DC=COM
4.6.6 DB2 table analysis

IBM Tivoli Identity Manager loads tables into the selected database during
installation. These tables are used for five features in Tivoli Identity Manager:
Workflow
Services
Scheduler
JMS messaging
Performance optimization
129
Workflow tables
Tivoli Identity Manager stores workflow specific information in the following
database tables:
The process table stores all the pending, running, and historical requests
submitted to the IBM Tivoli Identity Manager workflow. Each request is
represented as a process. The table includes descriptions of each column
name.
The processlog table maintains a record of audit events associated with a
process.
The processdata table stores the run-time process data of a process. After the
process is completed the table is removed.
The activity table contains records of each workflow process execution
status.
The workitem table maintains a record of work items associated with manual
workflow activities for running processes. The records associated with the
process are removed after the process is completed.
The password_transaction table is used during secure password delivery to
store information. After the password is retrieved, the record is deleted from
the table.
The pending table stores all provisioning requests that have not been
processed. This is a temporary table that is only created when another
request is being processed.
Services tables
Tivoli Identity Manager creates and uses the following database tables to store
information related to managed resources:
The resource_providers table stores cross references between resource
provider IDs and stores reconciliation data for each resource provider. The
resource provider IDs are used as the primary keys for resource provider
entity beans. The table includes descriptions of each column name.
The remote_services_requests table stores asynchronous requests or
requests that are made while a reconciliation is in progress.
The remote_resources_recons table stores the reconciliation units associated
with a given resource provider. The table includes descriptions of each
column name.
The remote_resources_recon_queries table stores reconciliation queries
associated with a given reconciliation unit. The table includes descriptions of
each column name.
130
Scheduler table
The scheduler is a component of Tivoli Identity Manager that stores one-time or
regularly scheduled events. These events are typically user requests (via the
workflow engine) or recurring reconciliation events. The scheduler stores the
information associated with the scheduled event in the scheduled_message table.
Performance optimization table

The listdata table is used to optimize memory utilization and improve
performance for IBM Tivoli Identity Manager. This table is used to store large
data lists. Instead of loading all data into memory, data will be stored in this table
and referenced by index in memory.
4.7 Common customization

Throughout this section, we have customized our application with a customer
(Tivoli Austin Airlines) logo. This is one of the available customization processes
that Identity Manager allows, with the following customization detailed in the
section:
User interface
Forms
4.7.1 User interface

The Identity Manager Web application is a Java application. The dialogs consist
of HTML code, JavaScript and some java applets (such as the workflow applet).
The following standard modifications can be made:
Every page has a standard logo in the top left corner. It currently contains the
IBM logo. It can be changed to any other logo by changing the appropriate
file.
Every page can have a logo in the top right corner that is a link. Both the
filename and the URL to jump to can be specified when the product is
configured. It can be later changed using the runConfig utility.
The forms for each object can be modified. This is discussed in the next
section.
131
4.7.2 Forms
Each object in Identity Manager has forms associated with it. The standard form
for the Person object (user) is shown in Figure 4-34.
Figure 4-34 Modify Person page: Corporate Information tab
There are three tabs for this form; Personal Information, Corporate Information,
and Communications Information. Each tab allows for the data entry of the
Person attributes.
The forms for the other Identity Manager objects are similar.
The layout of all forms can be modified using the User Interface Customization
Java applet under the Configuration menu item. Figure 4-35 on page 133 shows
this applet with the Person object form open and the Corporate Information tab
showing.
132
Figure 4-35 User Interface Customization applet for Person Corporate Information tab
This applet has five components:

The menu bar
The object selection list, with the Person object selected
The current form being edited, in this case, the Person form
The attribute list, showing all attributes that can be displayed on the form
The properties of the currently selected attribute
There are many changes that can be made to the forms for a deployment,
including:
Remove attributes that are not required to simplify the form for data entry.
Reduce the number of tabs to simplify the form for data entry.
Align the tabs and attributes on each tab to workflow, so that all initial data
entry is performed on the first tab and RFI attributes are on subsequent tabs.
Where an attribute has a defined set of values, such as "title", replace the
standard text field with a drop-down list.
Use attributes for other purposes and relabel the fields.
133
Form modification example 1

The following example shows some simple modifications:
The Communications tab has been relabelled to "Red Pages."
A new Tab Tivoli Austin Airlines has been created.
The Car Licence attribute under person attribute has been relabelled to
"Employee Type."
This is shown in a simplified Person form, with many attributes removed and all
remaining attributes put on a single tab. The configuration applet view of the form
is shown in Figure 4-36.
Figure 4-36 User Interface applet for first customization
The modified Person form is shown in Figure 4-37 on page 135.
134
Figure 4-37 Modified Person form with first customization
All of the Identity Manager object forms can be modified in this way.
Any modifications apply to the entire installation. You cannot have different forms
for different parts of the business.
Tip: The Tivoli Identity Manager online help functions provide more
information about how to design forms. After you have started the online help,
search for custom constraints.
4.8 Agent connectivity

In todays e-business environment, effective and efficient data management is
crucial. As such, two technologies prove vital to proper data management:
directory services and XML. Directory services allow you to store and manage
data. XML provides an effective way to present and transfer data. With that in
mind, there is a clear need to bridge the two technologies. Today, Tivoli Identity
Manager 4.4 exclusively uses the Directory Access Markup Language (DAML)
which represents directory operations in XML, for all agent communication.
135
It is Tivolis stated intention to support the Directory Service Markup Language

(DSML) standard, designed to make directory services more dynamic by
employing XML, in future versions of the product.
How does the communication between the IBM Tivoli Identity Manager Server
and the remote service work? Let us take a closer look at the schematics
depicted in Figure 4-38.
IBM Tivoli Identity

Manager Server
ml
l
e. x
xm
S
nt. .xml
L
u
o
s
AM
cc
rm
IXD rAIXA
xfo
erA
e
c
eri
Tivoli Identity
LDAP
Manager
AIX Server
/etc/passwd
CA Public Cert
HTTP(S)
Workflow
signed Server Cert
CA Cert
erglobalid=8586800984477496319
cn = Doris Penman
sn = Penman
erAIX=a016432
UID number=3001
Unix Shell = /bin/ksh
$cn=doris penman
$sn=penman
$eruid=a016432
$UID number=3001
$erunixshell=/bin/ksh
Figure 4-38 DSML connectivity
It is all about data.

Most attributes within the IBM Tivoli Identity Manager Server have a unique
identifier that is used to tie information and data together on a user, such as what
service they can access, the access control that has been enforced on the user
and service, and the type of data field.
With every data repository having different data structures, IBM Tivoli Identity
Manager basically manages the attribute mapping between the two points and
then allows the centralized control of the users information from one point.
With a new user (in this example, Doris Penman) identified within the IBM Tivoli
Identity Manager Service, basic information is collected and stored within the
LDAP directory. Upon creating the user within the service (in the example, the
service is an AIX service), data from the LDAP directory is mapped to the
required information on the target platform. This information is sent to the service
136
over HTTP(S), where the end service reads the information and creates the user
on the operating system.
In our example in Figure 4-39, you can see that user Doris has been created as
user a016432 and mapped into the AIX operating system with the various
attributes.
Figure 4-39 User Doris displayed in AIX operating system
Within LDAP, you can see the user Doris has a unique Object Identifier and the
various AIX attributes are stored within the accounts object, as shown in
Figure 4-40.
Figure 4-40 User Doris displayed in the LDAP Directory
137
4.9 IBM Directory Integrator

In the future, it is IBM Tivolis stated intention to use IBM Directory Integrator as
the preferred method of integrating new services or information sources into the
identity management service.
Through the provisioning policy, for example, as part of the workflow process,
information, such as the requirements of a users clothing sizes, may be exported
to a storage area for the issuing of a uniform in the form of a Microsoft Excel file
or a comma separated file (CSV file).
For this reason, this section covers the basic concepts of IBM Directory
Integrator and the possible use of this technology integrating end points, such as
the following:
Comma Separated Values file
NT 4/Windows 2000
Active Directory
MQ Series
Figure 4-41 shows an overview of the IBM Directory Integrator components
involved in the Identity Manager environment.
Assembly
Line
Event Handler
ITIM
Operating
System
Database
LDAP
Parser
CSV File
Figure 4-41 IBM Directory Integrator components
138
Connectors
4.9.1 CSV file

The IBM Directory Integrator connectivity to a file format such as a CSV file
would be through a parser, which basically takes the information that comes off
the Assembly Line and transforms it into the correct data format.
4.9.2 Windows NT 4 and Windows 2000

The Windows NT4 connector operates with the Windows NT security database.
It deals with Windows NT users and groups (the two basic entities of the
Windows NT security database). The connector can both read and modify the
Windows NT security database on the local Windows NT machine, the Primary
Domain Controller machine, and the Primary Domain Controller machine of
another domain.
This connector depends on a Windows NT API, and only works on the Windows
platform.
The connector is designed to connect to the Windows NT 4 and Windows 2000
security databases through the Win32 API for Windows NT 4 and Windows 2000
user and group accounts. You can connect to a Windows 2000 security
database, but the connector will only read/write attributes that are
backward-compatible with Windows NT 4 (in other words, the connector has a
pre-defined and static attribute map table consisting of Windows NT4 attributes).
Windows 2000 native attributes or user defined attributes are therefore not
supported by the connector.
4.9.3 IBM Directory Integrator password synchronizer plug-in

The password synchronizer intercepts Windows NT user ID and password
change requests and propagates the changes to the multiple user ID and
password repositories (data sources) before the Windows NT system changes
the password.
The IBM Directory Integrator password synchronizer changes the password of
the user ID and password entry in an LDAP server (repository/datasource). The
changes can then be propagated to the other servers by writing an IBM Directory
Integrator EventHandler and IBM Directory Integrator AssemblyLine.
This component can be used on Windows NT, Windows 2000, and Windows XP
operating systems.
Additionally, the IBM Directory Integrator password synchronizer can be used to
provide global password policy enforcement, by rejecting password changes on
139
the Windows systems if the LDAP server does not accept the new password
(password enforcement).
Synchronize from single machine

To synchronize passwords from a single machine to the external data source
through the use of the custom written Java synchronization code, simply follow
the install instructions to install the password synchronizer on the Windows
platform.
Synchronize from Windows NT domain

To synchronize password changes from a Windows NT domain, install the
password synchronizer on the Primary Domain Controller (PDC) for the domain
you want to synchronize with. Additionally, you must install the password
synchronizer on all backup domain controllers, in case the roles of the domain
controllers change.
Synchronize from a Windows 2000 or Windows XP domain

To synchronize password changes from a Windows 2000 or Windows XP
domain, install the password synchronizer on all domain controllers for the
domain you want to synchronize with.
Let us take a look at the following example:
Doris logs into her Windows machine, presses Ctrl-Alt-Delete, and requests a
password change. That password change is handled by the local timpwflt.dll file,
which delegates the request to an associated Java class file, which implements
com.ibm.bim.pwfilt.IPasswordSynchronizer by calling the syncPassword method
of that interface. The custom code in our case is the
com.ibm.di.plugin.idipwsync.IDIPasswordSynchronizer, which sets or updates
the information on a remote LDAP server. If the method returns true, meaning the
password was accepted, then the password is changed on the native Windows
machine, regardless of whether it is a stand-alone machine or a domain
controller.
4.9.4 Active Directory

The Active Directory changelog connector is a specialized instance of the LDAP
connector. This connector contains logic to poll for changes to Active Directory
using the .uSNChanged mechanism.
When started, the Active Directory changelog connector reads, from a file, the
USN values stored from the most recent connectors session. The connector first
retrieves the newly added Active Directory objects, then the modified and deleted
Active Directory objects. After an Active Directory object is retrieved, it is parsed
140
and its attributes and attribute values are copied to a new entry object. This entry
object is then returned by the connector. When there are no more Active
Directory objects to retrieve, the connector cycles, trying to retrieve the next
changed Active Directory object. The sleep interval connector parameter
specifies the number of seconds between two successive cycles. The connector
loops until a new Active Directory object is retrieved or the timeout (specified by
the time-out connector parameter) expires. If the timeout expires, the connector
returns an empty (null) entry, indicating there are no more entries to return. If a
new Active Directory object is retrieved, it is processed as previously described,
and the new entry is returned by the connector.
4.9.5 IBM MQSeries and JMS

The JMS connector provides access to JMS based systems, such as IBM
MQSeries. The connector enables communication of both native entry objects
and XML text to be passed using a Java Message Server based product.
The JMS connector supports JMS message properties. Each message received
by the JMS connector will populate the conn object with properties from the JMS
message (use the getProperty() and setProperty() methods of the entry class to
access these). Conn object properties are prefixed with .jms.. followed by the
JMS message property name. The property holds the value from the JMS
message. When sending a message, the user can set properties that will then be
passed on to the JMS message sent. The JMS connector scans the conn object
for properties that starts with .jms.. and sets the corresponding JMS message
property from the conn property:
JMS:correlationID=12 > conn jms.correlationID=12
conn:jms.inReplyTo=12 > JMS:inReplyTo=12
The conn object is only available in a few hooks.
Note: Currently, only the IBM MQSeries server is supported for this type of
connector.
JMS messages
Everything sent and received by the JMS connector is a JMS message. The JMS
connector converts the IBM Directory Integrator entry object into a JMS message
and vice versa. Each JMS message contains pre-defined JMS headers, user
defined properties, and some kind of body that is either text, a byte array, or a
serialized Java object.
141
JMS message types

The JMS environment allows you to send different types of data on the JMS bus.
This connector recognizes three of those types. The three types are referred to
as TextMessage, BytesMessage, and ObjectMessage. The most open-minded
strategy is to use TextMessage (for example, jms.usetextmessages=true) so that
applications other than IBM Directory Integrator can read messages generated
by the JMS connector.
When you communicate with other IBM Directory Integrator servers over a JMS
bus, the BytesMessage provides a very simple way to send an entire entry object
to the recipient. This is also particularly useful when the entry object contains
special Java objects that are not easy to represent as text. Most Java objects
provide a toString() method that returns the string representation of it, but the
opposite is very rare. Also, the toString() method does not always return very
useful information. For example, the string representation of a byte array is
.[B@<memory-address>..
Text message
A text message carries a body of text. The format of the text itself is undefined so
it can be virtually anything. When you send or receive messages of this type, the
connector does one of the following things, depending on whether you have
specified a parser or not:
When you specify a parser, the connector calls the parser to interpret the text
message and returns the attributes along with any headers and properties.
When sending a message, the provided conn object is passed to the parser in
order to generate the text body part. This makes it easy to send data in
various formats onto a JMS bus (for example, use the LDIF parser, XML
parser, and so on). You can even use the SOAP parser to send SOAP
requests over the JMS bus.
If you do not have a parser defined, the text body is returned in an attribute called
message. When sending a message, the connector uses the provided message
attribute to set the JMS text body part:
var str =work.getString ("message");
task.logmsg ("Received the following text:"+str );
If you expect to receive text messages in various formats (XML, LDIF, CSV, and
so on), you should leave the parser parameter blank and make the guess
yourself as to what format the text message is. When you know the format, you
can use the system.parseObject(parserName, data) to do the parsing for you.
142
4.9.6 JNDI
The JNDI connector provides access to a variety of JNDI services. In order to
reach a specific system, you may have to install the JNDI driver for that system.
The driver is typically distributed as one or more *.jar or *.zip files. Place these
files in a place where the Java run time can find them, for example, in the
.lib/ext....directory.
4.9.7 LDAP
The LDAP connector provides access to a variety of LDAP based systems. The
connector supports both LDAP Version 2 and 3.
Note that, unlike most connectors, while inserting an object into an LDAP
directory, you have to specify the object class attribute, the $dn attribute
(distinguished name), as well as the other attributes.
143
144
Chapter 5.

integration
Access and Identity Management are starting to merge in the market place. As
the Tivoli security products move forward, Access and Identity Management will
become increasingly integrated to allow customers to manage their security
framework from a single consistent management point.
This chapter describes how IBM Tivoli Identity Manager Version 4.4 both
integrates with and manages aspects of IBM Tivoli Access Manager. Topics
covered include what management tools are available, what common
components are used in an integrated environment, as well as how to use
Access Manager to protect access to your Tivoli Identity Manager GUI interface.
145
5.1 Functional overview

Many customers need access and identity management together to help manage
the security of an enterprise. IBM Tivoli Identity Manger Version 4.4 and IBM
Tivoli Access Manager Version 4.1 are two products offered by Tivoli Software.
This chapter describes how to use these products together to provide a complete
management solution for users and their access to resources in an enterprise.
Tivoli Identity Manager can be used to manage Tivoli Access Manager users and
groups. There are also different customizations that can be done to optimize the
integration of Identity Manager and Access Manager when managing Access
Manager accounts. In order to manage Tivoli Access Manager accounts, a Tivoli
Access Manager agent must be installed and configured, and a Tivoli Identity
Manager service is created to represent the Tivoli Access Manager user registry.
A provisioning policy is then set up in Tivoli Identity Manager to enable
provisioning Tivoli Access Manager accounts to users. Default values can be
specified using JavaScript to set Tivoli Access Manager attributes. Tivoli Access
Manager account management can be automated with automatic provisioning,
which creates Tivoli Access Manager accounts for every user with a given set of
attributes. Reconciliation can be set up to import Tivoli Access Manager
accounts into Tivoli Identity Manager. Finally, Tivoli Identity Manager ACIs and
groups can be created to implement a delegated administration hierarchy to
allow administrative control over subsets of people.
Each product is used for a different purpose, and is targeted towards different
levels of administrators. Access Manager is used to enforce access control, and
an administrator would use the Access Manager interfaces to set up a
company's security policy to define categories of users that need access to
different resources. Once the security policy is set up, then Identity Manager can
be used, with its rich delegated administration capabilities, to manage users and
their access to resources.
Special considerations are also required to manage Access Manager WebSEAL.
Identity Manager can manage business entitlements used by WebSEAL.
WebSEAL can be used to protect Web applications. When Identity Manager is
deployed in a WebSEAL environment, the Identity Manager Web application is
protected as well. In this environment, a user authenticates to Access Manager
so that WebSEAL can determine if that user is authorized to access specific Web
applications. Single sign-on can be set up between Identity Manager and Access
Manager so that users do not have to authenticate to both products.
Tivoli Access Manager for Operating Systems also has some requirements when
managing Access Manager accounts and UNIX accounts. Identity Manager can
be customized to help satisfy these requirements.
146
5.2 Managing Access Manager with Identity Manager

Identity Manager can manage a users "identity" data, along with a user's
provisioning policy, which contains entitlements that represent a user's accounts
and access on various systems and applications.
Identity Manager allows management of Access Manager data as part of
managing a user's provisioning policy by managing Access Manager accounts.
Once Access Manager entitlements are set up as part of a user's provisioning
policy, Identity Manager administrators can manage Access Manager accounts
for that user. Identity Manager also allows Access Manager customization in the
form of entitlement attributes, identity policy, and password policy. Identity
Manager administrators can also add users to groups using the group
membership attribute of the Access Manager account. Setting up automatic
provisioning can create an access manager account automatically when a user
becomes a member of an organizational role.
One additional feature that should be considered when managing Access
Manager data is Identity Manager's delegated administration capability.
5.2.1 Creating an Access Manager service

In order to start managing accounts in an Access Manager deployment, the
Access Manager agent and service profile must be installed, then the Access
Manager service must be defined.
Installing the Access Manager agent and agent profile

Information on how to install the Access Manager agent and the agent profile can
be found in the installation documentation that is included with the agent
software. The agent must be installed on a machine with an Access Manager run
time installed and configured. The agent install asks for the Access Manager
administrator ID and password, which is used to perform Access Manager
administrative operations. sec_master can be used here, or another
administrator user ID can be created with the authority to perform user and group
operations.
As with other Identity Manager agents, the agent must be configured, and the
SSL certificate(s) must be installed. The installation guide describes how to
configure the agent.
In an Access Manager for Operating Systems environment, multiple agents may
be required on the same machine, one for Access Manager, and one to manage
the UNIX user registry. Different port numbers are needed for each agent.
Figure 5-1 on page 148 shows a screen shot of the agentCfg command.
Chapter 5. Tivoli Access Manager integration
147
Figure 5-1 The agentCfg command
To set the port number, execute:

agentCfg -a TAMAgent
and do the following:

1. Enter the configuration key, usually agent.
2. Select option B: Protocol configuration.
3. Select C: Configure Protocol.
4. Select A: DAML.
5. Select A: Portnumber.
6. Enter a new port number, 45581, for example.
7. Enter X to exit the tool.
Changing the Access Manager agent administrator password

To change the Access Manager administrator password specified to the Access
Manager agent during install, use the agentCfg utility, with the following steps:
1. From the main menu, select Registry Settings.
2. Select Modify encrypted registry settings.
3. Select Modify attribute value.
4. Enter erTAMUserPasswd for Registry item to modify.
5. Enter the new password.
148
Creating the Access Manager service

Before Identity Manager can manage accounts in Access Manager, an Access
Manager service must be created. To create a service, the administrator must
navigate to the Provisioning tab in the Identity Manager GUI, then to the
Manage Services task. Pressing the Add button shows a list of available service
types that can be added. Select the TAMProfile service type. If the TAMProfile
service type is not listed, then the agent profile installation was either not
performed, or was not successful. The attributes shown for a Access Manager
service are the same as for other services. If multiple agents are on the same
machine, the Access Manager agents port number must be used in the URL
attribute to make sure that this service accesses the Access Manager agent.
5.2.2 Setting up an Access Manager specific policy

Another aspect of managing Access Manager account types is setting up a
policy specific to Access Manager. The different types of policy to consider are
password policy and identity policy. Password policy specifies the password rules
that control the content of an account password when a user changes their
password. Identity policy defines how to create user IDs for accounts.
Identity policy
An identity policy defines how a user's ID is created. Identity Manager
automatically generates user IDs from the identity policy, which can be assigned
per service or service type. Identity Manager allows JavaScript code to be written
to specify the string to use for the user ID.
For Access Manager, one method of creating a user ID would be to base it on a
user's common name (CN) and their surname or last name (SN). Example 5-1
shows a sample JavaScript that could be used as part of an Access Manager
service identity policy.
Example 5-1 Access Manager service identity policy JavaScript
function createIdentity()
{
var cn = subject.getProperty('cn')[0];
var sn = subject.getProperty('sn')[0];
var userid = "";
userid = cn.toLowerCase().substring(0,1) + sn.toLowerCase();
return userid;
}
return createIdentity();
149
A JavaScript object representing the person entity within the Identity Manager
data model is referred to as the subject. In this example, the cn and sn are used
from the person entity to generate the user ID. The first character of the cn is
appended to the last name to create the user ID. The user ID is returned in lower
case.
Password policy
Considerations should also be made in regards to the password policy. There are
three areas of password policy that should be addressed:
Password synchronization
Password strength policy
Password login policy
Identity Manager provides the capability to keep passwords synchronized. There
is a property that can be set from the Configuration panel in the Identity Manager
GUI, which enables password synchronization, as shown in Figure 5-2.
Figure 5-2 Password synchronization
150
To enable this feature, go to the Properties tab in the Configuration panel, and
check Enable password synchronization. If this feature is enabled, Identity
Manager keeps all of a user's passwords the same. Users will not be able to
change account passwords separate from their Identity Manager password using
the Identity Manager interface.
Identity Manager also provides the capability to set a password strength policy,
which Identity Manager calls the password policy, at a variety of levels.
Password policy can be set at a service level, a service type level, or for all
services.
In order to keep passwords synchronized between Identity Manager and Access
Manager, all password change operations should go through Identity Manager,
and Identity Manager can both enforce a common password policy, and can keep
the passwords synchronized. Users should not be allowed to change their
passwords through the pdadmin command or the Web Portal Manager Web
interface.
If WebSEAL has been deployed in the environment, it also has the capability of
changing a user's Access Manager password. In this environment, the WebSEAL
reverse password synchronization module should be installed into WebSEAL so
that all password checking goes through Identity Manager, and the Access
Manager password is synchronized with Identity Manager managed passwords.
In an Access Manager for Operating Systems environment, the best method of
keeping passwords synchronized is to have user's change their passwords
through the Identity Manager Web Interface. This allows Identity Manager to
manage the passwords in Access Manager as well as on the different UNIX
endpoints. Measures can be taken to disable the change password operation on
the different UNIX machines; however, when a password has expired, some
users have no way to get to the Web interface, because they cannot log into their
systems. Access Manager for Operating Systems login policy can be set to
include a number of grace logins, which would allow a user to log onto a system
after the expiration date. Then the user would have the opportunity to perform a
change password operation using a browser without being locked out of the
system.
Provisioning policy with Access Manager entitlements

Before Access Manager accounts can be created for users, an appropriate
provisioning policy must be set up with Access Manager entitlements.
Here are sample steps describing how to create a provisioning policy with
Access Manager entitlements:
1. Navigate to the Provisioning Policy tab in the Identity Manager GUI.
151
2. Select the Define Provisioning Policy task.

3. Press the Add button.
4. In the General tab, specify the name of the policy and the caption.
5. In the membership tab, specify an organizational role All(*) or Others. This
indicates who the provisioning policy will affect.
6. In the Entitlement tab, specify manual or automatic. This specifies if a user
is automatically given this entitlement or if it has to be given manually. Below
is a scenario that describes how to use automatic entitlements.
7. Select service to indicate that this is for a specific service, then select
Access Manager Profile and the Access Manager Service you want to
provision.
8. To use JavaScript to specify the value of the entitlement attributes, go to the
Advanced Provisioning Parameter list.
9. Press the Add button, Select cn, and add the following JavaScript to the text
box:
{subject.getProperty("cn")[0]}
This sets the Access Manager cn or common name attribute to the same
value as the Identity Manager 4.4 person cn attribute. The Enforcement type
should be DEFAULT, and the Expression type should be
JavaScript/Constant.
10.Press the Add button, select sn, and add the following JavaScript to the text
box:
{subject.getProperty("sn")[0]}
This sets the Access Manager sn, or surname attribute to the same value as
the Identity Manager 4.4 person sn attribute. The Enforcement type should be
DEFAULT, and the Expression type should be JavaScript/Constant.
11.Press the Add button, select ertamdn. The JavaScript code should be added
to create a desired dn for the Access Manager account as shown below:
{"cn="subject.getProperty("cn")[0]+",o=tivoli,c=us"}
For a user named "Joe User", this would set the Access Manager dn to:
cn=Joe User,o=tivoli,c=us
12.Press the Add button and select eruid. The JavaScript code should be added
to create a desired uid for the Access Manager account, as shown below:
{subject.getProperty("cn")[0].toLowerCase().substring(0,1) +
subject.getProperty("sn")[0].toLowerCase()}
13.Press the Add button and select ertamsinglesign. Set the attribute to TRUE
or FALSE to enable or disable GSO credentials for users.
152
14.Press the Add button and select ertampasswordpolicy. Set the attribute to
TRUE to enable password policy checking. If all password changes come
through Identity Manager, this can be left disabled, or set to FALSE.
15.The complete Entitlement Default Attributes you entered are depicted in
Figure 5-3.
Figure 5-3 Access Manager Entitlement Default Attributes
16.Press Submit to submit the default attribute settings.

17.If workflow is desired, check the Identity Manager documentation on how to
create a workflow for this entitlement.
18.Press Add, and remember to press Submit twice.
Creating an Access Manager account

Here are the steps to create an Access Manager account for a user:
1. Navigate to the My Organization and My People task.
2. There should be a list of people to manage; select one of the people to add to
an Access Manager account.
3. Select manage accounts and press the New button.
4. If the Access Manager service does not appear in the list of available
services, then either the provisioning policy was not set up correctly, or the
membership was not specified to include the user that is being managed.
Select the Access Manager service and press Continue.
153
5. The User Information Tab should have the User ID filled in via the identity
policy, and the Full Name and the Last Name should be filled in via the
JavaScript in the advanced provisioning parameters of the Access Manager
entitlement. Fill in the Description and the LDAP dn, as shown in Figure 5-4.
Figure 5-4 Access Manager user information
Note: JavaScript should also be used to fill in the LDAP dn. Currently there
is no way to share the Identity Manager Person object and the Access
Manager Person object with the Access Manager Agent.
6. In the Administration tab, group membership can be defined. A reconciliation
must be performed to get all the group names into Identity Manager. Group
membership will be discussed below.
7. Press Submit, specify the password, and then press Submit again.
5.2.3 Managing Access Manager groups

Administrators can also manage Access Manager groups using Tivoli Identity
Manager. Access Manager groups can be managed by modifying the LDAP
group membership attribute on a user's account. To add a user to a group, select
the Access Manager account from a user's account list, and add the group to the
user's LDAP group membership attribute. To delete the user from a group,
remove that group from his LDAP group membership attribute. Identity Manager
obtains the list of Access Manager groups when reconciliation is performed
against an Access Manager service. Regularly scheduled reconciliation must be
performed to keep the group list up to date. Access Manager groups cannot be
154
created or deleted using the Identity Manager interface today; either Web Portal
Manager or pdadmin must be used.
5.2.4 Reconciliation
As with other Identity Manager Version 4.4 services, Access Manager accounts
can be imported into the Identity Manager database using reconciliation. When
setting up reconciliation for Access Manager, certain system accounts must be
excluded, and should not be adopted into the 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 Identity Manager database. The accounts can be
entered manually, or an LDIF file can be used. Here is a sample LDIF file that
can be used to specify the accounts to exclude from Access Manager:
dn: ou=excludeAccounts, ou=itim, ou=tivoli, dc=com
ou: excludeAccounts
objectClass: top
objectClass: organizationalunit
dn: cn=TAMProfile, ou=excludeAccounts, ou=itim, ou=tivoli, dc=com
erObjectProfileName: TAMProfile
objectClass: top
objectClass: eridentityexclusion
erAccountID: sec_masterer
AccountID: ivmgrd/master
erAccountID: amwpm/tamserver
erAccountID: ivacld/tamserver.tivoli.com
This LDIF file creates the excludeAccounts container object in LDAP, and then
adds an entry for TAMProfile, which applies to all services of type TAMProfile.
The excluded list contains several accounts. Access Manager creates the
sec_master account for administrative purposes, and that account should not be
reconciled into Identity Manager. The other accounts are used as server
principals, and are not assigned to people. To get an exact list of accounts, and
their exact names, the pdadmin command should be used to list all the users:
pdadmin> user list * 100
sec_master
ivmgrd/master
awwpm/tamserver
ivacld/tamserver.tivoli.com
5.2.5 Automatic provisioning

Identity Manager provides the capability to automatically provision accounts
when a user is created. Organization Roles can be set up so that users are
155
dynamically given membership depending on values of user attributes. These

roles can be attached to a provisioning policy that has Access Manager
entitlements, which are automatically provisioned. When setting up the
entitlements as part of creating provisioning policy, automatic entitlement can be
specified.
An entitlement can specify only group membership, which can be used to
automatically add a user to an Access Manager group when that user becomes a
member of a given Organizational Role.
5.2.6 Delegated user administration

The Access Manager Web Portal Manager (WPM) provides capabilities to
support delegated administration. Customers can use WPM to create delegate
domains and give administrators of these domains control over the user
management of those domains. When a domain is created, several administrator
roles are defined so that different types of administrators can manage users in
the domain.
Identity Manager provides similar but more powerful functionality. Using Identity
Manager security domains along with Access Control Information (ACIs) and
Identity Manager groups, delegation hierarchies can be set up with similar
capabilities to the WPM delegated administration domains.
A delegated administration domain has different types of administrators that can
perform different levels of administration. There are four types of administrator
roles defined:
Domain administrators
Senior administrators
Administrators
Support administrators
Table 5-1 on page 157 describes what capabilities each administrator has using
the WPM delegate administration support.
156
Table 5-1 Administrator capabilities
Domain
administrator
Senior
administrator
Administrator
Create Sub
domain
Add new
Administrators
Create Users
Modify Users
View Users
Assign users
to
authorization
roles
Change User
Passwords
Support
administrator
In order to enable the same type of administration roles in Identity Manager, ACIs
can be created to specify each of the capabilities listed in Table 5-1. Then Identity
Manager groups can be created for each of the administrator roles, and the
appropriate ACIs can be associated with those groups.
Delegated administration domain example

Here is an example of how to use Identity Manager to set up a delegated
administration domain. Assume that a new business partner, Acme Widgets,
needs access to some of the applications managed by Identity Manager. Some
Organizational Roles have been set up (Acme Widgets Applications), that are
attached to provisioning policies, which will give the user access to the
applications that are needed by this new business partner. Here are the steps
needed to set up a delegated administration domain for Acme Widgets:
1. Create a security domain named AcmeWidgetsDomain.
2. Add the following groups to the AcmeWidgetsDomain with Organizational
Tree Access
a. AWDomainAdministrator
b. AWSeniorAdministrator
c. AWAdministrator
d. AWSupportAdministrator
157
3. Create the ACIs specified in Table 5-2 and attach them to the specified
groups.
Table 5-2 ACI configuration for AcmeWidgetsDomain
ACI - Name
AWDomain
administrator
AWSenior
administrator
AW
administrator
AW Support
administrator
AWSubDomain
AWManageAdministrators
AWCreatePerson
AWCreateTIMUser
AWModifyPerson
AWModifyTIMUser
AWViewPerson
AWViewTIMUser
AWManageRoles
AWChangePassword
4. Put the domain administrator into the AWDomainAdministator group, as

shown in Figure 5-5 on page 159. Once a member of that group, that
administrator can add appropriate administrators to the different administrator
groups.
158
Figure 5-5 Administrative membership configuration
5. For each ACI, the permissions in Table 5-3 on page 160 to Table 5-12 on
page 167 were set.
159
Table 5-3 AWSubDomain settings
ACI
AWSubDomain
Context
Admin Domain
Permissions
Operation
Grant
Remove
Search
Add
Modify
Deny
None
Attribute permissions
Name
Read
Write
All
None
None
Table 5-4 AWManageAdministrators settings
ACI
AWManageAdministrators
Context
ITIM Group
Permissions
Operation
Grant
Remove
Search
Add
Modify
Deny
160
Name
Read
Write
All
None
None
None
Table 5-5 AWCreatePerson settings
ACI
AWCreatePerson
Context
Person
Permissions
Operation
Grant
Remove
Transfer
Deny
None
Search
Restore
Suspend
Add
Modify
Name
Read
Write
All
None
None
161
Table 5-6 AWCreateTIMUser settings
ACI
AWCreateTIMUser
Context
Identity Manager User
Permissions
Operation
Grant
Remove
Deny
Search
Restore
Suspend
Add
Modify
Attribute Permissions
162
None
Name
Read
Write
All
None
None
Table 5-7 AWModifyPerson settings
ACI
AWModifyPerson
Context
Person
Permissions
Operation
Grant
Deny
None
Remove
Transfer
Search
Restore
Suspend
Add
Modify
X
X
Name
Read
Right
All
Grant
Grant
163
Table 5-8 AWModifyTIMUser settings
ACI
AWModifyTIMUser
Context
Permissions
Operation
Grant
Deny
Remove
Search
Restore
Suspend
Add
Modify
X
X
164
None
Name
Read
Write
All
Grant
Grant
Table 5-9 AWViewPerson settings
ACI
AWViewPerson
Context
Person
Permissions
Operation
Grant
Deny
None
Remove
Transfer
Search
Restore
Suspend
Add
Modify
Name
Read
Write
All
Grant
None
165
Table 5-10 AWViewTIMUser settings
ACI
AWViewTIMUser
Context
Permissions
Operation
Grant
Deny
Remove
Search
None
X
Restore
Suspend
Add
Modify
Name
Read
Write
All
Grant
None
Table 5-11 AWManageRoles settings
ACI
AWManageRoles
Context
Organizational Role
Permissions
Operation
Grant
Deny
Remove
Search
X
X
Add
Modify
X
X
166
None
Name
Read
Write
All
None
None
Table 5-12 AWChangePassword settings
ACI
AWChangePassword
Context
Permissions
Operation
Grant
Deny
Remove
Search
None
X
Restore
Suspend
Add
Modify
Name
Read
Write
Password
Grant
Grant
5.3 Separation of duties: resource vs. user management

When managing a security infrastructure, there are administrators that take on
different roles that define their administrative duties. Tivoli Access Manager and
Tivoli Identity Manager provide tools to manage secure access to enterprise
resources. However, the different types of administrators manage different
aspects of the security infrastructure and take on different roles. Tivoli Access
Manager tools can be used to manage the secure access to resources, and
Tivoli Identity Manager can be used to manage users and their access to
resources.
5.3.1 Different types of administrators

Administrators that manage the security of an enterprise perform different tasks
in various roles when they implement the security policy of a company. One
security administration role is that of setting up a company's security policy.
Administrators in that role determine what resources need to be protected, and
what groups of users would need access to those resources. This type of
administrator, the security policy administrator, does not know which users get
access to resources, so he would determine which types of users get access to
resources, and would set up resource access lists or security roles to protect
167
those resources. A second security administration role would be identity

management. An administrator performing tasks in that role would deal more
with day-to-day activities, would create user identities, and give users access to
resources. That category of administrator may not understand how to set up the
resource security policy, but would know what resources are available, and how
to give users access to those resources.
When managing users and resources using Tivoli Identity Manager and Tivoli
Access Manager, different interfaces are available for the two administration
roles described. A security policy administrator would use the Access Manager
Web Portal Manager (WPM) to manage protected resources, and to create
access control lists (ACLs) with appropriate groups on the ACLs. The groups
would represent the different types of users that need access to resources. Once
this policy is set up, then that administrator would also create the appropriate
Identity Manager organizational roles, and provisioning policy to represent the
different groups, setting up the Identity Manager environment for the user
management administrator. The user management administrator would use the
Identity Manager interfaces to create user identities, Access Manager accounts,
and put users in Identity Manager organizational roles that are attached to
provisioning policy with entitlements to Access Manager groups, thus giving
them access to Access Manager protected resources.
5.3.2 Resource management

Tivoli Access Manager Web Portal Manager (WPM) is a Web-based application
that is used to manage Access Manager resources. Access Manager also has
the pdadmin administration utility, which also provides a full set of Access
Manager management tasks, but only provides a command line interface. WPM
provides tasks to manage all Access Manager objects used to implement
security policy, such as groups, the protected object space, ACLs, action groups,
protected object policies (POPs), and GSO Resources. WPM also provides the
capability to manage Access Manager users and groups. These capabilities,
along with the WPM delegated administration support, should not be used in
favor of using the equivalent Identity Manager functionality. Identity Manager
provides a unified capability to manage Access Manager users along with other
types of user accounts. If WPM is used to manage the user aspect of Access
Manager, then the full power of Identity Manager cannot be realized. WPM also
allows users to be assigned to Access Manager groups; Identity Manager should
also be used to manage Access Manager groups so that Identity Manager can
keep track of which users are in which groups.
168
5.3.3 Identity management

Tivoli Identity Manager can be used to manage identity information for Access
Manager users. Using Identity Manager, administrators can create an Access
Manager account as part of an Identity Manager users identity information. Once
associated with an Identity Manager user, the Access Manager account can be
managed along with other identity information. Operations can be performed on
the account, such as password management, including keeping the Access
Manager account password synchronized with the Identity Manager user
password and other account passwords. Identity Manager can be used to put
Access Manager users in Access Manager groups, giving Identity Manager
users access to protected resources.
5.4 Integration with Tivoli Access Manager WebSEAL

Two different aspects of integration need to be considered when using Access
Manager WebSEAL. One feature that Identity Manager can help manage is the
WebSEAL capability to insert LDAP tag value pairs into a Web interaction.
Another scenario that needs to be considered is when WebSEAL is protecting
the Web server that Identity Manager is using as a GUI server.
5.4.1 Managing LDAP attributes used by WebSEAL

WebSEAL has a feature that enables dynamic business entitlements, also
known as tag/value support. This feature allows entitlement data to be included
in a user credential so that the data can be used later for an access control
decision. This entitlement data can be pulled out of LDAP where it is stored in the
form of attributes on the person object associated with the Access Manager user.
The person object can be extended to add additional attributes to implement
company specific entitlements.
Identity Manager and Access Manager maintain their own person objects in the
directory. Since Identity Manager allows the management of person attributes on
the Identity Manager user object, a combination of Identity Manager, Access
Manager, and IBM Directory Integrator (IDI) can be used to manage these
entitlements through the Identity Manager interface, as depicted in Figure 5-6 on
page 170.
169
Identity
Manager
WebSEAL
IDI
dc=com
o=tivoli,c=us
TIM Person
TAM Person
Figure 5-6 IBM Directory Integrator integration
An IDI assembly line can be set up to first synchronize the entries in the Access
Manager person object from the Identity Manager person object. Any
synchronization should only occur from the Identity Manager object to the
Identity Manager object. Identity Manager can use attributes to trigger
provisioning operations, so Identity Manager person attributes should only be
managed by Identity Manager. Once all of the Identity Manager and Access
Manager user objects are synchronized, a second IDI assembly line can be set
up to dynamically watch for changes in the Identity Manager person objects, and
synchronize that data with Access Manager. See the IDI product documentation
on how to set up assembly lines.
5.4.2 Setting up Web single sign-on

A common architecture used by many customers, is to have a protected area
within their network called the DMZ, where firewalls are used to control access
from the external Internet to the internal intranet. The Access Manager for
eBusiness component for this purpose is WebSEAL. The only access inside the
DMZ would be to the WebSEAL reverse proxy server, which would control any
access to the internal Internet. Identity Manager may be set up inside the internal
170
intranet, with WebSEAL controlling access to the Identity Manager GUI. When
users access WebSEAL for the first time, an Access Manager authentication is
required (for example, the Access Manager account user ID and password is
entered).
With this type of setup, it would be nice to have single sign-on (SSO) enabled, so
that an administrator only enters a user ID and password once.
In setting up an SSO environment between Access Manager WebSEAL and
Identity Manager, steps are required to customize Identity Manager and to set up
WebSEAL.
Customizing Identity Manager for SSO

In order to customize Identity Manager for SSO with WebSEAL, a custom logon
interface is needed to integrate WebSEAL as a single sign-on provider to Identity
Manager. To find out more about single sign-on providers, look at the document
"Integrating enRole with a Single Sign-On Provider" in <ITIM install
directory>/extensions/doc/singleSignOn/single_sign_on.doc.
Identity Manager has an example in the examples directory that can be used to
enable SSO, which is found in <ITIM install
directory>/extensions/examples/singleSignOn/accessmgr.
To customize Identity Manager for SSO, the following steps need to be taken:
1. Set up the Access Manager agent and Identity Manager provisioning policy to
create Access Manager accounts, and synchronize the user IDs so that the
Access Manager user ID is the same as the Identity Manager user ID. This
step is described in the above sections.
2. Compile the sample Java classes.
3. Create the logoff JSP files.
4. Register the customized servlet, and modify the Identity Manager
configuration files.
5. Restart WebSphere.
Compile the example

To compile the examples, first navigate to the single sign-on example directory.
In order for the build scripts to work correctly, the siteminder directory must be
deleted, or moved to another directory.
The next step is to edit the build.bat file, which is in the examples directory
(<ITIM install directory>/extensions/examples).
171
The script variables should be set to reflect where different code is installed.
Here is an example of possible values:
set JAVA_HOME=C:/WebSphere/AppServer/java
set WAS_HOME=C:/WebSphere/AppServer
set ITIM_HOME=C:/itim
Before compiling, edit the <ITIM install

directory>/extensions/examples/singleSignOn/accessmgr file and check line 98,
and, if needed, change:
if ((userid != null) {
return userid;
}
to
if (userid != null) {
return userid;
}
Once these values are set, execute the build.bat command from the examples
directory. The output class files are put into <ITIM install
directory>/extensions/examples/lib.
From there, the appropriate classes can be put into a jar file to copy into the
Identity Manager directories. To create the itamauth.jar file, execute the following
from the lib directory:
jar cvf itamauth.jar examples/authentication/* examples/singleSignOn/*
Copy the jar file itamauth.jar into the Identity Manager application directory under
WebSphere. It will be in $WAS_HOME/installedApps/enrole.ear/enrole.war.
Edit the
$WAS_HOME/installedApps/enrole.ear/enrole.war/META-INF/MANIFEST.MF
file.
Add the jar file itamauth.jar to the Class-Path.
Create the Logoff JSP File

The example handles logoff in a very simple manner. An alternative method of
handling logoff would be to log the user out of Access Manager. In order to do
this, the user would have to be redirected to the WebSEAL /pkmslogout URL.
Example 5-2 on page 173 shows a sample JSP file, redirectlogout.jsp, which can
be used to redirect the user.
172
Example 5-2 Log off JSP file

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<jsp:scriptlet>
session.invalidate();
</jsp:scriptlet>
<HTML>
<HEAD>
<%@ page import="javax.servlet.http.*, javax.naming.*,
javax.rmi.PortableRemoteObject, java.rmi.RemoteException" %>
<%
String dest_url = request.getParameter("dest_url");
if( dest_url!=null &&
!request.getHeader("iv-user").equals(request.getParameter("orig_user")))
{
HttpSession session1 = request.getSession();
session1.setAttribute("dest_url",dest_url);
}
%>
<FORM NAME=logout METHOD=POST ACTION="TBD">
</FORM>
<SCRIPT LANGUAGE=JavaScript>
if(
"<%=request.getHeader("iv-user")%>"!=
"<%=request.getParameter("orig_user")%>")
{
document.logout.action = document.location.protocol + "//" +
document.location.host + "/pkmslogout";
}
else
{
document.logout.action = "<%=dest_url%>";
}
document.logout.submit();
</SCRIPT>
</HTML>
</BODY>
</HTML>
Copy this file into the Identity Manager application directory under WebSphere. It
will be in $WAS_HOME/installedApps/enrole.ear/enrole.war.
Register the servlet

The new servlet that was compiled from the single sign-on directory is called
ExternalLogonServlet. The code for that servlet is in the itamauth.jar file, and the
servlet must be registered with WebSphere before it can be recognized. The
following file must be modified:
$WAS_HOME/installedApps/enrole.ear/enrole.war/WEB-INF/web.xml
173
The following stanzas should be added:


<servlet>
<servlet-name>ExternalLogonServlet</servlet-name>
<description>
Custom Logon Servlet
</description>
<servlet-class>
examples.singleSignOn.ExternalLogonServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ExternalLogonServlet</servlet-name>
<url-pattern>/custom_logon</url-pattern>
</servlet-mapping>

This enables the custom_login URL to access the ExternalLogonServlet.
Modify the Identity Manager configuration

The Identity Manager configuration is stored in the $ITIM_HOME/data directory.
Two files must be modified. The first file, enRoleAuthentication.properties, must
be modified to specify a new authentication provider. This file can be copied from
the examples/authentication directory. The line that is modified is:
enrole.authentication.provider.simple=\
factory=examples.authentication.ExternalProviderFactory
which sets the simple authentication to use the example authentication provider.
This effectively turns off the Identity Manager native authentication so that
WebSEAL authentication can be used.
The second configuration file from the same directory is ui.properties. This file
needs to be modified to use the new redirectlogoff.jsp file for logoff and timeout.
Here are the appropriate lines that should be changed:
# URL for logoff
enrole.ui.logoffURL=redirectlogout.jsp
enrole.ui.timeoutURL=redireclogout.jsp
Restart WebSphere and test changes

At this point, WebSphere and the Identity Manager should be restarted. This will
pick up the changes made. To test the change, access the URL:
http://machine:port/enrole/custom_logon
174
That should go to the change password page, with user ID null. Next, try:
http://machine:port/enrole
This should go to the logon screen, where a user ID can be entered, for example,
itim manager, and no password. The logon should be allowed.
Create WebSEAL junction

To create a WebSEAL junction, use the pdadmin command. Here is a sample
command that creates a junction:
pdadmin> server task webseald-server1 create -t tcp -h blast.dev.tivoli.com -p
80 -c iv_user -j /tim
This creates a junction in WebSEAL that forwards the name of the logged in user
as iv_user in the HTTP header. The ExternalLogonServlet will read the iv_user
name from the header, and set up a user context for an Identity Manager user
with the same user ID. This means that the user IDs must be kept in synch.
Assuming that WebSEAL is running on server1.acme.com, the Identity Manager
GUI should be accessed through the URL:
https://server1.acme.com/tim/custom_login
Enable script filtering on the WebSEAL server

We also need to enable script filtering on the WebSEAL server by changing the
webseald.conf configuration file. Change the script-filtering parameter from no to
yes:
[script-filtering]
script-filter = yes
5.5 Access Manager for Operating Systems

Since Access Manager for Operating Systems (AMOS) uses base Access
Manager functionality, Identity Manager can manage Access Manager for
Operating Systems users as well. Access Manager for Operating Systems users
are the same as Access Manager users. However, Access Manager for
Operating Systems has an additional requirement that Identity Manager can help
to manage. Access Manager for Operating Systems requires that the Access
Manager user ID or short name be synchronized with the user's UNIX user ID or
short name where Access Manager for Operating Systems is running.
175
5.5.1 Managing Access Manager accounts in sequence with UNIX

In order to manage the Access Manager accounts with the corresponding UNIX
accounts, the following steps are recommended:
Create an identity policy that will apply to the Access Manager service and to
the UNIX services.
Create a provisioning policy with entitlements that will create accounts in
Access Manager and on the UNIX machines at the same time.
See Identity policy on page 149, which tells you how to create the JavaScript
needed for identity policies. When creating the identity policy for UNIX and
Access Manager accounts, make sure and select the appropriate service types
on the Services tab in the Define Identity Policy task. Actual service instances
can be specified if the identity policy should only apply to specific UNIX
machines.
When creating a provisioning policy for UNIX and Access Manager accounts,
entitlements need to be specified to create the appropriate accounts. There are
several options that can be used to create the proper entitlements. One
entitlement can be created for the Access Manager account, and one for each
UNIX machine. Another option would be to create one for the Access Manager
account, and one for all machines of a specific Target Type. There are target
type profiles defined for each type of UNIX (for example, AIXProfile,
SolarisProfile, and HpuxProfile). The entitlements should be set up to provision
automatically so that when a user is placed, either automatically via filter or
manually, in an organizational role, UNIX and Access Manager accounts are
created automatically for that user.
This concludes the discussion on the integration between Tivoli Access Manager
and Tivoli Identity Manager.
176
Part 2
Part
Customer
environment
In this part, we discuss an identity and credential management business solution
for the Tivoli Austin Airlines corporation, which operates on a worldwide basis.
177
178
Chapter 6.
Tivoli Austin Airlines Inc.

This chapter provides an introduction to the overall structure of the Tivoli Austin
Airlines (TAA) corporation, including its business profile, its current I/T
architecture and infrastructure, as well as their medium-term business vision and
objectives.
Note: All names and references for company and other business institutions
used in this chapter are fictional. Any match with a real company or institution
is coincidental.
179
6.1 Company profile

The Tivoli Austin Airlines (TAA) is one of the major airlines within the continental
United States. It has been in business for 12 years and now operates over 600
daily flights nationwide, with the motto to fly anything, anywhere.
The following sections describe:
The geographic distribution of TAA
The company organization
HR and personnel procedures
Note: The following sections describe the company information relevant to an

Identity Manager implementation and are not intended to be a complete
description of the company.
6.1.1 Geographic distribution of TAA

TAA is based in Austin, Texas, with the corporate head office and the central IT
data center located near the Austin International Airport. TAA further operates
the following three regional centers:
RW
Regional center West (San Francisco)
RA
Regional center Austin (Austin, within the central IT data

center)
RE
Regional center East (New York)
These regional data centers service the IT needs of the region, such as LAN/help
desk support and user administration. The corporate IT staff, such as systems
programmers and developers, are located at the central IT data center.
TAA also runs multiple Customer Service Centers (CSC) in the major airports,
servicing front-office functions, such as ticketing, member lounges, baggage
management, and staff HR systems. The CSC have no local staff, so they
contact the regional centers for technical support.
The TAA sites are:
180
Austin, TX
This is the IT center housing the core IT infrastructure and

staff. It is also the Regional Center for the Austin region
and contains the technical support staff for the Central
region.
San Francisco, CA
This site is the Regional Center for the West region. It

contains the technical support staff for the West region.
New York, NY
This site is the Regional Center for the East region. It

contains the technical support staff for the East region.
Seattle, WA
This site contains a Customer Service Center, is part of

the West region, and is supported by the regional center
in San Francisco.
Los Angeles, CA

the West region, and is supported by the regional center
in San Francisco.
Denver, CO

the Austin region, and is supported by the regional center
in Austin.
St. Louis, MO

the Austin region, and is supported by the regional center
in Austin.
Detroit, MI

the East region, and is supported by the regional center in
New York.
Raleigh, NC

the East region, and is supported by the regional center in
New York.
The geographic distribution of TAA is shown in Figure 6-1 on page 182. The
figure shows the three regions, West, Central, and East.
Chapter 6. Tivoli Austin Airlines Inc.
181
New York
(Regional Center
East)
Seattle
CSC
Detroit
CSC
San Francisco
(Regional
Center West)
Denver
CSC
St Louis
CSC
Raleigh
CSC
Los Angeles
CSC
Austin, TX
IT Center
Figure 6-1 TAA geographic distribution
6.1.2 Organization of TAA

The company is split into four key areas, the three regions and a core services
division. This is shown in Figure 6-2.
Executive
Region
West
Region
Austin
Region
East
Figure 6-2 High-level organization chart
182
Core
Services
Each of the regions is responsible for the operation of the local services in that
region, including customer service, baggage handling, ground services, airport
liaison, and staffing. The three regions have the same structure. The
organization chart for the central region is shown in Figure 6-3.
Region
Austin
Ground
Services
Baggage
Catering
IT
Center
Customer
Cleaning
Airport
Liaison
HelpDesk
CSC01
(Denver)
HR
Tech
Support
CSC02
(StLouis)
Figure 6-3 Central region organization chart
The core services division acts on a company wide scale. It is split into three
departments, Sales, Support, and Flights. Each of these departments has a
number of teams, as shown in Figure 6-4.
Core
Services
Sales
TAAMiles
Support
Marketing
Central IT
DataCenter
HR
Systems
HelpDesk
IT Dev
Flights
Accts
Crews
Maint.
Figure 6-4 Core services organization chart
Each team within a department has a unique business code identifying the team
and its location.
183
6.1.3 HR and personnel procedures

Personnel are managed locally within each region for the regions, and by the
Core Services HR team in Austin for all Core Services staff. The following
procedures apply to personnel management:
When a new employee joins the company, he is added to the HR system. An
e-mail (using Lotus Notes) is sent to the new employees manager
indicating when the person is starting work and his HR details. The manager
determines what types of access each person needs and sends e-mails to
the appropriate support team to create accounts on the systems (for example,
the LAN team creates the NT domain account and the UNIX team creates the
UNIX accounts). When access is granted, an e-mail is sent back to the users
e-mail account giving account details, including their password. As the
support teams are small, there is often a delay of a few days in creating each
account.
When an employee needs additional access to resources, they get their
manager to ask the appropriate support team, via e-mail, for the access. As
with new accounts, the support teams will grant the additional access.
When an employee forgets his password, or has an account locked due to
invalid passwords, he has to call the help desk (either at the regional or
central level). The help desk can reset NT (LAN) and z/OS RACF
passwords and accounts, but UNIX resets need to be referred to the UNIX
support team.
When employees leave the company, they are removed from HR, and
sometimes their accounts are deleted. However, this is not applied
consistently.
Each employee has a jobcode to describe his job role. Some of these are
common across the regions, such as CSC Manager and CSC Administrator.
Some jobs are specific to a team, such as UNIX Sysadm. These job roles and
jobcodes are managed by the central HR team. They rarely change.
When a new employee joins the company, there is some manual provisioning
that must be performed as follows:
All customer facing staff, such as the ticketing agents, air crews, and ground
personnel, need to have uniforms organized. This is normally carried out by
the new employees manager sending an e-mail to the uniform department,
who then contacts the new employee and arranges for fitting and ordering of
uniforms.
All non-customer facing staff, such as the administrative and IT staff, need to
have real estate set aside for them, including desk locations, phone
connection, and filing cabinets. This is normally carried out by the new
184
employees manager sending an e-mail to the local office manager, who

arranges everything.
6.2 Current IT architecture

In this section, we describe the current IT environment at TAA. We cover:
An overview of the TAA network
The recently implemented e-business application
The security infrastructure deployed for the e-business application
The secured e-business initiative architecture
User administration issues
6.2.1 Overview of the TAA network

TAAs central IT data center has implemented a back-end datastore, which is
based on DB2 running on z/OS. They are using an MQ Series infrastructure for
asynchronous transactions between the central IT data center, the CSCs, and
the regional data centers.
The high-level network diagram of TAAs network is shown in Figure 6-5 on
page 186.
185
New York
(Regional Center
East)
Seattle
CSC
T1 (1.54Mbps)
T1 (1.54Mbps)
San Francisco
(Regional
Center West)
Detroit
CSC
Denver
CSC
T1 (1.54Mbps)
St Louis
CSC
T3 (45Mbps)
T1 (1.54Mbps)
T3 (45Mbps)
T1 (1.54Mbps)
Raleigh
CSC
T1 (1.54Mbps)
Los Angeles
CSC
Austin, TX
IT Center
Internet
T3 (45Mbps)
Figure 6-5 The TAA network
The location of firewalls is shown in Figure 6-8 on page 191. All external access
to the TAA network is channeled through the firewalls and routers in Austin.
There are also firewalls between the regional centers and the IT data center, as
well as between the regional centers and the CSCs.
All T1 and T3 links are leased services. TAA relies on the service provider to
ensure the necessary uptime, as agreed in the service level agreement. The
diagram in Figure 6-5 is therefore logical and does not show redundant/standby
links or triangulation of the network. TAA relies on the service provider for this.
TAA uses Lotus Notes as their e-mail system. This application is not available in
the CSC and at the Gate terminals.
6.2.2 TAAs e-business initiative

Most of the business applications have been migrated to a distributed
WebSphere Application Server implementation based on AIX systems, which is
186
located in every regional center. All these systems communicate with the
back-end database through the high-speed network.
The only application that has not been implemented using the WebSphere model
is the Gate Terminal Application. This application runs on a Windows NT based
network on Windows NT terminals in each CSC (that is, the CSC employees
cannot use a browser to access this application). The Gate Terminal Application
uses MQ Series calls to check the appropriate passenger data. Although a risk
assessment has highlighted this MQ area as being in need of some work,
particularly as messages can sit on queues in an unencrypted form, TAA decided
that other risks were of a higher priority.
The implementation of IBM Tivoli Access Manager for eBusiness was important
for phase one of improving security, but it also provides a platform for the future
authorization services, specifically for MQ series, using IBM Tivoli Access
Manager for Business Integration.
The Identity Management Solution will therefore have to be able to provision to
operating systems, for native MQ, and to LDAP, for the IBM Tivoli Access
Manager family, as well as the e-mail system based on Lotus Notes.
6.2.3 Security infrastructure for the e-business initiative

In the past, TAAs application system experienced many unauthorized access
attempts to critical business data. Recently, TAA has deployed a security solution
that implements a centralized access control mechanism enforcing
authentication and authorization of users before they actually access the
applications and critical data via their Web browser. This solution is implemented
based on IBM Tivoli Access Manager for e-business, with the access control
component being WebSEAL.
Note: In this redbook, we omit any detailed description about the IBM Tivoli
Access Manager and WebSEAL solution, because our focus is on the identity
management system. For further details, you might want to consolidate the
following Redbooks: Enterprise Security Architecture using IBM Tivoli Security
Solutions, SG24-6014, Enterprise Business Portals with IBM Tivoli Access
Manager, SG24-6556, and Enterprise Business Portals II with IBM Tivoli
Access Manager, SG24-6885.
A typical user access with WebSEAL controls looks like this:
1. A user in a CSC logs on to the Windows domain specifying his Windows user
ID and password.
187
2. He starts his Web browser and accesses a login page for a specific
application. He logs in with his application user ID and password. A credential
is used for access control by WebSEAL in the regional centers the CSC
belongs to.
3. WebSEAL accepts or denies the login. WebSEAL works as a reverse proxy
between the users Web browser and the application hosting Web server,
controlling whether a user can access the requested resource or not.
4. WebSEALs access control decisions are based on the information held
within the Access Manager Policy Server and an LDAP repository. The Policy
Server stores the access control information used by WebSEAL and
distributes access control information database replicas to all defined
WebSEAL servers, and the LDAP server has the user credential information
assessed on the users login. The Policy Server is located in the Austin site,
but WebSEAL and LDAP replica servers are made available in each regional
center. The LDAP server in Austin is the master server, which can be
modified; the LDAP replica servers are read-only.
Only the Web applications can be secured by WebSEAL using Web user
accounts, but there are other types of accounts necessary to run standard
operations, such as Windows NT/W2K, AIX, and z/OS. These accounts can only
rely on the native operating system security. That is why TAA puts the employees
under an obligation to follow additional security policies to strengthen the levels
of security, such as a periodical password change and other password policies
for all types of accounts.
At the time of implementing this security solution, TAA has started to provide new
Web based customer services (reference of a customers mileage, special
campaign information, and so on) via the Internet. A customers access to their
data is controlled by WebSEAL also.
6.2.4 Secured e-business initiative architecture

Figure 6-6 on page 189 contains only the Austin site, which consists of the
central IT data center, Region Center Austin, and CSC, in order to make it simple.
While there are strong grounds for altering the network topology and firewall
configuration so that the Austin Regional Site is separate from the Austin
Corporate site, the risk assessment carried out once again showed that there
were higher priorities (those addressed by Access Control and Identity
Management) than this internal network topology change. The full existing TAA
topology is shown in Figure 6-7 on page 190
188
Central IT Center
Central IT Center
Region Center Austin
Web
Web
Application
Application
Server
Server
WebSEAL
CSC sites
IBM
z/OS (DB2,
MQSeries)
Customer
F
I
R
E
W
A
L
L
F
I
R
E
W
A
L
L
Access
Manager
Policy
Server
AIX
WebSEAL
F
I
R
E
W
A
L
L
LDAP
Server
Internet
Internet DMZ
Production DMZ
Intranet
application data flow

access control flow
Figure 6-6 Current I/T architecture in Austin
189
Central IT Center
Central IT Center
CSC site

Web
Web
Application
Application
Server
Server
WebSEAL
z/OS
(DB2,MQSeries)
Access
Manager
Policy
Server
Customer
F
I
R
E
W
A
L
L
IBM
LDAP
Master
F
I
R
E
W
A
L
L
AIX
WebSEAL
F
I
R
E
W
A
L
L
Production DMZ
F IREW AL L
Region Center East / West
Web
Web
Application
Application
Server
Server
WebSEAL
LDAP
Replica
Windows
NT/2000
Domain
AIX
Production DMZ
F IREW AL L
Internet
Internet DMZ

access control flow
CSC site
Windows NT/2000
Domain
Intranet
Intranet
Figure 6-7 Current Entire TAA architecture
Ultimately, TAA will aim at segregating the data (DB2 on zOS) and systems
management zones (LDAP, Security management, and so on) from the Austin
Corporate Network. The Austin Regional Network could then further be
separated by a firewall, and be treated exactly as if it were a remote regional
center, even though it is not remote from Austin. Evolving towards this security
best practice also creates further operating gains on the system management
side of the organization and therefore user experience. One possible future for
TAA is shown in Figure 6-8 on page 191.
190
Central IT Center
Central IT Center
Web
Application
Server
IBM
F
I
R
E
W
A
L
L
Customer
AIX
F
I
R
E
W
A
L
L
z/OS
(DB2,MQSeries)
Access
Manager
Policy
Server
LDAP
Replica
WebSEAL
F
I
R
E
W
A
L
L
LDAP
Master
FIREW AL L
Regional Center , West, Central, East

Production DMZ
Web
Application
Server
AIX
WebSEAL
LDAP
Replica
FIREW AL L
Internet
Internet DMZ
CSC site

access control flow
Windows NT/2000
Domain
Intranet
Figure 6-8 Possible future TAA architecture
Undoubtedly, the security solution shown in Figure 6-7 on page 190 contributes
to strengthening the corporate security level and customer confidence using the
Internet over previous architectures. The secure implementation helps build and
maintain a positive company image, but there are other emerging problems,
particularly in the area of identity management.
6.2.5 Identity management and emerging problems

Emerging problems are related to user administration and identity management.
Before we describe the emerging problems in detail, we give an overview of the
current user management.
191
Current user management

TAA uses many different platforms with user accounts in their system. The CSC
staff have their accounts in a Windows domain and the LDAP directory (for
WebSEAL controlled Web application access). The regional center
administrators have their accounts on AIX systems, adding to Windows domains
in their region and the LDAP directory. All these accounts are managed by the
regional center administrators using OS/application-specific interfaces. Windows
domain accounts are created with the NT User Manager, AIX accounts with the
smitty interface, and LDAP accounts with the pdadmin utility shipped with
Programmers and developers in the central IT data center have their accounts
on all platforms in the enterprise, including z/OS. Due to their specific tasks and
influence, they often manage their own accounts with administrative rights, not
the regional administrators. Accounts on z/OS are created using the RACF
interface shipped with z/OS.
Customers accounts are created in the LDAP registry located in Austin. They are
managed by administrators in the regional center Austin.
Emerging problems
As mentioned above, all employees have several types of accounts and they
have to maintain multiple sets of user IDs and password. If an employee forgets
his password, he has to call a regional administrator in order to reset the
password. Especially after the new periodical password change policy has been
applied, more and more password reset requests come to the regional
administrators. The current password reset flow is as follows:
1. A user who wants to reset his password has to use a hardcopy request form
specifying the type of account, account name, and the reason for the reset
request.
2. His manager accepts the request form and signs for approval. In the case of
denial, the request form is returned to the requester.
3. The user faxes the form to his regional center after he gets his managers
approval.
4. An administrator resets the specific account(s) and sends an e-mail to the
user and his manager to inform him about the password reset and his new
temporary password(s).
Too many requests cause regional administrators not to reply immediately and
some employees cannot continue their work because their accounts remain
inaccessible. When a users manager is not available temporarily, the password
reset procedure gets even more delayed.
192
Besides password reset requests, there are other reasons that increase the
administrators workload. Employee fluctuation is a much more common
scenario these days, which brings newly-hired people, laid off employees, staff
changes, and so on. This increases the administrators workload even after
security solutions have been deployed and account types have been added.
Furthermore, the management interfaces for the various types of accounts on the
different platforms are not the same. Administrators have to use specific
interfaces along with account types (smitty for AIX accounts, pdadmin for LDAP
accounts, and so on). There are many complex operations and much more time
is needed for an administrator to learn how to properly use them. In complex
operations, human error is a common problem.
A similar situation prevails in the administration of customer information: requests
for creating their accounts, password reset requests, and so on. Some customers
have already contacted IT management because it takes too much time and
effort managing their account information.
As we have seen, complicated operations prevent regional administrators from
working functionally. This decreases employees and customer satisfaction and it
will lead to an inability to provide sufficient services to the users in a proper way.
TAA has now decided to implement an additional security management solution
focusing on user and identity management. The main objective in this case study
scenario is to use the Tivoli Identity Manager solution.
6.3 Corporate business vision and objectives

TAA has implemented their e-business application system to employees and
expanded their services on the Web to their customers. This system relies on a
Web-based application infrastructure provided by the IBM WebSphere
Application Server and a centralized access control solution using IBM Tivoli
In order to increase the employees productivity and prevent dissatisfied
customers, the user management processes for all the involved platforms has to
be streamlined and opportunities for human errors have to be reduced, if not
eliminated.
The TAA mid-term vision is as follows:
TAA wants to deploy a corporate wide user management system to be
operated efficiently and correctly, following the corporate security policies.
They need generalized information about user management to make plans
for the future to adjust the system to their circumstances change. Also, in
193
order to lessen administrative cost, it is desirable to automate management

operations wherever possible.
TAA already has some systems management functions in place, such as
monitoring system availability and software distribution, which are
implemented based on the Tivoli Framework. An additional user and identity
management system should be implemented with minimum development
cost, making full use of the existing resources.
6.4 Project layout and implementation phases

Based on the corporate business vision, TAA has decided to implement the new
solution in two phases:
1. Building the foundation for an enterprise wide identity management
infrastructure based on IBM Tivoli Identity Manager Version 4.4. See
Chapter 8, Technical implementation: phase I on page 227 for details.
2. Extend and refine the system with customization and workflow automation to
further reduce administrative costs and streamline IT operations. See
Chapter 9, Technical implementation: phase II on page 269 for details.
6.5 ROI study and results

When considering the implementation of a centralized identity management
solution, there are two business drivers that are important: Does the deployment
of the tool mitigate security risk to an extent where the residual risk is acceptable
to the business, and/or does the return on investment (ROI) of the proposed
solution occur in an acceptable time frame?
TAA, therefore, asked for an ROI study to be conducted to assist them in
producing a business case to present to senior management. The business case
was based upon the interview, response, and questionnaire process discussed
in Appendix C, ROI questionnaire on page 385.
In addition to the company profile and information discussed above, TAA
supplied information concerning operational costs, which was factored into the
ROI case along with the costs of software, additional hardware, and deployment
services. When information was not available, the default values supplied by the
ROI tool were used. The tool included some elements of risk analysis and also
looked at the benefits from integration with the existing authentication and
authorization framework (IBM Tivoli Access Manager for e-business) that was
already in place.
194
The decision to move ahead into the implementation phase was taken not only
as a result of the current ROI benefits, but also because of the benefits to future
business-led projects that would no longer need to code complex security
models. This would mean a more rapid deployment of the application (product or
service) and therefore the ability to set a higher margin price, because as the first
entrant to the market, there would, for a period, be no competition.
The results of the ROI study conducted for TAA amounted to a detailed 80 page
report. The executive summary and some other parts of the report are shown in
the following sections.
Executive summary
Tivoli proposes the implementation of a business impact management solution to
help the organization achieve its strategic goals. The implementation of this
solution requires an investment of $1,863,830 total three year investment.
As a result of this investment, the organization is expected to realize savings and
business benefits of $870,330 over the next twelve months, and $4,460,962 total
over the three year analysis period. Comparing these benefits to the investment,
the recommended solution has a return on investment of 139%, and net present
value (NPV) savings of $1,986,406. The initial investment is recouped with a
payback period of 15 months.
Strategic Business Initiatives

The analysis of the company's business needs uncovered the following Strategic
Business Initiatives:
Risk Management
Goal 1: Reduce security risks by ensuring the application of Corporate

Security Policies concerning Identity Management.
Quality of Service
Goal 1: Reduce the waiting time for password resets for users, thus
improving user satisfaction.
Goal 2: Integrate the non-IT provisioning system (uniform, desks, phones,
and so on) with the IT user account provisioning system to ensure better
responsiveness.
IT Best Practices
Goal 1: An administrator should have access to only the resources

needed, not to all systems.
Goal 2: An administrator may be able to self administer their accounts, but
should do so through a centrally fully audited system.
195
Goal 3: Local resource changes should be detected and be subject to the

same security controls as those carried out directly on the centralized
identity management system.
Strategic Advantage
Goal 1: TAA must become customer Web enabled. This includes the use
of automated identity management that enables new business initiatives
to be integrated without new identity solutions being required.
Goal 2: Costs of customer identity management must be driven down in
order to reduce overhead and improve margins.
To address these Strategic Business Initiatives, the following Tivoli Solutions
were selected:
IBM Tivoli Identity Manager
IBM Tivoli Access Manager for e-business (already in use)
ROI analysis
Table 6-1 compares the investment costs for the Tivoli solution with the savings
and business benefits. Financial analysis examines the projected cash flow over
three years to calculate ROI, NPV savings, and payback period.
Table 6-1 ROI analysis
ROI analysis
Initial
Year 1
Year 2
Year 3
Total
Total Adjusted
Costs
$528,000
$606,038
$359,280
$370,512
$1,863,830
Total Adjusted
Benefits
$0
$870,330
$1,659,405
$1,931,227
$4,460,962
Cumulative
Adjusted
Costs
$528,000
$1,134,038
$1,493,318
$1,863,830
Cumulative
Adjusted
Benefits
$0
$870,330
$2,529,735
$4,460,962
Net Benefit
($528,000)
$264,292
$1,300,125
$1,560,715
Cumulative
Net Benefit
($528,000)
($263,708)
$1,036,417
$2,597,132
196
$2,597,132
ROI analysis
Initial
Three Year
Net Savings
$2,597,132
Net Present
Value (NPV)
$1,986,406
Internal Rate
of Return (IRR)
121%
Return on
Investment
(ROI)
139%
Payback
Period
(Breakeven)
15 months
Year 1
Year 2
Year 3
Total
ROI analysis graph

The ROI analysis graph shown in Figure 6-9 on page 198 illustrates the
cumulative investment cost versus the cumulative savings and business benefits
over the three year analysis period.
197
Figure 6-9 ROI Analysis graph showing 15 month cross-over point
Important: Other factors taken into consideration for this ROI study were a
simplified risk analysis and financial measures, such as internal rate of return.
The cost of the software selected was calculated using the current IBM
Passport Advantage rules for the US. As with any Passport Advantage
Pricing figures, they are dependant upon a number of factors, including an
organizations current discount band. The software pricing for TAA should not
therefore be viewed as applicable to your organization. For a full ROI study,
including a current pricing assessment using up to date figures and metrics,
you should contact your local IBM Tivoli Account Manager.
198
Chapter 7.
Identity Management design

In this chapter, we describe the business requirements, functional requirements,
security design objectives, and design aspects for an identity management
foundation based on Tivoli Identity Manager.
There are essentially two phases to most implementations: phase I, which
concerns deployment and simple customizing, and phase II, which adds extra
value by more advanced customization and automation of the solution.
Implementation details are found in Chapter 8, Technical implementation: phase
I on page 227 and Chapter 9, Technical implementation: phase II on page 269.
TAA decided to use the two-phase approach, so as to gain some ROI advantage
early in the project and then to implement further savings once they have proven
the basic implementation.
199
7.1 Business requirements

Tivoli Austin Airline Inc. has implemented their e-business system with
Web-based technology and an Access Manager based access control
architecture. They have discovered that there are some emerging problems, as
described in Chapter 6, Tivoli Austin Airlines Inc. on page 179.
7.1.1 Phase I
From the vision and objectives presented in 6.3, Corporate business vision and
objectives on page 193, the CEO emphasizes the following four business
requirements for phase I of the project.
All administrative operations related to user management, including user
creation, modification, deletion, and password reset, need to be executed
momentarily in order to minimize any latency times for internal users as well
as customers.
The corporate security policy should be enforced for all user accounts and
their attributes, access rights, and password rules. No user account
inconsistent with the policy should be allowed.
The user management historical data has to be available from a
corporate-wide perspective in order to verify whether the system works
according to the guidelines and policies. These logs can help understand
shortcomings and implement future improvements.
The existing system resources should be utilized as much as possible and the
new identity management system should be implemented with reasonable
new investments.
There are several hidden details behind each of the four phase I business
requirements. The functional requirements in 7.2, Functional requirements on
page 201 take a closer look at those details.
7.1.2 Phase II
Tivoli Austin Airlines has secured their e-business applications by implementing
Tivoli Access Manager to secure the Web interfaces and by implementing Phase
I of the Identity Management project to consistently manage users and their
accounts. TAA now wants to enhance this infrastructure, to gain more benefit
from it.
The business requirements for phase II are:
Further reduce the costs of administering users and their passwords. The first
Identity Manager project has made significant administration cost savings by
200
providing employees the tools to manage their personal information and

passwords. The CEO is keen to gain further cost savings by reducing the
amount of work the administrators still have to do. The areas identified where
savings could be made include:
The effort required to manually create accounts when a person joins the
company
The effort required to add new accounts (and remove old accounts) when
an employee changes job roles
Improve audit compliance. TAA recently had an external audit performed and
a number of areas were seen to be lacking:
Many employees have access to systems that they should not because
they:
Changed job roles and retained access from their old job role.
They are friends with the system administrators and were granted
special access without any form of independent check or review of the
request.
They have left the company, but their accounts have not been deleted.
There is no reporting available to verify security compliance.

As these two requirements were seen to be interrelated, it was decided to
address the two in a single project.
The aim of this phase is to configure the Identity Manager implementation to
meet these two business requirements.
7.2 Functional requirements

For Phase I of the project, we extract functional requirements by tracing the
objective --- reason tree in Figure 7-1 on page 203, which starts with the four
business requirements above (numbered I.1, I.2, I.3, and I.4).
7.2.1 Extracting Phase I functional requirements

Let us examine every objective, and search for reasons and the functional
requirements.
OBJECTIVE I.1: Identity management should be executed momentarily and
correctly.
The main problems in this area are the increasing password reset requests
that have to be handled by the administrators (I.1-a1 in Figure 7-1 on
Chapter 7. Identity Management design
201
page 203) and that the management operation itself is very time consuming
(I.1-a2).
After implementing a central security solution for access control and applying
a new security policy for passwords, a user has to maintain multiple accounts
with different passwords (I.1-a11), which he has to change more frequently
than before (I.1-a12). This, as a result, causes too many password reset
requests. If a user has a single password for his multiple accounts (A),
password maintenance becomes easier.
Not all administrative tasks need to be executed by the same level of
administrator. Many tasks can be delegated according their security level
(I.1-a13). For instance, password resets do not require a high security
clearance as long as we can see its operation flow within the logs. A
password reset can be delegated to people other than administrators, even to
a user itself. Delegation is a contribution to alleviate the administrative
workload (B).
User management operations themselves are time consuming and skill
intensive (I.1-a2) because different management interfaces necessary for
each type of account are hard to handle and need much time for
administrators to master (I.1-a21). Administrative productivity could be
enhanced by utilizing a common interface to manage different types of
accounts centrally (D). A user friendly interface (C) would be an additional
relief.
Another major problem lies in the manual administrative operations (I.1-a22);
often, recovery work is needed for operational mistakes (I.1-a23). When
accounts are created or modified, it is convenient for attribute values common
to all or some of the accounts to be entered automatically (E), and it is also
convenient if there is an automatic function to verify values that are entered
by manual or automatic operations (F). Adding to it, it is preferable that some
business processes are automated, such as sending an e-mail to a user or to
a manager for approval (G).
The final problem of objective 1 is founded in the hardcopy request forms. It
would be desirable for a series of operations (from creation of request form,
through operation of approval, to notification of requests completed) to be
handled digitally and integrated into the user management system (H).
202
OBJECTIVE I.1:
Identity management should be
executed momentarily and
correctly.
REASON I.1-a:
Administrators can not fulfil tasks
in proper time.
I.1-a1:
Too many password reset
requests to administrators.
I.1-a11:
A user has many different
passwords for his acounts.
I.1-a12:
Passwords should be changed
periodically for the company's
security policy.
I.1-a13:
Almost all administrative tasks
are executed by administrators
with any security level.
I.1-a2:
It is time consuming to manually
manage user data or to execute
requests.
Functional
requirements
A : A single password for
user's accounts.
B : Delegate low-security
administration tasks to
others including end
users.
C : User-frendly interface.
I.1-a21:
Different interfaces for every
type of accounts.
D : Central common
interface.
I.1-a22:
Values are entered manually
by administrators.
E : Common values are

entered automatically.
I.1-a23
Often, operations need to be
redone because of mistakes.
F : Value checking
function is required.
G : Automate business
processes.
REASON I.1-b:
It may take more time to get a
manager's approval.
I.1-b1:
When manager is not in the
office, he can not approve it.
I.1-b11:
Hard copy request form.
H : Integrate business
processes into user
administration system.
Figure 7-1 TAA functional requirements part I.1
203
OBJECTIVE I.2: The corporate security policy should be enforced for all
accounts.
Accounts sometimes have attributes that do not correspond with the

corporate security policy (I.2-a in Figure 7-2 on page 205) because attribute
types and the ways of setting them differ depending on account types (I.2-a1),
and because all or some of them are set manually (I.2-a2). Furthermore,
there is no verification function for entered values.
If an enterprise wide user management is available, administrators can apply
the corporate security policy to those attributes without having to realize
differences between account types (I). If there are some common values
between users, such as password length or invalid password retry count,
automatically entered values contribute to decrease manual mistakes (J). In
addition, verification functions can prevent creation of user accounts with
invalid values (K).
OBJECTIVE I.3: Corporate-wide user management data has to be available
for verification and future improvements.
In the current system, account information is scattered all over the corporate
systems (I.3-a). It is not easy to understand how many user accounts are
being used in the enterprise, at what rate they are growing, and when the
system should be expanded due to increasing account numbers, and so on.
The information is indispensable for verifying the current system and for
making future plans to expand it. A central logging system can provide this
information (L).
OBJECTIVE I.4: The existing system resources should be utilized and new
implementation should be reasonable.
The existing resources should be utilized in order to minimize new

implementation costs (M).
204
OBJECTIVE I.2:
The corporate security policy
should be enforced for all
accounts.
REASON I.2-a: Accounts with

invalid attribues may be created
by mistake.
Functional
requirements
I.2-a1:
Every type of account has a
different way of definition.
I : Centrally cross-wide
user management.
I.2-a2:
Manual operations may cause
invalid values.
J : Common values are

entered automatically.
V2-a3:
No value-checking function.
K : Value checking
functions are needed.
OBJECTIVE I.3:
Corporate-wide user management
data has to be available for
verification and future
improvements.
REASON I.3-a:
User information is scattered over
the enterprise, such as on every
LDAP server, every AIX machine,
and so on.
I.3-a1:
There is no integrated logging
system.
L : Central logging system

is needed.
OBJECTIVE I.4:
The existing system resources should
be utilized and new implementations
should be reasonable.
REASON I.4-a:
Existing investments in Tivoli
Framework system, WebSphere
solution, and Access Manager for
e-business system.
M : Integration with
existing systems.
Figure 7-2 TAA functional requirements part I.2, I.3, and I.4
205
Phase I functional requirements summary

The extracted functional requirements are summarized here. The letters in
parentheses correspond with the letters in Figure 7-1 on page 203 and
Figure 7-2 on page 205.
Implement a cross-platform user management and centrally perform
password synchronizations and password resets (A, D, I, and M).
Centrally control business and security policies for users. Reduce identity
management effort through configurable automation of administrative
processes through default and validation policies (E, F, J, and K).
Delegate necessary administration along organizational or geographic
boundaries (B).
Automate user life cycle management by integrating it into the existing
business processes (G and H).
Provide ubiquitous management interfaces, such as Web browsers (C).
Leveraging identity data (L).
7.2.2 Phase II
For phase II of the project, we extracted the functional requirements by using an
objective --- reason tree, as we did in phase I. We have not included the
detailed tree, but the results are shown below
OBJECTIVE II.1: Reduce administrative costs:
Further reduce the costs of administering users and their passwords. Phase I
of the Identity Manager project has made significant administration cost
savings with the tools used to manage employees personal information and
passwords. The CEO is keen to gain further cost savings by reducing the
amount of work the administrators still have to do. The areas identified where
savings could be made include:
The effort required to manually create accounts when a person joins the
company.
The effort required to add new accounts (and remove old accounts) when
an employee changes job roles.
The functional requirements derived from this business requirement are listed
in Table 7-1 on page 207.
206
Table 7-1 Functional requirements for business requirement 1
Requirement
Title
Comment
II.1A
Minimize data entry on user

creation in Identity Manager.
User definition in Identity Manager can be simplified

by using a default policy to automatically generate
user attributes.
II.1B
Automatically create accounts

based on the job role when a
person is employed.
The accounts a user requires is based on their job

role, so creating a user in a job role can be tied to
automatic account creation.
II.1C
Automatically grant access to

systems/applications based on
job role when a person is
employed.
The allocation of accounts to system/application

groups/profiles determines the access a user will
have on systems.
II.1D
Automatically send e-mail to

provisioning teams.
When a new user is added to Identity Manager, the

appropriate e-mail should be sent to the uniform
department for customer facing staff and to the
location manager for non-customer facing staff.
II.1E
Automatically add new

accounts and remove old
accounts when a user changes
job role.
Configure auto account generation so that when a

user changes to another job role, the new accounts
are automatically created and the old accounts are
automatically removed.
These requirements are consolidated in 7.2.3, Summary of functional

requirements on page 208.
OBJECTIVE II.2: Ensure audit compliance:
Improve audit compliance. TAA recently had an external audit performed and
a number of areas were seen to be lacking:
Many employees have access to systems that they should not because
they:
Moved job roles and retained access from their old job role.
They are friends with the system administrators and were granted
special access without an form of independent check or review of the
request.
They have left the company, but their accounts have not been deleted.
This is addressed with the first implementation of Identity Manager.
There is no reporting available to verify security compliance.

The functional requirements derived from this business requirement are listed in
Table 7-2 on page 208.
207
Table 7-2 Functional requirements for business requirement 2
Requirement
Title
Comment
II.2A

their job role.

user changes a job role, the new accounts are
automatically created and the old accounts are
II.2B
Implement approval process for

changes of job role and
associated accounts.
Ensure multiple levels of approval to ensure all

account changes are appropriate.
II.2C
Implement approval process for

changes of job role and
associated OS/application
groups/profiles.

access changes are appropriate.
II.2D
Integrate password policy with

NT domain password changes.
Integrate the NT domain password mechanism with

the Identity Manager application so password
changes in the NT domain are cascaded up to Identity
Manager.
II.2E
Define audit reports for audit

compliance.
Define and build the audit reports.
These requirements are consolidated in 7.2.3, Summary of functional

requirements on page 208.
7.2.3 Summary of functional requirements

Some of the requirements from the previous sections overlap. The consolidated
list of requirements is shown in Table 7-3. The requirement numbering has been
changed to identify the unique requirements.
Table 7-3 Consolidated phase II functional requirements
Requirement
Title
Comment
Minimize data entry on user

creation in Identity Manager.
User definition in Identity Manager can be simplified

by using a default policy to automatically generate
user attributes.
Automatically create accounts

based on a job role when a
person is employed.
The accounts a user requires is based on their job

role, so creating a user into a job role can be tied to
automatic account creation.
208
Requirement
Title
Comment
Automatically grant access to

systems/applications based on
a job role when a person is
employed.
The allocation of accounts to system/application

groups/profiles determines the access a user will
have on systems.
Automatically send e-mail to

provisioning teams.
When a new user is added to Identity Manager, the

appropriate e-mail should be sent to the uniform
department for customer facing staff and to the
location manager for non-customer facing staff.

their job role.

user changes a job role, the new accounts are
automatically created and the old accounts are
Implement approval process

for changes of job role and
associated accounts.

account changes are appropriate.
Implement approval process

for changes of job role and
associated OS/application
groups/profiles.

access changes are appropriate.
Integrate password policy with

NT domain password changes.
Integrate the NT domain password mechanism with

the Identity Manager application so password
changes in the NT domain are cascaded up to
Identity Manager.
Define audit reports for audit

compliance.
Define and build the audit reports.
These requirements define part of the scope for phase II.
7.3 Security design objectives

With the business and functional requirements defined, we are now ready to
document some of the Security design objectives.
While business and functional requirements are the main parts of the security
design objectives, we also have to consider other issues, for example, objectives
that are necessary to meet the general or business requirements, or practical
constraints on constructing security sub-systems. These may include high
availability, performance/capacity issues, ease of distribution of smart cards and
so on. Because we focus on the security architecture of identity management
209
with Identity Manager software in this book, we do not look in detail at all of these
constraints.
7.3.1 Security Design Objectives: general concepts

Security design objectives and associated subsystems become the basis for the
conceptual architecture and therefore the implementation phase.
When we define security design objectives, we must realize that such a project is
first done to reduce the management cost; however, well organized identity
management will also give key benefits to the security team.
The primary Security Design Objectives for identity management are:
Keep a central repository of user identities among all the systems
As all the systems have different ways of constructing IDs, tracking a user
within a heterogeneous IT centric system is difficult.
A central repository able to match IDs to users quickly allows investigations
and control in an efficient way.
When combining this with a central auditing and reporting system, it can
consolidate information easily per employee.
Provide system independent capabilities
Operating systems and applications are built with different capabilities in

terms of security. Some offer password aging, other password patterns or
account aging, and so on. These capabilities are all useful, but not common to
all platforms.
A central tool can handle these matters and enforce security, meaning that all
the systems receive a common set of policies that are enforced from the
central system.
Use standard access templates
By creating templates, the access needed can be matched to the users

profile, so the implementation time is reduced and the risk of error is less, as
the number of manipulations is reduced.
Any subsequent change to this template, such as addition of a system or a
change to a system, is propagated to all the existing users automatically.
Provide quick deletion and locking
In a heterogeneous environment, deleting and locking a user is a hard task.

When an account must be terminated or locked for security reason, manual
intervention on all systems take a lot of time and can be incomplete if not
performed automatically. However, this kind of task requires quick
intervention.
210
Strictly speaking, the next few design objectives are not solely within the scope
of identity management alone, but are examples of Security Design Objectives
that have an impact on identity management.
Access Control
Protect access to systems, applications, and data. Enforce and control

their usage.
Provide access control to new online administration interface.
Enforce strict access control to new management systems and prevent
unauthorized access attempts.
If required, restrict access to users from authorized networks.
Authentication
Allow different authentication mechanisms and allow selection for

individual systems or applications.
Allow simple user authentication with passwords.
Provide stronger authentication mechanisms on request, for example
support of RSA SecurID tokens and basic usage of PKI certificates.
Integrity
Allow consistent administration of users and systems.

Avoid undocumented servers.
Make sure that documented system settings are consistent with
documentation.
Enforce compliance with business policies.
Enforce security settings for systems and applications.
Auditing
Allow monitoring of user activity and resource usage (systems,

applications, and data).
Allow generation of status and history reports.
7.3.2 Security Design Objectives: TAA specifics

With the business and functional requirements clearly defined, we are now ready
to document some of the most important design objectives for a security solution.
The design objectives can be classified as functional-related, for example,
derived from the functional requirements, and non-functional, for example, the
other design objectives. The functional-related objectives can be mapped to the
security common criteria.
211
Phase I
In this section, we define the Security Design Objectives that are specific to
phase I of the TAA project.
Identity management
All accounts related to a user are managed in the central repository.
When users change location in an organization, all of their accounts are
moved to proper machines and their access rights are changed. In order to
simplify this operation, users are made into groups with the same
organization or common attributes, and moving group membership gives
them the necessary accounts and access rights.
User management tasks are delegated to other administrators, managers, or
users in response to the security level of a management task. For example,
administrators of one regional center can manage only users in the region,
not users in other regions. A manager of one division can do some
administrative task on users in that division. Some operations, such as
password reset, are dedicated to a user.
If the created user accounts have common attribute values, those values are
entered automatically upon creation by an attached default policy in order to
save time and prevent human error. All values of the account attributes can
be checked by validation policies if necessary (this can also be done in phase
II).
Identity management can be done by using a common ubiquitous interface,
which can be accessed through a Web browser (hereafter known as the Web
interface). Administrators, managers, and all users can use it for user
management.
Password management
Users can have a single password for all of their accounts, or they can have
different passwords for multiple accounts.
When a user changes the single password for all the accounts, the user uses
the Web interface to do it. User who are not administrators are only allowed to
access their own information.
Users have to log on to the Windows domain before accessing the Web
interface. If their Windows password expires, they change the password
locally, which cause inconsistency between the accounts. To avoid this
situation, a password change operated locally on a Windows machine
synchronizes all the other accounts passwords (this can also be done in
Phase II).
Administrators can reset the passwords of the users they manage.
212
When users forget their passwords, they can reset them through the Web
interface. The user is authenticated by answering some confidential
questions. The users define the answers in advance.
Policy management
When a user sets the password for his accounts using the Web interface, the
password strength is checked against the corporate security policy and OS
and application specific rules, such as length of passwords, the number of
numeric letters included, and so on.
When a new user or a new account is created, a certain number of common
values between users are entered automatically by the default policy.
When a new user or account is created, or an existing user or account is
modified, the entered values are checked against the validation policy.
Business process management

Some of the business processes are automated. If a user needs to have his
account created on a particular machine, or he needs to reset an invalid
password, a request is automatically sent to his manager, and the operation
needed for creation or reset is automatically executed after a managers
approval.
Audit management
All operations for user management are logged centrally. Gathered log entries
are extracted along with what we want to see.
Phase II
In this section, we define the Security Design Objectives specific to phase II of
the TAA project. They build on phase I objectives above, and in addition, there
are also a number of non-functional objectives that relate to the project.
Identity Management
The additional Identity Management objectives for phase II are:
When a person is employed, they are added to the Identity Manager system.
New users should be created with minimal input from the administrators. The
design must allow for automation, in the form of a default policy that is used to
reduce the number of attributes that need to be specified when creating a new
user. All other required attributes are derived automatically based on the
entered data. This derivation of attributes is based on common standard
attributes, which may include department, team, location, and job code.
When defining a new user to Identity Manager, the accounts and access that
the user needs to do their work should be automatically created. The design
must allow for the automation of account creation and OS and application
213
group membership. This is done by associating the accounts for a new user
with the appropriate OS and application groups and profiles. The accounts
and access rights each user should receive may be based on their job code,
department, and team.
When a user changes their job role and/or team, their access requirements
change. The design must allow for the automatic removal of accounts
associated with the old job role and creation of accounts associated with the
new job role. Where an account is common to both old and new job roles, the
design must ensure that the account is carried over.
Password management
The first Identity Management project had a number of password management
related design objectives. The additional objectives for this project are:
The design should impose corporate security policy password standards to all
identities (users and accounts) managed by the Identity Manager solution.
The design should incorporate integration with the Windows NT password
integration mechanism available with Identity Manager 4.4.
Policy management
The first Identity Management project had a number of policy management
related design objectives, the additional objectives for this project are:
The design should allow for the application of security policy and the
subsequent modification of policy if the company decides to amend their
policy.
The application of this policy should be transparent to the user and only
impact the maintenance of the solution.
Business process management

The first Identity Management project had a number of business process
management related design objectives. The additional objectives for this project
are:
The design should incorporate an approval process for the creation of new
accounts and the allocation of accounts to OS and application groups and
profiles.
The design should incorporate workflow steps to send e-mails to the
provisioning departments (uniform and location managers) based on
department and team.
214
Audit management
There were no audit management related objectives for the first project. In this
project:
The design must address the generation of audit reports, including how the
report is defined, when and how it is run, and where the output is sent.
It should also address the maintenance of the auditing subsystem.
Non-functional design objectives

The non-functional design objectives are those that do not relate specifically to
the functional requirements, but are items that should be addressed in the
design. For this project, these include:
Re-use of the existing Identity Management infrastructure
Standards to be used
Maintainability and configuration management
High availability and disaster recovery
Re-use of the existing infrastructure

The design must allow for the re-use of the existing Identity Management design,
except where it conflicts with the new requirements. Furthermore, as highlighted
in 6.2.4, Secured e-business initiative architecture on page 188, there is a
future project to strengthen the security of the network architecture. IBM Tivoli
Identity Manager must therefore be deployed into the existing architecture in a
way that allows the accommodation of network changes in the future with the
least possible interruption to service.
Standards to be used
Where possible, the design must comply with standards in order to make
subsequent implementation easier, more secure, and audit compliant. Further
details on policies and standards can be found in Appendix B, Corporate policy
and standards on page 377.
Maintainability and configuration management

The design must allow for the maintainability of the system. This may involve
deployment of some form of configuration management methodology and/or
system management tool set.
High availability and disaster recovery

There are no additional requirements for high availability or disaster recovery
over the first Identity Manager project, so the design does not need to be
concerned with these items. It is a good idea to be aware of the potential for
future changes in directory choice and so on.
215
7.4 Design approach

Here we consider how security design objectives can be realized using Tivoli
Identity Manager in the TAA case. Also, we describe the scopes we will
implement in each phase.
As this is a product-centric design based on IBM Tivoli Identity Manager Version
4.4, the approach involves mapping the functional requirements to the product
features, or identifying areas of customization where the requirements cannot be
met. The design objectives provide a direction for the mapping and they give
guidance on what needs to be addressed in the design.
The approach for this project is to review all current business information that
relates to the functional requirements and map these to the Identity Manager
components and their configuration.
In building the design, the following tasks need to be performed:
Review the existing Corporate Security Policy document and extract the
policies relating to password management. This defines the password policy.
Review the existing job roles in the organization and for each one:
Identify the systems and applications that an account is required on. This
defines the auto-account generation mapping for each job role.
For each of these accounts, identify the account attributes and any logic
that can be applied to automatically generate the attributes. This defines
the default policy to be applied to the accounts in a job role.
For each of these accounts, identify the OS and application groups and
profiles that the account should be a member of. This defines the group
allocation policy for the job role.
Identify the approval requirements for people in that job role. Who should
approve changes? This defines the approval model for the job role.
Review the existing organization structure and map the job roles to teams and
departments. This identifies any patterns that can be applied to auto account
generation and policy that may simplify the design.
Review the departments and teams and define each as customer facing or
non-customer facing. This is used for the provisioning workflow design.
Review the existing audit compliance procedures and map to Identity
Manager. Identify the reporting required of the product.
Once these tasks have been performed and the information gathered, the
solution can be designed.
216
The remaining sections of this chapter present the design solution for this
project.
7.5 Implementation architecture

The aim of this section is to take the logical and physical architecture aspects of
the solution in relation to the TAA project. Chapter 3, Identity Manager
component structure on page 61 provides useful guidelines for an Identity
Manager solution as a whole.
7.5.1 Logical components

TAA has already deployed IBM Tivoli Access Manager for eBusiness and the
components that are part of this package combined with IBM Tivoli Identity
Manager, are shown in Figure 7-3 on page 218. The new Identity Manager
components that are depicted on the right side of the chart are further described
in this section.
217
Exisiting Environment
General IT Systems
New Environment
IBM Tivoli Access Manager
End Users
Reverse Proxy
Supervisors
Administrators
Centralized Authentication
Browsers
W ebSEAL
Web User Interface
Security Policy Server

Application
LDAP (Replica)
LDAP (Master)
LDAP
Database
W orkflow
Database
O/S
Applications
RDBMS
User Repositories
Service
Legend
LDAP (Master)
Authentication
flows
Applications
Data
Flows
Provisioning Agents
O/S
RDBMS
LDAP
Replication
Figure 7-3 TAA logical components
Web user interface

This interface provides all types of users with the ability to connect to Identity
Manager through a Web browser. Figure 7-4 on page 219 shows an example of
this interface. There are three main areas,
Menu Bar
218
This area contains the tabs that allow a view of IBM Tivoli
Identity manager to be displayed. These are HOME, MY
ORGANIZATION, PROVISIONING, SEARCH, REPORT,
CONFIGURATION, and HELP.
Action buttons
These buttons are displayed in response to the Menu bar

item selected.
Main Area
The results area of the screen shows the necessary

information and further functions in context. This context
is dependent upon Menus and Buttons and also the
security or delegation level for the user.
As you can see, this is a Web browser interface that can be customized. End
users therefore do not need training. A familiarization period or process is all that
is required.
Menu Bar
Action
Buttons
Figure 7-4 Web user interface example screen
Application
The IBM Tivoli Identity Manager application is, in simple terms, responsible for
tying together the other components (Web user interface, Workflow database,
219
LDAP directory, and its service layers). Based upon WebSphere Application
Server, the application provides all the functionality required for an identity
management solution and presents this to the user through the graphical user
interface (Web server and Web browser). Changes to user information are
pushed/pulled to and from the LDAP directory by the application layer, and other
operational information, such as workflow to do lists, are exchanged with the
database. Communication with the target platforms is handled through the
service layer under control of the application.
LDAP
There are three types of LDAP directory shown in the logical component diagram
(Figure 7-3 on page 218). In that diagram, they are labelled LDAP Database,
LDAP (Master), and LDAP (Replica). Both the LDAP (Master) and the LDAP
(Replica) are part of the logical components within the IBM Tivoli Access
Manager architecture deployed at TAA. For the purposes of this design, the
LDAP (Master) can be regarded as a user repository, and the LDAP (Replica) as
out of scope for Identity Manager, as it is controlled entirely by IBM Tivoli Access
Manager. The component labelled LDAP Database is the LDAP directory used
by the application layer of IBM Tivoli Identity Manager to store all user repository
data. This is not the only possible architecture, particularly if IBM Directory
Integrator were also in the solution, but for a medium sized organization without
metadirectory functionality, it is the most elegant and therefore the most cost
effective.
Note: This discussion of LDAP directories holds true for IBM Tivoli Identity
Manager Version 4.4.x. It is Tivolis stated intention to increase the existing
level of integration between IBM Tivoli Identity Manager and IBM Tivoli Access
Manager and also between IBM Tivoli Identity Manager and IBM Directory
Integrator in the future. This and some other elements of design and planning
should therefore be scrutinized if IBM Tivoli Identity Manager Version 4.5 or
later is being considered.
Database
Although it would be possible to hold all information and data needed for the
operation of the application layer within an LDAP structure, LDAP directories are
designed to be read-intensive data structures. Other information, particularly that
which is write-intensive, is therefore placed directly into this database so that it is
available in a timely fashion, and also so that it does not adversely affect the
performance of the LDAP directory.
Service
The service layer is the layer that the application layer uses to interface with the
agents and therefore the user repositories within the identity management
220
domain. While this area is vital for the planned IBM Tivoli Identity Manager
implementation, it is also a key integration point with IBM Directory Integrator.
TAA could already use this layer to integrate with IBM Directory Integrator using
unpublished APIs, but has decided to create a future meta-directory project to
allow for identity management to be implemented first. This is sensible, as it
allows for the deployment of IBM Directory Integrator, through the service layer,
to create a true Meta-directory onto a well managed environment, thus speeding
up deployment and reducing time to value.
Note: It is Tivolis stated intention to review and change (if necessary) the
un-published set of APIs. These will be published to allow the integration
between IBM Tivoli Identity Manager and IBM Directory Integrator to be fully
supported.
Agents
Agents receive their instructions from the service layer and are responsible for
translating add, change, delete, and other requests into actions on the target
repository.
TAA has decided to deploy agents for the most important user repositories rather
than 100% coverage in the first instance. This allows them to gain as much
advantage as possible (both in terms of ROI and improved security) early in the
project. It is possible to deploy to any repository, even those not out of the box,
through the use of a number of techniques. TAA has decided to review the
progress after six months in production have passed, to decide on whether and
how to implement the remaining user repositories (for example, those in bespoke
applications). Because of the existing involvement of IBM Tivoli Access Manager,
the use of IBM Tivoli Identity Manager, and the possible future use of IBM
Directory Integrator, the choice of various agents and methods is wider than in
an Identity Manager-only environment.
Authentication
Once again, because of the involvement of IBM Tivoli Access Manager for
e-business, the authentication process is slightly different from the one normally
used in a stand-alone deployment of IBM Tivoli Identity Manager. Instead of a
direct connection to the Web user interface and authentication against the LDAP
database component, the request to the Web user interface is intercepted by the
centralized authentication component. This is, in practice, a combination of
firewall and local Web server. The reverse proxy component then authenticates
the user against the security policy server and its underlying LDAP (replica). If
the authentication is successful, a certificate is generated, and the reverse proxy
uses this to encrypt communications and handle sessions between itself and the
user and between itself and the requested resource (in this case, the Web user
221
interface to IBM Tivoli Identity Manager). The use of IBM Tivoli Access Manager
strengthens the underlying security model, and it is also important in a
deployment where delegated identity management is opened to administrators
outside of the control of TAA, such as partner organizations.
7.5.2 Physical components

IBM Tivoli Identity Manager Version 4.4 can be deployed in two different types of
physical layout: single server and clustered. These are discussed in full in the
IBM Tivoli Identity Manager Server Installation Guide for Windows V4.4,
SC32-1148. For clarity, they are briefly outlined here.
Single server
Despite being called single server, this model consists of two servers. The first
contains the LDAP database on DB2 while the remainder of the components are
installed on the second server. It is called single server because the version of
WebSphere that is loaded onto the second server is the single server edition.
Cluster
In contrast to the single server layout, this model contains a number of servers,
and is based upon WebSphere servers in a cluster with one or more underlying
directory/database servers.
TAA has selected the single server model and their selection is based on a
number of considerations:
Lower cost: hardware and deployment.
High availability requirements are less than those for other components of the
security architecture (for example, WebSEAL).
Future inclusion of IBM Directory Integrator may warrant a review of the
model.
The customer registration load is small enough when compared with internal
identity management requirements.
Directory server
The following logical components are placed on this server:
LDAP database
This functionality is provided by loading the following components:

IBM DB2
IBM Directory Server
222
Identity Management server

The following logical components are placed on this server:
Web user interface
Application
Workflow database
Service layer
This functionality is provided by loading the following components:

IBM DB2 (IBM admin client option)
IBM Tivoli Identity Manager, which as part of the installation, also loads the
following components:
IBM WebSphere Application Server

IBM MQSeries
Agents
Most agents are usually placed on the same platform as the user repository. This
does not necessarily have to be the case, and within the TAA environment, the
Windows NT PDC agent is a good example. Within TAA, the Windows NT agent
can be placed so as to be tolerant of promotion of the BDC to replace a failed
PDC.
Network topology and firewall settings

TAAs policy to rely upon IBM Tivoli Access Manager for e-business as a
centralized authentication and authorization architecture reduces the network
configuration impact and improves the security of the identity management
solution. The firewalls do not need to provide any extras, because only
HTTP/HTTPS protocols are involved in the Identity Manager implementation. Let
us take a closer look at some of these details.
Network topology overview

Figure 6-7 on page 190 shows the current state of the TAA Network. TAA
understands that it could be better and is looking at changing it as part of a
separate network review and refresh project. In the current design, there are
essentially five areas. These do not correspond to the five areas shown in
Figure 3-7 on page 74, but the five areas overlap with three of the areas in the
original diagram. This overlap is shown in Figure 7-5 on page 224.
223
Intranet (CSC)
Internet
Internet DMZ
Central IT Center
Production
DMZ (Region)
Uncontrolled
Zone
Controlled
Zone
Trusted
Zone
Restricted
Zone
Restricted
Zone
Internet
Internet DMZ
Intranet
Production
Network
Management
Network
LESS SECURE
MORE SECURE
Figure 7-5 Current TAA network zones mapped to network security model
Communication protocols
The following ways of communication between components is used:
End user (Web browser) to WebSEAL reverse proxy: HTTP, HTTPS, and
HTML
WebSEAL reverse proxy to Identity Manager application: HTTP, HTTPS, and
HTML
Application to LDAP Directory: TCP/IP and LDAP (SSL)
Application to agents: HTTP, HTTPS, and DAML (DARPA Agent Markup
Language)
The IBM Tivoli Identity Manager Tivoli Access Manager Agent for Windows
Installation Guide V4.4, SC32-1165 also mentions the use of ftp. In the interests
of security, TAA has decided to follow the recommendations in the guide and not
use ftp. IBM Directory Integrator also allows the use of ftp. TAA has determined
that if it makes sense to use ftp at a later stage, then they will consider securing
this protocol using the IBM Tivoli Access Manager for Operating Systems. For
the time being, ftp is not being used for the project.
Firewall settings
Within the current TAA environment, application communication traversing
firewalls is largely under the control of IBM Tivoli Access Manager, because it is
based on HTTP and HTTPS. Access Manager WebSEAL acts as a single point
of authentication and authorization for the IBM Tivoli Identity Manager Web user
interface. As the placement of both the Identity Manager server and the Directory
224
server is within the central IT Center, all other communication crossing firewall
boundaries use the HTTP/HTTPS ports already open for use by WebSEAL.
The final physical architecture is depicted in Figure 7-6.
Central IT Center
Central IT Center

Web
Web
Application
Application
Server
Server
WebSEAL
Access
Manager
Policy
Server
Customer
F
I
R
E
W
A
L
L
Identity
Manager
Server
CSC site
Directory
Server
z/OS
(DB2,MQSeries)
WebSEAL
IBM
LDAP
Master
F
I
R
E
W
A
L
L
F
I
R
E
W
A
L
L
Production DMZ
FIREWALL
Region Center East / West
Web
Web
Application
Application
Server
Server
WebSEAL
LDAP
Replica
Windows
NT/2000
Domain
AIX
Production DMZ
FIREWALL
Internet
Internet DMZ

access control flow
CSC site
Windows NT/2000
Domain
Intranet
Intranet
Figure 7-6 Final physical positioning of the two identity management servers
225
226
Chapter 8.
Technical implementation:
phase I
This chapter describes several aspects of the first phase implementation of IBM
Tivoli Identity Manager at Tivoli Austin Airlines. It discusses the basic
implementation of the following IBM Tivoli Identity Manager components or
aspects:
Organization tree
Services
Policies
Provisioning policies
Identity feed and HR synchronization
Administrator and user access
Each of these sections discuss the following details:

Requirement: What should be considered before designing a solution
Design consideration: What are the possibilities and options available for that
design.
TAAs implementation: How it was done in TAAs implementation.
227
8.1 TAAs requirement

TAAs requirement for this phase of deployment are described in 7.3.2, Security
Design Objectives: TAA specifics on page 211. Many of the goals stated are
solved by the basic functionality of IBM Tivoli Identity Manager, but some of the
goals require proper configuration to adjust their behavior. The following goals
require special configuration efforts:
User management task should be delegated to administrators.
Common account information should be provided.
Single password for all account.
Challenge response mechanism should be placed for the users.
Password should be checked for length and composition.
These are the basic issues that are addressed throughout this chapter, and in
some cases, new constraints and requirements are presented in each section.
8.2 Initial steps

Before any real design can be implemented, some issues should be addressed.
First, the product should be installed and configured for basic operation. It is also
helpful to have a naming convention in place to make names clear and unique.
8.2.1 Initial install and configuration

The initial installation involved installing and configuring the following
components:
LDAP for IBM Tivoli Identity Manager
DB2 database server for IBM Tivoli Identity Manager
IBM Tivoli Identity Manager (and all its prerequisites)
Agents for each of the target platforms (this also involves getting all the
certificates for the agents)
Note: The LDAP used by IBM Tivoli Identity Manager has to be secured using
proper access control implementation to avoid unwanted access to some of
the sensitive information it contains.
228
Once the software components are installed, the following basic configuration
has to be done:
Test connectivity to all agents
Configure IBM Tivoli Identity Manager for challenge response
Ensure that all components are working
The agents cannot be completely tested until several additional configurations

are completed. Reconciliation should only happen once services are defined in
their correct place on the organization tree. Services cannot be transferred, so if
all the accounts associated with a particular service have to be deleted, then the
service is deleted as well. This can be avoided only by doing a reconciliation after
the service is in its definitive place. Reconciliation also yields better results if the
identities are already created and their aliases are defined correctly; this allows
the reconciliation process to associate the identities to the accounts.
8.2.2 Naming considerations

There are several object types present in IBM Tivoli Identity Manager. Since
many of them are placed along the organization tree, there is a chance for
identical names appearing in many places. To minimize confusion, it is important
to consider a naming convention that allows users to easily determine the
following:
What kind of an object it is
Position on tree (rough idea)
Other information about the object
Name case is not relevant, since all the objects are stored in the LDAP directory,
which is case insensitive. However the same schema ideally should be used
throughout the entire solution.
In TAAs case, the name is composed in the following form:
[type(subtype)]+orgtree+name
The type(subtype) is a prefix that identifies the object type and in some cases the
subtype (used mostly for services). Some examples of prefixes are shown in
Table 8-1 on page 230. The next part (orgtree) should allow readers to determine
roughly where the objects are placed in the organization tree.
Chapter 8. Technical implementation: phase I
229
Table 8-1 TAA naming convention: object type prefixes
Object type prefix
Object
serv[type]_
Specifies the name of a service. Each

Service profile has its own name. Thus,
an AixProfile would have the name
servaix_ as a prefix.
pp_
Provisioning policy
role_
Role
pwp_
Password policy
idp_
Identity policy
ssp_
Service selection policy
aci_
Access control information
wf_
Workflow
ad_
Administrative domain
ig_
IBM Tivoli Identity Manager group
Here are some examples:
pwp_basic
Basic Password policy
servaix_wr_srwr01.west West regions AIX service, targeting machine

srwr01.west.taair.com
servnotes_notes01
Notes service targeting Notes on machine

notes01.taair.com
role_center_CSCUser
Role of CSC users of the Center region
Not all objects have a description that can be used alongside the name, so in
some cases it may be necessary to add a more descriptive name after the object
prefix. Also, identities should be named according to the way administrators
expect to see the information; normally, the identities names will be adequate.
8.3 Organization tree

The organization tree is a key element of the entire IBM Tivoli Identity Manager
design. It provides containers for identities and other objects (such as policies
and services). Various aspects of IBM Tivoli Identity Managers design are
controlled by the object placement in the tree.
230
8.3.1 Requirements
An organization tree normally exists in any organization. It should be considered
the first candidate; however, it is not necessarily the best design. Management
and resource access is frequently handled geographically. So an organization
tree based on the locations may be more useful.
The choice between these two tree designs depend on some other important
information:
Which user should have access to each system?
Is this done by business unit?

Is this done using locations?
Which of these two is more important?
How should a user account be managed?
Local administration?
Central administration?
Business unit specific management?
This information should allow designers to determine which tree should be used
to manage the system. Management is normally more relevant for the tree
design.
8.3.2 Design considerations

The organization tree design is guided by how users should be provisioned and
systems managed; thus, several other aspects must be considered. Several
objects have a scope within the tree, so the tree can influence the behavior of the
following objects:
Provisioning policies (see 8.6, Provisioning policies on page 242)
Password policies (see Password policies on page 239)
Identity policies (see Identity policies on page 239)
Services (see 8.4, Services on page 233)
Service selection policies (see Service selection policies on page 234)
Access control information (see 8.8, Administrator and user access on
page 260)
Access control information defines how users and administrators can view and
manage information. Understanding the design alternatives for each of the
objects above is critical for a good organization tree design. The policies have a
231
resolution scope: they can either affect one container in the tree or that container
and all its children.
In some cases, it is interesting to create services in an Admin Domain. The
Admin Domain are special containers: they can hold anything, just like other
regular containers. The main difference is that the domain may have several
administrators while a regular container can only have one supervisor.
8.3.3 TAAs implementation

The primary driver for the organization tree design is how administration will be
done. Going through the requirements, there are some key goals to be achieved:
Administrators of one regional center can manage only users in that region
A manager of one division can do some administrative tasks on users in his
division
Users in the CSC and Regional Centers log on to local Windows NT domains
There are two basic ways to design the organization tree: one is based on
business units or division, and the other is based on location. In TAAs case, the
resources utilization and administration is based on locations, so the most
natural approach is to have a location based tree. Figure 8-1 shows the proposed
organization tree.
Tivoli Austin Airlines
Corp
HQ
W est
RC
LA
CSC
Center
RC
Seattle
CSC
Denver
CSC
East
RC
St Louis
CSC
Detroit
CSC
Raleigh
CSC
Figure 8-1 Proposed organization tree for TAA identity management
Corporate headquarters is placed in the same level as the regional offices. The
reason for this is that, from a provisioning perspective, they are different, and
policies should be applied to them in specific ways.
232
Identities are placed in each location according to the persons function and
location. That means CSC containers hold all people of that CSC. Region
containers have the regional staff. Flight crew are in the Corp structure.
Figure 8-2 shows the initial organization tree based on the tree shown in
Figure 8-1 on page 232. Notice that the order is alphabetical. This could be
solved by placing a prefix to order the field, but there is little benefit from this
action. There is also an Administrative Domain (AD_CorpHQ) that was not part
of the original organization tree; this domain was added because of the services
and service selection policies (see 8.4, Services on page 233 for more detail).
Figure 8-2 TAAs organization tree on IBM Tivoli Identity Manager
8.4 Services
Services define what agents are being managed by IBM Tivoli Identity Manager.
Each service profile (or agent type) has its own characteristics, and can require
specific parameters.
233
8.4.1 Requirements
In order to create a good service design, one must know the answers to the
following questions:
What are the target systems?
This is the first information to be obtained. The list of intended systems is

good enough, but there may be special considerations on how IBM Tivoli
Identity Manager agents are deployed for that platform.
How are identities assigned to services?
While most services are unique in an organization, some systems have users
defined according to location. For example, each site may have its own
Windows domain, and users should be provisioned to the site they work in.
How are the services administrated?
Services can be centrally administrated or have distributed administration.

Each method of administration may impose certain requirements in the
service design.

The most important aspect of the services design is where they are located
within the organization tree. This defines how services are managed, and some
of the provisioning policies alternatives. Changing service placement on the
organization tree can have a ripple effect on the entire design, so alternatives
should be carefully tested to avoid having to move services around.
Service selection policies

Service selection policies are used inform which service, of a given service
profile, will be used to provision a given identity. The policy is a JavaScript that
should use the identitys information to find the service best suited for that
identity. Any identity information can be used to inform the service to be used.
One interesting function that IBM Tivoli Identity Manager provides is the
ServiceSearch.searchForClosestToPerson function. It returns the service closest
to the user on the organization tree. This function looks up the tree from the
identitys position to the trees root and returns the first service it finds of that
given service profile. This makes location based provisioning very simple, if the
services are set up correctly.
234
Figure 8-3 shows an organization tree with users and services on it. Using the
ServiceSearch.searchForClosestToPerson function, each user would be
provisioned as follows:
Joe
Service_A, since it is in the same organization unit.
Doris
No service can be found for her. All services are not on

the path between the identity and the organization trees
root (Company organization).
Robert
Service_D; same node on tree.
Vicky
Service_C; there are no services on the organization she

is defined in, but there is one on the organization above
her.
Company
Organization
HQ
Organization Unit
Service_A
DataCenter
Admin Domain
Sales
Organization Unit
Service_B
Manufacturing
Organization Unit
Service_C
Joe
Doris
Assembly
Organization Unit
Components
Organization Unit
Service_D
Robert
Vicky
Figure 8-3 Service selection example
Notice that there is an Admin Domain in the organization tree. This domain is a
container for services, but is not in the path for any user, so Service_B can only
be provisioned if the service selection script uses other criteria to select it. This
allows the isolation of services from the service selection policy.
Service placement
A service can be placed anywhere in the organization tree; this section describes
some of the alternatives. There is no reason to limit your design to those shown
here.
235
All services on organization tree root

Technically, all services could be placed at the top level. One of this designs
advantages is that all services and provisioning policies can be found easily.
However, provisioning policies are not able to use proximity selection
provisioning policies.
This design is ideal for a centrally managed environment. Service selection
policies are not able to use the proximity function.
Placing services in Admin Domains

Admin Domains can be used for several reasons. One interesting aspect of these
domains is that several identities can be assigned as domain administrators.
These domain administrators have a great deal of rights on the services and
other objects in that domain by default. This can make delegated administration
much simpler.
Distribute services throughout the organization tree

Services should be placed on the tree for two reasons: administration and
service selection policies. If service selection policies should assign users to the
nearest service, having the service on different containers in the tree, near to the
users, makes the policy simpler.
Administration of the services and identities may require that services be placed
in a container on the tree (see 8.8, Administrator and user access on
page 260).

TAA has several systems they want to manage:
1. RACF
2. Notes e-mail services at a central location
3. AIX systems in each region and corporate headquarters
4. Windows NT systems in each region and corporate headquarters
5. IBM Tivoli Access Manager at a central location
6. IBM Tivoli Identity Manager at a central location
There are two main provisioning methods. Users are provisioned to the central
systems in a corporate level, and any user in the organization can be provisioned
to these systems.
236
Each of the region centers and headquarters have there own local Windows NT
Domain and AIX system. For these systems, users should be provisioned to the
closest system.
Administration is done by local administrators on the local services. This requires
proper controls be placed on the local resources.
These requirements resulted in a resource placement, as shown in Figure 8-4.
Tivoli Austin Airlines
Corp
HQ
West
RC
Center
RC
East
RC
Data Center
Admin Domain
4
1
RACF
LA
CSC
Denver
CSC
Detroit
CSC
Seatle
CSC
StLouis
CSC
Raleigh
CSC
Notes
Windows
NT
AIX
IBM Tivoli
Access
Manager
IBM Tivoli
Identity
Manager
Figure 8-4 Service placement for TAA
Each of the regional centers and the corporate headquarters have their AIX and
Windows NT services. An administration domain is being used to contain all the
global services used. This allows for simple service selection policies to be used.
It also allows the local administrator to handle resources at their location.
8.5 Policies
The various policies in IBM Tivoli Identity Manager define how identities are
mapped to user accounts and their passwords. Policies control default and
required values for account attributes. There are three types of policies:
Identity policy
Specifies what is the user ID for a given person on a

system.
237
Password policy
Determines what criteria the password given must meet in

order to be accepted as a valid password.
Provisioning policy Determines access to a resource, and allowed and default

values of all the attributes in an account (these are
discussed in more detail in 8.6, Provisioning policies on
page 242).
This section discusses how identity and password policies affect the behavior of
accounts.
8.5.1 Requirements
Policies normally derive from the customers security policy and procedures.
Password policies are probably contained in the security policy or are known by
the systems administrators.
Identity policies are a more complex issue. If the customer has some procedures
in place for creating user accounts, they may hint to what is the way user ID are
created. However, the environments current state is frequently a result of years
of evolution, where user IDs have been changing and there are several
standards within the same platform.
IBM Tivoli Identity Manager can handle either manual free form identities or
automated generation. However, automation becomes more difficult if there is no
standard way of generating a user ID. Thus, defining acceptable identity policies
is critical for better results.
8.5.2 Design consideration

Password and identity policies affect services under their scope. They can affect
all services, specific service instances, or specific service profiles. The scope of
the policies dictate what services are affected by that policy.
Placement in the organization tree

Identity and password policies affect the service according to the organization
tree. The policies can have two scopes:
Single
Affect only the current node of the tree.
Sub-tree
Affect the current node and all the child nodes, until a new sub-tree
policy is found.
Figure 8-5 on page 239 shows an organization tree with some policies and
services on it. For simplicity these policies affect all services. Policy_A affects the
entire tree since it is a sub-tree scope policy at the top level. At ou=West there is
238
another policy that has a single scope. This means that Service_A is ruled by
Policy_B (the one on its node) and Service_B is ruled by Policy_A. If Policy_B
had a sub-tree scope, both services would be affected by it.
TAA
Organization
Policy_A (Scope Sub-tree)
CorpHQ
OU
West
OU
Policy_B (Scope single)
Service_A
Seattle
OU
Mike
LA
OU
Service_B
Figure 8-5 Policies scope example
The simplest way to define the policies is to have the organization wide policies
on top and, if necessary, use other policies on the appropriate levels. Notice also
that the policies apply to services and not to identities. Thus, a policy on the
ou=CorpHQ node would have no effect on the services.
Password policies
One immediate benefit of using IBM Tivoli Identity Management is that the
customer can define global password policies for all systems. This requires little
effort and can be a great improvement to the overall security of the organization.
The key issue for designing these policies is its placement. Set up a organization
wide policy on top (even if it is not very restrictive), and then apply specialized
policies where needed.
Identity policies
Identity policies are very important when automation is used frequently, since
they define the user ID in the targets. When all operations are done manually,
239
they are not needed. However, even in these cases, identity policies provide a
default value for the user, which avoids manual inputting.
When creating these policies, the first issue at hand is to discover all the policies
in the environment. As a next step, normalization is important; it may not be
necessary or possible to achieve one single policy. Once all of them are mapped,
it is a question of defining them on the organization tree and writing the
JavaScript.
While having custom policies is not necessary, not having them makes automatic
provisioning much more difficult (since it is not possible to be fully automatic).
Note: Identity policies are needed in order to do any kind of provisioning.

There are default policies, but there must always be a policy in order to
provision accounts.

TAA has two main interests in these policies:
Automate user ID generation to standardize the account in the environment
Ensure a minimal password strength with the new tool
To achieve these goals, they are defining two basic policies at the top level,
which allow them to automate their processes.
Identity policy
Since TAA wants to automate everything possible eventually, they would like to
have policies in place to select the identities on the systems right from the
beginning.
All employees have unique serial numbers used in several applications. On UNIX
and Windows NT systems, there is a large number of users that have chosen
their own names. Newer accounts are always created using a unique name
based on the serial number as part of their build.
TAA has been using this identity pattern in the zOS accounts, and they want to
make it standard in all systems (that allow it). All user IDs have a prefix of the
letter a followed by the employees serial number, for example, a056491.
Customer accounts are part of the account system. For the customers, the user
ID, on the only system they get access to, is their e-mail address.
240
The identity policy used has to be able to distinguish the user and build the name
based on the proper criteria. Example 8-1 shows the JavaScript used in the
identity policy.
Example 8-1 TAAs identity policy
function createIdentity()
{
var jobcode = subject.getProperty("title");
var identity;
var f;
if(jobcode != null && jobcode.length!= 0)
jobcode=jobcode[0];
else
jobcode=null;
if(jobcode == null || jobcode =="JC_CUSTOMER") {
/* This is a customer */
f=subject.getProperty("mail");
if(f != null && f.length != 0)
identity=f[0];
else
return "ERROR no email found";
} else {
/* This is an employee */
f=subject.getProperty("employeeNumber");
if(f != null && f.length != 0)
identity= "a"+f[0];
else
return "ERROR should have emplotyye number";
}
return identity;
}
return createIdentity();
Password policy
TAA decided for a basic and simple password policy that is acceptable on all
systems and yields a reasonable level of security without causing too much
trouble with the end users. The basic requirements are the following:
Have both letters and numbers (minimum of two of each)
Minimum size of six characters
Maximum size of eight characters (to avoid problems with platforms that limit
the size)
Minimum of five unique characters
241
Maximum of two repetitions of the same character

History of three passwords to reduce password reuse
These are the initial values for all platforms. TAA may revise these policies for
specific platforms in the future. This policy alone ensures that better passwords
are used throughout the IT resources.
8.6 Provisioning policies

Provisioning policies define how users should be provisioned to the systems, or
services, as they are called in IBM Tivoli Identity Manager. Each provisioning
policy has the following information:
General information
Several pieces of information about the policy, including:

The scope of the policy defines whether only services of the current
container or all services in the organization tree are affected.
A numeric priority value that defines which policy is more important (the
larger the number, the higher the priority).
Membership
The membership defines which organizational roles are allowed to use this
Entitlements
Defines what the identities being provisioned by this policy will have on the
system. This includes information on what are the default and allowed values
for attributes on the system.
Figure 8-6 on page 243 shows the typical components of a provisioning policy.
The roles referenced by this policy are depicted on the right side of the picture
and the target systems on the left side. In the middle are the provisioning policy
and a service selection policy.
242
Provisioning Policy
Service
AIX
Roles
Tester
values
Default and allowed
De
fau
lt a
nd
all
ow
ed
va
lue
Service
s
Selection
RACF
Provisioning Policy
Priority 1000
taff
NT
co
Ge
Developer
s
ps :
ro u
,G
e
alu
sV
NT
Policy
Figure 8-6 Provisioning policies and service selection
When defining a policy, there are two special roles that can be used:
All
This role applies to every identity in the IBM Tivoli Identity Manager.
Other
This role applies to any identity that has not been used previously in
any provisioning policy for that same service (see Provisioning
policy joins on page 243).
Another element shown on Figure 8-6 is a service selection policy. These are
policies that determine which service will be used for a given identity. They allow
an identitys account to be placed in different services, depending on some
business or administrative purpose. As an example, if each location has an AIX
server, user accounts can be created on the server nearest to the user. This is
achieved using a service selection policy.
Provisioning policy joins

When an account is being created for an identity, the characteristics it will have
on the target system are determined by the entitlement in the provisioning
policies. So if a given user can be provisioned to a system by membership in two
or more different provisioning policies, the actual attributes on the system are
determined by joining all provisioning policies. This is an important feature of IBM
Tivoli Identity Manager.
243
Figure 8-7 shows three provisioning policies that apply to the same service. Each
policy has a different priority. Two attributes are determined by each policy
(shown on the lines from the policies to the service: Login script and Groups. On
the configuration for these attributes, it is stated that Groups are determined by
Union and that Login script is determined by Priority.
Users
Roles
Provisioning Policy
Developer
Developer
Provisioning Policy
Priority 1000
Manager
Manager
Provisioning Policy
Priority 2000
Other
Other
Provisioning Policy
Priority 50
Service
Login script: user.cmd

Groups: Developer
Mike
Login script: mngr.cmd

Groups: Manager
Ana
Chris
Login script: guest.cmd

Groups: Guest
Figure 8-7 Provisioning policy joins
Three users are being provisioned by these policies to the target system. Chris is
a member of the Other group because, in regards to this service, he is not a
member of any other role. The attributes that each user gets on the systems are
shown in Table 8-2.
Table 8-2 Result of the provisioning policy join
Identity
Login script
Join directive: Priority
Groups
Join directive: Union
Mike
user.cmd
Developer provisioning policy
Developer
Ana
manager.cmd
Both Developer and Manager
polices apply, but Manager has a
higher priority
Developer
Manager
Manager provisioning policy
Chris
guest.cmd
Other provisioning policy
Guest
Other provisioning policy.
If the membership in the Other provisioning policy changed to All, all of the
accounts would be members of the Guest group.
244
8.6.1 Requirements
The simplest concept of a provisioning policy is mapping roles to services (target
systems). So to create the provisioning policies, one must know:
What are the services?
What are the roles?
An immediate follow up to these questions is:

What type of access do the roles have to these services?
These are simple questions; however, they are normally difficult to answer.
Unless the organization is highly process oriented and well documented, this
information is not readily available. Trying to determine all this information may
be time consuming, so it may be simpler to determine the high level roles,
services, and access information and progressively refine this information.

Provisioning policies are the keystone that connect services and roles. Several
design aspects can influence the way the policies are created. The simplest
policies involve assigning certain users to a specific well known service. Other
policies require the use of service selection policies to assign identities to a
service.
The provisioning policy design will be influenced by two factors:
Organization tree
Organization roles
Organization tree
The position of the service and the policy will influence the options of the
provisioning policy. A provisioning policy can only provision to services that are
within its resolution scope. This means that a policy that affects only a single
level of the tree can only provision to services on that level, while a policy with a
sub-tree scope can provision to all services from that level and below.
Figure 8-8 on page 246 shows an organization tree with services and policies
attached to it. The service resolution scope implies that each policy can affect the
following services:
Policy_A
All services, because it is at the top level and has a

sub-tree scope
245
Policy_B
Service_B, Service_C, and Service_D, since it has a

sub-tree scope, and those are the services under that
organization
Policy_C
Service_B, as this is the only service at that level and the

policy has a single scope
TAA
Organization
CorpHQ
OU
Service_A
Policy_A
(Scope Sub-tree)
Policy_B
(Scope sub-tree)
Policy_C
(Scope single)
West
OU
Service_B
Seattle
OU
Service_C
LA
OU
Service_D
Figure 8-8 Provisioning policies service resolution scope
The position of the identities in the organization tree do not restrict which
provisioning policies affect that user. So an identity defined in CorpHQ can be
provisioned to Service_C, via either Policy_A or Policy_B, if the policies have
that identity in their membership definitions.
For this reason, the policies could be placed anywhere on the tree and a simple
approach would be to place them all at the top level. However, it may be
interesting to have different administrators controlling the policies, so having the
services and policies in different levels may be required in order to define the
proper access rights (see 8.8, Administrator and user access on page 260).
Organizational roles
While provisioning policies can be designed without organizational roles, these
policies will be extremely broad in reach and can potentially cause security
problems in the environment. Broad scope provisioning policies should be
progressively reduced in scope using roles to defined what rights identities get
on the resources.
246
In order to create restricted provisioning policies, the organizational roles need to

be well defined, along with what these roles are entitled to. Having better defined
roles is critical, but having complete role definitions is time consuming,
considering that number of roles tend to grow exponentially.
One way to handle this, especially in the initial phases of the deployment of IBM
Tivoli Identity Manager, is to begin with high level role definitions, and rely on an
administrator to determine what the users are entitled to. As the solution
matures, roles and provisioning policies should be reviewed to restrict the scope
of the policies, and reduce the amount of information that administrators must
provide.

The first information required for the design of the provisioning policies is the
services that are used by the policies. The following services will be provisioned:
RACF
Notes e-mail services at a central location
AIX systems in each region and corporate headquarters
NT systems in each region and corporate headquarters
IBM Tivoli Access Manager at a central location
IBM Tivoli Identity Manager at a central location
Role Based Access Control is not a primary goal of this phase of the
implementation, so there is no need to create many roles. Table 8-3 shows all the
roles defined in this phase, including the definition rule. The manager role was
created to insure that managers have the proper access to IBM Tivoli Identity
Manager.
Table 8-3 TAAs basic roles
Role
Definition rule
role_employee
(&(!(title=JC_CUSTOMER))
(title=JC_*))
role_customer
(|(!(title=*)) (title=JC_CUSTOMER))
role_manager
(title=JC_*MNG*)
Tip: The definition rules are nothing but LDAP search filters, as defined by
RFC 2254 The String Representation of LDAP Search Filters.
247
With the roles defined, the following policies must be enforced:

Any one with the role_employee role is allowed access to the RACF, Notes,
and IBM Tivoli Access Manager systems.
Any one with the role_employee role is allowed access to the nearest
Windows NT and AIX system (this is done by a service selection policy).
Any one with the role_customer role is allowed access to the IBM Tivoli
Access Manager.
Any one with the role_manager role has access to the IBM Tivoli Identity
Manager with membership to the group_manager group.
All identities have access to the IBM Tivoli Identity Manager and IBM Tivoli
Access Manager.
The resulting provisioning policies are show in Table 8-4.

Table 8-4 TAAs provisioning policies
Provisioning policy
Membership
Entitlements
pp_employee_access
role_employee
RACF
Notes
(member of employee group)
pp_customer
role_customer

(member of customer group)
pp_itim_manager
role_manager

(member of ig_manager group)
pp_basic
All

pp_local_systems
role_employee
AIX service selection policy

Windows NT service selection policy
In this phase, most of the provisioning parameters are not set in the provisioning
policies. For some of the roles, the groups on the target systems have been set.
The roles on this implementation are used to keep customers from being
deployed to the wrong systems.
The last provisioning policy, pp_local_systems provisions users to the system
nearest to them. This is mostly used to provision CSC users to the Windows NT
domains and AIX machine in their Region. Identities in the corporate
headquarters must be provisioned to the local domain. Example 8-2 on page 249
shows the service selection policy that assign the appropriate service for that
user. This policy works effectively because of the way services where created
248
(see 8.4, Services on page 233), since each organization unit has its own
services defined for the local user.
Example 8-2 TAAs basic service selection policy
function selectService() {
var serviceInstance = null;
serviceInstance = ServiceSearch.searchForClosestToPerson(subject)[0];
return serviceInstance;
}
return selectService();
8.7 Identity feed and HR synchronization

Identity feed is a critical part of any deployment. Normally, the identity
management solution is not the authoritative source for identities. In most
companies, the Human Resources department is the best source. Whatever the
authoritative source, it is necessary to get the information from that source to be
fed into the identity management solution.
In IBM Tivoli Identity Manager, this is done by using a special service type called
DSML identity feed. This service provides the means to get data form the
authoritative source into IBM Tivoli Identity Manager. This can be done in two
ways:
JNDI
This is a programmatic approach using the Java Naming and

Directory Interface (JNDI). It requires the coding of Java
programs and provides all operations on the data.
DSML
This is a file approach using the Directory Service Markup

Language (DSML). This is done using DSML files (an XML file)
and loading them. The only operation not supported is the
deletion of identities.
Tip: Although DSML feeds cannot delete any identities, you can suspend
identities with them.
Identity feeds are needed in two different phases. The first one is the initial load
of identities. This is required to load all the users into IBM Tivoli Identity Manager.
The second part is an operational feed, which keeps the provisioning system in
synchronization with the authoritative source of identities.
249
8.7.1 Requirements
The first requirement for any design is finding the authoritative source for the
identities. Probably this will lead to the Human Resources (HR) system, but there
may be more sources, such as systems that manage:
Business partners
Contractors
Customers (including self-provisioning tools)
Next, it is important to determine what information these systems must provide.

There are some minimal requirements for IBM Tivoli Identity Manager:
Common Name (LDAP cn)
Last Name (LDAP sn)
Whatever is part of the distinguished name for the identity (LDAP dn)
Choosing a common way to determine the distinguished name is important to

avoid duplication of identities. Beyond this minimal information, other information
can be added as needed to the policies used in the solutions, such as:
Title or job description
Organization unit
Employee number
Department information
E-mail
Manager
In some situations, many sources may be needed to handle a single identity. For
example, HR gives basic identity information, but contact data comes from
another system. In these cases, a solution such as IBM Directory Integrator can
help the solution. It can help get the bits of information from the various sources
and output them in the proper format for the identity feed.
8.7.2 Using DSML identity feed

DSML is the easiest way to get the feed working. This section provides some
basic information on the DSML feeds in IBM Tivoli Identity Manager. A good
understanding of XML is always helpful.
Basic format
A basic entry DSML identity feed is provided in Example 8-3 on page 251. It
contains all the elements necessary for a feed.
250
Example 8-3 Basic DSML file

<?xml version="1.0" encoding="UTF-8" ?> 
<dsml> 
<directory-entries> 
<entry dn="uid=a234567"> 
<objectclass>
<oc-value>inetOrgPerson</oc-value> 
</objectclass>
<attr name="uid"><value>a234567</value></attr> 
<attr name="sn"><value>Shamway</value></attr>
<attr name="cn"><value>Gordon Shamway</value></attr>
</entry>
</directory-entries>
</dsml>
Some of the lines in the example have some comments that are addressed here:
1. This is a requirement for the XML parser; always use this prefix to ensure
proper parsing of the entire file.
2. This tag defines the document as a DSML document. It is the top level of the
document.
3. This tag defines the document as a set of directory entries; DSML standard
allows the classes of a directory to be defined in the file. This is not needed or
recommended in an identity feed.
4. This tag represents the start of an entry (identity). Each entry must have a
DN; this is used when searching for an existing identity in the directory. If the
identity already exists in the directory, the data in the entry will update those
in the directory. Otherwise, a new entry is created.
5. This part of the entry defines what object class a new entry will have in the
directory. This is needed when adding a user to the directory, but is optional
when updating its information.
6. This line shows a regular attribute; however, in this case, it is also the
attribute defined in the dn of the entry tag. In order to avoid problems, the field
in the dn entry must be defined in the attributes of the entry.
Comments 4 and 6 above refer to an important aspect of the identity feed
procedure. Every object in IBM Tivoli Identity Manager has a unique ID
generated when it is created, including persons. This ID is used as the objects
LDAP distinguished name, and allows all attributes of an identity to be changed.
251
However, this ID is unknown to external users, so the identity feed must have
another way to determine the distinguished name for an entry.
The identity feed distinguished name can be defined to any value and will be
used to check if the entry already exists in the LDAP and to link identities to their
supervisors. However, in order for this to work, whatever is used in the entry as a
dn must also be defined as an attribute when the identity is created.
Tip: When working with identity feed, reconciliation may keep running
indefinitely. Particularly in small test feeds, this may be a signal of some
serious XML syntax errors in the file. Syntactical correct files will not cause
this problem.
Multi-valued fields
Many of the values in the LDAP can have multiple values. This is achieved on the
DSML identity feed using the construction in Example 8-4.
Example 8-4 Multi-valued fields in the DSML
<attr name="ou">
<value>LACSC</value>
<value>WestRegion</value>
</attr>
<attr name="erAliases">
<value>a654321</value>
<value>celis.pale</value>
</attr>
Both the ou and erAliases have several values in this example.
Defining a supervisor
IBM Tivoli Identity Manager allows managers to be defined as supervisors for the
identity. In a DSML identity feed, this is defined by the construction in
Example 8-5.
Example 8-5 Defining the identitys supervisor
<attr name="erSupervisor">
<value>uid=a088515</value>
</attr>
Note that the supervisor value is defined by the distinguished name (dn) used
when the supervisors identity was imported. If the referenced identity cannot be
found, the literal values is stored (if the supervisor is being loaded in the same
252
feed) or an error will occur during reconciliation (if the supervisor is not in the
same feed).
Note: If no supervisor can be found, any workflow that involves a supervisor

will be approved automatically, since the supervisor cannot be resolved.
Updating existing identities

When an DSML identity feed specifies an existing identity (as determined by the
DSML entry dn field) user, all the attributes in that entry will be updated.
However, there is no way of clearing up an attribute, since the DSML
specification requires the existence of some value.
On updates, there is no need to include the objectclass tag. However any
attributes that are necessary for the placement rule must be included. This is
required since the placement rule (see Placement rule on page 253) will be
re-evaluated to determine if the identity must move inside the organization tree.
Not having these attributes may cause the rule to fail and reject the update of that
identity.
8.7.3 Design of the initial identity feed

Identity feeds require careful planning. The procedures are, in themselves,
simple, but if processes are not in place, the synchronization cannot be
maintained over time.
The initial identity feed is the first step in the synchronization process. It should
only happen once, and has to be planned and tested carefully. It is possible to
correct errors afterward, but the cleaner the first feed is, the better.
There are some important issues that have to be thought of before the initial
identity feed:
Placement rule: This is what defines where identities will be placed in the
organization tree.
Initial reconciliations: When going into an existing environment, there must be
a way to assign the existing account to identities.
Placement rule
A placement rule is a JavaScript that is part of a DSML identity feed service
configuration. The rule are used to determine where identities will be placed in
the organization tree. They are checked every time a identity appears in a feed,
both in the insert and update operations.
253
In the update operation, the behavior is as follows:

1. Run the rule, and determine what is the proper placement of the identity.
2. If the identity is in a new placement, transfer the identity to the new place,
including all changes in the identitys provisioning.
This means that whatever fields are used in the placement rule must be present
in all updates to avoid the identity from being moved around on the organization
tree.
The script is executed with the data that was provided in the feed, and it must
return a string representing a directory suffix of the container in the organization
tree (relative to the top of the organization). In the example shown in Figure 8-9,
Mikes identity has to be placed in the Seattle organization unit. To achieve this
task, the placement rule must return a string like:
ou=Seattle,ou=West
TAA
Organization
West
OU
Mike
Seattle
OU
LA
OU
Figure 8-9 Example of placement rule
Note: If the placement rule generates a name that does not exist in the
organization tree, the identity is placed in the top level organization.
Planning for reconciliations and roles

Another important issue that has to be handle by the initial feed is the first
reconciliation. When IBM Tivoli Identity Manager is deployed in a environment
where the accounts are already created, it must associate accounts to identities.
254
This is done by using the aliases in the identity feed. Ideally, all possible aliases
for a given identity must be included in the feed. The more aliases the better, but
it may be impossible to determine all accounts for the users.
Another issue to be considered are roles that may define the provisioning of the
users. The initial identity feed may be used to define the roles of users; however,
if roles are being defined progressively, the role may not have fully developed at
the time of the initial identity feed. Nevertheless, whatever information can be
used to determine roles should be placed in the initial feed.
Generating the initial identity feed files

There is no standard tool to generate the initial identity feed. However, this is not
very difficult and can be done by scripts. Taking in consideration all the
information discussed previously, the following steps can serve as a reference:
1. Determine all the data that will be necessary for roles, provisioning,
placement rules, and the policies.
2. Create the DSML identity feed service with a placement rule.
3. Determine the proper sources for these data.
4. Get the data from the source or sources.
5. Normalize and adjust the data (this is where IBM Directory Integrator can be
helpful).
6. Generate the DSML files (two feeds may be necessary if supervisors are to
be defined).
7. Reconcile the identity feed service.
Testing is important to ensure that all the identities will be loaded correctly.
If a supervisor (or managers) will be used in the provisioning processes, it is
important to define them in the identity feed. The best way to handle supervisors
is to update the identities with the supervisor information once all identities are
already loaded. If the erSupervisor field is included in the first DSML file, it may
be necessary to process the file a second time so that the managers are
correctly defined. However, on large feeds, this may require too much
processing.
As a best practice, load all the identities in one feed, then with a second feed,
define the supervisors for each identity.
255
Note: When doing the initial identity feed, the erSupervisor will only be set
correctly if the supervisor has already been imported into the LDAP directory.
If this has not happened yet, the literal text value of the field will be used. This
is not valid for workflow approvals, and may result in unwanted approvals.
8.7.4 Designing synchronization feeds

Once the initial feed has been done, it is necessary to keep IBM Tivoli Identity
Manager synchronized with the authoritative source of the identities. Although
this could be done manually, an automatic synchronization reduces errors and
allows the system to handle several important events that happen with the
identities, such as:
New people coming into the organization
People leaving the organization
Changes in positions, jobs, or managers
This procedure should be scheduled according to the business needs. This could
be done daily, hourly, or weekly, as business requirements dictate.
Adding new identities

This will happen whenever new people have joined the organization. The same
information used in the initial identity feed should be provided for new identities.
Special care should be taken with the supervisors. Once again, it is important
that a supervisor already be defined so that proper links can be established. But
generally speaking, new identities will have supervisors already defined in IBM
Tivoli Identity Manager.
Modifying identities
Existing identities may have changes in several fields. In this case, whatever
information that needs to be updated must be included in the identity feed. Any
data necessary for the placement rule must be included to avoid placing the
identity in a new position.
Example 8-6 on page 257 shows the update of an identity. Notice that this
includes information for the placement rule (in this case, the ou attribute). There
is also a change in the supervisor.
256
Example 8-6 Changing values of an identity

<?xml version="1.0" encoding="UTF-8" ?>
<dsml>
<directory-entries>
<entry dn="uid=a654321">
<attr name="telephoneNumber"><value>(512)-555-3450</value></attr>
<attr name="title"><value>Big Manager</value></attr>
<attr name="ou"><value>CorpHQ</value></attr>
<attr name="erSupervisor"><value>uid=a010001</value></attr>
</entry>
</dsml>
Suspending identities
The last type of common event that needs to be handled is a person leaving the
organization. There are two ways to handle this:
1. Identity is suspended.
2. Identity is removed.
DSML cannot handle the removal of an identity. This can be done using either a
JNDI update or using a manual deletion procedure.
Suspending an identity is easy using a DSML feed. Example 8-7 shows the
DSML necessary to suspend a user. Simply setting the identitys erPersonStatus
to 1 will suspend it. To restore the identity, set the erPersonStatus to 0.
Example 8-7 Suspending a user via identity feed
<?xml version="1.0" encoding="UTF-8" ?>
<dsml>
<directory-entries>
<attr name="erPersonStatus"><value>1</value></attr>
</entry>
</dsml>

TAA uses the Human Resources system as an authoritative source for the
identity information for the employees. IBM Tivoli Identity Manager policies and
deployment requires that some information be gathered:
Employee managers
257
Employee numbers (used to generate user ID)

E-mail address
Job code (used to determine roles)
Location information (used to determine placement on the organization tree)
Various name information
Social security number (used for initial passwords (as a shared secret))
The fields mapped are shown in Table 8-5.

Table 8-5 Mapping TAA data to DSML
Data
DSML attribute
Comment
Identifier
dn
Use a value of uid=[uid] (see uid

below).
Employee Number
employeeNumber
Used for generating user IDs
Last name
sn
Required
Common name
cn
Created by joining first name and last

name (required).
First name
givenname
For ID purposes
E-mail
mail
For workflow
Job Code
title
The job code has expanded to human

readable values
Manager ID
erSupervisor
Mapped just like the dn of the manager,

used in secondary feed
Social security number
erSharedSecret
Used for initial passwords
Employee number
uid
Assembled using a+[number]
Location code
ou
These have to be mapped from the HR

values to the organization chart
Policy alias
erAliases
Generated using several of the existing

policies and the data in the HR
Example 8-8 on page 259 shows part of the DSML feed, including all the fields
for the first feed. This feed includes all basic identity information, but not the
supervisors. These are handled in another identity feed.
258
Example 8-8 Complete TAA identity entry in the first feed

<objectclass>
<oc-value>inetOrgPerson</oc-value>
</objectclass>
<attr name="sn"><value>Pale</value></attr>
<attr name="cn"><value>Celis Pale</value></attr>
<attr name="givenname"><value>Celis</value></attr>
<attr name="mail"><value>celis.pale@taair.com</value></attr>
<attr name="employeenumber"><value>654321</value></attr>
<attr name="title"><value>JC_CSC_LUGHNDL</value></attr>
<attr name="uid"><value>a654321</value></attr>
<attr name="erSharedSecret"><value>6057140201</value></attr>
<attr name="ou">
</attr>
<attr name="erAliases"> 
<value>a654321</value>
<value>celis.pale</value>
</attr>
</entry>
The identities were placed in the proper container according to the placement
rule shown in Example 8-9. This rule concatenates all the ou provided in the field
into one string. It is a responsibility of the HR feed process to convert the data
into the proper format.
Example 8-9 TAAs placement policy
var orgunit=entry.ou;
var ty=typeof orgunit;
var filt="";
if(ty=="undefined") {
/* Handle undefined placements */
return "ou=CorpHQ";
} else {
for(i=0; i< orgunit.length; ++i) {
if(i==0)
filt="ou="+orgunit[i];
else
filt=filt+",ou="+orgunit[i];
}
}
return
filt;
259
Once the first identity feed was complete, a second feed was generated to
similiar identities to their supervisors. This was done using updated DSML
statements, as shown in Example 8-10. Notice that to avoid moving identities in
the organization tree, the ou field used by the placement rule is present.
Example 8-10 Complete TAA identity entry in the second feed (for supervisors)
<attr name="erSupervisor"><value>uid=a088515</value></attr>
<attr name="ou">
</attr>
</entry>
After the initial feed, the same two basic formats are used to keep the IBM Tivoli
Identity Manager synchronized with the HR system. Every day, a report of all the
changes is made by the HR system. A feed is created from it to create new
identities, modify those that changed, and suspend people that have left the
organization.
8.8 Administrator and user access

Delegated administration and user self-service are key elements in an effective
ROI for IBM Tivoli Identity Management. Delegating administration requires that
proper access controls be used. This is done using access control information
(ACI) in IBM Tivoli Identity Manager.
All IBM Tivoli Identity Manager users have their access to information controlled
by the ACI. They describe what operation can be done on what data, what
attributes are accessible, and by which user (principal). They affect all identity
specific data (user information, organization tree, and accounts) and tool specific
data (services, policies, and so forth). Creating the correct ACI allows for
delegated administration and user self-service.
8.8.1 Requirements
The design is influenced by two things:
What normal users can see and do
Can they manage their password, see information about their accounts,
modify information about their accounts (which information), and request new
accounts?
260
What each type of administrator can do and see
What people can they manage? What information can they see? Can they
create accounts? Can they create identities? Can they delete identities or
suspend and restore them? What account information they can modify? What
identity information can they modify?
Once again, having all this information up front may be difficult, so this can be
done in a progressive manner. Some of the questions above yield enough
information for an initial setup.

All the access control in IBM Tivoli Identity Manager is handled by Access
Control Information (ACI). These objects control what a given user can see of a
certain type of information. This allows for a very fine-grained control on what a
user can see and do.
There are several ways to set user access, and combinations can be employed
in order to get the desired result. It is important to understand how the ACI works
to avoid complex designs.

An ACI will have the following information:
Context
What does the ACI apply to. This includes all objects that exist
within IBM Tivoli Identity Manager (like a person, account,
organization unit, policies, services, and so forth). Only one
object class is affected by an ACI.
Scope
This is the scope within the organization tree that is affected by

the ACI. Like many other policies, the scope can be restricted to
a single node on the tree or to a node and all its children
(sub-tree scope).
Attributes
What attributes of the object can be seen and/or modified by the

principals of the ACI. A user may be allowed to see the attributes
but not edit them.
Operations
What operations the principal can do. Operations are context

specific. For example, accounts have add, remove, search,
suspend, modify, and restore operation capabilities. Services
have add, remove, reconcile, search, and modify operation
capabilities.
Principals
This defined what users are affected by the ACI.
261
The ACIs are described in Chapter 4, Access Control Information of the IBM
Tivoli Identity Manager Policy and Organization Administration Guide V4.4,
SC32-1149.
Scope and context

As described above, scope and context define which objects are being affected
by the ACI. There are, however, some differences. Unlike policies, several ACIs
can affect the same object. This allows for a very flexible control (see Design
options on page 265).
Another important detail to consider is that accounts are associated to identity,
so the account ACI will only allow management of accounts belonging to
identities within the ACIs scope.
ACI operation and attributes

Each ACI defines which operation can be done and, for those operations on that
ACI, what attributes can be read and/or written. However, many ACIs may be
affecting the object, so the final allowed operations are determined by the sum of
the ACIs.
Operations are object dependant, but in general, they allow the following:
Add
Create a new object of that type on the account object; this

allows for new provisioning.
Remove
Delete the object for the account, which means de-provisioning

the account.
Search
This allows the object to be searched for; this operation must be

granted to users if they are to view the object to request any
other operation on them.
Modify
Change the values of the object (if the attributes specific

authorizations allow this).
Suspend
Valid for persons and accounts; allows them to be suspended.
Restore
Value for persons and accounts; reverses the effects of a

suspend operation.
Reconcile
This allows administrators to reconcile services; this also allows

them to see orphan accounts.
Transfer
Move persons around the organization tree.
What users can see of an object is defined by the attribute read grants in the ACI.
If a user can see an object (after doing a search, for example), he is only able to
view any data if some ACI grants read to at least one attribute. This also applies
to the users own data.
262
ACI principals
The principal defines what users have the access rights specified in the ACI.
There are four possible principals:
Self
Each identity has a set of information that belong to it; this includes accounts.
This principal refers to the data that the identity owns in the IBM Tivoli Identity
Manager user. This principal is used to allow users to access their own
information and accounts.
Supervisor
The supervisor principal refers to either the identitys supervisor or the

organization unit (or container) supervisor.
Domain Administrator
This principal refers to the various Admin Domain administrators.

ITIM Group
This principal refers to any IBM Tivoli Identity Manager user group. This
allows users to be placed in a group and have access control set to this
group. This can be used for representing different groups of users not
expressed with the other principals.
Note: The supervisor and Domain Administrator have many rights by default,
so the default right may have to be reevaluated.
Merging ACIs
Frequently, many ACIs affect a given object. The ACI will determine what is the
valid access. Each attribute or operation has three possible states:
Grant
None
Deny
Implicitly, all operation and attributes are denied. An explicit grant will override
the implicit denial, and an explicit denial will override any grant. However, when
attributes are concerned, the only ACI effectively looked at are those that allow
for that operation. This can produce interesting unions.
Figure 8-10 on page 264 shows two ACIs applied to the users own data placed
on an organization tree. Each ACI refers to the users own AIX account data. All
of the ACIs have a sub-tree scope.
263
Corp
Organization
IT
OU
SysAdmin
OU
Ana
ACI_Unix
Context: AIX account
Scope: Sub-tree
Operations: Modify & Search
Attributes:
Shell: Grant Write
UID: Deny Write
All: Grant read
Password: Grant Read & Write
Principal: Self
Mike
ACI_Unix_Admin
Context: AIX account
Scope: Sub-tree
Operations: Add & Modify
Attributes:
Shell: Grant Read & Write
UID: Grant Read & Write
Primary Group: Grant Read & Write
Password: Grant Read & Write
Principal: Self
Figure 8-10 ACI resolution example
The result of the interaction between the ACIs is shown in Table 8-6.
Table 8-6 Result of the ACI interaction
264
Identity
Operation
Attributes
Reason
Ana
Create
View and edit:

Shell, user ID,
Primary Group,
and password
ACI_Unix_Admin is the only ACI that

affect the Add operation, so only what it
authorizes can be viewed and edited.
Modify
View: All attributes

Edit: Shell and
Primary group
In this case, both ACIs are, in effect, for

the modify operation. This means the
user can see all fields. Because of the
ACI_Unix, she cannot change the user
ID (it denies this). The primary group is
authorized by the ACI_Unix_Admin and
not denied anywhere.
Identity
Operation
Attributes
Reason
Mike
Create
Denied
ACI_Unix has no authorization for the

Add operation.
Modify
See all attributes

Edit: Shell and
password
Only these attributes are authorized in

the ACI_Unix.
This is a good example of how the interaction between the ACIs can help
delegate administration. Ana can create a new account, withi much of the
security related information (this would normally be checked by someone else in
a workflow). However, once the account is created, she has a more limited set of
options.
Design options
The design of the administrator and user access mostly depends on how it
should be done. As a base rule, you want to grant the least access necessary for
the administrators. Remember that much of the information concerning identities
may be coming from an identity feed. This means that administrators should
have very little to manage in regards to identities.
Policies may require some special handling of accounts. For example, regulation
may require that account information be kept on file after an employee leaves the
company. In such cases, local administrators should be limited in their access to
accounts.
The first design option depends on how many administrators will be managing a
container on the organization tree. If many administrators handle each container,
there are two possible designs:
Define multiple container Admin Domains.
Create the ACI based on IBM Tivoli Identity Manager groups.
Placement of the ACIs influence their scope, so the organization tree must match
the administration requirements, especially if Admin Domains are used.
Basic administrator access

In order for an administrator to be able to see and manage people on the
organization tree, several configurations have to be made.
First, the administrator has to be part of an IBM Tivoli Identity Manager group
that has access to the organization tree. Without this, they do not have access to
the necessary user interface options (including the search option).
265
Some ACIs have to allow the administrative user to see the appropriate
information:
There should be an ACI allowing the administrator to search and modify the
Person object (maybe also the BPPerson object).
There should be an ACI allowing the administrator to at least view the
container in the organization tree; this should include the search option and
some of the attributes.
There should be an ACI for each service profile account type in order to allow
administrators to add, search, and modify accounts. Depending on policies,
they may be able to remove, suspend, and restore accounts.
Besides the basic access for administrators, further ACIs may allow an
administrator to:
Remove identities (requires remove operation on the account for each service
profile)
Transfer identities (requires transfer operation on the Person and BPPerson
fields)
Create identities (requires add operation on Person and BPPerson objects)
Manage services (requires ACI on the services to allow this operation)
There are various options in the construction of the ACI, but the ACI always has
scopes. If the scope is too broad, the administrators may see too many objects
and they will effectively become central administrators.
Domain administrators and supervisors

The simplest way to delegate administration is by means of the Supervisor and
Domain Administrators. The ACIs can easily handle these principals. However,
this may require careful planing of the organization tree and the supervisor
relations between identities.
An organization tree containers supervisor can see all identities placed under
that container and any children containers.
An Admin Domain can have several administrators, while a regular organization
tree container or identity has only one supervisor. This means that several
administrators can manage the same domain, and the ACIs can still be fairly
simple.
IBM Tivoli Identity Manager groups

If an administrator requires something that cannot be delivered by supervisors
and domain administrators, there may be a need to define ACIs using IBM Tivoli
266
Identity Manager groups. This requires creating the groups and then creating a
complete set of ACIs for that group.
User self-care
Users are not authorized to do many things by default. The default ACI shipped
with IBM Tivoli Identity Manager allows users to do the following:
They can see all their identities data, search on that data, and modify it,
although there are no writable attributes by default.
They can see their IBM Tivoli Identity Manager user account information,
search for it, and modify the password, login screen, and challenge response
information.
Although they are authorized to search for data on their own data, the default
regular users do not have access to the search option.
User self-care normally requires that users be able to do other tasks. Table 8-7
shows what ACIs are required to allow users to perform some of these tasks.
Table 8-7 ACI for user self-care tasks
Task
ACI Context
Grants
Change password
Account (one for each

service profile)
Grants read and write access to the

password field and modify
operation.
Request new service

or account
Account (per service

profile)
The add operation grants the read

and write access on the password.
More attributes many be authorized
if necessary.
Change personal
information
Person or BPPerson
Grants read and write access on the

information bit that will be
authorized. This can be done on the
default ACI.
Modify account
information
Account (per service

profile)
Grants read and write access on

whatever attributes can be
changed. Grants the modify and
search operation.

For this phase, TAA requires that the users have the ability to change their
passwords for all their accounts. They also want to allow region administrators to
manage the users on their region. User managers should be able to see the user
information.
267
All of the identity information is coming from the identity feed, so there is no need
for the administrator to change this data. There is only one region administrator
per region. They can create and remove accounts, but they should not set
accounts in other regions.
Based on these requirements, the design must accomplish the following:
Regional administrators are set as the organization unit supervisors.
All users are able to manage their passwords for all services.
Default ACIs are reduced so that the local administrators can only read the
identity information.
Account ACIs are created to allow administrators to create, suspend, restore
and remove accounts that they supervise.
Regional administrators are a member of IBM Tivoli Identity Manager groups
that allow them to have all the user interface functions.
This is an initial design and it allows a quick deployment, but since all users have
their managers as supervisors, this may be changed in the future, especially if
the managers begin to have more access to the IBM Tivoli Identity Manager
interface. Since they have only simple access in this phase, this is not an issue.
268
Chapter 9.
Technical implementation:
phase II
Once the basic IBM Tivoli Identity Manager operation is in place, Tivoli Austin
Airlines can begin reviewing and automating processes.
269
9.1 TAAs requirements

Section 7.3.2, Security Design Objectives: TAA specifics on page 211
describes several goals that should be achieved in phase II. These goals have
been included in the following automated processes:
New employees should automatically gain access to basic applications. This
includes IBM Tivoli Access Manager, IBM Tivoli Identity Manager, the local
Microsoft Windows domain, and the Lotus Notes accounts.
Accounts to some more specialized systems, such as RACF and AIX, should
be requested by the user and approved by using a workflow involving
manager and system administration.
Use Role Based Access Control as much as possible with IBM Tivoli Identity
Manager.
On the wish list, Tivoli Austin Airlines would like to allow employees to use
IBM Tivoli Identity Manager processes to request uniforms once they have
joined the company.
This chapter explores how to achieve each of these goals. Each section contains
the following information:
Information that is relevant during the design phase
Design options and considerations
How it was implemented at Tivoli Austin Airlines
9.2 New hire automation

When an employee joins a company, the first task at hand is to get their
information into the appropriate systems. The human resources department
normally is the first group to acquire the employees data. Further tasks are to get
access to the relevant IT resources.
The ideal process should automatically generate accounts for the new user to
different IT resource platforms. This section shows how to do this with IBM Tivoli
Identity Manager.
270
9.2.1 Requirements
Automatically provisioning users is handled by provisioning policies. This
requires them to be set to automatic provisioning (see 8.6, Provisioning policies
on page 242), but in order for this to yield the appropriate results, the following
aspects must be considered:
Passwords must be generated in a way to satisfy the policies, be secure, and
be known to the users.
All required attributes for that particular service must be assigned default
values (that match policies for those values).
Organization roles must be defined to avoid granting undesired access to
certain users.
It is necessary to have enough information to address all these issues in order to

design the adequate provisioning policies.

A good automated provisioning policy for adding users should run independently
of any human input. It is technically possible to have a workflow on an automatic
provisioning policy, but this can cause storms of approval or information requests
to the administrators. In order to avoid this, the provisioning policy must correctly
handle:
Password generation
Default values for service attributes
Target system roles
It is possible to address all these issues by using scripts.

Another key requirement is that the new identities be passed from human
resources (or authoritative source) to IBM Tivoli Identity Manager using the
identity feed mechanism (see 8.7, Identity feed and HR synchronization on
page 249). This makes the entire process seamless and automatic.
Tip: Changing automatic provisioning policies may trigger large compliance

checks on the entire IBM Tivoli Identity Management identity base. This can
be time consuming. To avoid this delay, always test automatic provisioning
policies on test systems, or small groups of identities, before activating them.
Organizational roles and target systems membership

Automatic provisioning policies can be set for all identities, but, depending on the
resource, only certain users should be provisioned by them. It may also be
Chapter 9. Technical implementation: phase II
271
necessary to assign users to specific roles on the target system, which requires
more organization roles or a specific JavaScript to assign the proper target
system group membership.
If IBM Tivoli Identity Manager organizational roles map adequately to the target
systems roles, group membership can be determined by a set of provisioning
policies. Remember that provisioning policies can be added to determine group
membership (most services are configured to have group membership as a
union of all policies).
Based on this, it is possible to create the following:
One basic provisioning policy that grants the common group membership for
all identities, as well as the default values for the attributes
Provisioning policies for each organizational role to service group mapping
An alternative design is to have a JavaScript that assigns the proper group

memberships for all users. This can be more complex to test and maintain, but
may avoid an excessive number of provisioning policies.
Generating passwords
One key attribute that must be handled by automated provisioning policies is the
password. Passwords must be generated to match the password policies for the
services they are provisioning to. This may be a challenge if there are several
password policies in place.
Generating the password can be a complex issue when this is the first password
for that user. This password may be used for the mail system or entry point
applications, such IBM Tivoli Identity Manager and IBM Tivoli Access Manager.
For these applications, the user must have some way of knowing what the
password is.
IBM Tivoli Identity Manager includes a shared secret field that can be used for
holding the seed for a password. The password can be created with a
JavaScript. This script can have access to all the identitys information and the
account information. This means that any attribute can be used to create the
password. However, for the entry point applications, the user should know the
password, or have a way to determine it.
Tip: While testing, use a visible attribute (in clear text) on a manual
provisioning policy to see what the script is generating.
272
Provisioning policies attributes

Most services have a set of required attributes. For an automatic provisioning
policy to work, all these attributes must be given default values, which includes
the password (as discussed above).
These attributes can be defaulted to:
Constant values
Values returned by a JavaScript
The use of constant values is normally applied to items such as Boolean flags,
group membership, and anything that does not depend on the identities
information. The script should be used for any attributes that vary between
identities. Scripts can become fairly complex and can look into values in the
LDAP.
Provisioning policies will be joined to yield the final value for the attributes. This
allows the construction of one general provisioning policy that handles the values
for all or most users, and group specific policies that will override the general
policy. Overriding can be done using the appropriate priority on the provisioning
policy.
Important: When using generic provisioning policies, remember that anyone

in the membership will have access to whatever services are in that policies
entitlement, so be careful with Al memberships and entitlements to Service
Profiles.
Several simple scripts can be used to provide default values in provisioning
policies, as shown in Table 9-1. The value of the last expression in the script will
be used.
Table 9-1 Sample provisioning policy scripts
Script
Description
{'/home/'+ parameters.eruid[0];}
Defines the home directory based on the initial

value of the account eruid.
{subject.getProperty('cn')[0];}
Get the values from the identity for which the

account is being requested.
{ var strLen= Enrole.getAttributeValue(

"Person.ersharedsecret","").length; }
Declares strLen and assigns it the length of

the identities shared secret information.
273
Script
Description
{ Enrole.
getAttributeValue("Person.ersharedsecret","")
.substring(strLen-4,strLen); }
Get the last four characters of the identitys

shared secret information. Requires the
strLen to be defined with the current length (as
shown above).

TAA has decided to grant automatic access to the following systems:
Lotus Notes
With access to these systems, the new employee can start requesting new
accounts without having to depend on either help desk or manager.
The provisioning for IBM Tivoli Access Manager is used in this section to
illustrate how the automatic provisioning is handled.
There are two provisioning policies that are used to provision an account to IBM
Tivoli Access Manager: pp_employee_access and pp_basic (see 8.8.3, TAAs
implementation on page 267). These policies handle the employee specific
information and basic access rights.
Although these policies handle the basic access requirements, it was desirable
that managers have a different access right. This requires a new provisioning
policy to handle the additional access rights. To grant the additional role,
manager accounts are given membership to the IBM Tivoli Access Manager
group grp_manager. Table 9-2 show the entitlement for this policy.
Table 9-2 pp_manager_access entitlement values for IBM Tivoli Access Manager
Attribute
Enforcement
Value
ertamgroupmemeber
mandatory
grp_manager
This policy does not need to be automatic. The next changes are to the
pp_employee_access provisioning policy to allow automatic provisioning. The
following modifications were made:
Default values were created to allow automatic provisioning. The attributes
values are shown in Table 9-3 on page 275.
The entitlements for IBM Tivoli Access Manager were changed from manual
to automatic.
274
Table 9-3 pp_employee_access entitlement values for IBM Tivoli Access Manager
Attribute
Enforcement
Value
cn
mandatory
{subject.getProperty(cn)[0];}
description
default
{'EMPLOYEE: ' +
subject.getProperty("cn")[0];}
erpassword
default
See Example 9-1
ertamauthentication
default
IVADMIN_USER_LDAPAUTHMETH
ertamdn
mandatory
{'uid='+parameters.eruid[0]+
',dc=tam,dc=taair,dc=com' ;}
ertamexpirepass
default
TRUE
ertamgroupmemeber
default
grp_employee
ertammaxfailedlogon
default
ertampasswordpolicy
default
FALSE
ertamsinglesign
default
TRUE
sn
mandatory
{subject.getProperty("sn")[0];}
The password generation was handled by a script that uses part of the first
name, last name, and shared secret to generate a valid password. The script is
shown in Example 9-1. Since the shared secret is a number, the password
generated can be known by the users yet different for each user. Notice that in
Table 9-3 that the ertamexpirepass is set to true, which means that the user is
requested to change the password upon first logon.
Example 9-1 TAAs password generation script
{
var strLen= Enrole.getAttributeValue("Person.ersharedsecret","").length;
var data=Enrole.getAttributeValue(
"Person.ersharedsecret","").substring(strLen-4,strLen);
Enrole.getAttributeValue(
"Person.givenname","").substring(0,2).toLowerCase() + data +
Enrole.getAttributeValue(
"Person.sn","").substring(0,2).toLowerCase();
}
Most employees will be handled by the pp_employee_access provisioning policy

only (since they only have the role_employee organization role). However,
managers will be provisioned by both pp_employee_access and
role_manager_acess policies. When both policies are joined, the users have the
275
appropriate access. One interesting detail is that only one policy must be
automatic; the other provisioning policies will be considered even if they are
manual.
9.3 User requested accounts with workflow

One way to obtain greater ROI with an identity management tool is to have users
manage themselves. Password changes and managing personal information is
discussed in 8.8, Administrator and user access on page 260. An additional
possibility is to have users request their accounts on managed systems. This
makes the provisioning of accounts much simpler.
9.3.1 Requirements
If users are to request their own accounts, it is necessary to know how much
leeway they have on the request. This involves looking into the following aspects:
What attributes can the user choose?
They may be allowed to simply ask for an account or to request accounts with
certain characteristics. This varies for each account type and the particular
system they are requesting access to.
Is there an approval process in place?
What is the approval process? Who are the people involved in it? Is additional
information required? This information should allow for a rough concept of the
workflow that should be used.
Once the account has been created, what can the user see and change?
Since the user has requested the account, he may want to modify some
information in it. Is this possible? What fields can he change?
This information should allow the administrator to design the workflow, the
provisioning policy, and any ACI needed for this.

Designing a provisioning policy that allows users to request their own accounts
involves creating a workflow to be used by the policy, and then setting up the
Access Control Information (ACI) to allow users to request the account. The
policy must also provide adequate defaults for the attributes that users are not
allowed to change, and good restrictions on those that the user can change.
276
Workflow design
Designing a workflow is done using the Workflow Diagram tools within the IBM
Tivoli Identity Manager Web interface. The elements are documented in Chapter
7, Workflow, of the IBM Tivoli Identity Manager Policy and Organization
Administration Guide V4.4, SC32-1149. The same information is available in the
online help. Section 4.2.4, Workflow on page 84 also describes general
elements in the workflow. This section includes some additional information on
design options for workflows.
Brief workflow review

Workflows have to have at least the five elements:
Start element
End element
Rejected return element (indicating the workflow was rejected)
Approved return element (indicating that the request was approved)
An approval element or a subprocess element
Each element is connected with transition lines; when two or more of these lines
connect to the same element, the join type of the element is considered. The join
type can either be an and clause (indicating that all transitions must be active to
trigger the element) or an or clause (in which case, any one of the transitions
active will trigger the element). The join type is indicated by a symbol on the left
of the element, a triangle for the or clause and a circle for the and clause.
An approval is required somewhere in the workflow to allow the proper return
element to be activated. Workflows are used in the entitlement of a provisioning
policy. If a workflow has a Global service type, it can be used by any service
type.
Figure 9-1 on page 278 shows a simple workflow. This workflow has several
characteristics:
It uses parallel approval (both the Service Owner and the Manager are called
at the same time).
The request will be rejected if any of the approvers rejects the request. This is
indicated by the triangle on the left side of the Rejected box (or union).
If both approve, a Request for Information (RFI) is sent to an administrator,
asking for the group membership information. The circle on the left of the RFI
box indicates that this is an and union, that is, both lines coming in must be
true.
277
Note: On IBM Tivoli Identity Manager Version 4.4, the Rejected box is
displayed with a circle to its left, but it still operates in an or union (this
mode cannot be changed).
The RFI sends the request to the Approved action.
Figure 9-1 Workflow example
The following section contains some additional information about each element
in the workflow.
Approval
An approval is the key element in a workflow. Somewhere in the workflow,
someone will have to approve the request, unless it is strictly a request for
information workflow. IBM Tivoli Identity Manager provides several approvers to
choose from, among them:
Person
Organization role
Requestor
Requestee
Service Owner
Sponsor
Supervisor
System administrator
Domain administrator
One important consideration about approvers is that, if the approver cannot be

resolved, that is, mapped to an IBM Tivoli Identity Manager account, the request
is approved by default. This may lead to security problems. Some of the approver
types, such as supervisor and sponsor, may have several levels (one at the
identity level, and another at the organization unit level).
Another interesting aspect is that if the approver resolves to the same identity
and that identity has already approved something previously on the workflow, the
278
approval will be approved again. This does not happen inside loops. Although
this may seem strange, it avoids creating confusion with the same person being
requested over and over for the same approval.
Subprocess
Subprocesses can be used to call other workflows. This allows for the creation of
reusable workflows. For example, a Global service type workflow can give the
basic procedure for all manager approvals, and then be included via a
subprocess into specialized workflows for each service type.
A subprocess can also be used in loops to hide complex parallel or serial
approvals that could not be easily represented in the loop.
Request for Information (RFI)

RFI allows an administrator to change or input values for any attribute of the
requested account. An RFI can be used to:
Check the attributes that the user was allowed to input.
Manage group assignments for target systems.
Manage attributes that may be difficult to be handled via script, such as the
Lotus Notes server for the Notes mailbox, the home directory on UNIX
Systems, or a UNIX user ID number.
Although it is possible to connect the RFI to either the Approved or Rejected

elements, the person that answers the RFI cannot reject the request. By using a
custom transition line, it may be possible to determine if some fields have
changed to a certain value.
Loops
Loops allow for more complex logic to be used in the workflow. Each loop must
have JavaScript for at least the following workflow elements:
One on the loop itself, which determines an exit condition, for example:
context.getLoopCount() <= 3
One for each transaction line leaving the loop.
The placement of this script is shown in Figure 9-2 on page 280.
279
Exit condition for the loop

c o n t e x t .g e t Lo o p Co u n t ()<=3
JavaScript for a positive exit
from the loop
JavaScript for a negative exit

from the loop
Figure 9-2 Loops JavaScript requirements
Note: Loop usage is limited by the amount of information available to the

scripts used in the loop. Loops are currently intended to be used along with
extensions to the JavaScript engine used in the workflow. Extending the
JavaScript engine is beyond the scope of this book.
Putting it together
Workflow design is essential in joining the components. It is important to try to
use simple workflows, so you should use subprocesses to help simplify the
design. Complex workflows may become difficult to understand and maintain.
Workflows can be used in automated provisioning policies, but this should be
done with care, since changes in the policy or bulk loading of identities may
cause a large number of approval requests to be generated.
Important: Always test the workflows before putting them in production. It is

important to see if they are behaving as expected, since an invalid approver or
erroneous JavaScript can cause the workflows to fail, or invalid approvals to
happen.
280
Provisioning policies and the ACI

An Access Control Information (ACI) is needed to allow users to request their
account. These ACIs have been discussed in 8.8, Administrator and user
access on page 260. In order for a user to request an account, he will require an
ACI that grants him:
Add operation
Read and write access to the password
Access to other attributes he must see or edit
Along with the proper ACI, a provisioning policy must be set. This policy should
have default values for all fields the users cannot fill in, and validation for all fields
that the user can edit. This avoids the need for complex RFIs.

The majority of the systems used in TAA are being handled by the automatic
provisioning policies. However, the administrator of the AIX development
machines has decided to allow users to request access to this system. He also
decided that the users will have the ability to work with several things:
User ID (to allow them to request account for services)
Primary and secondary groups
Shell
Home directory
Once the account is created, they can only change the shell program. They can
also request the suspension, removal, and restoration of the account.
The administrator requires that only employees in development be allowed to do
this, and that the employees manager and the administrator must approve the
request. The system administrators must also double check the request
information. To handle this, the workflow in Figure 9-3 was created.
Figure 9-3 TAAs developer AIX workflow
281
Along with the workflow, the following ACIs were created:

One that grants the Add operation and read and write access to the
password, user ID, home directory, shell, and groups.
One that grants the remove, suspend, restore, modify, and search operations,
and allows users to see all attributes and updates the shell attribute.
Additionally, a provisioning policy was created with the following characteristics:

Has role_developer in the membership of the policy
Sets up manual provisioning for the development AIX machine, using the
workflow shown in Figure 9-3 on page 281
Provides default values to user ID and home directory
This allows users to easily request and do some simple maintenance on their
accounts while allowing the administrator a great deal of control over all the
accounts.
9.4 Role Based Access Control

One of the key benefits of having an identity management tool is the possibility of
centrally enforcing Role Based Access Control. However, this can only be
achieved if the systems being managed are prepared for Role Based Access
Control.
Membership
Group
Role
Access
User
Resource
Target System
Figure 9-4 Typical Role Based Access Control
Role Based Access Control is typically implemented as shown in Figure 9-4.

Users are placed in groups, which map to roles, which map to access on a given
resource. Names may vary, or roles, groups, and access may not be explicitly
named (as in IBM Tivoli Access Manager).
282
IBM Tivoli Identity Manager can manage groups on target systems. It is assumed
that groups will then map into roles. This alone does not mean it is a role based
access management tool, but used correctly, it can help.
9.4.1 Requirement
In order to manage Role Based Access Control using IBM Tivoli Identity
Manager, it is crucial to have a good understanding how Role Based Access
Control is being implemented on each target system. It is essential that a good
design already exists on the target system; no management tool is able to
correct or improve a bad Role Based Access Control design.
The first piece of information required is what group and/or roles exist on the
target systems. An adequate listing of each group and what kind of users there
are should be placed in each group; the more information available, the better.
Besides this information, it may be important to determine how identities can be
associated to the roles on IBM Tivoli Identity Manager. It is necessary to
determine if there is enough information to do this automatically (using dynamic
roles) or if it will have to be handled manually by administrators.

Managing system specific Role Based Access Control using IBM Tivoli Identity
Manager is done by managing the account membership to groups on the target
system. This can be done using provisioning policies, using them to define
mandatory group membership on the target system (or service).
283

Membership
Dynamic or static
Organization
Role
Identity
Ow
n
shi er
p
Entitlement
n
leme
Entit
Membership
rs
h ip
Provisioning
Policy
Target System
Group
Account
Membership
Recon
Service
Provisioning
Provisioning
M
em
be
Group
Role
Access
User
Resource
Target System
Figure 9-5 IBM Tivoli Identity Manager and Role Based Access Control
Figure 9-5 shows how IBM Tivoli Identity Manager interacts with the targets Role
Based Access Control. Several important aspects are shown in the figure:
Reconciliation brings the information of what groups (and, indirectly, roles)
exist on the target system.
Identities in IBM Tivoli Identity Manager are mapped to organization roles
either using static or dynamic membership; in the dynamic case, information
about in the identity will be used to determine membership.
Entitlement will determine what the account should look like, including the
group membership on the target system.
284
Analyzing Figure 9-5 on page 284, it is easy to see that by using IBM Tivoli
Identity Manager, the mapping of identities to access follows the path shown in
Figure 9-6.
Provisioning Policy
Organization
Role
Group
Role
Access
Resource
Identity
Dynamic Roles
Figure 9-6 Identity to access mapping using IBM Tivoli Identity Manager
Managing Role Based Access Control requires designing a more restrictive

provisioning policy that depends on good dynamic roles and restrictive mapping
of organizational roles to target system groups.
Since IBM Tivoli Identity Manager has a method of joining provisioning policies,
the role mapping can be done in several policies, and the resulting role
assignment will be handled by the joining of the provisioning policies, as shown
in Figure 9-7.
Provisioning policy for

users with Role_A
Basic Provisioning Policy
Provisioning policy for

user with Role_B
Result of join for user with

Role_A and Role_B
Figure 9-7 Using provisioning policy joins in role assignment
285
Reviewing provisioning policies

Mapping the IBM Tivoli Identity Manager organization role to the roles on the
target system may require reviewing all provisioning policies. The easiest
approach is to do the following:
Have one provisioning policy that grants basic access to all users that have
an account on the system. This includes basic group membership and all
default values to the account attributes. Membership to this policy should
include all users.
Create specific provisioning policies to handle group memberships on the
target system. These should have higher priority then the base policy.
Another important detail is that if membership should be restrictive, attribute
values should be set to mandatory (as shown in Figure 9-8). Setting the group
membership as mandatory avoids administrators overriding the policy defined
values.
Figure 9-8 Setting attributes to mandatory
Another way to set group membership is by using a JavaScript to return the

groups based on the identitys information. This allows a single provisioning
policy to handle all the role mapping, making for a simpler provisioning policy
design. However, this approach requires creating a script, and hides the policies
on how groups are assign in the script, which may not be simple to understand.
Using JavaScript does not eliminate the possibility of the joining of the
provisioning policy, so mixing the techniques can produce better results. The
hybrid approach can be done by having provisioning policies with a simpler and
somewhat broad membership, and by having the script do the final group
assignment within those users.
286
Whatever method is used, it is important to remember that some systems may

have extremely complex role based access control designs. This may make the
task of creating the correct policies very hard.
Organization roles revisited

Since the provisioning policies require more roles to allow for the mapping of
roles to groups, new roles will be needed. The number of roles will be highly
dependent on the way mapping will be done. If the mapping turns out to be at
least a one-to-one relation, there may be an enormous amount of roles, specially
in large enterprise systems like RACF and IBM Tivoli Access Manager.
The key is to avoid having to use one-to-one mapping. One way is to carefully
review the user assignment to roles on the target system, looking for patterns
that allow grouping of roles. Another alternative is to use scripts in the
As the number of roles increase, it may become harder to use manual
assignment to the organization roles. This can be avoided using:
Dynamic roles making the assignment automatic
Identity feeds that contain the role information
Keeping the design simple is critical. If it becomes too complex, it may be

impossible to understand, and thus unmanageable. If the complete mapping is
impossible, one option is to delegate the assigning to administrators and use the
provisioning policies to control access to what the users are not entitled to. This
can be done by using the excluded option on the attributes enforcement.

TAA decided to control the IBM Tivoli Access Manager roles using IBM Tivoli
Identity Manager. It handles several applications, which means the number of
roles is fairly large.
A hybrid approach was used to avoid using too many provisioning policies and
organization roles. General organization roles were created and scripts in the
provisioning policies were used to assign users to the correct groups.
The initial idea was to handle each application in a specific provisioning policy;
however, whenever possible, several applications are handled by the same
policy (if the membership where the same). Also, the basic provisioning to IBM
Tivoli Access Manager is described in 9.2, New hire automation on page 270.
As an example, the flight crew, cabin crew, and counter personnel have access
to a system that handles checking, flight plans, and boarding. People involved in
these functions can be found in the role role_customer_facing (used in 9.5,
287
Provisioning to non-IT resources on page 289). So the provisioning policy has

the following characteristics:
Membership for role_customer_facing role
It entitles manual access to the IBM Tivoli Access Manager service
In the entitlement attributes, the ertamgroupmember is defined to have a
mandatory value as defined by the script shown in Example 9-2
Using the script, it is possible to map the different job codes that are part of the
role_customer_facing role into the appropriate IBM Tivoli Access Manager
groups.
Example 9-2 Assigning groups using provisioning policy scripts
{
var a=new Array();
var i=0;
var title=Enrole.getAttributeValue('Person.title','');
if(title== 'JC_FLIGHT_PILOT') a[i++]='tam_grp_pilot';
if(title== 'JC_FLIGHT_COMMANDER') {
a[i++]='tam_grp_pilot';
a[i++]='tam_grp_commander';
}
if(title== 'JC_FLIGHT_ENGINEER') a[i++]='tam_grp_engineer';
if(title== 'JC_COUNTER_RECEPTION') a[i++]='tam_grp_reception';
if(title== 'JC_COUNTER_MNG') {
a[i++]='tam_grp_counter_reception';
a[i++]='tam_grp_counter_manager';
}
if(title== 'JC_CABIN') a[i++]='tam_grp_cabin';
if(title== 'JC_CABIN_SENIOR') {
a[i++]='tam_grp_cabin';
a[i++]='tam_grp_cabin_senior';
}
return a;
}
288
Tip: Example 9-2 shows a script that returns a list of groups to the
provisioning policies. It contains some interesting details:
In order to return more than one group, the script must return an array.
The array must be declared using the new Array() construction.
There is no add or push method for the arrays in this context, so to add
elements, one must use an index.
The last line includes a return statement, which is not really necessary; it
could be replaced by a simple a; statement.
9.5 Provisioning to non-IT resources

Once IBM Tivoli Identity Manager is used by end users, some interesting
possibilities start to appear. Among them is the provisioning of non-IT or non
security related resources. In TAAs case, the uniforms are a type of resource an
employee may want to request. Other resources could be considered, such as
hardware, telephone systems, and software (using tools like IBM Tivoli
Configuration Manager). Several resources could be correctly handled by the
provisioning model used in IBM Tivoli Identity Manager.
The key challenge in provisioning non-IT resources is how to connect IBM Tivoli
Identity Manager to the resource. As of Version 4.4, the only available agents
that can be tailored for this are the Universal Provisioning Agent and the CLI-X
Agent. The Universal Provisioning Agent converts the account related operations
into e-mails. The CLI-X agent calls out commands on each operation, so it can
be tailored to do the correct interface with whatever is required.
You could also write a Java provisioning agent using the API available for that
purpose.
Note: It is Tivolis stated intention to provide a provisioning agent or connector

for IBM Directory Integrator in the future. With such an agent or connector, it
would be possible to use IBM Directory Integrator to provision to non-IT
resources.
289
9.5.1 Requirement
IBM Tivoli Identity Manager can provision non-IT resources, assuming there is
some interface to those resources (be it a human or computer). However, to
create the link between the two, one must know the following:
What information is required for the provisioning to occur?
When provisioning, there will be information that is required. For example, for
a telephone system, you need to know where the line must be set up. This
information is critical in the design of the solution.
What will accounts represent on the system?
IBM Tivoli Identity Manager provisions accounts, but this concept may not be
applicable on the target system. Nevertheless, the account is a valid link
between the user and the resource, so it can be used as a representation of
the user.
What is the life cycle of the account?
The account being created will normally represent the resource being
provisioned to the user. But once it is provisioned, how should the account be
maintained? Will it exist forever? Should it be represented on a pending
request? This will be determined by the nature of the resource being
managed.
This information should be enough to create a provisioning model for the
resource.

The first and most important design decision is what type of agent will be used to
handle the provisioning. As described above, there are some options for this, and
new options will be available in the future. For this example scenario, the CLI-X
Agent will be used, since it is more flexible.
With the agent decided, the information required must be gathered. This involves
what information must be used for provisioning purposes, and also how the
agent can handle the information. Some agents have pre-defined fields that can
be tailored to suit the needs of the resource.
CLI-X Agent overview

The CLI-X Agent is a generic agent stub designed to handle any type of
command line interface commands or scripts. It is very flexible because very little
is pre-defined in the agent, so it can be seen as a toolkit agent.
290
The agent is basically composed of the following parts, many of which must be
created:
Agent code that can call commands passing arguments or files as input
Server side configuration files, which must be created for that agent
Agent script that should be called on several actions, which must be created
for that agent
Unlike other agents in the configuration process, you essentially create a new
service profile for that agent. This allows for the definition of new account types,
group types, and service profile types.
Important: This section is by no means a complete documentation of the

CLI-X Agent. It contains additional information, but readers should first refer to
the proper product documentation.
Scripts or commands
The agent operations are handled by commands on the machine where the
agent is executing. These commands can be executable programs or executable
scripts. There are some operations that must be handled by the scripts or
commands:
Add
Called to create a new account that should be created.
Delete
Used for deleting an account.
Modify
Used to change the information on an account. This is also called on

account suspend and restore operations.
Search
Used during the reconciliation process to list what is available at the

agent.
The information for the account creation can be supplied in two ways: through
the command line arguments or through an attribute files. The attribute files will
contain all the information that was not passed through the arguments.
Example 9-3 shows the content of the attribute file in the uniform provisioning
service.
Example 9-3 Sample CLI-X attribute file
eruniformleg|36
eruniformaddress|2600 Gracy Farms Ln, Austin, TX
eruniformwaist|30
eruniformhip|30
eruniformchest|30
eruniformgender|MALE
291
For all operations, the command may return a result file. This is mandatory for
the search operation. For this operation, the file should contain all accounts and
groups that were found in the system. Example 9-4 shows a result file for the
uniform provisioning service. The first line of each group contains the user ID for
that account and the account type (in this case, erUniformAccount). This
example does not contain group information.
Example 9-4 Sample result file for CLI-X agent
eruid|a665566|erUniformAccount
erUniformchest|20
erUniformaddress|50
erUniformhip|30
erUniformwaist|10
erUniformgender|MALE
erUniformleg|40
eruid|a012345|erUniformAccount
erUniformchest|20
erUniformaddress|50
erUniformhip|30
erUniformwaist|10
erUniformgender|MALE
erUniformleg|40
CLIXResult|0
Figure 9-9 on page 293 shows a screen shot of the CLI-X agents non-encrypted
registry settings. In the uniform service, there is a single script being called for all
operations; this can be seen in the template entries (numbered 01, 02, 08, and
10). the script handles internally the various operations. On all account related
operations, the user ID is passed in the command line, and all other information
is passed in the attribute file. This is not mandatory, but was how it was
implemented in the uniform service.
292
Select menu option:

Agent Registry Items
------------------------------------------------01. AddTemplate
'C:\uniform\uniform.cmd -add $erUid'
02. DeleteTemplate
'C:\uniform\uniform.cmd -del $erUid'
03. Delimiter
'|'
04. ENROLE_VERSION
'4.0'
05. ExtendedInput
'FALSE'
06. ExtendedOutput
'FALSE'
07. GroupIdAttribute
'erGid'
08. ModifyTemplate
'C:\uniform\uniform.cmd -mod $erUid'
09. ResultAttribute
'CLIXResult'
10. SearchTemplate
'C:\uniform\uniform.cmd -list'
11. UserIdAttribute
'erUid'
------------------------------------------------Page 1 of 1
A. Add new attribute
B. Modify attribute value
C. Remove attribute
D. Next Page
X. Done
Select menu option:
Figure 9-9 Configuration for CLI-X agent
Scripts or commands must return determined values to indicate if the operation

was successful or not. If the script returns 0 (zero), the action is assumed to have
happened successfully.
Tip: On the add operation, it is possible to create multiple accounts with the
same user ID. If the CLI-X returns a success, IBM Tivoli Identity Manager will
register a second account with the same user ID on its LDAP. This may lead to
discrepancies or cause confusion; if this is not an intended result, be sure to
make the CLI-X script or command return an error code on duplicate
accounts.
Configuration files
Each CLI-X Agent service profile requires that a set of files be created for the
server. These files should all be placed in
%ITIM_HOME%/data/remote_resources/ in a directory named after the service
profile. For the example used in this section, the uniform service (that is internally
293
called UniformProfile), the directory where these files were placed was
C:\itim\data\remote_resources\uniformprofile.
Each directory defining a service profile will contain several files. These files and
their functions are shown in Table 9-4.
Table 9-4 Files for the CLI-X service profile configuration
File
Uniform example
Content/Function
CustomLabels.properties
CustomLabels.properties
Labels to be shown in the user

interface. The attributes defined for
the service and account objects will
have the labels defined in this file.
er[ServiceAccount].xml
erUniformAccount.xml
This file is used to generate the

screen for the editing account for
that service profile. It is created by
the User Interface Customization
applet.
er[ServiceDAMLService].xml
erUniformDAMLService.xml
This file is used to generate the

screen for creating a service for the
service profile. It is created by the
User Interface Customization
applet.
resource.def
resource.def
XML files that describe the service.

This is used when installing the
service on the IBM Tivoli Identity
Manager server.
schema.dsml
schema.dsml
This files contains all the definitions

for attributes and object classes for
service account, service group,
and the definition of a service of
that CLI-X agent
xforms.xml
xforms.xml
This file contains the mapping of

the attributes in the IBM Tivoli
Identity Manager Database to the
ones on the target CLI-X agent.
The xforms.xml, schema.dsml, resrouce.def, and CustomLabels.properties must

be created for the service manually. The CLI-X Agent does supply a set of
examples; other services can also be used as a reference. The
er[ServiceDAMLService].xml and er[ServiceDAMLService].xml files can be
created using the User Interface customization applet once the service is
configured on the IBM Tivoli Identity Manager.
294
Tip: During our tests, it proved to be easier to copy the interface definition files
from another service and then edit them in the User Interface Customization
applet.
Important: Needless to say, all the service customization for the CLI-X agent
should be done in a test environment beforehand. Once the service is working
as desired, the service files can be copied to the production environment.
The most complex files are schema.dsml and resource.def. They will define all
service specific information to IBM Tivoli Identity Manager service. The best
source for information is the official documentation and the sample included in
the CLI-X Agent package.
Example 9-5 shows the schema.dsml file used for the uniform service. Some of
the important features of the file will be described below.
Example 9-5 TAA s schema.dsml file
<?xml version="1.0" encoding="UTF-8"?>
<dsml>
<directory-schema>

<attribute-type single-value = "true" >
<name>erUniformWaist</name>
<description>First Name</description>
<object-identifier>1.3.6.1.4.1.6054.3.101.2.1</object-identifier>
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
</attribute-type>
<name>erUniformChest</name>
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
</attribute-type>
<name>erUniformHip</name>
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
</attribute-type>
<name>erUniformLeg</name>
295
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
</attribute-type>
<name>erUniformGender</name>
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
</attribute-type>
<name>erUniformAddress</name>
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
</attribute-type>
<name>erTitle</name>
<description>Job Title</description>
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
</attribute-type>

<class superior="top">
<name>erUniformAccount</name>
<description>Uniform Request Account</description>
<attribute ref = "erUid" required = "true" />
<attribute ref = "erUniformChest" required = "true" />
<attribute ref = "erUniformWaist" required = "true" />
<attribute ref = "erUniformHip" required = "true" />
<attribute ref = "erUniformLeg" required = "true" />
<attribute ref = "erUniformGender" required = "true" />
<attribute ref = "erUniformAddress" required = "true" />
<attribute ref = "erTitle" required = "true" />
</class>



<name>erUniformDAMLService</name>
<description>Class for uniform provisioning.</description>
296
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
</class>
ref
ref
ref
ref
ref
ref
=
=
=
=
=
=
"erURL" required = "true" />

"erUid" required = "true" />
"erPassword" required = "true" />
"erCertFile" required = "false" />
"erPrivateKeyFile" required = "false" />
"erCACertStore" required = "true" />
</directory-schema>
</dsml>
Each attribute that will be used in the account or service is defined in a

attribute-type block. The block will include information on the attribute, including
type and identifier. Each object must have a object-identifier in the ISO/ITU
object identifier standard, as shown below:
The the object identifier breaks down in the following terms
1.3.6.1.4.1.6054
IBM enterprise ID: Must be this number.
Product ID used by IBM Tivoli Identity Manager for the

agents.
101
Agent ID: Each agent has one; for CLI-X agents, this
number must be a number between 101-110 (and
different for each agent type).
2.6
Instance ID: This is agent specific and is user defined.
Important: The instance ID must be unique for each attribute, account class,
group class, and service class.
Each attribute has its type defined by the following line:
<syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>
Each of these values represents an object type. The object identifier

1.3.6.1.4.1.1466.115.121 refers to values defined it the LDAPv3 syntaxes.
References to the types can be found on the CLI-X documentation and on the
Internet. The first line in the attribute definition also defines if the attribute is
multi-valued or not, as shown below:
Once all the attributes have been defined, the next section of the schema.dsml
file will define the classes for the service and service specific accounts and
groups. Example 9-6 on page 298 shows the initial lines of the class definition.
297
Example 9-6 TAAs Uniform Account definition (partial)

<name>erUniformAccount</name>
<description>Uniform Request Account</description>
<attribute ref = "erUid" required = "true" />
<attribute ref = "erUniformChest" required = "true" />
This definition include the name, description, and attributes used for that class.
Once more, the object-identifier tag will define the object identifier for that object.
The rules described above for attributes apply to class object identifiers. The
class also includes all the attributes, which can be mandatory or not.
Example 9-7 shows the resource file used for TAAs uniform provisioning system.
This the glue that connects all the other files, and allows a service to be defined
in IBM Tivoli Identity Manager.
Example 9-7 TAAs uniform service resource.def file
<?xml version="1.0" encoding="UTF-8"?>
<Resource>
<SystemProfile>
<Name>UniformAgent</Name>
<Description>Uniform Provisioning Agent</Description>
<BehaviorProperties>
<Property
Name =
"com.access360.enrole.remoteservices.ResourceProperties.TRANSFORMER"
Value =
"com.access360.enrole.remoteservices.transformation.EnroleAgentMessageTransformer"
/>
<Property
Name = "com.access360.enrole.remoteservices.ResourceProperties.TRANSFORM_FILE_NAME"
Value = "xforms.xml" />
<Property
Name = "java.naming.factory.initial"
Value = "com.access360.daml.jndi.DAMLContextFactory"/>
</BehaviorProperties>
<ProtocolProperties>
<Property Name = "java.naming.provider.url"
LDAPName = "erURL"/>
<Property Name = "com.access360.daml.jndi.DAMLContext.DEFAULT_PORT"
Value = "45580"/>
<Property Name = "com.access360.daml.jndi.DAMLContext.CLIENT_CERT"
LDAPName = "erCertFile"/>
<Property Name = "com.access360.daml.jndi.DAMLContext.CLIENT_CERT_KEY"
LDAPName = "erPrivateKeyFile" />
298
<Property Name = "com.access360.daml.jndi.DAMLContext.CA_CERT_DIR"

LDAPName = "erCACertStore" />
<Property Name = "java.naming.security.principal"
LDAPName = "erUid" />
<Property Name = "java.naming.security.credentials"
LDAPName = "erPassword" />
</ProtocolProperties>
</SystemProfile>
<AccountDefinition
ClassName = "erUniformAccount"
Description = "Uniform Account" >
</AccountDefinition>
<ServiceDefinition
ServiceProfileName = "UniformProfile"
ServiceClass = "erUniformDAMLService"
AttributeName = "erservicename"
AccountClass = "erUniformAccount"
AccountProfileName = "UniformAccount"
Description = "Uniform Account">
</ServiceDefinition>
</Resource>
This file contains the following sections:
SystemProfile
This section is composed of two sections:
BehaviorProperties Defines the services behavior.

ProtocolProperties
Defines the parameter needed to communicate with

the agent, item, such as certificates, user ID,
password, and so on.
AccountDefinition
Defines which LDAP class will be used to store accounts

for that service.
ServiceDefinition
Defines what class will be used to store the service

information, class for that server, and name for the
service.
The easiest way to create this file is to use the example in the documentation or
packed with the agent as a base, and just change the information in the
AccountDefinition and ServiceDefinition sections.
299
Installing the service

With all the files ready, the last activity needed to configure a CLI-X agent is to
configure the service on the IBM Tivoli Identity Manager server. This is done
using a script provided with the server. On Window 2000, the script is:
%ITIM_HOME%\bin\win\configure_remote_service.cmd
On UNIX servers, the script is:

$ITIM_HOME/bin/unix/configure_remote_service.sh
This script takes, as a parameter, the remote services name, which should
match the directory used to store the configuration files. In this example, for the
uniform service, the command used was:
C:\itim\bin\win\configure_remote_service.cmd uniformprofile
Note: In our environment, the configuration script failed due to an invalid path
within the script. This was solved by editing the
configure_remote_service.cmd file and changing the JAVA_HOME variable to:
JAVA_HOME=c:\WebSphere\AppServer\java
And removing the line that contained:

set CLASSPATH=%CLASSPATH%;%WL_HOME%\lib\weblogic.jar

Tivoli Austin Airlines has a system where uniforms can be requested by
employees that require them. This system is normally accessed by managers
that request the uniform on behalf of the employee. This system should be
integrated with IBM Tivoli Identity Manager, since this would allow users to
request their own uniforms.
Using the CLI-X agent, TAA was able to interface IBM Tivoli Identity Manager
with their uniform request system. The CLI-X agent has be configured to handle
requests in the following manner:
Uniforms should be requested and delivered to an employee according to an
address he provides.
An employee can only request one uniform at a time.
The process must not involve a manager.
300
In order to achieve this process, a new service profile was created with the
following general characteristics:
An account in this service represents a uniform request that has not been
fulfilled.
Once the employee receives the uniform, the account is eliminated. This
allows new requests to be placed.
Information concerning measures can be changed after the request has been
submitted.
The following information is handled by the service:

User ID (used to register the request, and get information about the user,
using the serial number in the user ID)
Measures (waist, chest, hips, and leg length)
Gender
Job title (to determine which uniform)
Mailing address (to deliver the uniform)
A single script was created to handle all operations, it handles the operations as
follows:
Add
Creates a new request. The operation will only succeed if there are
no pending request. If there is already a request, the new one will fail.
Modify
Updates the request for the new data. The operation will fail if the
processing of the request has reached a point where that information
cannot be handled.
Delete
Cancels the request.
Search
Lists all pending requests. Once a request has been fulfilled, the
account will no longer be listed.
The choice for having the accounts eliminated once the request has been fulfilled
allows a new request to be placed. The application uses the user ID (the
employee serial number) as a key for the requests. If all requests were kept, the
user ID would have to change, or IBM Tivoli Identity Manager would end up with
multiple accounts on the same service.
There is a weekly reconciliation process that clears out the requests (accounts)
that have been fulfilled. In order for this to work properly, the services
Enforcement Action must be set to Correct Noncompliances; this eliminates the
identity account that no longer exists.
301
In order for the employees to request the uniforms themselves, an ACI must be
created with the following characteristics:
Placement on the organization level (top of the tree). This is required because
employees are distributed along the branches and accounts are related to
identities.
Allow read and write access to all attributes, except user ID. Since the user ID
is important for the uniform system and the provisioning policy already
generates a valid user ID, there is no need for user input.
Allow the following operations: Add (to place a request), Delete (to cancel a
request), Modify (to change data on a request), and Search (without this the
employee cannot see the account after it has been created).
The last configuration need is the provisioning policy. It must control access to
only the people that have uniforms. The uniforms are reserved for customer
facing employees, which means the entire flight crew and the counter
representatives. The option was made to create a new dynamic role
(role_customer_facing) with the following rule:
(|(|(title=JC_FLIGHT_*)(title=JC_CABIN*))(title=JC_COUNTER*))
This filter will select all users that have a job title beginning with either
JC_FLIGHT_, JC_CABIN, or JC_COUNTER.
The provisioning policy entitles manual access to the uniform service for any
member of the role role_customer_facing. It is placed with the service in the
AD_CorpHQ administrative domain.
With all this in place, employees can request their uniforms, although some
improvement could be done, such as including a workflow to allow managers to
control requests.
The CLI-X agents configuration files were shown in the examples used
throughout 9.5.2, Design considerations on page 290.
302
Part 3
Part
Appendixes
303
304
Appendix A.

4.4 installation cookbook
This document is designed to walk you through all of the different steps required
to install Tivoli Identity Manager Version 4.4 (at this point, only the Microsoft
Windows installation is covered). This document is written with all the software
components being installed onto one system. One of the main objectives of this
document is to enable engineers to very quickly get Identity Manager up and
running, and start realizing value immediately. The software components can
also be installed on different systems; the steps to accomplish this are
straightforward but are not covered in this document.
305
Tivoli Identity Manager software overview

Here is a quick overview of the products that are installed during this process.
This is broken down by the CD-ROMs that Tivoli Identity Manager Version 4.4
ships on, and any external software that is required.
The Tivoli Identity Manager Base CD contains:
IBM MQSeries Version 5.2
WebSphere Advance Edition Server Version 4.0
Identity Manager Version 4.4 Application
The Tivoli Identity Manager Supplemental Disk 1 contains:

IBM MQSeries Version 5.2 CSD5 (this is a upgrade to MQ 5.2)
IBM MQSeries Support Pack MA88
IBM Directory Server Version 4.1.1
IBM Directory Server Version 4.1.1 eFix 00A
WebSphere Advance Edition Server Version 4.0.4 PTF
WebSphere Advance Edition Single Server Version 4.0.4 PTF
The Tivoli Identity Manager Supplemental Disk 2 contains:

DB2 Version 7.2 FixPack 7 upgrade (note this requires that DB2 7.2 already
be installed)
We also demonstrate the following items:

How to build agents for Active Directory and LDAP
How to set up workflow
How to install a mail server and use a LDAP browser
How to configure user data feed
How to use Identity Integrator with Identity Manager
Identity Manager component and process diagrams

Figure A-1 on page 307 shows the relationship between Identity Manager
components, and Figure A-2 on page 308 shows the relationship between
specific Identity Manager Server components.
306
ITIM Agent
E-mail Server
DAML/SSL
SMTP
HTTP/HTTPS
Web Server
HTTP/HTTPS
ITIM Server
JDBC
LDAP/SSL
HR feed
Directory Server
Database Server
LDAP/SSL
Figure A-1 Identity Manager components
Appendix A. IBM Tivoli Identity Manager 4.4 installation cookbook
307
ITIM Server Application
Directory Server
LDAP/SSL
Servlet
Host Platform
EJB
Application Server
(Websphere)
Directory Server
JDBC
Host Platform
Database Server
ITIM Server
Host Platform
Database Server
Figure A-2 Identity Manager Server components
Recommended hardware and software configuration

We use Windows 2000 Server with SP2 as the operating system with at least
one network interface configured. For stand alone demonstration purposes a
good setup is to configure the loopback interface. The detailed steps on how to
configure and set up the loopback interface is covered in Configure Windows
"loopback" interface on page 372.
The following hardware is required:
512 MB of memory (minimum)
Pentium lll or higher
6 GB of disk space or more
The Web browser prerequisites are:

Microsoft Internet Explorer Version 5.5 with SP2 or higher
Netscape Version 4.75 or higher
308
For further details refer to the IBM Tivoli Identity Manager Server Installation
Guide for Windows V4.4, SC32-1148.
Tip: It is recommend that you do not have any other Web servers running on
the system.
During the Identity Manager installation, WebSphere and the IBM HTTP server
are installed. This Web server expects that the standard http ports (80 and 443)
are available. Care needs to be taken with Microsoft Windows systems, as the
Microsoft Web server is quite often installed automatically. Before installing any
part of Identity Manager, first check and see if any Web servers are running on
the system. If there are, we recommend disabling these Web servers or
changing their ports to avoid conflicts, for example, 81 and 444.
Installation of DB2
Tivoli Identity Manager ships with DB2 Universal Database Enterprise Edition
Version 7.2.
Installing DB2 Version 7.2 FixPack 5

Insert the Windows DB2 CD and start the installation process. Either the
installation window will automatically start up when you insert the CD into the
machine or you need to double click on the Setup executable.
Select Install, as shown in Figure A-3 on page 310.
309
Figure A-3 Welcome to DB2 window
Select Next and accept the defaults, as shown in Figure A-4 on page 311.
310
Figure A-4 Select Products window
Accept the default Typical and select Next, as shown in Figure A-5.
Figure A-5 Select Installation Type window
311
Select Next, as shown in Figure A-6.
Figure A-6 Choose Destination Location window
For this installation, we used Tivoli as the password (see Figure A-7 on
page 313). Be sure to write down the password you entered, as you will need this
later. Select Next.
312
Figure A-7 User name and password
Click on Yes for the new user ID to be created (Figure A-8).
Figure A-8 User name creation dialog box
After selecting Next (see Figure A-9 on page 314), the installation will start
copying files and will then start the DB2 installation.
313
Figure A-9 Start Copying Files window
Select Do not install the OLAP Starter Kit and press the Continue button
(Figure A-10).
Figure A-10 Install OLAP Starter Kit window
314
When you click on Finish (Figure A-11), you should see the window shown in
Figure A-12.
Figure A-11 Setup Complete window
Figure A-12 Installation complete
Click Exit on this screen.
315
The next dialog box is about Product Registration. For this demonstration, we do
not register the product and directly exit the process.
Upgrading to DB2 FixPack 7

DB2 FixPack7 is included on the Identity Manager media on Supplemental Disk
2. Log on to the system as db2admin to complete this step.
Start the Windows Control Panel and double click on Administrative Tools.
Double-click on Computer Management and click on the plus sign in front of
Services and Applications, as shown in Figure A-13.
Figure A-13 Computer Management window
Select Services and stop all DB2 processes. Highlight one of the DB2 services
in the right window and stop the process.
316
This can be done by either:

Right-clicking on the highlighted services to be stopped and selecting Stop.
Highlight the services to be stopped and select the Stop button in the menu
immediately above this window (square).
The services window should look like the one displayed in Figure A-14 before
proceeding (all DB2 processes are stopped).
Figure A-14 Services Control window
Next install the DB2 Fix Pack. Select the Next button, as shown in Figure A-15
on page 318.
317
Figure A-15 Choose Destination Location window
Type in the password you entered during the initial DB2 install and select Next
(see Figure A-16).
Figure A-16 Defining a local warehouse control database
318
If you get the error shown in Figure A-17, you need to log out and back in again
as db2admin.
Figure A-17 Error pop-up window
Click on Next for the upgrade to begin, as shown in Figure A-18.
Figure A-18 Start Copying Files window
Finally, click on Finish to restart the system after the upgrade has been
completed.
319
DB2 configuration
Log on to the system as Administrator and stop all DB2 processes, as explained
in Upgrading to DB2 FixPack 7 on page 316.
Configuring DB2 for JDBC and JTS

Select Start Run from the menu, browse to the directory C:\Program
Files\SQLLIB\java12 and select the file userjdbc2.bat. Select Open and verify
the entry, as shown in Figure A-19.
Figure A-19 JDBC2 Batch File Screen
Select OK.
After the JDBC configuration has finished, restart the DB2 process using the
services panel shown in Figure A-20 on page 321.
320
Figure A-20 Services Control manager with DB2 Services Started
We need to use the DB2 Control Center for the operations shown in the following
screenshots. In order to start the Control Center, select Start Programs
IBM DB2 Control Center.
Right-click on the DB2 instance and select Configure (Figure A-21 on
page 322).
321
Figure A-21 Control Center and Configure windows
322
Select Use the TP monitor named below' and select JTS from the TP Monitor
pull-down list. Then click Finish (see Figure A-22).
Figure A-22 Specify a transaction processing monitor window
Select Close and exit the DB2 Control Center (Figure A-23).
Figure A-23 DB2 Message window
323
Confirm TCP/IP communications for DB2

Start a DB2 Command Window by selecting Start Programs IBM DB2
Command Window.
Run the command below to test the setup and verify the capture shown in
Figure A-24:
db2set -all DB2COMM
Figure A-24 Confirmation of DB2 connectivity
Identity Manager database creation and configuration

Using the command window shown in Figure A-24, enter the following command
to create the itim database for Identity Manager (see Figure A-25 on page 325):
db2 create db itim using codeset UTF-8 territory US
324
Figure A-25 Configuring DB2 for Tivoli Identity Manager
Set the DB2 heap size with the following command (see Figure A-26):
db2 update db cfg for itim using applheapsz 256
Figure A-26 Heap size configured
325
Configure the DB2 catalog by using the following command (see Figure A-27):
db2 catalog tcpip node db2node remote <servername> server 50000
Figure A-27 DB2 Catalog set
Create database instance and test configuration

Connect to the Identity Manager database to test the installation by using the
following command (see Figure A-28 on page 327):
db2 connect to itim
326
Figure A-28 DB2 connection to database itim
To test logging in as a user, enter the following command (see Figure A-29):
db2 connect to itim user <account> using <password>
Figure A-29 Logging on to Identity Manager database
327
If you see results that are similar to Figure A-29 on page 327, everything is
configured correctly. Proceed with the install. If something is not correct, stop and
correct the problem.
Steps to uninstall DB2

Log on as Administrator and select Start Settings Control Panel.
Double click on Add/Remove Programs and select IBM DB2. Select Remove
and answer Yes, as shown in Figure A-30.
Figure A-30 Removing DB2
328
Clean up directories and delete DB2Admin user

Start up the Windows Explorer and delete the following directories, as shown in
Figure A-31:
C:\DB2
C:\DB2CTLSW
C:\DB2LOG
Figure A-31 Windows Explorer showing DB2 subdirectories
Delete the db2admin user by selecting Start Settings Control Panel.

Double-click on Administrative Tools and double-click on Computer
Management. Click on the plus sign in front of Local Users and Groups and
click on the Users folder under Local Users and Groups, as shown in
Figure A-32 on page 330.
329
Figure A-32 User Management Console
Right-click on the user db2admin on the right side of the screen and select
delete.
Install IBM Secureway LDAP 4.1

Unzip the file IBMDIR410_WINDOWS_US in the IDS410 folder from the
supplemental disk 1. In our example, we unzipped the file into the install-ldap
subdirectory on drive c.
Go to the directory where you extracted this image and then open up the ismp
folder and run setup, as depicted in Figure A-33 on page 331.
330
Figure A-33 LDAP Directory Server installation files
Select the correct language; in our example, shown in Figure A-34, it is English.
Figure A-34 Language selection
Click on Next (Figure A-35 on page 332).
331
Figure A-35 Welcome window
Accept the terms in the license agreement and click Next (Figure A-36 on
page 333).
332
Figure A-36 Software License Agreement window
The system detects that you have DB2 already installed (see Figure A-37 on
page 334). Click on Next.
333
Figure A-37 DB2 already installed
Accept the default installation location (Figure A-38).
Figure A-38 Default installation location
334
Select English as the language for IBM Directory Server (Figure A-39). Note this
language selection needs to match the language you selected earlier during the
DB2 installation.
Figure A-39 Language selection
Accept the default of Typical and click on Next (Figure A-40 on page 336).
335
Figure A-40 Typical install
Accept the defaults here as well. Click on Next to proceed (Figure A-41).
Figure A-41 Features to install
336
Enter a user ID that already exists on the system and its password. In our
example, we used Administrator (Figure A-42). Note that this is only a demo
machine; for a production system, you should use a different account. Click on
Next.
Figure A-42 User ID and password
Enter a password for the LDAP administrator account. Make sure to write this
down, as you will need this later. In our example (Figure A-43 on page 338), we
used passw0rd as the password. Click on Next.
337
Figure A-43 Administrator password
Click on Next (Figure A-44).
Figure A-44 Review settings
Select OK to continue (Figure A-45). This will install the IBM SSL GSKit.
338
Figure A-45 GSKit Installation
Select OK to continue (Figure A-46). This installs the IBM HTTP Server.
Figure A-46 HTTP Installation
Select Next. This is the Readme for the LDAP client (Figure A-47).
Figure A-47 Readme for LDAP client
Select Next. This is the Readme for the LDAP Server (Figure A-48 on page 340).
339
Figure A-48 Readme for LDAP Server
Accept the default to restart your system (Figure A-49). Click on Next.
Figure A-49 Restarting the system
Click on Finish (Figure A-50 on page 341). This reboots the system.
340
Figure A-50 Installation finished
Configuration of the IBM Secureway LDAP v4.1

After the system has rebooted, log on as a privileged user, for example,
Administrator. The system automatically configures LDAP after you have logged
on and a status window showing the configuration progress is displayed. Do not
interfere with this process. Once this process is completed, the status window
will be closed.
In order to configure the IBM Directory Server, you need to edit the file
slapd32.conf. If you installed LDAP into the default directory, the file is located in
c:\Program Files\IBM\LDAP\etc.
We are using MS WordPad to edit the file, as shown in Figure A-51 on page 342,
but you can also pick an editor of your choice.
341
Figure A-51 LDAP configuration in WordPad
342
Add the line:

ibm-slapdSuffix: dc=com
below
ibm-slapdSuffix: cn=localhost
We recommend using the Find function to locate the line ibm-slapdSuffix.
Starting the LDAP Directory

Bring up the Windows Services window. We recommend changing the default
startup type of IBM Directory Server Version 4.1 from Manual to Automatic.
Double click on IBM Directory Server Version 4.1 and a configuration GUI comes
up (see Figure A-52 on page 344). Change the startup type to Automatic and
select Apply.
In order to be able to start up IBM Directory Server Version 4.1, two other
processes have to be already running. These are DB2 - DB2 and DB2 LDAPDB2. Note that both of these processes are configured to automatically
start at boot time.
This time, you need to start the IBM Directory Server Version 4.1 process
manually.
343
Figure A-52 Services Control panel with IBM Directory Server started
Next, we need to add our suffix object to LDAP by selecting Start Programs
IBM Directory Server 4.1 Directory Management Tool. This should
bring up the window shown in Figure A-53 on page 345.
344
Figure A-53 IBM Directory Management Tool Introduction window
Next, we need to authenticate to the IBM Directory Server. Select Rebind, which
is under Introduction/Server/Rebind, as shown in Figure A-54 on page 346.
345
Figure A-54 Rebind window
Select Authenticated and fill in the User DN field with cn=root and the User
password field with passw0rd, as shown in Figure A-55 on page 347.
346
Figure A-55 Authentication
Ignore the message shown in Figure A-56 and select OK.
Figure A-56 Directory Message Panel
Select Add on the right menu bar shown in Figure A-57 on page 348.
347
Figure A-57 Ready window
Select Domain from the Entry type menu. Leave Parent DN: blank and enter
dc=com in the Entry RDN: field, as shown in Figure A-58. Click OK.
Figure A-58 Add an LDAP Entry window
Select Add and exit from the Directory Management Tool, as shown in
Figure A-59 on page 349. You need to stop and restart LDAP to have the
changes take effect.
348
Figure A-59 Add an LDAP Entry: Attributes
Change the LDAP port to support Active Directory

We plan on installing Active Directory (AD) on this machine at some point. Since
AD uses port 389 (usually the default LDAP port), we need to configure LDAP to
use a different port.
Open C:\Program Files\IBM\LDAP\etc\slapd.conf with your editor, as shown in
349
Figure A-60 slapd32.conf in WordPad
Add the line:

ibm-slapdPort: 4000
We recommend using the Find function to locate the line ibm-slapdPort: 389.
Save the file.
Now we are ready to install the Identity Manager components.
Install Identity Manager components

Several components that are bundled with the Identity Manager base software
package, IBM WebSphere, and IBM MQSeries, are installed during the Identity
Manager installation.
350
Create Identity Manager user

Select Start Programs Administrative Tools Computer
Management.
Open Local Users and Groups and select the User folder, as shown in
Figure A-61.
Figure A-61 User Management Console creating Identity Manager
With the User folder highlighted, select Action New User or right-click on the
right side of the panel and select New User, as shown in Figure A-62 on
page 352.
351
Figure A-62 New User Dialog
In the User name: field, enter enrole.

In the Password field, enter passw0rd.
De-select the User must change password at next logon option.
Select Password never expires.
Click on Create and then on Close. Exit the computer management console.
Installing Identity Manager

When we install Tivoli Identity Manager, it automatically installs IBM WebSphere
Advanced Edition Single Server and IBM MQSeries, and all the required
maintenance packs.
Log on as a privileged user, for example, as Administrator.
352
Run the setup executable instW2k.exe. This file is located either in the folder
where you have unzipped the base CD or on the Base CD itself, if you have this
media. The installer should start, as shown in Figure A-63.
Figure A-63 Installer starting
Select I accept the terms of the License Agreement and click Next
(Figure A-64).
Figure A-64 License Agreement window
353
Accept the default for Single Server and click Next (Figure A-65).
Figure A-65 Choose the Installation Type window
Accept the default location of C:\itim and click on Next (Figure A-66 on
page 355).
354
Figure A-66 Choose Install Folder window
Install WebSphere, accept the default, and click Next (Figure A-67 on page 356).
355
Figure A-67 WebSphere AES 4.0 installation window
Select MQSeries install location, accept the default, and click Next (Figure A-68
on page 357).
356
Figure A-68 MQSeries installation window
Click on Install, as shown in Figure A-69 on page 358. At this point, Tivoli
Identity Manager and IBM WebSphere FixPack 4 will be installed, and Tivoli
Identity Manager will be deployed to WebSphere. This process will take a few
minutes.
357
Figure A-69 IBM Middleware Pre-install Summary window
Enter DB2 connection information

The next steps show the Identity Manager database connection configuration.
In the window shown in Figure A-70 on page 359, do the following:
1. Enter itim into the Database Net Service Name: field.
2. Enter db2admin into the Admin ID: field.
3. Enter passw0rd into the Admin Password: field.
4. Click on Test.
Note: Make sure that IBM Directory Server Version 4.1 is running.
358
Figure A-70 Input database information and test connection
Click on OK (Figure A-71).
Figure A-71 Database connection is successful message
Fill in the User Password: with the password you entered when you created the
enrole user; in our example, this was passw0rd. Click on Continue (Figure A-72
on page 360).
359
Figure A-72 Input user password and continue to configure database
Click on OK (Figure A-73).
Figure A-73 Configuration complete
Enter LDAP connection information

The next steps show the Identity Manager LDAP connection configuration.
After you enter the information shown in Figure A-74 on page 361, click on Test.
We need to change the port if we want to run AD on this system, as it will use
port "389".
360
Figure A-74 Input LDAP Server Information
You will get the pop-up window shown in Figure A-75. Click on OK.
Figure A-75 Directory connection successful message
In the window shown in Figure A-76 on page 362, enter the name of your
organization that will show up in the Identity Manager Organization structure; in
our example we use Tivoli Engineers. Enter the short name or abbreviation of
your organization name (tiv). Finally, enter the LDAP Distinguished Name (DN)
location. This needs to match the value you entered into the slapd32.conf file and
the suffix you created in LDAP. In our example, the value is dc=com. Click on
Continue.
361
Figure A-76 Input Directory Information window
The pop-up window in Figure A-77 will appear. Press OK to finish.
Figure A-77 LDAP configuration is successful
Identity Manager System configuration

The next steps show the Identity Manager system configuration.
The System Configuration dialog starts with the screen shown in Figure A-78 on
page 363.
362
Figure A-78 System Configuration: General tab
Click on the Mail tab. Change the value of Mail From: to

Administrator@machinename. In our example, shown in Figure A-79, we use
Mail From: Administrator@pooh. Click on Apply and then on OK.
Figure A-79 System Configuration: Mail tab
363
You should get the pop-up window shown in Figure A-80 on page 364. Click on
OK.
Figure A-80 Rebooting the system
You should then get the window shown in Figure A-81. Click on Done.
Figure A-81 Install Complete
Now you need to reboot your system to have all the changes take effect.
364
Install MQSeries 5.2 CSD05

On supplemental disk 1, in the location where you unzipped it, open the directory
MQ52CSD5 and double-click on U200169A to install MQSeries 5.2 CSD05. You
should get the window shown in Figure A-82.
Figure A-82 MQSeries Server for Windows NT: InstallShield Wizard
Important: Make sure you have a Microsoft Windows 2000 Server with SP2
installed.
Make sure that all MQSeries processes are stopped. Bring up the Task Manager
and see if there are any MQSeries processes showing. If there are, stop them,
then start the MQSeries 5.2 CSD05 install again. Click Next to continue. You
should get the window shown in Figure A-83 on page 366.
365
Figure A-83 Location to Save Files
Accept the default location and click on Next. You should get the window shown
in Figure A-84 on page 367. Click on Next.
366
Figure A-84 IBM MQSeries CSD setup welcome screen
You should get the window shown in Figure A-85 on page 368. Click on Next.
367
Figure A-85 Rollback
You should get the window shown in Figure A-86. Click on Next.
Figure A-86 Start Copying Files
368
You should get the window shown in Figure A-87. Click on Finish and reboot the
system. Then, log on as a privileged user, for example, Administrator.
Figure A-87 Installation complete
Final configuration of Identity Manager processes

Check that all of the following Identity Manager processes are running:
DB2 - DB2
DB2 - LDAPDB2
DB2 JDBC Applet Server
IBM Directory Server Version 4.1
IBM HTTP Administration
IBM HTTP Server
IBM MQSeries
We recommend you run IBM WebSphere as a service and configure it to start

automatically when the system is booted.
369
Steps to run WebSphere as a service

The advantages to running IBM WebSphere as a Windows service are:
It automatically starts at boot time.
Runs independent of a user and runs whether or not a user is logged on.
Start a command line window and enter the following command:

c:\> WASService -add "ITIM Manager"
Now open the Windows Services console and select the IBM WebSphere
Application Server V4 - ITIM Manager service. To have this service start
automatically at boot time, double click on the IBM WebSphere Application
Server V4 - ITIM Manager service and change Startup type to Automatic. click
on Apply and then OK.
Manual process to start WebSphere

You can also start IBM WebSphere manually by selecting Start Programs
IBM WebSphere Application Server V4.0 Start Application Server.
Note: You have to do this each time you start up the system. When you start
IBM WebSphere this way and the user logs off the system, the application
would stop.
Configure LDAP referential integrity plug-in with file option

In order to configure the LDAP referential integrity plug-in for Tivoli Identity
Manager we need to follow these steps:
1. Copy C:\itim\lib\nt\libdelref.dll to C:\Program Files\IBM\LDAP\bin.
2. Copy C:\itim\config\ldap\ibm\timdelref.conf to C:\Program
Files\IBM\LDAP\etc.
3. Open slapd32.conf with your editor.
4. Search for ibm-slapdPlugin: database /bin/libback-rdbm.dll
rdbm_backend_init and add the following line below this line, as shown in
ibm-slapdPlug: preoperation /bin/libdelref.dll DeleteReferenceInit
file="C:\itim\config\ldap\ibm\timdelref.conf" dn=dc=com
This line should be one line.
370
Figure A-88 slapd32.conf file
5. Restart the machine.
Verify Identity Manager installation

In order to verify the correct installation for Identity Manager, enter the following
URL into your browser:
http://<servername>/enrole/logon
As shown in Figure A-89 on page 372, enter the following information:

User ID: ITIM manager
Password: secret
371
Figure A-89 IBM Tivoli Identity Manager log-on page
Congratulations! Identity Manager is installed and configured correctly.
Configure Windows "loopback" interface

In this section we describe the necessary steps to configure the Windows 2000
TCP/IP "loopback" interface, which is required if you need to run the software
and are not connected to any network.
Follow these steps:
1. Open My Computer Properties, go to the Hardware tab, and select the
Device Manager.
2. Double-click on the Ethernet Controller under Other Devices.
3. Select Reinstall Driver and then click on Next.
372
4. Select Display a list ..... and then click on Next.

5. Select Network adapters and then click on Next.
6. Select Microsoft in the Manufacturers list and then select Microsoft
Loopback Adapter in the Network Adapter list. Click on Next.
7. Click on Yes, click on Next, click on Finish, and click on Close.
Finally, you need to go to Settings Network and Dial-up Connections and
configure the new loopback interface.
Uninstall all Identity Manager components

Here are the steps necessary to uninstall the Tivoli Identity Manager software:
1. Click on Start Settings Control Panel and double-click on
Add/Remove Programs.
2. Click on Tivoli Identity Manager and select Change/Remove.
3. Select Uninstall.
4. Click on Done.
5. Select IBM WebSphere Application Server 4.0 AES from the Add/Remove
Programs window and click on Change/Remove.
6. Click on Yes to the question "Are you sure you want to uninstall this product?"
7. Select No to the question "Uninstall will delete all file in the directory.
C:\Wepsphere\AppServer. Do you want to back up the configuration, logs,
and user files before you uninstall?"
Note: Make sure that the WebSphere server, IBM HTTP Server, and IBM
HTTP Administration Services are stopped before doing step 14.
8. Select OK.
9. Select IBM HTTP Server 1.3.19 and click on Change/Remove.
10.Select Yes to the question "Are you sure you want to completely remove 'IBM
HTTP Server 1.3.19' and all of its components?"
11.Select OK.
12.Select IBM Directory Server 4.1 and click on Change/Remove.
13.Accept the default language (English) and click on OK, unless you selected
another language. If you did not select a different language and wish to do so,
select it now and then click on OK.
373
14.Select Next.
15.Click on GSKit, IBM HTTP Server, Client SDK, DMT & Java, Server and
click on Next.
16.Click on Next.
17.Click on Yes to All for the question "C:\Program Files\IBM\LDAP\tmp dmt.log
exists on this system and it has been modified since the installation. Do you
want to remove this file?"
18.Click on Finish.
19.Select IBM MQSeries classes for Java and Java Message Service from
the Add/Remove Programs window and click on Remove.
20.Select Yes to "Are you sure you want to remove IBM MQSeries classes for
Java and Java Message Service from you computer?"
21.Select IBM MQSeries V5.2 from the Add/Remove Programs window and
click on Change/Remove.
22.Select Uninstall MQSeries completely and click on Next.
23.Click on Next.
24.Click on Next.
25.Click on Finish.
26.Select IBM DB2 and click on Change/Remove.
27.Click on Yes.
28.Click on Yes.
29.Click on OK.
30.Reboot the system.
31.Start up the Windows Explorer and delete the following directories:
C:\DB2
C:\DB2CTLSV
C:\DB2LOG
C:\itim
C:\LDAPDB2
C:\MQSeries
C:\WebSphere
C:\Program Files\IBM
C:\Program Files\IBM HTTP Server
C:\Program Files\SQLLIB
Make sure to empty the Recycle Bin.
374
32.Click Start Programs Administrative Tools Computer

Management and select Local Users and Groups.
33.Double-click the User folder in the right window.
34.Select the user db2admin and then right-click and select Delete. Answer Yes
when asked to confirm. Repeat this same step for the users enrole and
ldapdb2.
35.Make sure to remove all the files and folders in the Recycle Bin, then reboot
the system. Then you can reload Identity Manager.
375
376
Appendix B.
Corporate policy and

standards
Technology should not drive the corporate policy; it should be the other way
around. Once you know what you need to protect and the potential threats and
risks to those assets, you can start protecting them. First, all the threats and risks
will be classified in a study based on certain elements, such as:
Direct financial loss
Indirect financial loss (such as investigation, recovery, and so on)
Loss of confidential information
Liability
Image impact (loss of goodwill, customer loyalty, and so on)
Cost of risk mitigation and/or transfer
Accepting residual risk
This study can process the same threats and risks applied to different assets, but
concludes at a different level of liability, based on your particular business
environment. Then the decision has to be made: accept, mitigate, or transfer the
risk. This process can be handled by external consultants, such as IBM Global
Services, or by an internally appointed team. The process can use both formal
and informal methods, but the result is usually a blend of these approaches. The
threat identification, as well as this severity study, using a formal approach is
377
done in conjunction with the organization by applying a standard and a proven

methodology.
It is tempting to directly translate the threat analysis into a technical solution, but
it should first lead to the corporate policy and standards. These documents will
highlight the risks and present how they must be handled enterprise wide.
The first document that must be written is therefore the corporate policy
document. It must outline the high-level directions to be applied enterprise wide.
It is absolutely not technical; it is derived from the business of the enterprise and
should be as static as possible, as seen in Figure B-1.
Static
Corporate
Policy
Standards
Standards
Standards
Standards
ProceduresPractices
ProceduresPractices
Procedures
Technical
Figure B-1 Dynamics for policy, standards, practices, and procedures
Attention: Policies is a very common term and in many products you will find
specific policies sections. These are the product related policies that are
covered in the practice or procedure documents. The corporate policy is not
related to products and is a high level document.
378
Standards, practices, and procedures

Standards are derived from the corporate policy. They are documents explaining
how to apply the policy details in terms of authentication, access control, and so
on. They explain how the policy must be applied. Changes in threats or major
technology changes can impact them.
The standards are then mapped to practices and/or procedures.
The practices are descriptions of practical implementations of the standard on an
operating system, application, or any other end point. They will detail precise
configurations, such as the services to be installed, the way to set up user
accounts, or how to securely install software.
The procedures document the single steps to be applied to requests and the
approval and implementation flows. Such a procedure could be the request to
access a specific set of sensitive data, where the approval path (system owner,
application owners, and so on) and conditions (Virtual Private Network (VPN),
strong authentication, and so on) are explained in detail.
Tip: Approval procedures are often implemented by sending e-mails or
paperwork. The efficiency can be improved by using a computer to handle
these repetitive tasks and ensure that changes within the company are
applied quickly to the procedures. As explained later, this can reduce human
errors.
Practical example
Here is an example of how a policy is defined and implemented with procedures
and practices.
The operations manager has reported an increased workload on the help desk
due to problems caused by employees downloading non-business related
programs onto their systems.
The problems range from the introduction of viruses to disruption of business
processes, with a real financial impact. To address this problem, upper
management incorporated, in the corporate policy, the following directive: the
corporate assets may be used only to perform enterprise related tasks.
First, the policy must be communicated to all employees in the enterprise.
The standards for the networking part explain which services may be allowed on
the employee computer. The practice will then explain how to set up the
Appendix B. Corporate policy and standards
379
Windows or Linux clients according to the standards, and the procedures will
explain how to perform a request, the requirements, and the approval paths, to
get special services installed on your computer.
The existing clients will be updated and controls will be performed to verify the
compliance, in addition to further audit of the environment.
The five steps we went through are summarized in Figure B-2. It is a common
approach adopted in many methodologies.
Policies
Implement
Manage
Risk
Audit
Figure B-2 The five steps in defining your IT security
External standards and certifications

The discussion on corporate policies suggests that internal business needs are
the drivers for designing corporate policies. While this is true, there are a number
of external factors that can change these business needs and policies. Some of
these external pressures can be detailed enough to specify not only policies, but
also standards and procedures
380
Examples of these external drivers are shown in this section. The list is not
exhaustive, nor is each description complete. It is provided as a guide to the type
of standards that may (or may not) apply to your organization and, therefore,
some of the external factors you must consider when creating policies.
Many organizations use these external standards as a guide to help them
formulate their own corporate policies. It is not uncommon to find organizations
using the ISO 17799 standards, but without having them externally audited and
certified. These standards are seen as a good foundation for security.
Industry specific requirements

Some industry sectors have standards that are specific to that industry sector.
Two examples are:
Identrus
The Identrus standards are based upon standard PKI technologies for
authenticating secure transactions. In addition to the technology layers,
Identrus provides a complete infrastructure to help companies operate
effectively and safely on the Internet, across economic and political
boundaries, and with familiar business partners and new ones.
In addition to the technology standards and processes, Identrus describes an
all important set of business rules, contracts, and liabilities that create a
trusted environment particularly for use in the banking and finance sectors.
CFR 21 Part 11
21 CFR Part 11 applies to electronic records that are created, modified,

maintained, archived, retrieved, or transmitted under any records
requirements covered by Federal Drug Agency regulations.
Any pharmaceutical company that wishes to sell or market its products in
America needs to abide by these rules. Corporate policies, standards, and
processes need to reflect this requirement.
Product or solution certifications

Some products or solutions can be certified before use so that a potential
purchaser has an understanding that the product or solution will fit the role it is
needed for.
Common Criteria
This is a set of tests originally based upon the US Orange book and
European/Australian ITSEC evaluations. It is currently recognized by 14
countries. There are seven levels of tests. Evaluation Assurance Levels (EAL) 1
- 4 are usually used in the commercial areas, while the tests representing the
381
higher EALs 5 - 7 are reserved for the security testing of highly secure
environments.
CAPS UK
In addition to internationally recognized evaluations, there maybe local
evaluations that impact an organization. The UK Government's
Communications-Electronic Security Group (CESG) have produced the Assisted
Products Scheme in effort to help commercial product vendors produce
cryptographic products suitable for use by the British government. It is called
CAPS (CESG Assisted Product Scheme). CAPS is similar in purpose to the FIPS
140 (for the US and Canadian governments) and the Cryptographic Advisory
Note (CAN) (for the Australian and New Zealand governments).
Nationally and internationally recognized standards

Some standards bodies publish broad general sets of standards that an
organization can implement. These standards can be audited and hence the
organization can be sure they are complying
BS7799
The most widely known standard. British standard (BS) 7799 and its international
cousin ISO17799 are intended to serve as a single reference point for identifying
a range of security controls, needed for most situations, where information
systems are used in industry and commerce within large, medium, and small
organizations. BS7799 was written in February 1995 and was updated in May
1999.
BS 7858
BS 7858 is just one example of some of the other less, well known standards that
could affect security policy. Specifically, BS 7858 gives recommendations for the
security screening of personnel to be employed in an environment where the
security of people, goods, or property is a significant feature of the employing
organization's operations.
Legal requirements
The laws of the country in which an organization operates are many and diverse.
The application of the laws is variable from geography to geography, and it is
good to be aware of the impact of them upon corporate security policies. Modern
democracies are often fond of creating freedom of information laws. One of the
problems with these laws are that they are directly contrary to the same
democracies wish to maintain the privacy of individual information.
382
Privacy law is, therefore, a growing area. Some examples are:

UK Data Protection Act 1998
An act to make new provisions for the regulation of the processing of

information relating to individuals, including the obtaining, holding, use, or
disclosure of such information.
European Data Directive 95/46/EC
This directive and others give direction to issues surrounding the protection of
individuals with regard to the processing of personal data and on the free
movement of such data. The way they interact with national law must also be
considered.
US Health Insurance Portability and Accountability Act 1996
The Health Insurance Portability and Accountability Act 1996 (HIPAA) was
passed by the United States Congress to ensure the privacy of an individuals
private medical data.
Summary
Corporate policies must be thought of as business level requirements. They are
primarily internal business drivers, but they may be impacted upon by external
factors, so corporate policies will have to take account of these factors.
Subsidiary standards and the procedures and practices that result in turn are
also produced.
Corporate policies should be relatively static and technology free, while
standards, practices, and procedures can be more fluid and technology specific.
383
384
Appendix C.
ROI questionnaire
This appendix contains an example of the list of questions an organization
should consider when submitting information for an ROI study. This list is taken
from the ROI tool used by IBM Tivoli Security and System Management
specialists. The questionnaire is typically given to an organization some time
before a series of interviews takes place. The interviews serve to clarify some of
the answers, and also to find out some of the particular organizations special
requirements that could have an impact on the ROI.
Typically, the result of these interviews and the questionnaires are used to
provide the raw data for the ROI calculation. Not every organization will have the
answers to all the questions, so a number of industry standard default figures are
provided. Typically, these tools should be available in a number of international
currencies, complete with default answers specific to that country.
385
IBM Tivoli ROI analyst questionnaire

The ROI analyst questionnaire covers a total of seven sections, which are
described in more detail in this appendix:
Introduction
Tivoli Solutions
Performance and availability
Configuration and operations
Security management
Storage management
Additional information
Part 1: Introduction
1. Please specify the following details about your organization:
Company name
Division
Contact name
Address
City, State/Province
Zip/Postal Code
Country
Phone number
E-mail address
Strategic Business Initiatives
2. Please indicate which strategic business initiatives are relevant to your
company and towards which Tivoli can assist:
Risk Management: Reducing the risk to the business and user productivity
Measures:
386
Application Level Availability
Security Intrusion Protection
Application Security Enablement
Business Continuance
Time-to-Market
Quality of Service: Improving the measurable and perceived quality of IT

in meeting business unit and customer requirements
Measures:
Customer Satisfaction
User Satisfaction
Problem Rates
Responsiveness
Resolution
Availability
Service Level Performance
IT Best Practices: Reducing IT costs and increasing capability without

increasing staff
Measures:
Strategic Staff Reallocation
Labor Savings
Growth and Change Cost Avoidance
Attrition and Training Savings
IT Capital Cost Reduction
Support Contract Savings
Strategic Advantage: Increasing revenue, brand, and market share

Measures:
Increased innovation/decreased housekeeping
IT Enabling Business Systems
Maximizing Web Performance
Optimizing Campaigns
Customer experience/performance
Web transaction responsiveness and effectiveness
3. Please specify the following details about your current enterprise users:
How many computer users are in the enterprise? _____________
What is the expected annual growth in the number of users? _______ (%)
What is your average annual revenue per employee? $______/employee
How many client computers are currently installed? _____________
Appendix C. ROI questionnaire
387
4. Please specify the following details about your current enterprise servers.
Table C-1 How many enterprise servers are currently installed
Type of server
Number of servers
currently installed
Number of processors
Web
Database
Messaging
Application and
middleware
File/print and others
5. Please specify the following details about your technology and management
practices:
Estimate your best practices compared to your peers (specify one: best in
class, better than average, average, slightly less than average, less than
average)
Technology / Tools: ______________
Integration effectiveness: ______________
Process maturity: _____________
Estimate information about your computing environment compared to your
peers (select one: very high, high, average, lower than average, very low)
Business impact dependency: _______________
Complexity: _________________
6. Please specify the following details about your current staff headcount:
Table C-2 Full time equivalent staff managing IT functions/supporting the enterprise
Total FTE
Performance and Availability staff FTEs
Configuration and operations staff FTEs
Security Management staff FTEs
Storage Management Staff FTEs
Incident and Problem Management Staff
FTE
388
Average unburdened
salary
Note: Incident and Problem Management FTEs include full time IT

staff, contractors, part time resources, and business unit personnel
performing support tasks.
7. Please specify the following details about your current support services:
Table C-3 Specify the value of your annual support contracts (if any)
Annual support contracts
Annual support fees
Service Desks
PC Desktop Support
Host outsourcing
8. Please specify the following details about your informal support:

What is the current expenditure by business unit users on informal support
(hours per user per month)? ______________________ (Informal support is
users supporting peers in lieu of calling formal support, which costs typical
companies an average of two hours per user per month)
Part 2: Tivoli Solutions

Which Tivoli Solutions are you interested in implementing and including in this
analysis?
Performance and Availability
IBM Tivoli Business Systems Manager

IBM Tivoli Service Level Advisor
IBM Tivoli Web Site Analyzer
IBM Tivoli Enterprise Console
IBM Tivoli Monitoring
IBM Tivoli Monitoring for Applications
IBM Tivoli Monitoring Active Directory Option
IBM Tivoli Monitoring for Databases
IBM Tivoli Monitoring for Messaging & Collaboration
IBM Tivoli Monitoring for Business Integration
IBM Tivoli Monitoring for Web Infrastructure
IBM Tivoli Monitoring for Transaction Performance
389
IBM Tivoli Manager for Sybase

IBM Tivoli Manager for MS SQL
IBM Tivoli Management Solution for MS SQL
IBM Tivoli Manager for Exchange
IBM Tivoli Management Solution for Exchange
IBM Tivoli Netview
IBM Tivoli LAN Switch Analyzer
IBM Tivoli Comprehensive Network Address Translator
Configuration and Operations
IBM Tivoli Workload Scheduler

IBM Tivoli Workload Scheduler for Applications
IBM Tivoli Configuration Manager
IBM Tivoli Remote Control
IBM Tivoli Point-of-Sale Manager
IBM Tivoli Data Exchange
IBM Tivoli Self-Service Terminal Manager
Security
IBM Tivoli Risk Manager

IBM Tivoli Access Manager for e-business
IBM Tivoli Access Manager for Business Integration
IBM Tivoli Access Manager for Operating Systems
IBM Tivoli Intrusion Manager
IBM Tivoli Privacy Manager
Storage
IBM Tivoli Storage Manager

IBM Tivoli Storage Manage Enterprise Edition
IBM Tivoli Storage Manager for Mail
IBM Tivoli Storage Manager for Application Servers
IBM Tivoli Storage Manager for Databases
IBM Tivoli Storage Manager for Enterprise Resource Planning
IBM Tivoli Storage Manager for Hardware
390
IBM Tivoli SANergy

IBM Tivoli Storage Network Manager
Part 3: Performance and availability

1. Please specify the following details about your current performance and
availability staff:
Specify the full time equivalent staff managing performance and availability
(include full time IT staff, contractors, part time resources, and business unit
personnel performing tasks).
Table C-4 Full time equivalent staff managing performance and availability
Performance and Availability Staff
Percentage of time spent on task (%)
Business System Management

Database Management
Application Administration
Web Management
Messaging Management
System Management
Network Management
Service Level Management
Total
100%
What is the expected annual growth in Performance and Availability Staff

FTEs? ______________(%)
2. Please specify the following details about your availability:
What is the current availability of specific enterprise applications/systems to
be managed by Tivoli Performance and Availability solutions?
391
Table C-5 Current availability of specific enterprise applications/systems
System
application
Application
name
Application
type
Availability
Operational
hours
per day
Operational
days
per week
Impact per
downtime
minute
App 1
App 2
App 3
App 4
App 5
App 6
App7
For reference, the following are industry average Impact per Downtime
Minute metrics that can be used.
Table C-6 Impact per downtime minute metrics
Downtime impact by application
$ Loss per minute of unplanned downtime
Financial/Trading
$40,000
Supply Chain
$10,000
ERP
$10,000
CRM
$8,000
E-Commerce
$8,000
E-Business
$8,000
Business Application
$5,000
Database
$5,000
Messaging
$1,000
Infrastructure
$700
What is your estimated annual increase in downtime impact per minute?

_________(%)
3. Please specify the following details about your service level management:
What are your estimated annual service level penalties from business
units? $________________________
What is the annual trend in service level penalties? ________(%)
392
Part 4: Configuration and operations

1. Please specify the following details about your configuration and operations
staff:
Specify the full time equivalent staff managing the IT configuration and
operations (include full time IT staff, contractors, part time resources, and
business unit personnel performing tasks):
Table C-7 Full time equivalent staff managing the IT configuration and operations
Configuration and operation staff
Business System Management

Application Administration
Software Distribution and control
Asset Management
Total
100%
What is the expected annual growth in Configuration and Operations Staff

Growth? _________(%)
2. Please specify the following details about your availability:
What is the current availability of specific enterprise applications/systems to
be managed by Tivoli Configuration and Operations solutions?
Table C-8 Current availability of specific enterprise applications/systems
System
application
Application
name
Application
type
Availability
Operational
hours
per day
Operational
days
per week
Impact per
downtime
minute
App 1
App 2
App 3
App 4
App 5
App 6
App7
393
For reference, the following are industry average Impact per Downtime
Minute metrics:
Table C-9 Impact per downtime minute metrics
Downtime impact by application
$ Loss per minute of unplanned downtime
Financial/Trading
$40,000
Supply Chain
$10,000
ERP
$10,000
CRM
$8,000
E-Commerce
$8,000
E-Business
$8,000
Business Application
$5,000
Database
$5,000
Messaging
$1,000
Infrastructure
$700
What is your estimated annual increase in downtime impact per minute?

_________(%)
Part 5: Security management

1. Please specify the following details about your security management staff:
Specify the percent of time spent on these Security Management tasks:
Table C-10 Percent of time spent on security management tasks
Security management staff
Policy Management
Intrusion Detection
Repair and Resolution
Forensics
Counter Measures
Auditing and reporting
Other
394
Security management staff
Total
100%
What is the anticipated growth in Security Management Staff? ________(%)

2. Please specify the following details about your security risks:
Specify the requested information for specific Security Risks:
Table C-11 Security risk information
Security
threat
Expected
number of
incidents
Number of
users/
customers
effected
Average
length of
downtime
(hours)
Downtime
cost per
user/customer
(per hour)
Additional
business loss
risk
Denial of
service
Intentional
data
destruction
Theft of
proprietary
information
Illegal
systems
access
(outsider)
Illegal
systems
access
(insider)
What is your estimated annual increase in security risk or downtime impact

per minute? _________(%)
3. Please specify the following details about your application security
development:
How many new/modified applications require security development each
year?
Year 1: _____________
Year 2: _____________
Year 3: _____________
395
What is the total application development time (in person hours) spent on
overall application development and maintenance annually (total, not just
security)?
Year 1: _____________
Year 2: _____________
Year 3: _____________
Of this development activity, on average, what is the per application

security development effort (person hours)? (%)
Year 1: _____________
Year 2: _____________
Year 3: _____________
Per application, what is the average security development time (in

weeks)?
Year 1: _____________
Year 2: _____________
Year 3: _____________
What is the estimated average annual value of these applications to the

organization in terms of business revenue or increased user productivity?
Year 1: $____________
Year 2: $_____________
Year 3: $_____________
4. Please specify the following details about your current new user profile
management:
How many new users need security access per year (Includes new users
being added because of growth and attrition)? _________________
What is the average annual change in new users needing access?
_________(%)
How many users require modified profiles each year (updates because of
promotions, relocations, and so on)? ______________
What is the average annual change in modified profiles?
_______________(%)
What is the typical Work Delay for new users to Receive Access?
____________ (hours)
396
5. Please specify the following details about your current password resets:
How many total number of help desk calls are fielded per user per month
(average 1.9 calls per user per month)? ________________
What is the average cost per help desk call (average $17.00 )?
______________
What percentage of all of the calls is password related (average 16%)?
_____________ (%)
How much lost productivity time is experienced in resolving password
issues (on average, 30 minutes)? ___________________
Part 6: Storage management

1. Please specify the following details about your current storage profile:
What is the Server and Network Storage Profile in the enterprise?
Total Server / Network Storage Capacity: __________ (GB)
Annual Storage Growth (75% on average): _________(%)
Total Used Storage Capacity per Server (60% on
average)_____________(%)
2. Please specify the following details about your storage administration staff:
Specify the percent of time spent on these storage management tasks:
Table C-12 Percent of time spent on storage management tasks
Storage administration staff
Capacity and Performance Management

Disaster/Contingency Planning
Backup Administration
Data Restore
Tape Administration
Archiving
Other
Total
100%
What is the expected growth in Storage Administration Staff?

____________(%)
397
3. Please specify the following details about your current data and backup
investment:
What amount of Server Data could be moved from online storage, and be
kept near line (on average, 20%)? ________(%)
What amount of Server Data could be moved from online storage to
Archive (on average, 20%)? __________(%)
What is the planned investment in tape drives, libraries, and tapes over
the next 12 months? $________________
What is the planned investment in network for backup bandwidth over the
next 12 months? $__________________
What is the annual growth in planned network investment?
____________(%)
What is the annual growth in planned tape investment?
______________(%)
4. Please specify the following details about your current restore profile servers:
How many Server Data Restores are conducted per month?
_____________
What is the average time it takes to complete each server restore?
___________ (hours)
What is the expected lost productivity/business per restore hour?
$_______________
5. Please specify the following details about your current restore profile - clients:
How many client data restores are conducted per month? _____________
What is the average time to complete each client restore? ____________
(hours)
What is the estimated annual increase in risk or downtime impact per
minute? ___________(%)
6. Please specify the following details about your current server backup issues:
What is the average amount of server data left unprotected due to backup
window issues (per week)? ______________(%)
How much additional server data is currently not backed up reliably every
evening/week? ______________(%)
For this server data, what is the risk of data loss in any given year?
________(%)
What is the average time to re-create, recover, or work around lost data
(hours per GB)? ________________ (hours)
398
What is the estimated business/productivity loss per hour during

restore/recovery/workaround downtime? $__________________
What is the estimated annual increase in risk or downtime impact per
minute? ___________(%)
7. Please specify the following details about your current client backup issues:
What is the average storage capacity per client? _________ (GB)
What is the average Client Data Storage Used? ____________(%)
How much of the client data is currently not backed up reliably?
_________(%)
What is the Risk of Data Loss with the client data in a given year?
_________(%)
What is the average time to re-create, recover, or work around lost data?
_________________ (hours per GB)
Part 7: Additional information

1. What is your company's cost of capital (average 9.5% in U.S.)?
___________(%)
2. What are the average salaries of IT staff?
Table C-13 Average salaries of IT staff
Title
Salary
Business management
System administrators
Network administrators
Storage administrators
BAckup administrators
Database administrators
Security managers
Application managers
Operations administrators
Messaging administrators
Procurement specialists
Project managers
399
Title
Salary
Application developers
Service desk
Technical support specialists
What is the average fee paid for IT outsourced staff (consultants)?

_____________
3. For the IT staff, specify the following salary factors:
Burdened Salary (taxes, health care, sick time and vacation - average
35% in U.S.): ____________________
Salary Increase (average 4% in U.S.): _________________
Hours Worked per Year (average 1,880 in U.S.): ______________
This concludes the overview of an ROI assessment questionnaire.
400
Glossary
CSV In computers, a CSV (comma-separated
values) file contains the values in a table as a series
of ASCII text lines organized so that each column
value is separated by a comma from the next
column's value and each row starts a new line.
Here's an example:
Doe,John,944-7077
Johnson,Mary,370-3920
Smith,Abigail,299-3958
A CSV file is a way to collect the data from any table
so that it can be conveyed as input to another
table-oriented application. Spreadsheet programs or
relational database applications can read CSV files.
A CSV file is sometimes referred to as a flat file.
DAC Discretionary access control (DAC) is used
to control access by restricting a subject's access to
an object. It is generally used to limit a user's access
to a file. In this type of access control, it is the owner
of the file who controls other users' accesses to the
file. Using a DAC mechanism allows users control
over access rights to their files. When these rights
are managed correctly, only those users specified
by the owner may have some combination of read,
write, execute, and so on, permissions to the file.
DAML DARPA Agent Markup Language is a

markup language for the U.S. Defense Advanced
Research Project Agency (DARPA) that is based on
the Extensible Markup Language (XML). DAML is
designed to have a greater capacity than XML for
describing objects and the relationships between
objects, to express semantics, and to create a higher
level of interoperability among Web sites. As the
central research and development agency for the US
Department of Defense, DARPA was instrumental in
the creation of the Internet and many of its
technologies. DARPA is developing DAML as a
technology with intelligence built into the language
through the behaviors of agents, programs that can
dynamically identify and comprehend sources of
information, and interact with other agents in an
autonomous fashion.
DSML Directory Services Markup Language is an

application of the Extensible Markup Language
(XML) that enables different computer network
directory formats to be expressed in a common
format and shared by different directory systems.
In the latest DSML specification, the related XML
schema defines types of information found in today's
network and enterprise directories. It then defines a
common XML document format that should be used
to display the contents of each directory.
JDBC Java Database Connectivity is an
application program interface (API) specification for
connecting programs written in Java to the data in
popular databases. The application program
interface lets you encode access request statements
in SQL that are then passed to the program that
manages the database. It returns the results through
a similar interface.
401
JMS Java Message Service is an application

program interface from Sun Microsystems that
supports the formal communication known as
messaging between computers in a network. Sun's
JMS provides a common interface to standard
messaging protocols and also to special messaging
services in support of Java programs. Sun
advocates the use of the Java Message Service for
anyone developing Java applications, which can be
run from any major operating system platform.
JNDI Java Naming and Directory Interface
enables Java platform-based applications to access
multiple naming and directory services. Part of the
Java Enterprise application programming interface
(API) set, JNDI makes it possible for developers to
create portable applications that are enabled for a
number of different naming and directory services,
including file systems, directory services, such as
Lightweight Directory Access Protocol (LDAP),
Novell Directory Services, and Network Information
System (NIS), and distributed object systems, such
as the Common Object Request Broker Architecture
(CORBA), Java Remote Method Invocation (RMI),
and Enterprise JavaBeans (EJB).
JSP Java Server Page is a technology for
controlling the content or appearance of Web pages
through the use of servlets, which are small
programs that are specified in the Web page and run
on the Web server to modify the Web page before it
is sent to the user who requested it.
Kerberos Kerberos is a secure method for
authenticating a request for a service in a computer
network. Kerberos was developed in the Athena
Project at the Massachusetts Institute of Technology
(MIT). The name is taken from Greek mythology;
Kerberos was a three-headed dog who guarded the
gates of Hades. Kerberos lets a user request an
encrypted "ticket" from an authentication process
that can then be used to request a particular service
from a server. The user's password does not have to
pass through the network.
402
LDAP Lightweight Directory Access Protocol is a

software protocol for enabling anyone to locate
organizations, individuals, and other resources,
such as files and devices, in a network, whether on
the public Internet or on a corporate intranet. LDAP
is a "lightweight" (smaller amount of code) version of
Directory Access Protocol (DAP), which is part of
X.500, a standard for directory services in a network.
MAC The need for a mandatory access control
(MAC) mechanism arises when the security policy of
a system dictates that
protection decisions must not be decided by the
object owner and the system must enforce the
protection decisions (for example, the system
enforces the security policy over the wishes or
intentions of the object owner).
The POSIX.6 standard provides support for a
mandatory access control policy by providing a
labeling mechanism and a set of interfaces that can
be used to determine access based on the MAC
policy.
MASS IBM Method for Architecting Secure
Solutions
RBAC. With RBAC (Role Based Access Control),
security is managed at a level that corresponds
closely to the organization's structure. Each user is
assigned one or more roles, and each role is
assigned one or more privileges that are permitted
to users in that role. Security administration with
RBAC consists of determining the operations that
must be executed by persons in particular jobs, and
assigning employees to the proper roles.
Complexities introduced by mutually exclusive roles
or role hierarchies are handled by the RBAC
software, making security administration easier.
ROI. For a given use of money in an enterprise,

the ROI (return on investment) is how much "return,"
usually profit or cost saving, results. An ROI
calculation is sometimes used along with other
approaches to develop a business case for a given
proposal. The overall ROI for an enterprise is
sometimes used as a way to grade how well a
company is managed. If an enterprise has the
immediate objectives of getting market revenue
share, building infrastructure, positioning itself for
sale, or other objectives, a return on investment
might be measured in terms of meeting one or more
of these objectives rather than in immediate profit or
cost saving.
SOAP Simple Object Access Protocol is a way for
a program running in one kind of operating system to
communicate with a program in the same or another
kind of an operating system by using the HTTP
Protocol and XML as the mechanisms for
information exchange.
SSL The Secure Sockets Layer is a
commonly-used protocol for managing the security
of a message transmission on the Internet. SSL has
recently been succeeded by Transport Layer
Security (TLS), which is based on SSL.
XML Extensible Markup Language is a flexible
way to create common information formats and
share both the format and the data on the World
Wide Web, intranets, and elsewhere. For example,
computer makers might agree on a standard or
common way to describe the information about a
computer product (processor speed, memory size,
and so forth) and then describe the product
information format with XML. Such a standard way
of describing data would enable a user to send an
intelligent agent (a program) to each computer
maker's Web site, gather data, and then make a
valid comparison. XML can be used by any
individual or group of individuals or companies that
want to share information in a consistent way.
Glossary
403
404
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see How to get IBM Redbooks
on page 406. Note that some of the documents referenced here may be available
in softcopy only.
Business Process Reengineering and Beyond, SG24-2590
Continuous Business Process Management with HOLOSOFX BPM Suite and
IBM MQSeries Workflow, SG24-6590
Enterprise Business Portals with IBM Tivoli Access Manager, SG24-6556
Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885
Enterprise Security Architecture using IBM Tivoli Security Solutions,
SG24-6014
Intra-Enterprise Business Process Management, SG24-6173
Other publications
These publications are also relevant as further information sources:
IBM Tivoli Identity Manager Policy and Organization Administration Guide
V4.4, SC32-1149
IBM Tivoli Identity Manager Server Installation Guide for Windows V4.4,
SC32-1148
IBM Tivoli Identity Manager Tivoli Access Manager Agent for Windows
Installation Guide V4.4, SC32-1165
Bass, et al, Software Architecture in Practice, Second Edition, Addison
Wesley, 1997, ISBN 0321154959
Committee on Information Systems Trustworthiness, et al, Trust in
Cyberspace, National Academy Press, 1998, ISBN 0309065585
Harris, CISSP All-in-One Exam Guide, The McGraw Hill Companies, 2001,
ISBN 0072193530
405
Lloyd, et al, "Technical Reference Architectures", IBM Systems Journal 38,

No. 1, 51-75 (1999)
Rechtin, Systems Architecting: Creating and Building Complex Systems,
Prentice Hall, Incorporated, 1990, ISBN 0138803455
RFC2254 The String Representation of LDAP Search Filters
Online resources
These Web sites and URLs are also relevant as further information sources:
IBM ^ pSeries Support AIX 4.3.3 Maintenance Packages
http://techsupport.services.ibm.com/server/mlfixes/43/10/01to10.html
National Institute of Standards and Technologies homepage.

http://www.nist.gov/
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips,
draft publications and Additional materials, as well as order hardcopy Redbooks
or CD-ROMs, at this Web site:
ibm.com/redbooks
406
Index
A
access control 47, 50, 211
management 43
model 1011
see ACI
Access Control List
see ACL
Access Manager 72
access control list 168
agent 146147, 171
authentication 221
common name attribute 152
distinguished name attribute 152
entitlement 154
entitlements 151, 156
groups 154, 288
GSO Resources 168
integration with Identity Manager 145
pdadmin 155, 168
Policy Server 74, 188
protected object policies 168
protected object space 168
reconciliation 155
roles 287
sec_master 155
server principals 155
service 147, 154
surname attribute 152
UNIX endpoint 151
Web Portal Manager 151, 155, 168
WebSEAL 74, 169170
Access Manager for Business Integration 187
Access Manager for e-business 187, 192
Access Manager for Operating Systems 146, 175
access templates 210
Access360 61
account 78, 229
alias 98
auto generation 216
automatic generation 270
deleting 210
information 267
locking 210
management 64, 88, 92, 146
management module 65
orphan 79, 99, 113, 126
provisioning 82, 94, 155
reconciliation 98
report 85
user ID generation 82
accounts 126
ACI 82, 106107, 156, 230231, 261, 276
interaction 264
ACL 82, 127, 168
Active Directory 27
changelog connector 140
activity table 130
adaptor 70
admin domain 232
Admin Server option for DB2 117
administration
... of services 234
delegated 222, 260
group 267
administrative domain 230
administrator
rights 265
administrator roles 106, 156
advanced provisioning parameters 154
agent 80, 220
Access Manager 146147
certificate 228
CLI-X 290
connectivity 69
profile 147
agentCfg 147
AIX requirements 118
AIXProfile 176
alias 98, 229
All role 243
anonymity 50
API Javadoc 123
Application Layer 64
approval 278
element 101
workflow 83, 99
407
approval model 216

approval process 276
architectural decision 54
architecture
physical 115
assembly line 170
AssemblyLine 139
asynchronous messaging 67
attribute 78
attribute file 291
attributes 262
audit 43, 47, 130, 195, 201, 211
compliance procedures 216
management 215
audit trail 69
authentication 50, 211, 221
extensible framework 121
module 67
authority
delegation 88
authorization module 67
automatic adoption 155
automatic provisioning 146, 155, 271
automation 239
business process 9
CLI-X agent 289290

configuration files 294
cluster configuration 222
command line interface 290
Common Criteria 47
communication protocols 224
CompanyName 126
compliance check 271
component architecture 56
component design 77
component placement 71
configuration of ports 75
connectivity 69
constraints 125
context 262
controlled network 72
CORBA 402
corporate security policy 200
credential 188
credentials life cycle 50
cryptographic 49
CSV 401
file connectivity 139
customization process 131
CustomLabels.properties 294
best practices 195

BPPerson 266
business entitlements 146
business process 37
automation 9
flow 50
re-engineering 58
business requirements
Identity Management automation 200
Identity Management foundation 200
business role 106
BytesMessage 142
DAC 401
DAML 135, 148, 224, 401
DARPA Agent Markup Language 401
data join management module 66
data join module 69
data management zones 190
data services API 121
data services module 68
database 69
DB2
Admin Server option 117
Connect Client 117
Heap Size 117
performance optimization table 131
services tables 130
table analysis 129
workflow tables 130
DB2INSTHOME 119
default policy 10
delegate 94
delegated administration 36, 146, 156, 168, 260
C
capabilities of administrators 156
central repository 210, 212
certificate 147, 228
challenge question 79, 87, 89
challenges 126
CLI-X
attribute file 291
408
domain example 157

delegation 222
... of administration 6
hierarchies 156
design of organization tree 231
design of workflow 277
desktop module 64
Directory Access Markup Language
see DAML
Directory Service Markup Language 249
see DSML
directory strategy 27
Discretionary Access Control 12
discretionary access control 401
distinguished name 250
DMZ 72
domain 156
domain administrator 156, 236, 266
dormant report 85
DSML 69, 249, 401
DSML identity feed service 249250
dynamic business entitlements 169
dynamic membership 284
dynamic role 65, 283
E
EJB 402
end element 101
enRole 126
enRoleAuthentication.properties 174
entities 78
entitlement 84, 95, 147, 151, 176, 277, 284
default attributes 153
entity management module 66
entity relationships 85
ePerson object 78
erdictionaryname 125
erPersonStatus 257
erSupervisor 255
escalation limit 113
EventHandler 139
excludeAccounts 155
Extensible Markup Language 403
ExternalLogonServlet 175
F
FESI JavaScript interpreter 122
firewall 224
port configuration 75
flow control 47
forgot your password 91
form
creation 63
design module 64
modification 134
rendering module 64
formTemplate 127
FTP 80, 117
ftp 224
functional design 56
G
government environment 13
grace login 151
group 20
management 79
membership 154
reconciliation 79
group membership 272, 283
group of administration 267
GSO Resources 168
GUI server 72
H
hardware requirements 117
Heap Size 117
high availability 222
historical information 69
historical reporting 114
historical request 130
HpuxProfile 176
HR synchronization 249
HTTPS 70, 80
I
IBM DB2 222
IBM Directory Integrator 70, 138, 169, 221, 250
assembly line 170
AssemblyLine 139
CSV file connectivity 139
entry object 141
EventHandler 139
parser connector 71
password synchronizer plug-in 139
Windows NT4 connector 139
Index
409
IBM Directory Server 222

IBM MQ Series 223
IBM MQSeries 118, 141
IBM WebSphere Application Server 118, 223
identification 50
identity
modification 256
policy 230
suspension 257
identity and credentials 47
identity feed 249250, 271, 287
placement rule 253
reconciliation 252
supervisor 255
identity management 31, 64
identity management module 65
Identity Manager
design 77
entities 78
identity policy 65, 83, 97, 147, 149, 154, 176, 237,
239
iNetOrgPerson object 78
installation log 84
integrity 211
IT best practices 195, 387
itamauth.jar 172
iv_user 175
J
Java Database Connectivity 401
Java Message Service 67, 402
Java Naming and Directory Interface 249, 402
Java Server Pages 402
Javadoc 123
JavaScript 95, 97, 131, 146, 150, 234, 272
extensible framework 122
JDBC 116, 401
JMS 67, 402
connector 141
JNDI 70, 249, 402
connector 143
job role 82, 95, 184, 216
join engine 69
join type 277
joinDirectives 127
JSP 402
junction 175
410
K
Kerberos 402
L
LDAP 116, 220, 402
ACL 127
analysis 124
connector 140, 143
directory 69
distinguished name 250
ePerson object 78
excludeAccounts 155
group membership 154
Identity Manager schema 125
iNetOrgPerson object 78
membership restrictions 125
multi-value fields 252
replica server 188
tag value pairs 169
LDIF file 155
liability 377
Lightweight Directory Access Protocol 402
location 82
locking of accounts 210
logging 84, 204
logical component architecture 62
logical component design
Application Layer 64
service layer 66
Web User Interface 63
login policy 150
logo 131
loop 113, 279
M
MAC 402
mail extensible framework 122
mail module 67
manage people 91
managed resource 92
managed services 83
management entities 80
management of accounts 92
Mandatory Access Control 13, 402
MASS 40
access control 47
architectural decision 54
audit 47
component architecture 56
flow control 47
functional design 56
identity and credentials 47
solution integrity 47
solution model 54
use case 55
membership 284
menu system module 63
messaging module 67
Meta Directory 27, 29
Method for Architecting Secure Solutions 40
methodology 40
military environment 13
modification of form 134
MQSeries 118
multi-value fields 252
N
naming convention 229
network diagram 185
network topology 223
network zone
controlled 72
restricted 73
trusted 73
uncontrolled 72
network zones 72
O
object
operations 262
type prefix 229
ObjectMessage 142
operation 262
operation report 85, 114
organization tree 78, 81, 92, 229230, 238, 245,
260
design 231
module 64
organizational role 82, 95, 155, 157, 168, 176, 242,
246, 271272, 287
OrganizationName 126
orgChart 126
orphan account 79, 85, 99, 113, 126
Other role 243
P
parallel approval 101
parser connector 71
password
ageing 210
challenge question 79
change 267
forgotten 91
generation 272, 275
length 204
login policy 150
management 6, 43, 79, 88, 169, 212, 214, 216
policy 65, 84, 97, 147, 150, 228, 230, 238239,
241
policy enforcement 140
policy for Windows 89
reset 87, 184, 192, 201
retry count 204
scheduled change 110
strength 98
strength checking 94
strength policy 150
synchronization 79, 89, 150, 169
synchronizer plug-in 139
pdadmin 151, 155, 168, 192
pending requests 88
pending requests list 111
people 126
performance optimization
DB2 table 131
listdata table 131
person 78, 82
attributes 132
delegate 94
entity 150
management 91
object 154, 169
object synchronization 170
personnel management 184
physical architecture 115
physical components 222
placement
... of components 71
... of services 235
policy 259
rule 253
policy 82, 126
corporate 377
Index
411
default 10, 216

identity 83, 97, 154, 176, 230, 237, 239
join operations 243
management 64, 214
module 68
normalization 240
password 84, 97, 230, 238239, 241
placement 259
provisioning 83, 95, 138, 153, 156, 168, 171,
176, 230, 238, 242, 271, 276, 286
resolution scope 232
scope 239
scripts 273
service selection 83, 234, 237, 243
validation 10, 212
Policy Server 74
port configuration 75
port number 147
practices 379
prefix of object type 229
principal 82, 263
procedures 379
profile
service 233
protected object policies 168
protected object space 168
provisioning 68, 82, 155, 231
... of a user 235
advanced parameters 154
connector API 122
engine 36
method 236
non-IT resources 289
policy 65, 83, 95, 138, 146, 151, 153, 156, 168,
171, 176, 230, 238, 242, 271, 276, 286
policy compliance check 271
policy join directives 127
scripts 273
proximity selection 236
pseudonymity 50
Q
quality of service 195, 387
R
RACF agent 80, 117
RBAC 11, 18, 270, 282, 402
412
role design 21
system design 22
reconciliation 70, 79, 98, 146, 154155, 229, 254,
284
identity feed 252
report 85
recycleBin 127
Redbooks Web site 406
Contact us xvi
redirectlogoff.jsp 174
redirectlogout.jsp 172
rejected request report 85
relational database 69
remote services module 68
report system 103
reporting 114
module 66
reports 85, 89
Request for Information 277, 279
request for information 65
requirements
software and hardware 117
resolution scope 232
resource 92
resource access lists 167
resource.def 294, 298
restricted network 73
return on investment 3, 194, 385, 403
reverse password synchronization 151
reverse proxy 188
RFI 65
node 102
risk assessment 4
risk management 195, 386
risk mitigation 3
ROI 199, 276, 403
role 20, 65, 82, 101, 106, 126, 216, 230, 271272
Access Manager 287
All 243
organizational 242, 246
Other 243
Role Based Access Control 3, 1011, 247, 270,
282, 402
rule 259
runConfig utility 131
S
schedule information 69
scheduler
scheduled_message table 131
scheduling
... of changes 110
... of reconciliations 112
module 68
schema.dsml 294295
scope 262
scope of policy 239
scripts 273
search function 93
search module 64
sec_master 155
secrets 49
Secure Sockets Layer 403
Securelink 80
security architecture 37, 52
security design objectives
Identity Management foundation 209
security domain 156
security policy 4, 43, 73, 146, 167
security roles 167
self-care 267
self-service 87, 260
interfaces 36
senior administrator 156
sensitivity silo 17
serial approval 101
server log 84
server principals 155
service 146, 267
... selection policy 65, 83, 234, 237, 243
Access Manager 147
administration 234
design requirements 234
instance 84
layer 66, 220
placement 235
profile 147, 233
report 85
serviceProfile 126
services 126
DB2 tables 130
remote_resources_recon_queries table 130
remote_resources_recons table 130
remote_services_requests table 130
resource_providers table 130
session timeout 123
shared secret 275
Simple Object Access Protocol 403

single server configuration 222
single sign-on 122, 146, 170
sleep interval connector parameter 141
SOAP 403
parser 142
software requirements 117
Solaris requirements 119
SolarisProfile 176
solution architecture 54
solution integrity 47
solution model 54
SSL 75, 127, 403
certificate 147
start element 100
static membership 284
status change 68
strategic advantage 387
strategic business initiative 195, 386
strength policy 150
subject 150
subprocess 279
supervisor 252, 266, 268
support administrator 156
suspension 257
synchronization
HR data 249
synchronization feed 256
synchronization of passwords 66, 79, 89, 150
syncPassword method 140
sysRoles 126
system administrator 82
system configuration module 66
systems management zone 190
systemUser 127
T
table analysis 129
TAMProfile 155
target systems 43
target type profiles 176
TextMessage 142
timpwflt.dll 140
to-do list 88, 99, 102
toolkit 290
transactional information 69
transactions 50
trusted network 73
Index
413
U
ui.properties 174
uncontrolled network 72
Universal Provisioning Agent 289
UNIX endpoint 151
UNIX user ID synchronization 175
use case 55
user 78
management 43, 191
provisioning 27, 30, 231, 235
registry 146
report 85
self-care 267
self-service 260
user ID generation 82
user interface 105, 218, 223
customization 131
user suspension
scheduling of ... 111
user to role mapping 107
V
validation policy 10, 212
Virtual Meta Directory 29
W
Web Portal Manager 151, 155, 168
Web single sign-on 170
Web user interface 105, 218, 223
Web User Interface Layer 63
WebSEAL 72, 74, 146, 151, 169170, 187, 222,
224
business entitlements 146
dynamic business entitlements 169
junction 175
reverse password synchronization 151
WebSphere Application Server
see IBM WebSphere Application Server
Windows
domain login 89
NT4 connector 139
password policy 89
password reset 89
requirements 120
work item 130
workflow 84, 99, 126, 130, 138, 214, 230, 271, 276
approval 83, 278
approval element 101
414
database 223
DB2 tables 130
design 63, 216
elements 100
end element 101
engine 36
escalation limit 113
java applet 99
join type 277
loop 113, 279
module 68
parallel approval 101
password_transaction table 130
pending table 130
process table 130
processdata table 130
processlog table 130
Request for Information 279
serial approval 101
start element 100
subprocess 279
time limits 113
workitem table 130
worklist management module 65
WorldWide Project Management Methodology 40
WWPMM 40
X
X.500 27, 402
X.509 certificate authentication 67
xforms.xml 294
XML 69, 117, 135, 403
parser 251
Identity Management Design Guide

(1.0 spine)
0.875<->1.498
460 <-> 788 pages
Back cover
Identity Management
Design Guide
Enterprise
integration for
identity management
Complete
architecture and
component
discussion
Tivoli Access
Manager integration
Identity Management is the concept of providing a unifying

interface to manage all aspects related to individuals and their
interactions with the business. It is the process that enables
business initiatives by efficiently managing the user life cycle
(including identity/resource provisioning for people (users)), and
by integrating it into the required business processes. Identity
Management encompasses all the data and processes related
to the representation of an individual involved in electronic
transactions.
This IBM Redbook provides an approach for designing an
Identity Management solution with the IBM Tivoli Identity
Manager Version 4.4. Starting from the high-level,
organizational viewpoint, we show how to define user
registration and maintenance processes using the Self
Registration and Self Care Interfaces as well as the Delegated
Administration capabilities. Using the Integrated Workflow, we
automate the submission/approval processes for Identity
Management requests, and with the Automated User
Provisioning, we will take workflow output and automatically
implement the administrative requests on the environment with
no administrative intervention.
This redbook is a valuable resource for security administrators
and architects who wish to understand and implement a
centralized identity management and security infrastructure.
SG24-6996-00
ISBN 0738453323
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:

ibm.com/redbooks

Identity Management Design Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Identity Management Design Guide

Caricato da

Copyright:

Formati disponibili

Front cover

International Technical Support Organization

First Edition (July 2003)

Copyright IBM Corp. 2003. All rights reserved.

2.1.2 Implementation flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40