Integrated Identity Management Using IBM Tivoli Security Solutions Sg246054

Front cover
Integrated Identity Management ment

using IBM Tivoli Security Solutions
Latest technology in access control and identity management solutions Holistically covers security in e-business projects Best practices and experiences
Axel Bcker Jaime Cordoba Palacios Michael Grimwade Loc Guzo Mari Heiser Samantha Letts Sridhar Muppidi
ibm.com/redbooks
International Technical Support Organization Integrated Identity Management using IBM Tivoli Security Solutions May 2004
SG24-6054-00
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 Tivoli Directory 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 ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Part 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
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Part 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
iv
Integrated Identity Management using IBM Tivoli Security Solutions
Industry specific requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Product or solution certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Nationally and internationally recognized standards . . . . . . . . . . . . . . . . . 165 Legal requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 ISO 17799 and integrated identity management . . . . . . . . . . . . . . . . . . . . . . 166 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Contents
vi
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX CICS DB2 Universal Database DB2 Domino e-business on demand Eserver Eserver ibm.com IBM iNotes Lotus Notes Lotus MQSeries Notes pSeries RACF Redbooks (logo) Redbooks Tivoli Enterprise Console Tivoli Enterprise Tivoli TME WebSphere z/OS
The following terms are trademarks of other companies: Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others.
viii
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.
ix
Figure 1 From left, Axel, Sridhar, Samantha, Jaime, Loc, and Michael
Axel Bcker 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 consulting
engagements. He has worked on various customer projects performing network and security assessments and architecting secure e-business infrastructures. Michael Grimwade is a Senior IT Architect with IBM Global Services in Australia. He has eight years of experience in delivering custom e-business solutions to large organizations. He holds a degree in Information Technology from the University of Queensland, Australia and has worked at IBM for six years. His areas of expertise include e-business applications, infrastructure and security, software architecture and design, and solution delivery methodologies. Loc Guezo is an I/T Security Architect in IBM Global Services. He is primarily involved in security architecture design, implementation, and security consulting engagements. He has three years of experience within the Security and Privacy practice in France, and focuses on Tivoli security products. Before joining IBM he spent nine years in different positions in banking, industrial, and health care environments, leading IT projects, building, and managing infrastructures. Loc holds a degree in Computer Science from Paris XIII University and a Masters degree in OSS - Security from Ecole Centrale Paris in France. Mari Heiser is a senior I/T Architect with IBM in the United States, specializing in security and network architectures. She has 19 years experience in the I/T industry related to networking, Web infrastructure and enterprise security solutions. She holds a degree in Education from The Cleveland State University as well as a degree in Electrical Engineering. Her areas of expertise include Tivoli Access Manager, Tivoli Identity Manager, LDAP, e-business infrastructures and networking. During the last few years, she has worked on various customer projects performing network and security assessments and architecting secure eBusiness infrastructures. She has written and edited several books relating to the 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 in Commerce, majoring in Business Systems and Management, from the University of Wollongong, Australia. She has eight years of experience with IBM Australia software defect support. She has spent the last two years working on Tivoli products in the security area. Sridhar Muppidi is a Senior Security Architect working in the Tivoli division of IBM Software Group. His area of expertise is providing secure and manageable e-commerce solutions to enterprises and their edge systems, which includes architecting solutions for customers, working on new product developments, and standards work. Prior to this, Sridhar was a Security and Directory Architect in IBM's Global Services group. Sridhar obtained his M.S. and Ph.D. from Texas A&M University in 1992 and 1996 respectively.
Preface
xi
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 O'Mahoney, Andrew Jupp IBM UK
Become a published author

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

[email protected]
Mail your comments to: IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493
xii
Part 1
Part
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.
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 todays 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
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 Increase Security & Resiliency Increase business flexibility Extract greater value from data Improve the customer experience Drive business innovation Optimize todays IT investments Improve employee productivity Streamline/simplify processes
1
Innovate the business to differentiate and capture new value
2
Make better use of resources to be more productive
Figure 1-1 Innovation and productivity are linked to increased security and resiliency
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 Internets 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
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.
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 doesnt automatically grant authorization.
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 todays 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)
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 arent 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.
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.
Users
Other Applications
Access Management
Users
Policy - Provisioning - Password - ID - Workflow (Int. and Ext) - Service Selection - Roles - Organization - ACI Provisioning
Authentication / Password Policy Business Partners
LDAP App. Provisioning - IM LDAP or
Secure Enforcement Proxy Gateway Server
Self Help, Help Desk, Del. Admin API Self Registration JAAS, JACC, WIM API User, Group lookup
Identity management
Directory Server - AM
Administrators
Applications
Web Trust - Portal Server - App. Server - Content Server Message security, Cred. Maping Secure Data Access
Privacy Enforcement
Privacy Privacy Management mangement
Security Enforcement - Authentication - Cred. Acquisition - Authorization - Single Sign-On - Policy Enforcement - Auditing
Meta directory
HR Data
Database
Authoritative data
Managed Targets Managed Targets
Identity management related components
Application components
Infrastructure components
Figure 1-2 Integrated identity management reference architecture
10
Provisinoing
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 resources 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 requesters 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.
11
Rule based authorization grants or denies access based on a users 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 users 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 users 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
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 wayafter 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
13
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
1.5.5 Privacy management

Websters 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 todays 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 childrens 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.
15
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 dont violate too many regulations and they dont 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
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.
17
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 RW RC RE Regional center Europe (London, UK) and the peripheral IT data center Regional center West (San Francisco, California) Regional center Central (Paris, Texas) and the central IT data center 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
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.
Seattle
New York (Customer Service & Regional Center East)
Detroit
San Francisco (Customer Service & Regional Center West)
Denver St Louis
Raleigh
Paris (Customer Service & Regional Center Central)
Los Angeles
Paris, TX IT Center
Figure 2-1 Geographic distribution of WBI sites for the continental US
Chapter 2. What Bank International
19
London (C ustom er Service & Regional Center Europe)
Paris
London, UK IT Center
Rom e
Figure 2-2 Geographic distribution of WBI sites for the European division
2.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 W est
R e g io n C e n tra l
R e g io n E ast
R e g io n E u ro p e
C o re S e rvic e s
Figure 2-3 Key areas for WBI company
20
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 Services Card Services Account Services Broker Services IT Center HelpDesk Tech Support HR
Customer
Seattle
Los Angeles
CSC
Figure 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
Partners
Marketing
IT Data Center
HR
Accts
BO Trade
GA
Systems
HelpDesk
IT Dev
Figure 2-5 Core Services organization chart
2.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.
21
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 employees 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 users 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 initiative
22
The security infrastructure deployed for the e-business initiative The secured e-business initiative architecture Identity management and emerging problems
2.2.1 Overview of the WBI network

WBIs 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 WBIs 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 IT Center
T3 (45Mbps)
to Europe
Figure 2-6 High-level network diagram for the continental United States
23
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
T 3 (4 5 M b p s )
P a ris
to C e n tra l
Rom e
Figure 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
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 Administrators Guide Version 5.1, SC32-1359.
25
3. WebSEAL accepts or denies the login. WebSEAL works as a reverse-proxy between the users Web browser and the application hosting Web server, controlling whether a user can access the requested resource or not. WebSEALs 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 users 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 customers account, personal trading operations, special campaign information, and so on) via the Internet. A customers 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
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.
27
Central IT Center
Central IT Center, Paris

Web Portal Server AIX
z/OS (DB2,MQSeries)
I BM
F I R E W A L L
FIREWALL LDAP Master Access Manager Policy Server
F I R E W A L L
WebSEAL
F I R E W A L L
LDAP LDAP LDAP replicas replicas replicas
Identity Management Server

Management zone
F IR E WALL
4 Regional centers
LDAP Replica WebSEAL
Production Zone
F I R E W A L L F IR E WALL
Access Manager Proxy Policy Server

Management Zone
Internet DMZ
application data flow access control flow Identity mgt flow

Figure 2-8 Entire WBI architecture
WBI sites
Intranet Windows Domain
2.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
Actual processes
WBI uses many different platforms with user accounts in their system. The staff at the WBI sites have accounts in a Windows domain and the LDAP directory (for WebSEAL controlled Web application access). The regional center administrators have accounts on the central AIX systems, as well as the Windows domains in their region and the LDAP directory. All these accounts are managed by the regional center administrators using operating system or LDAP specific interfaces. Windows domain accounts are created with the Windows NT User Manager, AIX accounts with the smitty interface, and LDAP accounts with the pdadmin command line utility or the Web Portal Manager shipped with Tivoli Access Manager for e-business. Programmers and developers in the central IT data center have their accounts on all platforms in the enterprise, including z/OS. Due to their specific tasks and influence, they often manage their own accounts with administrative rights the regional administrators are not involved. Accounts on z/OS are created using the RACF interface provided with z/OS. Since customers are accessing the WBI applications by Web browser interface only, 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 expand this business area in the future, specific policies and procedures need to be designed for handling and maintaining these accounts.
Emerging problems
As mentioned above, all employees have several types of accounts, and they must maintain multiple sets of user ID and password combinations. Employees have to call a regional administrator in order to reset the password. Especially after the new periodical password change policy has been applied, more and more password reset requests come to the attention of the regional administrators. 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 users 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 managers 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).
29
Too many requests cause regional administrators not to reply immediately, and some employees cannot continue their work because their accounts remain inaccessible. When a users manager is not available temporarily, the password reset procedure gets even more delayed. 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
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.
31
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 functionality
32
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).
33
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
OBJECTIVE I.1: Identity management should be performed immediately and correctly. 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: Passwords should be changed periodically for the company's security policy. I.1-a13: Almost all administrative tasks are executed by administrators with any security level. I.1-a2: It is time consuming to manually manage internal user data or to execute requests - this is unmanageable for external users I.1-a21: Different interfaces for every type of accounts. I.1-a22: Values are entered manually by administrators. I.1-a23 Often, operations need to be redone because of mistakes. REASON I.1-b: It may take to much more time to get an approval. 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. I.1-b2: For external customers,quick account manager approval or immediate automatic basic creation are needed.
Functional requirements
FR1.1 : A single password for user's accounts.
FR1.2 : Delegate lowsecurity administration tasks to others including end users.
FR1.3 : User-frendly interface. FR1.4 : Central common interface. FR1.5 : Common values are entered automatically. FR1.6 : Value checking function is required.
FR1.7 : Automate business processes.
FR1.8 : Integrate business processes into user administration system.
Figure 2-9 WBI functional requirements, part I.1
35
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
OBJECTIVE I.2: The corporate security policy should be enforced for all accounts.
REASON I.2-a: Accounts with invalid attribues may be manually created by mistake.
I.2-a1: Every type of account has a different way of definition. I.2-a2: Manual operations may cause invalid values.
FR2.1 : Centrally crosswide user management.
FR2.2 : Common values are entered automatically.
V2-a3: No value-checking function.
FR2.3 : Value checking 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: Enforcement is immediate and utomatic
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 CEOs 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.
37
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 CIOs 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
OBJECTIVE I.3: Further cost savings and enhancement of "autonomy"
REASON I.3-a: Reduce manual activities for managing accounts by job roles I.3-a1: Use an authoritative HR source FR3.1 : Centrally crosswide user management.
I.2-a2: Define Company job roles
FR3.2 : Common values are entered automatically.
I2-a3: Automatically grant access and generate changes / job role I2-a3: Automatic process should be auditable REASON I.3-b: IT resources will focus on other tasks than user management I3-b1: Users will have self care functions I3-b2: Autonomous users will manage their related sphere with selfregistration and self subscription to applications
FR3.3 : Integrate business processes into user administration system. FR3.4 : Provide audit trails
FR3.5 : Value checking functions are needed.
FR3.6 : Delegate administration tasks and registration tasks to end users. FR3.7 : Automate business processes.
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.
39
OBJECTIVE I.4: Corporate-wide user management data has to be available for 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: There is no integrated logging system. REASON I.4-b: External user identity is the link for in e-business for nonrepudiation mechanisms or forensics activities I.4-b1: There is no integrated logging system. I.4-b2: In case of need (for nonrepudiation mechanisms or forensics activities), link between identity and person has to be backward established
FR4.1 : Central logging system is needed.
FR4.3 : Integrate business processes into user administration system.
FR4.4: Provide audit trails
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 be utilized and new implementations should be reasonable.
REASON I.5-a: Existing investments in Tivoli Framework system, WebSphere portal solution, and Access Manager for e-business system.
FR5.1 : Integration with existing systems.
40
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 perimeters 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.
41
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? IBMs 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
IBM MASS includes a four-step risk management approach, as shown in Figure 2-14, consisting of these actions: Identify vulnerabilities Identify threats/agents Determine risk Identify countermeasures
Assets
Identify Vulnerabilities Vulnerabilities
Identify Threats/Agents
Threats
Determine Risks Risk
Identify Countermeasures Countermeasures
Residual Risk
Acceptance
Figure 2-14 Four step risk assessment approach
This approach provides a logical flow, from the threats to the countermeasures, which should be designed into the architecture. Thus, it anchors the IT Security Architecture firmly in the business requirements and addresses the major risks that the business faces and mitigates losses that can be estimated. The company focuses on those countermeasures that will address the major risks. It assists the business case for the architecture, because there is an estimate of the losses that it is designed to avoid.
43
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 risks 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
The outcome or objective of a threat and risk assessment is to provide recommendations that maximize the protection of confidentiality, integrity, and availability 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 failures Based on the risk assessment, we present our security recommendations as follows: 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)
45
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 dont 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
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.
47
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
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 managers 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.
49
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
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.
51
52
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.
53
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 IBMs 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
Assess and Plan Life-Cycle
Design Life-Cycle
Implement Life-Cycle
Client Environment
Solution Outline
Solution Build
Strategy
Macro Design
Pilot
Assessment
Micro Design
Deployment
Solution Approach
Transition Planning
Figure 3-1 Implementation life-cycle
Assessment and planning life-cycle

There are five phases in the assessment and planning life-cycle: Client environment Strategy Assessment Solution approach Transition planning
Client environment
The purpose of this phase is to collect the relevant data about the organizations business and IT environment that are required to assess and plan both current and future identity management solutions. The organizations business and IT environment is examined to determine what identity 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
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 organizations various business areas and IT systems.
Assessment
This phase has three purposes: To assess the organizations 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 areas
56
The capability assessment identifies the areas where the current environment is unable to support the identity management strategy and also examined to find inhibitors to change. Known issues can help to identify these areas. The assessment is performed at an enterprise-wide level and may find, for example, that an investment in tools is planned, but the administration organization is in such a state that it will be unable to support the tools. The financial assessment will identify areas where substantial benefits can be obtained, as the cost structure is such that a considerable return of investment may be achieved. The capability and financial assessment, along with the business drivers and the business and IT strategy, will identify priority areas.
Solution approach
The purpose of this phase is to determine the solution approach and to perform an initial cost benefit analysis. Defining an overall approach is the next step in establishing a road map for implementing enterprise-wide identity management. Once the approach has been defined, a preliminary cost benefit analysis can be made that will further prioritize the initial set of focus areas that were identified in the Assessment phase. The organizations that are likely to be impacted by the solution approach should be informed about any plans considered at during the phase. This creates awareness, provides early feedback and enhances stakeholder commitment.
Transition planning
The purpose of this phase is to plan the transition towards an enterprise-wide identity management solution. Transition planning first produces a transition strategy and then develops a road map for implementing the strategy. The strategy establishes various transition approaches. For each approach the risks are evaluated, priorities determined based upon risk, business priorities, and cost/benefit ratios defined. A business case may be developed to justify initial approaches if required. The road map establishes dependencies between related areas, and the high level work streams are identified and prioritized. Finally, the detailed scope is defined for the first project(s).
57
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 phases 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
Micro design
This phase creates the detailed design and implementation plans required to deploy the integrated identity management solution. Detailed architectural documents are developed in this phase, and if business process or organizational changes are being implemented, detailed workflows, job descriptions, measurements, and reports are also defined. All documentation is produced at a level of detail that is sufficient to implement the solution. This typically includes the selection of vendors and products to apply to the specified design and also the details required to procure equipment and budget for the implementation stage. It should also produce physical design details, such as floor plans, rack layouts, power requirements, and so on. At the conclusion of the micro design, a design review is conducted with all stakeholders in order to progress to the next stage of the project.
Implementation life-cycle
The implementation life-cycle has three phases: Solution build Pilot Deployment
Solution build
The purpose of this phase is to develop detailed configurations for the identity management solution based on the design specified in the preceding stages of the life-cycle. The solution build will be performed in a development and test environment. This is a limited scale environment that is representative for production but does not interfere with the actual production environment. During this phase installation and configuration, scripts or procedures are developed, detailed product and tool configurations are built, and required educational materials and other documentation is prepared. This phase also establishes the supporting processes and organizational changes required by the solution.
Pilot
The pilot phase validates the systems and implementation procedures in a limited scope production environment. In the case of a network this may be a single site, single floor in a building, or subset of the production environment. The same would hold for servers or workstations. The main idea is to plan a pilot implementation that will test new design and implementation procedures, and user training in a production environment. The selection process for the target environment should take into consideration the scope of the test and that enough variety exists to ensure that all aspects of the design are tested prior to the production deployment. During this phase, any required adjustments are made to either the implementation procedures or the design.
59
This phase, the ultimate test of the design and development activities, implements the end-to-end identity management solution in a portion of the client's 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 enterprises 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
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 enterprises 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 access management solution, and is also one of the most frequently misunderstood access management concepts. Key issues in developing SSO requirements include 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.
61
Compatibility of standards: Compatibility with the enterprises 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 users 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 enterprises 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 deployment
62
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 enterprises 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 Enterprise Security Architectures using Tivoli Security Solutions, SG24-6014-01. Let us now take a closer look at the identity management solution.
Identity management
The identity management solution comprises both business (or procedural) and technical (security subsystem-specific) functionality. An implementation will not just involve installing identity management technology; there will be integration with existing business procedures and perhaps some business process re-engineering (BPR). Both technical (product-related) and business (process-related) skills are required in the assessment and planning stage, and the solution design stage, of the implementation life-cycle. To deliver an effective identity management solution, the project team must understand 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
63
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
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 this redbook. 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-2590 In summary, the business and technical requirements that should be captured as part 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 and workshops with the people and teams involved in identity management. This may include the IT executive, security management/administration team, operations, help desk, key technical teams (such as system administrators) any application development teams and business managers involved in the project.
65
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 enterprises 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 doesnt 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 customers 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
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 enterprises user registries. Application Classification, also known as PII Discovery, is the principal privacy analysis activity. Its goals are to identity applications that access PII data, and also the optimal order in which to privacy enable these applications. Typical questions 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 applications priority, based on organizational objectives? Common examples of how an organization may choose to prioritize applications for 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 first Finally, requirements analysis must determine what mode of operation will be used, 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.
67
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 enterprises 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 enterprises resources. Unauthorized access to the enterprises 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
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 enterprises 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.
69
Requirements Analysis/ Micro Design
Deploy a Single Site
Deploy Applications
Implement Multi Site Failover
Enhance a 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 enterprises 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 enterprises 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 infrastructure
70
For subsequent sites, the ability to improve application response times and infrastructure availability
Deploy applications
This phase deploys one or more applications that have been built to leverage the access 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 standards The 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 centralized access management and include: Reduced application development costs/time frames Flexible, consistent application security policy enforcement Single sign-on improved user experience, simplified identity administration
Implement multi-site fail-over

In this phase, existing sites are linked together to enable fail-over support. This improves overall infrastructure availability.
Enhance a single site

An enterprises access management requirements naturally evolve over time. Some changes are relatively simple, such as increasing the number of supported users. Other changes are more complex, such as modifying technical integration standards. In either case, existing sites may need to be enhanced to meet these changing requirements.
71
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 Foundation & Password Management Phase 2 Automate provisioning of standard accounts Phase 3 Roles and Policies Defined - RBAC Phase 4 Custom Agents Phase 5 Maturity
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 enterprises 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
Once the foundation Phase 1 is complete, if business needs require, it is possible to change the focus and content, and to commence a project phase to deliver any element of the subsequent phases. Certain prerequisites may be required, but none that would disallow the activity; although it may extend overall implementation time and costs.
Phase 1: Foundation and password management

The first phase focuses on delivering high visibility, high value benefits quickly and with minimal impact on existing systems. These benefits are typically realized by implementing self-service password reset and managing orphaned accounts. 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 accounts The 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 available The 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 time
Phase 2: Automatic provisioning for infrastructure accounts The second phase automates the provisioning process for standard accounts
and resources. The scope of phase 2 includes: Automatic provisioning of standard accounts and workflow Consistent GUI for administration Consistent account creation Full audit trail
73
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 reporting
74
Phase 4: Develop custom agents

The fourth phase continues the work of phases two and three with non-standard applications 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 management The expected outcomes of phase 4 are: Templates for later roll-out established All significant applications covered The 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 automation
Phase 5: Maturity
By now, the initial deployment of the identity management solution is complete. The fifth phase covers the ongoing evolution of the identity management solution as new business roles, applications, and infrastructure are added to the IT environment. 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
75
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.
Custom Agents
Foundation & Password Management
Auto Provisioning and workflow for standard Accounts Maturity 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 organizations 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
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 business The 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 resources While 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 cost
Privacy management
This section describes an incremental approach to delivering a privacy management solution as depicted in Figure 3-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 possible and also become self reliant as soon as possible.
Phase 2 Monitor Implementation Phase 3 Privacy Enablement
Phase 1 Foundation
Phase 4 Maturity
Figure 3-5 Privacy management delivery strategy
Phase 1 delivers the infrastructure required to notify data subjects of the enterprises privacy policy and also to record their consent to having their PII data used in accordance with the policy. Notification and consent are typical requirements of privacy legislation. Consent is also typically required to meet the conditions associated with PII data use, such as a customer having to opt-in to receive marketing material.
77
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 enterprises 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 subjects 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 employees understanding and commitment to the policy.
78
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 enterprises brand perception. Employee training records may be useful in dealing with incidents where the privacy policy has been breached.
Phase 2: Monitor implementation

The second phase is only required when there are application-types that must be privacy enabled but are not supported by existing monitor implementations. Monitor implementation is discussed in detail in IBM Tivoli Privacy Manager Solution Design and Best Practices, SG24-6999-00. Typically a custom monitor implementation will be usable by all applications of the same technology type. The target application-types and sequencing of phase 2 iterations will be determined by priorities defined during requirements analysis. The scope of phase 2 is to implement an application type-specific privacy monitor. The expected outcome and benefit of this phase is that a new application type can be privacy enabled.
Phase 3: Privacy-enablement
Each iteration of the third phase privacy enables a single application. The sequencing 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 policy The benefits delivered by phase 3 include: Regulatory compliance Visibility of employee compliance with corporate policies
7
Integration may require monitor or application customization.
79
In many cases, improved corporate visibility of which applications access specific types of corporate data. Maintain or enhance the enterprises 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 1 Foundation
Phase 3 IM Adapter Implementation
Phase 4 Centralized Risk Management
Phase 5 Maturity
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
Phase 1 delivers the infrastructure required to capture all audit and security events. The goal of phase 2 is to add value to the raw events captured by the infrastructure delivered in phase 1. This phase is critical to delivering an efficient risk management solution. Phase 2 can begin before the end of phase 1 and continue 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 identity management components are integrated with the risk management components. Phase 4 can run in parallel with phase 2 and 3. It addresses the operational and organizational aspects of the centralized risk management solution. Phase 4 is dependent upon on the definition of security processes, procedures for supporting and acting inside the enterprise. Phase 5 marks the total integration of identity management components into the enterprises centralized risk management solution.
Phase 1: Foundation
The goal of this phase is to deploy risk management components throughout the enterprises IT infrastructure components and begin capturing security event data. The configuration of what data is captured and how it is used will be refined in subsequent phases. This phase provides a foundation for risk management capability that will be further developed in subsequent phases.
Phase 2: Tuning
The goal of this phase is to increase the capability of the risk management solution by providing qualified information to security administrators and at the same time protect the infrastructure from the huge number of flow events and degradation of real-time supervision. These features are critical in large environments. 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
81
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 enterprises security level via the qualified visibility of system activity available to security administrators Management reporting
82
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 WBIs 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 WBIs 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 Users Enforcement Gateway Reverse Proxy Authorization API Self Help, Help Desk, Del. Admin TIM API Self Care/ Registration TIM API Identity Management Identity Manager Server Identity Manager Agents Identity Manager DB User, Group lookup Applications HTTP Server WS App/Portal Server Mail Server LOB Applications Security Enforcement Risk Manager Server Risk Manager Clients Secure Data Access Privacy Enforcement Privacy Management Privacy Server Privacy Montiors App. Provisioning Directory Server User Registries
Meta Directory Directory Integrator
Enterprise Data
Managed Targets Enterprise Systems
Figure 3-7 WBI architecture overview
Each of the major functional areas is described in the following sections.
Provisinoing
83
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. The Policy Database provides secure storage for the security policies that are utilized by other Access Management and Enforcement Gateway components. The Web Portal Manager provides an administrative interface for maintaining the security policies and infrastructure configuration.
Policy Database
Web Portal Manager
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 enterprises 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. The Authorization API allows applications to leverage the central access management infrastructure when implementing fine grained authorization services.
Authorization API
These components are described in further detail in Access Management components on page 91.
84
Applications
Application components provide the infrastructure to required to run the enterprises 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 enterprises business activities. These components are described in further detail in Application components on page 89.
Security Enforcement
Security Enforcement components provide a mechanism to monitor all activity within the processing environment in real time. Suspicious activity is identified automatically and appropriate corrective action taken. The key Security Enforcement 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 are deployed throughout the enterprises IT infrastructure and applications to capture information about system activity for processing by the server.
Risk Manager Clients
These components are described in further detail in Audit components on page 95.
85
Identity Management
Identity Management components provide centralized identity administration functions that can improve an enterprises 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 enterprises target systems. 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 Agents
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 enterprises 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 enterprises privacy policy and also audits privacy-enabled applications use of personally identifiable information. Privacy Monitors are deployed within applications to enforce the enterprises privacy policy.
Privacy Monitor
These components are described in further detail in Privacy Management components on page 101.
86
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 WBIs integrated identity management solution. It documents each components: 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.
87
Risk Manager Gateway Risk Manager Server RM Adapter for AM
Risk Manager Clients AM Web Portal Manager
Sensors
HTTP Client
HTTP Admin Client
Mail Server
Reverse Proxy
Proxy Policy Server
AM Policy Server
IM AM Agent
IM Lotus Notes Agent
HTTP Server WAS Plug-in
RM Web IDS
Replica Policy Database
Master Policy Database
Self Reg Self Care LOB Applications WebSphere Application/ Portal Server
WAS/WPS Security AM Plug-in/API Privacy Monitor
Replica User Registry
Master User Registry
Enterprise Data/ Systems
Directory Integrator
IM Agents
Enterprise Client
IM Database
RM Adapter for TPM Application flow Audit Flow
Privacy Manager Server
Identity Manager Server
IM User Registry
Existing Components (Current IT Infrastructure)
Access control flow Identity management flow Abbreviations: AM Access Manager IM Identity Manager New Components RM Risk Manager IDS Intrusion Detection System
Figure 3-8 Component model
88
Application components
The following application components are part of the current IT infrastructure as described in Chapter 2, What Bank International on page 17. For detailed information on Web application security, refer to the redbook IBM WebSphere V5.0 Security WebSphere Handbook Series, SG24-6573-00.
Enterprise Client
The Enterprise Client component represents all non-Web application components used by intranet-based employees to access enterprise data and systems, such as Visual Basic applications and terminal emulation programs.
Enterprise Data and Systems

The Enterprise Data and Systems components represent all of the non-Web based IT applications and infrastructure within the enterprise, such as relational databases, CICS applications and file servers. Enterprise data and systems provide aspects of the database and managed target functionality defined in the reference architecture as shown in Figure 1-2 on page 10. Some enterprise data is accessed via Web-enabled applications that are secured using the components described in Access Management components on page 91. Many enterprise data and systems are not Web-enabled, and are access directly via enterprise clients. These systems use their own Access Management components, which must be integrated into the overall Identity Management solution.
HTTP Client
The HTTP Client provides the user interface for Web-based application and static content. It is the component used by users, business partners and administrators, as defined in the reference architecture shown in Figure 1-2 on page 10, to submit requests to the enforcement gateway. The enterprise has standardized on Microsoft Internet Explorer for all intranet-based HTTP Clients. Internet-based HTTP Clients cannot be standardized, and multiple client implementations must be supported.
HTTP Server
The HTTP Server processes requests from HTTP clients. Requests for static content, such as images, are serviced directly by the HTTP Server. Requests for dynamic content, such as J2EE application pages are handed off to the WebSphere Application Server Plug-In for processing. The HTTP Server provides application functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by IBM HTTP Server using binary executables.
89
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
WebSphere Application Server/Portal interacts with other components as follows: 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 components

The following Access Management components are part of the current IT infrastructure 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 Server

The Tivoli Access Manager for WebSphere Application Server plug-in integrates into WebSphere Application Server and WebSphere Portal to replace their native authorization functionality with Access Manager components. The plug-in 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 for e-business as a set of Java classes that run within the WebSphere Application Server. The Access Manager for WebSphere Application Server plug-in/authorization API 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.
91
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
The enterprise has standardized on Microsoft Internet Explorer for all intranet-based HTTP clients.
Master/replica policy database

The master and replica policy databases provide a high performance, highly secure proprietary database that holds all access management related security policies, such as rules, protected object policies, and access control lists. The policy database 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 using a flat file and in-memory cache. The master policy database is deployed in a secured network zone and provides read/write access for both access control and system administration tasks. The master 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 provide read-only access to the policy information required by the authorization API, Proxy Policy Server, Authorization Server, and Reverse Proxy components.
Reverse Proxy
The Reverse Proxy authenticates and authorizes all HTTP access to production systems, and also performs the password change self-care function. The proxy provides enforcement gateway functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Access Manager 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 clients 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 clients 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.
93
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
The Proxy Policy Server receives requests from other Access Manger components (such as replica policy database update requests), and forwards them on to the Policy Server.
WebSphere Security Server

The WebSphere Security Server provides security policy enforcement within WebSphere Application/Portal Server. The server provides enforcement gateway functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented as an by WebSphere Application Server as an internal 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 components
The following Audit components are part of the new integrated identity management solution as described in 2.2.5, Identity management and emerging problems 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 Manager

The Risk Manager Adapter for Access Manager scans the audit logs of all Access Manager components 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 Reverse Proxy, Policy and Authorization Servers, and passes details of any potential security incidents to the Risk Manager Gateway or Server.
95
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 enterprises incident response policy.
10 11
Running within WebSphere Application Server. Running within DB2 Universal Database.
96
Risk Manager Gateway

The Risk Manager Gateway may improve network security by acting as a buffer between the Risk Manager Server, which typically runs in a highly trusted network zone, and Risk Manager Clients, that typically run in less trusted network security zones. The gateway provides audit functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented by Tivoli Risk Manager as a binary executable. The Gateway receives events from Risk Manager Client components and forwards them on to the Risk Manager Server.
Risk Manager Web IDS

The Risk Manager Web IDS component scans the activity logs of HTTP Server components to identify potential security incidents. Web IDS 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 PERL-based addition to the Risk Manager Client. The adapter reads activity logs generated by the HTTP Server, and passes details of any potential security incidents to the Risk Manager Server.
Sensors
The Sensors component represents existing hardware and software devices that are capable of reporting potential security incidents to Risk Manager Client component. Examples of such sensors include the AIX system images running on 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 components

The following Identity Management components are part of the new integrated identity management solution as described in 2.2.5, Identity management and emerging 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
97
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
The agent provides a secure bi-directional interface for propagating identity administration updates between the two systems.
Identity Manager Agents

The Identity Manager Agents component represents all agents not explicitly referenced in this section. Examples of agents that would be deployed include z/OS RACF and Microsoft Windows Server specific agents. The agents provide identity management functionality as defined in the reference architecture shown in 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 administration updates.
Identity Manager Database

The Identity Manager Database maintains the internal configuration of the Identity Management Server. The database provides identity management functionality as defined in the reference architecture shown in Figure 1-2 on page 10. It is implemented as a relational database using DB2 Universal Database.12
Identity Manager Server

The Identity Manager Server manages all technical identity life-cycle activities within the enterprise. It is the focal point of the integrated identity management solution and provides identity management functionality defined in the reference architecture as shown in Figure 1-2 on page 10. It is implemented by Tivoli Identity Manager as a J2EE application, running within WebSphere Application Server.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 other components: 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 13
Oracle and Microsoft SQL Server are also supported. BEA WebLogic Server is also supported.
99
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
Note: For Self Registration/Self Care components to be accessible to users who either dont have an existing account or have forgotten their password, the Reverse Proxy must be configured to allow unauthenticated user access.
Privacy Management components

The following Privacy Management components are part of the new identity management solution as described in 2.2.5, Identity management and emerging problems 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-01
Privacy Manager Server

The Privacy Manager Server manages the enterprises technical implementation of its privacy policies, including policy enforcement and audit logging. It is a Privacy Management component, as defined in the reference architecture shown in Figure 1-2 on page 10, and is implemented by a J2EE application running within 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.
101
Privacy Monitor
Privacy Monitor components mediate both line of business applications and enterprise systems access to enterprise data. They intercept applications 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
Internet
(Uncontrolled)
Internet DMZ
(Controlled)
Production Zone
(Restricted)
Mail Server
Intranet
(Controlled)
Internet Client
Internet Reverse Proxy
HTTP Server Domain Firewall Web App/ Portal Server

Security Proxy
Intranet Reverse Proxy

Enterprise Data/ Systems
Intranet Client
Management Firewall
Directory & Security
Identity Management
Management Zone
(Trusted)
Application flow
Access management flow
Identity management flow
Figure 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
Enterprise Firewall
Protocol Firewall
103
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 enterprises 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 Registry
104
Internet Client node

The Internet Client node provides the interface for the banks customers and other Internet users to interact with the banks Web-enabled applications. This node hosts the following components: Application - HTTP client
Internet Reverse Proxy node

The Internet Reverse Proxy node is a stand-in for the production systems behind the domain firewall. The Internet Reverse Proxy receives all requests to Web-enabled applications as well as the responses from the Web applications. For the submitter of requests, the Reverse Proxy appears to be the only production system. It also provides security, access and data traffic redirection associated with the Web-enabled applications. Additionally, the Reverse Proxy provides: Reverse Proxy caching, which improves response time Forward Proxy caching, to reduce network bandwidth requirements Look up HTTP Server redirects The Reverse Proxy creates a barrier between the production systems and the external access points creating a higher level of security and protection against unauthorized access. This node hosts the following components: Access Management - Reverse Proxy Access Management - Replica Policy Database Note: The Reverse Proxys 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 node

The intranet Client node provides the interface for the banks employees and others to interact with both the banks Web and non-Web enabled applications. This node hosts the following components: Application - HTTP Client (Microsoft Internet Explorer) Application - Enterprise Client
105
Intranet Reverse Proxy node

The intranet Reverse Proxy performs a similar function to the Internet Reverse Proxy, but for employees on the banks 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
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 node

The Web Application/Portal Server node hosts Line-of-Business and other J2EE applications, 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 borders

The focus of this redbook is not on networks, or the concepts and practices used in designing or implementing them. However, an understanding of network fundamentals is crucial when designing or implementing a security architecture. A security-oriented review of network fundamentals can be found in Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. The Method for Architecting Secure Solutions16 defines four types of network zones and associated transport classifications. This section describes how these zone definitions relate to the Logical Operational Model shown in Figure 3-9 on page 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
107
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
Intranet
Like the Internet DMZ, the corporate intranet is generally a controlled zone that contains components with which clients may directly communicate. It provides a buffer to the internal networks.
Firewall configuration
Firewalls filter and manage data flows between network zones, typically applying one or more technologies to analyze IP packets and decide if they are allowed to flow through the firewall or not. See Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01 for an overview of typical firewall implementations. The following network traffic is permitted across the Protocol Firewall (Internet Internet DMZ): HTTP/S traffic from Internet Clients to the Internet Reverse Proxy The following network traffic is permitted across the Domain Firewall (Internet DMZ - 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 Proxy The 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 Server
17
Using the Unix remote syslog facility for example
109
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 Tivoli Access Manager for e-business Tivoli Directory Server Tivoli Identity Manager DB2 Warehouse Management: High Availability and Problem Determination Guide, SG24-6544. Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. 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. 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. Centralized Risk Management Using Tivoli Risk Manager 4.2, SG24-6095-00. IBM WebSphere V5.1 Performance, Scalability, and High Availability WebSphere Handbook Series, SG24-6198-01. IBM WebSphere Portal for Multiplatforms V5 Handbook, SG24-6098-00.
Tivoli Privacy Manager
Tivoli Risk Manager WebSphere Application/ Portal Server
110
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 WBIs 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.
111
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 Database
Policy Server
ACL Database
Access Manager Servers
Management Tools
Access Manager Servers
User
Registry
GSO Data
User
Security Groups
Group
Group
Group
Security Groups
Figure 3-10 Access Manager multi-domain environment
112
GSO Data
Security Master
User
User
Security Master
In this diagram, some users and groups are only defined in one domain, but others are defined in both domains. This is made possible by Access Managers ability to import users and groups that already exist in the user registry. If the registry ACLs are set up to allow it, a user or group that is created in one domain can be imported into other domains. A user definition that is shared between domains only shares the attributes of the base user object. This is the users First Name (CN), Last Name (SN), description and password. All other attributes are managed independently by each domain. Registry ACLs can be configured to limit which domains can modify the users base object (including the users password). Registry ACLs could also be configured so that one domains users are not visible in any way to other domains. Group objects (and therefore group membership information) can also be shared between domains. In this case, registry ACLs can be configured manually to limit which 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 from gaining control of another domains management users/groups.
WBI security domains

WBI implements a security domain design (shown in Figure 3-11) that is typical of a global enterprise which prefers de-centralized security administration.
113
Identity Manager Domain Line-of-Business Applications Regional Applications/Data AM Eastern Region Domain Line-of-Business Applications Regional Applications/Data AM Western Region Domain Access Manager Management Domain Line-of-Business Applications Regional Applications/Data AM Central Region Domain Line-of-Business Applications Regional Applications/Data AM European Region Domain AM Administration Infrastructure Enterprise Systems
Enterprise Data
AM IT Center Domain
Customer facing LOB Applications
AM Customer Domain
Enterprise Systems
Enterprise Data
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
Network communication
This section classifies the different types of network traffic generated by the integrated identity management solution and also provides an overview of the network protocols used.
Application flows
The flow of information between the HTTP Client and Web Application/Portal server uses either the HTTP or HTTPS protocol, depending upon the sensitivity of the data being transferred in each specific interaction. Each component involved in a particular interaction will use the same protocol. The individual information flows are: HTTP Client to Reverse Proxy Reverse Proxy to HTTP Server WebSphere Application Server Plug-in to Web Application/Portal Server Both J2EE applications and enterprise clients connect to enterprise systems and data using the protocols appropriate for the specific enterprise resource, such as CICS, IIOP, MQSeries, or DB2 CLI.
Access management flows

Policy Database and User Registry updates are replicated using proprietary protocols over SSL-encrypted network connections. All Access Manager components (including client APIs in other products such as Privacy Manager) communicate using proprietary protocols over SSL-encrypted network connections. The HTTP Admin Client uses HTTPS to communicate with the Web Portal Manager, Privacy Server, and Identity Management Server. Privacy enabled J2EE applications communicate with the Privacy Manager Server using the J2EE RMI/IIOP protocol over a SSL-encrypted network link.
Identity management flows

Most Identity Management Flows are DSMLv219 document exchanges over SSL-encrypted network connections. The Identity Manager Server uses this communication 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 functions
19 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.
115
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
Intranet HTTP client authentication

The security architecture will leverage the Access Manager capability to authenticate Web users based upon their Windows desktop user identity. This single sign-on capability is implemented using the Microsoft SPNEGO protocol and a Kerberos-based authentication service. Microsoft provides an authentication solution that allows Windows clients to use Microsoft Internet Explorer (IE) to access resources on Microsoft Internet Information Servers (IIS) without having to reauthenticate. This single sign-on solution relies on proprietary Microsoft HTTP authentication mechanisms. Access Manager provides an equivalent authentication solution that enables IE clients to access protected resources without having to reauthenticate. This means that users with an IE browser can access resources protected by Tivoli Access Manager without having to reenter their username and password. The user only needs to login once to the Windows domain, as is done when logging in to Windows on a desktop workstation. Access Manager supplies a similar implementation of the HTTP authentication method used by Microsoft. This implementation involves two components: Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Kerberos authentication The SPNEGO protocol mechanism enables Access Manager to negotiate with the browser to establish the authentication mechanism to use. The browser supplies Kerberos authentication information. Access Manager is able to use the users Kerberos authentication information when processing a user request to access 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-on

The security architecture will provide single sign-on across all Web-enabled applications for both Internet and intranet users. Cross Domain single sign-on (CDSSO) allows Web users to perform a single sign-on and move seamlessly between separate secure domains when requesting access to protected resources. When a user makes a request to a resource located in another domain, the CDSSO mechanism transfers an encrypted user identity token from the first domain to the second domain.
117
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 enterprises 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 Managers password validation service instead of its own. The diagram in Figure 3-12 shows the sequence of the events when Access Managers 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 2 Access Manager WebSEAL 4 Reverse Proxy 5 Password Strength Library Post Password Change Library 3 6
Password Management Servlet Identity Manager
Figure 3-12 Integrated password change workflow
118
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 Managers 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.
119
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 workgroups 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 groups customers will be able to register themselves and be automatically granted access to the work groups 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
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 WBIs implementation
121
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)

Mail Server
iNotes (Mail) Server
Management Zone (Secured)

Directory & Security
Policy Server IM AM Agent IBM Directory Server Replica Policy DB Master Policy DB Master User Registry IM User Registry IM Database
Reverse Proxy
WebSEAL
HTTP Server
IM Domino Agent HTTP Server WAS Plug-in
WebSphere App/Portal Server Self Reg Self Care LOB Applications WAS/WPS Security AM Plug-in/API Replica User Registry Proxy Policy Server Directory Integrator
Identity Manager Server Access Manager Web Portal Manager WebSphere App Server
Enterprise Data
Replica Policy DB IM Windows Agent
HR Data File
Web Application/ Portal Server, Security Proxy, Enterprise Systems & Data
Windows File Server
Identity Management
Abbreviations: AM Access Manager IM Identity Manager
Application flow Access management flow
Identity management flow
Figure 4-1 WBI integrated identity management pilot development environment
Solution build on page 59 describes how this phase forms part of an end-to-end implementation.
122
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 Identity Management Directory and Security, Reverse Proxy Server, Security Proxy Web Application Web Application / Portal Server Directory Identity Management Mail Server Product implemented IBM Tivoli Identity Manager IBM Tivoli Access Manager IBM WebSphere Application Server IBM WebSphere Portal IBM DB2, enterprise version IBM Directory Integrator Lotus Domino Server Product level Release 4.5.1 Release 5.1
Release 5.0.2, Fixpack 2 Release 5.0 Release 8.1, Fixpack 2 Release 5.2 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
For WBIs 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
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 node

For a description of this node, see Directory & Security node on page 103. This node 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 node

For 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 Server A flat file from the HR enterprise system is also delivered to this node on a nightly basis. 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 zones
Firewalls have not been implemented in the development environment. However, the data flows between logical zones comply with the network protocol rules defined in Firewall configuration on page 109.
125
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 Server
4.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 WBIs implementation: Automatic provisioning Application subscription Self care Self registration
4.2.1 Automatic provisioning

Let us take a closer look at the requirements, the design considerations, and WBIs 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 employees 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
The ideal process for this should automatically generate accounts for this new user to different IT resources. This section shows how to achieve this provisioning with IBM Tivoli Directory Integrator and IBM Tivoli Identity Manager. Based on the fields within the HR file (roles, departments) we should be able to provision access to specific new accounts for the users. This can be done automatically with a process that permits synchronization between the HR directory and IBM Tivoli Identity Manager. This synchronization process will be achieved by IBM Tivoli Directory Integrator, and when users are loaded into IBM Tivoli Identity Manager, automatic provisioning processes will provide access to the applications. The synchronization process between the HR directory (HR file) and Tivoli Identity Manager is handled by an assembly line in Tivoli Directory Integrator, which creates an identity (person) for Identity Manager. This process can be done on an interactive base, or it can be scheduled to synchronize the directories at a specific time of day (maybe at night). Automatic provisioning of users is handled by provisioning policies which have automatic settings configured. But in order for this to yield the appropriate results, the following aspects have to be considered: 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 to design the adequate assembly lines and provisioning policies.
Design consideration
In order to use the identities supplied by the HR file, we require the use of an assembly 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 the HR directory. Then, we upload this to a network drive so that Directory Integrator can access and read the file, and synchronize with Identity Manager. Once the new identities are created, they must have access to the applications they need to do their job, based on services (access to application) and provisioning policies (corporate access policies).
127
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
The first process needed, when a new employee arrives at WBI, is for the HR department to feed the directory with all the data needed, including their role, location, and organization unit. A batch process creates a text file with the information and format required, and the assembly line from IBM Tivoli Directory Integrator synchronizes the data in the file and creates the new identities in IBM Tivoli 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.
129
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
The representative diagram for the data flow is shown in Figure 4-2.
HR Directory
IBM Tivoli Identity Manager Directory
IDI
IBM Tivoli Access Manager Directory
iNotes Directory
Provisioning
IDI
Figure 4-2 Data Flow between directories
Organizational roles and target systems membership

Automatic provisioning policies can be set for all identities, but, depending on the resource, only certain users should be provisioned by them. It may also be necessary to assign users to specific roles on the target system, which requires more organizational roles or a specific Java Script to assign the proper target system group membership. If IBM Tivoli Identity Manager organizational roles can be adequately mapped to the target systems roles, group membership can be determined by a set of provisioning policies. Remember that provisioning policies can be added to determine group membership (most services are configured to have group membership as a union of all policies). Based on this, it is possible to create the following 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
131
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 identitys information and the account information. This means that any attribute can be used to create the password. However, for the entry point applications, the user should know the password, or have a way to determine it.
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
Provisioning policies will be joined to yield the final value for the attributes. This allows the construction of one general provisioning policy that handles the values for all or most users, and group specific policies that will override the general policy. Overriding can be done using the appropriate priority on the provisioning policy
WBIs implementation
The identity feed synchronization will do a bulk load of identity data into Identity Manager. The identity feed is initiated by the administrator using the IBM Tivoli Directory Integrator user interface. For this process, we have configured an IBM Tivoli Directory Integrator assembly line, which reads a text file, and creates the new users with IBM Tivoli Identity Manager. This assembly line is based on hrfeed_jndi_placement.xml, an example taken from the IBM Tivoli Identity Manager Provisioning Fast Start Guide Version 5.1. WBIs 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 Trade
This file could contain further fields to be passed into IBM Tivoli Identity Manager. To do that, you must configure the assembly line in order that IBM Tivoli Directory Integrator understands the data given, and format it to create the identity with the right format. Directory Integrator is designed to synchronize identity data located in directories, databases, collaborative systems, applications used for human resources (HR), customer relationship management (CRM), Enterprise Resource Planning (ERP) and other corporate applications. In Identity Manager, a provisioning service type called a Directory Integrator Data Feed is supported for user data exchange between Directory Integrator and the Identity Manager server. The IT department creates the file and uploads it to a network drive where IBM Tivoli Directory Integrator can access it. In our WBI environment this file will be processed once a day, which is considered to be sufficient. The frequency for this process can, however, be changed to a different interval. See Figure 4-3.
133
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
WBI has recently implemented a new e-business initiative. With IBM Tivoli Access Manager for e-business, WBI will provide access to Web applications to internal and external users, based on a central authentication and central authorization point. Besides IBM Tivoli Access Manager for e-business, WBI will automatically provide access to these applications: IBM Tivoli Access Manager IBM Lotus Notes Microsoft Active Directory Based on corporate policies, we will provision users from the BO Trade organizational unit with the necessary rights to access their corporate applications. Once the HR feed is finished, identities are created within the organizational units. Next the users must be given access to services for their corresponding organizational 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 Service Each identity created at this point must be granted access to these services. In order to execute this process automatically, we create provisioning policies for these services with automatic provisioning. Each provisioning policy uses an entitlement for one service and automatically creates the account. As an example, the provisioning policy parameter list for the IBM Tivoli Access Manager service for granting user access to Web resources (such as IBM WebSphere Portal) is shown in Figure 4-4.
135
Figure 4-4 Advanced Provisioning Parameter List
When a user is created in LDAP for IBM Tivoli Access Manager (o=wbi), that users 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
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 company's 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 WBIs 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.
137
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 dont 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
Design considerations
In 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 applications To implement application subscription, we need to know what applications the user can subscribe to. Since WBI has implemented IBM Tivoli Access Manager for e-business, it has an e-business enabler that is protecting all Web based applications. It is important to know the authentication and authorization process done by IBM Tivoli Access Manager for e-business, and the configuration implemented at WBI. All access to Web resources is based on roles (groups); we can provide access to these resources to users simply by making the users part of an appropriate group. IBM Tivoli Access Manager authorization decisions are made based on a users identity (authentication) and an access control policy, based on permissions. For more information regarding these procedures, refer to Part II, Managing Access Control, in the IBM Redbook, Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. Provisioning the users to the application requires a specific service. Also needed is a policy to allow users to subscribe to this application (ACI). Refer to the Policy and Organization Administration Guide for IBM Tivoli Identity Manager, Version 4.5.0, SC32-1149-01. Once users have subscribed to the application, an authorization process needs to be started, which is done by the workflow utility. BO Trade VP Manager is to be notified (by e-mail) that there is a request to be actioned. The VP Manager then needs to access the IBM Tivoli Identity Manager user interface and approve or reject the access request to the application.
WBIs implementation
The WBI portal allows users to subscribe to applications, based on policies. A service needs to be created in IBM Tivoli Identity Manager, which refers to applications that the users can subscribe to. In this case, since WBI has multiple locations, and is managing different IBM Tivoli Access Manager domains, some users in BO Trade will need to have access to an IBM Tivoli Access Manager application in a different location. Before this access can be granted, it must go through an approval process.
139
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
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 WBIs requirements, various design considerations, and WBIs 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 WBIs 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 users passwords on all directories, so there must be a process to accomplish this as well.
141
The user will only be able to change their personal information: Name Work telephone number Home telephone number This list is sufficient for WBIs 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.
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
We have to configure the challenge/response option through IBM Tivoli Identity Manager, where we will configure the proper policies (ACI) to allow the users to perform this operation. Once again, when a change is made to IBM Tivoli Identity Manager directory, it will be reflected in all the directories involved. When a user needs to change some personal information (for example, their home telephone number), users will be able to perform this action by accessing the WBI company portal. Users must have the permission to perform this operation, and after doing changes, directories must be synchronized again.
WBIs implementation
WBI users should be able to access the self care application for implementing self care functionalities at the WBI portal; there is a link at the portal to access this application. With this application, users can choose to logon to self care functionalities 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 their challenge/response answers in order to be able to reset forgotten passwords. We used the Web interface for user self management, provided with IBM Tivoli Access Manager version 5.1 in the Provisioning Fast Start set. The Web application sample is mounted on an IBM WebSphere Application Server, and it is compliant with the referential architecture discussed in 3.2.3, The operational architecture on page 102. This application features these functionalities: Reset of users passwords Challenge/response function Change of users personal information Self registration, as discussed in 4.2.4, Self registration on page 149 In order to have all the functions working, we have established a data flow process shown in Figure 4-2 on page 131. With this flow, changes made in the WBI portal are written in the IBM Tivoli Identity Manager directory, and the directory synchronization process with IBM Tivoli Directory Integrator. All changes are reflected to corporate directories.
143
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
Figure 4-8 User access to self care application
IBM Tivoli Identity Manager must be configured in order to enable the challenge/response functions. WBIs administrator has completed this procedure and has configured the challenge/response as an Admin-Defined mode. In this way, predetermined (administrator configured) questions will be presented to the user, 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 to IBM Tivoli Identity Manage with this application. Once a change occurs, IBM Tivoli Directory Integrator will synchronize the data between corporate directories (such as IBM Tivoli Access Manager directory). In order to be able to synchronize data between directories, ITDI must be able to read changes made to the Identity Manager directory. Identity Manager uses IBM Tivoli Directory Server Version 5.2 as the user data store. To read all changes, we configured the directory to log changes, as seen in Figure 4-9.
145
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
Configuration for ITDI can be done as seen in Figure 4-10.
Figure 4-10 Connector to LDAP Change Log
This part of the configuration reads the log changes, and the normal operation is to 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.
147
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
4.2.4 Self registration

For self registration, we tnow ake a closer look at the requirements, the design considerations, and WBIs 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 WBIs help desk. The help desk then verifies the customers 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 (WBIs 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.
149
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.
WBIs 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
WBI installed a self registration application, which connects directly to the identity management server (Identity Manager), and it requests the information from users who want to register. This information can be configured and validated with an automatic process or a manual one. The result is the creation of an account, or the rejection of the process, in which case the users will be notified by e-mail. WBI wants all of their customers to have an account. Customers will be asked to supply the following data: Full Name First Name Last Name E-mail Address This self registration application can be configured to request more information than just the items noted above. We are using the Web interface for user self management provided with IBM Tivoli Access Manager version 5.1 in the Provisioning Fast Start set. The Web application sample provides self registration functions. It is mounted on an IBM WebSphere Application Server, and it is compliant with the referential architecture discussed 3.2.3, The operational architecture on page 102. In the IBM Tivoli Identity Manager organization tree, we created a new location for placement of self registered users. This location has its own services and policies, in order to not grant access to internal applications. The application to which we will provide access is Web based, and the central data repository is the IBM Tivoli Access Manger directory. In this location, WBI has configured a service to provide the access, and it has automatic provisioning with e-mail notification, as seen in Figure 4-12.
151
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 Customers
152
With this information, the self registration application creates users at the correct organization level tree, in order to apply the right policies. A user accesses the registration page and provides the requested information, as seen in Figure 4-13.
Figure 4-13 Self registration application
Provisioning policies for the Internet Customer location includes the creation of an account for IBM Tivoli Access Manager for e-business. As discussed, this can be placed in a specific ITAM group of users, and the authorization model for ITAM is based on the Access Control List, applied to specific points in the object space. For more details, refer to Part II, Managing access control, in Enterprise Security Architecture using IBM Tivoli Security Solutions, SG24-6014-01. The automatic process is achieved with provisioning policies. Each of the external users will have an Identity Manager account in order to use the self care functions. Once this process has been completed, an e-mail such as the one shown in Figure 4-14 is passed on to the user with the access information.
153
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
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 enterprise's 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 WBIs 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.
155
156
Part 2
Part
Appendixes
157
158
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.
159
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
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
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
Policies
Implement
Risk
Manage
Figure A-2 The five steps in defining your IT security
Audit
External standards and certifications

The discussion on corporate policies suggests that internal business needs are the drivers for designing corporate policies. While this is true, there are a number of external factors that can change these business needs and policies 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.
163
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 Government's 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
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 organization's operations.
Legal requirements
The laws of the country in which an organization operates are many and diverse. The application of the laws is variable from geography to geography, and it is good to be aware of the impact of them upon corporate security policies. Modern democracies are often fond of creating freedom of information laws. One of the problems with these laws are that they are directly contrary to the same democracies wish to maintain the privacy of individual information. 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.
165
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 users activity. With these topics, most aspects of the overall identity management solution are part of the organizational security.
166
Asset classification and control: This domain has the objective to maintain appropriate protection of organizational assets (via inventory on information, software and physical assets as well as services) and to ensure appropriate levels of protection, regarding classifications. This classification often generates projects for mitigation of risk on sensible assets. This mitigation of risk includes the possible integration of specific tools that can be part of the integrated identity management solution. Personnel security: The closest sub-domain related to identity management is targeted on reducing risks of human error, theft, fraud, or misuse of facilities. The identity management solution can help with the automation of processes for 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 accessing premises or sensitive information via authentication controls such as swipe cards or PINs. In that case, identity recognition, access granting, and audit trails are also driven by the global identity management solution. Communications and operation management: For operational procedures, a segregation of duties implementation is one of the targets by reducing the risk for system misuse. With that, the enforcement of identity management is clearly a key point. This is also very useful for operational change control and audit trails. Access control: The business requirement for this domain is the need to control access to information by abiding to an access control policy in order to prevent unauthorized access to information systems. This is precisely the major goal of an integrated identity management solution. Refer to 1.5, Integrated identity in the enterprise on page 11 for a more comprehensive description. Other related sub-domains are also covered by the integrated identity management 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.
167
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.ch
168
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.
169
170
Glossary
DMZ A DMZ (demilitarized zone) is an area of your network that separates it from other areas of the network, including the Internet. J2EE Java 2 Platform Enterprise Edition is a Java platform designed for the mainframe-scale computing typical of large enterprises. Sun Microsystems, together with industry partners such as IBM, designed J2EE to simplify application development in a thin client tiered environment. JDBC Java Database Connectivity is an application program interface (API) specification for connecting programs written in Java to the data in popular databases. The application program interface lets you encode access request statements in SQL that are then passed to the program that manages the database. It returns the results through a similar interface. JMS Java Message Service is an application program interface from Sun Microsystems that supports the formal communication known as messaging between computers in a network. Sun's JMS provides a common interface to standard messaging protocols and also to special messaging services in support of Java programs. Sun advocates the use of the Java Message Service for anyone developing Java applications, which can be run from any major operating system platform. JNDI Java Naming and Directory Interface enables Java platform-based applications to access multiple naming and directory services. Part of the Java Enterprise application programming interface (API) set, JNDI makes it possible for developers to create portable applications that are enabled for a number of different naming and directory services, including file systems, directory services, such as Lightweight Directory Access Protocol (LDAP), Novell Directory Services, and Network Information System (NIS), and distributed object systems, such as the Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (RMI), and Enterprise JavaBeans (EJB). JSP Java Server Page is a technology for controlling the content or appearance of Web pages through the use of servlets, small programs that are specified in the Web page and run on the Web server to modify the Web page before it is sent to the user who requested it. Kerberos Kerberos is a secure method for authenticating a request for a service in a computer network. Kerberos was developed in the Athena Project at the Massachusetts Institute of Technology (MIT). The name is taken from Greek mythology; Kerberos was a three-headed dog who guarded the gates of Hades. Kerberos lets a user request an encrypted ticket from an authentication process that can then be used to request a particular service from a server. The user's password does not have to pass through the network. LDAP Lightweight Directory Access Protocol is a software protocol for enabling anyone to locate organizations, individuals, and other resources, such as files and devices, in a network, whether on the public Internet or on a corporate intranet. LDAP is a lightweight (smaller amount of code) version of Directory Access Protocol (DAP), which is part of X.500, a standard for directory services in a network.
171
LDIF
LDAP Data Interchange Format
MASS IBM Method for Architecting Secure Solutions PII Personally Identifiable Information
RBAC. With RBAC (Role Based Access Control), security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. Complexities introduced by mutually exclusive roles or role hierarchies are handled by the RBAC software, making security administration easier. ROI. For a given use of money in an enterprise, the ROI (return on investment) is how much return, usually profit or cost saving, results. An ROI calculation is sometimes used along with other approaches to develop a business case for a given proposal. The overall ROI for an enterprise is sometimes used as a way to grade how well a company is managed. If an enterprise has immediate objectives of getting market revenue share, building infrastructure, positioning itself for sale, or other objectives, a return on investment might be measured in terms of meeting one or more of these objectives rather than in immediate profit or cost saving. SPNEGO Simple and Protected GSS-API Negotiation Mechanism. SSL The Secure Sockets Layer is a commonly-used protocol for managing the security of a message transmission on the Internet. SSL has recently been succeeded by Transport Layer Security (TLS), which is based on SSL.
XML eXtensible Markup Language is a flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere. For example, computer makers might agree on a standard or common way to describe the information about a computer product (processor speed, memory size, and so forth) and then describe the product information format with XML. Such a standard way of describing data would enable a user to send an intelligent agent (a program) to each computer maker's Web site, gather data, and then make a valid comparison. XML can be used by any individual or group of individuals or companies that wants to share information in a consistent way.
172
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-6098
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site:
ibm.com/redbooks
173
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services

ibm.com/services
174
Index
A
access control 8 management procedures 65 policies 84 access control list access management access control list 93 access control management 11 access management application integration 71 business requirements 60 components 84, 91 delivery strategy 69 enforcement gateway 84, 89 protected object policy 93 requirements analysis 60 solution types 62 technical requirements 61 user registry 94 account automatic generation 127 creation 47 management 29 provisioning 87 accountability 8 administration delegation 34, 47 application components 89 application classification 67 application subscription 37, 137 approval process 49 architectural decisions 50 assembly line 127 assessment and planning life-cycle 55 assessment stage 54 asset value 42 assurance 6 attack identification 68 audit 34, 39, 61, 65, 67, 73, 81 access control 92 compliance 33, 76 components 85 flow structure 68 management 13, 49 auditing 8 authentication 7 service 11 authorization 7 Authorization API 84, 91 authorization service 11 automatic provisioning 127 autonomy 38 availability 6, 110
B
British Standard 7799 159 business process re-engineering 63 business process management 49 business requirements 32 access management 60 business vision 30
C
capability assessment 57 CIA Triad 5 common criteria 164 confidentiality 6 conformance check 67 consent collection 77 CORBA 171 corporate policy 160 correlation 8 countermeasure 42 Cross Domain single sign-on 117 custom agents 75
D
delegated administration delivery strategy access management identity management privacy management risk management 80 47, 62 69 72 77
175
design life-cycle 58 directory and security node 103 directory integration 9 directory management 14 Directory Server components 87
E
e-business on demand 4 EJB 171 enforcement gateway 84, 89 enrollment 8 enterprise systems node 104 event correlation 8 eXtensible Markup Language 172
F
federation of identities 9 financial assessment 57 firewall configuration 109 functional design objectives 47
provisioning 73 requirements analysis 63 Role Based Access Control 74 roles 72 server 86 user registry 94 workflow 73, 86 identity management node 104 Identrus 164 implementation life-cycle 54, 59 integrated identity management 8, 11 component model 87 network communication 115 pilot environment 122 solution overview 83 integrity 6 interfaces 65 internet client node 105 intranet client node 105 intrusion detection 13 ISO 17799 159, 166
J
J2EE 171 J2EE application 85, 8990 Java Naming and Directory Interface 171 Java Server Pages 171 JavaScript 131 JNDI 171 job role change 38 JSP 171
G
group membership 131
H
HR feed 73 HR procedures 21 HTTP Server 85
I
identification 7 identity and credential management 12 identity federation 9 identity lifecycle management 8 identity management 47 agent 86 components 86 custom agents 75 database 86 delivery strategy 72 delivery strategy (alternate) 76 HR feed 73 orphan accounts 73 password management 73 policies 72
K
Kerberos 117
L
LDAP 171 liability 160 Lightweight Directory Access Protocol 171 logging 8, 13, 32, 39 logical operational model 102 Lotus iNotes 90
M
Mail Server 85, 90 managed targets 87
176
MASS risk management 43 meta directory components 87 mitigation of risk 44 monitoring 8 multiple domain model 111
N
network communication 115 network locations 107 network zones 45 non-functional design objectives 49 non-repudiation 32 nonrepudiation 8
O
on demand 4 operational architecture 102 orange book 164 organizational role 127, 131 orphan accounts 73
provisioning 127 scripts 133 Policy Database 84, 93 Policy Server 84, 9293 post password change library 119 privacy 7 control 8 legislation 66 policy 66, 78 privacy management 15 components 86, 91 consent collection 77 delivery strategy 77 legislative compliance 79 monitor 7879, 86 requirements analysis 66 server 86 privacy monitor 79, 102 protected object policy 93 provisioning 8, 12, 32, 73 policy 127 scripts 133 Proxy Policy Server 9394 purpose for PII data use 66
P
password generation 132 management 73 policy enforcement 118 reset 34 strength library 119 synchronization 87 password management 48 password management procedures 65 performance requirements 62 Personally Identifiable Information see PII PII 66 consent collection 77 data types 66 discovery 67 purpose for data use 66 planning stage 54 policies 72 policy corporate 160 enforcement 32, 36 management 48
R
Redbooks Web site 173 Contact us xii reporting 82 requirements analysis access management 60 identity management 63 privacy management 66 risk management 68 Reverse Proxy 93 reverse proxy 45, 84 reverse proxy node 105 risk 42 acceptance 44 assessment 42 mitigation 44 transfer 44 risk management delivery strategy 80 requirements analysis 68 Risk Manager see Tivoli Risk Manager role 127, 131
Index
177
Role Based Access Control 12, 74 roles 72
S
scalability 110 scripts 133 Secure Sockets Layer 172 security audit compliance 76 security design objectives 46 security domain architecture 111 security enforcement components 85 security policy 65 enforcement 32 security risks 69 security zones 45 self-care 8, 32, 34, 91, 93, 100, 141 self-registration 32, 91, 100, 149 service 127 session management 11 single sign-on 8, 11, 61, 116 solution approach 57 SPNEGO single sign-on 117 SSL 172 strategy assessment 56 subscription ... for applications 32, 37, 137
WebSEAL 93 Tivoli Directory Integrator 87 assembly line 127 components 98 Tivoli Directory Server 87 Tivoli Identity Manager Agents 86 data flow 115 Database 86 Lotus Notes Agent 90 password policy enforcement 118 password strength library 119 post password change library 119 provisioning policy 127 Server 86, 93 services 127 workflow 128 Tivoli Privacy Manager 86 components 101 Tivoli Risk Manager Adapter for Access Manager 9193, 95 Adapter for Privacy Manager 96 components 95 data flow 116 Server transfer risk 44
U T
technical requirements access management 61 threat 42 threat identification 68 Tivoli Access Manager ... for WebSphere Application Server 91 Authorization API 84, 91 Cross Domain single sign-on 117 data flow 115 domain configuration 111 importing users and groups 113 Management Domain 112 multiple domain model 111 Policy Database 84, 93 Policy Server 84, 9293, 112 Proxy Policy Server 9394 Reverse Proxy 84, 93 SPNEGO single sign-on 117 Web Portal Manager 84 user add a new ... 47 autonomy 38 management procedures 65 provisioning 12 user registry 94, 100
V
vulnerability 42
W
Web Application/Portal Server node 107 Web intrusion detection system 97 Web Portal Manager 84 WebSEAL 93 WebSphere Application Server 85, 90 Plug-In 8990 Security Server 95 WebSphere Portal 85, 90
178
workflow 9, 49, 73, 128
X
X.500 171 XML 172
Z
zones 107
Index
179
180
(0.2spine) 0.17<->0.473 90<->249 pages
Back cover
Integrated Identity Management

using IBM Tivoli Security Solutions
Latest technology in access control and identity management solutions Holistically covers security in e-business projects Best practices and experiences
This IBM Redbook provides a solution-oriented overview of using Tivoli's 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 as a holistic way of tying security requirements into your projects. This redbook is a valuable resource for security officers, administrators, and architects who wish to understand and implement enterprise security following these guidelines.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks

SG24-6054-00 ISBN 0738497843

Integrated Identity Management Using IBM Tivoli Security Solutions Sg246054

Uploaded by

Copyright:

Available Formats

Integrated Identity Management Using IBM Tivoli Security Solutions Sg246054

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Integrated Identity Management Using IBM Tivoli Security Solutions Sg246054

Uploaded by

Copyright:

Available Formats

Front cover

Integrated Identity Management ment

Copyright IBM Corp. 2004. All rights reserved.