Upload
bupbechanh
View
255
Download
1
Embed Size (px)
Citation preview
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
1/427
ibm.com/redbooks
Identity ManagemenAdvanced Designfor IBM Tivoli Identity Manager
Axel Andre
Alessandro
Takayos
Complete self-care scenario usingworkflow, lifecycle rules, and certification
High availability scenario for
WebSphere, DB2, and LDAP
Addressing compliance
with audit and reporting
Front cover
http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
2/427
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
3/427
Identity Management Advanced Design for IBM
Tivoli Identity Manager
August 2006
International Technical Support Organization
SG24-7242-0
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
4/427
Copyright International Business Machines Corporation 2006. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADSchedule Contract with IBM Corp.
First Edition (August 2006)
This edition applies to IBM Tivoli Identity Manager Version 4.6.
Note: Before using this information and the product it supports, read the information inNotices on page vii.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
5/427
Copyright IBM Corp. 2006. All rights reserved.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .iThe team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ixBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Part 1. Advanced Identity Topics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 1. Advanced design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1 Understanding the system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Logical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Web User Interface Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 Applications Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Services Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.5 LDAP Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.6 Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.7 Resource connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Application Programming Interface (API) . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.1 Application API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Authentication API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.3 Data Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.4 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.5 Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.6 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.7 Password rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.8 Remote Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.9 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.10 FESI extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.1 Script nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.2 Workflow extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Custom service provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Custom reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Chapter 2. Architect a high availability solution . . . . . . . . . . . . . . . . . . . . 62.1 Application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
6/427
iv Identity Management Advanced Design for IBM Tivoli Identity Manager
2.2 Directory server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 Manual failover to secondary LDAP . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Automated failover to secondary LDAP . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Relational database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Operating system cluster with DB2 active/standby . . . . . . . . . . . . . . 7
2.3.2 DB2 mutual takeover multiple partition . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3 DB2 High Availability Disaster Recovery (HADR). . . . . . . . . . . . . . . 72.4 Identity Manager adapters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Manual failover to secondary adapter . . . . . . . . . . . . . . . . . . . . . . . . 72.4.2 Automated failover to secondary adapter . . . . . . . . . . . . . . . . . . . . . 72.4.3 Event notification on an HA adapter configuration . . . . . . . . . . . . . . 8
2.5 Physical HA component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.1 Component configuration and placement . . . . . . . . . . . . . . . . . . . . . 82.5.2 Network zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Security and integrity for high availability . . . . . . . . . . . . . . . . . . . . . . . . . 82.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Part 2. Customer Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 3. Tivoli Austin Airlines, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1 Company profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Geographic distribution of TAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Organization of TAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.3 HR and personnel procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Current IT architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1 Overview of the TAA network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.2 TAAs e-business initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.3 Security infrastructure for the e-business initiative . . . . . . . . . . . . . 10
3.2.4 Secured e-business initiative architecture. . . . . . . . . . . . . . . . . . . . 103.2.5 Identity management and emerging issues . . . . . . . . . . . . . . . . . . 10
3.3 Corporate business vision and objectives. . . . . . . . . . . . . . . . . . . . . . . . 113.4 Project layout and implementation phases . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 4. Project design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Design approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.4 Implementation approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.2 Requirement priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.4.3 Implementation tasks and efforts . . . . . . . . . . . . . . . . . . . . . . . . . . 114.4.4 Project phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 5. Technical implementation phase I. . . . . . . . . . . . . . . . . . . . . . 12
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
7/427
Contents
5.1 TAAs high availability scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.1.2 TAAs high availability planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Application server high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3 Application server high availability implementation. . . . . . . . . . . . . 125.3 Relational database high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.3.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.3.3 Relational database high availability implementation . . . . . . . . . . . 13
5.4 Directory Server high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.4.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4.3 TAAs Directory Server high availability implementation. . . . . . . . . 155.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 6. Technical implementation phase II . . . . . . . . . . . . . . . . . . . . . 206.1 Self-care . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.1.3 TAAs implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Delegated administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.2.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.2.3 TAAs implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Advanced custom report design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3.3 TAAs implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4 Automated operation report delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.4.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.4.3 TAAs implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.5 Recertification process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.5.2 Design considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.5.3 TAAs implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Corporate policy and standards . . . . . . . . . . . . . . . . . . . . . 31Standards, practices, and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
8/427
vi Identity Management Advanced Design for IBM Tivoli Identity Manager
Practical example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31External standards and certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Industry specific requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Product or solution certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Nationally and internationally recognized standards. . . . . . . . . . . . . . . . . 31
Legal requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32BulkFeedAdminDomain.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32AdminDomainModelExtension.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32AbstractExtension.java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33AbstractExtension.java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33applicationServlet.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
applications.jsp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35application_sub.jsp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36todolistServlet.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
todolist.jsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37mainServlet.java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37main.jsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix C. Tivoli Directory Server proxy server . . . . . . . . . . . . . . . . . . 38
Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
System requirements for downloading the Web material . . . . . . . . . . . . . 39How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
9/427
Copyright IBM Corp. 2006. All rights reserved. v
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. Consuyour local IBM representative for information on the products and services currently available in your areaAny reference to an IBM product, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product, program, or service thatdoes not infringe any IBM intellectual property right may be used instead. However, it is the user'sresponsibility 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 licenseinquiries, 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 provisionsare inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDESTHIS 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 disclaimeof 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 madto the information herein; these changes will be incorporated in new editions of the publication. IBM maymake improvements and/or changes in the product(s) and/or the program(s) described in this publication aany time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in anmanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials 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 publisheannouncements or other publicly available sources. IBM has not tested those products and cannot confirmthe accuracy of performance, compatibility or any other claims related to non-IBM products. Questions onthe 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 themas completely as possible, the examples include the names of individuals, companies, brands, and productAll of these names are fictitious and any similarity to the names and addresses used by an actual businesenterprise is entirely coincidental.
COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrates programmingtechniques 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 applicatioprograms conforming to the application programming interface for the operating platform for which thesample 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 copymodify, and distribute these sample programs in any form without payment to IBM for the purposes ofdeveloping, using, marketing, or distributing application programs conforming to IBM's applicationprogramming interfaces.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
10/427
viii Identity Management Advanced Design for IBM Tivoli Identity Manager
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United Stateother countries, or both:
EserverRedbooks (logo)
xSeriesz/OSAIXDB2 Universal Database
DB2HACMP
IBMLotus NotesLotusNotes
RedbooksRACF
TivoliWebSphere
The following terms are trademarks of other companies:
Enterprise JavaBeans, EJB, Java, Java Naming and Directory Interface, JavaBeans, JavaScript,JavaServer, JavaServer Pages, JDBC, JSP, JVM, J2EE, Solaris, Sun, Sun Microsystems, and allJava-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, oboth.
Active Directory, JScript, Windows NT, Windows, and the Windows logo are trademarks of MicrosoftCorporation in the United States, other countries, or both.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Mozilla, Firefox, Thunderbird, Mozilla logo, the Firefox logo and the Thunderbird logo are trademarks orregistered trademarks of Mozilla in the United States, other countries or both
Other company, product, or service names may be trademarks or service marks of others.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
11/427
Copyright IBM Corp. 2006. All rights reserved.
Preface
Identity and user lifecycle management projects are being deployed more and
more frequently - and demand is growing. By demonstrating how IBM TivoliIdentity Manager can be made resilient and adapted to special functionalrequirements, this IBM Redbook creates or enhances confidence in the IBMTivoli Identity Manager-based solution for senior management, architects, andsecurity administrators.
Advanced design topics can start with infrastructure availability for all involvedcomponents, Web application and database server clustering as well as LDAPmulti-master setups. Advanced care topics can continue with compliancechallenges addressing enhanced auditing and reporting, and designing andcreating your own self-care and self-registration application environment thatembraces external users and business partners, offering fine-tuned workflowoptions and lifecycle management capabilities.
The powerful features and extensions of IBM Tivoli Identity Manager is openingdoors into a world of advanced design and customization for every identitymanagement challenge you might encounter.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.Axel Buecker is a Certified Consulting Software IT Specialist at the InternationTechnical Support Organization, Austin Center. He writes extensively andteaches IBM classes worldwide about areas of Software Security Architectureand Network Computing Technologies. He holds a degree in computer sciencefrom the University of Bremen, Germany. He has 20 years of experience in avariety of areas related to Workstation and Systems Management, NetworkComputing, and e-business Solutions. Before joining the ITSO in March 2000,Axel worked for IBM in Germany as a Senior IT Specialist in Software SecurityArchitecture.
Andrew Annas is a Senior IT Specialist with IBM Tivoli Software in the UnitedStates. He often teaches classes about deploying and customizing IBM TivoliIdentity Manager. He has five years of experience in identity management andtwelve years experience in the deployment of enterprise software applications.He holds a degree in Computer Science from the University of California, Irvine
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
12/427
x Identity Management Advanced Design for IBM Tivoli Identity Manager
Alessandro Faustini is an IT Specialist in IBM Software Group, Italy. He joinedIBM in 2000 and has a three-year history in security and systems managementsolutions. His product experience includes the Tivoli Identity Manager, TivoliAccess Manager, and Tivoli Federated Identity Manager. He holds a degree inElectronic Engineering from University La Sapienza in Rome.
Takayoshi Sanui is an IT Specialist in IBM Japan Systems Engineering. He ha
four years of experience in identity management and IT security. He has alsobeen teaching classes about Tivoli security products in Japan. He holds a degrein Computer Science from the Tokyo Institute of Technology.
From left to right: Axel, Andrew, Takayoshi, and Alessandro
Thanks to the following people for their contributions to this project:
Leslie ParhamInternational Technical Support Organization, San Jose Center
Alex Amies, Dave Bachmann, Chris Bauserman, Brian Davis, MarkMcConaughy, Connie Nelin, Casey Peel, Jeffrey Robke, Thomas Sharp, JimSides, James Sun, and Weibo YuanIBM US
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
13/427
Preface
Gene Kligerman, Dale McInnis, and Vivien PageIBM Canada
Become a published author
Join us for a two- to six-week residency program! Help write an IBM Redbookdealing with specific products or solutions, while getting hands-on experiencewith leading-edge technologies. You'll team with IBM technical professionals,Business Partners, and/or customers.
Your efforts will help increase product acceptance and customer satisfaction. Aa bonus, you'll develop a network of contacts in IBM development labs, andincrease your productivity and marketability.
Find out more about the residency program, browse the residency index, andapply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Send us your commentsabout 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 e-mail to:
Mail your comments to:
IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400
http://www.redbooks.ibm.com/residencies.htmlhttp://www.redbooks.ibm.com/residencies.htmlhttp://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/contacts.htmlhttp://www.redbooks.ibm.com/contacts.htmlhttp://www.redbooks.ibm.com/http://www.redbooks.ibm.com/http://www.redbooks.ibm.com/residencies.htmlhttp://www.redbooks.ibm.com/residencies.html7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
14/427
xii Identity Management Advanced Design for IBM Tivoli Identity Manager
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
15/427
Copyright IBM Corp. 2006. All rights reserved.
Part 1
AdvancedIdentity Topics
In this part, we introduce advanced identity management topics, specifically, thApplication Programing Interfaces (APIs) of IBM Tivoli Identity Manager 4.6, anwhat you can achieve by using these APIs as well as high availability scenariosIdentity Manager can handle a multitude of integration aspects and many ITinfrastructures, Web portals, and application environments, which we describe detail throughout this part of the book. After we discuss the advanced topics,Part 2, Customer Scenario on page 93 provides a more solution-oriented,scenario-based approach to the topics discussed in this part.
Part 1
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
16/427
2 Identity Management Advanced Design for IBM Tivoli Identity Manager
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
17/427
Copyright IBM Corp. 2006. All rights reserved.
Chapter 1. Advanced design overview
This chapter introduces the high-level components and new concepts for thedesign of advanced identity management solutions.
This chapter provides you with an understanding of the following IBM TivoliIdentity Manager topics:
The high-level logical component architecture The various internal modules and subprocesses The high-level physical architecture
1
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
18/427
4 Identity Management Advanced Design for IBM Tivoli Identity Manager
1.1 Understanding the system architecture
In order to understand IBM Tivoli Identity Manager system architecture and howto utilize its capabilities, it is important to understand how the architecture is laiout logically. In the following section, we explain the logical components of theIdentity Manager architecture.
1.1.1 Logical component architecture
IBM Tivoli Identity Manager can be thought of logically as having two primaryareas of functionality: presentation and provisioning. The presentationfunctionality is represented logically by the Web User Interface, and provisionincan be thought of as the provisioning platform. The provisioning platform can bfurther logically divided into two more layers of functionality, the applicationslayer and that of the core services layer. The applications layer acts as anexternal interface to core services from both the Web User Interface and externapplications such as an identity store or other types of applications. In Figure 1-
on page 5, we depict these three functional areas graphically, showing theIdentity Manager API and the two functional areas we have just described.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
19/427
Chapter 1. Advanced design overview
Figure 1-1 IBM Tivoli Identity Manager logical architecture
The following sections cover each individual layer in more detail.
1.1.2 Web User Interface Layer
The Web User Interface is a set of combined subprocesses that provide all theapplications of the Applications layer content to a users browser as well as theinitiation of applets (both run on the client and the server), such as the WorkflowDesign and the Form Creation.
Figure 1-2 on page 6 is a graphical representation of the Web User Interfacefollowed by a description of each of the modules shown.
A p p l i c a t i o n
S e r v i c e
L D A PD a t a b a s e
A p p l i c a t i o n
A d a p t e r
R D B M S
A d a p t e r
O p e r a t i n g
S y s t e m
A d a p t e r
E n d U s e r
B r o w s e r
Trans ac t i ona l /
Sc hedu l i ng /H is to r i c a
D a t a
Ident i t ies ,
A c c o u n ts , R o le s ,
O rg C ha r t , Pol ic ies ,
W ork f low
I dent i t y S tore
W e b U s e r
I n te r face
J a v a / X M L A P I
E x t e r n a l
A p p l i c a t i o n
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
20/427
6 Identity Management Advanced Design for IBM Tivoli Identity Manager
Figure 1-2 Web User Interface module subprocesses
Menu SystemThe Menu System module provides a consistent menu and shortcut mechanismthat are used for navigation throughout the user interface.
Form RenderingThe Form Rendering module provides the run-time interpreter to display thecustomized forms designed in the Form Design module.
SearchThe Search module provides a framework for general and more specific searchinterfaces to be used throughout the user interface.
Form Design
The Form Design module provides a near WYSIWYG (What You See Is WhatYou Get) user interface design environment for customizing the forms thatdisplay information about the entities managed through the user interface. Thismodule makes use of applets for its more flexible demands.
Organization TreeThe Organization Tree module provides the graphical tree representation of theorganizational structure in which entities managed through the user interface arlogically stored.
DesktopThe Desktop module provides a framework for providing a consistent layout inthe pages displayed in the user interface. It is within this framework that productof the other Web User Interface modules are displayed, such as the MenuSystem and Organization Tree.
Interf
ace
Web User Interface
Menu SystemForm
RenderingSearch
Organization
TreeDesktop
Workflow
Design
Form Design
Application
Interface
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
21/427
Chapter 1. Advanced design overview
Workflow DesignThe Workflow Design module provides a graphical workflow design environmenA workflow process consists of a set of activities that are executed in an orderefashion according to conditional transitions. The designer provides a graphicalway of defining such a workflow process. This module makes use of applets foits more flexible demands.
Application InterfaceThe Application Interface module consists of all application-specific userinterface components. For example, the interfaces required to create aprovisioning policy or an account are organized into this module. This modulemakes use of other modules in the Web User Interface subsystem, such as theForm Rendering and Search modules.
1.1.3 Applications Layer
The applications layer is the remoteable external interface used to access allpublicly available provisioning functions.
The Applications subsystem contains all modules that provide provisioningspecific capabilities, such as identity management, account management, andpolicy management. Each application makes use of the core services in theServices layer to achieve its goals. It is the Applications module that provides thexternal interface to the provisioning platform. Figure 1-3 is a graphicalrepresentation of the Applications Interface followed by a description of each ofthe modules shown.
Figure 1-3 Applications module subprocesses
System ConfigurationThe System Configuration module provides the capabilities required to managethe IBM Tivoli Identity Manager system, such as defining behavioral properties
Appl icat ions
Sys tem
Conf igurat ion
Repor t ing
Pol icy
M a n a g e m e n t
A ccou nt
M a n a g e m e n t
Identi tyM a n a g e m e n t
Enti ty
W orkflo w
M a n a g e m e n t
M a n a g e m e n t
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
22/427
8 Identity Management Advanced Design for IBM Tivoli Identity Manager
Policy ManagementThe Policy Management module provides the capabilities to manage the policiein the system, including provisioning, password, service selection, and identitypolicies.
Identity Management
The Identity Management module provides the capabilities required to manageidentities, such as their addition, removal, suspension, reinstatement, transferaand modification, including the changing of roles. The definition of roles,including dynamic roles, is also included in this module.
Workflow ManagementThe Workflow Management module provides the capabilities required to managworkflow processes, such as their addition, modification, and removal. The abilitto view the status and details of active and historical processes is also providedin this module.
ReportingThe Reporting module provides the canned report capabilities of the system.This module provides the query and formatting of the reports driven from theuser interface.
Account ManagementThe Account Management module provides the capabilities required to managaccounts, such as their addition, removal, suspension, reinstatement, andmodification.
Entity ManagementThe Entity Management module provides the capabilities required to manage thtypes of entities managed by the system, such as types of identities andaccounts. This includes the ability to define the schema for the entity type, theoperations the entity type can support, and the lifecycle of the entity type.
Note: Sitting between the Web user interface and the Applications layer inFigure 1-1 on page 5 is the public Java API. This API provides a set of Javaclasses that abstracts the more commonly used functions of the provisioningplatform, such as identity management, password management, and account
management. The classes that make up this API are the same classes theIdentity Manager product uses for its out-of-the-box user interface.
For more information, refer to documentation provided with the ApplicationsAPI in the /extensions/doc/applications directory.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
23/427
Chapter 1. Advanced design overview
1.1.4 Services Layer
The Core Services subsystem contains all modules that provide general servicethat can be used within the context of provisioning, such as authentication,authorization, workflow, and policy enforcement. These services often make usof other services to achieve their goals. Figure 1-4 is a graphical representationof the Services Interface followed by a description of each of the modules show
Figure 1-4 Core Services module subprocesses
AuthenticationThe Authentication module provides a set of authentication implementations thacan be used by clients of the service. Examples of these implementations aresimple password authentication and X.509 certificate authentication. The moduis designed as a framework that can be extended by customers to provide theirown implementations.
RoleThe Role module evaluates dynamic memberships to roles. This module iscalled upon when an identity or dynamic role definition changes to identify whicidentities should be members of dynamic roles.
Policy
The Policy module enforces the policies that associate users with services. Themodule ensures that provisioning requests conform to the policies that aredefined. The module resolves the appropriate policies that apply to a user anddetermines the services for which that user is authorized. The module validates
Core Services
Managed Services
HR DatastoreWorkflow Database
Authentication
Scheduling
Policy
Messaging Data ServicesRemote
Services
Workflow AuthorizationRole
Logging
Identity/Operational
Database
Orchestration
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
24/427
10 Identity Management Advanced Design for IBM Tivoli Identity Manager
and generates passwords. The module generates identities for users andaccounts.
OrchestrationThe Orchestration module provides a coordination service for extensibleoperations that are performed on entities and manages the lifecycles of those
entities. For instance, the orchestration module provides an abstraction layer tothe Account Management application for executing the steps needed to provisioan account of a given type. Regardless of the steps involved, which could becustomized or changed, the Account Management module would always use thsame interface to the Orchestration module.
WorkflowThe Workflow module executes and tracks transactions within the system. Thiswould include the provisioning and de-provisioning of a service, a user's statuschange, the custom process associated with a provisioning request in thesystem, 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 executionand historical auditing purposes. Clients can query the Workflow module for thestatus of the transactions being executed.
AuthorizationThe Authorization module provides an interface to enforce authorization rules aclients attempt operations in the system. These rules apply to accessing datawithin the system, as well as to operations that can be applied to the systemdata.
SchedulingThe Scheduling module provides a timer that notifies clients of timed events fowhich they are subscribed. The Scheduling module uses the Messaging moduto notify those clients.
Messaging
The Messaging module provides guaranteed asynchronous messaging to andbetween internal modules in the architecture. The module relies heavily on theJava Message Service (JMS) specification to provide support for multiplemessaging middleware vendor implementations.
Note: The clients discussed in this section are internal to Identity Manager.For example, workflow is a client to scheduling; it uses scheduling to allowworkflows to start at a later date instead of immediately.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
25/427
Chapter 1. Advanced design overview 1
Data ServicesThe Data Services module provides a logical view of the data in persistentstorage (LDAPv3 directory) in a manner that is independent of the type of datasource that holds the data. The model abstracts the details of the stored data intmore usable constructs, such as Users, Groups, and Services. The model alsoprovides an extendable interface to allow for customized attributes that
correspond to these constructs. Metadata information about the persistent datacan also be retrieved using this module.
Remote ServicesThe Remote Services module provides the interaction with the external systemfor provisioning and de-provisioning services. The synchronization of serviceinformation and user information is also performed within this module. Themodule is designed as a framework that can be extended by customers toprovide their own implementations of provisioning and de-provisioning ofservices. This allows the platform to easily support different protocols and APIsthat may be supported by the resources to be provisioned.
LoggingThe Logging module provides a common logging interface to all other modules
MailThe Mail module provides an interface for notifying users via a messagingsystem, such as e-mail. The module is configurable to accommodate differentmessaging systems.
1.1.5 LDAP DirectoryThe IBM Tivoli Identity Manager system uses an LDAPv3 directory server as itsprimary repository for storing the current state of the enterprise it is managing.This state information includes the identities, accounts, roles, organization charpolicies, and workflow designs.
More details about the LDAP Directory and its schema are available in the IBMTivoli Identity Manager Database and Schema Reference Version 4.6,SC32-1769.
1.1.6 DatabaseA relational database is used to store all transactional, reporting, and scheduleinformation. Typically, this information is temporary for the currently executingtransactions, but there is also historical information that is stored indefinitely toprovide an audit trail of all transactions that the system has executed.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
26/427
12 Identity Management Advanced Design for IBM Tivoli Identity Manager
More details about the database and its schema are available in IBM TivoliIdentity Manager Database and Schema Reference Version 4.6, SC32-1769.
1.1.7 Resource connectivity
The back-end resources that are being provisioned by IBM Tivoli Identity
Manager are generally very diverse in their capabilities and interfaces. The IBMTivoli Identity Manager system itself provides an extensible framework foradapting to these differences in order to communicate directly with the resourceFor a more distributed computing alternative, a built-in capability to communicatwith a remote adapter is provided. The adapters typically use an XML-basedprotocol, either Directory Access Markup Language (DAML) or Directory ServicMarkup Language (DSML Version 2), as a communications mechanism.
Directory Access Markup Language connectivityDAML is a proprietary XML message format used when communicating with onof IBM Tivoli Identity Managers standalone adapters. These adapters are
programs installed on either the managed resource or on a host that can managthe resource through a remote administration API.
DAML is a simple XML schema definition that enables the encoding of identityinformation in the form of an XML document so that it can be easily shared via Iprotocols such as HTTPS, as shown in Figure 1-5.
Figure 1-5 DAML connectivity to a service
Transactions from the IBM Tivoli Identity Manager Server are sent securely viaHTTPS to the service adapter and then processed by the adapter.
For example, if a service has just been connected to the IBM Tivoli IdentityManager Server, the accounts that already exist on the server can be reconcile
IP
Network
DATA
Identity Manager
Server
Web Interface
Applications
Core Services
DAML over HTTP/S
DAML
Adapter
Service
http://-/?-http://-/?-7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
27/427
Chapter 1. Advanced design overview 1
or pulled back in order to import the users details into the IBM Tivoli IdentityManager LDAP directory. If a password change or a provisioning of a new useroccurs, the information is transferred to and then processed by the adapter. Thadapter deposits the new information within the application or operating systemthat is managed.
Directory Service Markup Language connectivityDSMLv2 is an industry standard XML message format for the representation ofdirectory data and operations. There are no standard IBM Tivoli Identity Manageadapters that use DSMLv2. Instead, DSMLv2 is used in conjunction with IBMTivoli Directory Integrator to create custom adapters.
Directory Integrator provides an easy and flexible way to link IBM Tivoli IdentityManager to a wide variety of managed resources. Directory Integrator offersconnectors that can be used to manage data in files, directories, databases,message queues, and many other data sources. It allows you to define, usingsimple scripts, how DSMLv2 operations issued by IBM Tivoli Identity Manager
should be translated into operations on the managed resource, as shown inFigure 1-6.
Figure 1-6 DSMLv2 service communication using IBM Tivoli Directory Integrator
1.2 Application Programming Interface (API)
The API provided for the system is organized into two categories based on theprogramming language, Java and JavaScript. TheJavaScript APIis useddirectly by users of the graphical user interface when defining rules in thesystem, such as with identity policies, provisioning policies, and workflowdesigns.
IP Network
ServiceIdentity Manager
Server
Applications
Core Services
Web Interface
DATA
DSML v2 over HTTP/S
Directory
Integrator
DSMLv2
Handler
Data
Connector
Scripts
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
28/427
14 Identity Management Advanced Design for IBM Tivoli Identity Manager
TheJava APIcan be further subdivided into two more categories, an API forinterfacing with the system and an API for extending the system's behavior. Inother words, the interface APIallows external programs to direct the provisioninsystem to perform some actions or to simply query the provisioning system forsome information. The extension APIallows custom Java code to be called fromthe provisioning system during its regular flow within the same context (andJVM).
Since the interface API can be called by any program that is out of the control othe provisioning system, a strict security layer is built into it. A JAASimplementation is provided and required to be used by clients to authenticateagainst the Identity Manager user store. Once authenticated, the JAAS principamust be authorized to execute each API against the requested objects in thesystem's data model. This is identical to the security provided by the graphicaluser interface of the system. The interface APIconsists of the followingpackages already described:
Applications
JAAS Identity Provisioning Workflow Search
The extension API can only be called by the provisioning system, or at leastwithin the same application server. The API is not remoteable. This API is alsoused within the provisioning system itself. The functions provided by this APImust be extremely fast and have very little overhead. Due to its restricted useand overhead requirements, this API does not have a strict security model. The
extension APIconsists of the following packages already described:
Authentication (all) Data Services Model Domain Logging Mail Workflow Password Rules (all) Remote Services Provider
Workflow Applications Model Provisioning Query
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
29/427
Chapter 1. Advanced design overview 1
We discuss each one of these API categories in more detail in the followingsection.
1.2.1 Application API
TheApplication package represents the Application subsystem of the System
Architecture. This package contains classes that aggregate the capabilitiesprovided in the Services subsystem into more abstract provisioning specificapplications, such as those required to manage passwords or accounts. Thispackage provides the external interface to the provisioning platform forpresentation-oriented clients to use. The applications provided within thispackage enforce security for the platform by authenticating all clients andauthorizing all operations.
There are two major areas of distinction in the Application package. One areacontains packages that are not only used by the Identity Manager user interfactier, but also provided as a public interface, Application Programming Interface
(API). The second area contains packages, which are used solely by the IdentiManager user interface, and the second area is not provided as a publicinterface.
For organization purposes, the public API portion of the Application package habeen broken down into five sub-packages,Identity,Provisioning, Search,Workflow, andJAAS. TheIdentity package represents the Identity Managemenmodule in the Applications subsystem of the System Architecture. It contains thclasses that provide the capabilities to manage identities, or people, includingtheir placement in an organizational chart and their categorization through role
TheProvisioning package represents the Account Management module in the
Applications subsystem of the System Architecture. At the base level, theProvisioning package contains the classes that provide the capability forprovisioning the identities to external resources via accounts. This also includethe management of passwords on those resources. Both packages have adependency on the Identity package.
The Workflow package represents the Workflow Management module in theApplications subsystem of the System Architecture. It contains the classes thatprovide the auditing and management capabilities of workflow processes fromthe user's perspective. This package provides an authorization layer over thecapabilities of the Workflow package in the Services subsystem. This package
also has a dependency on the Identity package to provide an identity's workflowassignments.
The Search package contains the classes that provide general searchcapabilities over any of the objects managed in the system (identities, accounts
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
30/427
16 Identity Management Advanced Design for IBM Tivoli Identity Manager
and so on). This package does not, however, have a dependency on the otherpackages listed because it interacts directly with the Data Services architecturamodule for these managed objects.
TheJAAS package contains JAAS extensions to provide an authenticationmechanism for users of the Application package within the JAAS framework. Aother Application packages have a dependency on this package for identifying
the authenticated user. The JAAS package utilizes the Authentication service toimplement the user authentication. Below in Figure 1-7 is a graphicalrepresentation of these packages and how they interact.
Figure 1-7 Application Public Interface Package Diagram
The root Application package provides general use classes that can be used ball sub-packages when implementing specific provisioning features. Below inFigure 1-8 on page 17 is a diagram of the Application class.
identity
workflowprovisioning
search
jaas
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
31/427
Chapter 1. Advanced design overview 1
Figure 1-8 Application class diagram
ThePlatformContextrepresents a connection to the provisioning platform. ThisPlatformContextis an interface that can be implemented differently dependingon the deployment of the provisioning platform. The different implementationsare constructed using a corresponding implementation of the
PlatformContextFactory.
To help keep the client simple, theInitialPlatformContextclass provides animplementation of thePlatformContextinterface that constructs the proper
PlatformContextimplementation to communicate with the provisioning platformusing the correctPlatformContextFactory. The client merely has to reference thcorrect factory class name during theInitialPlatformContext's construction.
1.2.2 Authentication APITheAuthentication package represents the Authentication module within theServices module of the System Architecture. This package contains the classeneeded to authenticate users of the system using an extensible framework toallow custom authentication mechanisms to be put in place. A defaultimplementation for password credentials checked against the platform's datastore is provided.
The Authentication package holds the classes that provide authenticationservices for clients. The design of this package is based on a framework to allocustom authentication implementations to be registered with the system. Below
in Figure 1-9 on page 18 is a graphical representation of these classes and howthey interact.
PlatformContext
getEnvironment()
getEnvProperty()
close()
InitialPlatformContext
InitialPlatformContext()
PlatformContextFactory
create()
creates
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
32/427
18 Identity Management Advanced Design for IBM Tivoli Identity Manager
Figure 1-9 Authentication class diagram
TheAuthenticator interface provides the primary method signature for clients trequest authentication of an identity using a set of credentials. The
AuthenticationAuthority class implements that interface with a flexible
implementation of delegating the implementation of the authentication to anAuthenticationProviderimplementation. This bridge pattern allows for theAuthenticatorclient interface to be specialized independently of theimplementation mechanisms. AnAuthenticationProviderFactory is used by the
AuthenticationAuthority to construct the provider.
SystemThe System package is a sub-package of Authentication that provides the IdentiManager specific implementation of theAuthenticator interface that provides thultimate flexibility in both selecting implementations of authentication
mechanisms as well as the number of authentication types that are supported(for example, user certificates, user passwords, distributed agent authenticationand so on). See Figure 1-10.
Figure 1-10 System authentication class diagram
Authenticator
authenticate()
AuthenticationProvider
authenticate()
AuthenticationProviderFactory
getProvider()
creates
AuthenticationAuthority
delegates authentication
SystemAuthenticationAuthority
getInstance()
Authenticator
authenticate()
(from authentication)
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
33/427
Chapter 1. Advanced design overview 1
The SystemAuthenticationAuthority is a singleton class that implements theAuthenticator interface to provide the global authentication service to theprovisioning platform. It is flexible in that it reads from a configuration file thetypes of authentication needs required by its clients and the implementations othose authentication needs. This allows for additional applications to bedeveloped that can have new authentication needs met very simply withoutaffecting the implementation of this module, as well as for deployment choices ohow to implement the authentication (for example, using a Windows NT domacontroller as the authentication store).
1.2.3 Data Services
TheData Services package holds the object-oriented logical representation of thsystem's subject data held within persistent storage. The goal of the package isto provide an intuitive, flexible, and efficient interface to the data repositorywithout revealing the details of the storage mechanism or format to thepackage's client. This package is further divided into the two packages, Model
and Schema.
TheModel package itself is quite large. For purposes of organization, the Modepackage has been divided into several sub-packages, Domain, Form, Policy,Workflow, and System. ThePolicy package holds the data objects relevant topolicies. The Workflow package holds the data objects relevant to workflowdesigns. Since policies reference services, roles, and workflow designs, thePolicy package has a dependency on the Domain package. TheDomain
package holds the data objects relevant to an organization, such as locations,people, services, and roles. The System package holds the data objects relevanto Identity Manager users specifically, such as Identity Manager accounts andgroups for authorization. Since an Identity Manager account must be traced bacto its owner, the System package has a dependency on the Domain also.
The Model and Schema packages represent the modules defined in the SystemArchitecture for the Data Services subsystem. The Model package provides athin abstraction layer above the data store for all persistent objects managed bthe system. The Model package has a dependency on the Schema package foobtaining schema information needed to efficiently access system data frompersistent storage. See Figure 1-11 on page 20.
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
34/427
20 Identity Management Advanced Design for IBM Tivoli Identity Manager
Figure 1-11 Data Services Package Diagram
SchemaThe Schema package contains a set of objects that represent the schema of thedata store. This interface provides clients the ability to query different aspects oclasses and attributes in the data store, which is particularly useful in this systemwhich allows customers to use their own class and attribute definitions within th
data model.
The SchemaAttribute class represents attribute information. This class can beretrieved independently. In addition to the standard LDAP schema informationabout an attribute, additional information, such as whether the attribute isenumerated and what those enumerations are, is provided by the
AttributeConstraintclass, which can be obtained from the SchemaAttribute.
ModelTheModel package holds the system's subject data specific to the manageddomain. This includes domain information such as the organization, people,
services, accounts, and policies. Since there are a large number of objects in thDomain Model package, the Model package has been further subdivided intoseveral other packages. At the base Model package level, some objects havebeen defined that can be used across all objects within the Model sub-package
model
schema
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
35/427
Chapter 1. Advanced design overview 2
Figure 1-12 ProtectedObject class diagram
TheProtectedObject, depicted in Figure 1-12, is the base interface for all dataobjects that are protected through the use of access control information (ACI).This access control information is stored using theAccessRightclass and itsaggregates. TheAccessRightobjects are used by the Authorization package todetermine whether users of the system are authorized to read or modify theassociated data objects. TheAuthorizationOwnerclass identifies the users ofthe system who are allowed to make changes to theAccessRightobjects,therefore, changing the authorization model for the associated data objects.
AttributeRight
isForAllAttributes()
setForAllAttributes()
getAttributes()
getOperations()
setOperations()
Permission
getAction()
setAction()
getAttributeRights()
getClassRights()
0..n
+attribute right
0..n
AccessRight
getName()
setName()
getTarget()
setTarget()
getPermissions()
getPrincipals()
getScope()
setScope()
getRoles()
0..n+permission 0..n
AuthorizationOwner
getOwnerDistinguishedName()
getOwnerCategory()
ProtectedObject
getAuthorizationOwners()
setAuthorizationOwners()
getAccessRights()
setAccessRights()
0..n
+access right
0..n
0..n+authorization owner 0..n
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
36/427
22 Identity Management Advanced Design for IBM Tivoli Identity Manager
Figure 1-13 DirectoryObject class diagram
TheDirectoryObjectEntity, shown in Figure 1-13, is the base class for all dataobjects that can be represented with a flexible attribute name/value pair retrievaand update approach. The interface provided easily allows the data storagerepresentation of these objects to be extended without affecting the softwareinterfaces. This class can be instantiated on its own if clients wish to retrieve daobjects in a general fashion, or more commonly, this class is inherited from mor
specialized semantically meaningful classes found in the Model sub-packages
The entity can have an optionalEntityLifecycleProfile. TheEntityLifecycleProfile holds all lifecycle characteristics that are defined at theentity level versus the ObjectProfile level. This class is used specifically for
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
37/427
Chapter 1. Advanced design overview 2
workflow-based policy enforcement. Only ServiceEntities (see below) haveEntityLifecycleProfiles in Identity Manager 4.6. TheDirectoryObjectis the basinterface for all Value Objects that are provided by entities that implement the
DirectoryObjectEntity interface. TheDirectoryObjectis a subclass ofDirectoryEntry, which holds the interface for a raw directory entry. TheDirectoryObjectextendsDirectoryEntry for the purposes of representing asemantic directory entry in the platform's data model. This requires the ability tomap semantic attributes of the platform to customer-supplied raw directoryattributes. The isLifecycleDefined() method is new in Identity Manager 4.6, sothe client can quickly determine if the entity has any lifecycle characteristics.EachDirectoryObjectEntity has an ObjectProfile associated with it whichdefines how the data object fits within the system's semantics needed forprovisioning business logic.
To provide support for a flexible data model where relationships can be addedand queried at run time by clients, the concept of relationships is introduced. Th
Relationship interface defines the base requirements for all discoverablerelationships in the data model. For example, simply querying a
DirectoryObjectEntity for a relationship called "parent" can discover therelationship implementation ContainedEntityParent. An instance of the
DirectoryObjectEntity class returns a ContainedEntityParent instance, but theclient can perform an evaluation of this relationship using the interface providedby theRelationship object. Specializations ofDirectoryObjectEntity might retura different implementation for the "parent" relationship, but to clients, theimplementation difference is transparent.
There is one supporting search class,DirectoryObjectSearch, to theDirectoryObjectEntity. TheDirectoryObjectSearch class provides the interfacefor retrievingDirectoryObjectEntities by either distinguished name or a filter in
the RFC 22561 format.
1 Fore details about RFC 2256, check http://rfc.net/rfc2256.html
http://rfc.net/rfc2256.htmlhttp://rfc.net/rfc2256.html7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
38/427
24 Identity Management Advanced Design for IBM Tivoli Identity Manager
Figure 1-14 ObjectProfile class diagram
ObjectProfileEntity
getDistinguishedName()
getProfile()
update()
remove()
ObjectProfileFactory
create()
ObjectProfileSearch
lookup()
getProfilesInCategory()
getAllServiceProfiles()
ObjectProfile
getDistinguishedName()
getTenantDN()
getName()
setName()getMappedAttribute()
getAttributeMap()
setAttributeMap()
getCategory()
setCategory()
getCustomClass()
setCustomClass()
getNameAttribute()
setNameAttribute()
getSearchAtt ribute()
setSearchAttribute()
isPasswordAttributeExist()
ProfileLocator
getProfileByName()
getProfileByCategory()
getProfileByClass()
create()
getAllProfiles()
getDefaultProfileNames()
registerProfile()
ObjectProfileCategory
getName()
setName() getCategories()
ObjectProfileOperat
ion
getName()
getType()
getDefinitionDN()
isStatic()
isSystem()
setName()
setType()
setDefinitionDN()
setStatic()
setSystem()
ManagableProfile
addOperation()
getOperation()
setOperation()
removeOperation()
getOperationNames()
setOperations()
getRules()
setRules()
0..n
+operation
0..n
Schedulable(from scheduling)
LifecycleRule
getFilter()
getName()
getOperation()getSchedule()
setFilter()
setName()
setOperation()
setSchedule()
0..n +rule0..n
+schedule
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
39/427
Chapter 1. Advanced design overview 2
The ObjectProfileEntity class, depicted in Figure 1-14 on page 24, providesmetadata information about how data store object classes represent semanticdata model entities within the provisioning context of the system. For example,the system allows a customer to use their own LDAP class, Employee, torepresent people within the system. A profile is set up that associates that claswith the Person entity and maps the appropriate attributes of the Employee clasto the semantic personal attributes, such as name, mail, and shared secret. ThObjectProfile class represents the Value Object for this ObjectProfileEntity. ThObjectProfile implements theManageableProfile interface, which defines thecommon properties of profiles that have operations. The ObjectProfileOperatiorepresents a lifecycle operation, which is a named business task implementedusing a workflow process design. TheLifecycleRule class represents a lifecyclrule, which is made up of a filter and an operation. The ObjectProfile and theObjectProfileCategory both implement this interface because they both canhave operations defined for them. An ObjectProfile is also defined by belonginto an ObjectProfileCategory.
The two supporting classes for ObjectProfileEntities are the
ObjectProfileSearch and ObjectProfileFactory classes. TheObjectProfileSearch provides an interface to retrieve an ObjectProfileEntity bydistinguished name or by category, since that name is unique within the scope oa single tenant within the system. The ObjectProfileFactory provides theinterface to create a new ObjectProfileEntity in the data store.
Due to the frequency at which clients need to query ObjectProfile information, caching strategy is used. TheProfileLocatorprovides fast access toObjectProfiles based on predefined queries. The cache of ObjectProfiles thattheProfileLocatoruses is refreshed on a customer-defined time interval.Changes made to the profiles are not loaded into the cache until that time
interval.
Figure 1-15 Schema class diagram
Although the Schema package, as described earlier, provides an interface forobtaining schema information about the data store, clients of the data modeloften require this schema information, but with the semantics of the system'sdata model intact. For example, customers can map existing classes in the datstore to an entity in the system's data model. The object profile holds the
ModelSchema
getClassNames()
getClassSchema()
getAttributeSchema()
getClassSuperiors()
SchemaAttribute(from schema)
SchemaClass(from schema)
0..n
0..n
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
40/427
26 Identity Management Advanced Design for IBM Tivoli Identity Manager
mapping information of the customer's class schema to the semantic schemainformation the system requires for its business logic. TheModelSchema classshown in Figure 1-15 on page 25, is introduced here to execute these mappingrules before providing the schema information to the client so that the informatiois consistent with the system's business logic. TheModelSchema class alsofilters out attributes from classes that are used only internally by the system.
Domain
TheDomain package is a sub-package of the Model package that holds thesystem's subject data specific to the customer environment, such as people,roles, services, and the organizational structure this data is placed in.
The organizational structure of the items within the data model is represented ba handful of classes as shown in Figure 1-16.
Figure 1-16 OrganizationalContainer class diagram
First, the OrganizationalContainerEntityclass provides a base interface for allcontainers in the organizational structure. This class provides the interface fortraversing the tree through parent relationships, as well as an interface for
querying for dependent entities. The specializations of this class are theAdminDomainEntity,BusinesssUnitEntity (represents locations andorganizational units),BusinessPartnerOrgEntity, and OrganizationEntity.
OrganizationalContainer
DirectoryObjectEntity
(from model)DirectoryObject
(from model)
OrganizationalContainerSearch
lookup()
searchByFilter()
ContainedEntityParent
Relationship
(from model)
OrganizationalContainerEntity
hasDependencies()
getParentContainer()
getLogicalNameContext()
0..1 +parent/parent container0..10..n
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
41/427
Chapter 1. Advanced design overview 2
TheDirectorySystemEntity class, shown in Figure 1-17, represents the root of adomain entities in the system or the root tenant of all domain entities if thesystem is deployed as multi-tenant.
Figure 1-17 DirectorySystem class diagram
This entity holds the system-wide, or tenant-wide, properties. The
DirectorySystem class is the value object class forDirectorySystemEntity. TheisPasswordResetRequired() andsetPasswordResetRequired() methods replacethe isLostPwdByMail() andsetLostPwdByMail() methods in Identity Manager4.6 for the challenge/response login flow. The Challenge class is new in IdentitManager 4.6 so that a locale can be associated with the system-defined
DirectorySystemEntity
getChallenges()
setChallenges()
getPOConfiguration()
setPOConfiguration()
getWorkflowConfiguration()
setWorkflowConfiguration()
DirectoryObject
(frommodel)
DirectorySystemSearch
lookup()
searchById()
lookupDefault()
getAll()
DirectorySystem
isPwdEditAllowed()
setPwdEditAllowed()
getLogonCount()
setLogonCount()
getBucketCount()
isActive()
setPasswordRetrievalExpirationPeriod()
getPasswordRetrievalExpirationPeriod()
getChallengeMode()
setChallengeMode()getChallengeDefinitionMode()
setChallengeDefinitionMode()
getNumberOfRequiredChallenges()
setNumberOfRequiredChallenges()
getNumberOfRandomChallenges()
setNumberOfRandomChallenges()
isResponseHashedEnabled()
setResponseHashedEnabled()
isChallengeEnabled()
setChallengeEnabled()
getChallengResponseEmail()
setChallengeResponseEmail()
getPasswordExpirationPeriod()
setPasswordExpirationlPeriod()getResponseLastChanged()
getSuspendMessage()
setSuspendMessage()
isPasswordSynchAllowed()
setPasswordSynchAllowed()
updateResponseLastChanged()
isPasswordResetRequired()
setPasswordResetRequired()
OrganizationalContainerEntity
Challenge
getQuestion()
setQuestion()
getLocale()
setLocale()
POConfiguration
getPODeliveryInterval()
setPODeliveryInterval()
isPOEnabled()
setPOEnabled()
getPONotif icationTemplate()
setPONotif icationTemplate()NotificationTemplate
getSubject()
setSubject()
getTextBody()
setTextBody()
getHTMLBody()
setHTMLBody()
+template
WorkflowConfiguration
getReminderInterval()
setReminderInterval()
getReminderNotificationTemplate()
setReminderNotificationTemplate()
getActivityNotificationTemplate()
setActivityNotif icationTemplate()
+template
DirectoryEntry
(frommodel) 0..n
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
42/427
28 Identity Management Advanced Design for IBM Tivoli Identity Manager
challenges. TheNotificationTemplate class is new in Identity Manager 4.6 todescribe the template used for messages delivered to users for the NotificationPost Office, To do Item Reminders, and Manual Activity Notificationcustomization. ThePOConfiguration class is a value object holding post officeconfiguration information. The WorkflowConfiguration class is a value objectholding global workflow configuration information. TheDirectorySystemSearchclass provides a search capability. The only two search options provided are bydistinguished name or by a unique relative name, the id.
TheBusinessUnitEntity, depicted in Figure 1-18, represents both aLocation anan OrganizationalUnit in the organization hierarchy. The entity abstractsorganizational containers with no other distinction other than they all supportbeing assigned a supervisor.
Figure 1-18 BusinessUnit class diagram
OrganizationalContainerEntity
Supervisor
Relationship
(from model)
PersonEntity
BusinessUnitEntity
getSupervisor()
setSupervisor()
getOrganization()
OrganizationEntity
BusinessUnit
OrganizationalContainer
0..1
+supervisor
0..1
+organization1
BusinessUnitFactory
create()
BusinessUnitSearch
lookup()
searchByFilter()
0..n
1
Location
OrganizationalUnit
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
43/427
Chapter 1. Advanced design overview 2
Figure 1-19 AdminDomain class diagram
TheAdminDomainEntity, shown in Figure 1-19, represents an administrativedomain container. It distinguishes itself by its ability to associate a set ofadministrators with the organizational container.
OrganizationalContainerEntityAdminDomainAdministrator
OrganizationEntity
PersonEntity
AdminDomainEntity
getAdministrators()
setAdministrators()
addAdministrator()
removeAdministrator()
getOrganization()
Relationship
(from model)
AdminDomain
addAdministrator()
removeAdministrator()
setAdministrators()
OrganizationalContainer +organization1
0..1+administrator 0..1
AdminDomainSearch
lookup()
searchByFilter()
AdminDomainFactory
create()
0..n
1
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
44/427
30 Identity Management Advanced Design for IBM Tivoli Identity Manager
Figure 1-20 PartnerOrganization class diagram
TheBusinessPartnerOrgEntity in Figure 1-20 represents a business partnerorganization that was designed for holding, but not limited to,
BusinessPartnerEntities. The only real distinction between this container andother container types is the ability to associate a sponsor with the organizationcontainer.
OrganizationalContainerEntity
OrganizationEntity
Relationship
(from model)
BusinessPartnerOrg
OrganizationalContainer
BusinessPartnerOrgEntity
getSponsor()
setSponsor()
getOrganization()
1 +organization1
PersonEntity
0..1 +sponsor0..1
BusinessPartnerSponsor
BusinessPartnerOrgFactory
create()
BusinessPartnerOrgSearch
lookup()
searchByFilter()
0..n
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
45/427
Chapter 1. Advanced design overview 3
Figure 1-21 Organization class diagram
The OrganizationEntity, as shown in Figure 1-21, is a bit different in design to iorganizational container predecessors, because it cannot be nested or have anparents itself. Other than that, it is quite similar to other organizational container
Organization
getStatus()suspend()
restore()
OrganizationFactory
create()
OrganizationSearch
lookup()
searchByFilter()
OrganizationalContainer OrganizationalContainerEntity
OrganizationParent
Relationship
(from model)
DirectorySystem
OrganizationEntity
0..n
+parent
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
46/427
32 Identity Management Advanced Design for IBM Tivoli Identity Manager
Figure 1-22 Person class diagram
ThePersonEntity in Figure 1-22 represents any identity managed by the systein the data model. In general, these identities are truly human in nature, but cansometimes represent more, such as a system or job function (administrator). Th
PersonEntity provides an interface for all identity relationships needed within thsystem. The most noteworthy are an identity's relationship to its accounts and it
affiliation with roles. ThePerson class is the value object holding attributeinformation for a person. ThegetCreationDate(),setCreationDate(),
getLastStatusChangeDate(), andsetLastStatusChangeDate() methods are usedto support Lifecycle Event Information in the schema. ThegetSynchPassword()andsetSynchPassword() methods are used to synchronize passwords. Two
Person
getAliases()getMail()
setMail()
getRoles()
addRole()
removeRole()
setRoles()
getCustomAttribute()
getImmediateSupervisor()
setImmediateSupervisor()
getSharedSecret()
setSharedSecret()
getStatus()
setStatus()
suspend()
restore()
getLocale()
setLocale()
getCreationDate()
setCreationDate()
getLastStatusChangeDate()
setLastStatusChangeDate()
getSynchPassword()
setSynchPassword()
PersonFactory
create()
DirectoryObject(f rom model)
DirectoryObjectEntity
(f rom model)
PersonSearch
lookup()
searchByAlias()searchByFilter()
searchByRole()
PersonSupervisorRelationship
(f rom model)
RoleEntity
OrganizationEntity
BusinessPartnerEntity
getSponsor()
setSponsor()
PersonEntity
getRoles()
setRoles()
addRole()
removeRole()
getSupervisor()
setImmediateSupervisor()
move()getOrganization()
isMemberOfRole()
getImmediateSupervisor()
0..1
+supervisor
0..1
0..n
0..n +role
0..n+member
0..n
1+organization
10..n
0..1
+sponsor
0..1
0..1
+immediate supervisor
0..1
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
47/427
Chapter 1. Advanced design overview 3
supporting classes are provided,PersonFactory for creation of people in the datstore, andPersonSearch for different searching capabilities.
TheBusinessPartnerEntity class is a specialization of thePersonEntity torepresent business partners in the data model. The only real difference for abusiness partner is the need to identify a sponsor for the individual.
Figure 1-23 Service class diagram
TheHostedServiceEntity class, shown in Figure 1-23, is a specialization of theServiceEntity to represent a service hosted by another organization. This hosteservice lies in the customer organization and is a virtual copy, or proxy, to the
DirectoryObject(from m odel)
HostedServiceEntity
getHostedServiceProfile()
getConcreteService()
HostedServiceFactory
create()
ObjectProfile(from m odel)
DirectoryObjectEntity(from m odel)
ServiceFactory
create()
ServiceSearch
lookup()
searchByProfile()
searchByFilter()
ServiceOwner
Relationship(from m odel)
HostedService
getHostDN()
getHostProfileName()
Service
isCheckingPolicy()setPolicyChecking()
getNonComplianceAction()
setNonComplianceAction()
getPrerequisiteDNs()
getOwnerDN()
setOwnerDN()
getServiceProfileName()
isEnrole()
AccountTable
ServiceProfile
getAccountClass()
setAccountClass()
getAccountProfileName()
setAccountProfileName()
PersonEntity
OrganizationEntity
ServiceEntity
getPrerequisites()
setPrerequisites()
getOwner()
setOwner()
hasHostedService()
removeHostedServices()
getOrganization()
getAccountTable()
1 +profile1
0..1
+owner
0..1
1
+organization
1
0..n
0..1
+prerequisite
0..1
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
48/427
34 Identity Management Advanced Design for IBM Tivoli Identity Manager
concrete service within the owner organization. For the most part, this entitylooks the same as concrete services but provides an interface to obtain profileinformation about itself and the proxied service. The profile information for all
HostedServiceEntities is always the same, a hosted profile. TheHostedServiceclass represents the value object andHostedServiceFactory is the factory.
Figure 1-24 ServiceModel class diagram
The ServiceModelclass in Figure 1-24, which can also be obtained from theServiceEntity, provides the interface for the supporting provisioning model of aservice, such as groups and other contextual information. This interface allows
the client to add and remove objects from the directory that are linked to thespecified service.
ServiceModel
addSupportingData()
removeAllSupportingData()
getByFilter()
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242
49/427
Chapter 1. Advanced design overview 3
Figure 1-25 Account class diagram
TheAccountEntity class, depicted in Figure 1-25, represents an account, oridentity, that is provisioned on a service. TheAccountEntity provides theinterface for account relationships, such as ownership and business logic-likesuspensions. An account compliance issues list has been added that consists omany possible ComplianceIssue objects to support workflow-based policy
enforcement.
TheAccountclass is the value object holding attribute information for anaccount. ThegetCreationDate(),setCreationDate(),
getLastStatusChangeDate(), andsetLastStatusChangeDate() methods support
Account
addHistoricalPassword()
getHistoricalPasswords()
isSuspended()
setHistoricalPasswords()
getLastAccessedDate()
setLastAccessedDate()
setPassword()
getPassword()
getUserId()
setUserId()
getStatus()
setStatus()
suspend()
restore()getCompliance()
setCompliance()
getCreationDate()
setCreationDate()
getDatePasswordLastChanged()
setDatePasswordLastChanged()
getLastStatusChangeDate()
setLastStatusChangeDate()
DirectoryObject(from model)
AccountFactory
create()AccountSearch
lookup()
searchByFilter()searchByOwner()
searchByService()
searchByUserID()
DirectoryObjectEntity(from model)
AccountOwnerRelationship(from model)
AccountParentRelationship(from model)
AccountService
ServiceEntity
PersonEntity
AccountEntity
adopt()
getOwner()
getService()
orphan()
isOrphan()
getComplianceIssues()
setComplianceIssues()
0..n+account 0..n
+host
0..n
0..n0..1
+account 0..n
+owner
0..1
+parent
ComplianceIssue
getCreationDate()
getOperation()
setCreationDate()
setOperation()
7/31/2019 Identity Management Advanced Design for IBM Tivoli Identity