Identity Management Design Guide

ibm.com/redbooks

Identity ManagementDesign Guidewith IBM Tivoli Identity Manager

Axel BückerAndrew Camp

Rick CohenDavid EdwardsCollin Penman

Thomas Sant’ana

Enterprise integration for identity management

Complete architecture and component discussion

Tivoli Access Manager integration

Front cover

Identity Management Design Guide with IBM Tivoli Identity Manager

July 2003

International Technical Support Organization

SG24-6996-00

© Copyright International Business Machines Corporation 2003. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.

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.

Note: Before using this information and the product it supports, read the information in “Notices” on page xi.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Part 1. Architecture and design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Business context for Identity and Credential Management . . . 31.1 Security policies, risk, due care, and due diligence. . . . . . . . . . . . . . . . . . . 41.2 Centralized user management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Single interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Security policy enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3 Central password management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.4 Delegation of administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.5 Multiple repository support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2.6 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.7 Centralized auditing and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3 Simplify user management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.1 Automation of business processes . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.2 Automated default and validation policies. . . . . . . . . . . . . . . . . . . . . 101.3.3 Single access control models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.4 Ubiquitous management interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.5 Integration of other management architectures . . . . . . . . . . . . . . . . 11

1.4 Access control models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4.1 The Role Based Access Control model . . . . . . . . . . . . . . . . . . . . . . 111.4.2 Other access control models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.3 Which model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.4 Selection process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.5 Roles vs. groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.6 Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.5 Identity management vs. Meta Directory . . . . . . . . . . . . . . . . . . . . . . . . . . 271.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 2. Architecting an Identity and Credential Management solution372.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.1.3 Definition of an Identity Management solution . . . . . . . . . . . . . . . . . 432.1.4 Design of an Identity Management solution . . . . . . . . . . . . . . . . . . . 44

2.2 Identity Management design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.2.1 MASS and Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.2.2 Developing security architectures using MASS . . . . . . . . . . . . . . . . 522.2.3 Integration into the overall solution architecture . . . . . . . . . . . . . . . . 54

2.3 Business processes and Identity Management . . . . . . . . . . . . . . . . . . . . . 582.4 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 3. Identity Manager component structure . . . . . . . . . . . . . . . . . . 613.1 Logical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.1 Web User Interface Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.1.2 Application Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.1.3 Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.1.4 LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.1.5 Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.1.6 Resource connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.2 Physical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.2.1 Component configuration and placement . . . . . . . . . . . . . . . . . . . . . 713.2.2 Network zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.2.3 Integrating with Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapter 4. Detailed component design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.1 IBM Tivoli Identity Manager entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.1.1 Users, accounts, and attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.1.2 Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1.3 Group membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1.4 Managed systems and applications . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.2 Identity Manager management entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.1 Organizational tree and roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.2.2 Identity Manager roles and ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.2.3 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.2.4 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.2.5 Audit logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.2.6 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.2.7 Entity relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.3 IBM Tivoli Identity Manager functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.3.1 User self-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.3.2 Password management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.3.3 Manage users and accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.3.4 Apply policy to user and account management . . . . . . . . . . . . . . . . 944.3.5 Reconcile accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

iv Identity Management Design Guide with IBM Tivoli Identity Manager

4.3.6 Approval workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.3.7 Produce reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.4 User interface and access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.4.1 Administrator roles, Identity Manager roles, and ACIs . . . . . . . . . . 106

4.5 Identity Manager schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094.5.1 Scheduling of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104.5.2 Scheduling of reconciliations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.5.3 Time limits on workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1134.5.4 Historical reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.6 Detailed component analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154.6.1 Physical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154.6.2 Software and hardware requirements . . . . . . . . . . . . . . . . . . . . . . . 1174.6.3 IBM Identity Manager application layout . . . . . . . . . . . . . . . . . . . . . 1204.6.4 API Javadoc (..\Identity Manager\extensions\api\ . . . . . . . . . . . . . . 1234.6.5 LDAP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244.6.6 DB2 table analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

4.7 Common customization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314.7.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1314.7.2 Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

4.8 Agent connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354.9 IBM Directory Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

4.9.1 CSV file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1394.9.2 Windows NT 4 and Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . 1394.9.3 IBM Directory Integrator password synchronizer plug-in . . . . . . . . 1394.9.4 Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404.9.5 IBM MQSeries and JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.9.6 JNDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1434.9.7 LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapter 5. Tivoli Access Manager integration . . . . . . . . . . . . . . . . . . . . . 1455.1 Functional overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1465.2 Managing Access Manager with Identity Manager . . . . . . . . . . . . . . . . . 147

5.2.1 Creating an Access Manager service . . . . . . . . . . . . . . . . . . . . . . . 1475.2.2 Setting up an Access Manager specific policy . . . . . . . . . . . . . . . . 1495.2.3 Managing Access Manager groups. . . . . . . . . . . . . . . . . . . . . . . . . 1545.2.4 Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555.2.5 Automatic provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1555.2.6 Delegated user administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

5.3 Separation of duties: resource vs. user management . . . . . . . . . . . . . . . 1675.3.1 Different types of administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675.3.2 Resource management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685.3.3 Identity management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

5.4 Integration with Tivoli Access Manager WebSEAL . . . . . . . . . . . . . . . . . 169

Contents v

5.4.1 Managing LDAP attributes used by WebSEAL . . . . . . . . . . . . . . . . 1695.4.2 Setting up Web single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

5.5 Access Manager for Operating Systems. . . . . . . . . . . . . . . . . . . . . . . . . 1755.5.1 Managing Access Manager accounts in sequence with UNIX . . . . 176

Part 2. Customer environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Chapter 6. Tivoli Austin Airlines Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1796.1 Company profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

6.1.1 Geographic distribution of TAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1806.1.2 Organization of TAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826.1.3 HR and personnel procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

6.2 Current IT architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.2.1 Overview of the TAA network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.2.2 TAA’s e-business initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1866.2.3 Security infrastructure for the e-business initiative . . . . . . . . . . . . . 1876.2.4 Secured e-business initiative architecture. . . . . . . . . . . . . . . . . . . . 1886.2.5 Identity management and emerging problems . . . . . . . . . . . . . . . . 191

6.3 Corporate business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . 1936.4 Project layout and implementation phases . . . . . . . . . . . . . . . . . . . . . . . 1946.5 ROI study and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Chapter 7. Identity Management design . . . . . . . . . . . . . . . . . . . . . . . . . . 1997.1 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

7.1.1 Phase I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2007.1.2 Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

7.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2017.2.1 Extracting Phase I functional requirements. . . . . . . . . . . . . . . . . . . 2017.2.2 Phase II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2067.2.3 Summary of functional requirements . . . . . . . . . . . . . . . . . . . . . . . 208

7.3 Security design objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2097.3.1 Security Design Objectives: general concepts . . . . . . . . . . . . . . . . 2107.3.2 Security Design Objectives: TAA specifics . . . . . . . . . . . . . . . . . . . 211

7.4 Design approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2167.5 Implementation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

7.5.1 Logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2177.5.2 Physical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Chapter 8. Technical implementation: phase I . . . . . . . . . . . . . . . . . . . . . 2278.1 TAA’s requirement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2288.2 Initial steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

8.2.1 Initial install and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2288.2.2 Naming considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

8.3 Organization tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

vi Identity Management Design Guide with IBM Tivoli Identity Manager

8.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2318.3.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2318.3.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

8.4 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2338.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2348.4.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2348.4.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

8.5 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2378.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2388.5.2 Design consideration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2388.5.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

8.6 Provisioning policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2428.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2458.6.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2458.6.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

8.7 Identity feed and HR synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . 2498.7.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2508.7.2 Using DSML identity feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2508.7.3 Design of the initial identity feed . . . . . . . . . . . . . . . . . . . . . . . . . . . 2538.7.4 Designing synchronization feeds . . . . . . . . . . . . . . . . . . . . . . . . . . 2568.7.5 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

8.8 Administrator and user access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2608.8.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2608.8.2 Design consideration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2618.8.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Chapter 9. Technical implementation: phase II . . . . . . . . . . . . . . . . . . . . 2699.1 TAA’s requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2709.2 New hire automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

9.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719.2.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2719.2.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

9.3 User requested accounts with workflow . . . . . . . . . . . . . . . . . . . . . . . . . 2769.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2769.3.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2769.3.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

9.4 Role Based Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2829.4.1 Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2839.4.2 Design consideration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2839.4.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

9.5 Provisioning to non-IT resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2899.5.1 Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2909.5.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

Contents vii

9.5.3 TAA’s implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Appendix A. IBM Tivoli Identity Manager 4.4 installation cookbook . . . 305Tivoli Identity Manager software overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Identity Manager component and process diagrams . . . . . . . . . . . . . . . . . . . 306Recommended hardware and software configuration . . . . . . . . . . . . . . . . . . 308Installation of DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Installing DB2 Version 7.2 FixPack 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309Upgrading to DB2 FixPack 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316DB2 configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Configuring DB2 for JDBC and JTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Confirm TCP/IP communications for DB2. . . . . . . . . . . . . . . . . . . . . . . . . 324Identity Manager database creation and configuration . . . . . . . . . . . . . . . 324Create database instance and test configuration . . . . . . . . . . . . . . . . . . . 326

Steps to uninstall DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328Clean up directories and delete DB2Admin user . . . . . . . . . . . . . . . . . . . . . . 329Install IBM Secureway LDAP 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330Configuration of the IBM Secureway LDAP v4.1 . . . . . . . . . . . . . . . . . . . . . . 341Starting the LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343Change the LDAP port to support Active Directory . . . . . . . . . . . . . . . . . . . . 349Install Identity Manager components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

Create Identity Manager user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Installing Identity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Enter DB2 connection information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358Enter LDAP connection information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Identity Manager System configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362Install MQSeries 5.2 CSD05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Final configuration of Identity Manager processes. . . . . . . . . . . . . . . . . . . . . 369

Steps to run WebSphere as a service. . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Manual process to start WebSphere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Configure LDAP referential integrity plug-in with file option . . . . . . . . . . . 370Verify Identity Manager installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Configure Windows "loopback" interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Uninstall all Identity Manager components. . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Appendix B. Corporate policy and standards . . . . . . . . . . . . . . . . . . . . . 377Standards, practices, and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379Practical example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379External standards and certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

Industry specific requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Product or solution certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381Nationally and internationally recognized standards. . . . . . . . . . . . . . . . . 382

viii Identity Management Design Guide with IBM Tivoli Identity Manager

Legal requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Appendix C. ROI questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385IBM Tivoli ROI analyst questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

Part 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Part 2: Tivoli Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389Part 3: Performance and availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391Part 4: Configuration and operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393Part 5: Security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394Part 6: Storage management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397Part 7: Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Contents ix

x Identity Management Design Guide with IBM Tivoli Identity Manager

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.

© Copyright IBM Corp. 2003. All rights reserved. xi

TrademarksThe 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 Identity Management Design Guide with IBM Tivoli Identity Manager

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 redbookThis redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center.

© Copyright IBM Corp. 2003. All rights reserved. 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 Identity Management Design Guide with IBM Tivoli Identity Manager

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 Sant’ana 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 WallaceInternational Technical Support Organization, Austin Center

Steve Henning, Tony Gullotta, Becky McKane, Robert Larson, Grey Thrasher, Robert Adachi, Robert Schneider, Sean McDonaldIBM Tivoli Identity Manager development and marketing team

Sridhar MuppidiIBM Security Architecture team

David EdwardsIBM Tivoli Services Australia

Stefaan Van daeleIBM Global Services Belgium

Lawrence Drenner, Melissa GriffithIBM Austin

Eddie HartmanIBM Norway

Become a published authorJoin 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 welcomeYour 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:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. OSJB Building 003 Internal Zip 283411400 Burnet RoadAustin, Texas 78758-3493

xvi Identity Management Design Guide with IBM Tivoli Identity Manager

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/

http://www.ibm.com/redbooks/


http://www.redbooks.ibm.com/contacts.html

Part 1 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.

Part 1

© Copyright IBM Corp. 2003. All rights reserved. 1

2 Identity Management Design Guide with IBM Tivoli Identity Manager

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.1 Security policies, risk, due care, and due diligenceThe 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 managementThe 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 interfaceMost 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 enforcementIdentity 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 5

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 managementA 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 user’s 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 administrationAs the number and type of users within the scope of an organization’s 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 supportWhen we talk about repository support, we have to take a look at two types of repositories:

� User repositories

� Endpoint repositories

User repositoriesUser 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 repositoriesEndpoint 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

� Tivoli Access Manager

� 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 WorkflowManaging 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 reportingTraditionally, 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.


1.3 Simplify user managementThis 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 processesAll 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

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 coverage of identity management solutions 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

Centralized management feature

Cost reduction impact Security impact


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 policiesWhen 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 modelsDefining 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 interfacesWork 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


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 architecturesIdentity 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 user’s 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 modelsThis section looks at some of the access control models that are commonly found or are planned for use with a centralized identity management solution.

1.4.1 The Role Based Access Control modelRole 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

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/.


http://www.nist.gov/

roles according to the work they are doing. Each role enables access to specific resources.

RBAC examplesA 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 modelsThere 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.


DACThe 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.

MACThe 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.

MACThe 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


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.

DACDiscretionary 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.


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.

2. Highly secure.

1. Costly to implement because of personnel vetting and data segregation requirements.

2. Difficult to centrally manage all identities because of sensitivity silos.

DAC 1. Likely to already be in use.

2. Easy to implement centralized identity management solution.

3. Suited to most commercial organizations, prior to centralized identity management or during conversion to RBAC.

1. Subject to management by mood.

2. Policy enforcement and audit costly.

3. Centralized identity management possible but less return on investment (ROI) than single RBAC model.

RBAC 1. Useful for strong role focused organizations.

2. Useful for organizations with high staff turnover and reliance on temporary or casual staff.

3. Recommended for large user populations, particularly where users include customers and partner organizations.

1. RBAC design can be difficult politically and logically.

2. Strong policies required particularly where delegated administration is used.

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.


1.4.4 Selection processThe 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.

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

Including all user repositories in the coverage of identity management solutions 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.

Access control model Pros Cons


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)?

Start

1

Yes

No

Yes 2

4

No

3

No

11Yes 25

12Yes 26

No

14

21

22

8

7

6

5

No

No

No

No 9

Yes

YesYes

Yes

18 19 20 29

10 28Yes

No

9 16 2715

17

Yes

23

No

No

30

24

Yes

No


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 organization’s 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.


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 organization’s 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


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. groupsOne 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:

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.

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

Groups

Groups

Groups

Groups

Groups

A user is assigned to arole (or more than onerole).

A role contains the policyfor provisioning users toa service (or more thanone service).

A service (or resource) isthe user repository that isunder the umbrella of theidentity managementsystem.

A group is a subset of userswho have been provisionedto the service or resource. Agroup confers access controlrights to those users forspecific parts of the service.

Groups


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 DesignsThe 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.


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


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

Yvette Yes No No Yes No

Zach Yes No No Yes Yes

User Repositories

NT Internet Customer Application

SAP E-mail UNIX®

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


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

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 SystemAdmin

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

User Role Repositories

NT Internet Customer Application.

SAP E-mail UNIX


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.


1.5 Identity management vs. Meta DirectoryIdentity 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 organization’s 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 organization’s 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.


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.

Security policies can be applied in one place.

A single directory may require the purchase of administration and management toolkits.

Many applications may have to be re-written or customized to allow authentication and/or authorization against the directory.

Many directories Normally, the state of an organization itself generates the need to look strategically at the problem.

The situation often has evolved rather than been designed and controlled.

High degree of flexibility.

Little or no design effort required.

Costly to manage.

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.


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.

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.

Still has multiple points of administration, so costs are not reduced.

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.

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.

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.


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.

Many of the other tools, by definition, have user provisioning built in. There may be no need, therefore, to consider this type of product.

Usually based upon a proprietary framework that may need to be deployed.

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.


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.

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).

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.

Many solutions (particularly those in user provisioning space) use this title for their products.

Coverage of target platforms must be checked, particularly where no integration point with Virtual Meta Directories exists.


Notes® Pros Cons


”

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.

Self Service User management

Delegated Identity management

Process Workflows

Enforcement

Security Policy

Policy Based Provisioning

User Provisioning

x.50

0

Man

y di

rect

orie

s

Met

a D

irect

ory

Virt

ual M

eta

Dire

ctor

y

Use

r A

dmin

istr

atio

n

Iden

tity

Man

agem

ent

Virtual Directories

Join Engine

Mulitple Directories

Centralized Directory


WEM ShipyardsWEM 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


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


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 ConclusionLet 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


� 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

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 IBM’s 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.

2


2.1 Solution architectures, design, and methodologiesThis 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 terminologyThere 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)


structure and the physical structure. Bass, et al., give the following definitions for these:

Conceptual, or logical, structure The units are abstractions of the system’s 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 flowAny 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, IBM’s WorldWide Project Management Methodology (WWPMM)) and one or more design and implementation methodologies (such as IBM’s 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.


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.

SecurityArchitecture

Project

EnterpriseArchitecture

Project

Need for anIdentity

ManagementProduct

SecurityArchitecturedocument

Productselection and

purchase

ITArchitecturedocument

RFP or otherrequirementspecificationdocument

Product-centricImplementation

Project

Product-centricArchitecture andDesign document


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

Initiation Definition

SoW orCharter

DefinitionReport

Design

Architecture/Design

Build


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 solutionThe 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


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 solutionEberhardt 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.


2.2 Identity Management design processUser 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.


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.


Project

EnterpriseArchitecture

Project

Need for anIdentity

ManagementProduct

SecurityArchitecturedocument

Productselection and

purchase

ITArchitecturedocument

RFP or otherrequirementspecificationdocument

Product-centricImplementation

Project

Product-centricArchitecture andDesign document

Experience& ICAPMASS


2.2.1 MASS and Identity ManagementThis section summarizes MASS and how it maps to Identity Management.

MASS subsystemsFor 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


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.

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

Functional category Common Criteria functional class


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 ManagementThe 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


� 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.


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.


2.2.2 Developing security architectures using MASSChapter 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 processesIn 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 objectivesDefine 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 subsystemsIn 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.


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 architectureWith 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.

SummaryThe design flow and work/items or deliverables for these steps are shown in Figure 2-6 on page 54.


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 modelsCreating 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.

ModelBusiness

Processes

EstablishSecurityDesign

Objectives

BusinessProcess

DefinitionsSDO

ConceptualSecurity

Architecture

Select andEnumerateSubsystems

Subsystem

Subsystem

Subsystem

Subsystem

Subsystem

MASSSubsystems

DocumentConceptual


DesignFlow

Work Items/Deliverables MappingSDOSDO


The Enterprise Solutions Structure (ESS) provides a range of reference architectures1 for e-business solutions.

Documenting architectural decisionsPreviously, 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 casesArchitectural 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.

1 P. T. L. Lloyd and G. M. Galambos, “Technical Reference Architectures,” IBM Systems Journal 38, No. 1, 51–75 (1999).


Refining the functional designWalkthroughs 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 architecturesThe 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 processThis 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).


Figure 2-7 Developing an overall solution architecture

ModelBusiness

Processes

EstablishSecurityDesign

Objectives

BusinessProcess

DefinitionsSDO

ConceptualSecurity

Architecture

Select andEnumerateSubsystems

MASSSubsystems

DocumentConceptual


DesignFlow

Work Items/Deliverables

MappingSDOSDO

DevelopSolutionModel

ComponentArchitectures

(Architecture andDesign document)

Develop SecuritySubsystem Architecture

InitialSolutionModel

ArchitectureDecisions

Integraterequirements

into componentarchitectures

Other Rqmts/Design

Considerations

DocumentArchitectureDecisions

UseCases

RefineFunctional

Design

DefineUse

Cases

WorkingFunctional

Models

Design Flow Work Items/Deliverables


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 ManagementThe 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.


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.


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.


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 Manager’s different architecture and non-reliance upon Tivoli’s 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

3


3.1 Logical component architectureThe 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

Figure 3-1 IBM Tivoli Identity Manager logical architecture

The following sections cover each individual layer in more detail.

A p p lic a t io n

W e b U s e r In te r fa c e

S e rv ic e

L D A P D a ta b a s e

A p p lic a t io n

A g e n t

R D B M S

A g e n t

O p e ra tin gS ys te m

A g e n t

A c c o u n t p ro v is io n in g /re c o n c il ia tio n

S u p e rv is o rB ro w s e r

A d m in is tra to rB ro w s e r

E n d U s e rB ro w s e r

U s e r /A d m in is tra to r re q u e s ts /re s p o n s e s

E n tity p u ts /g e ts

T ra n s a c tio n a lin fo , s c h e d u lere a d s /w r ite s


3.1.1 Web User Interface LayerThe Web User Interface module is a set of combined sub-processes that provide the content to a user’s 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 user’s 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.

Figure 3-2 Web User Interface module sub-processes

Menu System moduleThe Menu System module provides a consistent menu and short-cut mechanisms that are used for navigation throughout the user interface.

Interface

Web User Interface

Menu SystemForm

RenderingSearch

OrganizationTree

DesktopWorkflowDesign

Form Design

ApplicationInterface

Chapter 3. Identity Manager component structure 63

Organization Tree moduleThe 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 moduleThe 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 moduleThe 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 moduleThe 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 LayerThe 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


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.

Figure 3-3 Applications module sub processes

Workflow Management moduleThe 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 individual’s workflow driven worklist, or assignments. This includes the approval/disapproval of a request or the fulfillment of a Request For Information (RFI).

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

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

Identity Management moduleThe 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.

Platfo

rmApplications

SystemConfiguration

Reporting

PolicyManagement

WorklistManagement

IdentityManagement

PasswordManagement

WorkflowManagement

AccountManagement

EntityManagement

Data JoinManagement


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

System Configuration moduleThe System Configuration module provides the capabilities required to manage the IBM Tivoli Identity Manager system itself, such as defining behavioral properties.

Reporting moduleThe 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 moduleThe 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 moduleThe 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 LayerIf 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.


Figure 3-4 Core Services module sub-processes

Authentication moduleThe 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 moduleThe 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 moduleThe 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 moduleThe 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.

Access Manager

Scheduling

Core Services

WorkflowAuthorization

Messaging

Data Services

PolicyRemoteServicesAuthentication

Managed Services

CustomerDatastore

Workflow Database

Data Join


Scheduling moduleThe 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 moduleThe 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 moduleThe 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 moduleThe 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 moduleThe 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.


Data Join moduleThe 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 DirectoryThe 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 DatabaseA 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 connectivityThe 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.

Directory Services Markup Language connectivityDSML provides a method for processing structured directory based information as an XML document. DSML is a simple XML schema definition that enables

Note: Tivoli Identity Manager Version 4.4 currently uses a DSML-like protocol called Directory Access Markup Language (DAML). It is Tivoli’s stated intention that Version 4.5 of the product will support DSML.


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.

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 connectivityDue 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 Manager’s JNDI API, it is possible to connect to just about any service, application or endpoint, as shown in Figure 3-6 on page 71.

IPNetwork

DSMLFile

DSMLAgent

DATA

Identity ManagerServer

Web Interface

Applications

Core Services

HTTP/S

DSMLFile

Service


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 architectureAn 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 placementIt 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.

IP Network

DATA

Service

Identity ManagerServer

Web Interface

Applications

Core Services

Data BUS

IDIConnector

JNDI

- CSV- Parser- Operating System- LDAP- Application


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 zonesWe 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.


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 networksKeep 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 organization’s 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.


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 ManagerWhen 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

No Identity Managercomponents should bedeployed in an uncontrollednetwork. It is also generallyunsafe for Identity Managercomponents tocommunicate with oneanother across anuncontrolled networkwithout using securecommunicationmechanisms (such as SSL).

Possible locationfor GUI serversthat serviceexternalcustomers.

The specific level oftrust in an internalnetwork dictates whatIdentity Managercomponents may bedeployed within them.

Organizations may setup specializedrestricted zones forproduction systems,which could includeIdentity Managercomponent servers andsupportingcomponents, such asDB2 LDAP and Webservers.

Some organizationsset up specialnetworks to separatevarious managementcomponents fromproduction systems.Some IdentityManager componets,such as the RMAserver, might beinstalled in such anetwork.

Internet

UncontrolledZone

Internet DMZ Intranet

ControlledZone

TrustedZone

ProductionNetwork

RestrictedZone

ManagementNetwork

RestrictedZone

LESS SECURE MORE SECURE


DMZ acts as a proxy to the GUI’s 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.

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.

No Access Managercomponent should bedeployed in an uncontrollednetwork. It is also generallyunsafe for Access Managercomponents tocommunicate with oneanother across anuncontrolled networkwithout using securecommunicationmechanisms (such as SSL).

Usually, onlyWebSEAL or otherAccess Managerblades should beplaced in acontrolled networkzone.

The specific level oftrust in an internalnetwork dictates whatAccess Managercomponents may bedeployed within them.

Organizations may setup specializedrestricted zones forproduction systems,which could includeWeb and applicationservers, and variousAccess Managercomponents, such asthe User Registry orinternally usedWebSEALs.

Some organizationsset up specialnetworks to separatevarious managementcomponents fromproduction systems.The Access ManagerPolicy Server might beinstalled in such anetwork.

Internet

UncontrolledZone


ControlledZone

TrustedZone

ProductionNetwork

RestrictedZone

ManagementNetwork

RestrictedZone



Figure 3-9 Integrated architecture for Access Manager and Identity Manager

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.

ITIM server

LDAPMaster

AccessManager

Policyserver

Web server

Browser

Internet

Web server

Internet DMZ

Production Network

80/443 80/443

81/1443

Port AccessConfiguration

Port OpenPort Closed

AccessManager

WebSEAL

Data

PortalIBM HTTP

serverApplication

server

LDAPReplica

LDAPReplica

ITIM serverWebserver

Applications

Mainframe

81/1443

Fir

ewal

l

Fir

ewal

l

Fir

ewal

l

Management Network

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.


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.

4


4.1 IBM Tivoli Identity Manager entitiesIdentity 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 attributesA 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.


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 PasswordsAll 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 Tivoli’s 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 user’s 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 membershipAccounts 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 applicationsIdentity 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 entitiesIdentity 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.


4.2.1 Organizational tree and rolesCentral 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


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 ACLsA 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.

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.

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.


4.2.3 PolicyIdentity Manager supports four types of policy: provisioning policy, password policy, identity policy, and service selection policy.

Provisioning policyA 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 policyA 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.


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 WorkflowA 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 logsIdentity 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.


4.2.6 ReportsAn 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 relationshipsAs a summary, the key Identity Manager entities and their relationships are shown in Figure 4-2 on page 86.


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.

OrganizationRoles

Provisioning PolicyDefines level of access to one or m oreService (managed resources) for group

of users

Service

System ManagementAuthority

ITIM SystemAdministrators

OperatingSystems

Access Control Information

ITIMGroups

Databases

Applications

People who are ITIMUsers

People who are ITIM Usersand Domain Administrators

People who are ITIM Usersand System Administrators

People who are governed byITIM policies

DomainAdministrators

OrganizationIBM Tivoli Identity Manager


4.3 IBM Tivoli Identity Manager functionsThe 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-serviceOne 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 functionsThe 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.


Self-service functionsThe 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.


� 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 managementThe 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.


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 User’s challenge/response details


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 accountsThe 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 PeopleFigure 4-7 on page 92 shows the Manage People dialog.


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 ManagementThe 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.


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 functionIdentity 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.


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 functionSystem 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 managementPolicy 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.


The use of the first three policies for identity management is discussed in the next section.

Use of provisioning policy for account provisioningProvisioning 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


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


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 generationIdentity 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.


Use of password policy for password strength enforcementPassword 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.


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 workflowWorkflow 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.


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 elementThe 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.


End elementThe 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 elementThe 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 hasn’t 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 stylesTwo 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).


Figure 4-15 Parallel and Serial approvals

Workflow exampleThe 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.

AND

OR ParallelApproval

SerialApproval


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 reportsAn 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.


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


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 controlIn 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.


4.4.1 Administrator roles, Identity Manager roles, and ACIsThe 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.


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.

IT SupportGroup

DEPARTMENT

Help DeskOperators

JOB ROLE

SeniorAdministrator

JuniorAdministrator

Help Desk

ACCESS RIGHTS

Full control

Person TIMAcct

W2KAcct

Limited Access

Person TIMAcct

W2KAcct

Limited Access

Person TIMAcct

W2KAcct


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.


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 user’s information, except the user’s 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 schedulesIdentity 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.


4.5.1 Scheduling of changesMost 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.


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.


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 reconciliationsReconciliations 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.


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 workflowWorkflow 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.


Figure 4-26 Setting escalation limits in workflow

4.5.4 Historical reportingMost 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.


Figure 4-28 New User Report output

4.6 Detailed component analysisIBM 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 customer’s requirements.

4.6.1 Physical architectureFigure 4-29 on page 116 shows a simple physical architecture of the key IBM Tivoli Identity Manager components.


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.

BROWSER BROWSER BROWSER

ITIM Server

ITIM Server

Web server

ApplicationServer

HTTP(S) HTTP(S) HTTP(S)

RDBMS Server

ITIMRDBMS

JDBC(JMS)

Directory Server

ITIMDirectory

LDAPv3

RDBMS

AGENT

AGENTAGENT

AGENT

Operating Systems

Applications

AGENT

Directories

AGENTAGENT

Proxy System

AGENT

Application

AppProtocol

XML/HTTP(S) or FTP (encrypted)


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 requirementsThe following sections describe the software requirements for both supported versions of the UNIX and Windows operating environments.

DatabaseAn 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)

For an all-in-one installation, use:

IBM DB2 Personal Edition Version 7.2 with FixPack 7

For a clustered installation, use:

IBM DB2 Enterprise Edition Version 7.2 with FixPack 7

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.

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.


Directory serverA 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 serverUse 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 installationsThe following sections identifies hardware and software requirements specific to installing the IBM Tivoli Identity Manager Server on an AIX system.

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.


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 installationsThe following sections identifies hardware and software requirements specific to 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


http://techsupport.services.ibm.com/server/mlfixes/43/10/01to10.html

– set semsys:seminfo_semopm = 100

– set semsys:seminfo_semume = 256

Additional notesThe temp directory (/tmp) must have at least 512 MB of space.

Windows installationsThe following sections identifies hardware and software requirements specific to installing the IBM Tivoli Identity Manager Server on a Windows system.

HardwareThe 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 layoutThe following is a break down of the directory structure used by IBM Identity Manager and an entry point for further information.

1 IBM DB2 database and directory server will require an additional 256 MB of memory.


ExtensionsThis 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 documentationWithin 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.


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


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


� 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 analysisIBM 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 Tivoli’s Identity Manager directory mapping. A brief explanation of each container’s operations is shown in Table 4-1 on page 125.


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.

ou=people

ou=0

ou=0

ou=n

ou=n ou=challenges

ou=joinDirectives

ou=systemUser

ou=serviceProfile

ou=recycleBin

ou=objectProfile

ou=formTemplates

ou=CompanyName

ou=accounts ou=roles

ou=orphansou=services

ou=orgChart ou=policies

IBM Tivoli IdentityManager Root Node

ou=itim(Application Information)

ou=sysRolesou=workflow

o=organizationName(Organization information)

ou=itim(Service Information)

ou=excludeAccounts

ou=constraints

erdictionaryname=password


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 This container stores all information pertaining to the Password Challenge/Response feature.

ou=objectProfile This container stores all information pertaining to the object profile.

ou=serviceProfile This container stores the service profiles required for the system to recognize a managed resource as a service.



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.

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 company’s Security Policy, a combination of ACLs and the use of SSL for secure network connectivity may be required.


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.


Figure 4-33 ACL for DC=COM

4.6.6 DB2 table analysisIBM 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


Workflow tablesTivoli 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 tablesTivoli 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.


Scheduler tableThe 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 tableThe 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 customizationThroughout 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 interfaceThe 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.


4.7.2 FormsEach 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.


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.


Form modification example 1The 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.


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.

4.8 Agent connectivityIn today’s 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.

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.


It is Tivoli’s 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.

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

$cn=doris penman$sn=penman$eruid=a016432$UID number=3001$erunixshell=/bin/ksh

erglobalid=8586800984477496319cn = Doris Penmansn = PenmanerAIX=a016432UID number=3001Unix Shell = /bin/ksh

Tivoli IdentityManagerLDAP

Workflow

IBM Tivoli IdentityManager Server

HTTP(S)

erAIXDAMLSerice.xml

erAIXAccount.xml

xforms.xml AIX Server

/etc/passwd

CA Public Cert

signed Server Cert

CA Cert


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


4.9 IBM Directory IntegratorIn the future, it is IBM Tivoli’s 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 user’s 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.

Figure 4-41 IBM Directory Integrator components

CSV File

Parser

Event Handler

AssemblyLine

Connectors

Database

OperatingSystem

ITIM LDAP


4.9.1 CSV fileThe 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-inThe 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


the Windows systems if the LDAP server does not accept the new password (password enforcement).

Synchronize from single machineTo 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 domainTo 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 domainTo 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 DirectoryThe 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 connector’s 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


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 JMSThe 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.

JMS messagesEverything 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.

Note: Currently, only the IBM MQSeries server is supported for this type of connector.


JMS message typesThe 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 messageA 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.


4.9.6 JNDIThe 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 LDAPThe 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.



Chapter 5. Tivoli Access Manager 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.

5


5.1 Functional overviewMany 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.


5.2 Managing Access Manager with Identity ManagerIdentity Manager can manage a user’s "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 serviceIn 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 profileInformation 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 passwordTo 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.


Creating the Access Manager serviceBefore 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 policyAnother 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 policyAn 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();


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 policyConsiderations 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


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 entitlementsBefore 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.


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.


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 accountHere 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.


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

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 groupsAdministrators 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

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.


created or deleted using the Identity Manager interface today; either Web Portal Manager or pdadmin must be used.

5.2.4 ReconciliationAs 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=comou: excludeAccountsobjectClass: topobjectClass: organizationalunit

dn: cn=TAMProfile, ou=excludeAccounts, ou=itim, ou=tivoli, dc=comerObjectProfileName: TAMProfileobjectClass: topobjectClass: eridentityexclusionerAccountID: sec_mastererAccountID: ivmgrd/mastererAccountID: amwpm/tamservererAccountID: 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 * 100sec_masterivmgrd/masterawwpm/tamserverivacld/tamserver.tivoli.com

5.2.5 Automatic provisioningIdentity Manager provides the capability to automatically provision accounts when a user is created. Organization Roles can be set up so that users are


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 administrationThe 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.


Table 5-1 Administrator capabilities

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 exampleHere 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

Domain administrator

Senior administrator

Administrator Support administrator

Create Sub domain

X

Add new Administrators

X

Create Users X X

Modify Users X X X

View Users X X X X

Assign users to authorization roles

X X X

Change User Passwords

X X X X


3. Create the ACIs specified in Table 5-2 and attach them to the specified groups.

Table 5-2 ACI configuration for AcmeWidgetsDomain

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.

ACI - Name AWDomain administrator

AWSenior administrator

AW administrator

AW Support administrator

AWSubDomain X

AWManageAdministrators X

AWCreatePerson X X

AWCreateTIMUser X X

AWModifyPerson X X X

AWModifyTIMUser X X X

AWViewPerson X X X X

AWViewTIMUser X X X X

AWManageRoles X X X

AWChangePassword X X X X


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.


Table 5-3 AWSubDomain settings

Table 5-4 AWManageAdministrators settings

ACI AWSubDomain

Context Admin Domain

Permissions

Operation Grant Deny None

Remove X

Search X

Add X

Modify X

Attribute permissions

Name Read Write

All None None

ACI AWManageAdministrators

Context ITIM Group

Permissions


Remove X

Search X

Add X

Modify X


Name Read Write

All None None


Table 5-5 AWCreatePerson settings

ACI AWCreatePerson

Context Person

Permissions


Remove X

Transfer X

Search X

Restore X

Suspend X

Add X

Modify X


Name Read Write

All None None


Table 5-6 AWCreateTIMUser settings

ACI AWCreateTIMUser

Context Identity Manager User

Permissions


Remove X

Search X

Restore X

Suspend X

Add X

Modify X

Attribute Permissions

Name Read Write

All None None


Table 5-7 AWModifyPerson settings

ACI AWModifyPerson

Context Person

Permissions


Remove X

Transfer X

Search X

Restore X

Suspend X

Add X

Modify X


Name Read Right

All Grant Grant


Table 5-8 AWModifyTIMUser settings

ACI AWModifyTIMUser


Permissions


Remove X

Search X

Restore X

Suspend X

Add X

Modify X


Name Read Write

All Grant Grant


Table 5-9 AWViewPerson settings

ACI AWViewPerson

Context Person

Permissions


Remove X

Transfer X

Search X

Restore X

Suspend X

Add X

Modify X


Name Read Write

All Grant None


Table 5-10 AWViewTIMUser settings

Table 5-11 AWManageRoles settings

ACI AWViewTIMUser


Permissions


Remove X

Search X

Restore X

Suspend X

Add X

Modify X


Name Read Write

All Grant None

ACI AWManageRoles

Context Organizational Role

Permissions


Remove X

Search X

Add X

Modify X


Name Read Write

All None None


Table 5-12 AWChangePassword settings

5.3 Separation of duties: resource vs. user managementWhen 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 administratorsAdministrators 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

ACI AWChangePassword


Permissions


Remove X

Search X

Restore X

Suspend X

Add X

Modify X


Name Read Write

Password Grant Grant


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 managementTivoli 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.


5.3.3 Identity managementTivoli 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 user’s 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 WebSEALTwo 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 WebSEALWebSEAL 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.


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-onA 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

dc=com

TIM Person

o=tivoli,c=us

TAM Person

IdentityManager

IDI

WebSEAL


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 SSOIn 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 exampleTo 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).


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/javaset WAS_HOME=C:/WebSphere/AppServerset 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 FileThe 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.


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


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 configurationThe 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 logoffenrole.ui.logoffURL=redirectlogout.jspenrole.ui.timeoutURL=redireclogout.jsp

Restart WebSphere and test changesAt 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


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 junctionTo 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 serverWe 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 SystemsSince 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.


5.5.1 Managing Access Manager accounts in sequence with UNIXIn 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.


Part 2 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.

Part 2



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.

6

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.


6.1 Company profileThe 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

6.1.1 Geographic distribution of TAATAA 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:

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.

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.


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 This site contains a Customer Service Center, is part of the West region, and is supported by the regional center in San Francisco.

Denver, CO This site contains a Customer Service Center, is part of the Austin region, and is supported by the regional center in Austin.

St. Louis, MO This site contains a Customer Service Center, is part of the Austin region, and is supported by the regional center in Austin.

Detroit, MI This site contains a Customer Service Center, is part of the East region, and is supported by the regional center in New York.

Raleigh, NC This site contains a Customer Service Center, is part of 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

Figure 6-1 TAA geographic distribution

6.1.2 Organization of TAAThe company is split into four key areas, the three regions and a core services division. This is shown in Figure 6-2.

Figure 6-2 High-level organization chart

Austin, TXIT Center

San Francisco(Regional

Center West)

New York(Regional Center

East)

Los AngelesCSC

DenverCSC

RaleighCSC

DetroitCSC

St LouisCSC

SeattleCSC

Executive

RegionWest

RegionAustin

RegionEast

CoreServices


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.

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.

Figure 6-4 Core services organization chart

Each team within a department has a unique business code identifying the team and its location.

RegionAustin

GroundServices

Customer

Baggage

ITCenter

HelpDeskTech

Support

HR

Catering CleaningAirportLiaison

CSC01(Denver)

CSC02(StLouis)

CoreServices

Sales

AcctsCentral ITDataCenter

Systems HelpDesk IT Dev

Support

TAAMiles

Flights

Crews Maint.HRMarketing


6.1.3 HR and personnel proceduresPersonnel 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 user’s 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


employees manager sending an e-mail to the local office manager, who arranges everything.

6.2 Current IT architectureIn 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 networkTAA’s 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 TAA’s network is shown in Figure 6-5 on page 186.


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 TAA’s e-business initiativeMost of the business applications have been migrated to a distributed WebSphere Application Server implementation based on AIX systems, which is

Austin, TXIT Center

T1 (1.54Mbps)

San Francisco(Regional

Center West)

Internet

T3 (45Mbps)

New York(Regional Center

East)

T3 (45Mbps)

Los AngelesCSC

DenverCSC

RaleighCSC

DetroitCSC

St LouisCSC

SeattleCSC

T1 (1.54Mbps)T1 (1.54Mbps)T1 (1.54Mbps)

T1 (1.54Mbps)

T1 (1.54Mbps)

T3 (45Mbps)


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 initiativeIn the past, TAA’s 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.

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.

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.


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 user’s Web browser and the application hosting Web server, controlling whether a user can access the requested resource or not.

4. WebSEAL’s 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 user’s 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 customer’s mileage, special campaign information, and so on) via the Internet. A customer’s access to their data is controlled by WebSEAL also.

6.2.4 Secured e-business initiative architectureFigure 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


Figure 6-6 Current I/T architecture in Austin

FIREWALL

Customer

WebSEAL

FIREWALL

FIREWALL

AccessManager

PolicyServer

LDAPServer

WebSEAL

z/OS (DB2,MQSeries)

AIX

Internet Internet DMZ Production DMZ Intranet

WebApplication

Server

WebApplication

Server

IBM

CSC sitesCentral IT Center

Region Center Austin

Central IT Center

application data flowaccess control flow


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.

FIREWALL

Customer

WebSEAL

FIREWALL

FIREWALL

AccessManager

PolicyServer

LDAPMaster

WebSEAL

z/OS(DB2,MQSeries)

AIX

Internet Internet DMZ

Production DMZ

Intranet

WebApplication

Server

WebApplication

Server

CSC siteCentral IT Center


Central IT Center


F I R E W A L L

LDAPReplica

WebSEAL

F I R E W A L L

Intranet

Region Center East / West

IBM

CSC site

Production DMZ

WebApplication

Server

WebApplication

Server

AIX

WindowsNT/2000Domain

Windows NT/2000Domain


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 problemsEmerging 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.

FIREWALL

Customer

WebSEALFIREWALL

AccessManager

PolicyServer

LDAPMaster

z/OS(DB2,MQSeries)

AIX


WebApplication

Server

Central IT CenterCentral IT Center


F I R E W A L L

LDAPReplica

WebSEAL

F I R E W A L L

Intranet

Regional Center , West, Central, East

IBM

CSC site

Production DMZ

WebApplication

Server

AIX


LDAPReplica

FIREWALL


Current user managementTAA 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 Access Manager for e-business.

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 problemsAs 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 manager’s 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 user’s manager is not available temporarily, the password reset procedure gets even more delayed.


Besides password reset requests, there are other reasons that increase the administrator’s 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 administrator’s 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 objectivesTAA 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 Access Manager for e-business.

In order to increase the employee’s 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


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 phasesBased 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 resultsWhen 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.


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 summaryTivoli 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 InitiativesThe 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.


– 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 analysisTable 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 $2,597,132

Cumulative Net Benefit

($528,000) ($263,708) $1,036,417 $2,597,132


ROI analysis graphThe 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.

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

ROI analysis Initial Year 1 Year 2 Year 3 Total


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 organization’s 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.


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.

7


7.1 Business requirementsTivoli 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 IFrom 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 IITivoli 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


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 requirementsFor 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 requirementsLet 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).


Figure 7-1 TAA functional requirements part I.1

I.1-a1:Too many password resetrequests to administrators.

I.1-a11:A user has many differentpasswords for his acounts.

I.1-a12:Passwords should be changedperiodically for the company'ssecurity policy.

REASON I.1-a:Administrators can not fulfil tasksin proper time.

OBJECTIVE I.1:Identity management should beexecuted momentarily andcorrectly.

REASON I.1-b:It may take more time to get amanager's approval.

I.1-b1:When manager is not in theoffice, he can not approve it.

I.1-b11:Hard copy request form.

I.1-a2:It is time consuming to manuallymanage user data or to executerequests.

I.1-a21:Different interfaces for everytype of accounts.

I.1-a22:Values are entered manuallyby administrators.

I.1-a23Often, operations need to beredone because of mistakes.

I.1-a13:Almost all administrative tasksare executed by administratorswith any security level.

A : A single password foruser's accounts.

B : Delegate low-securityadministration tasks toothers including end

users.

C : User-frendly interface.

D : Central commoninterface.

E : Common values areentered automatically.

F : Value checkingfunction is required.

G : Automate businessprocesses.

H : Integrate businessprocesses into user

administration system.

Functionalrequirements


� 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).


Figure 7-2 TAA functional requirements part I.2, I.3, and I.4

I.2-a1:Every type of account has adifferent way of definition.

REASON I.2-a: Accounts withinvalid attribues may be createdby mistake.

OBJECTIVE I.2:The corporate security policyshould be enforced for allaccounts.

I : Centrally cross-wideuser management.

J : Common values areentered automatically.

Functionalrequirements

REASON I.3-a:User information is scattered overthe enterprise, such as on everyLDAP server, every AIX machine,and so on.

I.2-a2:Manual operations may causeinvalid values.

V2-a3:No value-checking function.

K : Value checkingfunctions are needed.

OBJECTIVE I.3:Corporate-wide user managementdata has to be available forverification and futureimprovements.

I.3-a1:There is no integrated loggingsystem.

L : Central logging systemis needed.

OBJECTIVE I.4:The existing system resources shouldbe utilized and new implementationsshould be reasonable.

REASON I.4-a:Existing investments in TivoliFramework system, WebSpheresolution, and Access Manager fore-business system.

M : Integration withexisting systems.


Phase I functional requirements summaryThe 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 IIFor 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.


Table 7-1 Functional requirements for business requirement 1

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.

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.


Table 7-2 Functional requirements for business requirement 2

These requirements are consolidated in 7.2.3, “Summary of functional requirements” on page 208.

7.2.3 Summary of functional requirementsSome 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


II.2A Automatically add new accounts and remove old accounts when a user changes their job role.

Configure auto account generation so that when a user changes a job role, the new accounts are automatically created and the old accounts are automatically removed.

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.

Ensure multiple levels of approval to ensure all 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.


N 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.

O 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.


These requirements define part of the scope for phase II.

7.3 Security design objectivesWith 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

P 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.

Q 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.

R Automatically add new accounts and remove old accounts when a user changes their job role.

Configure auto account generation so that when a user changes a job role, the new accounts are automatically created and the old accounts are automatically removed.

S Implement approval process for changes of job role and associated accounts.

Ensure multiple levels of approval to ensure all account changes are appropriate.

T Implement approval process for changes of job role and associated OS/application groups/profiles.

Ensure multiple levels of approval to ensure all access changes are appropriate.

U 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.

V Define audit reports for audit compliance.

Define and build the audit reports.



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 conceptsSecurity 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 user’s 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.


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 specificsWith 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.


Phase IIn 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.


� 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 managementSome 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 manager’s approval.

Audit managementAll operations for user management are logged centrally. Gathered log entries are extracted along with what we want to see.

Phase IIIn 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 ManagementThe 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


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 managementThe 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 managementThe 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 managementThe 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.


Audit managementThere 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 objectivesThe 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 infrastructureThe 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 usedWhere 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 managementThe 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 recoveryThere 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.


7.4 Design approachHere 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.


The remaining sections of this chapter present the design solution for this project.

7.5 Implementation architectureThe 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 componentsTAA 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.


Figure 7-3 TAA logical components

Web user interfaceThis 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 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.

Web User Interface

Application

LDAPDatabase

Security Policy Server

Exisiting Environment New Environment

General IT Systems IBM Tivoli Access Manager IBM Tivoli Identity Manager

LDAP (Replica)

WorkflowDatabase

User Repositories

RDBMS

LDAP (Master)

O/S

Applications

Service

WebSEAL

Centralized Authentication

Reverse Proxy

Provisioning Agents

RDBMS

LDAP (Master)

O/S

Applications

Browsers

End Users

Administrators

Supervisors

Authenticationflows

DataFlows

LDAPReplication

Legend


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.

Figure 7-4 Web user interface example screen

ApplicationThe IBM Tivoli Identity Manager application is, in simple terms, responsible for tying together the other components (Web user interface, Workflow database,

Menu Bar

ActionButtons


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.

LDAPThere 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.

DatabaseAlthough 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.

ServiceThe service layer is the layer that the application layer uses to interface with the agents and therefore the user repositories within the identity management

Note: This discussion of LDAP directories holds true for IBM Tivoli Identity Manager Version 4.4.x. It is Tivoli’s 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.


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.

AgentsAgents 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.

AuthenticationOnce 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

Note: It is Tivoli’s 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.


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 componentsIBM 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 serverDespite 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.

ClusterIn 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 serverThe following logical components are placed on this server:

� LDAP database

This functionality is provided by loading the following components:

� IBM DB2

� IBM Directory Server


Identity Management serverThe 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

AgentsMost 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 settingsTAA’s 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 overviewFigure 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.


Figure 7-5 Current TAA network zones mapped to network security model

Communication protocolsThe 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 settingsWithin 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


ControlledZone

TrustedZone

ProductionNetwork

RestrictedZone

ManagementNetwork

RestrictedZone


Internet

UncontrolledZone


Central IT CenterIntranet (CSC)

ProductionDMZ (Region)


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.

Figure 7-6 Final physical positioning of the two identity management servers

FIREWALL

Customer

WebSEAL

FIREWALL

FIREWALL

AccessManager

PolicyServer

LDAPMaster

WebSEAL

z/OS(DB2,MQSeries)


Production DMZ

Intranet

WebApplication

Server

WebApplication

Server

CSC siteCentral IT Center


Central IT Center


F I R E W A L L

LDAPReplica

WebSEAL

F I R E W A L L

Intranet

Region Center East / West

IBM

CSC site

Production DMZ

WebApplication

Server

WebApplication

Server

AIX

WindowsNT/2000Domain


DirectoryServerIdentity

ManagerServer



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.

� TAA’s implementation: How it was done in TAA’s implementation.

8


8.1 TAA’s requirementTAA’s 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 stepsBefore 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 configurationThe 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.


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 considerationsThere 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 TAA’s 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

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 treeThe 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 Manager’s design are controlled by the object placement in the tree.

Object type prefix Object

serv[type]_ Specifies the name of a service. Each Service profile has it’s 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


8.3.1 RequirementsAn 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 considerationsThe 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


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 TAA’s implementationThe 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 TAA’s 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.

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.

Tivoli Austin Airlines

CorpHQ

WestRC

CenterRC

EastRC

LACSC

SeattleCSC

DenverCSC

St LouisCSC

DetroitCSC

RaleighCSC


Identities are placed in each location according to the person’s 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 TAA’s organization tree on IBM Tivoli Identity Manager

8.4 ServicesServices 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.


8.4.1 RequirementsIn 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.

8.4.2 Design considerationsThe 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 policiesService 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 identity’s 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 identity’s position to the tree’s 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.


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 tree’s 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.

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 placementA 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.

CompanyOrganization

HQOrganization Unit

DataCenterAdmin Domain

SalesOrganization Unit

ManufacturingOrganization Unit

ComponentsOrganization Unit

AssemblyOrganization Unit

Joe Doris

VickyRobert

Service_A Service_CService_B

Service_D


All services on organization tree rootTechnically, all services could be placed at the top level. One of this design’s 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 DomainsAdmin 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 treeServices 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).

8.4.3 TAA’s implementationTAA 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.


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.

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 PoliciesThe 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.

Tivoli Austin Airlines

CorpHQ

WestRC

CenterRC

EastRC

LACSC

SeatleCSC

DenverCSC

StLouisCSC

DetroitCSC

RaleighCSC

Data CenterAdmin Domain

1 2 5 63 43 43 43 4

1 RACF 2 Notes 3 WindowsNT 4 AIX 5

IBM TivoliAccessManager

6IBM TivoliIdentityManager


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 RequirementsPolicies normally derive from the customer’s 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 environment’s 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 considerationPassword 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 treeIdentity 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


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.

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 policiesOne 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 policiesIdentity policies are very important when automation is used frequently, since they define the user ID in the targets. When all operations are done manually,

CorpHQOU

WestOU

SeattleOU

LAOU

TAAOrganization

Policy_B (Scope single)

Policy_A (Scope Sub-tree)

Mike

Service_A

Service_B


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).

8.5.3 TAA’s implementationTAA 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 policySince 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 employee’s 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.

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.


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 TAA’s 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 policyTAA 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


� 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 policiesProvisioning 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 provisioning policy.

� 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.


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 identity’s 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 joinsWhen 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.

Provisioning PolicyPriority 1000

AIX

RA

CFDeveloper

Tester

Default and allowed values

Gecos Value, Groups: staff

Provisioning PolicyRoles Service

ServiceSelection

Policy

Default and allowed values

NT

NT


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.

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

If the membership in the Other provisioning policy changed to All, all of the accounts would be members of the Guest group.

Identity Login script Join directive: Priority

GroupsJoin directive: Union

Mike user.cmdDeveloper provisioning policy

DeveloperDeveloper provisioning policy

Ana manager.cmdBoth Developer and Manager polices apply, but Manager has a higher priority

DeveloperDeveloper provisioning policyManager Manager provisioning policy

Chris guest.cmdOther provisioning policy

GuestOther provisioning policy.

DeveloperProvisioning Policy

Priority 1000Developer

Other

Provisioning PolicyRoles Service

Mike

Ana

Chris

ManagerManager

Provisioning PolicyPriority 2000

OtherProvisioning Policy

Priority 50

Login script: mngr.cmdGroups: Manager

Login script: user.cmdGroups: Developer

Login script: guest.cmdGroups: Guest

Users


8.6.1 RequirementsThe 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.

8.6.2 Design considerationsProvisioning 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 treeThe 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


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

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 rolesWhile 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.

CorpHQOU

WestOU

SeattleOU

LAOU

TAAOrganization

Policy_C (Scope single)

Policy_A (Scope Sub-tree)

Service_B

Service_C Service_D

Policy_B (Scope sub-tree)

Service_A


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.

8.6.3 TAA’s implementationThe 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 TAA’s 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.


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 TAA’s provisioning policies

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

Provisioning policy Membership Entitlements

pp_employee_access role_employee RACFNotesIBM Tivoli Access Manager(member of employee group)

pp_customer role_customer IBM Tivoli Access Manager(member of customer group)

pp_itim_manager role_manager IBM Tivoli Identity Manager(member of ig_manager group)

pp_basic All IBM Tivoli Identity ManagerIBM Tivoli Access Manager

pp_local_systems role_employee AIX service selection policyWindows NT service selection policy


(see 8.4, “Services” on page 233), since each organization unit has its own services defined for the local user.

Example 8-2 TAA’s basic service selection policy

function selectService() {var serviceInstance = null;

serviceInstance = ServiceSearch.searchForClosestToPerson(subject)[0];

return serviceInstance;}return selectService();

8.7 Identity feed and HR synchronizationIdentity 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.

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.

Tip: Although DSML feeds cannot delete any identities, you can suspend identities with them.


8.7.1 RequirementsThe 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 feedDSML 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 formatA basic entry DSML identity feed is provided in Example 8-3 on page 251. It contains all the elements necessary for a feed.


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.


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.

Multi-valued fieldsMany 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 supervisorIBM 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 identity’s supervisor

<attr name="erSupervisor"><value>uid=a088515</value>

</attr>

Note that the supervisor value is defined by the distinguished name (dn) used when the supervisor’s identity was imported. If the referenced identity cannot be found, the literal values is stored (if the supervisor is being loaded in the same

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.


feed) or an error will occur during reconciliation (if the supervisor is not in the same feed).

Updating existing identitiesWhen 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 feedIdentity 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 ruleA 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.

Note: If no supervisor can be found, any workflow that involves a supervisor will be approved automatically, since the supervisor cannot be resolved.


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 identity’s 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, Mike’s 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

Figure 8-9 Example of placement rule

Planning for reconciliations and rolesAnother 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.

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.

TAAOrganization

WestOU

SeattleOU

LAOU

Mike


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 filesThere 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.


8.7.4 Designing synchronization feedsOnce 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 identitiesThis 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 identitiesExisting 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.

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.


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></directory-entries>

</dsml>

Suspending identitiesThe 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 identity’s 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><entry dn="uid=a654321">

<attr name="erPersonStatus"><value>1</value></attr></entry>

</directory-entries></dsml>

8.7.5 TAA’s implementationTAA 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


� 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

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.

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 Complete TAA identity entry in the first feed

<entry dn="uid=a654321"><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>[email protected]</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">

<value>LACSC</value><value>WestRegion</value>

</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 TAA’s 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;


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)

<entry dn="uid=a654321"><attr name="erSupervisor"><value>uid=a088515</value></attr><attr name="ou">

<value>LACSC</value><value>WestRegion</value>

</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 accessDelegated 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 RequirementsThe 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?


� 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.

8.8.2 Design considerationAll 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.

Access Control InformationAn 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.


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 contextAs 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 ACI’s scope.

ACI operation and attributesEach 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 user’s own data.


ACI principalsThe 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 identity’s 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.

Merging ACIsFrequently, 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 user’s own data placed on an organization tree. Each ACI refers to the user’s own AIX account data. All of the ACIs have a sub-tree scope.

Note: The supervisor and Domain Administrator have many rights by default, so the default right may have to be reevaluated.


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

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 attributesEdit: 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.

CorpOrganization

ITOU

SysAdminOU

Ana

Mike

ACI_Unix

ACI_Unix_Admin

Context: AIX accountScope: Sub-treeOperations: Modify & SearchAttributes: Shell: Grant Write UID: Deny Write All: Grant read Password: Grant Read & WritePrincipal: Self

Context: AIX accountScope: Sub-treeOperations: Add & ModifyAttributes: Shell: Grant Read & Write UID: Grant Read & Write Primary Group: Grant Read & Write Password: Grant Read & WritePrincipal: Self


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 optionsThe 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 accessIn 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).

Mike Create Denied ACI_Unix has no authorization for the Add operation.

Modify See all attributesEdit: Shell and password

Only these attributes are authorized in the ACI_Unix.

Identity Operation Attributes Reason


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 supervisorsThe 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 container’s 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 groupsIf an administrator requires something that cannot be delivered by supervisors and domain administrators, there may be a need to define ACIs using IBM Tivoli


Identity Manager groups. This requires creating the groups and then creating a complete set of ACIs for that group.

User self-careUsers 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

8.8.3 TAA’s implementationFor 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.

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.


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.


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.

9


9.1 TAA’s requirementsSection 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 automationWhen 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 employee’s 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.


9.2.1 RequirementsAutomatically 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.

9.2.2 Design considerationsA 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.

Organizational roles and target systems membershipAutomatic 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

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.

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 system’s 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 passwordsOne 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 identity’s 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.


Provisioning policies attributesMost 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.

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

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.

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.


9.2.3 TAA’s implementationTAA has decided to grant automatic access to the following systems:

� IBM Tivoli Access Manager� IBM Tivoli Identity Manager� 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, “TAA’s 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

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.

{ Enrole.getAttributeValue("Person.ersharedsecret","").substring(strLen-4,strLen); }

Get the last four characters of the identity’s shared secret information. Requires the strLen to be defined with the current length (as shown above).

Script Description

Attribute Enforcement Value

ertamgroupmemeber mandatory grp_manager


Table 9-3 pp_employee_access entitlement values for IBM Tivoli Access Manager

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 TAA’s 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

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 3

ertampasswordpolicy default FALSE

ertamsinglesign default TRUE

sn mandatory {subject.getProperty("sn")[0];}


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 workflowOne 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 RequirementsIf 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.

9.3.2 Design considerationsDesigning 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.


Workflow designDesigning 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 reviewWorkflows 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.


� 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.

ApprovalAn 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

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).


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.

SubprocessSubprocesses 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.

LoopsLoops 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.


Figure 9-2 Loops JavaScript requirements

Putting it togetherWorkflow 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.

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.

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.

Exit condition for the loopco n t ex t .g e t Lo o p Co u n t ()<=3

JavaScript for a negative exitfrom the loop

JavaScript for a positive exitfrom the loop


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.

9.3.3 TAA’s implementationThe 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 employee’s 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 TAA’s developer AIX workflow


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 ControlOne 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.

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).

Target System

Group Role Access

User

Membership

Resource


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 RequirementIn 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.

9.4.2 Design considerationManaging 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).


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.

IBM Tivoli Identity Manager

Service

Target System

Group Role Access

User

Membership

Resource

Target SystemGroup

OrganizationRole

ProvisioningPolicy

Identity

Account

MembershipDynamic or static Membership

Membership

Entitlement

Pro

visi

onin

g

Rec

on

Pro

visi

onin

g

Entitlement

Ow

ner

ship


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.

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.

Figure 9-7 Using provisioning policy joins in role assignment

Group Role AccessOrganization

Role

Identity

Resource

Provisioning Policy

Dynamic Roles

Provisioning policy foruser with Role_B

Basic Provisioning Policy

Provisioning policy forusers with Role_A

Result of join for user withRole_A and Role_B


Reviewing provisioning policiesMapping 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 identity’s 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.


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 revisitedSince 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 provisioning policy.

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 attribute’s enforcement.

9.4.3 TAA’s implementationTAA 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,


“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;

}


9.5 Provisioning to non-IT resourcesOnce 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 TAA’s 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.

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.

Note: It is Tivoli’s 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.


9.5.1 RequirementIBM 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.

9.5.2 Design considerationsThe 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 overviewThe 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.


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.

Scripts or commandsThe 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|36eruniformaddress|2600 Gracy Farms Ln, Austin, TXeruniformwaist|30eruniformhip|30eruniformchest|30eruniformgender|MALE

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.


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|erUniformAccounterUniformchest|20erUniformaddress|50erUniformhip|30erUniformwaist|10erUniformgender|MALEerUniformleg|40

eruid|a012345|erUniformAccounterUniformchest|20erUniformaddress|50erUniformhip|30erUniformwaist|10erUniformgender|MALEerUniformleg|40CLIXResult|0

Figure 9-9 on page 293 shows a screen shot of the CLI-X agent’s 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.


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.

Configuration filesEach 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

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:

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.


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

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.

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 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>

<attribute-type single-value = "true" ><name>erUniformChest</name><description>First Name</description><object-identifier>1.3.6.1.4.1.6054.3.101.2.2</object-identifier><syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>

</attribute-type>

<attribute-type single-value = "true" ><name>erUniformHip</name><description>First Name</description><object-identifier>1.3.6.1.4.1.6054.3.101.2.3</object-identifier><syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>

</attribute-type>

<attribute-type single-value = "true" ><name>erUniformLeg</name>

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.


<description>First Name</description><object-identifier>1.3.6.1.4.1.6054.3.101.2.4</object-identifier><syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>

</attribute-type>

<attribute-type single-value = "true" ><name>erUniformGender</name><description>First Name</description><object-identifier>1.3.6.1.4.1.6054.3.101.2.5</object-identifier><syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>

</attribute-type>

<attribute-type single-value = "true" ><name>erUniformAddress</name><description>First Name</description><object-identifier>1.3.6.1.4.1.6054.3.101.2.6</object-identifier><syntax>1.3.6.1.4.1.1466.115.121.1.7</syntax>

</attribute-type>

<attribute-type single-value = "true" ><name>erTitle</name><description>Job Title</description><object-identifier>1.3.6.1.4.1.6054.3.101.2.7</object-identifier><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><object-identifier>1.3.6.1.4.1.6054.3.101.1.1</object-identifier><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>

<class superior="top">

<name>erUniformDAMLService</name><description>Class for uniform provisioning.</description><object-identifier>1.3.6.1.4.1.6054.3.101.1.2</object-identifier>


<attribute ref = "erURL" required = "true" /><attribute ref = "erUid" required = "true" /><attribute ref = "erPassword" required = "true" /> <attribute ref = "erCertFile" required = "false" /> <attribute ref = "erPrivateKeyFile" required = "false" /> <attribute ref = "erCACertStore" required = "true" />

</class> </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:

<object-identifier>1.3.6.1.4.1.6054.3.101.2.6</object-identifier>

The the object identifier breaks down in the following terms

1.3.6.1.4.1.6054 IBM enterprise ID: Must be this number.

3 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.

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:

<attribute-type single-value = "true" >

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.

Important: The instance ID must be unique for each attribute, account class, group class, and service class.


Example 9-6 TAA’s Uniform Account definition (partial)

<class superior="top"><name>erUniformAccount</name><description>Uniform Request Account</description><object-identifier>1.3.6.1.4.1.6054.3.101.1.1</object-identifier><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 TAA’s 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 TAA’s uniform service resource.def file

<?xml version="1.0" encoding="UTF-8"?><Resource>

<SystemProfile><Name>UniformAgent</Name><Description>Uniform Provisioning Agent</Description><BehaviorProperties>

<PropertyName =

"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" />

<PropertyName = "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" />


<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>

<AccountDefinitionClassName = "erUniformAccount"Description = "Uniform Account" >

</AccountDefinition>

<ServiceDefinitionServiceProfileName = "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 service’s 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.


Installing the serviceWith 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 service’s 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

9.5.3 TAA’s implementationTivoli 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.

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


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.


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 agent’s configuration files were shown in the examples used throughout 9.5.2, “Design considerations” on page 290.


Part 3 Appendixes

Part 3



Appendix A. IBM Tivoli Identity Manager 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.

A


Tivoli Identity Manager software overviewHere 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 diagramsFigure 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.


Figure A-1 Identity Manager components

ITIM Agent

Web Server

Directory Server Database Server

ITIM Server

E-mail Server

HR feed

DAML/SSLSMTP

JDBC

LDAP/SSL

HTTP/HTTPSHTTP/HTTPS

LDAP/SSL

Appendix A. IBM Tivoli Identity Manager 4.4 installation cookbook 307

Figure A-2 Identity Manager Server components

Recommended hardware and software configurationWe 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

ITIM Server Application

Servlet

LDAP/SSL

EJB

Application Server(Websphere)

Host Platform

Directory Server

Host Platform

Database Server

Host Platform

JDBC

ITIM Server

Directory Server

Database Server


For further details refer to the IBM Tivoli Identity Manager Server Installation Guide for Windows V4.4, SC32-1148.

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 DB2Tivoli Identity Manager ships with DB2 Universal Database™ Enterprise Edition Version 7.2.

Installing DB2 Version 7.2 FixPack 5Insert 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.

Tip: It is recommend that you do not have any other Web servers running on the system.


Figure A-3 Welcome to DB2 window

Select Next and accept the defaults, as shown in Figure A-4 on page 311.


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


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.


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.


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


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.


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 7DB2 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.


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.


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


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.


DB2 configurationLog 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 JTSSelect 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.


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).


Figure A-21 Control Center and Configure windows


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


Confirm TCP/IP communications for DB2Start 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 configurationUsing 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


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


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 configurationConnect 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


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


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 DB2Log 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


Clean up directories and delete DB2Admin userStart 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.


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.1Unzip 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.


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).


Figure A-35 Welcome window

Accept the terms in the license agreement and click Next (Figure A-36 on page 333).


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.


Figure A-37 DB2 already installed

Accept the default installation location (Figure A-38).

Figure A-38 Default installation location


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).


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


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.


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.


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).


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.


Figure A-50 Installation finished

Configuration of the IBM Secureway LDAP v4.1After 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.


Figure A-51 LDAP configuration in WordPad


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 DirectoryBring 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.


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.


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.


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.


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.


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.


Figure A-59 Add an LDAP Entry: Attributes

Change the LDAP port to support Active DirectoryWe 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 Figure A-60 on page 350.


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 componentsSeveral components that are bundled with the Identity Manager base software package, IBM WebSphere, and IBM MQSeries, are installed during the Identity Manager installation.


Create Identity Manager userSelect 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.


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.


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


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).


Figure A-66 Choose Install Folder window

Install WebSphere, accept the default, and click Next (Figure A-67 on page 356).


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).


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.


Figure A-69 IBM Middleware Pre-install Summary window

Enter DB2 connection informationThe 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.


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).


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 informationThe 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".


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.


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 configurationThe next steps show the Identity Manager system configuration.

The System Configuration dialog starts with the screen shown in Figure A-78 on page 363.


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


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.


Install MQSeries 5.2 CSD05On 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

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.

Important: Make sure you have a Microsoft Windows 2000 Server with SP2 installed.


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.


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.


Figure A-85 Rollback

You should get the window shown in Figure A-86. Click on Next.

Figure A-86 Start Copying Files


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 processesCheck 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.


Steps to run WebSphere as a serviceThe 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 WebSphereYou can also start IBM WebSphere manually by selecting Start → Programs → IBM WebSphere → Application Server V4.0 → Start Application Server.

Configure LDAP referential integrity plug-in with file optionIn 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 Figure A-88 on page 371.

ibm-slapdPlug: preoperation /bin/libdelref.dll DeleteReferenceInit file="C:\itim\config\ldap\ibm\timdelref.conf" dn=dc=com

This line should be one line.

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.


Figure A-88 slapd32.conf file

5. Restart the machine.

Verify Identity Manager installationIn 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


Figure A-89 IBM Tivoli Identity Manager log-on page

Congratulations! Identity Manager is installed and configured correctly.

Configure Windows "loopback" interfaceIn 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.


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 componentsHere 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?"

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.

Note: Make sure that the WebSphere server, IBM HTTP Server, and IBM HTTP Administration Services are stopped before doing step 14.


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.


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.



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

B


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.

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.

CorporatePolicy

StandardsStandardsStandardsStandards

ProceduresPractices ProceduresPractices Procedures Technical

Static


Standards, practices, and proceduresStandards 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.

Practical exampleHere 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

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.

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.

Figure B-2 The five steps in defining your IT security

External standards and certificationsThe 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

Policies

AuditManage

RiskImplement


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 requirementsSome 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 certificationsSome 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 CriteriaThis 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


higher EALs 5 - 7 are reserved for the security testing of highly secure environments.

CAPS UKIn 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 standardsSome 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

BS7799The 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 7858BS 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 requirementsThe 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.


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.

SummaryCorporate 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.



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 organization’s 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.

C


IBM Tivoli ROI analyst questionnaireThe 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: Introduction1. 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:

• 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

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

Type of server Number of servers currently installed

Number of processors

Web

Database

Messaging

Application and middleware

File/print and others

Total FTE Average unburdened salary

Performance and Availability staff FTEs

Configuration and operations staff FTEs

Security Management staff FTEs

Storage Management Staff FTEs

Incident and Problem Management Staff FTE


7. Please specify the following details about your current support services:

Table C-3 Specify the value of your annual support contracts (if any)

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 SolutionsWhich 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

Note: Incident and Problem Management FTEs include full time IT staff, contractors, part time resources, and business unit personnel performing support tasks.

Annual support contracts Annual support fees

Service Desks

PC Desktop Support

Host outsourcing


– 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 Identity 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


– IBM Tivoli SANergy™

– IBM Tivoli Storage Network Manager

Part 3: Performance and availability1. 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

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?

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%


Table C-5 Current availability of specific enterprise applications/systems

For reference, the following are industry average Impact per Downtime Minute metrics that can be used.

Table C-6 Impact per downtime minute metrics

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? ________(%)

Systemapplication

Applicationname

Applicationtype

Availability Operationalhoursper day

Operationaldaysper week

Impact perdowntimeminute

App 1 % $

App 2 % $

App 3 % $

App 4 % $

App 5 % $

App 6 % $

App7 % $

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


Part 4: Configuration and operations1. 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

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

Configuration and operation staff Percentage of time spent on task (%)

Business System Management

Application Administration

Software Distribution and control

Asset Management

Total 100%

Systemapplication

Applicationname

Applicationtype

Availability Operationalhoursper day

Operationaldaysper week

Impact perdowntimeminute

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:

Table C-9 Impact per downtime minute metrics

What is your estimated annual increase in downtime impact per minute? _________(%)

Part 5: Security management1. 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

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

Security management staff Percentage of time spent on task (%)

Policy Management

Intrusion Detection

Repair and Resolution

Forensics

Counter Measures

Auditing and reporting

Other


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

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: _____________

Total 100%

Security management staff Percentage of time spent on task (%)

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 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)


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 management1. 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

What is the expected growth in Storage Administration Staff? ____________(%)

Storage administration staff Percentage of time spent on task (%)

Capacity and Performance Management

Disaster/Contingency Planning

Backup Administration

Data Restore

Tape Administration

Archiving

Other

Total 100%


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)


– 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 information1. 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 $


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.

Application developers $

Service desk $

Technical support specialists $

Title Salary


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-7077Johnson,Mary,370-3920Smith,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.

© Copyright IBM Corp. 2003. All rights reserved.

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.

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


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 RedbooksFor 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 publicationsThese 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


� 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 resourcesThese Web sites and URLs are also relevant as further information sources:

� IBM ^ pSeries Support AIX 4.3.3 Maintenance Packages


� National Institute of Standards and Technologies homepage.


How to get IBM RedbooksYou 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


http://www.redbooks.ibm.com/





Index

Aaccess control 47, 50, 211

management 43model 10–11

Access Control Informationsee ACI

Access Control Listsee ACL

Access Manager 72access control list 168agent 146–147, 171authentication 221common name attribute 152distinguished name attribute 152entitlement 154entitlements 151, 156groups 154, 288GSO Resources 168integration with Identity Manager 145pdadmin 155, 168Policy Server 74, 188protected object policies 168protected object space 168reconciliation 155roles 287sec_master 155server principals 155service 147, 154surname attribute 152UNIX endpoint 151Web Portal Manager 151, 155, 168WebSEAL 74, 169–170

Access Manager for Business Integration 187Access Manager for e-business 187, 192Access Manager for Operating Systems 146, 175access templates 210Access360 61account 78, 229

alias 98auto generation 216automatic generation 270deleting 210information 267

© Copyright IBM Corp. 2003. All rights reserved.

locking 210management 64, 88, 92, 146management module 65orphan 79, 99, 113, 126provisioning 82, 94, 155reconciliation 98report 85user ID generation 82

accounts 126ACI 82, 106–107, 156, 230–231, 261, 276

interaction 264ACL 82, 127, 168Active Directory 27

changelog connector 140activity table 130adaptor 70admin domain 232Admin Server option for DB2 117administration

... of services 234delegated 222, 260group 267

administrative domain 230administrator

rights 265administrator roles 106, 156advanced provisioning parameters 154agent 80, 220

Access Manager 146–147certificate 228CLI-X 290connectivity 69profile 147

agentCfg 147AIX requirements 118AIXProfile 176alias 98, 229All role 243anonymity 50API Javadoc 123Application Layer 64approval 278

element 101workflow 83, 99

407

approval model 216approval process 276architectural decision 54architecture

physical 115assembly line 170AssemblyLine 139asynchronous messaging 67attribute 78attribute file 291attributes 262audit 43, 47, 130, 195, 201, 211

compliance procedures 216management 215

audit trail 69authentication 50, 211, 221

extensible framework 121module 67

authoritydelegation 88

authorization module 67automatic adoption 155automatic provisioning 146, 155, 271automation 239

business process 9

Bbest practices 195BPPerson 266business entitlements 146business process 37

automation 9flow 50re-engineering 58

business requirementsIdentity Management automation 200Identity Management foundation 200

business role 106BytesMessage 142

Ccapabilities of administrators 156central repository 210, 212certificate 147, 228challenge question 79, 87, 89challenges 126CLI-X

attribute file 291

CLI-X agent 289–290configuration files 294

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

file connectivity 139customization process 131CustomLabels.properties 294

DDAC 401DAML 135, 148, 224, 401DARPA Agent Markup Language 401data join management module 66data join module 69data management zones 190data services API 121data services module 68database 69DB2

Admin Server option 117Connect Client 117Heap Size 117performance optimization table 131services tables 130table analysis 129workflow tables 130

DB2INSTHOME 119default policy 10delegate 94delegated administration 36, 146, 156, 168, 260


domain example 157delegation 222

... of administration 6hierarchies 156

design of organization tree 231design of workflow 277desktop module 64Directory Access Markup Language

see DAMLDirectory Service Markup Language 249

see DSMLdirectory strategy 27Discretionary Access Control 12discretionary access control 401distinguished name 250DMZ 72domain 156domain administrator 156, 236, 266dormant report 85DSML 69, 249, 401DSML identity feed service 249–250dynamic business entitlements 169dynamic membership 284dynamic role 65, 283

EEJB 402end element 101enRole 126enRoleAuthentication.properties 174entities 78entitlement 84, 95, 147, 151, 176, 277, 284

default attributes 153entity management module 66entity relationships 85ePerson object 78erdictionaryname 125erPersonStatus 257erSupervisor 255escalation limit 113EventHandler 139excludeAccounts 155Extensible Markup Language 403ExternalLogonServlet 175

FFESI JavaScript interpreter 122firewall 224

port configuration 75flow control 47forgot your password 91form

creation 63design module 64modification 134rendering module 64

formTemplate 127FTP 80, 117ftp 224functional design 56

Ggovernment environment 13grace login 151group 20

management 79membership 154reconciliation 79

group membership 272, 283group of administration 267GSO Resources 168GUI server 72

Hhardware requirements 117Heap Size 117high availability 222historical information 69historical reporting 114historical request 130HpuxProfile 176HR synchronization 249HTTPS 70, 80

IIBM DB2 222IBM Directory Integrator 70, 138, 169, 221, 250

assembly line 170AssemblyLine 139CSV file connectivity 139entry object 141EventHandler 139parser connector 71password synchronizer plug-in 139Windows NT4 connector 139

Index 409

IBM Directory Server 222IBM MQ Series 223IBM MQSeries 118, 141IBM WebSphere Application Server 118, 223identification 50identity

modification 256policy 230suspension 257

identity and credentials 47identity feed 249–250, 271, 287

placement rule 253reconciliation 252supervisor 255

identity management 31, 64identity management module 65Identity Manager

design 77entities 78

identity policy 65, 83, 97, 147, 149, 154, 176, 237, 239iNetOrgPerson object 78installation log 84integrity 211IT best practices 195, 387itamauth.jar 172iv_user 175

JJava Database Connectivity 401Java Message Service 67, 402Java Naming and Directory Interface 249, 402Java Server Pages 402Javadoc 123JavaScript 95, 97, 131, 146, 150, 234, 272

extensible framework 122JDBC 116, 401JMS 67, 402

connector 141JNDI 70, 249, 402

connector 143job role 82, 95, 184, 216join engine 69join type 277joinDirectives 127JSP 402junction 175

KKerberos 402

LLDAP 116, 220, 402

ACL 127analysis 124connector 140, 143directory 69distinguished name 250ePerson object 78excludeAccounts 155group membership 154Identity Manager schema 125iNetOrgPerson object 78membership restrictions 125multi-value fields 252replica server 188tag value pairs 169

LDIF file 155liability 377Lightweight Directory Access Protocol 402location 82locking of accounts 210logging 84, 204logical component architecture 62logical component design

Application Layer 64service layer 66Web User Interface 63

login policy 150logo 131loop 113, 279

MMAC 402mail extensible framework 122mail module 67manage people 91managed resource 92managed services 83management entities 80management of accounts 92Mandatory Access Control 13, 402MASS 40

access control 47architectural decision 54audit 47


component architecture 56flow control 47functional design 56identity and credentials 47solution integrity 47solution model 54use case 55

membership 284menu system module 63messaging module 67Meta Directory 27, 29Method for Architecting Secure Solutions 40methodology 40military environment 13modification of form 134MQSeries 118multi-value fields 252

Nnaming convention 229network diagram 185network topology 223network zone

controlled 72restricted 73trusted 73uncontrolled 72

network zones 72

Oobject

operations 262type prefix 229

ObjectMessage 142operation 262operation report 85, 114organization tree 78, 81, 92, 229–230, 238, 245, 260

design 231module 64

organizational role 82, 95, 155, 157, 168, 176, 242, 246, 271–272, 287OrganizationName 126orgChart 126orphan account 79, 85, 99, 113, 126Other role 243

Pparallel approval 101parser connector 71password

ageing 210challenge question 79change 267forgotten 91generation 272, 275length 204login policy 150management 6, 43, 79, 88, 169, 212, 214, 216management module 66policy 65, 84, 97, 147, 150, 228, 230, 238–239, 241policy enforcement 140policy for Windows 89reset 87, 184, 192, 201retry count 204scheduled change 110strength 98strength checking 94strength policy 150synchronization 79, 89, 150, 169synchronizer plug-in 139

pdadmin 151, 155, 168, 192pending requests 88pending requests list 111people 126performance optimization

DB2 table 131listdata table 131

person 78, 82attributes 132delegate 94entity 150management 91object 154, 169object synchronization 170

personnel management 184physical architecture 115physical components 222placement

... of components 71

... of services 235policy 259rule 253

policy 82, 126corporate 377

Index 411

default 10, 216identity 83, 97, 154, 176, 230, 237, 239join operations 243management 64, 214management module 65module 68normalization 240password 84, 97, 230, 238–239, 241placement 259provisioning 83, 95, 138, 153, 156, 168, 171, 176, 230, 238, 242, 271, 276, 286resolution scope 232scope 239scripts 273service selection 83, 234, 237, 243validation 10, 212

Policy Server 74port configuration 75port number 147practices 379prefix of object type 229principal 82, 263procedures 379profile

service 233protected object policies 168protected object space 168provisioning 68, 82, 155, 231

... of a user 235advanced parameters 154connector API 122engine 36method 236non-IT resources 289policy 65, 83, 95, 138, 146, 151, 153, 156, 168, 171, 176, 230, 238, 242, 271, 276, 286policy compliance check 271policy join directives 127scripts 273

proximity selection 236pseudonymity 50

Qquality of service 195, 387

RRACF agent 80, 117RBAC 11, 18, 270, 282, 402

role design 21system design 22

reconciliation 70, 79, 98, 146, 154–155, 229, 254, 284

identity feed 252report 85

recycleBin 127Redbooks Web site 406

Contact us xviredirectlogoff.jsp 174redirectlogout.jsp 172rejected request report 85relational database 69remote services module 68report system 103reporting 114

module 66reports 85, 89Request for Information 277, 279request for information 65requirements

software and hardware 117resolution scope 232resource 92resource access lists 167resource.def 294, 298restricted network 73return on investment 3, 194, 385, 403reverse password synchronization 151reverse proxy 188RFI 65

node 102risk assessment 4risk management 195, 386risk mitigation 3ROI 199, 276, 403role 20, 65, 82, 101, 106, 126, 216, 230, 271–272

Access Manager 287All 243organizational 242, 246Other 243

Role Based Access Control 3, 10–11, 247, 270, 282, 402rule 259runConfig utility 131

Sschedule information 69


schedulerscheduled_message table 131

scheduling... of changes 110... of reconciliations 112module 68

schema.dsml 294–295scope 262scope of policy 239scripts 273search function 93search module 64sec_master 155secrets 49Secure Sockets Layer 403Securelink 80security architecture 37, 52security design objectives

Identity Management foundation 209security domain 156security policy 4, 43, 73, 146, 167security roles 167self-care 267self-service 87, 260

interfaces 36senior administrator 156sensitivity silo 17serial approval 101server log 84server principals 155service 146, 267

... selection policy 65, 83, 234, 237, 243Access Manager 147administration 234design requirements 234instance 84layer 66, 220placement 235profile 147, 233report 85

serviceProfile 126services 126

DB2 tables 130remote_resources_recon_queries table 130remote_resources_recons table 130remote_services_requests table 130resource_providers table 130

session timeout 123shared secret 275

Simple Object Access Protocol 403single server configuration 222single sign-on 122, 146, 170sleep interval connector parameter 141SOAP 403

parser 142software requirements 117Solaris requirements 119SolarisProfile 176solution architecture 54solution integrity 47solution model 54SSL 75, 127, 403

certificate 147start element 100static membership 284status change 68strategic advantage 387strategic business initiative 195, 386strength policy 150subject 150subprocess 279supervisor 252, 266, 268support administrator 156suspension 257synchronization

HR data 249synchronization feed 256synchronization of passwords 66, 79, 89, 150syncPassword method 140sysRoles 126system administrator 82system configuration module 66systems management zone 190systemUser 127

Ttable analysis 129TAMProfile 155target systems 43target type profiles 176TextMessage 142timpwflt.dll 140to-do list 88, 99, 102toolkit 290transactional information 69transactions 50trusted network 73

Index 413

Uui.properties 174uncontrolled network 72Universal Provisioning Agent 289UNIX endpoint 151UNIX user ID synchronization 175use case 55user 78

management 43, 191provisioning 27, 30, 231, 235registry 146report 85self-care 267self-service 260

user ID generation 82user interface 105, 218, 223

customization 131user suspension

scheduling of ... 111user to role mapping 107

Vvalidation policy 10, 212Virtual Meta Directory 29

WWeb Portal Manager 151, 155, 168Web single sign-on 170Web user interface 105, 218, 223Web User Interface Layer 63WebSEAL 72, 74, 146, 151, 169–170, 187, 222, 224

business entitlements 146dynamic business entitlements 169junction 175reverse password synchronization 151

WebSphere Application Serversee IBM WebSphere Application Server

Windowsdomain login 89NT4 connector 139password policy 89password reset 89requirements 120

work item 130workflow 84, 99, 126, 130, 138, 214, 230, 271, 276

approval 83, 278approval element 101

database 223DB2 tables 130design 63, 216elements 100end element 101engine 36escalation limit 113java applet 99join type 277loop 113, 279management module 65module 68parallel approval 101password_transaction table 130pending table 130process table 130processdata table 130processlog table 130Request for Information 279serial approval 101start element 100subprocess 279time limits 113workitem table 130

worklist management module 65WorldWide Project Management Methodology 40WWPMM 40

XX.500 27, 402X.509 certificate authentication 67xforms.xml 294XML 69, 117, 135, 403

parser 251


(1.0” spine)0.875”<

->1.498”460 <

-> 788 pages

Identity Managem

ent Design Guidew

ith IBM Tivoli Identity M

anager

®

SG24-6996-00 ISBN 0738453323

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICALINFORMATION BASED ONPRACTICAL 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 ManagementDesign Guidewith IBM Tivoli Identity Manager

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.

Back cover

Documents

Identity Management Design Guide