Integrated identity management using ibm tivoli security solutions sg246054

  • 987 views
Uploaded on

 

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
987
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Front coverIntegratedIdentity Management mentusing IBM Tivoli Security SolutionsLatest technology in access control andidentity management solutionsHolistically covers security ine-business projectsBest practices andexperiences Axel Bücker Jaime Cordoba Palacios Michael Grimwade Loïc Guézo Mari Heiser Samantha Letts Sridhar Muppidiibm.com/redbooks
  • 2. International Technical Support OrganizationIntegrated Identity Managementusing IBM Tivoli Security SolutionsMay 2004 SG24-6054-00
  • 3. Note: Before using this information and the product it supports, read the information in “Notices” on page vii.First Edition (May 2004)This edition applies to Tivoli Access Manager for e-business 5.1, Tivoli Identity Manager 4.5,Tivoli Privacy Manager 1.2, Tivoli Risk Manager 4.2, Tivoli Directory Server 5.2, and TivoliDirectory Integrator 5.2.© Copyright International Business Machines Corporation 2004. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corp.
  • 4. Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiPart 1. Why Integrated Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter 1. An introduction to a new reference architecture . . . . . . . . . . . . 3 1.1 Everything is on demand today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Security management methods and practices . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.4 Areas of security implied in the CIA Triad . . . . . . . . . . . . . . . . . . . . . . 7 1.3 Business drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4 Issues affecting identity integration solutions . . . . . . . . . . . . . . . . . . . . . . . 9 1.5 Integrated identity in the enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.1 Access control management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.2 Identity and credential management . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.5.3 Audit management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.5.4 Directory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5.5 Privacy management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Chapter 2. What Bank International. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1 Company profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.1 Geographic distribution of WBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.2 Organization of WBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.3 HR and personnel procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Current IT architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.1 Overview of the WBI network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2 Recently implemented e-business initiative . . . . . . . . . . . . . . . . . . . 25 2.2.3 Security infrastructure deployed for the e-business initiative . . . . . . 25 2.2.4 Secured e-business initiative architecture. . . . . . . . . . . . . . . . . . . . . 27 2.2.5 Identity management and emerging problems . . . . . . . . . . . . . . . . . 28 2.3 Corporate business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . . 30© Copyright IBM Corp. 2004. All rights reserved. iii
  • 5. 2.4 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.4.1 Business requirements for phase 1. . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.4.2 Business requirements for phase 2. . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.5.1 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.5.2 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.6 Risk assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.6.1 WBI risk assessment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.7 Security design objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.7.1 Functional design objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.7.2 Non-functional design objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.8 Architectural decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Chapter 3. Applying the reference architecture . . . . . . . . . . . . . . . . . . . . . 53 3.1 Solution design and delivery approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.1.1 Implementation life-cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.1.2 Requirements analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.1.3 Incremental delivery strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.2 WBI solution design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.2.1 Solution overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 3.2.2 Component model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.2.3 The operational architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.2.4 The security architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.2.5 Implementation phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Chapter 4. Implementing the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.1 Development environment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.1.1 Component model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 4.1.2 Operational model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 4.1.3 Security architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.2 Technical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.2.1 Automatic provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 4.2.2 Application subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 4.2.3 Self care . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 4.2.4 Self registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 4.3 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Part 2. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Appendix A. ISO 17799 compliance mapping . . . . . . . . . . . . . . . . . . . . . 159 Corporate policy and standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Standards, practices, and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Practical example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 External standards and certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163iv Integrated Identity Management using IBM Tivoli Security Solutions
  • 6. Industry specific requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Product or solution certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Nationally and internationally recognized standards . . . . . . . . . . . . . . . . . 165 Legal requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165ISO 17799 and integrated identity management . . . . . . . . . . . . . . . . . . . . . . 166 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Contents v
  • 7. vi Integrated Identity Management using IBM Tivoli Security Solutions
  • 8. NoticesThis 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. Consultyour local IBM representative for information on the products and services currently available in your area.Any reference to an IBM product, program, or service is not intended to state or imply that only that 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 usersresponsibility 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 disclaimerof 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 madeto 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 atany time without notice.Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner 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 withoutincurring any obligation to you.Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements 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 products.All of these names are fictitious and any similarity to the names and addresses used by an actual businessenterprise 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 inany form without payment to IBM, for the purposes of developing, using, marketing or distributing applicationprograms 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 copy,modify, and distribute these sample programs in any form without payment to IBM for the purposes ofdeveloping, using, marketing, or distributing application programs conforming to IBMs applicationprogramming interfaces.© Copyright IBM Corp. 2004. All rights reserved. vii
  • 9. TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States,other countries, or both: AIX® IBM® Redbooks™ CICS® iNotes™ Tivoli Enterprise Console® DB2 Universal Database™ Lotus Notes® Tivoli Enterprise™ DB2® Lotus® Tivoli® Domino® MQSeries® TME® e-business on demand™ Notes® WebSphere® Eserver® pSeries® z/OS® Eserver® RACF® ibm.com® Redbooks (logo) ™The following terms are trademarks of other companies:Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in theUnited States, other countries, or both.Java and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the United States, other countries, or both.Other company, product, and service names may be trademarks or service marks of others.viii Integrated Identity Management using IBM Tivoli Security Solutions
  • 10. Preface This IBM Redbook provides a solution-oriented overview of using Tivoli® security products to provide an implementation for integrated identity management based on real-life customer experience. When defining functional requirements for e-business related projects, you have to take into consideration a serious amount of security related tasks and disciplines. These disciplines are authentication and credential acquisition, use of directory infrastructures, session management, multiple tiers of single sign-on, authorization, administration, users and policy, accountability, and availability. Together they stand for the integrated identity management approach, an approach that should be regarded a holistic way of tying security requirements into your projects. First we introduce a new reference architecture for building an integrated identity management solution in Chapter 1, “An introduction to a new reference architecture” on page 3. Then we use a typical customer environment to build a real-life example where we can methodically develop a solution design and approach for our new integrated identity management reference architecture.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.© Copyright IBM Corp. 2004. All rights reserved. ix
  • 11. Figure 1 From left, Axel, Sridhar, Samantha, Jaime, Loïc, and Michael Axel Bücker is a Certified Consulting Software I/T Specialist at the International Technical Support Organization, Austin Center. He writes extensively and teaches IBM classes worldwide on areas of Software Security Architecture and Network Computing Technologies. He holds a degree in computer science from the University of Bremen, Germany. He has 17 years of experience in a variety of areas related to Workstation and Systems Management, Network Computing, and e-business solutions. Before joining the ITSO in March 2000, Axel was working for IBM in Germany as a Senior IT Specialist in Software Security Architecture. Jaime Cordoba Palacios is a Certified Consulting I/T Specialist with Grupo PISSA (IBM Business Partner), based in Mexico, D.F. He holds a degree in electronics engineering, and a degree in Information Security from Instituto Tecnologico y de Estudios Superiores de Monterrey, Mexico. He has five years of experience in a variety of areas related to Systems Management, Network Computing, and Security Solutions. His areas of expertise include IBM Tivoli Access Manager, IBM Tivoli Risk Manager, IBM Tivoli Identity Manager, LDAP, e-business infrastructures, and networking. He currently is involved in security architecture design and implementation and general security consultingx Integrated Identity Management using IBM Tivoli Security Solutions
  • 12. engagements. He has worked on various customer projects performing networkand security assessments and architecting secure e-business infrastructures.Michael Grimwade is a Senior IT Architect with IBM Global Services inAustralia. He has eight years of experience in delivering custom e-businesssolutions to large organizations. He holds a degree in Information Technologyfrom the University of Queensland, Australia and has worked at IBM for sixyears. His areas of expertise include e-business applications, infrastructure andsecurity, software architecture and design, and solution delivery methodologies.Loïc Guezo is an I/T Security Architect in IBM Global Services. He is primarilyinvolved in security architecture design, implementation, and security consultingengagements. He has three years of experience within the Security and Privacypractice in France, and focuses on Tivoli security products. Before joining IBM hespent nine years in different positions in banking, industrial, and health careenvironments, leading IT projects, building, and managing infrastructures. Loïcholds a degree in Computer Science from Paris XIII University and a Mastersdegree in OSS - Security from Ecole Centrale Paris in France.Mari Heiser is a senior I/T Architect with IBM in the United States, specializing insecurity and network architectures. She has 19 years experience in the I/Tindustry related to networking, Web infrastructure and enterprise securitysolutions. She holds a degree in Education from The Cleveland State Universityas well as a degree in Electrical Engineering. Her areas of expertise includeTivoli Access Manager, Tivoli Identity Manager, LDAP, e-business infrastructuresand networking. During the last few years, she has worked on various customerprojects performing network and security assessments and architecting secureeBusiness infrastructures. She has written and edited several books relating tothe I/T industry in general and was a contributing author to the IBM Redbook,Enterprise Security Architecture using IBM Tivoli.Samantha Letts is an IT Specialist with IBM Australia. She holds a degree inCommerce, majoring in Business Systems and Management, from the Universityof Wollongong, Australia. She has eight years of experience with IBM Australiasoftware defect support. She has spent the last two years working on Tivoliproducts in the security area.Sridhar Muppidi is a Senior Security Architect working in the Tivoli division ofIBM Software Group. His area of expertise is providing secure and manageablee-commerce solutions to enterprises and their edge systems, which includesarchitecting solutions for customers, working on new product developments, andstandards work. Prior to this, Sridhar was a Security and Directory Architect inIBMs Global Services group. Sridhar obtained his M.S. and Ph.D. from TexasA&M University in 1992 and 1996 respectively. Preface xi
  • 13. Thanks to the following people for their contributions to this project: Yvonne Lyon, editor International Technical Support Organization, San Jose Center Ted Ralston, Chris Ehrsam, Becky McKane, Scott Simmons, Robert Larson, Weibo Yuan, Clyde Zoch, Eric Schultz, Paul Ashley, Rick McCarty, Bill Powell, IBM US Paul OMahoney, Andrew Jupp IBM UKBecome a published author Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. Youll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, youll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.htmlComments welcome Your comments are important to us! We want our Redbooks™ to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an Internet note to: redbook@us.ibm.com Mail your comments to: IBM® Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493xii Integrated Identity Management using IBM Tivoli Security Solutions
  • 14. Part 1Part 1 Why Integrated Identity Management In this part we provide an introduction as to why an integrated identity management approach for applying security within IT environments is the right thing to do. Enterprise security cannot be tackled by implementing bits and pieces in segregated portions of the infrastructure; it has to be built on a solid foundation of policies and standards. It should provide a seamless security infrastructure layer that other components, such as authentication proxies and applications, for example, can leverage.© Copyright IBM Corp. 2004. All rights reserved. 1
  • 15. 2 Integrated Identity Management using IBM Tivoli Security Solutions
  • 16. 1 Chapter 1. An introduction to a new reference architecture In the new territory of the on demand Internet economy, strategic partnerships are an important way to reduce development and marketing costs, increase sales figures, and seize new business opportunities. An enterprise whose business processes — integrated end-to-end across the company and with key partners, suppliers, and customers — can respond with flexibility and speed to any customer demand, market opportunity, or threat has the clear competitive advantage. By combining a challenging business environment with the efficiency of Web-based collaboration and strong security to protect proprietary information on other network resources, the enterprise is poised to respond to the competitive challenges facing them in today’s marketplace. However, with that, companies must be able to trust the electronic identities that access their Web sites from external locations. Identity management is a comprehensive, process oriented, and policy driven security approach that helps organizations consolidate identity data and automate the deployment across the enterprise. In this chapter we discuss how integrated identity management enables organizations to share trusted identities through strong authentication and single sign-on (SSO) functionality. We also outline methods of identifying the key components of an integrated identity management architecture.© Copyright IBM Corp. 2004 3
  • 17. 1.1 Everything is on demand today When we discuss on demand, we are talking about a new era. Today, people are used to getting their money, airline tickets, and a host of other things immediately. On demand is the logical extension of this immediacy across an enterprise — linking customers as well as suppliers. An enterprise whose business processes are integrated end to end across the company and with key partners, suppliers, and customers, can respond with flexibility and speed to the customer demand, market opportunity, or threat. On demand is not a marketing idea looking for an opportunity. On demand is a response to the competitive challenges facing business today. Markets are tightening, and the opportunity to reach new markets and increase profits within current budgets sounds like a contradiction. On demand comes alive in an industry context bringing the innovation needed to capture new value and generate the productivity gains at a lower cost. Things are changing — we have accelerating advances in technology, and the business landscape is changing as well. Volatility is increasing across all areas — from economies and stock markets to pricing pressures and competitive threats. There is a much deeper integration of IT with the business today. IT is no longer a back-room operation. Companies have to be able to manage in the face of all the pressure — that means responding faster and more accurately, while bringing down the cost of business by becoming more productive. Figure 1-1 shows the two strategic imperatives that exist today. The first is business innovation, and the second is improved productivity and deployment. The overriding factors to these requirements are increased security and resiliency. Optimize the value net 1 Innovate the Increase Security & Resiliency Increase business flexibility business to differentiate Extract greater value from data and capture new value Improve the customer experience Drive business innovation Optimize today’s IT investments 2 Make better use of Improve employee productivity resources to be more Streamline/simplify processes productive Figure 1-1 Innovation and productivity are linked to increased security and resiliency4 Integrated Identity Management using IBM Tivoli Security Solutions
  • 18. Core attributes of e-business on demand™ include: responsiveness, variability, focus, and resiliency. Responsiveness is sensing and responding in real-time based on an integrated view of customers, employees, suppliers, partners, and competitors. Variability is utilizing variable cost structures to do business at high levels of productivity, cost control, capital efficiency, and financial predictability. Focus refers to concentrating on core, differentiating tasks, and being capable of quickly evolving them, as well as leveraging competency of strategic partners to manage selected tasks. And, e-business on demand requires resiliency, meaning that enterprises must employ a flexible operating environment that can manage changes and threats with consistent availability, security, and privacy. Operating in an on-demand world requires that companies protect information assets, confidentiality, and data integrity. It also means that steps are taken to ensure that the IT infrastructure is reliable and available to support business operations — integrating existing business processes within the company, and capturing, analyzing, and utilizing information effectively to support business decision-making. Leveraging the infrastructure means integrating existing business applications as well, allowing for maximum utilization of existing computing resources.1.2 Security management methods and practices The Internet’s eruption into everyday life as a universal form of communication happened because of the easy and efficient sharing of information between users worldwide. Users, for the most part, were unidentified — hidden, if you will, in cyberspace. But as more information got pushed to the Web, it became increasingly important for the publishers of this information to know who was accessing it and to apply security methods to it. Today, companies are allowing employees, suppliers, prospective and existing customers, and business partners to access corporate information through the Internet. As more and more enterprises utilize the ease of the Internet to provide more services to their employees and partners, as well as customers, the need to supply a secure and effective e-business environment with trusted user credentials is essential. Security management methods and practices are the elements necessary for any solution deployment — whether it entails a network with no Internet access or something specific for the Internet. The basic principles that affect all security decisions are confidentiality, integrity, and availability — the CIA Triad — which is the basic roadmap containing the goals and objectives that both policies and systems must blend to achieve a secure solution. These three principles, which we discuss next, are often considered the most important within the realm of security, and no less so in an Internet enabled world. Chapter 1. An introduction to a new reference architecture 5
  • 19. 1.2.1 Confidentiality What is confidentiality? Ensuring that information is accessible only to those authorized to have access. The fundamental goal of any information security program is to assess what is being protected, as well as the why and how of controlling access. Determining confidentiality is not simply a matter of deciding whether information is secret or not. Rather, it is the act of determining the level of access in terms of how and where the data can be accessed. For information to be useful to the organization, it can be classified by a degree of confidentiality. While this book does not provide not an in-depth look into the many layers of security, it is helpful to mention that the concept of confidentiality entails other aspects, such as information security. These include sensitivity, secrecy, and privacy. However, confidentiality and integrity are interwoven: Without integrity, confidentiality cannot be maintained.1.2.2 Integrity What is integrity? Safeguarding the accuracy and completeness of information and processing methods. Integrity is the guarantee that the information has not been modified by any unauthorized mechanism. With data being the primary information asset, integrity provides the assurance that the data is accurate and reliable. Without integrity, the costs associated with collecting and maintaining the data cannot be justified. As stated above, confidentiality and integrity are dependent on each other. Other aspects of integrity include accuracy, authenticity, accountability, nonrepudiation, and validity.1.2.3 Availability What is availability? Ensuring that authorized users have access to information and associated assets when required.6 Integrated Identity Management using IBM Tivoli Security Solutions
  • 20. The principle of availability says that information is obtainable and accessible, but it does not say that acquiring information is immediate and/or instantaneous. What it does say is that authorized users can be granted timely and uninterrupted access to information. Availability is dependent on both confidentiality and integrity. Without the “C” and “I” there is no “A”. Other areas of availability include accessibility and timeliness.1.2.4 Areas of security implied in the CIA Triad As you have seen, the CIA Triad covers a broad spectrum. Some of the other areas implied and of concern are listed in the following sections. Privacy Privacy considers what information can be shared with others (confidentiality), how that information can be accessed safely (integrity), and how it can be accessed (availability). When discussing privacy in an IT world, it can quickly become a balancing act between individual rights and the rights of the organization. Privacy is an issue for everyone and must be addressed within the policies, procedures, and standards that are adopted. If not mandated to do so by law or regulation, organizations should review the privacy needs of their own information assets or their clients respectively. Identification When you examine the identity process, it actually has three distinct steps. As the first step, identification assigns every person or asset a distinct name, for example, user name, account name, application name, and so on. Authentication The second step is where we verify that the identity claimed is real and valid. The most common form of authentication is a password that is checked against a database and deemed correct or incorrect. Without identification, authentication is useless. Authentication should be mutually available for all involved and identified assets. Authorization This is the third step in the identification process. Once a user or process has been identified and authenticated, their ability to access assets is authorized. This is determined by the rights and privileges assigned to the authenticated identity. Please note that being identified and authenticated doesn’t automatically grant authorization. Chapter 1. An introduction to a new reference architecture 7
  • 21. Auditing Auditing is the process of monitoring and logging activities that occur within the IT system. It is not limited to authenticated and authorized users or processes, but also covers unauthorized or abnormal activities on a system. Auditing per definition is a passive activity, but on-demand auditing within an IT system requires intelligent event correlation and automated response behavior. Accountability Accountability is the result achieved by the actual auditing of a system. Accountability includes information about the access, such as date, time, network address, and other information that could further identify the condition or event. Nonrepudiation Nonrepudiation is the ability to ensure that the originator of a communication or message is the true sender by guaranteeing authenticity of their digital signature. This prevents a user from claiming not to have sent a message or performed an action that caused an event.1.3 Business drivers The highly competitive nature of today’s marketplace has caused businesses to look in many new and challenging directions to compete effectively. Doing more with less has become the mantra of every level of management. The edicts of open new markets and find new opportunities have made utilizing the vast infrastructure of the Internet a sound fiscal decision. But this sound decision also brings new challenges. As IT is challenged to do more with fewer resources, managing identities and their access to resources throughout the enterprise is even more difficult. Typical IT environments have many local administrators using manual processes to implement user changes across multiple systems and applications. As identity administration grows more costly, it can inhibit the development and deployment of new business initiatives. An integrated identity management solution can help you get users, systems, and applications online and productive quickly, as well as maintaining dynamic compliance to increase the resiliency and security of the IT environment, while helping to reduce costs and maximize return on investment. There are four key areas of an identity management solution: Identity lifecycle management (user self-care, enrollment, and provisioning) Identity control (access and privacy control, single sign-on, and auditing)8 Integrated Identity Management using IBM Tivoli Security Solutions
  • 22. Identity federation (sharing user authentication and attribute information between trusted applications) Identity foundation (directory, directory integration, and workflow) Identity management is a super-set of older user provisioning systems that allows for the management of identity and credential information for customers, partners, suppliers, automated processes, corporate users, and others. As the world of e-business gains global acceptance, the traditional processes of corporate user administration are no longer able to cope with the demands of increased scale and scope expected from them. As organizations come to depend upon their IT assets to a greater extent than previously, these assets attract the attention of accounting and reporting standards. IT data and system assets will increasingly become balance sheet line items, and therefore be subject to different audit and compliance rules. Organizations must be able to demonstrate due care, due diligence, improved security, and compliance with other financial rules. We should realize that any entity using the IT systems run by an organization must be included in the scope of identity management if we are to have any chance of achieving these goals.1.4 Issues affecting identity integration solutions Undertaking an identity integration project reveals situations that aren’t always readily apparent. Two major areas of interest when putting together an integrated identity management approach include: enabling user access (session management, authorization, authentication, and so on) and user lifecycle management (user administration, provisioning, and so on). These two areas stand at the forefront, and each area, again, has many facets of its own. We now touch upon these briefly. User access management is the application of security policies and procedures across an enterprise. Each requester (users, business partners, administrators, and so on) attempting to access a resource should provide proof of its identity. In turn, the security policy determines whether that client is permitted to perform an operation on a requested resource. In security systems, authorization is distinct from authentication. Authorization determines whether an authenticated client has the right to perform an operation on a specific resource in a secure domain. User identity management establishes and manages the identity of the user throughout its lifecycle. This begins with the initial creation of the user account, modifications to the account while it is active, and subsequent removal or disabling of the account. Integrating these activities facilitates the process for access approval, user provisioning, identity management, and subsequent reporting/auditing requirements or procedures. Chapter 1. An introduction to a new reference architecture 9
  • 23. By taking a life cycle approach to the management of the identity and specific attention to access control from the beginning of the process, an integrated identity management solution must have the ability to integrate with pre-existing information sources within the enterprise, such as directories. This allows for leveraging the existing information in data directories as well as integrating with other information sources already available. Integration is the key to effectively managing an individual identity and access. This holistic lifecycle approach helps to minimize the risk to the enterprise because it is ordered rather than fragmented. Figure 1-2 illustrates the approach. Policy Users Other - Provisioning Applications - Password - ID - Workflow (Int. and Ext) - Service Selection - Roles Access - Organization - ACI Management Users Provisioning Authentication / Password Policy LDAP Business Secure Self Help, Help Desk, Del. Admin App. - IM LDAP or Partners Enforcement Proxy API Identity Provisioning Gateway Server Directory management Self Server - AM API Registration Administrators User, Group lookup JAAS, JACC, WIM Provisinoing Applications Privacy Privacy Privacy Enforcement Management Web Trust - Portal Server mangement - App. Server - Content Server Message security, Security Enforcement Cred. Maping - Authentication Meta directory - Cred. Acquisition Secure Data Access - Authorization - Single Sign-On - Policy Enforcement Authoritative - Auditing Managed Targets HR Data Database data Managed Targets Identity management related components Application components Infrastructure componentsFigure 1-2 Integrated identity management reference architecture10 Integrated Identity Management using IBM Tivoli Security Solutions
  • 24. 1.5 Integrated identity in the enterprise There is often confusion regarding an integrated identity management solution. As stated before, identity management is an all-inclusive process and policy oriented security approach. A truly comprehensive solution requires integration of several important technologies. Once a user has been identified (password), they must be authenticated (their identity proven) and accountability is established. For authorization to occur, permissions and/or roles can be implemented to allow access to resources.1.5.1 Access control management Access control management generally evolves around authentication and authorization mechanisms. These technologies help warrant that every user has secure and convenient access to the resources they need (and only the resources they need) to perform their work or transactions. In order to be most effective, authentication mechanisms should be placed as close to the edge of the enterprise network as possible. This allows for the authentication to take place before any user can gain access to any resources located within the enterprise production perimeter. The authentication service has to provide different options of how to verify the authenticity of the presented secret based on userid and password, X.509 certificate, SecureID token, biometrics, or other means. These options again can vary depending on the requested resource’s asset value, with stronger mechanisms for high value assets. This flexibility should be provided within one security solution, and the management of this security solution needs to support both centralized and distributed security administration groups, while maintenance of the Web applications can be done by other individual groups applying different rules and roles. Once a requester has been successfully authenticated, a set of related credentials should be compiled and held available for the remainder of the online session (within certain time-out parameters). Proper session management is responsible for the transport and availability of the requester’s credential information between different tiers in the IT environment, for example, proxy, application, data, audit, and so on. When utilizing the security technologies of access management, the overall ease and convenience to the user is expanded by implementing single sign-on (SSO), which enables authorized users to access multiple protected resources across domains, while authenticating only once. Once the authentication process is completed with user credentials and session management context created, the authorization service gets involved. Chapter 1. An introduction to a new reference architecture 11
  • 25. Rule based authorization grants or denies access based on a user’s profile in which access decisions are made in real time by policy rules. These can either replace or complement roles. These rules can be fairly simplistic and based on what position the user holds and what they are requesting. Role Based Access Control (RBAC) is based on a collection of permissions that employs job function roles to regulate access to resources. The goal is to enable user authentication and to enforce target-based, coarse-grained or fine-grained authorization before forwarding a user’s request alongside with their credentials to any of the Web application servers. This way, the Web application developers can stay free of maintaining any security infrastructures.1.5.2 Identity and credential management Identity and credential management establishes and manages the identity of the user throughout the lifecycle of that identity. This begins from the initial provisioning of the user’s identify — including the defining of access rights and following a logical workflow to complete the process. Identity management uses policies to define access rules to resources that the user requires to complete their jobs and fulfill their roles. Using policies to manage identities provides consistent and automated updating of identities as users move between departments and positions in the organization. Access approval, user provisioning, and compliance reporting are extremely important for managing the integrated identity. Processes for approvals must be followed to ensure that access rights are appropriate for each user in question. When reprovisioning the users, there is a logical flow and sequence of steps that must tie into the non-IT segments of the workflow. One example is to periodically validate that personnel are still valid and authorized users. This ensures the security of accounts by eliminating those accounts of personnel who no longer work for the company or whose responsibilities have changed. Another example is to frequently check the active user accounts and access permissions and cross-reference them to the existing provisioning policies for users and roles. This ensures that users only have access to systems they are entitled to. Any access rights manually granted without proper policy-based indication (for example, by your friendly administrator) can be automatically revoked and audited. Integrated identity management also enforces access control across the extended enterprise. By using the identity information and combining it with policies to enforce access, greater consistency exists across the enterprise. If the access rights are enforced by policy and are based on specific information in the identity data, the need is removed for explicit access definitions. This allows for a more consistent and centralized approach to managing the enterprise.12 Integrated Identity Management using IBM Tivoli Security Solutions
  • 26. By taking the policy based access approach, you manage information privacy and adhere to regulatory or corporate requirements in an integrated and automated fashion — having the ability to specifically identify the information that must be kept private and safe guarding that privacy.1.5.3 Audit management Audit management is a crucial part of any solution. Unfortunately, many organizations learn this the hard way—after a security event has occurred. As part of the integrated identity solution, planning what events need to be audited or monitored and to what level is a crucial step. Auditing and monitoring are the foundation to sustaining accountability. The National Computer Security Center (NCSC) has approved the following definition: “An audit trail is a chronological record of system activities that is sufficient to enable the reconstruction, reviewing, and examination of the sequence of environments and activities surrounding or leading to an operation, a procedure or an event in a transaction from its inception to its final results.”1 With this definition in mind, the necessary requirements for tracking various activities should be carefully planned and agreed upon to minimize disruptions to the business process. This includes both internal as well as external access to resources. Logging events such as unauthorized or abnormal activities, attempted intrusions and systems failures helps to reconstruct the events that occur and provide evidence for legal purposes and analysis reports to track and correct vulnerabilities. Unfortunately, when logging is used to monitor a system or events, so much data is collected that important information can and does get buried. Being able to sort through the data and reduce it to something usable is an art that requires attention to detail. Tools are available to record and report on events and should be employed to reduce the volume of information gathered into a usable and understandable format. Key points to observe in building an audit system include these: Management should agree with the audit requirements. The scope of audit/monitoring should be agreed to and controlled. Logs should be read-only and access to them limited to read-only. Necessary resources for performing the checks should be identified and made available. The need for special or additional resources should be identified and agreed upon. All procedures, requirements and responsibilities should be documented.1 National Computer Security Center, Glossary of Computer Security Terms, NCSC-TG-004-88, October 1988 Chapter 1. An introduction to a new reference architecture 13
  • 27. The key objective in any audit environment should be to maximize the effectiveness of the system and to minimize interference not only to the system, but the audit process itself. That means protection of the tools and records as well as the IT systems involved.1.5.4 Directory management Increasingly, enterprises are seeking to improve operational efficiencies and expand their businesses by opening their internal systems to a broader community of their systems, employees, customers, and suppliers. A consistent and reliable identity infrastructure enables enterprises to expose their internal processes to their supply chain, their customers, and to the growing mass of automated machine-to-machine transactions. A common identity repository is a key enabler for security and application infrastructure in an enterprise. A centralized repository is meant to consolidate all user and resource definitions into only one data source. Most companies, while expanding their business, also increase the number of applications and platforms, usually each one with its own format and place for defining the enabled users. The final result is that user credentials are stored in a number of different and disjointed places. This means that the same person might have different un-synchronized accounts for different applications. In large companies the number of these accounts may reach double or even triple digit numbers. This situation presents a number of problems, including: High costs for user management: Expenses increase proportionally to the number of repositories. Security: Policies, standards, and guidelines cannot be enforced consistently across the enterprise. Data integrity: Inconsistent information is possible across the enterprise. Risks: There are higher risks related to human errors, malicious attacks, and system failures. Growth: Availability and scalability of the systems These problems can be faced and mostly solved by consolidating the disjointed data sources in only one manageable, available, and scalable repository. This is one of the basic concepts to implement an integrated identity solution. Managing and consolidating information allows for the definition of an authoritative source of user identities, and to establish clear and uniform processes to manage user definitions.14 Integrated Identity Management using IBM Tivoli Security Solutions
  • 28. 1.5.5 Privacy management Webster’s defines privacy as “the quality or state of being apart from company or observation”. In an IT world, privacy is the right of an individual to decide when, how, and to what extent information about them is communicated to others. When an individual gives their private data to an enterprise, the enterprise should consider itself the custodian of the data, and let the individual, as the owner of the data, decide how it should be used. Why consider privacy in an integrated identity project? If security is the protection of information, privacy is the act of complying with how the individual wants that information distributed. An example of this would be: A department within an enterprise has customers that have consented to receiving e-mail updates. Does this mean that you can send them e-mail about products from other departments? Are you allowed to share their information with other departments or business partners? Without policies governing these situations and governing what information may be shared, there is no clear-cut answer to either question. Formulating an enterprise privacy strategy is imperative in today’s global corporation. There are a number of risks faced if a privacy policy is not enforced. The risks include but are not limited to the following situations: Erosion of Reputation and/or Brand: Privacy violation is being reported as one of the key inhibitors to the growth of on-line business. Business relationships are built on trust. Organizations that demonstrate good privacy practices can build trust and grow their business. Organizations with poor privacy practices alienate their customers. Legislative Reproof: In response to various privacy violations and consumer complaints, many countries have enacted legislation to protect privacy. The core of the legislation is generally based on the Organization of Economic Co-operation and Development privacy guideline (http://www.oecd.org). When many of the current member countries were first considering privacy legislation, the OECD was concerned that the creation of so diverse and disparate privacy regulations would impede the flow of information between countries. Actual enactment of the legislation has varied significantly. In the EU, Canada, and Australia, regulations that cross industry sectors have been enacted. The United States has taken a sectorial approach enacting separate regulations for health care, finance, and protection of children’s data. Asia, as a whole, is not as far along in the creation or implementation of guidelines. The notable exceptions to this are Japan, Hong Kong, and Taiwan. Lawsuits: Lawsuits against organizations that violate privacy regulations or promises are becoming more common. A quick search of the United States Federal Trade Commission (FTC) Web site, for example, will find a number of companies that have both been charged by the FTC on privacy violations and that are under a class action lawsuit from their customers. Chapter 1. An introduction to a new reference architecture 15
  • 29. Unfortunately, up until quite recently, there have not been any software tools available for privacy policy enforcement. Enterprises have had two choices: Do nothing and pray that they don’t violate too many regulations and they don’t annoy too many of their customers. Or, try to implement their privacy policy across their application environment. This usually means coding privacy policy into applications. Enterprises are finding that implementing a privacy policy across their application environment is a daunting task. Each application that accesses private data has to be enhanced to include the privacy policy. This is an expensive and slow process. With an integrated identity approach, policies and guidelines may be implemented across the board, thus offering less confusion and greater control.1.6 Conclusion Clearly, many obstacles exist, but there are best practices that organizations can follow to mitigate risk, optimize investment, and achieve results, and ultimately balance user experience with greater productivity and cost savings, allied to increased IT security. An integrated identity solution offers a method of overcoming the obstacles and offering a greater return on investment from the enterprise by consolidating resources and utilizing them effectively. The introduced reference architecture for integrated identity management should be regarded as a measurement for optimized integration where all identity management related components should fully leverage and utilize one and the same infrastructure (see Figure 1-2 on page 10).16 Integrated Identity Management using IBM Tivoli Security Solutions
  • 30. 2 Chapter 2. What Bank International This chapter provides an introduction to the overall structure of our hypothetical corporation, What Bank International (WBI), including its profile, current IT architecture, and infrastructure, as well as its medium-term business vision and objectives. We also describe the business requirements, functional requirements, security design objectives, and architectural decisions for an Integrated Identity Management solution. Note: All names and references for company and other business institutions used in this chapter are fictional. Any similarity with a real company or institution is coincidental.© Copyright IBM Corp. 2004. All rights reserved. 17
  • 31. 2.1 Company profile What Bank International (WBI) is one of the financial institutions established throughout the continental United States and Europe. It has been in business for more than 30 years and now operates over 10 sites, providing common financial services, such as account management, credit card supply, and cash checking, as well as trading or other specialized services for high value customers. The following sections describe: The geographic distribution of WBI The company organization HR and personnel procedures Note: The following sections describe the company information relevant to our context and are not intended to be a complete description of the company.2.1.1 Geographic distribution of WBI WBI sites are distributed trough the continental United States and western Europe. The corporate head office is located in London, UK. WBI further operates the following four regional centers: RU Regional center Europe (London, UK) and the peripheral IT data center RW Regional center West (San Francisco, California) RC Regional center Central (Paris, Texas) and the central IT data center RE Regional center East (New York, New York) These regional centers service the basic IT needs of the sites in their respective region (including first-level user support and user administration). They also provide Customer Service Center services for the region (such as on-line account informations or trading operations). The corporate IT staff is located in Paris, Texas, within the US IT data center (which contains the core IT infrastructure). Members of this team are developers, engineers, and project managers for the corporate information systems. A second, historical, IT data center is located in London, UK, due to a merger in the early 1990s. The other WBI sites are distributed throughout the regions.18 Integrated Identity Management using IBM Tivoli Security Solutions
  • 32. The geographic distribution of WBI is shown in Figure 2-1 for the continental US division and in Figure 2-2 for the European division. New York (Customer Service & Regional Center East) Seattle Detroit San Francisco (Customer Service & Denver Regional Center West) St Louis Raleigh Paris (Customer Service & Regional Center Central) Los Angeles Paris, TX IT CenterFigure 2-1 Geographic distribution of WBI sites for the continental US Chapter 2. What Bank International 19
  • 33. London (C ustom er Service & Regional Center Europe) Paris London, UK IT Center Rom eFigure 2-2 Geographic distribution of WBI sites for the European division2.1.2 Organization of WBI The company is split into five key areas: the four regions and a core services department, as depicted in Figure 2-3. E x e c u tiv e R e g io n R e g io n R e g io n R e g io n C o re W est C e n tra l E ast E u ro p e S e rvic e sFigure 2-3 Key areas for WBI company20 Integrated Identity Management using IBM Tivoli Security Solutions
  • 34. Each of the regions is responsible for the operations within that region, customer service, and staffing. All the regions have the same structure. The organization chart for Region West is shown in Figure 2-4. Region West Banking IT Customer Services Center Card Account Broker Tech HelpDesk HR Services Services Services Support Los Seattle CSC AngelesFigure 2-4 Organization chart for Region West The core services department acts on a company-wide scale. Core Services include support services for the IT data centers (development, applications Help Desk, and systems administration), HR, sales, and finance. The organization chart for Core Services is shown in Figure 2-5. Core Services Sales Support Finance IT Data Partners Marketing HR Accts BO Trade GA Center Systems HelpDesk IT DevFigure 2-5 Core Services organization chart2.1.3 HR and personnel procedures Personnel is managed locally within each region for the regions, and by the Core Services HR team in Paris for all Core Services staff. Chapter 2. What Bank International 21
  • 35. The following procedures apply to personnel management today: When a new employee joins the company, the employee is added to the authoritative HR system. An e-mail is sent to the new employee’s manager indicating when the person is starting to work and giving their HR details. The manager determines what types of access each person needs and sends e-mails to the appropriate support teams to create accounts on the systems (for example, the LAN team creates the NT domain account, and the back-office application teams create the intranet application accounts as well as z/OS® RACF® if needed). When access is granted, an e-mail is sent back to the user’s e-mail account giving account details, including passwords. As the support teams are small, there are often delays of a few days when creating each account. When an employee requires additional resource access, the request has to be approved by their manager, who then involves the appropriate support team, via e-mail, to execute the request. As with new accounts, the support teams grant the additional access. When employees forget a password, or have an account locked due to invalid passwords, they have to call the help desk (either at the regional or central level). The help desk can reset NT (LAN) and z/OS RACF passwords and accounts, but some specific application resets need to be referred to the respective support team. When employees leave the company, they are removed from HR, and normally their set of accounts is deleted. However, this is not applied consistently, and there are no control mechanisms in place to ensure proper removal or inactivation. Each employee has a jobcode to describe the job role. Some of these are common across the regions, such as Manager and CSC operator. Some jobs are specific to a team, such as Intranet application administrator. These job roles and jobcodes are managed by the central HR team. They rarely change. When new employees join the company, there is some manual provisioning that must be performed, such as real estate set aside for them, including desk locations, phone connection, and filing cabinets. This is normally carried out by the new employee manager sending an e-mail to the local office manager, who arranges everything.2.2 Current IT architecture In this section, we describe the current IT environment at WBI. We cover: An overview of the WBI network The recently implemented e-business initiative22 Integrated Identity Management using IBM Tivoli Security Solutions
  • 36. The security infrastructure deployed for the e-business initiative The secured e-business initiative architecture Identity management and emerging problems2.2.1 Overview of the WBI network WBI’s central IT data center has implemented a back-end datastore, which is based on DB2® running on z/OS. They are using an MQ Series infrastructure for asynchronous transactions between the central IT data center, the CSCs, the European and regional data centers. WBI uses Lotus® iNotes™ as an e-mail system. This application is available for each employee. High-level network diagrams of WBI’s network are shown in Figure 2-6 (for the continental United States) and Figure 2-7 (for Europe). New York Seattle Detroit San Francisco Denver St Louis Raleigh T3 (45Mbps) T1 (1.54Mbps) Los Angeles Internet T3 (45Mbps) Paris, TX T3 (45Mbps) to Europe IT CenterFigure 2-6 High-level network diagram for the continental United States Chapter 2. What Bank International 23
  • 37. All external access to the WBI network is channelled through the firewalls and routers in Paris. Corporate access to the Internet is provided through a secure and highly available Internet Access Point, managed by the IT Center. All links are leased from a telecommunication operator. This service provider ensures reliability and redundancy as agreed in the service level agreement. London, U K IT C e n te r P a ris T 3 (4 5 M b p s ) to C e n tra l Rom eFigure 2-7 High-level network diagram for the European division Internet access for European employees is provided by the IT data center in region Central, through the corporate Internet Access Point. The applications and infrastructure used in Europe is similar to those in the US. They are planned to be standardized globally in the future.24 Integrated Identity Management using IBM Tivoli Security Solutions
  • 38. 2.2.2 Recently implemented e-business initiative Most of the business applications have been migrated to an e-business environment, and at least Web based access interfaces are provided to nearly all back-end applications. The implementation is based on a WebSphere® Portal and WebSphere Application Server (J2EE applications) solution. The communication with the back-end databases and applications leverages the high-speed network connectivity described previously. The implementation of IBM Tivoli Access Manager was the first important step for improving security, and for providing an access control infrastructure that is independent of the application layer. The targeted Integrated Identity Management Solution has to provision accounts to operating systems (Windows® NT and 2000, AIX®, and z/OS), LDAP, the e-mail system, the portal applications, and the IBM Tivoli Access Manager components, while adhering to existing security policies and procedures.2.2.3 Security infrastructure deployed for the e-business initiative In the past, WBI experienced many unauthorized access attempts to critical business data. This is why WBI has decided to use a centralized access control mechanism. This mechanism enforces authentication and authorization of users before they actually access the applications and related data via their Web browsers. This solution is based on IBM Tivoli Access Manager for e-business and uses the WebSEAL component to enforce access control. A typical user access looks like this: 1. The user logs on to the Windows domain specifying their Windows user ID and password. 2. The user starts their Web browser and then accesses a portal page for applications. Because WBI has decided to use the SPNEGO1 Windows SSO mechanism, users have no need to log on to the corporate portal. The presented Kerberos credential is used for access control decisions by WebSEAL in the regional center the site belongs to. 1 SPNEGO stands for Security Provider NEGOtiation authentication protocol. For more information on Tivoli Access Manager for e-business SPNEGO support, consult the IBM Tivoli Access Manager WebSEAL Administrator’s Guide Version 5.1, SC32-1359. Chapter 2. What Bank International 25
  • 39. 3. WebSEAL accepts or denies the login. WebSEAL works as a reverse-proxy between the user’s Web browser and the application hosting Web server, controlling whether a user can access the requested resource or not. WebSEAL’s access control decisions are based on the information maintained within the Access Manager Policy Server and an LDAP repository. The Policy Server stores access control information used by WebSEAL, and other Access Manager authorization services, in an authorization database, which is distributed as a database replica to all defined WebSEAL and other authorization servers. Dialogs between WebSEAL and the Policy Server components are implemented using an Access Manager Proxy Policy Server component. The LDAP server stores the user credential information assessed at the time of the user’s login. For each region, a Proxy Policy Server is located in the Regional Center management zone, and WebSEAL and LDAP replica servers are made available in a specific production zone to each regional center. The LDAP master and the Access Manager Policy Server is located in the management zone in the central IT center in Paris, TX. An overview of where the components are placed within the overall architecture can be found in Figure 2-8 on page 28. Today, only the Web applications are secured by WebSEAL using Web user accounts, but there are other types of accounts necessary to run standard operations, such as Windows NT® and 2000, AIX, and z/OS. These accounts can only rely on the native operating system security. That is why WBI puts the employees under an obligation to follow additional security policies to strengthen the levels of security, such as periodical password changes, and other password policies for all types of accounts. They are looking to add Tivoli Access Manager for Operating Systems into their security infrastructure at a later point in time. At the time of implementing this security solution, WBI has started to provide new Web based customer services (balance of a customer’s account, personal trading operations, special campaign information, and so on) via the Internet. A customer’s access to their data is controlled by WebSEAL also. Note: If you want to find out more about the different base components involved in the initial WBI rollout, please refer to the redbook Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01.26 Integrated Identity Management using IBM Tivoli Security Solutions
  • 40. 2.2.4 Secured e-business initiative architecture The overall IT architecture is being impacted by the new e-business infrastructure and by other organizational changes. For the mid-term future it has been decided to close the European IT data center and to apply best practices and methodology for architecting a secure infrastructure by segregating assets into different Level of Trust zones. Note: The redbook, Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01, introduces the Method for Architecting Secure Solutions (MASS) as a methodology for developing a design for a security implementation. It provides a detailed example of developing a security architecture using MASS. This method provides a proven approach to creating high-quality security architectures and includes Identity Management aspects as part of the full scope. This new infrastructure will drastically alter the network topology and firewalls configuration. But as we focus on Integrated Identity Management, our purpose is to depict the possible future WBI architecture. The WBI architecture is shown in Figure 2-8. For details on the implementation, refer to 4.2, “Technical implementation” on page 126. The target architecture will federate legacy systems in only one IT data center in the Central Region. The architecture permits the segregation of the data (DB2 on z/OS) and the Identity Management zone in the Central IT Center as well as in regional centers, for systems management zones, production zones, and user corporate networks. A specific DMZ is dedicated to Internet customer access. This ensures performance and appropriate security measures for uncontrolled access. Ultimately, production and management zones in the regional centers will also be segregated by a firewall. A dedicated management zone is introduced to respond to other new emerging problems in the area of identity management, described in the following section. This zone is located in the central IT Center. Chapter 2. What Bank International 27
  • 41. Central Central IT Center, Paris z/OS IT Center (DB2,MQSeries) Web Portal I BM Server F AIX I R E FIREWALL W A L LDAP L Master F F Identity LDAP LDAP Access Management I I LDAP replicas replicas Manager Server R R replicas E WebSEAL E Policy W W Server Management zone A A L L L L F IR E WALL 4 Regional centers F I Access LDAP R Manager Replica E Proxy W Policy A Server WebSEAL L L Production Zone Management Zone F IR E WALL Internet DMZ WBI sites application data flow access control flow Windows Domain Intranet Identity mgt flowFigure 2-8 Entire WBI architecture2.2.5 Identity management and emerging problems Emerging problems are related to user administration and identity management. Before we describe the emerging problems in detail, we give an overview of the current user management.28 Integrated Identity Management using IBM Tivoli Security Solutions
  • 42. Actual processesWBI uses many different platforms with user accounts in their system. The staffat the WBI sites have accounts in a Windows domain and the LDAP directory(for WebSEAL controlled Web application access). The regional centeradministrators have accounts on the central AIX systems, as well as theWindows domains in their region and the LDAP directory. All these accounts aremanaged by the regional center administrators using operating system or LDAPspecific interfaces. Windows domain accounts are created with the Windows NTUser Manager, AIX accounts with the smitty interface, and LDAP accounts withthe pdadmin command line utility or the Web Portal Manager shipped with TivoliAccess Manager for e-business.Programmers and developers in the central IT data center have their accountson all platforms in the enterprise, including z/OS. Due to their specific tasks andinfluence, they often manage their own accounts with administrative rights — theregional administrators are not involved. Accounts on z/OS are created using theRACF interface provided with z/OS.Since customers are accessing the WBI applications by Web browser interfaceonly, their accounts are solely created in the LDAP registry located in Paris, TX.These accounts are managed by administrators in the Paris IT center. To date,only a few customers have requested accounts, but since it is planned to expandthis business area in the future, specific policies and procedures need to bedesigned for handling and maintaining these accounts.Emerging problemsAs mentioned above, all employees have several types of accounts, and theymust maintain multiple sets of user ID and password combinations. Employeeshave to call a regional administrator in order to reset the password. Especiallyafter the new periodical password change policy has been applied, more andmore password reset requests come to the attention of the regionaladministrators. The current password reset flow is as follows:1. A user who wants to reset their password must use a hardcopy request form specifying the type of account, account name, and the reason for the reset request.2. The user’s manager accepts the request form and signs for approval. In the case of denial, the request form is returned to the requester.3. The user faxes the form to their regional center after getting their manager’s approval.4. An administrator resets the specific account(s) and sends an e-mail to the user and their manager to inform them about the password reset and the new temporary password(s). Chapter 2. What Bank International 29
  • 43. Too many requests cause regional administrators not to reply immediately, and some employees cannot continue their work because their accounts remain inaccessible. When a user’s manager is not available temporarily, the password reset procedure gets even more delayed. The management of customers accounts needs to be improved and automated, as the number of accounts is expected to increase significantly over time (see 2.4, “Business requirements” on page 31 for more details).2.3 Corporate business vision and objectives WBI has successfully implemented the first e-business applications for employees. Next they plan to provide some of their applications and services to their customers using a Web-based access method. The existing system relies on a Web-based application infrastructure provided by IBM WebSphere Portal and an access control solution using IBM Tivoli Access Manager for e-business. The decision to move ahead with the implementation phase was made because of the benefits to future business-led projects. These projects would no longer need to code complex security models, which implies a more rapid deployment of the applications (product or service). A complementary ROI study has also shown that quick benefits were realistically achievable. Note: See the redbook, Identity Management Design Guide, SG24-6996, for an example of an ROI questionnaire and analysis results. In order to increase employee productivity and improve customer satisfaction, the user management processes for all the involved platforms have to be streamlined, and opportunities for human errors need to be reduced, if not eliminated. The WBI mid-term business vision is as follows: WBI wants to deploy a corporate wide integrated identity management system to be operated efficiently and correctly, following the corporate security policies. In order to lower administrative cost, it is desirable to automate management operations wherever possible. WBI wants to offer self-care and self-registration functions as a key benefit to empower users to be autonomous and proactive.30 Integrated Identity Management using IBM Tivoli Security Solutions
  • 44. WBI wants to extend remote work capabilities for WBI employees. Employees will use I-notes as the corporate mail system and a Web browser interface to access internal corporate applications as they are increasingly being moved to a Web-based version. Employees, and in the longer term, customers, will be able to use new on-demand applications using online registration and subscription processes via the Internet, but at this time it is not planned that employees and customers share the same applications. These new processes have to be automated and secure; if needed, human approvals will be part of the new processes. WBI already has some systems management functions in place, such as monitoring system availability, and software distribution, which are implemented based on the Tivoli Framework. An additional user and identity management system should be implemented with minimum development cost, making full use of the existing resources and minimum impact on the existing infrastructure. Based on this corporate business vision, WBI has decided to implement the new solution in two phases: 1. Build the foundation for an enterprise wide integrated identity management infrastructure based on IBM Tivoli Identity Manager. In this phase WBI wants to provide automatic account provisioning, self-care, self-registration, and application subscription for a pilot subset of internal users. This also includes necessary automation where needed (for example, for approval cycles). 2. Refine and extend the system with customization and workflow automation to further reduce administrative costs, streamline IT operations, and open it securely to customers in an autonomous way. This second phase also needs improvements for audit compliance, privacy enforcement, and risk management.2.4 Business requirements WBI has implemented their e-business system with Web-based technology and a Tivoli Access Manager based access control architecture. They have to deal with some emerging problems, as described in 2.2.5, “Identity management and emerging problems” on page 28. WBI wants to move forward for some of the Corporate business vision and objectives with a first subset of internal selected users. After the first phase is implemented successfully, WBI wants to apply the concepts to their customers via the Internet in order to take the leadership in a new emerging market. Chapter 2. What Bank International 31
  • 45. 2.4.1 Business requirements for phase 1 From the vision and objectives presented in 2.3, “Corporate business vision and objectives” on page 30, the following business requirements for phase 1 of the project are formulated: All administrative operations related to user management, including user creation, modification, deletion, and password reset, need to be performed immediately in order to minimize any latency times for internal users as well as customers. The Corporate security policy should be enforced for all user accounts and their attributes, access rights, and password rules. No user account inconsistent with the policy should be allowed. The CIO wants to gain further cost savings by reducing the amount of work the system or application administrators still have to do. These areas are related to user autonomy improvements (internal as well as customers) in providing automated account provisioning, self-care and self-registration functions, and application subscriptions. For phase 1, these new functions will be implemented for a subset of selected internal users. The user management historical data has to be available from a corporate-wide perspective in order to verify whether the system works according to the guidelines and policies. These logs can help understand shortcomings and implement future improvements, as well as being used for non-repudiation or tracking external users activities. The existing system resources should be utilized as much as possible, and the new integrated identity management system should be implemented with reasonable new investments. There are several hidden details behind each of these phase 1 business requirements. In 2.5, “Functional requirements” on page 33 we take a closer look at those details. The following two areas have the greatest impacts on the functional requirements: Giving external customers access to the WBI information systems Providing users with self-care, self-registration, and self-subscription to application functionality32 Integrated Identity Management using IBM Tivoli Security Solutions
  • 46. 2.4.2 Business requirements for phase 2 WBI has secured their e-business applications by implementing Tivoli Access Manager to secure the Web interfaces, by implementing Phase 1 of the integrated identity management project to consistently manage users and their accounts, and by using innovative solutions for on demand applications. WBI now wants to enhance this infrastructure to further improve IT management and IT cost control, as well as the efficiency of IT operations and access for customers in an autonomous way. This phase also supports audit compliance and risk management. The business requirements for phase 2 are as follows: Further reduce costs of administering users and their passwords: The first phase of the integrated identity management project is expected to provide significant administration cost savings by providing employees with the tools to manage their personal information, passwords, and e-business applications used. In phase 2, this is extended to all internal users and to customers who want to access business applications via the Internet. Improve audit compliance: WBI is prepared for further new regulation aspects in banking environment. This requirement includes Risk Management and Privacy Management: new regulations are planned to be enforced in the coming years. As a first step, WBI is interested in the ISO 17799 approach as a good first way to use extremely comprehensive and detailed standards and improve internal audit methodology. Compliance, therefore, will require both a methodical and measured approach as well as appropriate tools and products. This is perhaps a prelude to future compulsory certifications. Note: Consult Appendix A, “ISO 17799 compliance mapping” on page 159 to see how an integrated identity management solution can improve IT implementation according to the ISO 17799 standard.2.5 Functional requirements For Phase 1 of the project, we extract functional requirements by tracing “objective — reason” trees in Figure 2-9 on page 35, Figure 2-10 on page 37, Figure 2-11 on page 39, Figure 2-12 on page 40, and Figure 2-13 on page 40. These figures start with the business requirements above (numbered I.1, I.2, I.3, I.4, and I.5). Chapter 2. What Bank International 33
  • 47. 2.5.1 Phase 1 Let us examine every objective, and evaluate for reasons and the functional requirements. OBJECTIVE I.1: Administrative operations for identity management should be performed immediately and correctly. The main problems in this area are the increasing password reset requests that have to be handled by the administrators and the fact that the management operation itself can be very time consuming. After implementing a central security solution for access control and applying a new security policy for passwords, the users have to maintain multiple accounts with different passwords, which they have to change more frequently than before. This, as a result, causes too many password reset requests. If each user has a single password for their multiple accounts, password maintenance becomes easier. Not all administrative tasks need to be performed by the same level of administrator. Many tasks can be delegated according their security level. For instance, password resets do not require a high security clearance as long as we can see its operation flow within the logs for audit purpose. A password reset can be delegated to people other than administrators, for example, to the users themselves. Delegation is a contribution to alleviate the administrative workload. Self-care is a key point for empowering internal as well as external users. User management operations themselves are time consuming and can be skill intensive because different management interfaces (necessary for each type of account) are hard to handle and need much time for administrators to master. Administrative productivity could be enhanced by utilizing a common, user friendly interface to manage different types of accounts centrally. When accounts are created or modified, it is convenient for attribute values common to all or some of the accounts to be entered automatically. An automatic function to verify values that are entered by manual or automatic operations is desirable as well. Adding to this, it is preferable that some business processes are automated, such as sending an e-mail to a user, to a manager or to an account manager for approval. The final problem of objective 1 is founded in the hardcopy request forms for an internal user. It would be desirable for a series of operations (from creation of request form, through operation of approval, to notification of requests completed) to be handled digitally and integrated into the user management system. This digital process is mandatory for handling external users.34 Integrated Identity Management using IBM Tivoli Security Solutions
  • 48. OBJECTIVE I.1: Identity management should be performed immediately and Functional correctly. requirements REASON I.1-a: Administrators can not fulfil tasks in proper time, especially with external users I.1-a1: Too many password reset requests to administrators. I.1-a11: A user has different passwords for his accounts. I.1-a12: FR1.1 : A single password Passwords should be changed for users accounts. periodically for the companys security policy. I.1-a13: Almost all administrative tasks FR1.2 : Delegate low- are executed by administrators security administration with any security level. tasks to others including I.1-a2: end users. It is time consuming to manually manage internal user data or to execute requests - this is unmanageable for external users FR1.3 : User-frendly interface. I.1-a21: Different interfaces for every FR1.4 : Central common type of accounts. interface. I.1-a22: Values are entered manually FR1.5 : Common values by administrators. are entered automatically. I.1-a23 FR1.6 : Value checking Often, operations need to be function is required. redone because of mistakes. REASON I.1-b: It may take to much more time to FR1.7 : Automate get an approval. business processes. I.1-b1: For internal users, when manager is not in the office, he can not approve it I.1-b11: Hard copy request form. FR1.8 : Integrate business processes into I.1-b2: user administration For external customers,quick system. account manager approval or immediate automatic basic creation are needed.Figure 2-9 WBI functional requirements, part I.1 Chapter 2. What Bank International 35
  • 49. OBJECTIVE I.2: The corporate security policy should be enforced for all accounts. Accounts sometimes carry attributes that do not adhere to the corporate security policy because attribute types and the ways of setting them differ depending on account types, and because all or most of them are set manually. Furthermore, there is no verification function for entered values. If an enterprise-wide user management system is available, administrators can apply the corporate security policy to those attributes without having to realize differences between account types. If there are some common values between users, such as password length or invalid password retry count, automatically entered values contribute to decrease manual mistakes. In addition, verification functions can prevent creation of user accounts with invalid values. This aspect is important for internal users but when opening the information systems to external users, which are able to create their own external identity, the corporate policy enforcement will guaranty that only compliant and legitimate identities are created.36 Integrated Identity Management using IBM Tivoli Security Solutions
  • 50. OBJECTIVE I.2: The corporate security policy Functional should be enforced for all requirements accounts. REASON I.2-a: Accounts with invalid attribues may be manually created by mistake. I.2-a1: FR2.1 : Centrally cross- Every type of account has a wide user management. different way of definition. I.2-a2: FR2.2 : Common values Manual operations may cause are entered automatically. invalid values. V2-a3: FR2.3 : Value checking No value-checking function. functions are needed. REASON I.2-b: Account can be created via Self registration process, or modified via self-care I2-b1: Values have to be checked to ensure compliance with policy I2-b2: FR2.4 : Automate Enforcement is immediate and business processes. utomaticFigure 2-10 WBI functional requirements, part I.2 OBJECTIVE I.3: The CIO is keen to gain further cost savings by reducing the workload on system or application administrators and by enhancing autonomy for users. The efforts required to manually create accounts when a person joins the company, and the efforts required to adapt accounts when an employee changes job roles are the two first topics addressed here. Autonomy is a more innovative requirement. In the CEO’s mind, it is a way to promote their company to become a leader on emerging markets (for example, by quickly providing new e-business applications to customers using a self-subscription function) and a way to improve agility and flexibility inside the company. Chapter 2. What Bank International 37
  • 51. The autonomy goal for internal users covers the maintenance of personal attributes (for example, mobile phone number in the white pages, and so on). The policy enforcement functions guarantee that this is performed without any conflict in regard of the authoritative sources. These functions should be accessible without any administrative support from the IT teams. In addition to maintenance tasks, mobile and front office users (for example, sales representatives or clerks) are able to increase their own business efficiency. The CIO’s plan is to develop new tools and applications for these groups of users and provide a much faster availability than today. Let us take a look at an example: If a user has a particular need for a financial simulation tool or a specific portal application, they can register themselves for the application. If their request is compliant with the company policy according to their group memberships and roles, the system grants access to this application, in a secured and auditable way, with no manual intervention necessary for IT team resources. If these users have to change their job role, the company policy will be automatically applied, and access information as well as standard application portfolios are updated (preserved, modified or even automatically deleted). All these changes will be completely auditable.38 Integrated Identity Management using IBM Tivoli Security Solutions
  • 52. OBJECTIVE I.3: Functional Further cost savings and enhancement of "autonomy" requirements REASON I.3-a: Reduce manual activities for managing accounts by job roles FR3.1 : Centrally cross- I.3-a1: wide user management. Use an authoritative HR source FR3.2 : Common values I.2-a2: are entered automatically. Define Company job roles I2-a3: FR3.3 : Integrate Automatically grant access and business processes into generate changes / job role user administration system. I2-a3: Automatic process should be FR3.4 : Provide audit auditable trails REASON I.3-b: IT resources will focus on other tasks than user management FR3.5 : Value checking functions are needed. I3-b1: Users will have self care functions FR3.6 : Delegate I3-b2: administration tasks and Autonomous users will manage registration tasks to end their related sphere with self- users. registration and self subscription to applications FR3.7 : Automate business processes.Figure 2-11 WBI functional requirements, part I.3 OBJECTIVE I.4: Corporate-wide user management data has to be available for verification, future improvements, as well as audit and traceability for external users. In the current system, account information is scattered all over the corporate systems. It is not easy to understand how many user accounts are being used in the enterprise, at what rate they are growing, and when the system should be expanded due to increasing account numbers, and so on. The information is indispensable for verifying the current system and for making future plans to expand it. This is a key point regarding the future expansion to external users, as planned in 2.3, “Corporate business vision and objectives” on page 30. A central logging system can provide this information. Chapter 2. What Bank International 39
  • 53. OBJECTIVE I.4: Corporate-wide user management Functional data has to be available for requirements verification, future improvements as well as audit or forensics REASON I.4-a: User information is scattered over the enterprise, such as on every LDAP server, every operational machine... I.4-a1: FR4.1 : Central logging There is no integrated logging system is needed. system. REASON I.4-b: External user identity is the link for in e-business for non- repudiation mechanisms or forensics activities I.4-b1: FR4.2 : Automate There is no integrated logging business processes. system. FR4.3 : Integrate I.4-b2: business processes into In case of need (for non- user administration repudiation mechanisms or system. forensics activities), link between identity and person has to be backward established FR4.4: Provide audit trailsFigure 2-12 WBI functional requirements, part I.4 OBJECTIVE I.5: The existing system resources should be utilized and new implementations should be reasonable in order to minimize new implementation costs. OBJECTIVE I.5: The existing system resources should Functional be utilized and new implementations requirements should be reasonable. REASON I.5-a: Existing investments in Tivoli FR5.1 : Integration with Framework system, WebSphere existing systems. portal solution, and Access Manager for e-business system.Figure 2-13 WBI functional requirements, part I.540 Integrated Identity Management using IBM Tivoli Security Solutions
  • 54. Phase 1 functional requirements summary The extracted functional requirements are summarized here: Implement a cross-platform user management and centrally perform password synchronizations and password resets. Centrally control business and security policies for users. Reduce identity management effort through configurable automation of administrative processes through default and validation policies. Provide self-care, self-registration, and self-subscription to users. Delegate necessary administration along organizational or geographic boundaries. Automate user life cycle management by integrating it into the existing business processes. Provide ubiquitous management interfaces, such as Web browsers. Leverage identity data. Provide audit trails.2.5.2 Phase 2 Phase 2 of the project is a natural continuation of phase 1. Phase 2 is a perimeter’s extension of phase 1, regarding the number of users or the availability of new e-business applications. On the other hand, the business requirements described in 2.4.2, “Business requirements for phase 2” on page 33 cover dedicated components of the new reference architecture presented in Chapter 1, “An introduction to a new reference architecture” on page 3. For these topics, phase 2 consists of deploying the corresponding components of the Risk Management and Privacy Management solutions. As part of the new reference architecture and included in the full lifecycle project management, they naturally fit together with the Integrated Identity Management solution. . Note: Refer to Centralized Risk Management Using Tivoli Risk Manager 4.2,SG24-6095-00, and IBM Tivoli Privacy Manager Solution Design and Best Practices, SG24-6999-00, for complete details on Risk Management and Privacy Management aspects of the new reference architecture. Chapter 2. What Bank International 41
  • 55. 2.6 Risk assessment Briefly, risk is usually assessed either formally or informally using quantitative or qualitative methods. This can be as structured as a full external risk assessment, or simply based on the intuition of members of an organization who know and understand how their business is constructed and the risks involved. Risk assessment is an important topic in its own right. The Internet has grown from an interesting tool for academic research purposes into an increasingly important platform for business transactions. As the commercial value of the Internet has grown, so have its risks. A company connecting to the Internet presents its front door to Internet users all over the world. But what about the back doors? Administrators, responsible for the security of the Internet solutions, are faced with shortages of time and resources. Additionally, new Internet applications have to be enabled quickly in order to gain market share and exploit the new opportunities of e-business. Most companies simply cannot keep up with the new challenges and neglect the business risks. Today, the risk of a security breach is very high and the consequences may be devastating. On the other side, security may be very expensive. How much security is enough for an e-business company? How do we determine the right level of security? IBM’s Method for Architecting Secure Solutions (MASS) uses the concepts of risk assessment to answer these questions. The elements of risk assessment are as follows: Assets: Information or resources to be protected by the countermeasures of a system. Vulnerability: A weakness in the software and/or hardware design that allows circumvention of the system security. Threat: An action or event that might prejudice security. Hackers could try to break into our network and compromise data. Also included are external or internal people that may purposefully, inadvertently, or accidentally harm our assets. Risk: The likelihood that a given vulnerability will be exploited by a particular threat. Countermeasure: A measure designed to reduce or eliminate a security threat or vulnerability.42 Integrated Identity Management using IBM Tivoli Security Solutions
  • 56. IBM MASS includes a four-step risk management approach, as shown inFigure 2-14, consisting of these actions: Identify vulnerabilities Identify threats/agents Determine risk Identify countermeasures Assets Identify Vulnerabilities Identify Threats/Agents Vulnera- Threats bilities Determine Risks Risk Identify Countermeasures Counter- measures Residual Risk AcceptanceFigure 2-14 Four step risk assessment approachThis approach provides a logical flow, from the threats to the countermeasures,which should be designed into the architecture. Thus, it anchors the IT SecurityArchitecture firmly in the business requirements and addresses the major risksthat the business faces and mitigates losses that can be estimated. Thecompany focuses on those countermeasures that will address the major risks. Itassists the business case for the architecture, because there is an estimate ofthe losses that it is designed to avoid. Chapter 2. What Bank International 43
  • 57. Note: If you want to learn more about the IBM Method for Architecting Secure Solutions, take a closer look at the redbook, Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. After the risk assessment, risks can be dealt with in one of four ways. 1. Transfer risk: The most common way of transferring risk is through insurance. In the current economic environment, the availability and cost assurance is variable. Currently, this method is more volatile than in the past. 2. Mitigate risk: Mitigation of risks can be achieved by identifying and implementing the means to reduce the exposure to risks. This includes the deployment of technologies that improve the security cover within an organization. 3. Accept risk: An organization may choose to accept that the impact of the risk is bearable without transferring or mitigating the risk. This is often done when the risk’s impact is small or when the cost of mitigation is large. 4. Ignore risk: Often confused with risk acceptance, ignoring risks is all too common. The main difference between accepting risks and ignoring risks is that risk assessment is an implicit part of risk acceptance. If no valid risk assessment has been done, this should raise a warning flag, pointing towards the dangerous path of ignoring risk. Deploying an Integrated Identity Management solution mitigates the security risks associated with poor identity management, access control, and privacy compliance.2.6.1 WBI risk assessment In the risk assessment, WBI examines the risk of the intended infrastructure, focused on identity management, and tries to answer the following questions: What assets need to be protected? An asset can be a tangible item, such as hardware, or intangible, such as an organizational database or even information in it. Who/what are the threats and vulnerabilities? Vulnerabilities are recognized deficiencies in assets that can be exploited by a hacker. An asset may have multiple vulnerabilities. Threats to each asset must be identified. There can be multiple threats for each asset. What can be done to minimize exposure to loss or damage? Possible countermeasures and security recommendations that address the major risks can be taken.44 Integrated Identity Management using IBM Tivoli Security Solutions
  • 58. The outcome or objective of a threat and risk assessment is to providerecommendations that maximize the protection of confidentiality, integrity, andavailability while still providing functionality and usability. The assets of WBI are primarily their databases and the information stored in the databases, about: – Customers financial and personal information – Sales figures and trend analyses collected and generated by the sales information tools – Price conditions used by the traders – Employee data used inside the employee management system Possible security threats are: – Unauthorized access by an external attacker – Unauthorized access by an internal hacker – Eavesdropping on confidential data or personally identifiable data on the network – Misuse by users from an internal network – Misuse by customers from the Internet Possible vulnerabilities are: – Insecure systems or applications – Lost or stolen passwords – Application failuresBased on the risk assessment, we present our security recommendations asfollows: Improve security to control access to servers: – Use security zones to control access to sensitive servers and applications. – Use firewalls or other gateways to control communication between different security zones. Block unwanted traffic and monitor authorized traffic. – Use reverse proxy at the edge of the network with authentication and authorization capabilities to control access to information. – Place critical service and support servers in separate networks and block access using routers or firewalls. – Use secure communication protocols like SSL whenever possible. Improve system security to control activity on systems: – Remove unneeded components, for example, insecure programs like ftp, telnet, and fingerd, if possible. – Manage very closely accounts on systems (for example, delete accounts that are no longer being used) Chapter 2. What Bank International 45
  • 59. – Install security components, for example, system auditing tools and integrity checking tools such as Tripwire. – Check and update all default settings, for example, password rules or impersonal accounts. – Enable system and application logging and send event information to a remote log server. – Monitor usage of all interfaces for users and administrators in order to detect misuse. Ensure application security by using and enforcing authentication mechanisms and access control mechanisms in order to prevent misuse. However, there are some other security risks that may have to be accepted: The administrator needs to be trusted (medium risk). The software needs to be trusted (low risk). With the list of functional requirements and the results of the risk assessment, we can define our security design objectives. Summary In the WBI scenario, the risk assessments have shown that the security risks associated with poor identity management should be mitigated. The discussion in WBI considered the possibility of accepting some of the risks when dealing with internal users (for example, when a person has a new job role, it is accepted by some managers that this person can keep their access for a while; other managers don’t accept that idea at all). However, when opening the IS to external users, the risks related to poor identity management can no longer be accepted.2.7 Security design objectives With the business and functional requirements previously defined in 2.4, “Business requirements” on page 31 and 2.5, “Functional requirements” on page 33, according with the risk assesment, we are now ready to document some of the most important design objectives for our solution. The design objectives can be classified as functional, for example, derived from the functional requirements; and non-functional, for example, the other design objectives. The functional-related objectives can be mapped to the security common criteria.46 Integrated Identity Management using IBM Tivoli Security Solutions
  • 60. 2.7.1 Functional design objectives The functional design objectives cover the following aspects: Identity management Password management Policy management Business process management Audit management Identity management These are the requirements for identity management: All accounts related to a user are managed in the central repository. When users change location in an organization, all of their accounts are moved to the proper machines and their access rights are changed. In order to simplify this operation, users are combined into groups with the same organization or common attributes, and moving group membership gives them the necessary accounts and access rights. User management tasks are delegated to other administrators, managers, or users in response to the security level of a management task. For example, administrators of one regional center can manage only users in the region, not users in other regions. A manager of one division can do some administrative task on users in that division. Some operations, such as password reset, are dedicated to a user. If the created user accounts have common attribute values, those values are entered automatically upon creation by an attached default policy in order to save time and prevent human error. All values of the account attributes can be checked by validation policies. This applies also for customers’ accounts. Identity management can be done by using a common ubiquitous interface, which can be accessed through a Web browser (hereafter known as the Web interface). Administrators, managers, and all users (employees or customers) can use it for user management. When a person is newly employed, they are added to the integrated identity management solution system. New users should be created with minimal input from the administrators. The design must allow for automation, in the form of a default policy that is used to reduce the number of attributes that need to be specified when creating a new user. All other required attributes are derived automatically based on the entered data. This derivation of attributes is based on common standard attributes, which may include department, team, location, and job code. Chapter 2. What Bank International 47
  • 61. When defining a new user, the accounts and the access that the user needs to do their work should be automatically created. The design must allow for the automation of account creation and OS and application group membership. This is done by associating the accounts for a new user with the appropriate OS and application groups and profiles. The accounts and access rights each user should receive may be based on their job code, department, and team. When a user changes their job role and/or team, their access requirements change. The design must allow for the automatic removal of accounts associated with the old job role and creation of accounts associated with the new job role. Where an account is common to both old and new job roles, the design must ensure that the account is carried over. Password management These are the requirements for password management: Users can have a single password for all of their accounts, or they can have different passwords for multiple accounts. When a user changes the single password for all the accounts, the user uses the Web interface to do it. Users who are not administrators are only allowed to access their own information. External customers will be able to do that also for their account. Internal users have to log on to the Windows domain before accessing the Web interface. If their Windows password expires, they change the password locally, which cause inconsistency between the accounts. To avoid this situation, a password change operated locally on a Windows machine synchronizes all the other accounts’ passwords. Administrators can reset the passwords of the users they manage. When users forget their passwords, they can reset them through the Web interface. The user is authenticated by answering some confidential questions. The users define the answers in advance. This applies for customer also. The design should impose corporate security policy password standards to all identities (users and accounts) managed by the identity management solution. Policy management These are the requirements for policy management: When a user sets the password for their accounts using the Web interface, the password strength is checked against the corporate security policy and OS and application specific rules, such as length of passwords, the number of numeric letters included, and so on.48 Integrated Identity Management using IBM Tivoli Security Solutions
  • 62. When a new user or a new account is created, a certain number of common values between users can be provided automatically by the default policy. When a new user or account is created, or an existing user or account is modified, the entered values are checked against the validation policy. The design should allow for the application of security policy and the subsequent modification of policy if the company decides to amend their policy. The application of this policy should be transparent to the user and only impact the maintenance of the solution. Business process management These are the requirements for business process management: The design should incorporate an approval process for the creation of new accounts and the allocation of accounts to OS and application groups and profiles and workflow steps based on department and team. Some of the business processes are automated. If a user needs to have their account created on a particular machine, or they need to reset an invalid password, a request is automatically sent to their manager, and the operation needed for creation or reset is automatically executed after a manager’s approval. Some of these processes can be improved by using enhanced automation, especially some of the new innovative processes (such as self-registration or self-subscription to applications) could be handled without any direct human approvals or interaction. Audit management These are the requirements for audit management: All operations for user management are logged centrally. Gathered log entries are extracted along with what we want to see. The design must address the generation of audit reports, including how the report is defined, when and how it is run, and where the output is sent.2.7.2 Non-functional design objectives The non-functional design objectives are those that do not relate specifically to the functional requirements, but are items that should be addressed in the design. Chapter 2. What Bank International 49
  • 63. For this project, these include: Re-use of the existing infrastructure Standards to be used Maintainability and configuration management High availability and disaster recovery Re-use of the existing infrastructure The design must allow for the re-use of the existing infrastructure (Web enablement and access control design, except where it conflicts with the new requirements. The new Integrated Identity Management components must therefore be deployed into the existing architecture in a way that allows the accommodation of changes in the future with the least possible interruption to service. Standards to be used Where possible, the design must comply with standards in order to make subsequent implementation easier, more secure, and audit compliant. Further details on policies and standards can be found in “Corporate policy and standards” on page 160. Maintainability and configuration management The design must allow for the maintainability of the system. This may involve deployment of some form of configuration management methodology and/or system management tool set. High availability and disaster recovery There are no additional requirements for high availability or disaster recovery as part of our scenario, so the design does not need to be concerned with these items. It is a good idea to be aware of the potential for future changes in directory choice and so on.2.8 Architectural decisions The goal of this section is to describe the key architectural decisions involved in our scenario. This description helps in understanding how Security Best Practices will influence design activities and final architecture. Refer to 3.2, “WBI solution design” on page 83 for further details on design and implementation in our scenario.50 Integrated Identity Management using IBM Tivoli Security Solutions
  • 64. The following four decisions have been made: The network is designed into zones, uncontrolled as the Internet, controlled as an Internet facing DMZ, restricted as the production network, and secured as the management zone. Access control enforcement points are located on the edge of the network; specific access DMZs are created and dedicated to that purpose. It is mandatory that all incoming network traffic passes through these DMZs before proceeding into the production zone. Wherever possible, proxies will be used. The use of proxies is a good way to mitigate risks and to help in controlling flows between zones; as zones are segregated by firewalls, only well-known communication flows issued from an external zone to a proxy or from a proxy to the authoritative server have to be authorized. This reduces complexity of management and also helps to detect abnormal behaviors. For management purposes, dedicated management zones are used. These zones are regarded as secured zones with restricted access reserved to management team members. Chapter 2. What Bank International 51
  • 65. 52 Integrated Identity Management using IBM Tivoli Security Solutions
  • 66. 3 Chapter 3. Applying the reference architecture This chapter describes how the integrated identity reference architecture can be implemented within a large enterprise such as What Bank International (WBI). General approaches to integrated identity solution design and delivery projects are discussed, and the technical architecture of the complete WBI scenario is defined.3.1 Solution design and delivery approach This section discusses approaches to delivering integrated identity management solutions as part of an overall enterprise security architecture, as well as some aspects of re-engineering enterprise business processes for managing identities. As with any IT solution, identity management solutions must provide an appropriate return on investment and also successfully integrate into the complex operational environment of an enterprise. An identity management solution interfaces with a number of external systems and processes a significant quantity of information that is distributed widely across the organization. It is important that the features of the solution be built upon architectures and deployed in an environment appropriate to the enterprise.© Copyright IBM Corp. 2004. All rights reserved. 53
  • 67. The task of developing IT solutions that consistently and effectively apply sound security principles has many challenges, including: The complexity of integrating the specified security functions within the multitude of underlying component architectures found in computing systems. The difficulty in developing a comprehensive set of baseline requirements for security. A lack of widely accepted security design methods. With the formalization of security evaluation criteria into an international standard known as Common Criteria1, one of the impediments to a common approach for developing extensible IT security architectures has been removed. However, adopting the Common Criteria alone cannot guarantee the delivery of secure solutions. Organizations and service providers must adopt a systematic approach to defining, modeling, and documenting security functions within a structured design process to provide an appropriate level of confidence in the resulting IT solutions. Background information on how to develop an end-to-end security architecture using IBM’s Method for Architecting Secure Solutions (MASS) can be found in the IBM Redbook Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. The remainder of this section describes integrated identity management aspects of the end-to-end process in greater detail.3.1.1 Implementation life-cycle The implementation life-cycle presented here provides a brief overview of the methodology that IBM uses to assist organizations implementing integrated identity management solutions. This approach, depicted in Figure 3-1, can assist organizations at several stages of the integrated identity management life-cycle: Assessment and planning: In the assessment stage, the current business and IT environment is analyzed, the current identity management infrastructure is assessed, the business drivers and strategic plans are determined, and the cost structure established. In the planning stage, the candidate solution approaches are outlined in terms of business process, organizational impact and technical solution. Priorities and cost justifications are determined, and a transition plan defined. Solution design: Detailed design is undertaken for the preferred solution, addressing the business process, organizational impact, and technology architecture of the solution. Solution implementation: The solution is implemented, piloted, and deployed. 1 See Appendix A, “ISO 17799 compliance mapping” on page 159 for more information.54 Integrated Identity Management using IBM Tivoli Security Solutions
  • 68. Assess and Plan Design Implement Life-Cycle Life-Cycle Life-Cycle Client Solution Solution Environment Outline Build Macro Strategy Pilot Design Micro Assessment Deployment Design Solution Approach Transition PlanningFigure 3-1 Implementation life-cycleAssessment and planning life-cycleThere are five phases in the assessment and planning life-cycle: Client environment Strategy Assessment Solution approach Transition planningClient environmentThe purpose of this phase is to collect the relevant data about the organization’sbusiness and IT environment that are required to assess and plan both currentand future identity management solutions.The organization’s business and IT environment is examined to determine whatidentity related information exists that needs to be managed: The business processes and services, and the roles and responsibilities that require business identity information, are described. Chapter 3. Applying the reference architecture 55
  • 69. The IT systems and applications used in processes and services that require IT identity information are described. The data stores from which these processes and services, as well as systems and applications, draw business and IT identity information, are identified and their data structure described. The current identity management infrastructure is described, and the administrative data stores used to manage administrative identity information are identified and their data structure described. The phase concludes by establishing the strategic business drivers and plans that will influence the identity management strategy. Strategy The purpose of this phase is to define the identity management strategy. This strategy includes: A statement of direction Identification of the required core identity management capabilities Principles that will guide the selection of solution approaches that combine capabilities The strategy provides an integrated view of the organization as a whole, but must also account for differences across the organization’s various business areas and IT systems. Assessment This phase has three purposes: To assess the organization’s current identity management solution, in terms of business process, the organization, data, and technology architecture To identify issues, focus areas, and recommendations for improvements To determine how current capabilities align with the formulated strategy and assess any gaps Assessment of both organizational capability and financial aspects of the identity management solution is undertaken, including: An overall assessment of the state of the administration processes, the organization, the infrastructure, and the data An assessment of key issues A financial assessment of the key cost drivers An identification of priority areas56 Integrated Identity Management using IBM Tivoli Security Solutions
  • 70. The capability assessment identifies the areas where the current environment isunable to support the identity management strategy and also examined to findinhibitors to change. Known issues can help to identify these areas. Theassessment is performed at an enterprise-wide level and may find, for example,that an investment in tools is planned, but the administration organization is insuch a state that it will be unable to support the tools.The financial assessment will identify areas where substantial benefits can beobtained, as the cost structure is such that a considerable return of investmentmay be achieved.The capability and financial assessment, along with the business drivers and thebusiness and IT strategy, will identify priority areas.Solution approachThe purpose of this phase is to determine the solution approach and to performan initial cost benefit analysis.Defining an overall approach is the next step in establishing a road map forimplementing enterprise-wide identity management. Once the approach hasbeen defined, a preliminary cost benefit analysis can be made that will furtherprioritize the initial set of focus areas that were identified in the Assessmentphase.The organizations that are likely to be impacted by the solution approach shouldbe informed about any plans considered at during the phase. This createsawareness, provides early feedback and enhances stakeholder commitment.Transition planningThe purpose of this phase is to plan the transition towards an enterprise-wideidentity management solution. Transition planning first produces a transitionstrategy and then develops a road map for implementing the strategy.The strategy establishes various transition approaches. For each approach therisks are evaluated, priorities determined based upon risk, business priorities,and cost/benefit ratios defined. A business case may be developed to justifyinitial approaches if required.The road map establishes dependencies between related areas, and the highlevel work streams are identified and prioritized. Finally, the detailed scope isdefined for the first project(s). Chapter 3. Applying the reference architecture 57
  • 71. Design life-cycle The design life-cycle has three phases: Solution outline Macro design Micro design Solution outline The purpose of this phase is to develop the conceptual level of solution design that meets the requirements and scope developed in earlier phases. This outline design includes any required business process or organizational changes, as well as the technology and data architecture. Key documents produced during this phase include the architectural overviews and high-level physical models. This phase should either develop design principles to be used as a starting point for the design, or reuse the principles, policies, and guidelines developed during the strategy phase of the assessment and planning life-cycle. The intent of this phase’s activities is to produce a design that is vendor agnostic. During the phase the processes are designed, and/or a high-level organization structure is produced. This design should provide a level of detail sufficient to issue an RFI (request for information) to product vendors if the organization so chooses. Once the specified level design is accepted by the client, the engagement may proceed to the next phase. Note: The Integrated Identity Management Reference Architecture, shown in Figure 1-2 on page 10, should be used as the starting point for design activities in this phase. The documentation produced during this phase will outline the business process and organizational changes needed to support the proposed identity management solution, the required technology and data components, and general items such as educational materials. Macro design The primary purpose of this phase is to define the criteria that will be used to select the infrastructure products that will be used to implement the solution. This includes capturing key functional and non-functional requirements, assessing the existing identity management infrastructure, and optionally preparing an RFI to issue to product vendors. Another important activity in this phase is the definition of a test strategy and high level test scenarios.58 Integrated Identity Management using IBM Tivoli Security Solutions
  • 72. Micro designThis phase creates the detailed design and implementation plans required todeploy the integrated identity management solution. Detailed architecturaldocuments are developed in this phase, and if business process ororganizational changes are being implemented, detailed workflows, jobdescriptions, measurements, and reports are also defined. All documentation isproduced at a level of detail that is sufficient to implement the solution. Thistypically includes the selection of vendors and products to apply to the specifieddesign and also the details required to procure equipment and budget for theimplementation stage. It should also produce physical design details, such asfloor plans, rack layouts, power requirements, and so on.At the conclusion of the micro design, a design review is conducted with allstakeholders in order to progress to the next stage of the project.Implementation life-cycleThe implementation life-cycle has three phases: Solution build Pilot DeploymentSolution buildThe purpose of this phase is to develop detailed configurations for the identitymanagement solution based on the design specified in the preceding stages ofthe life-cycle.The solution build will be performed in a development and test environment. Thisis a limited scale environment that is representative for production but does notinterfere with the actual production environment. During this phase installationand configuration, scripts or procedures are developed, detailed product and toolconfigurations are built, and required educational materials and otherdocumentation is prepared. This phase also establishes the supportingprocesses and organizational changes required by the solution.PilotThe pilot phase validates the systems and implementation procedures in alimited scope production environment. In the case of a network this may be asingle site, single floor in a building, or subset of the production environment. Thesame would hold for servers or workstations. The main idea is to plan a pilotimplementation that will test new design and implementation procedures, anduser training in a production environment. The selection process for the targetenvironment should take into consideration the scope of the test and that enoughvariety exists to ensure that all aspects of the design are tested prior to theproduction deployment. During this phase, any required adjustments are made toeither the implementation procedures or the design. Chapter 3. Applying the reference architecture 59
  • 73. This phase, the ultimate test of the design and development activities, implements the end-to-end identity management solution in a portion of the clients production environment. Validation of tools, data, measurement, documentation, and staffing levels are all completed during this phase. Deployment The purpose of the deployment phase is to fully implement the new design in the production environment. This phase uses the results of the pilot deployment to create an enterprise-wide rollout plan. The plan will be done only at the high level; a more detailed plan must be created as the first step in the actual deployment. At the commencement of the phase, any outstanding equipment procurement is finalized. The metrics developed in the solution build phase are used to measure the success of the implementation as it proceeds. If projections were made during the design engagement, measurements are also taken to test their accuracy. Towards the end of the phase, the operations and support staff receive any required training prior to the formal production hand over. At the completion of this phase, the enterprise has a fully functional and documented production environment based on the new design.3.1.2 Requirements analysis This section provides an overview of the key issues that must be addressed through the requirements analysis for the integrated identity management solution. The different aspects of the solution are closely related, but also have unique qualities that are best considered separately. Access management The purpose of the access management solution is to enforce the enterprise’s security policies that control access to the services provided by both IT applications and infrastructure. The access management solution provides data and component protection by implementing mechanisms for identification, authentication, and authorization for component access. Access management functionality must be built into components throughout the end-to-end solution. The task of incorporating access management functionality into the network, application, middleware, security, systems management, and infrastructure is a process that must address both business and technical requirements.60 Integrated Identity Management using IBM Tivoli Security Solutions
  • 74. Typical business requirements may include these considerations: It is necessary to eliminate the need for users to authenticate each time they access a new system within the same session, since this negatively impacts both customer and employee satisfaction. The enterprise’s Web presence has expanded significantly and requires increasingly sophisticated security management. Security policies must be consistently applied across the business, either due to corporate directives or legislative requirements. Controlling the costs of security management is a priority. A solution is needed for managing the business risks associated with security compromises from both internal and external sources.Similarly, technical requirements may include these considerations: Access management must be applied independently of application logic. A central point for access management is needed. Authorization policy management and enforcement mechanisms must be consistent across platforms. Exposure to potential attack must be minimized. Audit trails must be maintained for all access.Single sign-on (SSO) is typically seen as one of the key benefits of an accessmanagement solution, and is also one of the most frequently misunderstoodaccess management concepts. Key issues in developing SSO requirementsinclude these considerations: Stakeholder education: Stakeholders frequently request specific SSO features without understanding the business or technical consequences of implementing those features. Applications and platforms: The applications and associated technology platforms that must be integrated into the SSO environment, and any constraints imposed by them, must be considered. SSO buy-in: The organizational structure that exists around the applications and infrastructure needs to be brought into the SSO environment. Have all of the application owners and other stakeholders bought into the SSO vision?Other, more general issues to consider include these considerations: Implementation: How to implement requirements that cannot be met by the out-of-the-box access management infrastructure raises another question. Often the most expedient solution is to identity an alternative requirement that will meet the same business objectives but is more easily implemented. Chapter 3. Applying the reference architecture 61
  • 75. Compatibility of standards: Compatibility with the enterprise’s existing technology and security standards is needed. For example, WebSEAL changes the format of URLs, which may present a problem in some environments. Delegated administration: Different groups and individuals will typically be responsible for maintaining security policies for the infrastructure and specific applications. Security processes: Any internal or external security certification processes or reviews that must be completed before the solution is deployed. Non-functional requirements: These are especially important to the access management solutions developed, since the solution will affect the user’s experience of many applications. Tip: Many organizations define performance requirements such as this one: The application login process must complete in less than five seconds. To meet such requirements, both the access management infrastructure and the application components involved in the login process must perform acceptably. When performance issues arise, the access management infrastructure is usually assumed to be the source of the problem by default. It is often helpful to define performance reporting requirements that will clearly differentiate between the processing time taken by the access management infrastructure and the time taken by the application. Tivoli Access Manager deployments can typically be categorized as belonging to one or more common solution types. Understanding the solution type for a particular situation is the key to making appropriate architectural and implementation decisions. The solution should be driven by the enterprise’s long-term strategy. The three most common solution types are described here: Purpose built application solutions: The characteristics of purpose built application solutions are: – Security for a specific, known set of applications – Customization focused on facilitating application use – Single site deployment – Scaled to match expected user/transaction load – Often a single user community These solutions require an understanding of the integration requirements of the specific applications involved. Extranet solutions: The characteristics of extranet solutions are: – Multiple application environments – Multiple site deployment62 Integrated Identity Management using IBM Tivoli Security Solutions
  • 76. – Multiple security domains – Scaled to match load of each extranet domain – Multiple, possibly overlapped user communities These solutions require an understanding of the nature of the business relationships in the extranet environment in addition to the integration requirements of specific applications. Enterprise solutions: The characteristics of enterprise solutions are: – Impact across the enterprise – Broad range of application environments – Multiple site deployments – Unified, enterprise scale security domain – Extensible to address evolving scalability requirements – Diverse user communities These solutions require an understanding of the enterprise’s business and technical requirements. With this solution, applications are integrated into the environment on an ongoing basis.This concludes the requirements analysis for the access management solution.For more detailed information, take a look at the IBM Redbook EnterpriseSecurity Architectures using Tivoli Security Solutions, SG24-6014-01. Let us nowtake a closer look at the identity management solution.Identity managementThe identity management solution comprises both business (or procedural) andtechnical (security subsystem-specific) functionality. An implementation will notjust involve installing identity management technology; there will be integrationwith existing business procedures and perhaps some business processre-engineering (BPR). Both technical (product-related) and business(process-related) skills are required in the assessment and planning stage, andthe solution design stage, of the implementation life-cycle.To deliver an effective identity management solution, the project team mustunderstand all identity processes involved in detail. For example: A new employee starts working for the enterprise. How is their identity information created? Is there an HR database involved? How is that connected to their salary and benefits? How does HR tie in with the IT department? How does that person get access to the applications they need to do their job?The list of existing identity related business processes can include: A person joining a company and being defined in the HR system A person getting accounts to access applications Chapter 3. Applying the reference architecture 63
  • 77. A person getting passwords to use the accounts A person changing departments with bulk account changes A person changing a role with subtle account changes A person changing a surname and impacting accounts A person changing passwords A person resigning and being marched out, requiring locking of accounts A person resigning, but their account needs to be accessed by others A password being reset by an administrator A locked account being unlocked An account being locked All accounts for a user being deleted A set of accounts being moved from one system to another An access control group being changed and impacting a number of users This list is not exhaustive, but indicates some of the business processes that will need to be reviewed during the assessment and planning stage, and the solution design stage, of the implementation life-cycle. Implementing an identity management solution sometimes involves designing a solution that complements the existing business processes; and at other times, significant business process re-engineering. Business drivers and project requirements dictate the level of business process re-engineering required. Adoption of any re-engineered processes must involve analysis of the impact of the solution on the following persons: The system owners: For an identity management solution, this will be the company executive (for example, the owners of the security policy) and the IT Security department. The system administrators: For an identity management solution, this will be the security administrators, help desk staff, and technical support. The system users: For an identity management solution, this will be everyone defined as IT users in an organization. Any changes to processes could potentially impact every person in a company. These changes may drive the implementation of an identity management solution (for example, reducing password-reset help desk calls by allowing users to change their own passwords). If there are to be changes to the processes, the project team need to be cognizant of the following considerations: Usability: Users of various skill levels may be using the solution, so the usability of the components must be appropriate to all levels of users. Documentation: Process changes impacting a large number of users will require greater documentation support than a change impacting a small team. This may include procedure documents, intranet pages, and online help.64 Integrated Identity Management using IBM Tivoli Security Solutions
  • 78. Education: As with documentation, if you are deploying significant changes to a large number of people, thought must be given to the education plan.Business process re-engineering methodologies will not be discussed in thisredbook. There are many books and Web sites that contain such information.The following IBM Redbooks may be of interest: Intra-Enterprise Business Process Management, SG24-6173 Business Process Re-engineering and Beyond, SG24-2590In summary, the business and technical requirements that should be captured aspart of the overall analysis effort include the following areas: User management procedures: The procedures for managing users, who manages users, and what is required of the solution for managing users. Password management procedures: The procedures for managing account passwords, who manages passwords, and what is required of the solution for managing passwords. Access control management procedures: The procedures for managing access control, who manages access control definition, and what is required of the solution for managing access control. Security policy: What the corporate security policy defines for users, accounts, passwords, and access control. Target systems: The current system environment (including operating systems, databases, applications, the network, firewalls, physical location, and access control) and the system requirements of the solution. Interfaces: The interfaces to the current identity management mechanisms and procedures and the integration requirements of the solution. Auditing and reporting procedures: The procedures for auditing and reporting, who is involved in the auditing and reporting of users and their access, the audit requirements for the solution, and the reporting requirements for the solution. Technical requirements: The other technical requirements for the solution, such as availability and recovery.Capturing these requirements normally involves a series of interviews andworkshops with the people and teams involved in identity management. Thismay include the IT executive, security management/administration team,operations, help desk, key technical teams (such as system administrators) anyapplication development teams and business managers involved in the project. Chapter 3. Applying the reference architecture 65
  • 79. Tip: Interviewing end users or performing usability assessments can often provide additional insights into the current and proposed solution that will enhance user acceptance of the integrated identity management solution. The combination of these interviews and workshops will develop a picture of how the system currently works and how it could be improved. The project owners should drive the requirements for the proposed system, although others may contribute to an understanding of the need for the requirements. This concludes the requirements analysis for the identity management solution. For more detailed information take a look at the IBM Redbook Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996. Let us next take a closer look at the privacy management solution. Privacy management The privacy management solution will enable the enforcement and compliance auditing of the enterprise’s privacy policy. The privacy policy defines who within the enterprise can access Personally Identifiable Information (PII), what they can do with it, and any additional conditions on its use2. If this policy doesn’t already exist, it must be defined before further requirements analysis can be undertaken. The privacy policy must define the following data types for the enterprise: PII data types: This is an enterprise-level view of the data types stored within all enterprise systems — it is not specific to any one application. PII data types also define a common, consistent nomenclature for the same data types held in different applications under different names. Examples include bank account details, phone numbers, and home addresses. Sensitive data types: For many countries, privacy legislation defines a special class of PII data that is a high priority target for privacy enforcement3. Examples include health/disability/medical information, criminal records, and trade union membership. Purposes: These are the different purposes that the same PII data may be used for. For example, a customer’s contact details may be used for delivering products, contact in relation to the operation of accounts, and marketing4. Data users: These are the different roles held by employees who may access PII data. Examples include managers, customer contact center, and marketing staff. 2 For example, the bank may be able to market credit products to adults, but not children. In this case the condition is based upon the age of the account holder. 3 Privacy legislation often defines heavier penalties for mishandling of sensitive data, as compared to other types of PII data. 4 Privacy legislation often differentiates between e-mail, postal and telephone marketing.66 Integrated Identity Management using IBM Tivoli Security Solutions
  • 80. Conditions: These are additional constraints placed upon the use of PII data, such as the age of the data subject, and whether they have opted in, or out of, specific PII data purposes. Note: The roles defined for PII data users should align with the roles defined by the identity analysis activities described in “Identity management” on page 63. This is necessary to deliver an effective integrated identity management solution. Directory integration is another key analysis topic that is closely related to identity management. Each of the roles defined in the enterprise privacy policy must be mapped to groups within the enterprise’s user registries.Application Classification, also known as PII Discovery, is the principal privacyanalysis activity. Its goals are to identity applications that access PII data, andalso the optimal order in which to privacy enable these applications. Typicalquestions asked when classifying an application include: Does the application use PII data as defined by the enterprise privacy policy? Is an out-of-the-box privacy monitor available? – Be sure to confirm support for the specific product version, platform, and so on. If an out-of-the-box privacy monitor is not available: – How complex is the integration expected to be? – How many applications would reuse the same custom privacy monitor? What is the application’s priority, based on organizational objectives?Common examples of how an organization may choose to prioritize applicationsfor privacy enablement include: A short, simple pilot, possibly focusing on clusters of applications. Completing the easiest implementations first, to quickly deliver tangible benefits and develop in-house technical expertise. Realizing the greatest business value first; for example, if the majority of PII data may be held in mainframe systems, then completing these systems firstFinally, requirements analysis must determine what mode of operation will beused, based on business objectives. The three available modes are: Audit only: Every attempt to access PII data is allowed and logged, regardless of the privacy policy. Audit and conformance check: Every attempt to access PII data is allowed and logged, with exceptions to the privacy policy noted. Chapter 3. Applying the reference architecture 67
  • 81. Enforcement: Every attempt to access PII data is logged, and only those that comply with the privacy policy are allowed. Note: This is a key decision that influences the privacy monitor architecture and implementation. This concludes the requirements analysis for the privacy management solution. For more detailed information, refer to the IBM Redbook, IBM Tivoli Privacy Manager Solution Design and Best Practices, SG24-6999. Let us now take a closer look at the risk management solution. Risk management The goal of an enterprise-wide risk management strategy is to manage the risks associated with security incidents by continuously analyzing potential security incidents using event data captured from all components within the enterprise’s IT infrastructure. Correlating data captured from a wide variety of disparate sources is a core function of the integrated identity management solution: The audit flow structure integrates event data from the integrated identity management components. The components involved are part of the identity, privacy, and access management solutions, and also the underlying infrastructure components such as firewalls, operating systems, application servers, and HTTP servers. The goal is to be able to identify actual threats and attacks, and finally define actions to be taken, either automatically or by manual intervention. Identifying actual threats within the (often huge) stream of event data generated by infrastructure components will make the environment more secure and more manageable. Predefined actions will allow for quick and consistent handling of situations and increase the quality of service to users. Some key issues that the risk management component of the integrated identity management solution must address include the following possibilities: Unauthorized attempts to access the enterprise’s resources. Unauthorized access to the enterprise’s resources, resulting in the exposure of enterprise information assets or sensitive data. Possible attempts to misappropriate components of the integrated identity management solution and gain unauthorized administrative rights. Correlating suspicious activity observed within the low level IT infrastructure and the integrated identity management solution components.68 Integrated Identity Management using IBM Tivoli Security Solutions
  • 82. The usefulness of the risk management components depends, to a large extent, on good planning and appreciation of the roles of topics, such as these: Networking, such as the number of geographic locations, network connectivity between locations, firewall positions and rules. The use of distributed correlation servers as a load-balancing mechanism for correlation when the event volume is high. The use of summarization rules for events received from specific types of sensors. This greatly reduces traffic that flows into correlation servers. The requirement analysis must refine the scope of these topics in order to determine what level of effort is required to integrate the risk management solution into the enterprise’s business processes, organizational structure and IT infrastructure. Note: Risk management, in this context, refers to a systemic method by which information collected from different security points can be consolidated and correlated to obtain a precise and concise picture of the security risks that exist at any point in time and take the necessary action. For an more information on risk management topics, see the IBM Redbook Centralized Risk Management using Tivoli Risk Manager 4.2, SG 24-6095.3.1.3 Incremental delivery strategy This section provides an overview of how the “Implementation life-cycle” on page 59 can be decomposed into smaller, more manageable units of work. Each unit of work is appropriately sized for a single delivery team, while still delivering tangible business value. In many cases the overall delivery timeline can be reduced by using multiple teams to complete units of work in parallel. The components are closely related, but also have unique characteristics. In many enterprises different organizations are responsible for the different components. Given these factors, it is appropriate to deliver the components in separate projects, however, appropriate architectural governance must established to maintain the integrity of the integrated solution. Access management Enterprise-wide access management solutions are often best deployed in an incremental, iterative approach, as shown in Figure 3-2. Chapter 3. Applying the reference architecture 69
  • 83. Requirements Deploy a Single Deploy Analysis/ Site Applications Micro Design Implement Multi Enhance a Site Failover Single Site Figure 3-2 Access management delivery strategy This delivery strategy does not mandate a particular sequencing of phases after the initial infrastructure deployment. Every enterprise’s objectives, priorities and IT environment is different, and the optimal delivery strategy will be determined during the design lifecycle as described on page 58. Each delivery phase can be followed by any other phase, or another iteration of the same phase. The phases are described below. Deploy a single site This phase deploys access management infrastructure to a single site. Each iteration of the phase may occur in a different region of the world and have to comply with different company or government processes. The scope of this phase includes: Planning infrastructure deployment Procuring infrastructure components Deploying infrastructure components Configuring the site to support existing applications The expected outcomes of this phase are as follows: An additional site is online and able to service access management requests, potentially for the whole enterprise’s IT infrastructure. The benefits delivered by this phase include these: For the initial site, the ability to deploy applications that will leverage the access management infrastructure70 Integrated Identity Management using IBM Tivoli Security Solutions
  • 84. For subsequent sites, the ability to improve application response times and infrastructure availabilityDeploy applicationsThis phase deploys one or more applications that have been built to leverage theaccess management solution.The scope of this phase includes: Deploying the application(s) Configuring all current access management sites to support the applications Exception handling for applications that do not comply with the access management standardsThe expected outcomes of this phase are as follows: New applications are available for use and secured using the centralized access management infrastructure.The benefits delivered by this phase are essentially the benefits of centralizedaccess management and include: Reduced application development costs/time frames Flexible, consistent application security policy enforcement Single sign-on — improved user experience, simplified identity administrationImplement multi-site fail-overIn this phase, existing sites are linked together to enable fail-over support. Thisimproves overall infrastructure availability.Enhance a single siteAn enterprise’s access management requirements naturally evolve over time.Some changes are relatively simple, such as increasing the number of supportedusers. Other changes are more complex, such as modifying technical integrationstandards. In either case, existing sites may need to be enhanced to meet thesechanging requirements. Chapter 3. Applying the reference architecture 71
  • 85. Identity management This section describes an incremental approach to delivering an identity management solution.5 It decomposes the overall implementation stage into distinct phases and defines the scope, outcomes and benefits of each phase. The rationale behind this delivery strategy is to restrict each phase to manageable chunks, while still delivering tangible business value. This enables the enterprise to reach key milestones as early as possible and also become self reliant as soon as possible. Let us take a closer look at the identity management delivery strategy depicted in Figure 3-3. Requirements Analysis/Micro Design Phase 1 Phase 2 Phase 3 Phase 4 Foundation & Automate Phase 5 Roles and Policies Custom Password provisioning Maturity Defined - RBAC Agents Management of standard accounts Repeat password management and account provisioning for new applications and infrastructure Figure 3-3 Identity management delivery strategy Typically, Phase 1 and 2 cover infrastructure accounts. These are accounts in which the majority of the user base is represented (such as Windows, UNIX, and z/OS RACF accounts). Once the initial iteration of Phases 1 and 2 is complete, they can be combined and repeated to bring other standard systems under centralized identity management. This can be a parallel activity, so over a relatively short period of time, all standard systems come under centralized control. Phase 3 is dependent upon the business definition of roles and policies. It focuses on business unit and role based provisioning. Lessons learned enable refinement and replication across other business units. This phase is the most complex and far reaching, and ultimately has the highest long term rewards. Phase 4 brings in those systems which require a custom agent and completes the solution with all agreed systems/applications under centralized identity management. Phase 5 marks the total integration of centralized identity management into the enterprise’s business processes and IT environment. 5 IBM employees can obtain full details of this strategy by accessing the TSS Xpertise library asset “Identity Manager (TIM) - Services and Project Planning documentation”. Work product templates are also provided.72 Integrated Identity Management using IBM Tivoli Security Solutions
  • 86. Once the foundation Phase 1 is complete, if business needs require, it ispossible to change the focus and content, and to commence a project phase todeliver any element of the subsequent phases. Certain prerequisites may berequired, but none that would disallow the activity; although it may extend overallimplementation time and costs.Phase 1: Foundation and password managementThe first phase focuses on delivering high visibility, high value benefits quicklyand with minimal impact on existing systems. These benefits are typicallyrealized by implementing self-service password reset and managing orphanedaccounts.The scope of phase 1 includes: Password management Out-of-the-box supported applications/systems Baseline reporting Covers large or small user target HR feed established Orphan account control Single action to close/suspend user accountsThe expected outcomes of phase 1 are: Password management: synchronization, reset and self-service across managed platforms Organizational tree established Eliminate risks from backdoor access Necessary reporting availableThe benefits delivered by phase 1 include: High visibility of the solution Large benefits gained among the end-users and in the central user administration and support desk Compact delivery timePhase 2: Automatic provisioning for infrastructure accountsThe second phase automates the provisioning process for standard accountsand resources.The scope of phase 2 includes: Automatic provisioning of standard accounts and workflow Consistent GUI for administration Consistent account creation Full audit trail Chapter 3. Applying the reference architecture 73
  • 87. Simple workflow introduced Foundations for Role Based Access Control (RBAC) The expected outcomes of phase 2 are: User registration is automatically updated Reduced administration Necessary reporting for external parties is available Consolidation of users Organizational structure HR feed creating new users The benefits delivered by phase 2 include: High visibility of the solution Large benefits gained among the end-users and in the central user administration Improved security and potentially reduced user-based license costs Phase 3: RBAC for out-of-the-box services and applications The third phase focuses on implementing Role Based Access Control. By this time the analysis of business requirements should be complete and the business roles mapped to access rights, and security policies defined. These roles, rights, and policies are used to deliver automatic role driven provisioning and deprovisioning of access rights. The scope of phase 3 includes: Role-based account management Rule-set for automated creation and deletion of user accounts Rule-set for organizational changes Full workflow for account management Focused on small community The expected outcomes of phase 3 are: HR feed for managing user accounts - high demands on data quality Organizational chart may need refining Administration by role management introduced Requires input and buy-in from application/system owners The benefits delivered by phase 3 include: Time consuming tasks replaced by automation Large benefits gained by the application owners Delegated administration possible Improved control from detailed reporting74 Integrated Identity Management using IBM Tivoli Security Solutions
  • 88. Phase 4: Develop custom agentsThe fourth phase continues the work of phases two and three with non-standardapplications account types that require custom integration.The scope of phase 4 includes: Custom agents and extensions Custom developed agent Start program to extend RBAC to cover all companies Elimination of all administration of user accounts outside of the identity management solution. Workflow supporting authorization managementThe expected outcomes of phase 4 are: Templates for later roll-out established All significant applications coveredThe benefits delivered by phase 4 include: One interface for all user administration Scheduled re-organizations with shorter non-productive time for the end-user Fast activation and deactivation of users Time consuming tasks replaced by automationPhase 5: MaturityBy now, the initial deployment of the identity management solution is complete.The fifth phase covers the ongoing evolution of the identity management solutionas new business roles, applications, and infrastructure are added to the ITenvironment.The scope of phase 5 includes the following benefits: The enterprise is able to repeat new instances of agent installs and integrate into appropriate policies. The enterprise is able to self-maintain the solution to reflect changing business demands.The expected outcomes of phase 5 are: Role based access control fully enabled Only run-out applications excluded — if any Chapter 3. Applying the reference architecture 75
  • 89. At the completion of this phase, the organization can expect to realize the full potential of an identity management solution, such as: Easing compliance with security audits Consolidating control of the user management processes Eliminating inconsistencies from human error and management by mood6 Reducing training costs and education requirements Reducing help desk and overall administration costs Involving less people in day-to-day management Dividing work along organizational/departmental structures Improving response to user changes Leveraging user information in all business processes Alternative approaches The deployment strategy shown in Figure 3-3 on page 72 can be viewed as a bottom-up approach to implementing an integrated identity management solution. The same six phases can be recombined to form a top-down approach, as shown in Figure 3-4. Auto Provisioning and workflow for Foundation & standard Accounts Requirements Analysis/ Custom Password Maturity Micro Design Agents Management Roles and Policies Defined - RBAC Figure 3-4 Alternative identity management delivery strategy The two approaches have different advantages and disadvantages. The suitability of each approach for a particular deployment should be considered in the context of the organization’s environment. The advantages of choosing the bottom-up approach include these: User and business awareness of product and benefits are visible from and early stage. Many manual processes can be replaced by automation. Password management can be implemented for a large number of users. No development of agents required in phase 1. Broadens skills and understanding within your organization at the first phase. Eases the identity management processes gently into the business. 6 Management by mood refers to personal administrative favors or quick-and-dirty solutions that do not comply with any policy, for example, an administrator grants you root privileges just for one week because he knows you personally and trusts you.76 Integrated Identity Management using IBM Tivoli Security Solutions
  • 90. The disadvantages of the bottom-up approach include these: Possible need for alteration of organizational structure at a later phase Medium to high impact on system owners and so on; individual cooperation required to some extent Driven by infrastructure, not businessThe advantages of choosing the top-down approach include: Focused use of resources from the individual targets First implementation becoming showcase of what can be done Deep coverage of an application once implementation has finished Low impact on operation and maintenance resourcesWhile the disadvantages of the top-down approach include: Limited coverage in the first phases, due to minimal percentages of user accounts managed Potentially custom agents will have to be developed at an early stage Minimal benefit to support an overall business Higher implementation costPrivacy managementThis section describes an incremental approach to delivering a privacymanagement solution as depicted in Figure 3-5. It decomposes the overallimplementation stage into distinct phases and defines the scope, outcomes andbenefits of each phase. The rationale behind this delivery strategy is to restricteach phase to manageable chunks, while still delivering tangible business value.This enables the enterprise to reach key milestones as early possible and alsobecome self reliant as soon as possible. Phase 2 Monitor Requirements Implementation Phase 1 Phase 4 Analysis/ Foundation Maturity Micro Design Phase 3 Privacy EnablementFigure 3-5 Privacy management delivery strategyPhase 1 delivers the infrastructure required to notify data subjects of theenterprise’s privacy policy and also to record their consent to having their PIIdata used in accordance with the policy. Notification and consent are typicalrequirements of privacy legislation. Consent is also typically required to meet theconditions associated with PII data use, such as a customer having to opt-in toreceive marketing material. Chapter 3. Applying the reference architecture 77
  • 91. Phases 2 and 3 can be run both iteratively and in parallel, depending upon how the applications have been classified and prioritized. Phase 2 is only required for application-types that cannot use an out-of-the-box privacy monitor. Each iteration of phase 2 delivers a privacy monitor that can be used for a specific type of application. Each iteration of phase 3 delivers a privacy enabled application. The exact sequencing and degree of parallelism will depend on the business objectives and capabilities of the organizations involved. Phase 4 marks the total integration of centralized privacy management into the enterprise’s business processes and IT environment. Phase 1: Foundation The first phase aims to establish the business processes and technical infrastructure required to disseminate information about the enterprise privacy policy, to classify and determine privacy relevant data, and also record the consent of data subjects and confirmation that employees who have access to PII data are aware of their obligations under the policy. This foundation is required both for legislative compliance and to provide the consent data needed in phase 3. The scope of phase 1 includes these activities: Classify and determine privacy relevant data that is processed with the enterprise. Develop methods to notify data subjects of the enterprise privacy policy. Develop methods to capture data subject’s consent to both the enterprise policy, and specific uses of PII data. Develop educational material for staff who must comply with the policy. Optionally, develop methods to record that employees understand and are committed to complying with the enterprise privacy policy. The expected outcomes of phase 1 are as follows: Knowledge exists about what data holds PII, where this data is stored, and which applications and mechanisms have access to this data. Data is captured that is needed to enforce the conditions of the privacy policy. Data subjects are aware of privacy policy. Staff are aware of their obligations under the policy. Optionally, the enterprise has a record of employee’s understanding and commitment to the policy.78 Integrated Identity Management using IBM Tivoli Security Solutions
  • 92. The benefits delivered by phase 1 include: Legislative compliance is maintained. Improved flexibility to use PII data; a policy that clearly defines the purposes for which data may be used may give subjects the confidence to opt-in to additional services. It maintains or enhances the enterprise’s brand perception. Employee training records may be useful in dealing with incidents where the privacy policy has been breached.Phase 2: Monitor implementationThe second phase is only required when there are application-types that must beprivacy enabled but are not supported by existing monitor implementations.Monitor implementation is discussed in detail in IBM Tivoli Privacy ManagerSolution Design and Best Practices, SG24-6999-00. Typically a custom monitorimplementation will be usable by all applications of the same technology type.The target application-types and sequencing of phase 2 iterations will bedetermined by priorities defined during requirements analysis.The scope of phase 2 is to implement an application type-specific privacymonitor. The expected outcome and benefit of this phase is that a newapplication type can be privacy enabled.Phase 3: Privacy-enablementEach iteration of the third phase privacy enables a single application. Thesequencing of iterations is determined during requirements analysis.The scope of phase 3 includes: Monitor integration7. Mapping application specific data types and intended use to the enterprise privacy policy. Application data types are mapped to enterprise PII types and conditions. Application purposes are mapped to enterprise purposes.The expected outcomes of phase 3 are: Detailed auditing of application data access The ability to enforce the enterprise privacy policyThe benefits delivered by phase 3 include: Regulatory compliance Visibility of employee compliance with corporate policies7 Integration may require monitor or application customization. Chapter 3. Applying the reference architecture 79
  • 93. In many cases, improved corporate visibility of which applications access specific types of corporate data. Maintain or enhance the enterprise’s brand perception. Phase 4: Maturity By now, the initial deployment of the privacy management solution is complete. The fourth phase covers the ongoing evolution of the privacy management solution as privacy policies evolve and new applications and infrastructure are added to the IT environment. The scope of phase 4 includes: The enterprise being able to repeat new instances of monitor creation/configuration and integrate into appropriate policies Able to self maintain the solution, including privacy policies, to reflect changing business demands. The expected outcomes of phase 4 are: Ongoing auditing of application data access and ability to enforce the enterprise privacy policy Risk management This section describes an incremental approach to delivering a risk management solution8 as part of a broader integrated identity management solution, depicted in Figure 3-6. It decomposes the overall implementation stage into distinct phases and defines the scope, outcomes and benefits of each phase. The rationale behind this delivery strategy is to restrict each phase to manageable chunks, while still delivering tangible business value. This enables the enterprise to reach key milestones as early as early possible and also become self reliant as soon as possible. Phase 3 Phase 4 IM Adapter Centralized Risk Requirements Implementation Management Phase 1 Phase 5 Analysis/ Foundation Maturity Micro Design Phase 2 - Tuning Figure 3-6 Risk management delivery strategy 8 The complete methodology can be viewed by IBM employees by visiting the intranet Web site http://method.ibm.com and following the links to the GSMethod Intrusion Alert Management Design and Implementation engagement model.80 Integrated Identity Management using IBM Tivoli Security Solutions
  • 94. Phase 1 delivers the infrastructure required to capture all audit and securityevents.The goal of phase 2 is to add value to the raw events captured by theinfrastructure delivered in phase 1. This phase is critical to delivering an efficientrisk management solution. Phase 2 can begin before the end of phase 1 andcontinue to the end of phase 4. Tip: Refer to Chapter 7 in the IBM Redbook Centralized Risk Management using Tivoli Risk Manager 4.2, SG 24-6095 for more information on performance tuning for IBM Tivoli Risk Manager 4.2.Phase 3 can commence at the completion of phase 1. In this phase the identitymanagement components are integrated with the risk management components.Phase 4 can run in parallel with phase 2 and 3. It addresses the operational andorganizational aspects of the centralized risk management solution. Phase 4 isdependent upon on the definition of security processes, procedures forsupporting and acting inside the enterprise.Phase 5 marks the total integration of identity management components into theenterprise’s centralized risk management solution.Phase 1: FoundationThe goal of this phase is to deploy risk management components throughout theenterprise’s IT infrastructure components and begin capturing security eventdata. The configuration of what data is captured and how it is used will be refinedin subsequent phases.This phase provides a foundation for risk management capability that will befurther developed in subsequent phases.Phase 2: TuningThe goal of this phase is to increase the capability of the risk managementsolution by providing qualified information to security administrators and at thesame time protect the infrastructure from the huge number of flow events anddegradation of real-time supervision. These features are critical in largeenvironments.The scope of phase 2 includes: Base tuning; events filtered at the sensor or adapter level Advanced tuning; using IBM Tivoli Risk Manager advanced functions Specific correlation; new correlation rules added to provide new qualified incidents Chapter 3. Applying the reference architecture 81
  • 95. The expected outcomes of phase 2 are: Optimization of the event flow, aiming for maximum scalability Optimization of correlation, reducing the amount of data presented on the console while preserving essential information The main benefit delivered by phase 2 is the optimization of the raw events processes by the risk management solution to produce security event flows. Phase 3: Identity management adapter integration In this phase, the identity and privacy management adapters are deployed. The main outcomes for this phase include: Integration of the identity management components into the global security monitoring perimeter The ability to develop during phase 4 some management processes dedicated to identity management monitoring Phase 4: Centralized risk management This phase delivers the centralized risk management solution by integrating the components deployed during previous phases. After optimization of the security event flow, security administrators are presented with qualified security incidents on the security console. The benefits delivered by this phase include broad and qualified visibility of all system activities by the team responsible for security monitoring. Phase 5: Maturity By now, the initial deployment of the risk management solution (including identity management components) is complete. This phase will cover the ongoing evolution of the risk management solution as new components of infrastructure and applications are introduced, or security and audit policies change. The expected outcomes of phase 5 include: Auditing of the infrastructure, including identity management components The ability to enforce security policy and trigger actions on specific and qualified security incidents The benefits delivered by phase 5 include: Regulatory and audit compliance Maintaining the enterprise’s security level via the qualified visibility of system activity available to security administrators Management reporting82 Integrated Identity Management using IBM Tivoli Security Solutions
  • 96. 3.2 WBI solution design This section describes how an enterprise such as WBI might implement the reference architecture shown in Figure 1-2 on page 10. It continues with the WBI scenario described in Chapter 2, “What Bank International” on page 17. The solution addresses all of WBI’s requirements, as described in 2.4, “Business requirements” on page 31 and 2.5, “Functional requirements” on page 33.3.2.1 Solution overview This section provides an overview of WBI’s integrated identity management solution, and highlights how the reference architecture shown in Figure 1-2 on page 10 can be applied to an actual customer scenario. Figure 3-7 shows the mapping between the reference architecture and the component model described in 3.2.2, “Component model” on page 87. Access Management Policy Server Policy Database Web Portal Manager Provisioning Authentication / Password Policy Enforcement Self Help, Help Desk, Del. Admin Directory Server Gateway Identity Management App. Users TIM API Identity Manager Server Provisioning User Registries Reverse Proxy Identity Manager Agents Authorization API Self Care/ Identity Manager DB TIM API Registration User, Group lookup Applications Privacy Privacy Management Enforcement Privacy Server Provisinoing HTTP Server Privacy Montiors WS App/Portal Server Mail Server LOB Applications Security Enforcement Meta Directory Risk Manager Server Secure Directory Integrator Risk Manager Clients Data Access Managed Targets Enterprise Data Enterprise SystemsFigure 3-7 WBI architecture overview Each of the major functional areas is described in the following sections. Chapter 3. Applying the reference architecture 83
  • 97. Access Management Access management components provide a mechanism to define and enforce access control policies that are applied to all application and infrastructure services within the enterprise. The key Access Management components are: Policy Server The Policy Server provides centralized access control policy maintenance and enforcement for all application and infrastructure services. Policy Database The Policy Database provides secure storage for the security policies that are utilized by other Access Management and Enforcement Gateway components. Web Portal Manager The Web Portal Manager provides an administrative interface for maintaining the security policies and infrastructure configuration. These components are described in further detail in “Access Management components” on page 91. Enforcement Gateway Enforcement Gateway components provide infrastructure and application level mechanisms to enforce the enterprise’s access control policies. The key Enforcement Gateway components are: Reverse Proxy The Reverse Proxy mediates all end user access to Web-enabled applications, providing authentication and coarse grained authorization services. Authorization API The Authorization API allows applications to leverage the central access management infrastructure when implementing fine grained authorization services. These components are described in further detail in “Access Management components” on page 91.84 Integrated Identity Management using IBM Tivoli Security Solutions
  • 98. ApplicationsApplication components provide the infrastructure to required to run theenterprise’s line of business applications, as well as the applications themselves.The key Application components are:HTTP Server The HTTP Server serves static Web content and also dynamic Web content generated by other Application components.WebSphere Application/Portal The WebSphere Application Server provides a runtime environment for J2EE compliant applications. The WebSphere Portal is one such J2EE application. WebSphere Portal provides a personalized, collaborative work space that allows employees and customers to efficiently complete tasks that involve multiple applications.Mail Server The Mail Server provides Web-enabled access to E-mail and calendaring tools for all employees.Line of Business Applications These are the applications used by employees and customers during the day to day operation of the enterprise’s business activities.These components are described in further detail in “Application components” onpage 89.Security EnforcementSecurity Enforcement components provide a mechanism to monitor all activitywithin the processing environment in real time. Suspicious activity is identifiedautomatically and appropriate corrective action taken. The key SecurityEnforcement components are:Risk Manager Server The Risk Manager Server provides a centralized mechanism for monitoring system activity and responding to potential security incidents in real time.Risk Manager Clients Risk Manager Clients are deployed throughout the enterprise’s IT infrastructure and applications to capture information about system activity for processing by the server.These components are described in further detail in “Audit components” onpage 95. Chapter 3. Applying the reference architecture 85
  • 99. Identity Management Identity Management components provide centralized identity administration functions that can improve an enterprise’s ability to enforce a consistent policy across all IT resources, and reduce operational costs by automating administrative tasks. The key Identity Management components are: Identity Manager Server The Identity Manager Server implements centralized, automated identity management workflows across all of an enterprise’s target systems. Identity Manager Agents The Identity Manager Agents provide integration between the server and enterprise resources. Agents act as a secure, bi-directional conduit for identity administrative updates originating in both the Identity Manager Server and the target resource. Identity Manager Database The Identity Manager Database stores the configuration and security policy information used by the Identity Manager Server. These components are described in further detail in “Identity Management components” on page 97. Privacy Management Privacy Management components provide centralized privacy policy enforcement and compliance auditing. They allow an enterprise’s privacy policy to be consistently enforced and across multiple applications, with minimal changes to existing applications. The key Privacy Management components are: Privacy Server The Privacy Server enforces the enterprise’s privacy policy and also audits privacy-enabled application’s use of personally identifiable information. Privacy Monitor Privacy Monitors are deployed within applications to enforce the enterprise’s privacy policy. These components are described in further detail in “Privacy Management components” on page 101.86 Integrated Identity Management using IBM Tivoli Security Solutions
  • 100. Meta Directory The Meta Directory component provides a mechanism to efficiently synchronize the contents of multiple data stores, such as user registries. Directory Integrator will be used to provide this functionality, and is described in further detail in “Identity Management components” on page 97. Managed Targets Managed Targets are the enterprise systems that leverage the identity management solution by integrating into the automated identity management workflows such as account provisioning and password synchronization. This component is described in further detail in “Application components” on page 89. Directory Server The Directory Server hosts user registries, which are centralized stores of user account information, such as user names, passwords and group associations. This component is described in further detail in “Identity Management components” on page 97.3.2.2 Component model The component model describes the collection of components that interact to deliver WBI’s integrated identity management solution. It documents each component’s: Responsibilities Realization Relationship to the reference architecture as shown in Figure 1-2 on page 10 Interactions with other components The model is shown in Figure 3-8 and distinguishes between the existing components that were used to meet the requirements described in 2.2.2, “Recently implemented e-business initiative” on page 25, and the new components that will deliver the integrated identity management solution. Chapter 3. Applying the reference architecture 87
  • 101. Risk Risk Manager Manager Sensors Gateway Clients Risk RM AM HTTP Manager HTTP Client Adapter Web Portal Admin Server for AM Manager Client Proxy Reverse AM Policy IM AM Mail Server Policy Proxy Server Agent Server IM HTTP Server RM Lotus Notes WAS Web Replica Master Agent Plug-in IDS Policy Policy Database Database Self Reg WAS/WPS Replica Master Self Care Security User User Registry Registry LOB AM Applications Plug-in/API Enterprise WebSphere Privacy Directory Data/ Application/ Monitor Integrator Systems Portal Server IM Enterprise Agents Client IM Database RM Privacy Identity Adapter Manager Manager IM User for TPM Server Server Registry Application flow Access control flow Audit Flow Identity management flow Abbreviations: AM Access Manager Existing Components IM Identity Manager New Components RM Risk Manager (Current IT Infrastructure) IDS Intrusion Detection System Figure 3-8 Component model88 Integrated Identity Management using IBM Tivoli Security Solutions
  • 102. Application componentsThe following application components are part of the current IT infrastructure asdescribed in Chapter 2, “What Bank International” on page 17.For detailed information on Web application security, refer to the redbook IBMWebSphere V5.0 Security WebSphere Handbook Series, SG24-6573-00.Enterprise ClientThe Enterprise Client component represents all non-Web applicationcomponents used by intranet-based employees to access enterprise data andsystems, such as Visual Basic applications and terminal emulation programs.Enterprise Data and SystemsThe Enterprise Data and Systems components represent all of the non-Webbased IT applications and infrastructure within the enterprise, such as relationaldatabases, CICS® applications and file servers. Enterprise data and systemsprovide aspects of the database and managed target functionality defined in thereference architecture as shown in Figure 1-2 on page 10.Some enterprise data is accessed via Web-enabled applications that aresecured using the components described in “Access Management components”on page 91. Many enterprise data and systems are not Web-enabled, and areaccess directly via enterprise clients. These systems use their own AccessManagement components, which must be integrated into the overall IdentityManagement solution.HTTP ClientThe HTTP Client provides the user interface for Web-based application andstatic content. It is the component used by users, business partners andadministrators, as defined in the reference architecture shown in Figure 1-2 onpage 10, to submit requests to the enforcement gateway.The enterprise has standardized on Microsoft® Internet Explorer for allintranet-based HTTP Clients. Internet-based HTTP Clients cannot bestandardized, and multiple client implementations must be supported.HTTP ServerThe HTTP Server processes requests from HTTP clients. Requests for staticcontent, such as images, are serviced directly by the HTTP Server. Requests fordynamic content, such as J2EE application pages are handed off to theWebSphere Application Server Plug-In for processing. The HTTP Serverprovides application functionality as defined in the reference architecture shownin Figure 1-2 on page 10. It is implemented by IBM HTTP Server using binaryexecutables. Chapter 3. Applying the reference architecture 89
  • 103. Line-of-business applications Line-of-business applications are the set of J2EE applications used in the daily operation of the enterprise. Some applications are developed in house while others have been purchased and customized to meet the needs of the business. Each application has different security requirements — some are accessed by customers from the Internet, others by all employees or specific work groups. In most cases the J2EE applications provide a Web-enabled front end to existing enterprise systems and data. Mail Server The mail Server provides Web-enabled E-mail and calendaring access to employees. The mail Server provides application functionality as defined in the reference architecture shown in Figure 1-2 on page 10, but also includes dedicated Access Management components and a user registry that must be incorporated into the overall identity management solution. It is implemented by Lotus iNotes using binary executables. The Mail Server interacts with other components as follows: All end-user access to the Mail Server is mediated by the Reverse Proxy component. The Mail Server references the Replica User Registry for user authentication. Internal Access Management components exchange administrative updates with the Identity Management Server via the Identity Manager Lotus Notes® Agent. WebSphere Application Server Plug-in The WebSphere Application Server Plug-In provides the communications link between the HTTP Server and WebSphere Application/Portal Server. The plug-in provides application functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by WebSphere Application Server as a platform and an HTTP Server specific binary component that runs within the HTTP Server process. The Plug-In passes HTTP requests from the HTTP Server to WebSphere Application/Portal Server. WebSphere Application Server/Portal WebSphere Application Server/Portal provides the runtime environment for line-of-business and other J2EE applications. The server provides application functionality as defined in the reference architecture shown in Figure 1-2 on page 10. WebSphere Application Server is implemented as a collection of Java™ applications with some binary components. WebSphere Portal is a J2EE application that runs within WebSphere Application Server.90 Integrated Identity Management using IBM Tivoli Security Solutions
  • 104. WebSphere Application Server/Portal interacts with other components asfollows: Provides a runtime environment for J2EE applications, such as the Self Registration/self Care components. Hosts Access and Privacy Management components that enforce application-level security policies.Access Management componentsThe following Access Management components are part of the current ITinfrastructure as described in Chapter 2, “What Bank International” on page 17.For detailed information on these components, refer to the following redbooks: Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. IBM WebSphere V5.0 Security WebSphere Handbook Series, SG24-6573-00.Access Manager for WebSphere Application ServerThe Tivoli Access Manager for WebSphere Application Server plug-in integratesinto WebSphere Application Server and WebSphere Portal to replace their nativeauthorization functionality with Access Manager components. The plug-inprovides access management functionality, as defined in the referencearchitecture shown in Figure 1-2 on page 10. It is implemented by Tivoli AccessManager for e-business as a set of Java classes that run within the WebSphereApplication Server.The Access Manager for WebSphere Application Server plug-in/authorizationAPI interacts with other components as follows: The plug-in processes authorization calls made to the WebSphere Security Server and passes them on to the authorization API. The authorization API processes the request using locally cached copies of the Replica Policy Database and Replica User Registry. The authorization API generates audit logs of all authorization requests and decisions. These logs are processed by the Risk Manager Adapter for Access Manager component. Note: In versions of Access Manager for e-Business prior to 5.1, applications using the Java authorization API could not run in local cache mode and had to delegate all authorization decisions to a dedicated Authorization Server component, either running locally on the same machine as the WebSphere Application Server or remotely on a separate machine. Chapter 3. Applying the reference architecture 91
  • 105. Access Manager Policy Server The Tivoli Access Manager Policy Server maintains and replicates the policy database and also provides policy information about protected objects to resource managers such as the Reverse Proxy. The Policy Server provides access management functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Access Manager as a binary executable. The Policy Server interacts with other components as follows: Processes administrative updates from the Web Portal Manager, through a command line interface or an administration API. Processes incoming, and sends outgoing administrative updates to the Identity Manager Access Manager agent and/or Directory Integrator. Makes administrative changes to the Master Policy Database and Master User Registry. Replicates changes to the Master Policy Database to other Access Management components that host Replica Policy Databases. Generates audit logs of all protected object policy requests and administrative updates. These logs are processed by the Risk Manager Adapter for Access Manager component. Access Manager Web Portal Manager The Web Portal Manager provides a Web-based administrative interface to the Access Manager Policy Server/Database. The portal manager provides access management functionality, as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Access Manager as a J2EE application running within WebSphere Application Server.9 Note: The J2EE application is typically deployed within a trusted network security zone and not collocated with production J2EE applications. The Web Portal Manager interacts with other components as follows: Receive and process administrative requests from the HTTP Admin Client. Submit administrative updates to the Policy Server for processing. HTTP Admin Client The HTTP Admin Client is a standard Web browser, used by administrators in a trusted network zone to connect to the Access Manager Web Portal administrative interface. 9 BEA WebLogic Application Server is also supported.92 Integrated Identity Management using IBM Tivoli Security Solutions
  • 106. The enterprise has standardized on Microsoft Internet Explorer for allintranet-based HTTP clients.Master/replica policy databaseThe master and replica policy databases provide a high performance, highlysecure proprietary database that holds all access management related securitypolicies, such as rules, protected object policies, and access control lists. Thepolicy database provides access management functionality as defined in thereference architecture shown in Figure 1-2 on page 10. It is implemented byTivoli Access Manager using a flat file and in-memory cache.The master policy database is deployed in a secured network zone and providesread/write access for both access control and system administration tasks. Themaster policy database interacts with other components as follows: The Policy Server uses the database as its policy store. The database is replicated to the replica policy database component.The replica policy database is deployed in other network zones to provideread-only access to the policy information required by the authorization API,Proxy Policy Server, Authorization Server, and Reverse Proxy components.Reverse ProxyThe Reverse Proxy authenticates and authorizes all HTTP access to productionsystems, and also performs the password change self-care function. The proxyprovides enforcement gateway functionality as defined in the referencearchitecture shown in Figure 1-2 on page 10. It is implemented by Tivoli AccessManager for e-business WebSEAL, as a platform-specific binary executable.The Reverse Proxy has the following interactions with other components: HTTP clients connect to the proxy. If the end user is appropriately authorized, the proxy establishes a connection to production systems on the client’s behalf. The Reverse Proxy uses the replica user registry to authenticate users and generate user credentials for the remainder of the user session. The Reverse Proxy reads the replica policy database to determine what policy is to be applied to protected resources. Based on that information it authorizes a client’s requests or not. The Reverse Proxy issues password policy verification requests to the Identity Manager Server whenever a password change request is made. The Reverse Proxy generates an audit log of all user activity. This log is processed by the Risk Manager Adapter for Access Manager component. Chapter 3. Applying the reference architecture 93
  • 107. Master/replica user registry The master and replica user registries provide a Lightweight Directory Access Protocol (LDAP) based directory which holds user ids, passwords and group/role associations for all registered users of protected Web-based applications. The user registries provide directory server functionality as defined in the reference architecture shown in Figure 1-2 on page 10. They are implemented using IBM Directory Server with DB2. Tip: Access Manager and Identity Manager currently maintain separate User Registries, however both registries can be collocated within the same LDAP server under different namespaces. The Master user registry is deployed in a trusted network zone and provides read/write access for both access control and system administration tasks. The Master User Registry interacts with other components as follows: The Policy Server uses the registry as its user store. The database is replicated to the Replica User Registry component. The Replica user registry is deployed in restricted network zones to provide read-only access to the user information required for: Reverse Proxy user authentication WebSphere user authentication Mail Server user authentication Authorization API user authorization Proxy Policy Server The Proxy Policy Server improves network security by proving a buffer between the Policy Server, which typically runs in a highly trusted network zone, and other components such as the Reverse Proxy, that typically run in less trusted network security zones. The Proxy Policy Server provides access management functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is is implemented by Tivoli Access Manager for e-business as a binary executable. Tip: The Policy Proxy Server can be deployed at multiple sites within a wide area network (WAN). Doing so may reduce network traffic and improve policy refresh performance. Each proxy maintains an ACL database cache that is used to service requests from multiple Access Manager clients within the local area network (LAN).94 Integrated Identity Management using IBM Tivoli Security Solutions
  • 108. The Proxy Policy Server receives requests from other Access Mangercomponents (such as replica policy database update requests), and forwardsthem on to the Policy Server.WebSphere Security ServerThe WebSphere Security Server provides security policy enforcement withinWebSphere Application/Portal Server. The server provides enforcement gatewayfunctionality as defined in the reference architecture shown in Figure 1-2 onpage 10. It is implemented as an by WebSphere Application Server as aninternal service.The Security Server has the following interactions with other components: The WebSphere runtime requests authentication/authorization decisions from the Security Server. The server performs user authentication using the Replica User Registry. The server performs authorization by delegating the request to the Access Manager Plug-in/Authorization API.Audit componentsThe following Audit components are part of the new integrated identitymanagement solution as described in 2.2.5, “Identity management and emergingproblems” on page 28.For detailed information on these components, refer to the following redbooks: Centralized Risk Management Using Tivoli Risk Manager 4.2,SG24-6095-00 Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01.Risk Manager Adapter for Access ManagerThe Risk Manager Adapter for Access Manager scans the audit logs of allAccess Manager components to identify potential security incidents. The adapterprovides security enforcement functionality as defined in the referencearchitecture shown in Figure 1-2 on page 10. It is implemented by Tivoli RiskManager as a XML configuration file for the Risk Manager Client.The adapter reads audit logs generated by the Reverse Proxy, Policy andAuthorization Servers, and passes details of any potential security incidents tothe Risk Manager Gateway or Server. Chapter 3. Applying the reference architecture 95
  • 109. Risk Manager Adapter for Privacy Manager The Risk Manager Adapter for Privacy Manager scans the audit logs generated by the Privacy Manager Server to identify potential security incidents. The adapter provides security enforcement functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Risk Manager as a XML configuration file for the Risk Manager Client. The adapter reads audit logs generated by the Privacy Manager Server, and passes details of any potential security incidents to the Risk Manager Gateway or Server. Risk Manager Clients The Risk Manager Clients component represents all Risk Manager components deployed to target systems, including adapters and the event monitor. Examples of adapters include AIX Host IDS and CISCO PIX. The clients provide security enforcement functionality as defined in the reference architecture shown in Figure 1-2 on page 10. They are implemented by Tivoli Risk Manager, typically using binary executables. The adapters process activity notifications generated by the Sensors (typically by reading audit logs) and pass details of any potential security incidents to the Risk Manager Gateway/Server. Risk Manager Server The Risk Manager Server component represents the collection of components that interact to process security incident notifications from Risk Manager Client/Adapters. These components include the Tivoli Management Framework/Enterprise Console, Distributed Correlation Engine, Event Server and Archive Database. The server provides security enforcement functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Risk Manager as a collection of binary executables, J2EE applications10 and relational databases11. The Risk Manager Server processes notifications of potential security incidents received from clients/adapters and identifies/classifies likely security incidents. Once an incident has been identified, Tivoli Enterprise™ Console® can be used to implement the enterprise’s incident response policy. 10 Running within WebSphere Application Server. 11 Running within DB2 Universal Database™.96 Integrated Identity Management using IBM Tivoli Security Solutions
  • 110. Risk Manager GatewayThe Risk Manager Gateway may improve network security by acting as a bufferbetween the Risk Manager Server, which typically runs in a highly trustednetwork zone, and Risk Manager Clients, that typically run in less trustednetwork security zones. The gateway provides audit functionality as defined inthe reference architecture shown in Figure 1-2 on page 10. It is implemented byTivoli Risk Manager as a binary executable.The Gateway receives events from Risk Manager Client components andforwards them on to the Risk Manager Server.Risk Manager Web IDSThe Risk Manager Web IDS component scans the activity logs of HTTP Servercomponents to identify potential security incidents. Web IDS provides securityenforcement functionality as defined in the reference architecture shown inFigure 1-2 on page 10. It is implemented by Tivoli Risk Manager as aPERL-based addition to the Risk Manager Client.The adapter reads activity logs generated by the HTTP Server, and passesdetails of any potential security incidents to the Risk Manager Server.SensorsThe Sensors component represents existing hardware and software devices thatare capable of reporting potential security incidents to Risk Manager Clientcomponent. Examples of such sensors include the AIX system images runningon pSeries® hosts and CISCO PIX firewalls.The Sensors send activity notifications to their respective Risk Manager adapter,typically by writing an audit log file.Identity Management componentsThe following Identity Management components are part of the new integratedidentity management solution as described in 2.2.5, “Identity management andemerging problems” on page 28.For detailed information on these components, refer to the following redbooks: Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996-00. Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01 Chapter 3. Applying the reference architecture 97
  • 111. Directory Integrator The Directory Integrator component synchronizes the contents of multiple data repositories. This is a key element of the integrated identity management solution and provides the meta directory functionality defined in the reference architecture as shown in Figure 1-2 on page 10. It is implemented by Tivoli Directory Integrator using a collection of Java-based applications. Directory Integration workflows are configured using either command line or GUI administrative interfaces. As the workflow executes, Integrator interacts with a variety of data sources and directory technologies, such as flat files and LDAP directories. Specific interactions in the WBI environment are: Nightly processing of a flat file exported from the authoritative HR data source (an Enterprise System component). Synchronization of user registries in the Access Management, Mail Server and Enterprise Data/System components with the Identity Management user registry. Reconciliation of administrative updates applied directly to the Access Management policy database with the Identity Management database. HTTP Admin Client The HTTP Admin Client is a standard Web browser, used by administrators in a trusted network zone to connect to the Identity Management Server administrative interface. The enterprise has standardized on Microsoft Internet Explorer for all intranet-based HTTP clients. Identity Manager Access Manager Agent The Access Manager Agent provides integration between the Identity Management Server and Access Manager Policy Server. The agent provides identity management functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Identity Manager as a binary executable. The agent provides a secure bi-directional interface for propagating identity administration updates between the two systems. Identity Manager Lotus Notes Agent The Access Manager Agent provides integration between the Identity Management Server and the Mail Server. The agent provides identity management functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Identity Manager as a binary executable.98 Integrated Identity Management using IBM Tivoli Security Solutions
  • 112. The agent provides a secure bi-directional interface for propagating identityadministration updates between the two systems.Identity Manager AgentsThe Identity Manager Agents component represents all agents not explicitlyreferenced in this section. Examples of agents that would be deployed includez/OS RACF and Microsoft Windows Server specific agents. The agents provideidentity management functionality as defined in the reference architecture shownin Figure 1-2 on page 10. They are implemented by Tivoli Identity Manager,typically as binary executables.The agents integrate the Identity Management Server and the target resource,providing a secure bi-directional interface for propagating identity administrationupdates.Identity Manager DatabaseThe Identity Manager Database maintains the internal configuration of theIdentity Management Server. The database provides identity managementfunctionality as defined in the reference architecture shown in Figure 1-2 onpage 10. It is implemented as a relational database using DB2 UniversalDatabase.12Identity Manager ServerThe Identity Manager Server manages all technical identity life-cycle activitieswithin the enterprise. It is the focal point of the integrated identity managementsolution and provides identity management functionality defined in the referencearchitecture as shown in Figure 1-2 on page 10. It is implemented by TivoliIdentity Manager as a J2EE application, running within WebSphere ApplicationServer.13 Note: The J2EE application is typically deployed within a trusted network security zone and not collocated with production applications.The Identity Manager Server has the following interactions with othercomponents: Sending identity/access control updates to, and receiving updates from managed target systems via Agents or Directory Integrator. Managed Targets include Access Manager, the Mail Server (iNotes) and Enterprise Systems. Processing identity life-cycle requests from the Self Registration/Self Care components.12 Oracle and Microsoft SQL Server are also supported.13 BEA WebLogic Server is also supported. Chapter 3. Applying the reference architecture 99
  • 113. Maintaining the Identity Management User Registry and Database. Sending E-mail via the Mail Server as part of automated workflows. Identity Manager User Registry The Identity Manager User Registry provides a Lightweight Directory Access Protocol (LDAP) based directory which holds user ids, passwords and group/role associations for all registered users of all protected resources within the enterprise. The policy database is a directory server as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented using IBM Directory Server14 and DB2 UDB. Tip: Identity Manager and Access Manager currently maintain separate User Registries; however, both registries can be collocated within the same LDAP server under different namespaces. The Identity Manager User Registry is deployed in a trusted network zone and provides read/write access for identity administration tasks. It interacts with other components as follows: The Identity Manager Server uses the registry as its user store. Directory Integrator synchronizes portions of the registry with other user registries distributed throughout the enterprise. Self Registration/Self Care The Self Registration component allows customers and other Internet users to register themselves with the enterprise and gain access to customer-facing systems. The Self Care component allows both internally and externally registered users to perform simple identity administration tasks, such as resetting their password and subscribing to new services, all without contacting the help desk. Both components provide the Self Registration functionality defined in the reference architecture shown in Figure 1-2 on page 10. They are implemented as J2EE applications running within WebSphere Application Server. The Self Registration/Self Care components interface with other components as follows: Receive requests from end-user HTTP Clients Submit identity management requests to the Identity Management Server for processing. 14 Sun ONE Directory Server is also supported.100 Integrated Identity Management using IBM Tivoli Security Solutions
  • 114. Note: For Self Registration/Self Care components to be accessible to users who either don’t have an existing account or have forgotten their password, the Reverse Proxy must be configured to allow unauthenticated user access.Privacy Management componentsThe following Privacy Management components are part of the new identitymanagement solution as described in 2.2.5, “Identity management and emergingproblems” on page 28.For detailed information on these components, refer to the following redbooks: BM Tivoli Privacy Manager Solution Design and Best Practices, SG24-6999-00 Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01Privacy Manager ServerThe Privacy Manager Server manages the enterprise’s technical implementationof its privacy policies, including policy enforcement and audit logging. It is aPrivacy Management component, as defined in the reference architecture shownin Figure 1-2 on page 10, and is implemented by a J2EE application runningwithin WebSphere Application Server and associated relational database,running within DB2. Note: Although a security-related service, the J2EE application is not typically deployed within a trusted network security zone because it requires interaction with every privacy enabled production application. Deploying the application to a trusted network zone would force a significant reduction in the protection provided by the management firewall.The Privacy Manager has the following interactions with other components: Privacy Monitor components request authorization decisions from the Server whenever an end user requests access to privacy-protected information. The Privacy Manager communicates with the Access Manager Policy Server to determine the identity and group associations of the user requesting access to privacy-protected information. The Server generates audit logs of all authorization requests and decisions. These logs are processed by the Risk Manager Adapter for Privacy Manager component. Chapter 3. Applying the reference architecture 101
  • 115. Privacy Monitor Privacy Monitor components mediate both line of business applications and enterprise systems access to enterprise data. They intercept application’s requests for data and obtain authorization from the Privacy Server before allowing the request to be completed. Monitors provide privacy management functionality as defined in the reference architecture shown in Figure 1-2 on page 10. For J2EE applications, they are typically implemented as Java code that runs within WebSphere Application Server. There is a dedicated Monitor for each privacy-enabled J2EE application. HTTP Administration Client The HTTP Administration Client is a standard Web browser, used by administrators in a trusted network zone to connect to the Privacy Management Server administrative interface. The enterprise has standardized on Microsoft Internet Explorer for all intranet-based HTTP clients.3.2.3 The operational architecture The operational architecture focuses on describing the operation of the integrated identity management solution, and includes the following information: A logical model of the candidate nodes of the architecture and their connectivity. Nodes are potential hardware systems, although several nodes may be combined onto one physical server, or a node split onto multiple physical servers. A description of each candidate node, including its purpose and contained software components. A description of how network zones and firewalls are used to enhance the security of the operational environment. References to other redbooks that describe how to improve the availability and scalability of individual nodes and components. A brief review of how the physical operational model would be impacted by the global distribution of the software components. Logical operational model Figure 3-9 illustrates the logical nodes that will be used to host the integrated identity management solution, the connections between the nodes and network security zones.102 Integrated Identity Management using IBM Tivoli Security Solutions
  • 116. Internet Internet DMZ Production Zone Intranet (Uncontrolled) (Controlled) (Restricted) (Controlled) Mail Server Internet Internet Intranet HTTP Server Client Reverse Proxy Reverse Proxy Intranet Client Domain Firewall Web App/ Enterprise Data/ Portal Server Systems Security Proxy Management Firewall Enterprise Firewall Protocol Firewall Directory & Identity Security Management Management Zone (Trusted) Application flow Access management flow Identity management flowFigure 3-9 Logical operational model This model is described in detail in the next section. Node definitions This section describes each of the logical nodes in detail. Directory & Security node The Directory & Security node maintains information on the location, capabilities, and attributes of resources and registered users within the Web application infrastructure. This node can supply information for various security services, such as authentication and authorization, and also performs actual security processing. This node hosts the following components: Access Management - Access Manager Policy Server Access Management - Access Manager Web Portal Manager Access Management - Master Policy Database Access Management - Master User Registry Identity Management - Identity Manager Access Manager Agent Audit - Risk Manager Adapter for Access Manager Chapter 3. Applying the reference architecture 103
  • 117. Audit - Risk Manager Adapter for Privacy Manager Audit - Risk Manager Server Enterprise Systems node and Enterprise Data node Enterprise Systems nodes represent the enterprise systems and legacy applications that exist within the enterprise. These nodes host and execute the enterprise’s core business applications, on mainframe, midrange, or other platforms. These nodes receive and process the transactions that are generated by both Web and non-Web enabled applications. Enterprise Data nodes store and provide access to all the data required for the operational of the enterprise, including data related to products, services, customers, suppliers, transactions, administration and so on. This node hosts the following components: Application - enterprise data and systems Identity Management - Identity Manager agents Audit - Risk Manager clients HTTP Server node This node hosts an HTTP Server that services requests for static content, such as images. If requests to access J2EE application pages are received, the HTTP Server forwards them to the Web Application/Portal server. This node hosts the following components: Application - HTTP Server Application - WebSphere Application Server Plug-in Audit - Risk Manager Web IDS Identity Management node The Identity Management node maintains information on the location, capabilities, and attributes of resources and registered users throughout the enterprise. This node centralizes and coordinates identity administration throughout the enterprise. While all other nodes can be deployed at multiple sites throughout the enterprise, there is only one logical Identity Management node. This node hosts the following components: Identity Management - Directory Integrator Identity Management - Identity Manager Database Identity Management - Identity Manager Server Identity Management - Identity Manager User Registry104 Integrated Identity Management using IBM Tivoli Security Solutions
  • 118. Internet Client nodeThe Internet Client node provides the interface for the bank’s customers andother Internet users to interact with the bank’s Web-enabled applications.This node hosts the following components: Application - HTTP clientInternet Reverse Proxy nodeThe Internet Reverse Proxy node is a stand-in for the production systems behindthe domain firewall. The Internet Reverse Proxy receives all requests toWeb-enabled applications as well as the responses from the Web applications.For the submitter of requests, the Reverse Proxy appears to be the onlyproduction system. It also provides security, access and data traffic redirectionassociated with the Web-enabled applications. Additionally, the Reverse Proxyprovides: Reverse Proxy caching, which improves response time Forward Proxy caching, to reduce network bandwidth requirements Look up HTTP Server redirectsThe Reverse Proxy creates a barrier between the production systems and theexternal access points creating a higher level of security and protection againstunauthorized access.This node hosts the following components: Access Management - Reverse Proxy Access Management - Replica Policy Database Note: The Reverse Proxy’s audit logs are transmitted to the Security Proxy node for processing by the Audit components. This configuration avoids having to deploy Audit components in the (relatively insecure) Internet DMZ.Intranet Client nodeThe intranet Client node provides the interface for the bank’s employees andothers to interact with both the bank’s Web and non-Web enabled applications.This node hosts the following components: Application - HTTP Client (Microsoft Internet Explorer) Application - Enterprise Client Chapter 3. Applying the reference architecture 105
  • 119. Intranet Reverse Proxy node The intranet Reverse Proxy performs a similar function to the Internet Reverse Proxy, but for employees on the bank’s internal network only. Using a separate proxy that is not deployed in the Internet DMZ improves network security. By eliminating any requirement for direct connectivity between the intranet and Internet DMZ, the likelihood of an Internet-based intruder being able to gain access to the intranet is reduced. This node hosts the following components: Access Management - Reverse Proxy Access Management - Replica Policy Database Audit - Risk Manager Adapter for Access Manager Mail Server node The Mail Server provides HTTP-based access to messaging, calendaring, scheduling and other Lotus Domino® Web-enabled applications. This node hosts the following components: Application - Mail Server Access Management - Replica User Registry Identity Management - Identity Manager Lotus Notes Agent Security Proxy node The Security Proxy improves network security by reducing the number of network locations and protocols that a permitted inbound access to the trusted management zone. All inbound access to sensitive security services such as access management and auditing must pass through this node — the management firewall will be configured to reject traffic from any other source. This node hosts the following components: Access Management - Proxy Policy Server Access Management - Replica Policy Database Access Management - Replica User Registry Audit - Risk Manager Adapter for Access Manager15 Audit - Risk Manager Gateway Privacy Management - Privacy Manager Server 15 The adapter processes logs generated by the local Proxy Policy Server and also the Reverse Proxy Server hosted in the Internet DMZ.106 Integrated Identity Management using IBM Tivoli Security Solutions
  • 120. Note: The Privacy Manager Server is deployed on the Security Proxy, rather than the Directory & Security node because it must to communicate with every privacy-enabled LOB-application and enterprise system. Allowing these applications to directly communicate with the Directory & Security node poses an unacceptable security risk.Web Application/Portal Server nodeThe Web Application/Portal Server node hosts Line-of-Business and other J2EEapplications, such as end-user accessible identity administration functions.This node hosts the following components: Access Management - Replica User Registry Access Management - Replica Policy Database Access Management - Access Manager Plug-in/Authorization API Access Management - WebSphere Security Server Application - WebSphere Application/Portal Server Application - Line-of-Business Applications Identity Management - Self Registration/Self Care Privacy Management - Privacy Monitor Audit - Risk Manager Adapter for Access Manager Note: The operational model presented here defines a single node hosting both WebSphere Application Server and WebSphere Portal Server for simplicity. A best-practice operational model for a production environment should at a minimum specify separate nodes for Portal and Application servers.Network locations/zones and bordersThe focus of this redbook is not on networks, or the concepts and practices usedin designing or implementing them. However, an understanding of networkfundamentals is crucial when designing or implementing a security architecture.A security-oriented review of network fundamentals can be found in EnterpriseSecurity Architecture using IBM Tivoli Security Solutions, SG24-6014-01.The Method for Architecting Secure Solutions16 defines four types of networkzones and associated transport classifications. This section describes how thesezone definitions relate to the Logical Operational Model shown in Figure 3-9 onpage 103, and also the types of traffic permitted to flow between them.16 MASS is also described in Enterprise Security Architecture using IBM Tivoli Security Solutions,SG24-6014-01 Chapter 3. Applying the reference architecture 107
  • 121. Internet The Internet is a global network of networks, connecting millions of computers. The Internet is not a zone that can be controlled or one that should have any components in it. Internet DMZ The Internet DMZ is a controlled zone that contains components with which uncontrolled clients may directly communicate. It provides a “buffer” between the uncontrolled Internet and internal networks. Because the DMZ is bounded by firewalls on both sides, it provides the opportunity to control traffic at multiple levels: Incoming traffic from the Internet to hosts in the DMZ Outgoing traffic from hosts in the DMZ to the Internet Incoming traffic from internal networks to hosts in the DMZ Outgoing traffic from hosts in the DMZ to internal networks The transport between a controlled and an uncontrolled zone is classified as public. The transport between a controlled and another controlled or a restricted zone is classified as managed. The Reverse Proxy is deployed in this zone, and in conjunction with the network traffic controls provided by the bounding firewalls, allows WBI to deploy a highly secure Web presence. Production zone One or more production network zones may be designated as restricted, which means that they support functions to which access must be strictly controlled, and direct access from uncontrolled networks is not permitted. As with the Internet DMZ, the production network is bounded by firewalls and incoming/outgoing traffic is filtered as appropriate. The Production Zones typically contain replicated information of user registries and access control information in order to provide this information as close to the decision seeking applications as possible. Management zone One or more network zones may be designated as a secured zone. Access is only available to a small group of authorized staff. Access into one area does not necessarily give you access to another secured area. The transport into a secured zone is classified as trusted. These zones typically would contain back-end Access Manager components that do not directly interact with users.108 Integrated Identity Management using IBM Tivoli Security Solutions
  • 122. IntranetLike the Internet DMZ, the corporate intranet is generally a controlled zone thatcontains components with which clients may directly communicate. It provides a“buffer” to the internal networks.Firewall configurationFirewalls filter and manage data flows between network zones, typically applyingone or more technologies to analyze IP packets and decide if they are allowed toflow through the firewall or not. See Enterprise Security Architecture using IBMTivoli Security Solutions, SG24-6014-01 for an overview of typical firewallimplementations.The following network traffic is permitted across the Protocol Firewall (Internet -Internet DMZ): HTTP/S traffic from Internet Clients to the Internet Reverse ProxyThe following network traffic is permitted across the Domain Firewall (InternetDMZ - Production): HTTP/S traffic from the Reverse Proxy to the HTTP Server LDAP lookups from the Reverse Proxy to the Security Proxy Policy Database replication from the Security Proxy to the Internet Reverse Proxy Reverse Proxy audit log transmission17 from the Reverse Proxy to the Security ProxyThe following network traffic is permitted across the Management Firewall(Internet DMZ and Production zone - Management zone): Policy lookups from the Security Proxy to the Directory & Security node Policy Database replication from the Directory & Security node to the Security Proxy Risk Manager event notifications from the Security Proxy to the Directory & Security node LDAP replication from the Directory & Security node to the Security Proxy, Mail Server and Web Application/Portal Server Bi-directional identity management updates between the Identity Management node and Enterprise Data/System nodes, and the Mail Server Password policy verification requests from the Reverse Proxy to the Identity Management Server17 Using the Unix remote syslog facility for example Chapter 3. Applying the reference architecture 109
  • 123. SMTP e-Mail traffic from the Identity Manager Server to the Mail Server Privacy Authorization/Audit requests from the Web Application/Portal Server to the Directory & Security node The following network traffic is permitted across the Enterprise Firewall (intranet - production zone): HTTP/S traffic from intranet clients to the intranet Reverse Proxy Application/Database traffic from intranet clients to Enterprise Data/Systems nodes as defined by the corporate security policy Availability and scalability Availability and scalability issues have been covered extensively in other redbooks, and will not be discussed further in this book. The following redbooks provide more information on how to deploy the individual components of an integrated identity management solution for scalability and high availability. DB2 Universal Database DB2 Warehouse Management: High Availability and Problem Determination Guide, SG24-6544. Tivoli Access Manager for Enterprise Security Architecture using IBM e-business Tivoli Security Solutions, SG24-6014-01. Tivoli Directory Server Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. Tivoli Identity Manager Identity Manager is a J2EE application. See WebSphere Application Server Scalability and Availability. Additional information can be found in Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996-00. Tivoli Privacy Manager Privacy Manager is a J2EE application. See WebSphere Application Server Scalability and Availability. Additional information can be found in IBM Tivoli Privacy Manager Solution Design and Best Practices, SG24-6999-00. Tivoli Risk Manager Centralized Risk Management Using Tivoli Risk Manager 4.2, SG24-6095-00. WebSphere Application/ IBM WebSphere V5.1 Performance, Scalability, Portal Server and High Availability WebSphere Handbook Series, SG24-6198-01. IBM WebSphere Portal for Multiplatforms V5 Handbook, SG24-6098-00.110 Integrated Identity Management using IBM Tivoli Security Solutions
  • 124. Geographic distribution This book does not aim to describe in detail the architecture of complex, geographically distributed systems. Most elements of the integrated identity management solution design can be deployed multiple times throughout the enterprise, with the following restrictions: There can be only one Identity Management Server. There can be only one primary Access Manager Policy Server, but any number of standby Policy Servers.18 A single Master User Registry maintains information for all users across all Access Manager domains.3.2.4 The security architecture This section reviews some additional elements of WBI’s integrated identity management architecture, namely: Security domain architecture Network communication Single sign-on Password management Security domain architecture This section provides an overview of how multiple security domains can be implemented using Access Manager v5.1 and then goes on to describe how this technology has been deployed in the WBI environment. Access Manager domain configuration The security architecture will leverage the new Access Manager v5.1 multiple domain model. This allows a centrally managed Policy Server to control multiple domains, where each domain has its own independent access control database and user management. This model provides the regional business units with the autonomy they require, while still realizing many of the benefits of a centralized infrastructure. Each domain has its own: Access Control Database Access Manager servers (WebSEAL, Authorization Server, and so on) Security Master and security groups GSO information 18 The use of standby policy servers requires a network dispatcher to give the appearance of a single Policy Server host. Chapter 3. Applying the reference architecture 111
  • 125. However, all domains share: Users and groups Management tools (for example, Web Portal Manager) Policy Server, Proxy Policy Server, and User Registry Tip: Although the WBI security architecture specifies shared user registries and management tools, Access Manager can also be deployed with dedicated user registries and management tools in each environment. Access Manager uses a default domain known as the Management Domain. This is the domain that is created when the Access Manager Policy Server is configured. The Policy Server is always registered in the Management Domain and other domains can only be configured by an administrator of the Management Domain. The Management Domain (through registry ACLs) controls all Access Manager objects owned by all domains. Figure 3-10 illustrates what is shared and what is independent in a multi-domain environment. Domain A Domain B ACL Policy Server ACL Database Database Access Manager Management Access Manager Servers Tools Servers User Registry Security Security Master User User Master GSO Data GSO Data User Security Security Groups Group Group Groups Group Figure 3-10 Access Manager multi-domain environment112 Integrated Identity Management using IBM Tivoli Security Solutions
  • 126. In this diagram, some users and groups are only defined in one domain, butothers are defined in both domains. This is made possible by Access Manager’sability to import users and groups that already exist in the user registry. If theregistry ACLs are set up to allow it, a user or group that is created in one domaincan be imported into other domains.A user definition that is shared between domains only shares the attributes of thebase user object. This is the user’s First Name (CN), Last Name (SN),description and password. All other attributes are managed independently byeach domain. Registry ACLs can be configured to limit which domains canmodify the users base object (including the users password). Registry ACLscould also be configured so that one domain’s users are not visible in any way toother domains.Group objects (and therefore group membership information) can also be sharedbetween domains. In this case, registry ACLs can be configured manually to limitwhich domains can add/remove users from the group.The administration users and groups for a domain are always independent.These cannot be shared between domains, which prevents one domain fromgaining control of another domain’s management users/groups.WBI security domainsWBI implements a security domain design (shown in Figure 3-11) that is typicalof a global enterprise which prefers de-centralized security administration. Chapter 3. Applying the reference architecture 113
  • 127. Identity Manager Domain Line-of-Business Line-of-Business Enterprise Applications Applications Systems Regional Regional Enterprise Data Applications/Data Applications/Data AM Eastern Region AM Central Region Domain Domain AM IT Center Domain Line-of-Business Line-of-Business Applications Applications Customer facing LOB Applications Regional Regional Applications/Data Applications/Data AM Western Region AM European Region Domain Domain AM Customer Domain Access Manager AM Administration Management Infrastructure Domain Enterprise Enterprise Data Systems Figure 3-11 WBI security domains A single Identity Manager domain will provide identity administration functions for all secured resources within the enterprise. Individual Access Manager Secure Domains have been defined for each of the four regions, the IT Center and customer facing applications. Each regional domain is administered by a local IT support group, with resource-level access control delegated to resource owners within the region. IT Center staff administer both the enterprise and customer facing application domains. The Management Domain has ownership of the regional domains and also contains the shared administrative infrastructure such as the Web Portal Manager. Some systems and databases have not yet been migrated into the Access Manager environment and administration is performed by dedicated support groups.114 Integrated Identity Management using IBM Tivoli Security Solutions
  • 128. Network communicationThis section classifies the different types of network traffic generated by theintegrated identity management solution and also provides an overview of thenetwork protocols used.Application flowsThe flow of information between the HTTP Client and Web Application/Portalserver uses either the HTTP or HTTPS protocol, depending upon the sensitivityof the data being transferred in each specific interaction. Each componentinvolved in a particular interaction will use the same protocol. The individualinformation flows are: HTTP Client to Reverse Proxy Reverse Proxy to HTTP Server WebSphere Application Server Plug-in to Web Application/Portal ServerBoth J2EE applications and enterprise clients connect to enterprise systems anddata using the protocols appropriate for the specific enterprise resource, such asCICS, IIOP, MQSeries®, or DB2 CLI.Access management flowsPolicy Database and User Registry updates are replicated using proprietaryprotocols over SSL-encrypted network connections. All Access Managercomponents (including client APIs in other products such as Privacy Manager)communicate using proprietary protocols over SSL-encrypted networkconnections.The HTTP Admin Client uses HTTPS to communicate with the Web PortalManager, Privacy Server, and Identity Management Server.Privacy enabled J2EE applications communicate with the Privacy ManagerServer using the J2EE RMI/IIOP protocol over a SSL-encrypted network link.Identity management flowsMost Identity Management Flows are DSMLv219 document exchanges overSSL-encrypted network connections. The Identity Manager Server uses thiscommunication mechanism for: All communication with agents All communication with client applications, such as Access Manager WebSEAL (for password verification and synchronization) and the J2EE applications that implement self registration/self care functions19 DSMLv2 is an open standard to encapsulate directory queries and updates as XML documents.See http://www.oasis-open.org/committees/dsml/docs/DSMLv2.doc for more information. Chapter 3. Applying the reference architecture 115
  • 129. Directory updates passing between the Identity Management Server and Directory Integrator. The Identity Management Server also sends mail via the Mail Server over unencrypted SMTP. Directory Integrator exchanges information with various data sources using the native protocols of each source. Common examples include LDAP Data Interchange Format (LDIF), Java Naming and Directory Interface (JNDI), MQSeries messaging or Extensible Markup Language (XML). Note: Not all Directory Integrator data sources support encrypted network communication. In these cases an Identity Manager agent may provide a more secure synchronization mechanism. Audit flows Risk Manager components exchange information using the proprietary Tivoli Management Environment event notification protocol. Three different network communication mechanisms may be used: Risk Manager socket communication: Risk Manager agents talk to each other using simple TCP/IP sockets. This mechanism is suitable for communication only if the network is internal and secure, such as a dedicated management network. Secure Socket Layer (SSL): SSL is a protocol that provides data privacy and integrity between two communicating applications using TCP/IP. SSL makes use of digital certificates and the data being transmitted is encrypted. A Risk Manager agent is capable of receiving and sending data using the SSL protocol. The default port used by the agent for receiving SSL data is 5549. TME communications: TME® communications is a secure communication mechanism provided by the Tivoli Management Framework. Risk Manager agents residing on Framework Endpoints and Managed Nodes can communicate using TME. Single sign-on Single sign-on (SSO) presents a complex, but potentially rewarding challenge for an enterprise of any significant size. This section provides an overview of Windows desktop SSO, and Cross Domain SSO. For more information on SSO implementation considerations, see Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. Appendix B, “Single sign-on - a contrarian view” may be of particular interest.116 Integrated Identity Management using IBM Tivoli Security Solutions
  • 130. Intranet HTTP client authenticationThe security architecture will leverage the Access Manager capability toauthenticate Web users based upon their Windows desktop user identity. Thissingle sign-on capability is implemented using the Microsoft SPNEGO protocoland a Kerberos-based authentication service.Microsoft provides an authentication solution that allows Windows clients to useMicrosoft Internet Explorer (IE) to access resources on Microsoft InternetInformation Servers (IIS) without having to reauthenticate. This single sign-onsolution relies on proprietary Microsoft HTTP authentication mechanisms.Access Manager provides an equivalent authentication solution that enables IEclients to access protected resources without having to reauthenticate.This means that users with an IE browser can access resources protected byTivoli Access Manager without having to reenter their username and password.The user only needs to login once to the Windows domain, as is done whenlogging in to Windows on a desktop workstation. Access Manager supplies asimilar implementation of the HTTP authentication method used by Microsoft.This implementation involves two components: Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Kerberos authenticationThe SPNEGO protocol mechanism enables Access Manager to negotiate withthe browser to establish the authentication mechanism to use. The browsersupplies Kerberos authentication information. Access Manager is able to use theuser’s Kerberos authentication information when processing a user request toaccess protected resources. Note: This solution requires that the WebSEAL servers be configured into an Active Directory domain, and that WebSEAL is able to access a Kerberos Key Distribution Center. Also, the Internet Explorer clients must be configured to use the SPNEGO protocol and Kerberos authentication when contacting WebSEAL.Cross Domain single sign-onThe security architecture will provide single sign-on across all Web-enabledapplications for both Internet and intranet users.Cross Domain single sign-on (CDSSO) allows Web users to perform a singlesign-on and move seamlessly between separate secure domains whenrequesting access to protected resources. When a user makes a request to aresource located in another domain, the CDSSO mechanism transfers anencrypted user identity token from the first domain to the second domain. Chapter 3. Applying the reference architecture 117
  • 131. The identity information in this token indicates to the receiving domain that the user is successfully authenticated in the first domain. The identity does not contain password information. The receiving server uses this token to build credentials in its own cache for that user. The user is not forced to perform an additional login. See “WBI security domains” on page 113 for details of the secure domains that have been defined as part of this security architecture. See Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01 for more information on implementing CDSSO. Password management The security architecture will use Identity Manager, rather than Access Manager, to enforce the enterprise’s password policy. Identity Manager enables consistent password synchronization and validation across both Web and non-Web resources. One consequence of this decision is that Access Manager must be configured to use Identity Manager’s password validation service instead of its own. The diagram in Figure 3-12 shows the sequence of the events when Access Manager’s password change processing is integrated with the password validation and account management functions of Identity Manager. Internet/Intranet Client HTTP Client Identity Manager Database 1 Password 2 Strength Library 3 Password Access Manager Management WebSEAL Post Password 4 5 6 Servlet Change Library Reverse Proxy Identity Manager Figure 3-12 Integrated password change workflow118 Integrated Identity Management using IBM Tivoli Security Solutions
  • 132. The sequence of events is as follows: 1. The user requests a change of password, possibly due to password expiration or after being reset. 2. WebSEAL invokes a custom password strength library that has been developed and configured for integration with Identity Manager.20 3. The password strength library composes an XML message containing the new password and requests password validation by POSTing a message to a configured servlet on the Identity Manager server. The password management servlet validates the proposed new password using Identity Manager’s rules for password policy. 4. If the new password is valid, the password strength library returns success to WebSEAL and WebSEAL updates the User Registry (not shown) with the new password. 5. If the update of the User Registry is successful, WebSEAL invokes a custom post password change library that has been developed and configured for integration with Identity Manager. 6. The password change library creates an XML message containing the new password and requests password synchronization by POSTing a message to the password management servlet. Note: WebSEAL considers the post-password change library to be a notification-only mechanism — its return value has no effect on WebSEAL processing. If step 4 is successful, the user will be shown the password updates success page regardless of the results in steps 5 or 6.3.2.5 Implementation phases This section describes how WBI has partitioned the overall integrated identity management solution implementation into a number of high-level phases. Each phase will be further partitioned during implementation. Phase 0 The goal of the primarily phase was to Web-enable core applications, as described in 2.2.2, “Recently implemented e-business initiative” on page 25. This phase deployed the Application and Access Management components described on pages 89 and 91 respectively. The preliminary phase is complete and will not be discussed further in this book. 20 This library uses a standard WebSEAL interface. Chapter 3. Applying the reference architecture 119
  • 133. Phase 1 The goal of phase 1 is to meet the functional requirements described in 2.5.1, “Phase 1” on page 34. This phase will deploy the Identity Management components described on page 97 and integrate them with the existing Application and Access Management components described on pages 89 and 91 respectively. Phase 1 will be delivered incrementally, as discussed in 3.1.3, “Incremental delivery strategy” on page 69. This initial delivery project will target a pilot workgroup within a single region and implement the following functionality: Automatic account provisioning from an authoritative HR data feed: During the pilot deployment, a nightly flat file export of relevant data will be generated by the HR system and processed by the Identity Management solution. This integration architecture will be revised during subsequent delivery increments. The target systems for account provisioning are: – LOB applications protected by the Access Management components described on page 91. – A local Windows domain, used to control access to the workgroup’s file server. – The Mail server. Intranet user self care: Members of the pilot work group will be able to use a Web page to change or reset their password on all target systems. Intranet user application subscription: Members of the pilot work group will be able to request access to workgroup LOB applications. These requests will be automatically forwarded to the workgroup administrator for approval. If approved, the access is granted automatically. Internet user self registration: The pilot work group’s customers will be able to register themselves and be automatically granted access to the work group’s customer-facing LOB applications. Chapter 4, “Implementing the solution” on page 121 details the integration steps performed during this phase. Phase 2 The goal of phase 2 is the meet the functional requirements described in 2.5.2, “Phase 2” on page 41. This phase will deploy the Audit and Privacy Management components described on pages 95 and 101 respectively, and also enhance the functionality of the Identity Management components described on page 97. The implementation of phase 2 will not be discussed further in this book.120 Integrated Identity Management using IBM Tivoli Security Solutions
  • 134. 4 Chapter 4. Implementing the solution This chapter describes several aspects of implementation for IBM Tivoli Identity Manager and IBM Tivoli Directory Integrator at WBI. It also describes the integration with the existing environment, such as IBM Tivoli Access Manager for e-business and iNotes. The implementation and configuration of the following IBM Tivoli components or aspects are covered: Organization tree Services Policies Provisioning policies Administrator and user access Identity feed and directory synchronization Each of these sections discusses the following details: Requirements: What should be considered before designing a solution Design considerations: What are the possibilities and options available for that design WBI implementation: How it was done in WBI’s implementation© Copyright IBM Corp. 2004. All rights reserved. 121
  • 135. 4.1 Development environment overview This section describes the development environment that has been created for the solution build phase1 of the WBI integrated identity management pilot project. This project targets a pilot workgroup within a single region and will implement the functionality described in “Phase 1” on page 120. The development environment is shown in Figure 4-1. Production Zone (Restricted) Management Zone (Secured) Directory & Security Reverse Proxy Mail Server Policy IM iNotes (Mail) WebSEAL Server AM Agent Server HTTP Server IBM Directory Server IM HTTP Server Domino WAS Master Replica Master IM User IM Agent Plug-in User Policy DB Policy DB Registry Database Registry WebSphere App/Portal Server Identity Self Reg WAS/WPS Replica Proxy Policy Directory Manager Self Care Security User Server Integrator Server Registry LOB AM Applications Plug-in/API Access HR Manager Enterprise Replica Data Web Portal Data Policy DB File Manager Web Application/ WebSphere Portal Server, IM App Server Windows Windows Security Proxy, File Server Agent Identity Enterprise Systems & Data Management Abbreviations: Application flow Identity management flow AM Access Manager IM Identity Manager Access management flowFigure 4-1 WBI integrated identity management pilot development environment 1 “Solution build” on page 59 describes how this phase forms part of an end-to-end implementation.122 Integrated Identity Management using IBM Tivoli Security Solutions
  • 136. The development environment follows the design principles described in 3.2.3, “The operational architecture” on page 102. Some logical nodes have been collocated to reduce the number of physical servers required. The test and production environments will implement the logical operational model shown in Figure 3-7 on page 83.4.1.1 Component model The WBI pilot project integrates the Application, Access, and Identity Management components as previously described in 3.2.2, “Component model” on page 87. Table 4-1 outlines the products implemented, and their release levels, in relation to the components for WBI. Table 4-1 Component to product mapping Components Product implemented Product level Identity Management IBM Tivoli Identity Release 4.5.1 Manager Directory and Security, IBM Tivoli Access Release 5.1 Reverse Proxy Server, Manager Security Proxy Web Application IBM WebSphere Release 5.0.2, Fixpack 2 Application Server Web Application / Portal IBM WebSphere Portal Release 5.0 Server Directory IBM DB2, enterprise Release 8.1, Fixpack 2 version Identity Management IBM Directory Integrator Release 5.2 Mail Server Lotus Domino Server Release 5.0.11 WBI implementation will be on a Windows 2000 Server environment running with service pack 4. IBM Tivoli Identity Manager agents As shown in Figure 4-1, in the WBI pilot development environment, some product components may contain several logical components. An example is IBM Tivoli Identity Manager, which requires additional specific code to manage data repositories (agents). At WBI, we will install IBM Tivoli Identity Manager agents for IBM Tivoli Access Manager, IBM Lotus Notes, and Windows 2000 Server. Chapter 4. Implementing the solution 123
  • 137. For WBI’s implementation, all the agents are placed on the same platform as the user repository. There will be cases where this will not be the situation. If so, the installation of the agent on different platforms may require administrative client software (depending on the data repository to be managed) in order to be configured. For specific details on each agent, please refer to the appropriate product documentation.4.1.2 Operational model The development environment follows the design principles outlined in 3.2.3, “The operational architecture” on page 102, albeit with a different focus. The production environment design maximizes scalability, availability, and security, while the development environment design minimizes hardware requirements and administrative overheads. Nodes The following nodes have been deployed in the development environment. Mail Server node This node is similar to the description of the “Mail Server node” on page 106, except that a replica user registry has not been created. For simplicity, the Mail Server has been configured to reuse the user registry on the Web application node. HTTP Server node This node is similar to the description of the “HTTP Server node” on page 104. Web Application/Portal Server, Security Proxy, Enterprise Data node In the development environment, this node combines the functions of the following nodes: “Web Application/Portal Server node” on page 107 “Security Proxy node” on page 106 “Enterprise Systems node and Enterprise Data node” on page 104 During the WBI pilot project, a Windows file server is the only enterprise system that shall be used. Reverse Proxy node This node is similar to the description of the “Internet Reverse Proxy node” on page 105, but is used to control access to both Internet and intranet applications.124 Integrated Identity Management using IBM Tivoli Security Solutions
  • 138. Note: A single reverse proxy is unlikely to pose a security risk in a controlled development environment, but should not generally be used in production deployments involving both intranet and Internet network access.Directory & Security nodeFor a description of this node, see “Directory & Security node” on page 103. Thisnode hosts the following components in the development environment: Access Management - Access Manager Policy Server Access Management - Master Policy Database Access Management - Master User Registry Identity Management - Identity Manager Access Manager agent Identity Management - Identity Manager Database Identity Management - Identity Manager User Registry Note: The Identity Management database and user registry have been deployed on the Directory & Security server to balance hardware capacity requirements between nodes and make better use of available hardware. While acceptable in a small scale development environment, this configuration is unlikely to be appropriate for production or other large scale deployments.Identity Management nodeFor a description of this node, see “Identity Management node” on page 104.This node hosts the following components in the development environment: Access Management - Access Manager Web Portal Manager Identity Management - Directory Integrator Identity Management - Identity Manager ServerA flat file from the HR enterprise system is also delivered to this node on a nightlybasis. This file will drive automatic provisioning during the WBI pilot project. Note: The Access Manager Web Portal Manager has been deployed on the identity management node to reuse the WebSphere Application Server environment created for the Identity Manager Server. This configuration simplifies the development environment but is unlikely to be appropriate for production or other large scale deployments.Network zonesFirewalls have not been implemented in the development environment.However, the data flows between logical zones comply with the network protocolrules defined in “Firewall configuration” on page 109. Chapter 4. Implementing the solution 125
  • 139. The following nodes are in the logical production zone: Mail Server HTTP Server Reverse Proxy Web Application/Portal Server, Security Proxy, Enterprise Systems & Data The following nodes are in the logical management zone: Directory & Security Identity Management Server4.1.3 Security architecture The development environment uses a simplified, non-production-like security architecture: A single, dedicated Access Manager Domain is used. Windows Desktop SSO has not been configured. These features will be enabled when the WBI pilot is deployed into production. See 3.2.4, “The security architecture” on page 111 for details of the full production implementation.4.2 Technical implementation In this section, we will be addressing the following four areas for WBI’s implementation: Automatic provisioning Application subscription Self care Self registration4.2.1 Automatic provisioning Let us take a closer look at the requirements, the design considerations, and WBI’s implementation. Requirements When an employee joins a company, the first task at hand is to get their information into the appropriate systems. The human resources department is normally the first group to acquire the employee’s data and enter it into their system. The next step would be to set up access to the relevant IT resources for the employee.126 Integrated Identity Management using IBM Tivoli Security Solutions
  • 140. The ideal process for this should automatically generate accounts for this newuser to different IT resources. This section shows how to achieve thisprovisioning with IBM Tivoli Directory Integrator and IBM Tivoli Identity Manager.Based on the fields within the HR file (roles, departments) we should be able toprovision access to specific new accounts for the users. This can be doneautomatically with a process that permits synchronization between the HRdirectory and IBM Tivoli Identity Manager. This synchronization process will beachieved by IBM Tivoli Directory Integrator, and when users are loaded into IBMTivoli Identity Manager, automatic provisioning processes will provide access tothe applications.The synchronization process between the HR directory (HR file) and TivoliIdentity Manager is handled by an assembly line in Tivoli Directory Integrator,which creates an identity (person) for Identity Manager. This process can bedone on an interactive base, or it can be scheduled to synchronize the directoriesat a specific time of day (maybe at night). Automatic provisioning of users ishandled by provisioning policies which have automatic settings configured. But inorder for this to yield the appropriate results, the following aspects have to beconsidered: The HR file must have the proper format in order to create identities with the right information. Passwords must be generated in a way to satisfy the policies, be secure, and be known to the users. All required attributes for that particular service must be assigned default values (that match policies for those values). Organization roles must be defined to avoid granting undesired access to certain users.It is necessary to have enough information to address all these issues in order todesign the adequate assembly lines and provisioning policies.Design considerationIn order to use the identities supplied by the HR file, we require the use of anassembly line via Directory Integrator to import the data into Identity Manager.There has to be a process to create a flat file, with the right information from theHR directory. Then, we upload this to a network drive so that Directory Integratorcan access and read the file, and synchronize with Identity Manager.Once the new identities are created, they must have access to the applicationsthey need to do their job, based on services (access to application) andprovisioning policies (corporate access policies). Chapter 4. Implementing the solution 127
  • 141. There will be a provisioning policy for the WBI company, in order to provide an Identity Manager account to every user in the company, automatically. Every identity requires an Identity Manager account, as this is how each user is administered. For specific application access, there will be specific provisioning policies in each organization unit for WBI, in order to automatically provision the users for this access. A good automated provisioning policy for adding users should run independently of any human input. It is technically possible to define a workflow for an automatic provisioning policy, but this can cause storms of approval requests and information requests being sent to the administrators. In order to avoid this, the provisioning policy must correctly handle: Password generation Default values for service attributes Target system roles It is possible to address all these issues by using scripts. Once we have configured the assembly line in Directory Integrator, and created the services and provisioning policies in Identity Manager, automatic provisioning is complete. This makes the entire provisioning process seamless and automatic. Directory Integrator is a very important tool required for the data synchronization and it proves very powerful in identity management projects. When reviewing the design consideration of automatic provisioning it is important to consider the following: Data flow Organizational roles and target systems membership Generating passwords Provisioning policies attributes Please refer to IBM Tivoli Directory Integrator 5.2: Getting Started Guide for a complete explanation of these. Data flow There has to be a design to implement data synchronization between directories with IBM Tivoli Directory Integrator. Integration problems between directories are all about communication. In this process, we are using a text file to get the user data from the HR Directory. We need to know the proper format for creating this file.128 Integrated Identity Management using IBM Tivoli Security Solutions
  • 142. The first process needed, when a new employee arrives at WBI, is for the HRdepartment to feed the directory with all the data needed, including their role,location, and organization unit. A batch process creates a text file with theinformation and format required, and the assembly line from IBM Tivoli DirectoryIntegrator synchronizes the data in the file and creates the new identities in IBMTivoli Identity Manager.Here we describe the constituent elements of a communications scenario:Data Sources These are the data repositories, systems, and devices that talk to each other. For example, the Enterprise Directory you are implementing or trying to maintain; your CRM application; the office phone system; maybe an Access database with the list of company equipment and to whom the equipment has been issued. Data sources represent a wide variety of systems and repositories, such as databases (for example, Oracle, DB2®, SQL Server), directories (for example, iPlanet, IBM Directory Server, Active Directory), directory services (for example, Exchange), files (for example, XML, LDIF or SOAP documents), specially formatted e-mail, or any number of interfacing mechanisms that internal systems and external business partners use to communicate with your information assets and services. In the case of the WBI data feed from HR, it will be a text file.Events Events can be described as the circumstances dictated when one set of data sources communicates with another. One example is whenever an employee is added to, updated within, or deleted from, the HR system. Another example is when the access control system detects a keycard being used in a restricted area. An event can also be based on a calendar or a clock-based timer, for example, starting communications at 12:00 midnight every day except Sunday. It might even be a one-off event, for example, populating a directory. Events are usually tied to a data source, and are related to the data flows that are triggered when the specified set of circumstances arise. At this point, for IBM Tivoli Identity Manager, WBI is implementing the synchronization based on time; every day at 12:00 midnight, communications will start and data synchronization will happen. Chapter 4. Implementing the solution 129
  • 143. Data Flows These are the threads of the communications and their content, and are usually drawn as arrows that point in the direction of data movement. We will be using IBM Tivoli Directory Integrator for HR feed, and for data synchronization. This process implies that there will be a large amount of data being exchanged between the different directories. Attribute Mapping For a conversation to be meaningful to all participants, and Transformation everyone involved must understand what is being communicated. But you can probably count on the data sources representing their data content in different ways. One system might represent a telephone number as textual information, including the dashes and parentheses used to make the number easier to read. Another system might store them as numerical data. If these two systems are to communicate with this data, then the information must be translated during the conversation. Furthermore, the information in one source might not be complete, and might need to be augmented with attributes from other data sources. Also, only parts of the data in the flow might be relevant to some of the output sources. Choosing which fields or attributes are to be handled in a dataflow, or passed on to a data source, as well as how each connected system refers to and represents this information, is called Attribute Mapping. WBI uses several corporate directories such as Lotus Notes, IBM Tivoli Access Manager, and Microsoft Active Directory, which all store user relevant data in their own directories. Synchronization and integration of these directories is the major objective of this project. Because we implement an integrated identity management solution, we will utilize IBM Tivoli Directory Integrator assembly lines to synchronize this data.130 Integrated Identity Management using IBM Tivoli Security Solutions
  • 144. The representative diagram for the data flow is shown in Figure 4-2. HR Directory IBM Tivoli IBM Tivoli Identity Access iNotes IDI Manager Manager Directory Directory Directory Provisioning IDIFigure 4-2 Data Flow between directoriesOrganizational roles and target systems membershipAutomatic provisioning policies can be set for all identities, but, depending on theresource, only certain users should be provisioned by them. It may also benecessary to assign users to specific roles on the target system, which requiresmore organizational roles or a specific Java Script to assign the proper targetsystem group membership.If IBM Tivoli Identity Manager organizational roles can be adequately mapped tothe target system’s roles, group membership can be determined by a set ofprovisioning policies. Remember that provisioning policies can be added todetermine group membership (most services are configured to have groupmembership as a union of all policies).Based on this, it is possible to create the following policies: One basic provisioning policy that grants the common group membership for all identities, as well as the default values for the attributes Provisioning policies for each organizational role to service group mapping Chapter 4. Implementing the solution 131
  • 145. Since we use IBM Tivoli Directory Integrator for the HR feed, we need to create a set of provisioning policies that can create and change user identities and their respective user ids and passwords. These policies will also provision the users into the correct organizational units and create the accounts necessary to access the corporate applications. An alternative design is to use a Java Script to assign the proper group memberships for all users. This can be more complex to test and maintain, but may avoid an excessive number of provisioning policies. Generating passwords One key attribute that must be handled by automated provisioning policies are the users passwords. Passwords must be generated to match the password policies for the services to which they are provisioned. This may be a challenge if there are several password policies in place. Generating the password can be a complex issue when this is the first password for the user. This password may be used for the mail system or entry point applications, such IBM Tivoli Identity Manager and IBM Tivoli Access Manager. For these applications, the user must have some way of knowing what the password is. IBM Tivoli Identity Manager includes a shared secret field that can be used for holding the seed for a password. The password can be created with a Java Script. This script can have access to all the identity’s information and the account information. This means that any attribute can be used to create the password. However, for the entry point applications, the user should know the password, or have a way to determine it. Provisioning policies attributes Most services have a set of required attributes. For an automatic provisioning policy to work, all these attributes must be given default values, which includes the password (as discussed above). These attributes can be defaulted to: Constant values Values returned by a Java Script The use of constant values is normally applied to items such as Boolean flags, group membership, and anything that does not depend on the identities’ information. The script should be used for any attributes that vary between identities. Scripts can become fairly complex and can look into values in the LDAP.132 Integrated Identity Management using IBM Tivoli Security Solutions
  • 146. Provisioning policies will be joined to yield the final value for the attributes. Thisallows the construction of one general provisioning policy that handles the valuesfor all or most users, and group specific policies that will override the generalpolicy. Overriding can be done using the appropriate priority on the provisioningpolicyWBI’s implementationThe identity feed synchronization will do a bulk load of identity data into IdentityManager. The identity feed is initiated by the administrator using the IBM TivoliDirectory Integrator user interface.For this process, we have configured an IBM Tivoli Directory Integrator assemblyline, which reads a text file, and creates the new users with IBM Tivoli IdentityManager. This assembly line is based on hrfeed_jndi_placement.xml, anexample taken from the IBM Tivoli Identity Manager Provisioning Fast StartGuide Version 5.1.WBI’s HR department generates a text file with the information on the new users,which looks as follows: First;Last;Title;Department Robert;Dubois;VP Manager;BO Trade Andre;Gabin;Financial Advisor;BO Trade Jean;Marais;Financial Advisor;BO Trade Marie;Tran;Financial Advisor;BO TradeThis file could contain further fields to be passed into IBM Tivoli IdentityManager. To do that, you must configure the assembly line in order that IBMTivoli Directory Integrator understands the data given, and format it to create theidentity with the right format.Directory Integrator is designed to synchronize identity data located indirectories, databases, collaborative systems, applications used for humanresources (HR), customer relationship management (CRM), EnterpriseResource Planning (ERP) and other corporate applications. In Identity Manager,a provisioning service type called a Directory Integrator Data Feed is supportedfor user data exchange between Directory Integrator and the Identity Managerserver.The IT department creates the file and uploads it to a network drive where IBMTivoli Directory Integrator can access it. In our WBI environment this file will beprocessed once a day, which is considered to be sufficient. The frequency forthis process can, however, be changed to a different interval. See Figure 4-3. Chapter 4. Implementing the solution 133
  • 147. Figure 4-3 CSV file read example The assembly line contains the information to communicate with IBM Tivoli Identity Manager, which creates the new identities in the specified location. IBM Tivoli Identity Manager must be configured to accept the data and create the identities in the specified location. To do this, we configured a service before running the assembly line. This service is a DSML Identity Feed type, and has a placement rule as follows: return "ou=" + entry.departmentnumber[0]; With this rule, the service reads the value for the department, and creates the identity in the organizational unit. If there is no value for department, it creates the identity in the root organization tree, but, since there is only one provisioning policy at this level (the one for provisioning to Identity Manager account), the user only gets access to Identity Manager.134 Integrated Identity Management using IBM Tivoli Security Solutions
  • 148. WBI has recently implemented a new e-business initiative. With IBM TivoliAccess Manager for e-business, WBI will provide access to Web applications tointernal and external users, based on a central authentication and centralauthorization point.Besides IBM Tivoli Access Manager for e-business, WBI will automaticallyprovide access to these applications: IBM Tivoli Access Manager IBM Lotus Notes Microsoft Active DirectoryBased on corporate policies, we will provision users from the BO Tradeorganizational unit with the necessary rights to access their corporateapplications.Once the HR feed is finished, identities are created within the organizationalunits. Next the users must be given access to services for their correspondingorganizational unit. We configure provisioning policies for the following services: Notes BO Trade Service TAM BO Trade Service TAM GSO BO Trade Service Win2000 BO Trade ServiceEach identity created at this point must be granted access to these services. Inorder to execute this process automatically, we create provisioning policies forthese services with automatic provisioning. Each provisioning policy uses anentitlement for one service and automatically creates the account. As anexample, the provisioning policy parameter list for the IBM Tivoli AccessManager service for granting user access to Web resources (such as IBMWebSphere Portal) is shown in Figure 4-4. Chapter 4. Implementing the solution 135
  • 149. Figure 4-4 Advanced Provisioning Parameter List When a user is created in LDAP for IBM Tivoli Access Manager (o=wbi), that user’s passwords will default to their last name. This way the user is able to gain initial access to the Identity Manager self reset password page and change their passwords (with password synchronization performed by Tivoli Directory Integrator). The users are then automatically provisioned for all the applications they require access to. This is done by Identity Manager provisioning policies and services, as seen in Figure 4-5.136 Integrated Identity Management using IBM Tivoli Security Solutions
  • 150. Figure 4-5 Accounts For every Location, Organization Unit, Business Partner, and Organization Role defined, there will be provisioning policies to grant access to the applications (services). The companys security policies will either allow a fully automatic process, or they require a workflow based process with an explicit management appoval.4.2.2 Application subscription Let us take a closer look at the requirements and the design considerations for WBI’s implementation for application subscription. Requirements Once a user exists in IBM Tivoli Identity Manager (identity), that user has been provisioned with the default access for their role. But, for various reasons (such as security policies), sometimes new users in specific roles are not provided with access to all applications they are allowed to use, because there are some specific procedures to do this, or a new application has just become available. Chapter 4. Implementing the solution 137
  • 151. The complete list of applications that users in the BO Trade organization unit from WBI company have access are: Notes BO Trade Service TAM BO Trade Service TAM GSO BO Trade Service Win2000 BO Trade Service These applications have specific provisioning policies and placement rules in order to provide new users access to these resources. But, there is another application, TAM 2 BO Trade Service, that is not provided by default, as it is part of another IBM Tivoli Access Manager Domain. The reason is that not all users in the BO Trade organization unit should have access to this application; it is limited to only those users who are authorized by the BO Trade VP Manager. In this particular case, a user has to submit a request if he needs access to the application. An approval process is automatically started and the VP Manager can either grant or deny access to this application. WBI provides a portal interface where users can subscribe for additional applications. Note: The list of applications to which a user can subscribe should be limited to only those applications to which the user could potentially have access; you don’t want to show more applications (for example, those that are specific to managers). To assure this, we need to establish a proper policy at IBM Tivoli Identity Manager (ACI). Choice of an application to which a user can subscribe is based on services specific for BO Trade on IBM Tivoli Identity Manager. Access to that particular application is controlled by IBM Tivoli Access Manager for e-business, which authenticates such applications and chooses an authorization process for them based on the identity and policies, and roles (groups). To provide access to a particular application, the user just needs to be part of a group permitted to access it. At WBI, we must develop an authorization process for granting users access to certain applications. We need to use the workflow utility from IBM Tivoli Identity Manager in order that the VP Manager can grant or deny the applications for such provisioning. Once the VP Manager has processed this request, the user must be created automatically, or the request will be denied. In either case, the user is informed of the application status via e-mail.138 Integrated Identity Management using IBM Tivoli Security Solutions
  • 152. Design considerationsIn order to solve problems in this area, there are some aspects to be considered: Which applications the user can subscribe to Which users can subscribe to those applications Who has to approve the access to these applicationsTo implement application subscription, we need to know what applications theuser can subscribe to. Since WBI has implemented IBM Tivoli Access Managerfor e-business, it has an e-business enabler that is protecting all Web basedapplications. It is important to know the authentication and authorization processdone by IBM Tivoli Access Manager for e-business, and the configurationimplemented at WBI. All access to Web resources is based on roles (groups); wecan provide access to these resources to users simply by making the users partof an appropriate group.IBM Tivoli Access Manager authorization decisions are made based on a user’sidentity (authentication) and an access control policy, based on permissions. Formore information regarding these procedures, refer to Part II, “Managing AccessControl”, in the IBM Redbook, Enterprise Security Architecture using IBM TivoliSecurity Solutions, SG24-6014-01.Provisioning the users to the application requires a specific service. Also neededis a policy to allow users to subscribe to this application (ACI). Refer to the Policyand Organization Administration Guide for IBM Tivoli Identity Manager, Version4.5.0, SC32-1149-01.Once users have subscribed to the application, an authorization process needsto be started, which is done by the workflow utility. BO Trade VP Manager is tobe notified (by e-mail) that there is a request to be actioned. The VP Managerthen needs to access the IBM Tivoli Identity Manager user interface and approveor reject the access request to the application.WBI’s implementationThe WBI portal allows users to subscribe to applications, based on policies. Aservice needs to be created in IBM Tivoli Identity Manager, which refers toapplications that the users can subscribe to.In this case, since WBI has multiple locations, and is managing different IBMTivoli Access Manager domains, some users in BO Trade will need to haveaccess to an IBM Tivoli Access Manager application in a different location.Before this access can be granted, it must go through an approval process. Chapter 4. Implementing the solution 139
  • 153. Requesting access to applications is done by accessing the WBI portal, where there is a list of applications that users may subscribe to. An example of this can be seen in Figure 4-6. Figure 4-6 Application subscription list Users may select the application to which they wish to receive access. This starts the approval process, which includes these actions: 1. Approval is requested from the BO Trade VP Manager and the service owner (in this case, the Sales department). If one of them rejects the process, it finishes, and a notification is made to the user by e-mail. 2. A request for information (RFI) process is done to the BO Trade VP Manager. 3. The account for the user is created automatically.140 Integrated Identity Management using IBM Tivoli Security Solutions
  • 154. Figure 4-7 shows the workflow used to accomplish this functionality. Figure 4-7 Workflow example Also, we defined Access Control Information in order that users can see, request, and modify specific information from these accounts. An ACI account type has been configured and placed for an object type TAM Account.4.2.3 Self care In this section, we take a closer look at WBI’s requirements, various design considerations, and WBI’s implementation. Requirements The productivity of WBI users needs to be increased. Currently there is a bottleneck caused by the amount of requests to the help desk. Large requests increase the workload of the help desk personnel and also create delays for WBI’s users. We should be able to address these issues by implementing the following self care functions: Challenge/response system Self resetting of passwords Self changing of user information (limited to specific information) This self care will be done by accessing the WBI portal, and the changes will affect the IBM Tivoli Identity Manager user data base. IBM Tivoli Directory Integrator will replicate the changes to the corporate directories (such as HR, IBM Tivoli Access Manager, and Microsoft Active Directory). The challenge/response function needs to be configured so that users can postulate at least four questions with prepared answers, in order to be able to reset forgotten passwords. This is done at the time a new user accesses the portal. For password resets, WBI wants to synchronize each user’s passwords on all directories, so there must be a process to accomplish this as well. Chapter 4. Implementing the solution 141
  • 155. The user will only be able to change their personal information: Name Work telephone number Home telephone number This list is sufficient for WBI’s purposes, although if necessary, this feature could be configured to allow changing of further information. Users must also be able to subscribe to new applications automatically, thereby improving their productivity. To accomplish this, we can use the application subscription process described in 4.2.2, “Application subscription” on page 137. Design considerations Since the self care function requires a different process to work (such as data synchronization, application subscription, and password reset), we need to be aware of several aspects of the implementation. First, this application will run on the WBI portal, so all users can access it. We will use the Web interface for user self-management (Web application sample) provided by the Provisioning Fast Start shipped with IBM Tivoli Access Manager Version 5.1, which uses several JSP files and servlets. The application runs on IBM WebSphere Application Server, and connects to IBM Tivoli Identity Manager using the Identity Manager API. For more information, refer to IBM Tivoli Identity Manager Provisioning Fast Start Guide version 5.1 manual. In order to perform this operation, all users must have an Identity Manager account. The password change option can achieved by using the graphical interface from IBM Tivoli Identity Manager; the Web application sample uses this feature. The user can change all their passwords in this manner. A back-end synchronization process must be running in order to make changes in the IBM Tivoli Identity Manager directory and to reflect these changes to all corporate directories. To provide the password change operation, we must configure the Web sample to connect to IBM Tivoli Identity Manager and allow users to do this. Once a user has changed their password at IBM Tivoli Identity Manager, a process for directory synchronization must start. We will do this throughout IBM Tivoli Directory Integrator Assembly lines, and synchronize the IBM Tivoli Identity Manager directory with the IBM Tivoli Access Manager directory and the HR directory. In order to maintain directory synchronization, IBM Tivoli Directory Integrator has be configured to read all changes in the Identity Manager directory. We will follow the data flow shown in Figure 4-2 on page 131.142 Integrated Identity Management using IBM Tivoli Security Solutions
  • 156. We have to configure the challenge/response option through IBM Tivoli IdentityManager, where we will configure the proper policies (ACI) to allow the users toperform this operation. Once again, when a change is made to IBM Tivoli IdentityManager directory, it will be reflected in all the directories involved.When a user needs to change some personal information (for example, theirhome telephone number), users will be able to perform this action by accessingthe WBI company portal. Users must have the permission to perform thisoperation, and after doing changes, directories must be synchronized again.WBI’s implementationWBI users should be able to access the self care application for implementingself care functionalities at the WBI portal; there is a link at the portal to accessthis application. With this application, users can choose to logon to self carefunctionalities or reset their passwords through the challenge/response function.In order to provide user self care, we need to perform the following tasks:1. Install a self care application that every user can access (Identity Manager).2. Give the user permissions to modify some information (such as passwords, personal information, etc.)3. Configure the challenge/response function.4. Synchronize data between directories.The first time a user logs onto the self care application, they must configure theirchallenge/response answers in order to be able to reset forgotten passwords.We used the Web interface for user self management, provided with IBM TivoliAccess Manager version 5.1 in the Provisioning Fast Start set. The Webapplication sample is mounted on an IBM WebSphere Application Server, and itis compliant with the referential architecture discussed in 3.2.3, “The operationalarchitecture” on page 102.This application features these functionalities: Reset of user’s passwords Challenge/response function Change of user’s personal information Self registration, as discussed in 4.2.4, “Self registration” on page 149In order to have all the functions working, we have established a data flowprocess shown in Figure 4-2 on page 131. With this flow, changes made in theWBI portal are written in the IBM Tivoli Identity Manager directory, and thedirectory synchronization process with IBM Tivoli Directory Integrator. Allchanges are reflected to corporate directories. Chapter 4. Implementing the solution 143
  • 157. The self care application connects directly to IBM Identity Manager. For example, here is the coding for a configuration using the itim_expi.properties located in the IBM WebSphere Application Server: #------------------------------------------------------ # IBM Websphere specific configurations #------------------------------------------------------ # Platform Context Factory Name platformContextFactory=com.ibm.itim.apps.impl.Websphere.WebSpherePlatformContex tFactory # Application Server platform.url=iiop://itim02.wbi.com:2809 platform.principal=enrole platform.credentials=enrole This information provides the application with the location of the server where Identity Manager is installed. Also, it is necessary to provide the information for the organization in the same file: #------------------------------------------------------ # Organizational information #------------------------------------------------------ tenantid=WBI tenantdn=ou=WBI,dc=wbi.com default.org=ou=WBI Please refer to the IBM Tivoli Identity Manager Provisioning Fast Start Guide, Version 5.1 for detailed information. When the user logs on to the self care application, with this initial entry, they are required to configure the challenge/response functionallity, as seen in Figure 4-8.144 Integrated Identity Management using IBM Tivoli Security Solutions
  • 158. Figure 4-8 User access to self care applicationIBM Tivoli Identity Manager must be configured in order to enable thechallenge/response functions. WBI’s administrator has completed this procedureand has configured the challenge/response as an Admin-Defined mode. In thisway, predetermined (administrator configured) questions will be presented to theuser, and the user is required to provide the answers for the configuration.The user can now logon to the self care application and make some changes toIBM Tivoli Identity Manage with this application. Once a change occurs, IBMTivoli Directory Integrator will synchronize the data between corporate directories(such as IBM Tivoli Access Manager directory). In order to be able tosynchronize data between directories, ITDI must be able to read changes madeto the Identity Manager directory. Identity Manager uses IBM Tivoli DirectoryServer Version 5.2 as the user data store. To read all changes, we configuredthe directory to log changes, as seen in Figure 4-9. Chapter 4. Implementing the solution 145
  • 159. Figure 4-9 IBM Tivoli Directory Server Configuration This configuration normally adds a specific value for changes, cn=changelog, which can be used by ITDI, to read changes and start the synchronization process.146 Integrated Identity Management using IBM Tivoli Security Solutions
  • 160. Configuration for ITDI can be done as seen in Figure 4-10.Figure 4-10 Connector to LDAP Change LogThis part of the configuration reads the log changes, and the normal operation isto perform the following actions:1. The change of directory is read.2. The process looks for the corresponding ITAM account.3. It reads some information from Identity Manager directory (such as personal information).4. The change is reflected in the directory. Chapter 4. Implementing the solution 147
  • 161. This process should be running in order to feed all the changes in the Identity Manager directory. For all functionallities at the self care application, there are some notifications to be considered. For the challenge/response function, you can generate a new password (based on policies) and have it displayed at the application, or you can send an e-mail notification with the new password, as seen in Figure 4-11. Figure 4-11 Password generation notification This notification process can be used for all the functionalities of self care applications. Optionally, we can also display the password generated on the application.148 Integrated Identity Management using IBM Tivoli Security Solutions
  • 162. 4.2.4 Self registration For self registration, we tnow ake a closer look at the requirements, the design considerations, and WBI’s implementation. Requirements By implementing the three areas mentioned above, WBI is now managing all their internal users in an integrated and centralized way. Since WBI has implemented IBM Tivoli Access Manager for e-business as an e-business enabler, protecting all Web based applications, with authentication and authorization enforcement, WBI now has the capability to permit customers (external users) to self register and permit access to specific applications. Since WBI is a financial company, their customers need to perform operations such as paying bills and checking their accounts. In order to register for this access, a customer must call WBI’s help desk. The help desk then verifies the customer’s information and processes a form. WBI then mails the customer their access information (Web site, userid, and passwords), a process that currently takes two business days. With the new implementation, WBI will enable their customers (external users) to register themselves at WBI through their Web portal. With this process, users can register, fill in a form, and send a request. Once the request has been approved (for example, in an automatic process), an e-mail notifying the approval must be sent to user with the data needed to access the external application (Web based and protected by IBM Tivoli Access Manager for e-business). Important: All access to this self registration feature must be protected by IBM Tivoli Access Manager for e-business, because confidential data may be sent to the server. Since it is possible to automatically provision user access to applications, the placement of users in a data store needs to be carefully planned, in order to prevent security violations that could occur when granting user access to internal applications. Therefore, you might want to consider using a different server than that used for the internal proposal. External users (WBI’s customers) should have the same self care functionalities as the internal users. This will also reduce or avoid calls to help desk. Users must have a IBM Tivoli Identity Manager account. To perform these operations, refer to 4.2.3, “Self care” on page 141. There may be an approval process to verify all data provided by the user, but this is optional and it depends on the application we are providing access to. In order to perform this function, we will use a workflow process. Chapter 4. Implementing the solution 149
  • 163. Design considerations To provide self registration functionalities to customers (external users), WBI will place an appropriate link at its portal. This link should comply with the referential architecture (as discussed in Chapter 3, “Applying the reference architecture” on page 53), and will communicate with the identity management server. Another consideration it is that since this is a self service for external users, we need to create specific policies to create users, passwords, notifications, and access to applications. At the IBM Identity Managers point of view, we should separate the administration of external users from internal users. We can achieve this in the following ways within Identity Manager: Create a complete new organization. Create a new location for external users. Use a different identity management server. As WBI has implemented specific security policies for each location, organization unit and global policies for the organization, we decided to create a new location for external users. In this location, we will provide access only to those applications for which external users could conceivably require access. With specific provisioning policies and ACIs, users can self register and automatically gain access to those applications, as well as subscribing to new ones. When a new account is created, an e-mail will notify the user of the data needed to access specific applications. All changes to user accounts will create an e-mail to notify the user. First time users will also configure their challenge/response function. For the self care functionalities, we will use data synchronization between directories (IBM Tivoli Identity Manager directory and IBM Tivoli Access Manager directory) provided by IBM Tivoli Directory Integrator. This is discussed in 4.2.3, “Self care” on page 141 section. By implementing specific policies for self care for external users, this functionality should also dramatically reduce calls to the help desk . To protect access to external applications, WBI is using IBM Tivoli Access Manager for e-business and the reverse proxy (WebSeal) to enforce the authentication and authorization process. WBI’s implementation Since WBI has implemented IBM Tivoli Access Manager for e-business to enforce authentication and authorization process for Web applications, we used IBM Tivoli Access Manager for protecting the self registration feature.150 Integrated Identity Management using IBM Tivoli Security Solutions
  • 164. WBI installed a self registration application, which connects directly to the identitymanagement server (Identity Manager), and it requests the information fromusers who want to register.This information can be configured and validated with an automatic process or amanual one. The result is the creation of an account, or the rejection of theprocess, in which case the users will be notified by e-mail. WBI wants all of theircustomers to have an account. Customers will be asked to supply the followingdata: Full Name First Name Last Name E-mail AddressThis self registration application can be configured to request more informationthan just the items noted above.We are using the Web interface for user self management provided with IBMTivoli Access Manager version 5.1 in the Provisioning Fast Start set. The Webapplication sample provides self registration functions. It is mounted on an IBMWebSphere Application Server, and it is compliant with the referentialarchitecture discussed 3.2.3, “The operational architecture” on page 102.In the IBM Tivoli Identity Manager organization tree, we created a new locationfor placement of self registered users. This location has its own services andpolicies, in order to not grant access to internal applications. The application towhich we will provide access is Web based, and the central data repository is theIBM Tivoli Access Manger directory.In this location, WBI has configured a service to provide the access, and it hasautomatic provisioning with e-mail notification, as seen in Figure 4-12. Chapter 4. Implementing the solution 151
  • 165. Figure 4-12 Internet customers location In order to place self registered users in this location, in the self registration application file (itim_expi.properties) located in the IBM WebSphere Application Server where this application is mounted, we configured the organization tree: #------------------------------------------------------ # Self-Registration specific information # - l = an LDAP attribute that represents a location reference # in the attribute Person object. (this must match # the attribute that is configured in the WorkFlow for # LOCATIONSEARCH - the default name of a workflow script # in the selfRegister entity object). # - org = the name of the Location object created in ITIM # where the self-registered users will be placed # by default. #------------------------------------------------------ orgContainer.selfregister.location.attr=l orgContainer.selfregister.location.org=Internet Customers152 Integrated Identity Management using IBM Tivoli Security Solutions
  • 166. With this information, the self registration application creates users at the correctorganization level tree, in order to apply the right policies. A user accesses theregistration page and provides the requested information, as seen in Figure 4-13.Figure 4-13 Self registration applicationProvisioning policies for the Internet Customer location includes the creation ofan account for IBM Tivoli Access Manager for e-business. As discussed, this canbe placed in a specific ITAM group of users, and the authorization model forITAM is based on the Access Control List, applied to specific points in the objectspace. For more details, refer to Part II, “Managing access control”, in EnterpriseSecurity Architecture using IBM Tivoli Security Solutions, SG24-6014-01.The automatic process is achieved with provisioning policies. Each of theexternal users will have an Identity Manager account in order to use the self carefunctions. Once this process has been completed, an e-mail such as the oneshown in Figure 4-14 is passed on to the user with the access information. Chapter 4. Implementing the solution 153
  • 167. Figure 4-14 E-mail notification for self register With this notification, the self registration process finishes, and the user can now access the application to which they have registered. It is important to notice that since we are using automatic provisioning policies, the design of the organization tree, the provisioning policies, and all procedures should be carefully reviewed before implementing them in a production environment. It is recommended that you first test all the procedures, and accomplish all your infrastructure according to the referential architecture discussed in Chapter 3, “Applying the reference architecture” on page 53.154 Integrated Identity Management using IBM Tivoli Security Solutions
  • 168. 4.3 Conclusion There are several important but frequently overlooked issues to consider when implementing an Integrated Identity Management solution: An Integrated Identity Management Solution must incorporate a broad range of business processes and functional areas beyond user provisioning and lifecycle management. Chapter 1, “An introduction to a new reference architecture” on page 3 provides a high level overview of the business issues and solutions typically found in an Integrated Identity Management scenario. There has to be a consulting process to integrate the disparate technical and business elements of the integrated solution. An overview of this process was provided in Chapter 3, “Applying the reference architecture” on page 53. In Chapter 2, “What Bank International” on page 17, a typical enterprise scenario was introduced, including business context and organizational aspects. Having depicted the overview of the enterprises requirement set, an approach to implementing the integrated identity management solution was introduced in Chapter 3, “Applying the reference architecture” on page 53, which also showed how a technical solution based upon the reference architecture meets the needs of a large enterprise such as WBI. An implementation of this solution was then described in Chapter 4, “Implementing the solution” on page 121. In WBI’s implementation, we have shown the most important configurations to consider when implementing an integrated identity management solution with IBM Tivoli Products. It explains the normal process in identity management projects, when involved in large enterprises: 1. Automatic provisioning with data feed from HR. 2. Data synchronization between corporate directories. 3. User self care functionalities (password reset, challenge/response function, modifying personal data information, and application subscription). 4. User self registration (to external users). The WBI example shows how to address these. There are some processes that were not covered here (such as installations), because it was not the purpose of the book. Please refer to the proper documentation for these processes. All processes in a big project should be approached in small parts, and include the necessary infrastructure to provide all required functionalities to end users. IBM Tivoli Security Solutions provide all the components to address an integrated identity management project. As shown in all the processes of this book, it is compliant with international best practices and standards. Chapter 4. Implementing the solution 155
  • 169. 156 Integrated Identity Management using IBM Tivoli Security Solutions
  • 170. Part 2Part 2 Appendixes© Copyright IBM Corp. 2004. All rights reserved. 157
  • 171. 158 Integrated Identity Management using IBM Tivoli Security Solutions
  • 172. A Appendix A. ISO 17799 compliance mapping The British Standard 7799 is the most widely recognized security standard in the world and has evolved in December 2000 into the International Organization for Standardization 17799 (ISO 17799). Facing the actual quests for management of the risks of information and safety of the systems in a context of extended company, the companies are asking for objective criteria and framework of reference for really managing the safety of information. The ISO 17799 approach is the use of the standard ISO 17799 as an enterprise reference framework and basis of a common language, including external partners. This chapter describes how an integrated identity management solution can be helpful for an ISO 17799 based approach. After an introduction to Corporate Policies and Standards, relevant parts of the ISO 17799 and integrated identity management solution are discussed next.© Copyright IBM Corp. 2004. All rights reserved. 159
  • 173. Corporate policy and standards Technology should not drive the corporate policy; it should be the other way around. Once you know what you need to protect and the potential threats and risks to those assets, you can start protecting them. First, all the threats and risks will be classified in a study based on certain elements, such as: Direct financial loss Indirect financial loss (such as investigation, recovery, and so on) Loss of confidential information Liability Image impact (loss of goodwill, customer loyalty, and so on) Cost of risk mitigation and/or transfer Accepting residual risk This study can process the same threats and risks applied to different assets, but concludes at a different level of liability, based on your particular business environment. Then the decision has to be made: accept, mitigate, or transfer the risk. This process can be handled by external consultants, such as IBM Global Services, or by an internally appointed team. The process can use both formal and informal methods, but the result is usually a blend of these approaches. The threat identification, as well as this severity study, using a formal approach is done in conjunction with the organization by applying a standard and a proven methodology. It is tempting to directly translate the threat analysis into a technical solution, but it should first lead to the corporate policy and standards. These documents will highlight the risks and present how they must be handled enterprise wide. The first document that must be written is therefore the corporate policy document. It must outline the high-level directions to be applied enterprise wide. It is absolutely not technical; it is derived from the business of the enterprise and should be as static as possible, as seen in Figure A-1.160 Integrated Identity Management using IBM Tivoli Security Solutions
  • 174. Static Corporate Policy Standards Standards Standards Standards ProceduresPractices ProceduresPractices Procedures Technical Figure A-1 Dynamics for policy, standards, practices, and procedures Attention: Policies is a very common term and in many products you will find specific policies sections. These are the product related policies that are covered in the practice or procedure documents. The corporate policy is not related to products and is a high level document.Standards, practices, and procedures Standards are derived from the corporate policy. They are documents explaining how to apply the policy details in terms of authentication, access control, and so on. They explain how the policy must be applied. Changes in threats or major technology changes can impact them. The standards are then mapped to practices and/or procedures. The practices are descriptions of practical implementations of the standard on an operating system, application, or any other end point. They will detail precise configurations, such as the services to be installed, the way to set up user accounts, or how to securely install software. Appendix A. ISO 17799 compliance mapping 161
  • 175. The procedures document the single steps to be applied to requests and the approval and implementation flows. Such a procedure could be the request to access a specific set of sensitive data, where the approval path (system owner, application owners, and so on) and conditions (Virtual Private Network (VPN), strong authentication, and so on) are explained in detail.Practical example Here is an example of how a policy is defined and implemented with procedures and practices. The operations manager has reported an increased workload on the help desk due to problems caused by employees downloading non-business related programs onto their systems. The problems range from the introduction of viruses to disruption of business processes, with a real financial impact. To address this problem, upper management incorporated, in the corporate policy, the following directive: “The corporate assets may be used only to perform enterprise related tasks”. First, the policy must be communicated to all employees in the enterprise. The standards for the networking part explain which services may be allowed on the employee computer. The practice will then explain how to set up the Windows or Linux clients according to the standards, and the procedures will explain how to perform a request, the requirements, and the approval paths, to get special services installed on your computer. The existing clients will be updated and controls will be performed to verify the compliance, in addition to further audit of the environment. The five steps we went through are summarized in Figure A-2. It is a common approach adopted in many methodologies.162 Integrated Identity Management using IBM Tivoli Security Solutions
  • 176. Policies Implement Risk Manage Audit Figure A-2 The five steps in defining your IT securityExternal standards and certifications The discussion on corporate policies suggests that internal business needs are the drivers for designing corporate policies. While this is true, there are a number of external factors that can change these business needs and policies as well. Some of these external pressures can be detailed enough to specify not only policies, but also standards and procedures. Examples of these external drivers are shown in this section. The list is not exhaustive, nor is each description complete. It is provided as a guide to the type of standards that may (or may not) apply to your organization and, therefore, some of the external factors you must consider when creating policies. Many organizations use these external standards as a guide to help them formulate their own corporate policies. It is not uncommon to find organizations using the ISO 17799 standards, but without having them externally audited and certified. These standards are seen as a good foundation for security. Appendix A. ISO 17799 compliance mapping 163
  • 177. Industry specific requirements Some industry sectors have standards that are specific to that industry sector. Two examples are: Identrus: The Identrus standards are based upon PKI technologies for authenticating secure transactions. In addition to the technology layers, Identrus provides a complete infrastructure to help companies operate effectively and safely on the Internet, across economic and political boundaries, and with familiar business partners and new ones. In addition to the technology standards and processes, Identrus describes an all important set of business rules, contracts, and liabilities that create a trusted environment particularly for use in the banking and finance sectors. CFR 21 Part 11: CFR 21 Part 11 applies to electronic records that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements covered by Federal Drug Agency regulations. Any pharmaceutical company that wishes to sell or market its products in America needs to abide by these rules. Corporate policies, standards, and processes need to reflect this requirement.Product or solution certifications Some products or solutions can be certified before use so that a potential purchaser has an understanding that the product or solution will fit the role it is needed for. Common Criteria This is a set of tests originally based upon the US Orange book and European/ Australian ITSEC evaluations. It is currently recognized by 14 countries. There are seven levels of tests. Evaluation Assurance Levels (EAL) 1 - 4 are usually used in the commercial areas, while the tests representing the higher EALs 5 - 7 are reserved for the security testing of highly secure environments. CAPS UK In addition to internationally recognized evaluations, local evaluations may impact an organization. The UK Governments Communications-Electronic Security Group (CESG) has produced the Assisted Products Scheme in effort to help commercial product vendors produce cryptographic products suitable for use by the British government. It is called CAPS (CESG Assisted Product Scheme). CAPS is similar in purpose to the FIPS 140 (for the US and Canadian governments) and the Cryptographic Advisory Note (CAN) (for the Australian and New Zealand governments).164 Integrated Identity Management using IBM Tivoli Security Solutions
  • 178. Nationally and internationally recognized standards Some standards bodies publish broad general sets of standards that an organization can implement. These standards can be audited and hence the organization can be sure they are complying. BS7799 The British Standard 7799 is the most widely recognized security standard in the world. The last major publication was in May 1999, an edition that included many enhancements and improvements on previous versions. In December 2000, it was republished again, and evolved into International Organization for Standardization 17799 (ISO 17799). It is intended to serve as a single reference point for identifying a range of security controls, needed for most situations, where information systems are used in industry and commerce within large, medium, and small organizations. BS 7858 BS 7858 is just one example of some of the other less, well known standards that could affect security policy. Specifically, BS 7858 gives recommendations for the security screening of personnel to be employed in an environment where the security of people, goods, or property is a significant feature of the employing organizations operations.Legal requirements The laws of the country in which an organization operates are many and diverse. The application of the laws is variable from geography to geography, and it is good to be aware of the impact of them upon corporate security policies. Modern democracies are often fond of creating freedom of information laws. One of the problems with these laws are that they are directly contrary to the same democracies’ wish to maintain the privacy of individual information. Privacy law is, therefore, a growing area. Some examples are: UK Data Protection Act 1998: An act to make new provisions for the regulation of the processing of information relating to individuals, including the obtaining, holding, use, or disclosure of such information. European Data Directive 95/46/EC: This directive and others give direction to issues surrounding the protection of individuals with regard to the processing of personal data and on the free movement of such data. The way they interact with national law must also be considered. Appendix A. ISO 17799 compliance mapping 165
  • 179. US Health Insurance Portability and Accountability Act 1996: The Health Insurance Portability and Accountability Act 1996 (HIPAA) was passed by the United States Congress to ensure the privacy of an individuals private medical data.ISO 17799 and integrated identity management The ISO 17799 standard provides guidelines and recommendations in the domain of the information security management. The audience for these is the people responsible for initiating, implementing, and maintaining security in the organization. As a code of practice for information security management, it includes direct or closely related objectives that can be discussed in conjunction with an integrated identity management solution. The ISO 17799 guidelines and recommendations cover ten domains and are introduced next. The purpose of this section is to show that an integrated identity management solution can help in managing security for an organization that tries to apply ISO 17799. The ten domains are as follows: Security policy: This domain provides management direction and support for information security. The security policy document should be the first way to introduce identity management solution benefits all along the organization, as integrated in automated business processes, for example. Organizational security: This domain introduces the information security infrastructure and discusses security aspects of third parties or for outsourcing scenarios. As part of this, security responsibilities, co-operation between organizations and access control agreements are introduced, including the use of unique identifiers, and the possible right to monitor and revoke a user’s activity. With these topics, most aspects of the overall identity management solution are part of the organizational security.166 Integrated Identity Management using IBM Tivoli Security Solutions
  • 180. Asset classification and control:This domain has the objective to maintain appropriate protection oforganizational assets (via inventory on information, software and physicalassets as well as services) and to ensure appropriate levels of protection,regarding classifications.This classification often generates projects for mitigation of risk on sensibleassets. This mitigation of risk includes the possible integration of specifictools that can be part of the integrated identity management solution.Personnel security:The closest sub-domain related to identity management is targeted onreducing risks of human error, theft, fraud, or misuse of facilities.The identity management solution can help with the automation of processesfor job related responsibilities or as part of auditing tools.Physical and environmental security:This domain is mainly related to physical aspects.But, it is more and more common to find automated controls for accessingpremises or sensitive information via authentication controls such as swipecards or PINs. In that case, identity recognition, access granting, and audittrails are also driven by the global identity management solution.Communications and operation management:For operational procedures, a segregation of duties implementation is one ofthe targets by reducing the risk for system misuse.With that, the enforcement of identity management is clearly a key point. Thisis also very useful for operational change control and audit trails.Access control:The business requirement for this domain is the need to control access toinformation by abiding to an access control policy in order to preventunauthorized access to information systems.This is precisely the major goal of an integrated identity managementsolution. Refer to 1.5, “Integrated identity in the enterprise” on page 11 for amore comprehensive description.Other related sub-domains are also covered by the integrated identitymanagement solution:– User access management, as the way to prevent unauthorized access to information systems, including user registration, privilege management, user password management, and possible review of user access rights.– User responsibilities to prevent unauthorized user access, including password uses, and unattended user equipment protections. Appendix A. ISO 17799 compliance mapping 167
  • 181. – Network access control for protection of networked services, including policy on use, enforced path, authentication for external connections or segregations when extending traditional organizational boundaries. – Operating system access control to prevent unauthorized computer access (including identifying and verifying identity, as well as ensuring quality passwords). – Application access control to prevent unauthorized access to information held in information systems, and other sensitive systems. – Monitoring for system access and use to detect unauthorized activities. With event logging, as part of a global risk management solution, the identity management solution assists in future investigations and monitoring. Systems development and maintenance: Ensuring that security is built into information systems is easier with the use of the enforcement framework provided by the integrated identity management solution. This applies to infrastructure, business applications, and even user-developed applications. This framework is also able to help to ensure that IT projects and support activities are securely conducted (all the way up to auditing access to system for administration teams). Business continuity management: This domain has the objective to counteract interruptions to business activities and to protect critical business processes from the effects of major failures or disasters. Compliance: For legal requirements, depending on country, the design, operation, use, and management of information systems may be subject to statutory, regulatory and contractual security requirements. In providing a complete documented framework for enforcement, as well as multiple audit trails and automation within workflows improving delegation and segregation of duties, integrated identity management solution is a key point to help achieving compliance. For complete information on ISO 17799 content, refer to the ISO internet site: http://www.iso.ch168 Integrated Identity Management using IBM Tivoli Security Solutions
  • 182. Summary Corporate policies must be thought of as business level requirements. They are primarily internal business drivers, but they may be impacted upon by external factors, so corporate policies will have to take account of these factors. Subsidiary standards and the procedures and practices that result in turn are also produced. Corporate policies should be relatively static and technology free, while standards, practices, and procedures can be more fluid and technology specific. For organizations interested in ISO 17799 compliance (or other security frameworks), the use of an integrated identity management solution is a good way to progress on the way to that compliance. Appendix A. ISO 17799 compliance mapping 169
  • 183. 170 Integrated Identity Management using IBM Tivoli Security Solutions
  • 184. GlossaryDMZ A DMZ (demilitarized zone) is an area of JNDI Java Naming and Directory Interfaceyour network that separates it from other areas of enables Java platform-based applications to accessthe network, including the Internet. multiple naming and directory services. Part of the Java Enterprise application programming interfaceJ2EE Java 2 Platform Enterprise Edition is a Java (API) set, JNDI makes it possible for developers toplatform designed for the mainframe-scale create portable applications that are enabled for acomputing typical of large enterprises. Sun number of different naming and directory services,Microsystems, together with industry partners such including file systems, directory services, such asas IBM, designed J2EE to simplify application Lightweight Directory Access Protocol (LDAP),development in a thin client tiered environment. Novell Directory Services, and Network Information System (NIS), and distributed object systems, suchJDBC Java Database Connectivity is an as the Common Object Request Broker Architectureapplication program interface (API) specification for (CORBA), Java Remote Method Invocation (RMI),connecting programs written in Java to the data in and Enterprise JavaBeans (EJB).popular databases. The application programinterface lets you encode access request JSP Java Server Page is a technology forstatements in SQL that are then passed to the controlling the content or appearance of Web pagesprogram that manages the database. It returns the through the use of servlets, small programs that areresults through a similar interface. specified in the Web page and run on the Web server to modify the Web page before it is sent to theJMS Java Message Service is an application user who requested it.program interface from Sun Microsystems thatsupports the formal communication known as Kerberos Kerberos is a secure method formessaging between computers in a network. Suns authenticating a request for a service in a computerJMS provides a common interface to standard network. Kerberos was developed in the Athenamessaging protocols and also to special messaging Project at the Massachusetts Institute of Technologyservices in support of Java programs. Sun (MIT). The name is taken from Greek mythology;advocates the use of the Java Message Service for Kerberos was a three-headed dog who guarded theanyone developing Java applications, which can be gates of Hades. Kerberos lets a user request anrun from any major operating system platform. encrypted “ticket” from an authentication process that can then be used to request a particular service from a server. The users password does not have to pass through the network. LDAP Lightweight Directory Access Protocol is a software protocol for enabling anyone to locate organizations, individuals, and other resources, such as files and devices, in a network, whether on the public Internet or on a corporate intranet. LDAP is a “lightweight” (smaller amount of code) version of Directory Access Protocol (DAP), which is part of X.500, a standard for directory services in a network.© Copyright IBM Corp. 2004. All rights reserved. 171
  • 185. LDIF LDAP Data Interchange Format XML eXtensible Markup Language is a flexible way to create common information formats andMASS IBM Method for Architecting Secure share both the format and the data on the WorldSolutions Wide Web, intranets, and elsewhere. For example, computer makers might agree on a standard orPII Personally Identifiable Information common way to describe the information about a computer product (processor speed, memory size,RBAC. With RBAC (Role Based Access Control), and so forth) and then describe the productsecurity is managed at a level that corresponds information format with XML. Such a standard wayclosely to the organizations structure. Each user is of describing data would enable a user to send anassigned one or more roles, and each role is intelligent agent (a program) to each computerassigned one or more privileges that are permitted makers Web site, gather data, and then make ato users in that role. Security administration with valid comparison. XML can be used by anyRBAC consists of determining the operations that individual or group of individuals or companies thatmust be executed by persons in particular jobs, and wants to share information in a consistent way.assigning employees to the proper roles.Complexities introduced by mutually exclusive rolesor role hierarchies are handled by the RBACsoftware, making security administration easier.ROI. For a given use of money in an enterprise,the ROI (return on investment) is how much “return,”usually profit or cost saving, results. An ROIcalculation is sometimes used along with otherapproaches to develop a business case for a givenproposal. The overall ROI for an enterprise issometimes used as a way to grade how well acompany is managed.If an enterprise has immediate objectives of gettingmarket revenue share, building infrastructure,positioning itself for sale, or other objectives, areturn on investment might be measured in terms ofmeeting one or more of these objectives rather thanin immediate profit or cost saving.SPNEGO Simple and Protected GSS-APINegotiation Mechanism.SSL The Secure Sockets Layer is acommonly-used protocol for managing the securityof a message transmission on the Internet. SSL hasrecently been succeeded by Transport LayerSecurity (TLS), which is based on SSL.172 Integrated Identity Management using IBM Tivoli Security Solutions
  • 186. Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.IBM Redbooks For information on ordering these publications, see “How to get IBM Redbooks” on page 173. Note that some of the documents referenced here may be available in softcopy only. Intra-Enterprise Business Process Management, SG24-6173 Business Process Re-engineering and Beyond, SG24-2590 Enterprise Security Architectures using Tivoli Security Solutions, SG24-6014-01 Centralized Risk Management using Tivoli Risk Manager 4.2, SG 24-6095 IBM Tivoli Privacy Manager Solution Design and Best Practices, SG24-6999 Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996 IBM WebSphere V5.0 Security WebSphere Handbook Series, SG24-6573-00 DB2 Warehouse Management: High Availability and Problem Determination Guide, SG24-6544 IBM WebSphere V5.1 Performance, Scalability, and High Availability WebSphere Handbook Series, SG24-6198-01 IBM WebSphere Portal for Multiplatforms V5 Handbook, SG24-6098How to get IBM Redbooks You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site: ibm.com/redbooks© Copyright IBM Corp. 2004. All rights reserved. 173
  • 187. Help from IBM IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services174 Integrated Identity Management using IBM Tivoli Security Solutions
  • 188. Index flow structure 68A management 13, 49access control 8 auditing 8 management procedures 65 authentication 7 policies 84 service 11access control list authorization 7 access management Authorization API 84, 91 access control list 93 authorization service 11access control management 11 automatic provisioning 127access management autonomy 38 application integration 71 availability 6, 110 business requirements 60 components 84, 91 delivery strategy 69 B enforcement gateway 84, 89 British Standard 7799 159 protected object policy 93 business process requirements analysis 60 re-engineering 63 solution types 62 business process management 49 technical requirements 61 business requirements 32 user registry 94 access management 60account business vision 30 automatic generation 127 creation 47 management 29 C capability assessment 57 provisioning 87 CIA Triad 5accountability 8 common criteria 164administration confidentiality 6 delegation 34, 47 conformance check 67application consent collection 77 components 89 CORBA 171application classification 67 corporate policy 160application subscription 37, 137 correlation 8approval process 49 countermeasure 42architectural decisions 50 Cross Domain single sign-on 117assembly line 127 custom agents 75assessment and planning life-cycle 55assessment stage 54asset value 42 Dassurance 6 delegated administration 47, 62attack identification 68 delivery strategyaudit 34, 39, 61, 65, 67, 73, 81 access management 69 access control 92 identity management 72 compliance 33, 76 privacy management 77 components 85 risk management 80© Copyright IBM Corp. 2004. All rights reserved. 175
  • 189. design life-cycle 58 provisioning 73directory and security node 103 requirements analysis 63directory integration 9 Role Based Access Control 74directory management 14 roles 72Directory Server server 86 components 87 user registry 94 workflow 73, 86 identity management node 104E Identrus 164e-business on demand 4 implementation life-cycle 54, 59EJB 171 integrated identity management 8, 11enforcement gateway 84, 89 component model 87enrollment 8 network communication 115enterprise systems node 104 pilot environment 122event correlation 8 solution overview 83eXtensible Markup Language 172 integrity 6 interfaces 65F internet client node 105federation of identities 9 intranet client node 105financial assessment 57 intrusion detection 13firewall ISO 17799 159, 166 configuration 109functional design objectives 47 J J2EE 171G J2EE application 85, 89–90group membership 131 Java Naming and Directory Interface 171 Java Server Pages 171 JavaScript 131HHR feed 73 JNDI 171HR procedures 21 job roleHTTP Server 85 change 38 JSP 171Iidentification 7 Kidentity and credential management 12 Kerberos 117identity federation 9identity lifecycle management 8 Lidentity management 47 LDAP 171 agent 86 liability 160 components 86 Lightweight Directory Access Protocol 171 custom agents 75 logging 8, 13, 32, 39 database 86 logical operational model 102 delivery strategy 72 Lotus iNotes 90 delivery strategy (alternate) 76 HR feed 73 orphan accounts 73 M Mail Server 85, 90 password management 73 managed targets 87 policies 72176 Integrated Identity Management using IBM Tivoli Security Solutions
  • 190. MASS provisioning 127 risk management 43 scripts 133meta directory Policy Database 84, 93 components 87 Policy Server 84, 92–93mitigation of risk 44 post password change library 119monitoring 8 privacy 7multiple domain model 111 control 8 legislation 66 policy 66, 78N privacy management 15network communication 115 components 86, 91network locations 107 consent collection 77network zones 45 delivery strategy 77non-functional design objectives 49 legislative compliance 79non-repudiation 32 monitor 78–79, 86nonrepudiation 8 requirements analysis 66 server 86O privacy monitor 79, 102on demand 4 protected object policy 93operational architecture 102 provisioning 8, 12, 32, 73orange book 164 policy 127organizational role 127, 131 scripts 133orphan accounts 73 Proxy Policy Server 93–94 purpose for PII data use 66Ppassword R generation 132 Redbooks Web site 173 management 73 Contact us xii policy enforcement 118 reporting 82 reset 34 requirements analysis strength library 119 access management 60 synchronization 87 identity management 63password management 48 privacy management 66password management procedures 65 risk management 68performance requirements 62 Reverse Proxy 93Personally Identifiable Information reverse proxy 45, 84 see PII reverse proxy node 105PII 66 risk 42 consent collection 77 acceptance 44 data types 66 assessment 42 discovery 67 mitigation 44 purpose for data use 66 transfer 44planning stage 54 risk managementpolicies 72 delivery strategy 80policy requirements analysis 68 corporate 160 Risk Manager enforcement 32, 36 see Tivoli Risk Manager management 48 role 127, 131 Index 177
  • 191. Role Based Access Control 12, 74 WebSEAL 93roles 72 Tivoli Directory Integrator 87 assembly line 127 components 98S Tivoli Directory Server 87scalability 110 Tivoli Identity Managerscripts 133 Agents 86Secure Sockets Layer 172 data flow 115security audit compliance 76 Database 86security design objectives 46 Lotus Notes Agent 90security domain architecture 111 password policy enforcement 118security enforcement password strength library 119 components 85 post password change library 119security policy 65 provisioning policy 127 enforcement 32 Server 86, 93security risks 69 services 127security zones 45 workflow 128self-care 8, 32, 34, 91, 93, 100, 141 Tivoli Privacy Manager 86self-registration 32, 91, 100, 149 components 101service 127 Tivoli Risk Managersession management 11 Adapter for Access Manager 91–93, 95single sign-on 8, 11, 61, 116 Adapter for Privacy Manager 96solution approach 57 components 95SPNEGO single sign-on 117 data flow 116SSL 172 Serverstrategy assessment 56 transfer risk 44subscription ... for applications 32, 37, 137 U userT add a new ... 47technical requirements autonomy 38 access management 61 management procedures 65threat 42 provisioning 12threat identification 68 user registry 94, 100Tivoli Access Manager ... for WebSphere Application Server 91 Authorization API 84, 91 V Cross Domain single sign-on 117 vulnerability 42 data flow 115 domain configuration 111 importing users and groups 113 W Web Application/Portal Server node 107 Management Domain 112 Web intrusion detection system 97 multiple domain model 111 Web Portal Manager 84 Policy Database 84, 93 WebSEAL 93 Policy Server 84, 92–93, 112 WebSphere Application Server 85, 90 Proxy Policy Server 93–94 Plug-In 89–90 Reverse Proxy 84, 93 Security Server 95 SPNEGO single sign-on 117 WebSphere Portal 85, 90 Web Portal Manager 84178 Integrated Identity Management using IBM Tivoli Security Solutions
  • 192. workflow 9, 49, 73, 128XX.500 171XML 172Zzones 107 Index 179
  • 193. 180 Integrated Identity Management using IBM Tivoli Security Solutions
  • 194. Integrated Identity Management using IBM Tivoli Security Solutions (0.2”spine) 0.17”<->0.473” 90<->249 pages
  • 195. Back cover ®IntegratedIdentity Managementusing IBM Tivoli Security SolutionsLatest technology in This IBM Redbook provides a solution-oriented overview ofaccess control and using Tivolis security products to provide an implementation INTERNATIONALidentity for integrated identity management based on real-life TECHNICALmanagement customer experience. SUPPORTsolutions ORGANIZATION When defining functional requirements for e-business related projects, you have to take into consideration a serious amountHolistically covers of security related tasks and disciplines. These disciplines aresecurity in authentication and credential acquisition, use of directory BUILDING TECHNICALe-business projects infrastructures, session management, multiple tiers of single INFORMATION BASED ON PRACTICAL EXPERIENCE sign-on, authorization, administration, users and policy,Best practices and accountability, and availability. Together they stand for theexperiences integrated identity management approach, an approach that IBM Redbooks are developed by should be regarded as a holistic way of tying security the IBM International Technical requirements into your projects. Support Organization. Experts from IBM, Customers and Partners from around the world This redbook is a valuable resource for security officers, create timely technical administrators, and architects who wish to understand and information based on realistic implement enterprise security following these guidelines. scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment. For more information: ibm.com/redbooks SG24-6054-00 ISBN 0738497843