Identity Management Advanced Design for IBM Tivoli Identity Manager Sg247242

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:

    [email protected]

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

    Mail

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