IBM Tivoli Privacy Manager

Front cover
IBM Tivoli Privacyy

Manager
Solution Design and Best Practices
Privacy policy and governance
discussion
Solution architecture and

design
Real-life best practices
Axel Bücker
Bill Haase
David Moore
Martin Keller
Dr. Otto Koblinger
Hai-Fun Wu
ibm.com/redbooks
International Technical Support Organization
IBM Tivoli Privacy Manager Solution Design and

Best Practices
December 2003
SG24-6999-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page ix.
First Edition (December 2003)
This edition applies to Version 1.2 of IBM Tivoli Privacy Manager for e-business.
© Copyright International Business Machines Corporation 2003. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Part 1. Drivers and architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Enterprise policy, standards and procedures . . . . . . . . . . . . . . 3

1.1 Standards, practices and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Privacy governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Privacy governance documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Privacy policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Privacy statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Information classification and control standard . . . . . . . . . . . . . . . . . . 9
1.3.4 User authentication standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.5 Role and group definition standards . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.6 Access control standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.7 Data ownership and custodian standard. . . . . . . . . . . . . . . . . . . . . . 12
1.3.8 Data logging standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.9 Data subject choice and consent standard . . . . . . . . . . . . . . . . . . . . 13
1.3.10 Data authorization standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.11 Data authorization procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.12 Consent collection procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Privacy governance roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 Chief Privacy Officer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.2 Chief Information Security Officer . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.3 Internal auditor or compliance officer . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.4 Human resource officer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.5 Application development architect . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.6 Database administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Practical example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.6 Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.7 Broader impact of privacy management . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 2. Tivoli Privacy Manager architecture . . . . . . . . . . . . . . . . . . . . . 27

2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
© Copyright IBM Corp. 2003. All rights reserved. iii

2.2 Logical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Basic application components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Centralized authentication and authorization service . . . . . . . . . . . . 29
2.2.3 Centralized privacy service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.4 Layered architecture for privacy management . . . . . . . . . . . . . . . . . 32
2.2.5 Component description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Physical component architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.1 Dedicated server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.2 Enterprise Privacy Server configuration . . . . . . . . . . . . . . . . . . . . . . 44
2.3.3 Other parameters which influence the architecture. . . . . . . . . . . . . . 45
2.4 Scalability, high availability, and performance. . . . . . . . . . . . . . . . . . . . . . 46
2.4.1 Scalability considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.2 High availability considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.3 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.5 The IBM Enterprise Privacy Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.5.1 User Interaction Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.2 Support Tools Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5.3 Privacy Data Handling Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5.4 Privacy Service Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.5.5 Directory and Security Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.5.6 IBM Tivoli Privacy Manager in EPA . . . . . . . . . . . . . . . . . . . . . . . . . 58
Part 2. Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapter 3. Monitor patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.1 Monitor background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2 Proxy Monitor pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3 Application Exit Point Monitor pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4 Application Callout Monitor pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.5 Declarative Monitor pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6 Business Process Monitor pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Chapter 4. Health care provider using a WebSphere application . . . . . . . 79

4.1 Current architecture (and AHC-internal procedures). . . . . . . . . . . . . . . . . 80
4.1.1 Data entry into the health system . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.2 Status and shortfall for AHC, patients, and practitioners . . . . . . . . . 82
4.2 Project layout and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.1 Project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3 Companies business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.5 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.5.1 Description of participants and their objectives. . . . . . . . . . . . . . . . . 87
4.5.2 Reduce the risk of exposing personal data . . . . . . . . . . . . . . . . . . . . 91
iv IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
4.5.3 AHC Privacy Manager policy groups . . . . . . . . . . . . . . . . . . . . . . . . 93
4.5.4 AHC identification mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.5.5 The actors in the Tivoli Privacy Manager groups . . . . . . . . . . . . . . . 97
4.5.6 AHC privacy policy usage statements. . . . . . . . . . . . . . . . . . . . . . . . 98
4.5.7 Risk assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.6 Technical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.6.1 Solution architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.6.2 Monitor design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Chapter 5. Human Services application based on Siebel 7 . . . . . . . . . . 125

5.1 Our company (Authority for Social Administration) . . . . . . . . . . . . . . . . . 126
5.2 Architecture and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2.1 Organization of the Authority for Social Administration. . . . . . . . . . 127
5.2.2 Client data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.2.3 What PII data do we have? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.2.4 Examples of data needed within branches of ASA . . . . . . . . . . . . . 129
5.2.5 Which privacy policy matches my consent? . . . . . . . . . . . . . . . . . . 132
5.2.6 Case worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.2.7 An atypical household: The Privacy Manager family . . . . . . . . . . . 132
5.2.8 Other shortfalls of the current situation . . . . . . . . . . . . . . . . . . . . . . 136
5.3 Corporate business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . 137
5.4 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.4.1 Business value of the integration of Siebel and PADRE. . . . . . . . . 139
5.4.2 Benefits of the privacy enhanced system PADRE . . . . . . . . . . . . . 140
5.5 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.5.1 Front desk handles calls from police and hospital . . . . . . . . . . . . . 141
5.5.2 Public housing calculating benefits . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.5.3 Enroll in recovery therapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.5.4 Violence consultation of Mary on behalf of Peter . . . . . . . . . . . . . . 147
5.5.5 Management assigns a case worker. . . . . . . . . . . . . . . . . . . . . . . . 149
5.5.6 ASA privacy policy usage statements . . . . . . . . . . . . . . . . . . . . . . . 149
5.6 Implementation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.7 Technical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.7.1 Siebel architecture background. . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
5.7.2 Monitor architecture background. . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.7.3 Siebel setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.7.4 Monitor setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.7.5 Tivoli Access Manager setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.8 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Chapter 6. Financial provider using multiple J2EE applications . . . . . . 175

6.1 Company structure and profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Contents v
6.1.1 Geographical distribution of RPF . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.1.2 Organization of RPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.2 Current architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
6.2.1 Overview of the Web-based application infrastructure . . . . . . . . . . 177
6.2.2 Outline of the customer Web portals. . . . . . . . . . . . . . . . . . . . . . . . 178
6.2.3 Outline of company-internal financial applications . . . . . . . . . . . . . 179
6.2.4 Current shortcomings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
6.2.5 Privacy issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.3 Corporate business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.1 Business vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
6.3.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.3.3 Corporate privacy policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.3.4 Expected benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.4 Project layout and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.4.1 Phase 1: Privacy policy design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
6.4.2 Phase 2: Monitor descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.4.3 Phase 3: Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
6.5 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.5.1 Customer’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.5.2 Banking department’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.5.3 Insurance department’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.5.4 Trading department’s view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.5.5 Customer relationship department’s view . . . . . . . . . . . . . . . . . . . . 188
6.6 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6.1 Data design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6.2 Privacy rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
6.6.3 Risk assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.7 Implementation architecture for declarative privacy . . . . . . . . . . . . . . . . 196
6.7.1 Declarative Privacy Monitoring concept . . . . . . . . . . . . . . . . . . . . . 196
6.7.2 Declarative XML privacy deployment descriptor file . . . . . . . . . . . . 201
6.7.3 Plug-in classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.7.4 Declarative Privacy Monitoring download site. . . . . . . . . . . . . . . . . 208
6.8 DPM monitor technical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 208
6.8.1 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
6.8.2 System setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
6.8.3 Create a P3P policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.8.4 Create a declarative privacy deployment descriptor XML file . . . . . 211
6.8.5 Provide privacyOperationPoint descriptor plug-in classes . . . . . . . 215
6.8.6 Deploy monitors in Privacy Manager . . . . . . . . . . . . . . . . . . . . . . . 220
6.8.7 Enforce privacy policies in auto insurance application . . . . . . . . . . 228
6.9 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
vi IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Appendix A. Declarative Privacy Monitoring . . . . . . . . . . . . . . . . . . . . . . 237
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Contents vii
viii IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright IBM Corp. 2003. All rights reserved. ix

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® Holosofx® Tivoli Enterprise™
alphaWorks® ibm.com® Tivoli®
DB2 Universal Database™ IBM® WebSphere®
DB2® Redbooks (logo) ™
e-business on demand™ Redbooks™
The following terms are trademarks of other companies:
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, and service names may be trademarks or service marks of others.
x IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Preface
Conducting business today involves more and more personal information of the
parties involved in the transactions. This is not limited to e-business but applies
to all companies that use computer technology for business processes in order to
store data. In this era of e-business, people have become aware that their
personal information is being used in multiple places and are asking questions
about the whereabouts of these assets.
IBM Tivoli® Privacy Manager provides an enterprise-wide system that enables a

company to use the personally identifiable information (PII) it collects according
to the principles of Fair Information Practices1 and to monitor and enforce its
compliance with those principles. The Chief Privacy Officer has the ability to
prove what kind of PII his company is using, where it is stored and who accessed
this data at any given time. This helps the enterprise to win the trust of their
customers and partners.
This IBM Redbook helps privacy and security officers as well as their staff to
understand and implement the IBM Tivoli Privacy Manager in an enterprise
environment.
Part 1, “Drivers and architecture” on page 1 covers the design and architecture of
Tivoli Privacy Manager and looks at the impact of privacy issues on enterprise
policy, standards, and procedures.
Part 2, “Best practices” on page 61 discusses three specific customer scenarios

with different business requirements and technical implementations, ranging
from a WebSphere® application to Siebel 7 integration. A more generalized topic
on Monitor patterns is also included.
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.
1
The Fair Information Practices is a report from the Federal Trade Commission submitted to
Congress in May 2000. The document can be found at
http://www.ftc.gov/reports/privacy2000/privacy2000.pdf
© Copyright IBM Corp. 2003. All rights reserved. xi

Figure 1 From left: David, Axel, Martin, Hai-Fun and Otto
Axel Buecker is a Certified Consulting Software I/T Specialist at the

International Technical Support Organization, Austin Center. He writes
extensively and teaches IBM classes worldwide on areas of software security
architecture. He holds a degree in computer science from the University of
Bremen, Germany. He has 17 years of experience in a variety of areas related to
workstation and systems management, network computing, and e-business
solutions. Before joining the ITSO in March 2000, Axel was working for IBM in
Germany as a Senior I/T Specialist in software security architecture.
Bill Haase is a part of the Tivoli Americas National Sales Engineer Team in
North America. Bill has 20 years of experience in the development of information
technology systems and over 10 years of experience in developing security and
privacy management infrastructure. He holds several certifications in security
and has contributed to the development of IBM's privacy methodology, patented
Enterprise Privacy Architecture and intellectual property including patents,
methods and architectures. In addition, he has developed most of the current
training materials and certification exams for Tivoli Privacy Manager. He serves
as an expert in privacy and security to IBM customers in North America with
expertise in regulatory compliance and systems integration.
xii IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Martin Keller is a Certified Tivoli Consultant with his own company Red Planet
Solutions, an IBM business partner in Germany. Since 1997 he has provided
professional services in Tivoli Enterprise™ and Tivoli Security products. He
holds a degree in computer science from the Fachhochschule of Fulda,
Germany. His main interests are IT architecture, e-business infrastructures and
systems and network management. Before founding Red Planet Solutions in
1998, Martin was a Senior IT Consultant for the systems integrators Softlab
GmbH and Danet GmbH in Germany.
Dr. Otto Koblinger is a Tivoli Security Consultant in the Software Group of IBM
Germany. He has many years of experience in the security area. He holds a
degree in Physics from the University of Stuttgart/Germany and received his PhD
in Science. He joined IBM Research and Development in Böblingen, Germany in
1985 and has worked in various technology areas of IBM. In 1996 he moved to
IBM Global SmartCard Solutions in Böblingen. In 1998 he joined the IBM
e-business unit in EMEA/Central Region covering security issues. Since 2001 he
has been a Business Consultant in the Security Pre-Sales Department of Tivoli
Germany.
David Moore is a Software Engineer with the Tivoli Security Integration Factory
in Australia. He has eight years of experience in developing integration
middleware and security software. He holds a degree in Computer Science from
Griffith University in Australia. Before joining IBM, David was employed as a
Software Engineer at Compaq.
Hai-Fun Wu is a software engineer in the Tivoli Privacy Manager development

team. He authored and supports the Declarative Privacy Monitoring (DPM) for
the Enterprise Privacy Authorization Language, in addition to working on the core
DPM implementation. He holds a Master’s degree in computer science from the
University of Texas in Dallas, USA. He has 20 years of experience in software
development.
Thanks to the following people for their contributions to this project:
Calvin Powers, John Harter, Phil Fritz, Steven Adler

IBM Privacy Manager product management and development team
Dr. Paul Ashley

IBM Software Group Australia
Dr. Larry Ponemon, Ponemon Institute

Steve Dowling, Pioneer-Standard Electronics, Inc.
Ed vanEssen, Deloitte & Touche
Members of the IBM Privacy Council
Preface xiii
Jeff Miller
IBM Developer Relations
Kathy Bohrer
IBM Privacy Control Research and IBM Distinguished Engineer
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:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM® Corporation, International Technical Support Organization
Dept. JN9B Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
xiv IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
Part 1
Part 1 Drivers and

architecture
In this part, we cover the design and architecture of Tivoli Privacy Manager and
look at the impact of privacy issues on enterprise policy, standards, and
procedures.
© Copyright IBM Corp. 2003. All rights reserved. 1

2 IBM Tivoli Privacy Manager 1.1 Solution Design and Best Practices
1
Chapter 1. Enterprise policy, standards

and procedures
The technology may not drive the corporate policy; it is the other way around…
Once you know what you need to protect and the potential threats and risks, you
can start addressing them. First, all the threats and risks need to be classified in
a study based on such elements as:
򐂰 Direct financial loss
򐂰 Indirect financial loss (such as investigation, recovery, and so on)
򐂰 Loss of confidential information
򐂰 Liability
򐂰 Image impact
򐂰 Cost of mitigation
򐂰 Accepting residual risk
This study can process the same threats and risks, yet may conclude in a
different severity based on your particular business. Then the decision has to be
made whether to accept or to mitigate the risk. This process can be handled by
external consultants such as IBM Global Services. The threat identification, as
well as this severity study, is done in conjunction with the organization by
applying a standard and proven methodology.

It is tempting to directly translate the threat analysis into a technical solution. But
first it should be related to the corporate policy and standards. These documents
highlight the risks and present how they must be handled enterprise-wide.
Static
Corporate
Policy
Standards
Standards
Standards
Standards
ProceduresPractices ProceduresPractices Procedures Technical
Figure 1-1 Dynamics for policy, standards, practices and procedures
If not existing, the first document that will be written is the corporate policy. It
must outline the high-level directions to be applied enterprise wide. It is
absolutely not technical, but is derived from the business of the enterprise and
should be as static as possible, as depicted in Figure 1-1.
Corporate policy vs corporate policies:
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.
1.1 Standards, practices and procedures

From the corporate policy will derive the standards. They are documents
explaining how to apply the policy details in terms of authentication, access
control, information classification, 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 implementation of the standards on

operating system, application, or any other endpoint. They detail precise
configurations, such as the services to be installed, the way to set up user
accounts, or how to securely install software. A privacy-related practice may
describe how to apply the standard for disclosure of information or the collection
of data subject consent.
The procedures document the single steps to be applied to requests, the

approval, and implementation flows. Such a procedure could be a request to
access a specific set of sensitive data, where the approval path (system owner,
application owners, and so on) and conditions such as VPN, strong
authentication, and so on are explained in details.
Use cases are very helpful to illustrate how policies and standards are translated
into specific practices or procedures. Use cases can be used to articulate the
step-by-step process, environment, and conditions that can help define what a
practice is and what it is not. This helps to identify and articulate risks that are not
clearly defined by the practice.
While the implementation of privacy practices can be achieved by using

technology, they are often implemented through manual procedures.
Organizations train their staff to implement these procedures in a specific way to
reduce their risk. The assumption is that the risk has been mitigated, but
unfortunately there are gaps in performance. This approach introduces risk by
not leveraging technology to implement the procedure consistently. Tivoli Privacy
Manager can help reduce the risk of inappropriate disclosure through a
consistent application of policy and standards that govern data disclosure.
Tip: Approval procedures are often implemented by sending e-mail or

paperwork. The efficiency can be improved by using a computer to handle
these repetitive tasks and ensure, unlike static paperwork, that changes within
the company are applied quickly to the procedures. As explained later it can
also reduce human errors.
1.2 Privacy governance

Privacy governance is implemented by a team of people through a set of
documents. If an organization wants to include privacy management as a part of
their strategy to leverage information they create, collect and retain, they need to
Chapter 1. Enterprise policy, standards and procedures 5

develop a governance program for this information. Privacy management is
usually developed by an organization that values and respects the idea that
some information needs to be handled with special care because the subject of
this information has trusted the organization with this information. This idea that
an organization is acting as the custodian of information that belongs to someone
else is fundamental to privacy management and is often the reason for the
creation of the information governance program that includes privacy
management.
This governance program will usually be implemented by a team of people and

guided by a set of governance documents. The Organization for Economic
Cooperation and Development (OECD) published in 1980 a set of privacy
guidelines1 that are regarded as the best practices in privacy. These guidelines
can serve as a set of requirements and practices that an organization should
address when developing a privacy governance program. Two key points that
OECD recommends is that organizations should be open about how they collect
and handle personally identifiable information (PII) and the second is the
definition of PII. OECD suggests this definition for PII:
Personal data under the OECD Privacy Guidelines is a very broad
expression, which means any information relating to an identified or an
identifiable individual (data subject). It includes any kind of information once
linked to an individual.
The privacy governance documents are developed to enhance the business

strategy and enable information management using the concepts of safeguarding
the personal information within the data sets that the organization retains. The
idea is to enable use of PII while reducing the risk of misuse and inappropriate or
unauthorized disclosure of this information. These documents help the
organization to identify information that requires privacy management and define
how to use and handle this information. The documents also communicate to the
owners of that information how their information is handled, used, and protected.
The overall goal is to create trust between the owner and the custodian and allow
the custodian to use and collect accurate, detailed information about the owner
for specific purposes.
A simple analogy may help illustrate some of the basic requirements.
If a man asks to borrow your car, you probably would want to know a few things
before you would consider lending it to him:
򐂰 Why do you want my car?
򐂰 When will you return my car?
1
The OECD Web site provides different articles on the background of privacy guidelines, the version
from 1980 can be found at
http://www.oecd.org/document/18/0,2340,en_2649_34255_1815186_1_1_1_1,00.html
򐂰 What do you plan to do with my car?
򐂰 Are you planning to let others use my car?
If the man tells you “I would like to enter a demolition derby with your car”, then
you might not let him take it. If he tells you “My friends will each pay me a fee for
using your car but I do not know what they intend to do with it”, then you might
not let him take your car.
On the other hand, if he says “I would like to get us lunch and I will return in 20
minutes with your car and lunch for us”, then you might agree to let him borrow
your car.
The idea here is that your car is your property and you are the owner. As the
owner, you have the rights of ownership, which include controlling how your
property is used. Privacy management starts with the concept that information
belongs to the data subject of that information, and that how the organization
cares for this information must be communicated and enforced consistently to
build trust between the organization and the data subject. This is usually
communicated through policy, standards, and practices internally and through
the privacy statement and opt-in or opt-out programs externally (or to the subject
of the data collected).
Let us outline some of the key governance documents, including critical policies,
standards, and practices. Unique to privacy management are data subject choice
or consent programs, such as opt-in or opt-out programs.
1.3 Privacy governance documents

Privacy governance documents provide a set of materials to establish an
organization’s privacy management requirements to make privacy both
functional and useful at every level of the organization. There are several levels
of governance documents. The highest level document is a policy. A policy
document is a general statement from the organization’s senior management
articulating the organization’s commitment, goals, and guidelines for privacy
within the organization. Standards and benchmarks establish specific metrics and
performance requirements that will be implemented through procedures within
the guidelines provided by management. Each of these governance documents
serve the organization at a finer granularity of detail and are implemented at
different levels of the organization. Together they define the privacy management
practices and guide the organization’s behavior to achieve an appropriate level of
flexibility in the use and disclosure of privacy-sensitive data.

1.3.1 Privacy policy
The privacy policy is the highest level privacy governance document. It is
designed to serve the organization by aligning business strategy and the
organization’s use of personally identifiable information (PII). This document
tends to be static over time and provides high-level guidance to the organization
about the data-handling practices for privacy-sensitive information. The intended
audience is the employees and auditors of the organization. This policy is usually
not shared outside the organization. An excellent resource to assist in the
development of a privacy policy and a privacy statement is the OECD Privacy
Policy wizard. You can find this wizard on the Web at:
http://cs3-hq.oecd.org/scripts/pwv3/PWPart1.htm
Another good resource for guidance is the U.S. Federal Trade Commission,
which enforces most of the United States Federal Privacy laws. When it performs
an investigation into privacy violations it usually starts with two basic questions:
What are the privacy practices in your policy and do you follow them? According
to the U.S. Federal Trade Commission, a privacy policy should at least contain
the following five key components:2
򐂰 Notice/Awareness: Notice means providing data subjects and users of
personal information with the organization’s privacy practices and the
organization’s policy. Often this includes the organization’s practices of PII
collection and lists the uses and purposes for the collection of the PII. In an
e-business environment, this would typically be done through a hypertext link
to the privacy policy or for external constituents, the privacy statement.
򐂰 Consent/Choice: Any user who submits a PII should be given the
opportunity to grant consent for how his or her information will be used.
Typically, this takes the form of an opt-in/opt-out program. The policy specifies
what PII is collected and identifies for what purposes the data will be used
and if the data subject will be given an opportunity to grant consent for
specific uses.
򐂰 Access/Participation: Access typically means providing the data subjects
with the ability to view, edit, or update the PII that the organization has
collected about them. It includes a contact point and a method for viewing and
correcting information stored in the organization’s databases about them.
This usually includes personally identifiable information, demographic
information and associated preferences. Most often this is used to correct
contact information such as address, phone numbers, and e-mail addresses,
as well as the ability to choose or grant consent to specific uses of their
information.
2
Source: “Privacy Online: A report to congress”, submitted on 7-11-1998, at
http://www.ftc.gov/reports/privacy3/index.html
򐂰 Integrity/Security: The policy includes a commitment to securely store and
maintain the integrity of the PII collected. Many privacy policies include a
commitment to secure information and prevent its access by unauthorized
users. You cannot have privacy without security and security is all about
preventing access by unauthorized users to sensitive information. Privacy is
focused on ensuring proper use for specific purposes of PII by authorized
users.
򐂰 Enforcement/Redress: The privacy policy at a minimum includes a contact
point for filing a complaint or to notify the organization of a potential privacy
violation. Some policies include contact information for specific industry
programs that organizations can subscribe to, for example, the Better
Business Bureau Online (see http://www.bbb.org), TRUSTe (see
http://www.truste.org), or the Direct Marketing Association (see
http://www.the-dma.org/). The general principle is to provide a means for
the data subjects to access a resource to handle or investigate the misuse of
their information. Enforcement may include detailed specific practices
including data-handling procedures and audit procedures to verify policy
compliance. More advanced organizations may even include access to a
detailed report of how and when the data subject’s information has been
accessed, for what purposes it has been used, and by whom.
1.3.2 Privacy statement

The privacy statement is a commitment to data subjects from whom the
organization collects information. It outlines the organization’s practices and
commitments to safeguard the PII and communicates the information about the
privacy policy to the data subjects. It is the primary communications tool for the
organization to the data subjects from which it collects privacy-sensitive
information. It is more limited in scope than the policy because it is a
communications vehicle about the policy rather than the actual policy. This is
what is often listed on most Web sites as the privacy policy; it is the privacy
statement.
1.3.3 Information classification and control standard

Information classification and control or data classification, as it is known in the
security domain, is one of the critical standards for privacy management. It is
used to segment data into classes or categories for handling in a specific way.
Data classification is used to reduce the administration of specifying
data-handling requirements for data elements. If an organization maintains
12,000 data elements and they want to specify security and privacy controls for
those data elements, it is a lot easier to set up a data classification schema for
categories or classes of data rather than specifying handling controls for each of
the 12,000 data elements. By associating a class specification with an individual

data element, you can associate a specific set of handling requirements for that
element. This is a metadata approach to specify handling controls for data. A
typical data classification schema includes the following categories:
򐂰 Roles and responsibilities
The roles and responsibilities specify who is responsible for the identification
and the association of the data classification with the data that is retained.
Often organizations find themselves serving in a custodial role or an
ownership role, depending on the data. An organization usually is the owner
of data its create and custodian for the data it collects. This usually helps to
guide the choice of the data classification and the enforcement of specific
data-handling practices. The organization usually identifies one of the two
ownership paradigms with the data or includes it as part of its data
classification schema. Most often the organization specifies a data or
application owner who is responsible for assigning the classifications from the
enterprise data classification schema to the data set that they have been
assigned governance. The Information Classification and Control Standard
is the governance document used as a guide through that process.
򐂰 Scope of the classification
The scope of the classification specifies the resolution of the applied
classification. The classification for privacy should be applied at the element
level rather than the database row, record, or table level. If an organization
handles PII, its data classification schema should set the scope of the data
classification to the element level in order to meet the requirements from most
privacy regulation, OECD best practices and the organization’s own privacy
policy.
򐂰 Class name
The class name is not very important and often a source of confusion. If one
organization has a class called confidential and another has the same class
distinction and they have different handling requirements, then the
assumption by looking at the name would be that they are the same, when in
fact they are different. It is often better to use other naming schemes and
apply them consistently. This allows the user to focus on the handling
requirements and segmentation criteria rather than the name.
򐂰 Segmentation criteria
Segmentation criteria are used to associate a data element with one class as
opposed to another. The segmentation criteria should offer clear guidance to
associate a data element exclusively in one classification. If you find that an
element is “fitting-in” with more than one class, you should consider revising
your classification schema to include an additional classification that allows
you to mutually exclusively segment data with specific sets of data-handling
requirements.
򐂰 Data-handling requirements
The data-handling requirements are the practices that are to be applied to
data of a specific class. Often the data classification schema is developed in a
by identifying and collecting the sets of data-handling requirements that are
required to be applied to the data that the organization retains.
1.3.4 User authentication standard

User identification and authentication are critical security standards that provide
a basis for establishing user credentials to the enterprise systems. Authentication
is critical to privacy because we must know who is requesting access to the data
in order to determine if they are authorized to access privacy-sensitive data for a
specific purpose. An authentication standard usually specifies the identification
procedures necessary to obtain a specific type of credential. The credential type
is associated with a specific form of authentication. The most common
authentication method is a weak authentication — a combination of user name
and password with a specific password strength. Most enterprise authentication
systems include some form of course-grained authorization or access control.
For privacy purposes, the important point is to ensure that the organization has
an authentication system that can be leveraged into the privacy solution to
establish a level of trust that the user is who he says he is. Excellent sources for
these types of security standards include the U.S. Government’s National
Institute of Standards and Technology’s Computer Security Resource Center3, or
either British Standard 7799 or the ISO 177994.
1.3.5 Role and group definition standards

Privac-enforcing access is usually managed by user groups or roles within the
enterprise. Roles and groups are similar control instances but come from a
different approach to abstracting users. Organizations that use groups tend to
have a cumulative approach to building security privileges. A user can be in
group A with privileges to read the customer data and if they are also in group B
that has update privileges the user will get the privileges cumulatively from both
groups.
Organizations that use roles tend to have a mutually exclusive approach to

building privileges. If a user Dave is in Role A and he has privileges to use the
sales application, and Mary is in Role B and has access to the HR application,
then only Mary will not be able to access the sales application. The use of roles
tends to be mutually exclusive. If Mary then is assigned to work on a project with
sales, she will either need to be given a new role or have that role added to the
authorization model for sales.
3
The National Institute of Standards and Technology can be found online at http://csrc.nist.gov/
4 Resources on either BS7799 or ISO17799 can be found at http://www.iso17799software.com/

Many organizations have elected to establish a Role Based Access Control
program to assist with the enforcement of privacy access controls to sensitive
data, or on a broader basis, as a part of their data authorization system. Role
Based Access Control is often selected to help approximate the purpose of the
user’s request and use that as a part of the authorization decision. The idea is
that a person in a particular role is authorized to execute certain business
processes and those business processes require access to sensitive data. The
problem is that this approximation is bound to the user and not to the business
transaction or the data. Establishment of roles and groups should be used to
build local sets of users by authorized business purposes rather than
organization structure. This can be difficult to establish, so organizations often
design their roles and groups around the organizational structure and establish a
set of authorized business purposes separately. Then they map these groups to
purposes. This mapping often leads to a refinement of the groups and roles.5
1.3.6 Access control standards

Access control is often implemented as a part of the authentication infrastructure
but the access control standard is a separate and higher level guidance for the
implementation of processes and procedures. This standard usually starts with
an establishment that the organization will use access control to limit a system
user’s access to information resources. This is an important security standard
that privacy leverages, but it is focused on limiting or controlling access to a
resource where privacy is focused on managing disclosure of information from
the resource. Access control is part of most security standards including ISO
17799 and the NIST Guidelines for Role Based Access Control (RBAC)6. Most
access control standards documents require authentication for certain
information resources as well as adopting either a group or role management
model. This is evident in the RBAC model mentioned above. Access and privacy
control often work together to provide a complete data authorization framework
that can be implemented across the enterprise. Each tends to enhance the
strength of the other. The access control standard should address a
course-grained authorization procedure, controlling access to a resource. The
privacy authorization technology is used to control access or disclosure of
information within the resource.
1.3.7 Data ownership and custodian standard

The purpose of data ownership and custodian standard is to provide guidance to
the individual within the organization who is responsible for setting the
safeguards and implementing and maintaining the safeguards for the data
5
For sources of good examples see the standards references in 1.3.4, “User authentication
standard” on page 11.
6 These can be found at http://csrc.nist.gov/rbac/
retained by the organization. The data ownership and custodian standard
addresses the organization’s approach to setting data-handling requirements to
mitigate risks with different “types” of data. If an organization is the creator or
owner of data, the risks from inappropriate disclosure may be limited to loss of
competitive advantage or embarrassment by the organization. On the other
hand, if the organization is the custodian of data that it has collected from outside
the enterprise, then there are additional risks, such as liability for regulation
violations or identity theft of customers to civil penalties from contract violations.
Included in the data ownership and custodian standard are guidelines for the
identification of the organization’s role to the data under management and
assignment of responsibility for setting safeguards of the data. This standard is
often associated with the information classification and control standard
(discussed in 1.3.3, “Information classification and control standard” on page 9)
and leverages this standard to help set data-handling controls for the data. In
addition, it usually defines consent or authorization collection requirements for
use or disclosure of the data. These requirements may include limitations by
purpose or authorized business processes.
1.3.8 Data logging standard

The data logging standard is a key security standard that is often used to support
privacy compliance review programs. Since privacy requires fine-grained
authorization to individual transaction requests for data elements, most
organizations require logs to be maintained about the requests for sensitive data.
Detailed audit logs are critical to support compliance audits. This standard
usually includes logging requirements for specific types of data and specifies the
retention period of the logs. Most logging policies specify logging of all
transactions individually. For privacy purposes, it is common practice to
associate the specific user who generated the transaction and the business
purpose for the transaction. This value-added information in the log supports the
requirements for audit log reviews for compliance with policy and allows these
reports to be generated without a significant amount of analysis. If this
information is stored in a format that can be easily presented to a user, then
reports can be generated in real time. This can add value by not only supporting
auditing requirements but can also help support business information analysis in
a unique way by helping the organization see how personal information is
actually used by whom for what purpose.
1.3.9 Data subject choice and consent standard

The purpose of this standard is to involve a third party in setting the controls and
data-handling requirements for the data. It is required practice to support the

data custodian relationship with data that the organization retains. It includes a
few basic requirements such as:
򐂰 Presentation of the data-handling practices
򐂰 Data user submitting the data
򐂰 Time and date of the consent
As a component of a privacy program, the third party who is submitting the data
and granting consent is the data subject of the data retained by the organization,
or in a broader sense the data owner or data submitter. The standard defines a
process for collection of consent or to grant authorization to the organization to
use data in a specific way.
1.3.10 Data authorization standard

The data authorization standard is the organization’s guideline for IT system
developers to implement controls for the access and disclosure of data the
organization retains. This standard usually specifies guidelines for systems,
databases, and applications to establish the requirements for data authorization.
The standard guides the system developer on when a data authorization process
is required and what the procedure is to grant access to the data retained. Often
this is specified by type or classification of the data. Each type of data may have
its own data authorization process or procedure. It also guides the system
developer on when to include logging to document compliance with the
organization’s policies and procedures.
In addition to establishing when data authorization is required, the standard

guides the developer to implement authorization at a level of granularity that
balances performance and flexibility of control. More flexibility is obtained when
the granularity is set to instance level by element as opposed to setting it to
system or database access level. This standard enables the organization to use
data in more ways and share data with more users by setting authorization
standards at an appropriate level of granularity for the users of the data. If the
data has a lot of potential uses, then it is better to set the data authorization
standard to a finer granularity.
1.3.11 Data authorization procedure

The data authorization procedure implements the data authorization standard. It
specifies what data is collected and analyzed to determine if a user is authorized
to access, update, create, or delete data. Privacy programs are mainly
concerned with the disclosure of data. Privacy programs usually require a
fine-grained data authorization procedure for granting access to privacy-sensitive
information.
An organization may have multiple data authorization procedures in place. All
data authorization procedures specify what data is collected at what time to be
analyzed in a specific way. This usually involves the collection of metadata about
the data being acted on and evaluated in some way. Privacy programs often
specify the evaluation of at least four metadata elements:
򐂰 The users role of privacy group
򐂰 The type or classification of the data requested
򐂰 The purpose for the disclosure
򐂰 The data subject’s consent or authorization for this use
1.3.12 Consent collection procedure

The consent collection procedure implements the data subject consent or choice
standard. This process requires the data submitter to agree to a policy upon data
submission. The policy presented to the data submitter contains the
data-handling practices such as the following:
򐂰 Purpose the data will be used for and disclosed
򐂰 The retention policy
򐂰 Access restrictions
򐂰 Data sharing or publishing guidelines
򐂰 The organization’s relationship to the data (owner or custodian)
The guiding principle is to be open and honest with the data submitter about the
organization’s data-handling practices when collecting their consent to the
handling practices. An important requirement of this procedure is the binding of
the policy presented to the user and the recording of the consent. Binding these
two elements together allows the organization to revise policies and maintain a
trust relationship with the data submitter. If the organization changes its
data-handling practices (for example, it revises its policy to include the ability to
transfer the data in a merger or acquisition or to lease the data to other users
outside the organization), then these new practices can be implemented with the
full knowledge that the previously collected consent was for the old policy and
does not carry over to the new. This has been a significant restriction for
organizations and challenge for organizations;,binding consent and collection
policy while providing the organization the ability to change and stay flexible.
1.4 Privacy governance roles

Once the privacy governance documents have been developed, an organization
often assigns people to specific roles with responsibilities and authority to ensure
their successful implementation. Successful implementation of the governance
documents is ultimately performed by manual and automated processes

executed and measured by people. The titles of these roles may be different from
one organization to another, but recently there has been a trend to establish
privacy management at a senior level of the organization. Companies, such as
IBM and others, have established senior management roles to guide the
development and measure the effectiveness of their organization’s privacy
management practices. Presented in the following sections are some of the roles
often found within organizations and how they impact the implementation of
privacy within an organization.
1.4.1 Chief Privacy Officer

The Chief Privacy Officer role in an organization is key to the development and
implementation of an organization’s privacy program. A common best practice is
to have this role report to the President, Chief Executive Officer or the Board of
Directors, depending on how integrated privacy is to the business strategy or the
organizational brand7. The Chief Privacy Officer (CPO) works closely with
marketing, human resources, and corporate security and often sets requirements
that need to be implemented through these other roles. Most CPOs have a legal
background, but some of the leaders and innovators in this role have strong
marketing and technical backgrounds. Although they may understand and
interpret regulation to set the minimum standard for privacy practices, they often
lack the organizational knowledge to achieve effective change to implement
those requirements. Developing expertise in marketing and technology can equip
the CPO to effectively communicate and identify key impact points within the
organization. This role involves many activities, including:
򐂰 Development of an organization’s privacy management requirements
򐂰 Establishment of measures of success and performance metrics
򐂰 System application and process development guidance
򐂰 Assessment of privacy management programs and procedures
򐂰 Investigation and resolution of privacy complaints and violations
򐂰 Privacy practice alignment with the organization’s business strategy
Often this role is articulated in a two-dimensional set of activities:

򐂰 Development of the privacy management requirements
򐂰 Measurement and assessment of the organization’s compliance with those
requirements
Development of the privacy management requirements involves the integration of

business strategy, legal and regulatory requirements, and operational and
technical requirements for data management of privacy-sensitive information.
7
Other reporting points often are Chief Information Officer, Chief Security Officer, Compliance Office
and Vice President of Marketing.
The measurement and assessment activities of the Chief Privacy Officer involves
working with individuals who have privacy complaints and auditors to assess the
organization’s compliance with the privacy program’s requirements. Both of these
activities involve assessing the organization’s business process requirements
and their uses of privacy-sensitive data.
CPOs require a clear understanding of how an organization uses

privacy-sensitive information and what business processes need or use this
information. Developing a clear understanding of how privacy-sensitive
information is used and disclosed will assist the CPO with the identification of
high-risk activities and business process points where an inappropriate
disclosure may occur. With that knowledge, the CPO can focus on mitigation
tactics to reduce this risk.
1.4.2 Chief Information Security Officer

The Chief Information Security Officer (CISO) has a significant contribution to
privacy management. The CISO role is often focused on the following key
security tenets:
򐂰 Confidentiality of information
򐂰 Integrity of information
򐂰 Availability of information
All three of these domains have a direct impact on the success of a privacy
management program. The linkage is strong between these two roles because
you cannot have privacy without good security but you can have good security
without good privacy. Good information security is an important requirement for a
successful privacy program. While security is often more focused on keeping
unauthorized users from accessing sensitive information, privacy is often focused
on managing authorized users to use information effectively and within the
constraints necessary to achieve an organization’s strategy.
Effective information security is the largest dependency that privacy

management requires to reduce risks and threats to privacy-sensitive
information. Many of the policies and standards necessary to implement a
privacy program are established and managed by the CISO. An important
example is the data classification standard and the organization’s process for
managing and defining access controls through user groups and roles. In
addition, the CISO and the CPO often have to work together to resolve breaches
of privacy-sensitive information. The best practice is to identify sources of
potential threats and identify the contributing risks that may negatively impact the
organization. CISOs often provide tenured expertise with this practice and can
help the CPO office develop and implement metrics and procedures to support
risk mitigation.

The following effective tools from the security domain have a direct impact on
privacy management:
򐂰 Fine-grained data authorization and access control (privacy management
calls this disclosure management)
򐂰 Audit logging and analysis for policy compliance
򐂰 Data typing or classification to establish data-handling requirements
Encryption is often included in the privacy management domain, but it really is a

security tool for ensuring confidentiality and integrity. It is used to mitigate the
risks from unauthorized use of information. The industry’s best practices
separates the security and privacy domains by sources of threats and risks to
information retained by the organization.
The CPO and CISO roles work together to reduce the threats to the information
retained by the organization by both authorized and unauthorized users. The
security role is focused on threats from unauthorized users and external factors
where privacy is focused on internal threats often from authorized users of the
information.
1.4.3 Internal auditor or compliance officer

Internal auditing is very important in effectively monitoring and managing the
information-handling practices of an organization to achieve the privacy
objectives of the business strategy. The internal auditor needs to work closely
with the CPO to understand and develop metrics from the privacy management
requirements. These metrics need to examine all sources of disclosure of
information and align those disclosures with the data collection policies that the
information was collected under. This helps an organization identify points in the
information flow that can lead to a privacy threat. The internal auditor can assist
the CPO and CISO in the development of standards and practices to more
effectively manage information disclosures through the use of automation. This is
key to reducing the risk because automation can improve consistent
implementation of these standards and practices. Internal audit ing can help
develop the information flow and information usage patterns that an organization
organically develops. Privacy management tools offer the auditor an insight into
how some of the most valuable information an organization retains is used and
managed. Working together, these roles can effectively monitor the
implementation of privacy controls to reduce the risks for the organization and
protect one of its most valued assets - privacy-sensitive information.
1.4.4 Human resource officer
The human resources (HR) group has a direct impact on privacy management
and a dependency on effective privacy management of the information the
organization stores about employees and contractors. The human resources
group often is the first contact point for employees, contractors, and so on within
the organization to learn about the organization’s policies and standards. HR
often provides the workforce training and re-training for compliance with these
policies, and it enforces disciplinary action if these policies are violated. Privacy
management needs to integrate HR into the processes for the establishment and
implementation of privacy management practices. Key integration points include:
򐂰 Development of data classification schemes
򐂰 Development of data-handling requirements for employee information
򐂰 Development of employee policy education
򐂰 Defining auditing and evidence requirements for employee disciplinary
actions
HR is a source of privacy requirements and a key execution point for risk

mitigation tactics for manual processes carried out by employees and
contractors. The most common mitigation tactic leveraged by HR is education.
Their contribution to privacy requirements can often be implemented through
information technology systems within the organization with the assistance of
privacy-enabled technology.
1.4.5 Application development architect

Integration of privacy into the information technology infrastructure is usually
guided by an application architect. This role in privacy management is to identify
access paths to privacy-sensitive information from the user to the data storage
systems. Once the access paths have been identified, a workflow model is
developed8.
One best practice for this role is to identify the data that is used and disclosed,
the application and transaction that is used to access the data, and the business
purpose of the transaction at each step in the workflow. Each step that discloses
or uses privacy-sensitive information introduces the risk of appropriate
disclosure.
The best practice for managing this type of risk includes the implementation of an
authorization gate, and logging information on the access path as close to the
data storage system as possible that contains the privacy-sensitive information.
In addition, the workflow analysis should contain the applications and
8
An excellent modeling tool for business processes is Holosofx® from IBM. More information can be
found at http://www-3.ibm.com/software/integration/wbimodeler/

transactions used to support each step in the business process. This mapping of
business process to application and transactions supports the purpose
classification of the transactions that access, use, and update privacy-sensitive
information. With these tools and documentation, an application or systems
architect can analyze and select the best control points to implement a technical
risk mitigation solution. Application of a technical solution is often designed and
implemented through Information technology architecture enhancements to
achieve consistent implementation of risk-reduction tactics.
1.4.6 Database administrator

One of the critical tasks in privacy management is the identification of where the
privacy-sensitive data is retained in the organization’s information systems. Often
this information resides in the databases of key information systems such as a
Customer Relationship Management System, Patient Record System or
Customer Service Application. The database administrators and designers have
access to the applications’ logical data models and can assist with the
implementation of privacy controls by classifying or at least identifying
privacy-sensitive information. Once the privacy-sensitive information has been
identified, the access paths to that data can be identified and evaluated for
privacy risks and threats.
Two best practices that are usually implemented by the database management
team include the evaluation of the database logs and development of the
enterprise data dictionary.
Once a database has been identified to contain privacy-sensitive information, the

logs of that database should be examined to determine the applications that
access the database and, if possible, the users who access the data. This
process helps identify all access paths to the data. Business process owners and
application architects are usually not aware of all of the users or access paths to
a data storage system, but careful log analysis can help determine this
information.
The best practice to manage enterprise privacy risks is to know where all of the
privacy-sensitive information is retained. A very helpful tool for this task is an
enterprise data dictionary that includes all of the enterprise data elements and
documents the data classification of each element. Developing this enterprise
data model alone can be a very challenging task and is usually done organically
over time rather than in a single discovery effort. Documenting changes and
additions to the enterprise data dictionary helps to manage privacy threats and
risks by at least providing a map or inventory of where the privacy-sensitive
information is retained. One approach to this practice is to use a federated
database to support the task. IBM DB/2 software has this capability to develop,
maintain and manage access to an enterprise data dictionary9 and to implement
a federated database management approach.
1.5 Practical example

Here is an example of how a privacy policy is defined and implemented with
procedures and practices for Widgets Consumer Sales.
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 that 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 accordingly 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 a further audit of the environment.
The five steps we went through may be summarized using the chart in Figure 1-2
on page 22. It is a common approach adopted in many methodologies.
9
An article on this topic can be viewed at:
http://www7b.boulder.ibm.com/dmdd/library/techarticle/0203haas/0203haas.html.

Policies
Implement Risk
Manage Audit
Figure 1-2 The five steps in defining your IT security
1.6 Other considerations

In the privacy domain, there are a few unique issues that should be considered
before implementing a privacy program or enforcement solution.
The first is the concept of data ownership. If the organization accepts a property
rights framework about information, then the authority and responsibilities of
data ownership may lie outside the organization with the data subject for
personal information. This is a driver for a lot of regulation around the world. If the
organization adopts this approach to personal information, then the organization
needs to implement its responsibilities as a custodian of this information and
operate within the authority granted by the data subject. This means the
organization needs to implement a choice or consent program of some type.
The second issue is the development and application of a data classification

schema. This has been a common security standard that often has not been
implemented within the IT systems of an organization. Without proper exercise of
the standard, there has been little way to measure its effectiveness. As a key
standard in both privacy management and data disclosure management, the
data classification schema needs to have enough segmentation to adequately
express the variety of data-handling requirement sets. Most organizations have
developed schemas with as little as three to seven class segments and usually
they do not include classifications for personally identifiable information or
privacy-sensitive information. Before a privacy program or enforcement solution
can be implemented, this standard should be revised. Data classification is a
metadata attribute of a data element. Privacy requires that classification be
implemented at an element level, but some organizations have applied
classifications at a record level. In order to meet the requirements of most privacy
regulation this needs to be updated to record level resolution. Classification or
abstraction at this level usually requires more than seven categories to
sufficiently express the organization’s data-handling requirement sets. This
would be like saying that an organization of 5,000 employees only needs three
role definitions to adequately control access to information. Abstraction by
category does tend to follow a logarithmic model to adequately express the
required number of categories, but also suggests that as few as three would be
sufficient. However, this may leave significant gaps in security and privacy and
not allow flexibility to share information in ways that benefits the organization.
Once the data has been classified, its use and disclosure needs to be managed
by an authorization model that is evaluated on every transaction that accesses or
discloses the data. Transaction level authorization is required in order to be
sensitive to the specific instances of the data that may be governed by different
consent levels for specific purposes.
Another issue that may need special consideration is the concept of asserted
user credentials. There are two interesting use cases where the user credentials
are not relevant or useful for privacy enforcement purposes. The first use case,
and most common, is when an application server uses a shared user credential
to access data stored in a back-end database. In this case, the actual user who
initiated the transaction is not represented by the user credential that is identified
as initiating this particular transaction. What is needed here is a way to express
both the shared or application credential and an asserted user credential that
represents the actual person initiating the transaction. Privacy management, and
often security management as well, require the credential of the actual user in
order to determine authorized access or disclosure of certain information.
The second use case is an extension of the first. It is best expressed by a

customer service example. If a customer speaks with a representative after he
contacted the service department via phone, then it may be helpful to have the
application consider the user to be the actual customer on the other end of the
phone rather than the customer service user credential alone. Both may be
valuable to establish authority for privacy and security purposes, although most
access control systems only allow or support the use of the customer service
representative’s credential. This use case would assert the customer’s
credentials to the customer service representative’s credential and allow the
customer service representative to act as a proxy to the system for the customer
with full authority and responsibility. In addition, the organization would have the
necessary documentation to audit exactly what happened, who did what on
behalf of whom.

It is frustrating to work in an environment where you are constantly trying to
discover what you can do or not. It is even more frustrating when once all is set
up, services are blocked without any plausible reason.
How can you accuse an employee of attempting unauthorized actions when it is

not properly documented? Worse, if you need to take any legal action against an
employee, how can you justify it without supporting documents?
Since these documents are used as rules within an enterprise, they must be
clear and not subject to interpretation. In addition, they must be publicly
published and available. If a policy or a standard is written but not appropriately
published, how can an employee be expected to follow it? It is not a loss of time
to train the staff on these documents, especially when it is new and complex.
It is more efficient to get the staff enforcing a policy or standard they understand
than having them fight against it. They are a key part of the global security level
of the enterprise, and when they try to bypass some policy, they put your
enterprise in danger.
The policy and the standards are written to:

򐂰 Provide enterprise-wide rules
򐂰 Highlight the risks and the way to cope with them
򐂰 Formalize the security measures that must be applied
򐂰 Set up the expectation between the employee and the enterprise
򐂰 Clarify the procedures to follow
򐂰 Provide legal support in case of problems
1.7 Broader impact of privacy management

Privacy management is an excellent use case for a broader security domain
called Data Disclosure Management. Information security has a legacy of
focusing on controlling access to information containers. Access control models
focus on users and their access to resources. Data Disclosure Management
focuses on the opposite data flow path: controlling disclosure of information from
a resource to a user for a specific purpose. In addition, combining several data
elements may itself violate a policy. This is why Data Disclosure Management is
transaction focused and must examine the instances of the data returned from a
query for disclosure. Data Disclosure Management is data instance based
(actual record of specific data) and has two key requirements:
򐂰 Data element by instance authorization requirement
򐂰 Audit logging of all disclosures by user and purpose
The authorization models used for Data Disclosure Management are instance
based and are usually sensitive to the data type or classification of each element
in the instance record. They evaluate each transaction that records and discloses
data from storage locations. Fine-grained authorization is required and is usually
implemented through custom authorization models that do not tend to be very
flexible. Data Disclosure Management shares its requirement for a fine-grained
authorization model and the audit logging details with the privacy domain but
privacy has as an objective allowing flexibility with access and use of information.
Both domains depend on the data types and purpose of the disclosure to
determine if it is an authorized disclosure.
Data Disclosure Management is often found in financial systems and Intellectual

property management systems where data elements and their potential
combinations must be tightly controlled. This is another common requirement
that Data Disclosure Management shares with the privacy domain. There are
risks from associating one element with another to imply or, in the privacy
domain, identify an individual by demographic or secondary characteristics.
Combinations of certain data elements can introduce a threat to an individual’s
privacy; often this is an objective of a market research program. In certain
domains, such as health care, this may introduce a privacy threat to an individual
that could cause substantial harm. Effective controls for disclosure management
will help mitigate this and many other threats to information.

2
Chapter 2. Tivoli Privacy Manager

architecture
Deploying enterprise software solutions such as IBM Tivoli Privacy Manager can
have a high impact on the overall IT architecture of a company. IBM Tivoli Privacy
Manager consists of numerous components that need to be placed onto physical
systems. A good understanding of the components, what they do, and how they
communicate with each other is key to a good architecture design.
This chapter provides you with an understanding of the following topics:

򐂰 High-level logical component architecture of IBM Tivoli Privacy Manager
򐂰 Physical systems in an IBM Tivoli Privacy Manager environment and
component placement
򐂰 Scalability, high availability and performance considerations

2.1 Definitions
Since we are describing a fairly complex environment, we want to clarify some
terms before we proceeding. When referring to IBM Tivoli Privacy Manager, we
will use the term Privacy Manager when we consider the product with all its
components. The main components of IBM Tivoli Privacy Manager are the
monitor, the server and the database. Our environment contains several servers
and databases, and for this reason, we use the terms monitors, privacy server,
and privacy database respectively. A privacy-enabled application consists of the
application itself and a place where the application stores its data, so we will call
the components application and data store.
2.2 Logical component architecture

Before we go into the details of an IBM Tivoli Privacy Manager design, we give
an overview of the history of application development and IT architecture design.
This overview shows the motivation that leads to the development of IBM Tivoli
Privacy Manager from an IT architecture design and application development
point of view. Also, the relationship between IBM Tivoli Privacy Manager and IBM
Tivoli Access Manager is addressed. In the following three sections we sketch
the IT architecture of client/server applications and how they developed. We also
focus on the isolation of the common functions for authentication, authorization
and privacy in the IT architecture design.
Authentication answers the question:

Who can access to the application?
Authorization answers the question:

What functions can someone perform in the application?
Privacy answers the question:

What purpose is the accessed data used for?
2.2.1 Basic application components

When we talk about a client/server application in this context, we also consider
Web applications as client/server applications. The browser is the client
component and the Web server, Web application server, and database server
are the server components.
GUI
Application
Authentication Authorization Privacy
Data Store
Figure 2-1 Basic components of a client/server application
As shown in Figure 2-1 the application components of a client/server application

consist of a graphical user interface (GUI), an application and a data store. The
application contains hardcoded functions to enforce authentication, authorization
and privacy. A user has to log on to this particular application where it is
determined if he is allowed to use this application, what functions he can execute,
and what data he can see and/or manipulate. In all applications of a company,
these functions have to be addressed by the application itself. Concerning
privacy, the rules are not only hardcoded within the application, but enforced by
the business process. For example, before a list of customer purchases was
given to the marketing department for market research purposes, the individual
customer identifying data had to be masked as unreadable.
2.2.2 Centralized authentication and authorization service

Today everybody realizes that it is expensive and risky to develop and maintain
authentication and authorization functions for each individual application. It
becomes more and more common to isolate the authentication and authorization
functionality and provide them as a centralized service to the applications. Early
drivers for this trend have been centrally managed PC networks and e-mail
systems that needed a central directory where users could find other users’
e-mail addresses.
Chapter 2. Tivoli Privacy Manager architecture 29

GUI
Authentication and
Authorization
Service
Authentication
Data User Authentication Application
Authorization
Store Registry Framework
Authorization
Privacy
Data Store
Applications
Figure 2-2 Centralized authentication and authorization server
As you can see in Figure 2-2, the authentication and authorization service is
isolated from the application. It is provided as a service to all applications in a
company or in a domain. In the IBM Tivoli product world, the authentication and
authorization service is provided by the IBM Tivoli Access Manager products.
The User Registry is an LDAP directory implemented by the IBM Tivoli Directory
Server, which itself uses an IBM DB2® database as the data store.
2.2.3 Centralized privacy service

In Figure 2-2 the privacy service is still implemented inside the application, which
means it is hardcoded. Since privacy is a concern in a lot of applications, it
makes sense to isolate the privacy service in a similar way as in the
authentication and authorization service. So the next step in the evolution is the
isolation of the privacy service.
This trend is being driven by the following facts:

򐂰 Privacy sensitiveness
End users are becoming more privacy sensitive.
򐂰 Regulations and laws
New regulations and laws protect the privacy of individuals.
򐂰 Web-enablement of applications
Business processes are implemented in workflows that make intensive use of
intranets, extranets and the Internet. Privacy rules can‘t be enforced anymore
by business process instructions such as masking the customer name before
giving the purchases list to the market research people.
򐂰 Vertical industry integration
Business processes are more and more interwoven between companies that
partner to offer a product or service. Distributed data access between
partners is very common and privacy becomes important.
򐂰 Reporting requirements
Regulations and laws enforce businesses to record actions that access,
distribute, and manipulate data. This is because more and more actions that
have legal consequences are done electronically over the Internet.
Figure 2-3 shows how the privacy service is centralized and isolated for the
application.
GUI
Privacy Service
Authentication and Application Privacy Data-

Authorization
Service
Server base
Monitor Monitor Monitor Monitor
Data Store
Applications
Figure 2-3 Centralized privacy service

As you can see in Figure 2-3 on page 31, the privacy service is isolated from the
application. It is provided as a service to all applications in a company or in a
domain.
To implement a privacy service, the application that needs to be privacy enabled

has to be intercepted in order to check the privacy rules before data can be
presented to a user. The interception is implemented with a monitor. If the
application accesses personally identifiable information (PII), the monitor collects
additional information and passes this information on to the privacy server. The
privacy server makes a decision whether all, some or none of the data elements
the user wants to access can be exposed. To enable the centralized privacy
enforcement, the privacy server stores the privacy rules and consent information
in its data store. Consent defines what needs to be wiped out when data is
accessed for a certain purpose. Consent can be given or denied by the customer
or by company internal regulations and policies.
In the IBM Tivoli product world, privacy services are provided by IBM Tivoli
Privacy Manager, which itself uses a DB2 database as the data store. Monitors
enforce data access restrictions based on privacy policies.
As discussed in 2.2.2, “Centralized authentication and authorization service” on

page 29 and 2.2.3, “Centralized privacy service” on page 30, isolating a service
moves the complexity from a single application into the IT infrastructure. The
principle of economy of scale is applied to computer applications. By allowing
faster development, maintenance, and deployment of applications, it saves costs
and reduces security risks. As another important factor, this particular IT
architecture enables an enterprise to get prepared for the e-business on
demand™ age, because centralized services can be relocated to any place on
earth or even be outsourced.
2.2.4 Layered architecture for privacy management

In this section we describe a layered architecture for privacy management.
Figure 2-4 on page 33 depicts the three layers:
򐂰 User interface layer
򐂰 Application layer
򐂰 Service layer
Administrator CPO
Browser Browser
User Interface Layer
Application Layer
Service Layer
Application Authentication Data

Monitoring Authorization Storage
Figure 2-4 Layered architecture for privacy management
The user interface layer contains the graphical user interfaces for privacy
management administrators and for the Chief Privacy Officer and his staff. These
interfaces are Web-based and can be accessed with Microsoft or Netscape Web
browsers.
Underneath the user interface layer is the application layer. This is the layer
where privacy policies and monitor data is managed, reporting functions are
executed, and user consent is updated. The monitors trigger procedures in the
application layer to make the decision about which data fields can be exposed to
the application end user. The application layer make use of the features provided
by the service layer.
The service layer supports the application layer by providing basic functions such
as data storage and an authentication and authorization service. Data storage is
provided through a relational database where privacy policies, monitor data,
consent information and audit reports are stored. The authentication and
authorization service answers the basic questions about whether a user is who
he claims to be and what functions he is allowed to access. The most important
features of the service layer is the application monitoring service. Application
monitoring is the interception of applications to check if data access is
conforming to privacy policies.

2.2.5 Component description
In this section we take a closer look at the IBM Tivoli privacy management
solution implemented with IBM Tivoli Privacy Manager. We give a detailed
description of the components of the privacy management environment shown in
Figure 2-5.
Monitored System
GUI Web User

Interface
Application Privacy
Data Data Privacy Database
Collecting Accessing Monitor Data
Server
Ref.Mon.
Ref.Mon.
Storage
Ref.Mon.
SDK
Monitor
API
SDK
Monitor
API
SDK
Monitor Location
API
EJB
PII
Policies
Data Store Audit Trails
Reports
Authentication and
Authorization
Service
Figure 2-5 Components of a privacy management solution with IBM Tivoli products
Monitored system
The Monitored System is the customer application that needs to be
privacy-enabled. Users of a monitored system collect PII or access PII, which is
stored in the Monitored Systems Data Store. The Monitored System is accessed
by using a GUI. Examples of Monitored Systems are ERP applications and CRM
applications and directories.
Web user interface

The Web user interface connects to the Privacy Server, the actual Privacy
Manager engine that runs on the IBM WebSphere Application Server. The Web
user interface is implemented as a combination of JavaServer Pages, Servlets
and Enterprise Java Beans. The Web user interface is named the Privacy
Manager Console. The Web User Interface allows its users to accomplish the
following tasks:
򐂰 Create and modify, export and import privacy policies
򐂰 Administer monitors
򐂰 Create and manage report definitions
򐂰 Start and manage reports
The users can be grouped into the following categories:

CPO staff Performs the tasks associated with creating and publishing a
privacy policy as well as the tasks that an auditor can perform.
IT staff Performs the tasks required to set up privacy policies, and
monitors for deployment and to generate audit reports.
Administrator Performs a small number of tasks, such as deleting
persistently stored records that are no longer needed and
configuring the authorization service to allow Tivoli Privacy
Manager to obtain and publish the users and groups defined to
that service.
Auditor The auditor role is designed as an external auditing role to
create, manage, and run audit reports that provide an
historical accounting of PII submission and access in the
monitored system. These tasks can also be performed by the
CPO staff and IT staff roles.
Privacy Server
The Privacy Manager Privacy Server is the main processing component in a
privacy management architecture. It processes incoming requests from the Web
user interface and from monitors. The Privacy Server is connected to one or a set
of monitors. Incoming requests from monitors ask for decisions whether data
elements can be exposed to users of an application, or for new consent
submissions. In data access, a monitor request contains details about the identity
of the user, which storage locations are accessed, the purpose of the access,
and other defined conditions. After the Privacy Server has decided, a response is
sent to the monitor. The decision is made with consideration of data stored in the
data store and by the use of an authentication and authorization service.
Enquiries from the Web user interface are requests to create or modify Privacy
Manager configuration data, such as privacy policies, monitor definitions or
reports. This data is also stored in the data store. The Privacy Server component
is an Enterprise Application deployed on IBM WebSphere Application Server,
Advanced Edition.

Privacy Database
The Privacy Database contains tables for the following data:
򐂰 P3P (Platform for Privacy Preferences) policies
򐂰 Identity and group mappings
򐂰 Usage purposes
򐂰 Conditions
򐂰 Report definitions
򐂰 Data submissions
򐂰 Data access operations
These database tables are used by the Privacy Server when privacy decisions
are made and when reports are to be generated. The Privacy Database is
implemented using the IBM DB2 Universal Database™.
Monitors
To privacy-enable an application, one or more monitors need to be developed.
Monitors are adapters that exchange information with the application and the
Privacy Server. Monitors are the policy enforcement point within the architecture.
Monitors are implemented using the Monitor SDK to communicate with the
Privacy Server. Monitors also can be developed using the Reference Monitor
API, which simplifies the development (see Reference Monitor API below).
Monitors have the following functions:
򐂰 Poll the Privacy Server to find out if any new configuration data, such as policy
changes or monitor definition changes, is of importance for the monitor.
򐂰 Intercept an application to check if data access to PII is conforming to a
defined privacy policy.
򐂰 Pass new consent submissions to the Privacy Server.
򐂰 Inform the Privacy Server that PII data is accessed. This is performed for the
purpose of reporting.
Monitors are deployed in a WebSphere container on a WebSphere Client or

WebSphere Server.
SDK
The Monitor Software Development Kit (SDK) is a tool that allows customers to
develop customized monitors. It contains Java APIs that are used by a monitor to
connect to the Privacy Server and request enforcement decisions. The SDK is of
primary interest because in most customer-specific deployment cases, monitors
need to intercept existing applications that need to be privacy-enabled. The SDK
provides the following functions:
򐂰 Register a monitor and get information about a registered monitor.
򐂰 Register and manage storage location lists.
򐂰 Submission of PII storage locations and report of PII data access.
򐂰 Real-time privacy policy conformance check.
򐂰 Monitor exception.
The SDK is located in a WebSphere container on a WebSphere Server or

WebSphere Client. The Client uses the Internet Inter-ORB Protocol (IIOP) to talk
to EJBs on the Privacy Server.
Reference Monitor API

The Reference Monitor for Tivoli Privacy Manager is a reference implementation
of a Tivoli Privacy Manager monitor, consisting of sample code that can be
modified quickly to build privacy functionality into new or existing applications.
The Reference Monitor’s purpose is to simplify the task of developing new
privacy monitors. The Reference Monitor API makes use of the Monitor SDK.
Typically most new monitor developments use the Reference Monitor API,
because it allows a rapid monitor development.
Reference Monitor provides a low-level foundation API and a sample Reference

Monitor, which also includes the complete Java source code of its
implementation. The code is necessary for customizing a Reference Monitor for
a new application. The Reference Monitor is not part of the IBM Tivoli Privacy
Manager product. Instead it can be download from IBM alphaWorks® at:
http://www.alphaworks.ibm.com
Note: At the time this redbook was written, there were two monitor
implementations available on alphaWorks: the Reference Monitor as
described above and a monitor for HIPAA that adds privacy controls to the IBM
WebSphere Business Integration Collaboration for HIPAA Transaction by
monitoring claims transactions between health care payers and providers,
ensuring that privacy policies and individual privacy choices are respected.
򐂰 The Reference Monitor for Tivoli Privacy Manager can be found at:
http://www.alphaworks.ibm.com/tech/refmon
򐂰 The Privacy Manager Monitor for HIPAA can be found at:
http://www.alphaworks.ibm.com/tech/hipaa
Authentication and authorization service

The Privacy Server uses Tivoli Access Manager to associate authorized users
and groups with the groups defined in a privacy policy. The Privacy Server maps
application-specific users and groups to Tivoli Access Manager.

2.3 Physical component architecture
In this section we describe how the logical components can be mapped onto a
physical infrastructure. For component placement, a privacy IT architect may
choose from many options. To make the choice clear, we describe in the
following section an architecture that uses a dedicated server node whenever
possible. We describe the functions of each server node and list the advantages
for this configuration. In 2.3.2, “Enterprise Privacy Server configuration” on
page 44, we describe an architecture that centralizes as many components as
possible. These two sample architectures provide the reader with a good
overview of the kinds of solution architectures that are possible.
2.3.1 Dedicated server configuration

Figure 2-6 on page 39 shows the dedicated server configuration. We explain all
major components in the following sections.
Privacy Database
Customer Application Privacy Server
Database
Server WebSphere
Server
Server
DB2
WebSphere Privacy
Application WebSphere Database
Container Privacy
Monitor Data
Server Storage Loct
Ref DB
Monitor Mon SDK EJB Client PII
API Policies
Audit Trails
Data Store Reports
AM Java RTE
Access Manager
Server
Policy
Server
LDAP Client
LDAP
Server
LDAP
DB2
Figure 2-6 Dedicated server configuration
Customer application server

The customer application server contains the application and the application data
store. To privacy-enable a customer application, a Privacy Manager monitor
needs to be installed. The Privacy Manager monitor itself requires the Monitor
SDK and a WebSphere container as a runtime environment. In the following
sections, each component is described.
Application
These are customer-specific applications that need to be privacy-enabled.
Usually these applications cannot be changed and have to be taken as a given.
Applications can be of any type, such as Web-based application, client/server
application, or mainframe-based. Therefore, they can be located on any type of
server in the customer environment. For interception by a Tivoli Privacy monitor,

in the ideal case, the application is a Java application with well-documented
access routines to its data store. A WebSphere client needs to be available on
the application server as well as providing the runtime environment for the
monitor. If the customer application is not Java based, other ways must be
explored to intercept the application. Some of these possibilities are discussed in
Chapter 3, “Monitor patterns” on page 63.
Application data store

Usually this component is also a given and determined by the customer’s
environment. The application data store can be a relational database, a file or file
system, a proprietary database, or an LDAP user registry. It can be located on a
Windows or UNIX server or on a mainframe. Whatever mechanism the customer
application uses to access the data store, it has to be intercepted by the monitor.
Often the application data store is physically co-located with the application.
Monitor
This is the component that has to be developed to intercept the application and
the application data store. It requires the Monitor SDK. Whenever possible a new
monitor development should be based on the Reference Monitor.
Monitor SDK
The Monitor SDK is the Java API used to develop monitors. The Monitor SDK
needs to be installed in a WebSphere container.
WebSphere container
The WebSphere container is required as a runtime environment for the monitor
and can be provided by either a WebSphere Client or a WebSphere Server. In
this WebSphere container, the monitor and the Monitor SDK are installed.
The following products need to be installed on the customer application server:

򐂰 Customer application
򐂰 Customer application data store
򐂰 WebSphere container
򐂰 Monitor
򐂰 Monitor SDK
Privacy Server
The Privacy Server is a Java application that runs on IBM WebSphere
Application Server, Advanced Edition. WebSphere Application Server is a J2EE
certified application server that provides the runtime environment for the Privacy
Server. The Privacy Server runs in one Java Virtual Machine (JVM) and uses a
Web container and an Enterprise Java Bean (EJB) container. The Web container
is used for the Web user interface, and the EJB container is used for the Privacy
Server core functions. To access the Privacy Database, a DB2 client needs to be
installed on this server. The Access Manager Java Runtime Environment is used
to provide access to the Tivoli Access Manager Policy Server to resolve
user-to-group mapping. The following products need to be installed on the
Privacy Server WebSphere Server:
򐂰 WebSphere Application Server
򐂰 DB2 client
򐂰 Access Manager Java Runtime Environment
򐂰 Privacy Manager Server
Note: There is a distinction between the Access Manager Runtime

Environment and the Access Manager Java Runtime Environment. The first
one contains libraries and supporting files that all Access Manager
components share as a basic library. The latter one is used by any Java
application that wants to use the Access Manager authorization services.
Privacy Database Server

The Privacy Database Server maintains all the data the Privacy Server stores. It
contains one database with database tables for monitor data, storage locations
and other details of Personal Identifiable Information (PII), privacy policies and
audit reports.
The following products need to be installed on the Privacy Database Server:

򐂰 DB2 Universal Database
򐂰 Privacy Manager database
Access Manager Server

Tivoli Privacy Manager uses Tivoli Access Manager as the user and group
registry. Tivoli Access Manager is used to check if the user who is accessing data
belongs to a certain group. The privacy policies are defined to allow certain
groups to see certain data elements.
The following components need to be installed on the Access Manager Server:

򐂰 Access Manager Runtime Environment
򐂰 Access Manager Policy Server
Note: Privacy Manager utilizes the pdadmin APIs in order to communicate

with Access Manager. Therefore, the Access Manager Policy Server needs to
be available at all times to answer Privacy Manager requests, since it is the
only Access Manager component that accepts pdadmin API calls.

LDAP Server
The LDAP Server is a requirement of Tivoli Access Manager that stores user and
group definitions as well as metadata in the LDAP server. The following products
need to be installed on the LDAP Server:
򐂰 IBM Tivoli Directory Server
򐂰 DB2 Database
At this point, we want to mention a special role the LDAP Server can play, apart
from its role as data store for Tivoli Access Manager. Since an LDAP Server is a
common data store for PII data, it is practical that an LDAP Server is monitored
for privacy reasons. In this case, an LDAP Server is nothing else than a data
store for a customer application. Because the LDAP Server is a common place to
store PII data, and an LDAP Server provides a well-defined interface, Tivoli
Privacy Manager comes with a set of monitors for LDAP Servers.
Network connections
Figure 2-7 on page 43 uses the dedicated server configuration to illustrate the
network traffic and the protocols used between the components.
Privacy Database
Customer Application Privacy Server
Database
Server WebSphere
Server
Server
DB2
WebSphere Privacy
Container Privacy
Monitor Data
Server Storage Loct
Ref DB PII
Monitor Mon SDK EJB Client
API Policies
Audit Trails
Data Store Reports
AM Java RTE
Access Manager
Server
DB2,
Policy
TCP/IP
TCP/IP
RMI, CORBA- Server
IIOP, TCP/IP
SSL, LDAP Client
TCP/IP
LDAP LDAP, (SSL),

TCP/IP
Server
LDAP
DB2
Figure 2-7 Network Protocols between components of Dedicated Server Configuration
Since Monitor and Privacy Server are EJB applications, they use Java Remote
Method Invocations (RMI) over CORBA-IIOP on top of TCP/IP to communicate
with each other.
Note: In Version 1.2 of the Tivoli Privacy Manager product, the Privacy Server
implements a Web Services interface based on SOAP for Monitor-to-Privacy
Server communication.
The Access Manager Java Runtime Environment uses a secure protocol based
on SSL to communicate to the Access Manager Policy Server.
The Access Manager Policy Server uses an LDAP client that communicates with
the LDAP server using the LDAP protocol, which is based on TCP/IP. Optionally,

SSL can be switched on between LDAP client and server to encrypt the data
packets. The DB2 client uses a DB2 protocol on top of TCP/lP to communicate
with the DB2 server.
Usually all components of the privacy management solution are located in the
secure zone behind all firewalls. However, one can think of the case where the
customer application’s front-end is located in the Demilitarized Zone (DMZ) and
the data store is in the secure zone. Because of monitor design issues, the
monitor could now be located in the DMZ, close to the application’s front-end or
in the secure zone close to the data store. In the case of the monitor being
located in the DMZ, the monitor communication would need to cross a firewall.
This would require that CORBA-IIOP needs to run across the firewall.
Advantages of dedicated server configuration

The dedicated server configuration has the following advantages:
򐂰 Using individual servers for each function increases the deployment flexibility.
򐂰 Since Tivoli Access Manager is not tied to Privacy Manager, it can be used as
the centralized authentication and authorization service for other applications
as well.
򐂰 If one server has a failure, the other servers still work and provide their
functionality.
2.3.2 Enterprise Privacy Server configuration

Figure 2-8 shows the Enterprise Privacy Server configuration.
Customer Application
Enterprise Privacy Server
Server
DB2
WebSphere Privacy
Container Privacy LDAP
Monitor Data
Server Storage Loct
Database
Ref Admin Data
Monitor Mon SDK EJB PII
User Data
API Policies
Audit Trails Group Data
Data Store Reports
AM Java RTE
Access Manager LDAP

Policy Server Server
Figure 2-8 Enterprise Privacy Server configuration
In the Enterprise Privacy Server configuration, components are concentrated on
one server as much as possible. This means we have one server that runs the
customer application with its data store and the monitor, which requires a
WebSphere container and the Monitor SDK. All other components are installed
on the Enterprise Privacy Server. This server contains the IBM WebSphere
Application Server with the Privacy Server EJB application, and the Access
Manager Policy Server components with its Java Runtime Environment. Also
located on this server is the LDAP server and the DB2 database, which contains
the Privacy Database and the LDAP database.
Advantages of Enterprise Privacy Server configuration

The Enterprise Privacy Server configuration has the following advantages:
򐂰 Fewer servers means less server management effort, which means lower
operational costs.
򐂰 Components can communicate faster, because they use local server-internal
channels.
򐂰 Reduced components, for example a separate DB2 client is not needed.
2.3.3 Other parameters which influence the architecture

As can been seen from the three configuration examples above, there are many
ways the logical components of a privacy management solution can be mapped
onto physical systems. In the following, we give a list of parameters that should
also be considered when designing a privacy management solution:
򐂰 The WebSphere Application Server itself consists of several components,
which can be separated on different machines.
򐂰 The DB2 database consists of a lot of files that can be stored on different hard
disks.
򐂰 Firewalls may influence architectural design. See “Network connections” on
page 42.
򐂰 The Monitor design might require that certain components need to be
installed on a certain server.
򐂰 Scalability, performance, and high availability considerations might influence
architectural design.

2.4 Scalability, high availability, and performance
The following sections describe what needs to be considered in respect to
scalability, high availability and performance, when designing a privacy
management solution.
2.4.1 Scalability considerations

Scalability means that an application can be used more frequently or by more
users without the loss of performance. A typical scenario around a centralized
privacy service starts with one privacy-enabled application. Later, other
applications are migrated to use the central privacy service. Another scenario
involves an application that is used more frequently because of increasing
demands, which means more privacy-related checks must be performed.
A good architectural design considers and provides scalability. Scalability is

closely related to high availability in that application environments must have a
backup system for every component. This implicitly means that the application is
also scalable, because a second component can be activated in the case of high
load instead of only failure of a component. For this reason, we do not explicitly
describe scalability for each component, but we do for high availability.
2.4.2 High availability considerations

When considering high availability we can look at the physical components, as
they are described in 2.3, “Physical component architecture” on page 38. A
closer examination shows that we need to consider the following components for
high availability:
򐂰 LDAP Server
򐂰 DB2 database for Privacy Server
򐂰 Tivoli Access Manager
򐂰 Privacy Server
򐂰 Monitors
򐂰 Customers privacy-enabled application
In the following subsections we give hints or references to help implementing

high availability of each component.
LDAP Server
In most cases privacy management is just another application using the LDAP
Server infrastructure and there are already other applications deployed that
extensively use LDAP. The LDAP infrastructure has become one of the most
critical elements in the enterprise IT infrastructure. Inherent in LDAP are
replication mechanisms to assure scalability and high availability.
Replication can be used to improve performance by providing a service from
multiple machines in order to satisfy a search as quickly as possible. Replication
can also be used to improve the availability of a directory service by having more
than one server. If one of them is temporarily down, the directory service
continues to be available from another server. The IBM Tivoli Directory Server
replication is based on a master-slave replication model.
There are two types of directories with respect to replication: master and replica.
LDAP refers to the master as the master server and to the replica as the replica
server. All updates are made on the master server, and these updates are
subsequently propagated to the replica server(s). Every replica server’s
database contains an exact copy of the master server’s directory data. A replica
server can be promoted as master server if required (for example, if the master
server is out of service for an extended period of time) in order to allow write
operations to the directory during this time.
Changes can only be made to the master server. If a replica server receives a
request to update an entry, this request will be returned with a reference to the
master server using a referral.
For more information on how to set up LDAP replication, refer to the LDAP
Implementation Cookbook, SG24-5110 and the latest product documentation for
the IBM Tivoli Directory Server.
Note: It is IBM’s stated intention to publish an updated version of the LDAP

Implementation Cookbook, SG24-5110-01 in the first quarter of 2004 that will
be based on the IBM Tivoli Directory Server 5.2.
DB2 database for Privacy Servers

Since this book is not going to focus on DB2 details, we recommend that you
refer to the redbook DB2 Warehouse Management: High Availability and Problem
Determination Guide, SG24-6544 for information on how to set up a DB2
database for high availability.
Tivoli Access Manager

Since Privacy Manager uses the pdadmin API interface to request user and
group information from Access Manager, the Access Manager Policy Server
needs to be available 24x7. In order to meet this requirement, the Policy Server
component needs to be configured on an AIX® based HACMP configuration
cluster — you can also configure HA solutions for the other supported operating
system platforms.
Since the Policy Server is the only component in the Access Manager framework
that answers to pdadmin calls, you cannot afford the Policy Server going down if

you have a Privacy Manager infrastructure because every request for data
access needs to check group membership information on the Access Manager
platform.
Privacy Server
Since Privacy Server is a J2EE application running on an IBM WebSphere
Application Server, a clone application server needs to be configured on a
different machine — in the following, we call the two machines original and
clone.
To create clones in a WebSphere environment, a Server Group needs to be

created on the original server. The Server Group can be created using the
WebSphere Administrative Console, right-click the Default Server and select
Create Server Group. The Server Group can be named PMgroup.
On the clone server, we have to install a DB2 client and the Privacy Manager and
WebSphere Application Server databases need to be cataloged for this DB2
client. The properties file <WAS_HOME>/properties/sas.server.props needs to
be copied from the original server to the clone server. Both nodes, original and
clone, should be displayed when running the WebSphere Administrative Console
on both nodes. Using the WebSphere Administrative Console on the clone node,
the Application Server clone needs to be created in the PMgroup by right-clicking
PMgroup -> New -> Clone. Privacy Manager and the Access Manager Java
Runtime Environment have to be installed and configured on the clone server.
The privacy.ear file needs to be copied from the original server and expanded on
the clone.
Monitors
Backup monitors are only needed if the monitors are separated from the
application. Most likely, the monitors are tightly connected to the applications and
thus can be considered part of the application. When the monitors are separated
from the application, a backup WebSphere container with the installed Monitor
SDK and the monitors needs to be triggered to take over and interface with the
application. The backup monitors have to be registered with the Privacy Server.
Privacy-enabled application
If the privacy-enabled applications require high availability, so must the monitors.
In case of a switchover, the monitor must re-register with the Privacy Server and
reload the configuration.
2.4.3 Performance considerations

Since Privacy Manager is a J2EE application running on WebSphere Application
Server and DB2, performance issues on these components have a high impact.
The following sections give hints on how these components and the underlying
operating systems can be tuned for better performance. The last subsection
gives advice on how the Privacy Server itself can be tuned.
Operating system tuning

Let us take a look at AIX, Solaris, and Windows tuning for Privacy Manager.
AIX
The number of local IPC (inter-process communication) connections is restricted
on AIX. This can become an issue when a DB2 client is used to access a DB2
database on the same server. The solution is to remotely catalog a local DB2
database as remote, so that the IPC connections are used more efficiently. For
details, see the DB2 product documentation.
Solaris
On Solaris, system parameters for message queues, shared memory, and
semaphores can be tuned for better performance. Message queues, shared
memory and semaphores are low-level operating system features for IPC. In the
/etc/system file, the following changes are recommended:
Increase the following:

set msgsys:msginfo_msgssz = 40
Increase the following:

set shmsys:shminfo_shmseg = 70
Add the following:

set semsys:seminfo_semume = 75
set semsys:seminfo_semopm = 60
Windows
If you are running a Windows 2000 Server version in a distributed environment, a
performance improvement can be achieved by optimizing the system for network
traffic instead of file sharing.
To configure the system for network traffic:

1. Select Start -> Settings -> Control Panel.
2. Click the Network and Dial up connections icon.
3. Click the Local Area Connections icon.
4. Click the Properties button.
5. Highlight File and Print Sharing for MS networking.
6. Click the Properties button.
7. Select Maximize data throughput for network applications.

Database tuning
Possible database tuning steps are the splitting of table spaces on to dedicated
disks. With preferably three disks, binaries (operating system, DB2) and logs can
be put on one disk 1, table spaces except access Binary Large Objects (BLOBs)
and submission BLOB table spaces can be put on disk 2, and access BLOB and
submission BLOB tables can be put on disk 3. Database BLOB tables contain
references to data in the database.
Another tuning task could be the use of Database Managed Space (DMS)
instead of System Managed Space (SMS). In the case of an SMS, a data
container is a file system directory. Tables and files are created as numerous files
within the directory. This means the tablespace is subject to file system
fragmentation and overhead during the opening and closing of multiple files. The
default installation for Tivoli Privacy Manager uses SMS.
DMS requires an up-front allocation for storage. The DMS container is a single
file in a host file system or can be created directly on a disk, bypassing the file
system altogether. In this way DMS delivers much better performance.
Database tuning can increase system performance by approximately 30%. The

actual work should be done by an experienced database administrator with skills
in database tuning.
WebSphere tuning
As an initial starting point, it is recommended that you run the Performance Tuner
wizard that is available through the WebSphere Administrative Console. This will
tune common performance-related settings for both the WebSphere Application
Server and the Privacy Manager database. In Table 2-1 we list the important
parameters and provide an explanation and their default values.
Table 2-1 WebSphere Tuning Parameters

Parameter Explanation Default Value calculation
value
Web container max Specifies the number 50 Default value should be sufficient. Increase if
threads of threads available to you need more than 25 parallel running
Privacy Manager Privacy Manager consoles.
consoles.
value
ORB thread pool size Size of an Application 20 Example with LDAP monitors:
Server queue (Number of monitors *
through which a client LDAP.MONITOR.SERVER.CONNECTIONS.
request flows on its MAX)
way to a database. +
(Sum of
LDAP.MONITOR.SSA.THREAD.MAX, for all
monitors with enforcement ON)
+
total number of monitors
+
(Number of concurrently used consoles * 2)
Data source Maximum number of 10 Example with LDAP monitors:

connection pool size connections to a data (Sum of
source (JDBC). LDAP.MONITOR.SSA.THREAD.MAX, for all
monitors with enforcement ON)
+
(Sum of
LDAP.MONITOR.SERVER.CONNECTIONS.
MAX for all monitors with enforcem. ON)
+
(Sum of
LDAP.MONITOR.SERVER.CONNECTIONS.
MAX for all monitors with enforcem. OFF *2)
+
total number of monitors
+
(Number of concurrently used consoles * 2)
= Sum
Multiply this sum by 0.9
Prepared statement Number of prepared 100 Data source connection pool size * 200
cache size SQL statements (200 is the approximate number of SQL
which can be stored prepared statements used by Tivoli Privacy
in a cache. Manager 1.1).
JVM starting heap The heap size used 0 Recommended value:

size a by the JVM when it 1/4 of JVM maximum heap size
starts. The starting
heap size should be
set to 1/4 of the
maximum heap size.

value
JVM maximum heap The maximum heap 0 Recommended values:

size size the JVM 128 MB for machines < 1 GB memory
allocates. 256 MB for machines < 2 GB memory
512 MB for machines >= 2 GB memory
a. The Java heap is where the objects of a Java program live. It contains live objects, dead objects,
and free memory. The heap size determines when the virtual machine is collecting garbage, which
means deleting dead objects. The heap size is application-specific and should be adjusted after the
application is monitored for a while. Large heap size means garbage collection is slower but occurs
less frequently. Low heap size means faster garbage collection, but executed more frequently.
It is recommended that only experienced WebSphere administrators make

changes to these parameters. It is absolutely necessary that the operation of
WebSphere and Privacy Manager be monitored before the changes are made.
From the monitoring logs, the WebSphere administrator can derive reasonable
parameter values for tuning.
Privacy Server tuning

For general Privacy Server tuning, the following rules can be applied:
򐂰 Database housekeeping
By keeping the amount of data that the Privacy Server stores in its Privacy
Database small, search times can be reduced. Frequently clean up or back
up submission, access, testing and audit records.
򐂰 Condition rules
Minimize condition rules and define only those needed to meet legal and
corporate objectives.
򐂰 Impacts of enforcement ON
Enforcement ON can severely impact network throughput for all applications
for which a monitor is deployed. As traffic increases, throughput and
application availability are impacted further. If the privacy enforcement needs
of your organization do not require enforcement ON, it is recommended that
this level of enforcement not be used.
򐂰 Impacts of enforcement OFF
Even though data access is not blocked when enforcement is OFF, network
throughput is still impacted by the enforcement process. Defining and
deploying multiple monitors can increase the concurrency in data flow. After
an initial successful deployment of one monitor, additional monitors can be
deployed to better manage network load.
2.5 The IBM Enterprise Privacy Architecture
In this section, we introduce the IBM Enterprise Privacy Architecture (EPA),
which can be used in the early stages of a privacy project to evaluate the existing
environment, to identify existing components and functions, and to design a
product-independent solution. In later project phases, the solution will be
implemented with existing products. We discuss how Tivoli Privacy Manager fits
into this conceptional model and which components of the model are
implemented by Tivoli Privacy Manager.
EPA is a conceptional model that considers an overall installation to handle

personally identifiable information (PII). It describes the actors and data involved
in respect to privacy. Figure 2-9 shows the actors, the actions, and the data that
are involved in a real-world scenario.
Data Users
disclosure
using PII
Obligations PII Privacy

Policy
policy
described by negotation
capture data
release PII
Data Subject
Figure 2-9 Real-world privacy scenario

In this scenario the following actors perform:
Data subjects Data subjects are individuals that are described by PII.
Examples for PII are social security number, ID card number,
and date of birth.
Data users Data users are individuals or members of an organization
that make use of PII. Examples are the marketing
department, compiling sales reports, or an employee
accessing a credit record. Data users belong to the
organization that originally captured the PII or to an external
organization.
Other important objects in a privacy scenario are:

Obligations Obligations are responsibilities that define the handling of PII.
Obligations result from the application of regulations and
laws. Example obligations are the regulation to delete data
after a certain time or to allow the data subject access to his
or her data.
Privacy Policy A privacy policy contains a set of rules that allow or forbid
privacy-relevant actions on personal data under specific
conditions and for a certain purpose. An example is the data
access to the bank statement, if the account holder is under
18 and the accessor is a parent.
In a privacy scenario, the following actions happen:

Capture data PII is captured about the data subject. Usually this happens
when a data subject fills out a (Web-based) form that
contains data fields.
Release PII A data subject releases PII for certain use, according to the
privacy policy. The data subject can opt-in or opt-out from
certain choices in the proposed policy. The proposed policy is
presented to the data subject together with the form to
capture data.
Policy negotiationBy opting-in or opting-out, the privacy policy is negotiated
individually for each data subject who fills out a form.
Use of PII The use of PII by data users for certain purposes.
Disclosure of PII The forwarding of PII data from one user to another. In this
way the PII data can cross organizational borders.
To map this real-world scenario to a technical computer-based infrastructure,

EPA defines a technical component architecture, which is shown in Figure 2-10
on page 55.
Data User other
Data Subject Data User
Organization
Capture PII Use

Release PII Use PII disclosed PII
Negotiate Policy
Enterprise Applications
User
Directory and
Interaction
Security Node
Node
Privacy Data Handling Node
Support
Privacy Service Node
Tools Node
Figure 2-10 EPA technical component architecture
The technical component architecture consists of five nodes and the enterprise
applications. It should be noted that for each enterprise application a
corresponding Privacy Data Handling Node exists. The components are
described in the following:
Enterprise Applications Provide the actual services of the enterprise.
User Interaction Node Provides services to interact with the data
subject and other non-administrator users.
Privacy Data Handling Node Stores and protects personally identifiable
information (PII).
Privacy Service Node Is the centralized privacy management
component.
Directory and Security Node Provides services to authenticate users and to
securely exchange PII with other enterprises.
Support Tools Node Provides tools that are needed by other
components.
In Figure 2-11 on page 56, we show the components of the EPA technical
architecture and their interactions. The following sections describe each node
and its functions in detail.

PII Submit
Access Requests
User Interaction Privacy Data Handling Node Directory and

Node Security Node
Policy Presentation Policy Decision Privacy Enabling

Privacy Data Privacy-enabled
Policy Negotiation Point Resource Manager
Transformation Authentication
Engine User
Authentication
Web Legacy
Data Data
PrivacyActionManager Policy Consent
Deployment Engine
Privacy Contact Identity

Manager Mapping
Policy Negotiation, Log Privacy Log Privacy

Consent Replicate Decision Action
Attribute
Support Tools Privacy Service Node Exchange
Node Engine
Vulnerability
Checker Privacy Policy Privacy Action Privacy Obligation
Manager Audit Manager Event Service User
PII Discovery Authentication
Privacy-
enabling
Policy Consent Log Credential
Log Analyzer
Service
Edit Policy
Policy Editor
Figure 2-11 EPA technical component architecture details
2.5.1 User Interaction Node

As shown in Figure 2-11, the User Interaction Node is further broken down into
three separate functions.
򐂰 The Policy Presentation/Negotiation function is the Web page where the
Privacy Policy is displayed and where the user can opt-in or opt-out for certain
privacy data-handling procedures. The Policy Presentation/Negotiation
function interacts with the Privacy Policy Manager, which stores the policy for
the individual users and also stores the consent given.
򐂰 Another function in the User Interaction Node is fulfilled by the Privacy Action
Manager, which allows data subjects certain actions on their own PII, for
example to see what data the enterprise holds about them, to retrieve usage
logs, or to add or withdraw consent for certain types of usage.
򐂰 The Privacy Contact Manager in the User Interaction Node contacts the data
subject in case of an enterprise-triggered event concerning privacy
management. For example, if the general privacy policy has changed, the
data subject can be informed.
2.5.2 Support Tools Node

The Support Tools Node contains the Policy Editor, which can be used to edit
enterprise privacy policies as they are used in the Privacy Policy Manager.
Besides editing one policy in textual or graphical form, a policy edition might
allow merging of several policies, or offer additional visualization of certain policy
properties for policy validation (for example, consistency and completeness
checks).
The Log Analyzer examines the logs held in the Privacy Action Audit Manager. It
can generate reports on behalf of the Privacy Policy Manager or summarize logs.
PII Discovery is a tool for locating PII stored by an enterprise.
A Vulnerability Checker discovers privacy vulnerabilities in an enterprise, similar

to firewall or security vulnerability checkers.
2.5.3 Privacy Data Handling Node

The Privacy Data Handling Node is one of the most important components of a
privacy management solution. To store and protect PII it contains a
Privacy-enabling Resource Manager, which contains PII and gives other
components, including applications and users, access to it according to privacy
rules. It can contain an optional Deployment Engine that translates
application-specific technical terminology to generalized access requests. For
applying, the Privacy-enabling Resource Manager interacts with further
components, in particular the Privacy Policy Decision Point.
The Privacy Policy Decision Point is an engine that evaluates privacy rules. It
gets an abstracted access request from a Privacy-enabled Resource Manager
and returns a decision (“allowed” or “denied”) and possibly obligations. The
decision is based on policy and consent and may be based on additional data
from other PII. For example, the condition may be whether the accessor is a
parent of the data subject for which PII is accessed. The policy and consent is
either replicated from the Privacy Service Node or else retrieved when needed.
The Privacy Data Transformation Engine applies privacy-related transformations

to PII. The data may still be PII (for example, depersonalized but in a
re-personalizable way) or totally anonymized and thus no longer PII.

2.5.4 Privacy Service Node
The Privacy Service Node is the core management component of a privacy
management solution. The Privacy Policy Manager stores privacy policies,
including data-subject provided parts of them, ranging from simple consent over
opt-in or opt-out choices to entire sub-policies. It also interacts with the
Privacy-enabling Resource Managers to define how to deploy each policy onto
each Privacy-enabling Resource Manager. The Privacy Policy Manager stores
policies and consent in the corresponding PIIs. These are replicated onto the
Privacy Data Handling Nodes.
The Privacy Action Audit Manager logs access to PII. It must be used by
Privacy-enabling Resource Managers if the privacy rules require output logging
and may be used for further privacy-relevant actions. It provides services for
auditing and for accessing history data.
The Privacy Obligation Event Services keep track of privacy-action obligations.
2.5.5 Directory and Security Node

The Directory and Security Node contains the privacy-enabled authentication
function, which is an extension of normal security authentication to include
authentication based on pseudonyms, where the person’s identity is not known.
The identity mapping component maintains information needed to link entries in

different privacy-enabling Resource Managers.
The Attribute Exchange Engine supports the exchange of attributes (for example,
facts about a person) between different privacy-enabling Resource Managers or
applications, in particular with different organizations. It may also support policy
negotiation between applications.
The privacy-enabling Credential Service is a specific type of Attribute Exchange

Engine that supports the generation and verification of credentials, for example,
confirmation of attributes, while hiding the identity of the person.
2.5.6 IBM Tivoli Privacy Manager in EPA

Figure 2-12 on page 59 shows which components of the architecture are
implemented by IBM Tivoli Privacy Manager.
PII Submit
Access Requests
User Interaction IBM Tivoli Privacy

Privacy Data Handling Node Directory and
Node Manager IBM Tivoli Privacy Security Node
Monitor
Policy Presentation Privacy Policy Privacy Enabling
Privacy-enabled
Privacy Data
Policy Negotiation Decision Point Resource Manager
Transformation Authentication
Engine User
Authentication
Web Legacy
Data Data
PrivacyActionManager Policy Consent
Deployment Engine
Privacy Contact Identity

Manager Mapping
Policy Negotiation, Log Privacy Log Privacy

Consent Replicate Decision Action
Attribute
Support Tools Privacy Service Node Exchange
Node Engine
Vulnerability
Checker Privacy Policy Privacy Action Privacy Obligation
Manager Audit Manager Event Service User
PII Discovery Authentication
Privacy-
enabling
Policy Consent Log Credential
Log Analyzer
Service
Edit Policy
Policy Editor
Figure 2-12 EPA technical components implemented by IBM Tivoli Privacy Manager
As illustrated in Figure 2-12, IBM Tivoli Privacy Manager implements a Policy

Editor, the Privacy Policy Manager, the Privacy Action Audit Manager, and the
Privacy Policy Decision Point.
Let us refer back to the Privacy Database in Figure 2-6 on page 39. We see that
the database contains policies and reports. The policies correspond to the policy
and consent data shown in EPA. The logs of the Privacy Action Audit Manager
can also be found in the Tivoli product Privacy Database. Unlike in EPA, the
Policy and Consent databases are not replicated. Instead monitors, which are
called the Privacy-enabling Resource Manager in EPA terminology, access the
Privacy Database through the Privacy Server, which is called in EPA terminology
the Privacy Policy Decision Point.

Part 2
Part 2 Best practices

In this part we discuss three specific customer scenarios with different business
requirements and technical implementations, ranging from a WebSphere
application to Siebel 7 integration. A more generalized topic on Monitor patterns
is also included.

3
Chapter 3. Monitor patterns

Looking at different models of monitor implementations, we can identify different
patterns that provide a classification of individual approaches.
In this chapter we discuss the following five different patterns for a Privacy
Manager monitor deployment:
򐂰 Proxy Monitor
򐂰 Application Exit Point Monitor
򐂰 Application Callout Monitor
򐂰 Declarative Monitor
򐂰 Business Process Monitor
Since a pattern approach is always based on a similar model of implementation,

we look at the following aspects for each monitor pattern:
򐂰 Appropriateness - when to use
– Defined protocol
– Defined exit points
– Architecture adherence
– Access to source code
򐂰 Trade offs
– Performance
– Enforcement/audit only
– Application transparency

– Context information availability
3.1 Monitor background

The IBM Tivoli Privacy Manager for e-business Monitor Developer’s Guide
Version 1.1, SC32-4790 describes a basic blueprint for privacy monitors. The
blueprint is illustrated in Figure 3-1.
Storage Storage Privacy Privacy Privacy

Storage Monitor
System System Manager Manager Manager
System Implementation
Adapter Interface Interface Adapter Server
Figure 3-1 Monitor blueprint
The blueprint describes logical divisions of responsibility that exist within a typical
monitor. Table 3-1 lists the main responsibilities of monitors mapped to the logical
monitor components.
Table 3-1 Monitor component responsibility

Monitor Responsibility Blueprint Component
Learn the Storage System Storage System Adapter
Register Monitor Monitor Implementation,

Privacy Manager Adapter
Register Storage Locations Monitor Implementation,
Retrieve Monitor and Storage Location Monitor Implementation

Classifications
Poll Privacy Manager Server for Updates Monitor Implementation
Report PII Submission and Access Storage System Adapter
Enforce Privacy Policy Storage System Adapter
To assist with monitor development, Tivoli Privacy Manager for e-business ships
with a Java-based Monitor Software Development Kit (SDK). The SDK provides
the responsibilities and implementation of the Privacy Server Adapter.
Additionally, Tivoli Privacy Manager for e-business provides a component named
the Reference Monitor. The Reference Monitor provides the core functionality for
the monitor implementation and storage system interface. Using the Reference
Monitor, developers are required to provide the implementation of the Storage
System Adapter.
The Reference Monitor simplifies the development of new monitors. However,

careful analysis and consideration are still required when developing a new
monitor. The following sections discuss monitor patterns and describe various
analysis considerations and characteristics of monitored storage systems that
direct the design of the monitor toward a given pattern.
3.2 Proxy Monitor pattern

Figure 3-2 illustrates a generalized design template for a Proxy Monitor pattern.
Generic Proxy Monitor
Request Proxy Request

TransportAdapter Storage
Response Proxy Response System
Client or
Protocol Parser Metadata Processor
Browser
Realtime
Conformance
PIIAccess PIISubmission
and
Enforcement
Tivoli Privacy Manager Reference Monitor
Tivoli Privacy
Manager Server
Figure 3-2 Proxy Monitor design
As discussed in the IBM Tivoli Privacy Manager for e-business Monitor

Developer’s Guide Version 1.1, SC32-4790, monitors should ideally be placed as
close as possible to the monitored storage system. This is true for the Proxy
Monitor. The Proxy Monitor pattern is so named because the monitor behaves as
a proxy for the storage system with respect to the applications that use the
Chapter 3. Monitor patterns 65

storage system. The monitor is typically located on the communication access
path(s) between the client applications and the storage system. The LDAP
Monitor, which ships with the Tivoli Privacy Manager for e-business, is an
example of a Proxy Monitor.
A well-defined access protocol is the primary characteristic of monitored
environments that suit a Proxy Monitor design. The protocol is typically
carried over a network, for example TCP/IP. All access to the storage system
should be limited to well-defined transport endpoints.
A further characteristic of the monitored environment is the existence of a
well-defined, interpretable, and accessible metadata or schema. This is true
for all monitors, but particularly so for Proxy Monitors. The metadata allows
the monitor to register storage locations with the Tivoli Privacy Manager
server. The metadata also allows the monitor to automate request and
response parsing for interpretation of messages directed to and from the
monitored storage system.
Application environments based on message queue and network protocol
access to the storage system data are primary candidates for the Proxy
Monitor design.
򐂰 Architecture
The typical architecture components of the Proxy Monitor are illustrated in
Figure 3-2 on page 65.
The foundation of the Proxy Monitor design is its location between the storage
system and the applications that access it. Specifically, a monitor is placed on
the access path for each published transport endpoint of the storage system.
All client access and update operations are re-routed or channeled through
the monitor. The monitor then performs the given operation on behalf of the
client application. With real-time enforcement enabled, it is the monitor’s
responsibility to ensure any data returned to the client is in compliance with
the privacy polices defined on the Tivoli Privacy Manager server.
The following components of the Proxy Monitor map onto the Storage System
Adapter defined by the monitor blueprint:
– Transport Adapter
– Protocol Adapter
– Metadata Processor
The Transport Adapter is responsible for connecting with the transport
systems used to access the storage system. In order to place the monitor on
the access path, the Transport Adapter would be configured to listen for or
accept client requests on the same endpoint address as the storage system.
The storage system is then re configured to accept client requests on an
alternate endpoint address. The endpoint address of the actual storage
system is published only to the monitor. No other client access to the storage
system is permitted.
For a TCP/IP access scenario, this requires the configuration of a server port
for the monitor and an alternate port for the storage system. For a message
queue environment, two pairs of queues would be required. A
request/response queue pair is used between a client application and the
monitor. Another pair is used between the monitor and the storage system.
If the storage system supports multiple concurrent client accesses, it may be
necessary for the Transport Adapter to support this feature also. Additionally,
if authentication or other client context information is required by the storage
system, the Transport Adapter will need to support the ability to forward such
information to the storage system.
The Protocol Adapter is responsible for reading request and response
messages. It may use the services of the Metadata Processor to interpret the
messages. Once the messages have been interpreted, the adapter can
identify the storage location names referenced in both the request and
response messages. The Protocol Adapter can also classify the operation as
an access or submission so that the messages can be dispatched to
appropriate privacy handling modules.
The Metadata Processor is responsible for obtaining storage location
information from the storage system or messages used to access the storage
system. It may obtain the metadata by using the services of the Transport
Adapter or by using its own connection to the storage system.
򐂰 Trade offs
The Proxy Monitor design has the significant benefit of minimizing or
eliminating the need to modify source code on the client or storage system.
This assumes, of course, that transport endpoint connection addresses are
configurable at the storage system. The Proxy Monitor takes advantage of
this configurability to represent the storage system with respect to the clients.
The monitor intercepts client access and response traffic transparently.
Enforcement of governing privacy policy is typically feasible using the Proxy
Monitor design. The monitor is directly on the PII access paths between the
client applications and the storage system. All request and response traffic
flows through the monitor, so the monitor typically has the opportunity to filter,
modify, or deny response data.
A disadvantage of the Proxy Monitor design can be the lack of context
information available for a given access. For example, it is often difficult to
determine purpose. If the monitor is not managing the authentication to the
storage system on behalf of the client, identifying the data user can also be
difficult.

The Proxy Monitor design requires all client access traffic flow to be
channeled through the monitor. The potential then exists for the monitor to
become a performance bottleneck. It is critical that the monitor be designed
and implemented for high-volume traffic. The design of a new Proxy Monitor
should consider how connections for clients and the storage system are to be
managed and pooled. Using thread pools within the monitor might also be
considered. The design and deployment of the monitor should also consider
support for load balancing across multiple instances of the monitor.
3.3 Application Exit Point Monitor pattern

The Application Exit Point Monitor pattern is a style of monitor that takes
advantage of applications or storage systems that define architected hooks or
exit points for integration. Figure 3-3 illustrates a generalized design for this type
of monitor.
Application (ERP, CRM) Storage

System
Client Application App Pluggable

Events
Defined Interface
Interface
Application
Application Interface Adapter
API
Tivoli Privacy Manager Reference Monitor
Generic Exit Point Monitor
Tivoli Privacy
Manager Server
Figure 3-3 Exit Point Monitor design
The monitor is configured to be part of the monitored application. However, it is
not visible to client applications. The monitor is essentially behind the application.
The monitored application delivers events or programming invocations to the
monitor based on well-defined interfaces. On each invocation, the monitor can
perform conformance checks or notifications to Tivoli Privacy Manager server.
An Exit Point Monitor pattern is ideally suited to monitored applications that
support event registration and delivery, or user-implemented code modules
that are dynamically loaded. The exit points must be associated with data
access and update activity.
Enforcement can be supported only if the monitored application supports
synchronous delivery of events or notifications to the exit point to the monitor.
A further condition is that the exit point interface supports a type of return
indicator or can modify the result data set before returning control to the
monitor application.
򐂰 Architecture
The architecture of the Exit Point Monitor pattern is illustrated in Figure 3-3 on
page 68. The architecture is relatively simple and is typically driven by the exit
point interface defined by the monitored application. Using the Reference
Monitor, a new monitor should provide the implementation of the Application
Interface Adapter.
The Application Interface Adapter acts as the monitor’s storage system
adapters. It must provide the implementation of the exit point interface defined
by the monitored application. For example, if the exit point is defined in terms
of a C language export library, the Application Interface Adapter must
implement these functions. The adapter’s responsibility is to marshal the exit
point invocation parameters into method calls on the Reference Monitor.
Depending of the parameters delivered by the monitored application, it may
be necessary to use monitored application APIs to gather enough context
information for the Reference Monitor calls. The exit point delivery will drive
the Reference Monitor invocation, which will in turn drive the Monitor
Assistant invocation for required data values.
Typically part, if not all, of the monitor will be running within the process space
of the monitored application. This will certainly be the case if the integration is
based on a dynamically loaded C/C++ code library or loaded Java class.
򐂰 Trade offs
The primary benefit of the Exit Point Monitor design is the minimization, or
lack of code modification required in the monitored application or the client
application. The monitor design is based on the availability of well-defined exit
point interfaces on the monitored application. The monitored application logic
remains unchanged regardless of monitor execution.

If the monitor is dynamically loaded, it will then be executing within the
process space of the monitored application. This is considered to be a benefit
for runtime performance.
It is the monitored application design that determines under what
circumstances the exit point will be invoked. Careful analysis of the monitored
application documentation and runtime behavior is required to determine if all
of the data operations trigger an appropriate invocation of the exit point for
privacy management. Furthermore, the essential context information such as
access purpose needs to be identifiable.
It is not uncommon for exit points to be invoked asynchronously by a
monitored application. If this is the case, policy enforcement is difficult, if not
impossible. Feasibility of real-time enforcement is dependent on the
monitored application invoking exit points synchronously, and on its main logic
processing path.
The technology platform used by the monitored application to define the exit
point interface can sometimes introduce complexity to monitor design and
implementation. Particularly, if the exit point platform does not support Java, it
may be necessary to split or distribute the monitor implementation.
Considering Figure 3-3 on page 68, the Application Interface component may
reside on the monitored application within its process space. The Reference
Monitor component may reside within a WebSphere container in a separate
process space.
3.4 Application Callout Monitor pattern

The Application Callout Monitor pattern describes a style of monitor that is
embedded within a monitored application. The application is typically modified to
callout directly to Tivoli Privacy Manager server via the Reference Monitor. The
generalized design of the Callout Monitor is illustrated in Figure 3-4 on page 71.
J2EE Application
Privacy
Enabled
Data
Abstraction
Existing Existing Privacy

Presentation Business Enabled Storage
Client or Logic Logic Data System
Browser Abstraction
Privacy
Enabled
Data
Abstraction
Application
Monitor Adapter
Tivoli Privacy
Manager
Reference Monitor
Tivoli Privacy
Manager Server
Figure 3-4 Application Callout Monitor design

The Callout Monitor is suited to monitored application environments where
source code changes are permitted. Typically, these applications are
developed in house or on highly customizable vendor applications. The Tivoli
Privacy Manager for e-business Monitor SDK requires a WebSphere client or
server runtime container, so an ideal candidate application is implemented on
the WebSphere J2EE platform also. However, this is not essential.
Another preferred characteristic of the monitored application is a high level of
code abstraction and encapsulation for storage location operations. The
application ideally has an identifiable data access layer that is used by
application business logic. From a privacy monitoring perspective, this type of
data access layer represents the storage system. Therefore, following the
recommendation of placing the monitor as close to the storage system as
possible, this layer will typically be modified to include the callouts to Tivoli
Privacy Manager server.

This type of monitor is also suited to new application development situations.
Many of the complexities associated with privacy context information
gathering can be reduced if the application is designed with privacy
constraints in mind. The privacy callouts can be integrated into the new
application from the start.
򐂰 Architecture
The generalized design of the Callout Monitor is illustrated in Figure 3-4 on
page 71. The application design has been generalized based on standard
software components representing presentation logic, business or functional
logic, and data access logic. The core monitor functionality is provided by the
Reference Monitor and Application Monitor Adapter. It is represented as
separate component within the application. However, additional modifications
to the existing data access logic are required, and are represented as the
dotted lines between the data access components and the Application
Monitor Adapter.
The callouts to the monitor are placed in the data abstraction components
following the recommendations in IBM Tivoli Privacy Manager for e-business
Monitor Developer’s Guide Version 1.1, SC32-4790. The data abstraction
components are the closest to the storage system than other component
within the application. Typically the data abstraction components encapsulate
SQL queries to database tables, or message queue access. Within these
components, it will usually be quite simple to identify the storage locations, by
name, that are involved in a given query or operation.
In some circumstances, the data abstraction components may not be able to
identify privacy context information such as the purpose of a given access, or
the identity of the subject accessing the data. Often, this type of privacy
context information is more readily available within the presentation or the
business logic components. If this is the case, a variation of the pattern may
introduce a Privacy Context object. This object is populated with purpose and
identity information, and then made available to the data abstraction
components. For example, the Privacy Context object might be added as a
method argument. Alternatively, thread-specific storage might be used to
cache the object.
Policy enforcement and Tivoli Privacy Manager server notifications are
performed using callouts within the data access components. If enforcement
is required, the callouts must be performed in the main logic flow of control
and must occur before control leaves the data abstraction component.
򐂰 Trade offs
At face value, the Application Callout Monitor pattern seems quite invasive.
However, many benefits can be derived from this approach. The embedding
of the monitor into the application can gain performance improvements over
other approaches. Enforcement is usually feasible since code modification
can be done, and the monitor is an integrated component of the application.
Context information related to data operations tends to more meaningful than
for other monitor patterns.
The obvious disadvantage of this approach is the need to modify application
code. This disadvantage is reduced for applications that have been well
architected and have a well-defined data abstraction layer. The more data
access logic is dispersed throughout an application, the more complexity will
exist for the monitor implementation.
Other additional factors to consider include the security and transaction
contexts that exist within the application. In some situations, for example, it
may be preferable to have the monitor share the same transaction context as
the core application logic, while in other situations, a separate transaction
boundary might be preferred for the monitor. It may be reasonable to have
privacy access notifications participate in the application transaction context.
This way, the notification can be rolled back or committed within Tivoli Privacy
Manager server based on the application behavior.
3.5 Declarative Monitor pattern

The Declarative Monitor pattern is specific to J2EE application environments.
The idea of this design is to integrate privacy monitoring functionality into the
J2EE platform infrastructure. As with other J2EE enterprise services, such as
security, transactions, and so on, privacy monitoring can be enabled using
deployment descriptors. Privacy monitoring is made available by the Web or EJB
container. A complete example of how to develop and deploy a Declarative
Monitor is described in Chapter 6, “Financial provider using multiple J2EE
applications” on page 175.
Restriction: The current release of the Declarative Monitor is available only

for Web containers. EJB Container monitoring is not currently supported but it
is Tivoli’s stated intention to support them in the near future.
Important: The Declarative Monitor does not ship with the Tivoli Privacy
Manager for e-business installation media. It is available as a Web download
at:
http://www.alphaworks.ibm.com/tech/dpm?Open&ca=daw-flnt-071703
The Declarative Monitor is illustrated in Figure 3-5 on page 74.

WAS Application Server
Web.xml
Descriptor
Web Container
J2EE Service Application

(Security, Privacy Servlets
Transactions, Filter Storage
and JSPs
Resources) System
Client or
Browser
Custom
Tivoli Privacy Plugin
Manager Code
Declarative
Monitors
Privacy
Descriptor
Tivoli Privacy
Manager Server
Figure 3-5 Declarative Monitor

The current Declarative Monitor is available only for Web containers.
Therefore, the monitor is best suited for J2EE applications that have a front
Web component based on servlets or JSPs. The current implementation of
the monitor is based on servlet filters. Web containers compliant with Java
Servlet Specification Version 2.3 or later are an additional requirement.
򐂰 Architecture
As with all declarative J2EE services, deployment descriptors are critical. The
Declarative Monitor is based on deployment descriptor configuration. The
privacy deployment descriptor is composed of a series of definitional and
operational elements described in Table 3-2 on page 75.
Table 3-2 Mapping monitor responsibility to descriptor
Monitor Responsibility Descriptor Element
Monitor name registration <privacyMonitorDefinition>
Storage location name registration <privacyMonitorDefinition>
Application task registration <privacyTaskDefinition>
Detecting accessor identity <privacyIdentitySetupPoint>
Detecting application runtime task <privacyTaskSetupPoint>
Detecting storage location activity <privacStorage ActivitySetupPoint>
Enabling policy enfocement <privacyOperationPoint>
Under the current implementation, multiple monitors can be instantiated and

registered for a given Web application. The Web application archive (WAR) is
deployed with the PrivacyServletContextListener. The PrivacyServletFilter is
associated with each application servlet referenced by privacy deployment
descriptor setup points.
Detection of PII submission and access is the responsibility of the
PrivacyServletFilter. The filter is able to intercept the HTTP request and
response traffic directed to a given servlet. The filter determines if
notifications or conformance checks should be sent to Tivoli Privacy Manager
server based on privacy deployment configuration.
Enforcement is performed by the filter. If a non-conformant access is
detected, the filter is able to modify the response that would have previously
been populated by the servlet. The filter is able to cache the HTML response
of the servlet before actually sending it on the wire.
User-defined plug-in code can be configured in the privacy deployment
descriptor. It is possible to associate a user plug-in for each of the Identity,
Task, and Storage Activity setup points. If configured, the filter will call the
plug-ins to obtain the necessary context information required by Tivoli Privacy
Manager server. Alternatively, static configuration can be used at the setup
points.
Important: User plug-in code is required at the Storage Activity setup

point. The user code must be able to retrieve the master key identifier value
of the data subject whose data is being accessed. Additionally, values for
storage locations referenced by policy conditions (for example Evaluation
Rules) must be retrieved.

򐂰 Trade offs
Monitored applications using the declarative privacy model typically do not
modify their core business logic. Using the declarative model, the privacy
monitor responsibility is pushed into the J2EE container infrastructure and the
declarative privacy filters. Monitoring of a given J2EE application is a
configuration and deployment task.
The design of the Declarative Monitor allows for customization. User plug-in
code can be written and deployed with the monitor when static deployment
descriptor configuration does not allow for complete privacy monitoring.
A potential disadvantage of the declarative approach results from its location
within a typical J2EE application. The current release of the declarative
monitor is implemented using servlet filters within the J2EE Web container.
Applications servlets and JSPs generally are not recommended to access
databases and storage systems directly. Therefore, it may not always be
feasible, or possible to determine, all storage locations accessed behind a
given servlet or URL. Further, it may not always be possible to obtain values
for master keys and context information rules from the Declarative Monitor’s
location within the Web container.
Since privacy monitoring information is externalized through deployment
descriptors, consideration needs to be given to the management of this
information. Particularly, configuration information related to storage locations
can change with new versions of an applications. If data schemas change for
an application, those changes need to be maintained in the deployment
descriptor.
3.6 Business Process Monitor pattern

Another style of privacy monitoring can be done at the business process level.
Here, the idea is to integrate the monitor into a well-defined step of a given
process or workflow.
A key requirement for this type of monitor is the use of workflow automation
software. Examples of such software include WebSphere Business Integrator
and Microsoft Biztalk. Business processes are defined using the software.
The definition should include details about the data flows between
components of the process. This is essential for the monitor.
򐂰 Architecture
The basic idea for this strategy is to integrate the monitor into the workflow.
One idea for integration is to build the monitor into the steps of the workflow.
The monitor would inspect,and report on data as a given step is executed.
Another idea is to integrate the monitor as an extra step(s) of the workflow. As
one core business step is completed, the workflow engine could redirect the
output to a privacy monitor step. The privacy monitor step could filter data out
before the engine is redirected to the next core business step.
򐂰 Trade offs
The existence of a workflow-driven application typically implies well-defined
access points to data. This make the job of identifying where and what to
monitor relatively simple. A further advantage of automated business
workflows for privacy monitoring is the ability to identify purpose. A workflow
itself will typically correlate to purpose for privacy monitoring. Workflow
monitoring is generally less intrusive than other monitoring approaches. The
monitor can potentially reside in its own workflow step, and remain separate
from the core business steps.
The main disadvantage of this type of monitoring is its applicability to
organizations that use automated workflow tools.
3.7 Conclusion
This chapter has given you an overview of different ways to design and
implement a privacy monitor in an existing environment. The next three chapters
take you through specific examples of real-life implementations.

4
Chapter 4. Health care provider using a

WebSphere application
The costs of health care systems are exploding all over the world, and in many
countries the government feels they need to make significant changes to their
system to regain control over the costs of the health system.
In our fictional scenario the government is asking the national Agency for Health
Control (AHC) how they could help analyze the costs and benefits of the current
system and propose alternatives for changing the system, and also for help in
planning for more Web-based interaction between the insured citizens and the
AHC to offer more and better choices for the insureds.
In the future, the government wants to change the Agency for Health Control
more into a Health Management Organization (HMO).
The government assumes this could help increase the quality of the health
service across the nation, but also it would help to reduce the cost of the health
system while being more flexible in providing extended services to the people (for
which the insureds will have to pay extra).
Having multiple parties working with health-related information in a competitive

environment strongly increases the risk that certain data is exploited by
unauthorized people. This could be a big drawback, because the government

wants to be competitive with lthe atest data protection laws such as the
European Directive for Data Protection1.
4.1 Current architecture (and AHC-internal procedures)

The Agency for Health Control has approximately 20 million insureds and settles
basically all payments of its clients all over the country. It receives treatment
records from every appointment a patient schedules with any practitioner and
hospital. Treatment records include patients’ administrative data, reason for the
treatment, diagnosis and practitioners identities.
AHC’s insureds who are electronically managed in a large database with all
national health records. Today they cannot take much advantage of it, for
example, they cannot analyze current situations because health data is
considered to be very private and sensitive. This data belongs to the insured
people and the practitioners who are considered the data owners. To make more
use of this data AHC needs explicit consent from the data owner in order to
analyze health data.
Analyzing health data can help improve the quality of the health system across
the country in general, but also to improve the quality of individual health
treatment by offering choices and bonus programs to the patients while collecting
information from them.
In the future, the government wants to transform the Agency for Health Control
into a Health Management Organization (HMO), interacting with insureds directly
to manage their health instead of paying their bills only.
However, the government wants AHC to continue being a leader in implementing

the recently released national privacy legislation, which is based on international
OECD guidelines2 and is closely related to the European Directive for Data
protection. Compare 1.2, “Privacy governance” on page 5.
4.1.1 Data entry into the health system

A patient has two options to settle payment for a practitioner’s treatment:
1. They can pay cash at the doctor’s office and then claim the expenses by
either going to a local branch office of AHC or mailing the receipts to the local
office to be reimbursed.
1
Briefing Materials on the European Union Directive on Data Protection can be found at the Center
for Democracy & Technology (CDT) Web site: http://www.cdt.org/privacy/eudirective/
2 The OECD guidelines can be found at: http://www.oecd.org
All personal and medical data is entered manually into the national data
system by branch office staff.
– Generally this procedure means a lot of data handling and manual
interaction.
– It therefore requires much control.
– Manually entered data is never free of errors and cannot be trusted as
much as direct input by a data owner.
– Having third parties filing consent to use certain data on behalf of the data
owner can become risky and can be considered a liability issue.
– Exposing sensitive data to third parties is also a data protection issue.
Therefore minimum data handling is a key objective for AHC. Automatic data
handling can make it much easier to match the legal requirements for data
protection and also provides a way to include good audit capabilities.
2. The patient can ask the practitioner for direct reimbursement by AHC, but this
increases the overhead costs for the practitioner. Some practitioners also feel
uncomfortable with this solution, because it gives AHC more details on their
internal operations.
A practitioner might be more willing to accept a centralized health data system
if he can receive some benefits such as the following:
– Use the AHC application to directly enter patients’ personal and medical
data.
– File an approval or consent from the data owner that certain data can be
used by others according to approved policies.
– Use the data repository for research on emergency records or other
health-related information.
– Charge AHC for data entry, which is not unreasonable:
• Given the actual costs AHC spends in order to gather and enter data in
the branch offices all over the country.
• Improving the quality and trustworthiness of data for AHC.
• Reflecting explicit data owner consent for data usage.
AHC has to comply with the latest data protection act passed one year ago. This
act requires strict control over who can see personal data and a clear statement
of the purpose the given data is used for.
Chapter 4. Health care provider using a WebSphere application 81

4.1.2 Status and shortfall for AHC, patients, and practitioners
Let us take a look at several reasons to improve the established processes for
the different groups involved.
AHC (anonymization of health records /de-identified data)

Anonymization of data is a very typical problem in the health industry. AHC faces
the following particular challenge:
򐂰 Today AHC cannot explicitly prove the consent from a data owner for data
usage. Therefore it has to de-identify records by removing all personal data
before they can use medical records for further analysis.
򐂰 De-identified data is almost worthless in improving treatment and health care.
It can be used for basic statistical purposes only.
򐂰 Data has a certain lifetime of value. If de-identified data does not reflect the
latest medical records, any database query might provide unreasonable
results when applying statistical methods.
򐂰 Organizational units need to test their new applications but often do not have
qualified data. It would be very beneficial if they could use live data — but this
is not allowed by data protection laws. To make the best use of existing live
data, they want the data to be as close as possible to protected patient data.
Substituting certain data fields and inserting typical demographic data such
as sex, age, or area code just before processing the data for analysis would
be very helpful.
Practitioner’s view
The practitioners are more concerned with individual patient records and how
they can improve diagnosis and treatment plans.
򐂰 Treatments from two independent practitioners are not listed within a single
patient health history.
򐂰 The patient needs to hand carry other practitioners’ diagnoses to his
preferred general practitioner if he does not want to take a chance of
important data running late in the mail.
򐂰 Information shared between practitioners and hospitals is not entered into the
single treatment plan but stays on a separate paper and in separate data
sets.
򐂰 The practitioner does not have a complete and conclusive health history of
the patient sitting in front of him.
Patient’s view
The patient is mostly concerned with his private health care record.
򐂰 He does not have a complete and conclusive overview of his health history
and his treatment plan.
򐂰 He has no capability to update, print, or store his health history electronically.
򐂰 Some data is often needed to answer questions from insurance companies
and so on.
򐂰 If the patient’s data is stored at a doctor’s office, it becomes useless if the
patient moves to another area.
򐂰 The patient does not have the chance for a conclusive discussion with other
experts to settle his mind.
򐂰 It is hard to estimate if a disease was cured fast and effectively.
򐂰 Patients participating in donor programs (blood, organs, and so on) cannot
store data or explicit consent electronically on a centralized database.
򐂰 Very rarely does a patient still have access to his childhood history:
– It is very difficult to reconstruct a child’s health history.
– Data is basically lost.
– For parents, it is often very beneficial to know their own health problems in
their youth.
– Parents are typically not available to answer these questions when
information is needed.
Emergency view
AHC has become aware of a strong increase in the fatality rate within the
emergency system. That high rate is supported by missing online health
information urgently needed in any emergency situation.
4.2 Project layout and implementation

AHC is under strong pressure for a fast change in the actual implementation;
otherwise it cannot meet its business plan and its commitment to management.
The company needs to extend the current system and include new business
models in order to prepare for the next-generation health management approach.
AHC has realized that a home-grown solution that includes security and privacy
functionality exceeds its capability by far, because it would exhaust all available
IT resources and therefore lead to tremendous maintenance costs over the long
term. A home-grown solution would not be flexible enough to allow easy changes
of the applications after being released because security and privacy functions
are hardcoded into every single application. This approach also requires
recoding every time a privacy policy needs to be updated.

Therefore management has decided to use IBM Tivoli Privacy Manager for
e-business for data protection and to create audit records needed for compliance
checks. AHC is planning a four-phase rollout that will take advantage of the
experience gathered within the previous project steps.
4.2.1 Project plan

Let us take a closer look at each of the four project phases:
򐂰 Phase 1 includes running a basic pilot to gather some experience. The basic
objective is to define and implement privacy policies and privacy rules and
generate a common understanding of protected data for the various
scenarios. Since the first phase includes collaborative work with selected
practitioners, their feedback will be most valuable.
򐂰 Phase 2 will extend data usage to the emergency services.
򐂰 Phase 3 will connect all general practitioners in hospitals and run the first pilot
information system for patients.
򐂰 Phase 4 is the final rollout to extend the new system into the doctors’ offices.
Because of several reports on TV about a strong increase in the fatality rate in

several emergency cases because of missing online health information, AHC has
not only included the emergency system in the implementation plan but given it a
strong focus for fast implementation.
The emergency system could also be used for application testing, because it is a
closed environment and nicely controlled compared to the many thousands of
individual practitioners across the country.
4.3 Companies business vision and objectives

The national health system has struggled with rising costs for years. Therefore
the government has strictly requested AHC to change and adjust the current
health care system to regain control of costs.Simultaneously, it wantw AHC to
improve the quality of the current health service to be internationally competitive
with other health systems. The government wants to transform the Agency for
Health Control into a Health Management Organization (HMO), actively
interacting with insureds to manage their own health instead of only paying the
bills.
AHC has answered this challenge with three statements on how it wants to
regain control of the health system.
1. Improve health treatment by sharing the latest and most accurate health
records with practitioners, hospitals, and emergency services.
2. Have available consolidated information on the health status of the
population.
3. Apply statistical methods to understand the average costs of treatments.
4.4 Business requirements

The announced program will result in modifications to the current business
procedures and models, but will also let the health provider create new business
models (as other HMOs are already doing). Another impact is expected on
existing insurance contracts, which AHC might want to modify according to the
latest regulations (such as a new Medicare law).
AHC also understands that it needs to reduce manual data handling in the
branch offices rather than have the practitioners doing this, so they can achieve
the following targets:
򐂰 Reduce costs of data handling and operation.
򐂰 Increase data quality.
򐂰 Ask the patient and practitioner for consent to use certain data to analyze.
򐂰 Comply with the data protection law by minimizing data handling.
Changes will also result in stronger guidance for use by patients, practitioners
and AHC.
򐂰 Patients are asked for stronger participation and interaction to make certain
choices.
򐂰 Patients are asked to articulate preferences, indicate participation in health
prevention programs or to provide certain health-related information.
򐂰 Abiding with legal regulations, providers offer their patients certain options
and controls if they want to participate in bonus programs.
򐂰 Choices can have impact on the quality of service and on the costs of
premiums.
򐂰 Patients can change preferences and contracts more frequently and easily.
They can compare benefits they get from AHC and information they need to
provide to AHC, so they can finally select the offer that best fits their personal
situation.
򐂰 The new insurance contracts contain a section where patients are asked to
explicitly agree to AHC’s analytical methods that optimize services and costs.
These contracts have to describe how health data will be used according to
the signed contract. Thereafter, AHC assumes implicit consent as long as the
contract is in place.

򐂰 Health-related data will always be considered very private and sensitive, and
therefore all applications need to incorporate the latest legislation and
regulation.
From an ITpoint of view, this requires continuous modifications to health

applications, which very often means re-coding of the application because
privacy protection rules are typically hardcoded in each health application.
Therefore an implementation of a new business model becomes very costly. For
every modified application, you need to ensure that the user has only the
approved view on each data field he is allowed to see (according to the current
contract and the related business policy the patient has agreed to).
AHC management has agreed to use a centralized information access control

system for all available data containers with a fine-grained access control
mechanism in place for any data field a single user wants to access for a
particular reason. The system has to provide the following capabilities:
򐂰 The language that describes privacy policies and business rules must comply
with the following requirements:
– It should be based on international standards.
– It should be easy to read and understand.
– It has to match business logic with state of the art IT capabilities.
– It must reflect assumptions, business rules and the access purpose.
򐂰 It has to allow the Supervising National Board to check compliance of policy
with approved national rules and regulation for health services for any single
contract offered.
򐂰 It must provide a sufficient monitoring capability and check the access control
enforcement. A monitor must be enabled to record every action an AHC
analyst is attempting to execute while he works with personal and medical
data he is entitled to see.
About policy and consent lifetime in a health record:
򐂰 It is the patients’ personal choice to choose a specific health provider and
contract. The health provider has to inform the patient about his policies
and how he will use PII data. The patient always has the choice to change
his contract for which a certain policy applies.
򐂰 From an IT point of view, changing a contract must be immediately
conveyed into the access control procedures for personal and
health-related data so that internal analysts can only see records with
proper access enforcement.
򐂰 Be aware that the explicit consent a patient has given under an old policy
will stick to this data. This policy decides how this old data can be used. For
example, changes only have impact on new data collected under the new
consented policy, whereas the internal analyst still can see the old data of
the patient records he was already entitled to see before.
4.5 Functional requirements

In the following section we describe some very basic roles, tasks, and functions.
Because of the limitations of this book and the complexity of a real
implementation in any given health system, we do not want to be more specific.
We have kept the examples as simple as possible. Rules are intended to provide
the reader with basic ideas about how he could match and adjust his own
examples within our environment.
4.5.1 Description of participants and their objectives

The individuals and acting groups we have created reflect the users interacting
with a centralized Health Data System:
򐂰 The insured
– Patient
– Dependent
򐂰 The practitioners
– Your preferred general practitioner (PGP)
– Other general practitioner
򐂰 The internal health insurance analysts
– Service quality analyst
– Health researcher

򐂰 Independent researchers
– Independent health researcher (blood research)
– Independent health provider (donor program)
򐂰 Emergency
– Hospital
– Doctor
– Nurse
How to extend role and policies to fit a real-life scenario

In order to map our approach into a real-life scenario, you want to consider the
following:
򐂰 The patient should always have full access to his medical records.
Technical restrictions should apply in strength of authentication needed (see
the security discussion in 4.5.2, “Reduce the risk of exposing personal data”
on page 91).
򐂰 A dependent is a boy or a girl between the ages of 16 and 18, almost grown
up but still under legal control of his or her parents. Because of this, they do
not have personalized access to their health records, but their parents are
entitled to check on their behalf. Parents can see most of the health-related
treatments of their children, but certain discretion should apply for very private
details that the children might not want known by their parents, such as
seeing a doctor for birth control-related questions or taking a blood test for
STD (sexually transmitted diseases).
– Dependents need to give explicit consent if they want their parents to see
these treatments on the list.
– To protect consent overwrite from parents when checking the data via the
Internet, the doctor also has to give explicit consent to avoid look-ups from
nosy parents.
In real life, it becomes much more complicated to include a dependent
scenario. This requires strong guidance from the government, health service
providers, and lawyers to resolve.
򐂰 The preferred general practitioner can see most of his patients’ treatments,
including some other treatments the patient has undertaken at another
general practitioner’s for any given reason.
򐂰 The other general practitioner can see all services he provided himself (or
his practice) to this single patient.
– If the patient does not want his preferred general practitioner to see
treatments he has undergone at another general practitioner, he does not
consent when this general practitioner submits this treatment record to the
health service.
– If the patient has undergone a specific treatment and both parties do not
consent, neither the patient nor the general practitioner nor another
practitioner can see details of this treatment (this would also apply for
diseases under regulation or legal control).
Consent: Explicit consent per health record from either or both patient
and practitioner could be used to share some information between
practitioners.
For specialized practitioners such as eye doctors and so on, it would be

very helpful to have more reliable data about the patients’ history, so
they could develop a more individual treatment plan or could adjust their
prescription to better reflect sophisticated medicine avoiding
contra-indication.
It can also be used for other reasons, such as a patient wants to see
another practitioner for a second opinion. Approval of the PGP could be
indicated by a given consent.
This would keep some patients away from doctor-shopping, because

with no explicit approval from their PGP, they might have to pay a fixed
contribution for shopping around.
– Health records having no data owner consent attached must be

de-identified completely before the medical data can be used for further
analysis.
– Health records that include STD statements can only been viewed by a
strictly monitored group of people who are qualified for this special privacy
rule.
򐂰 The emergency team can always see the full health record, because it might
be essential to rescue a patient’s life.
– From a security point of view, providing all available patient data to a single
emergency screen is most likely the biggest data protection risk within the
whole system.
– To reduce this risk, the project needs to implement certain controls and
strictly enforce access control (refer to 4.5.2, “Reduce the risk of exposing
personal data” on page 91).
– Providing all health-related data to the emergency team is not a risk, but
the fact that it is so easy to request any patient’s record needs appropriate
protection.

򐂰 A health service analyst or internal health researcher of AHC is a person in
charge of ensuring the quality of health services across the country by
performing the following tasks:
– Checking effectiveness of treatment for certain diseases.
– Comparing average costs per diagnosis within a certain area or across the
country.
– Monitoring the speed of propagation of certain diseases.
– Ensuring sufficient supply of doctors within an certain area.
– Supporting practitioners with vocational training to apply latest technology.
򐂰 An independent blood researcher is a person who is interested in your
medical data for the sake of research.
– He represents an organization (such as the Blood Donation Association)
the patient has personally subscribed to or is actively participating in.
De-identified data is used for general research purposes.
– A dedicated blood donor might want to sign up for a certain program
where the association sends out e-mail to all patients who have a rare
blood group (such as “0”-extra strong). The patient might therefore wants
the association to see his blood group, and his e-mail address but not his
name and residential address.
Becoming an HMO
If AHC transitions to become a Health Management Organization, it might want
to use the data in a much more sophisticated and advanced way. HMOs tend to
contract with a set of doctors to which their clients (patients) must go. They have
agreements in place with the practitioners to monitor the average costs per
disease and treatment.
The AHC analysts become responsible for finding the most qualified doctors with
the highest efficiency for certain treatments on specific diseases. The
researchers’ responsibilities include supervising patients actively participating in
certain prevention programs or motivating them to undergo regular health
checkups to lower risks.
As an HMO, AHC can give rewards to patients for participating in these programs
and for giving consent to share treatment data, so the researchers and analysts
can see this data in the system and be more effective.
Be aware that it is the patients’ choice to sign up for a certain health provider and
not the technology provider’s. The HMO needs to communicate its policies to
monitor a set of data and to prove via audit lists that it abides with its policies and
signed contracts.
Finally, let us consider a few patient choices:
򐂰 The insured must have the free choice to opt-in or opt-out from certain
services at any time by simply changing their contract.
򐂰 Data access for an AHC analyst must immediately be altered if a patient
changes certain opt choices.
򐂰 Be aware that if a policy is changed, the consent a patient has given under an
old policy sticks to this data. Changes only affect new data collected under the
new consented policy, that is, an analyst can see your old data forever.
4.5.2 Reduce the risk of exposing personal data

How can we enforce the legal use of our health applications? Our simple
scenario might look like it is very easy to cheat, but in a real-world scenario you
need to make certain security adjustments to protect your data accordingly (also
see 4.5.7, “Risk assessment” on page 103). We are basically facing three major
risks:
򐂰 Proper use of applications, especially when participating in multiple roles
(doctor, researcher).
򐂰 Proper identification of participants (especially of the patient).
򐂰 Avoid misuse of data in an emergency room or at a doctor's office.
Proper use of applications

We must ensure that specific applications can only be invoked by users who
authenticate within the appropriate role. A doctor can also be a certified
researcher, and the applications have to make that distinction when presenting
data accordingly. When authenticated as a researcher, he should only be able to
access anonymized data instead of the complete patient records that he could
work with as a doctor.
Proper identification of participants

A patient should have unlimited access to his own data. Doctors, general
practitioners or emergency personnel should be able to see all records for their
patients. However, the system provider has to ensure that the user requesting the
data is in fact the person he says he is.
Because health-related data is very sensitive, the security architecture needs to

include authentication strength and sensitivity as parameters for Web
applications and not only as a technology.
SmartCards with a valid certificate can be considered the strongest

authentication mechanism to give patients access to all available data regarding

himself. However, most patients won’t have an expensive token such as a
SmartCard. Typically, patients use user ID and password in order to authenticate.
The strength of this authentication method might be justified for showing more
than just organizational data, such as date of appointment and doctor’s name.
Since the information request comes from the patient himself, the application
does not need to return the patient’s personal data because the user should
know about this anyhow.
If the patient submits a more advanced data request, such as asking for the
reason for treatment or for the diagnosis, we suggest a two-factor authentication.
This could mean providing a second password (one-time password) from the
provider, which could be a list with transaction numbers that is sent to his
registered e-mail or his residential address, or it could come via SMS to his
registered mobile phone as a single-use password. If the patient can provide
both secrets, user ID/password and one-time password, all related data is
displayed in the application.
Locations such as doctor offices, hospitals, and emergency centers should be

required to provide a means of strong authentication in the first place. Strong
authentication might be negligible for roles such as researchers and analysts, as
long as the applications only provide anonymized data.
This discussion shows that the type of authentication cannot be tied to the
person alone, but also to the type of application. Depending on the application
that somebody wants to execute, we might want to provide mechanisms of
step-up authentication to enforce a stronger authentication for the particular data
provided by the application.
Emergency
In addition to strong authentication mechanisms, access to the emergency
application should be limited to specific IP addresses for designated workstations
at hospitals and other emergency rooms, since a successful login means
unlimited access to data within the national health system.
Emergency applications can also use a way of anonymization. After determining

the patient ID, by consulting his insurance card or using a search screen with his
name and other personal information, all health record results that are displayed
do not further reveal personal information. This way, the emergency personnel
can see all relevant data on the screen, but someone who cannot draw the
conclusion between the data and the patient ID only sees a list of de-identified
data.
The security aspects of this solution include both access control (security) and
data protection (privacy) points of view. Access threats can be minimized using
proper access control tools such as Tivoli Access Manager, and data protection
can be enforced using Tivoli Privacy Manager.
Tivoli Access Manager controls access on an IP address level and also supports
multiple authentication methods such as user ID/password, certificate, and other
tokens, as well as two-factor authentication. Based on the data access purpose
and the authenticated user’s credentials, Tivoli Privacy Manager can filter the
data presentation according to the business policy and de-identify the results.
Privacy Manager also logs every data access if required. Table 4-1 shows a
typical emergency data display with all patient information necessary for the
medical personnel without showing any identifying personal data except patient
ID. If required, even this ID can be faded out.
Table 4-1 Typical health record emergency room display

Patient Reason Category Provider Blood Patient Provider Date
ID ID Grp consent consent
0133 STD Bloodtest ZZ A-R+ NC NC 06/23/03
0133 Inspection Checkup XX N/A YES YES 08/15/03
0133 Diabetes Prescription WW N/A YES YES 09/03/03
4.5.3 AHC Privacy Manager policy groups

Policy groups define the individuals, groups of individuals, or applications that
can access specific PII data. At least one group must be defined to create a valid
privacy policy usage statement. Five groups have been defined for the AHC
privacy policy:
򐂰 Patients and dependents
򐂰 General practitioner/practice group
򐂰 Analyst and researcher (AHC internal)
򐂰 Independent researcher
򐂰 Emergency personnel
When a group is defined in the Tivoli Privacy Manager console, it must be

categorized in one of five recipient categories that reflect the data-usage
practices of the organization allowed to access the PII. These categories are
defined in the P3P specification and used for P3P export. The AHC Privacy
Manager groups were categorized within the organization or person associated
with the organization recipient category. The resulting groups are depicted in

Figure 4-1 Tivoli Privacy Manager group definition and description
4.5.4 AHC identification mapping

The mapping of the Tivoli Privacy Manager groups to the access attributes of
their associated Tivoli Access Manager groups and authorization IDs is as
follows:
򐂰 Patient and dependent group
The patient and dependent group represents clients (or dependents) who
have been treated within the health service system as Patients.
The Tivoli Access Manager group name is am_ahc_patients_group.
򐂰 General practitioner/practice group
The general practitioner/practice group represents health service providers,
identified as Doctors.
The Tivoli Access Manager group name is am_ahc_doctors_group.
򐂰 Analyst and researcher (internal) groups
The analyst and researcher (internal) group represents health service
provider employees, identified as AhcAnalystResearchers.
The Tivoli Access Manager group name is am_ahc_research_group.
򐂰 Independent researcher group
The independent researcher group represents an independent researcher
called IndependentResearcher.
The Tivoli Access Manager group name is am_ahc_indresearch_group.
򐂰 Emergency group
The emergency group represents health services providers called
EmergencyProviders.
The Tivoli Access Manager group name is am_ahc_emergency_group.
Figure 4-2 Tivoli Privacy Manager group mapping
After defining Tivoli Privacy Manager for e-business groups and their
participants, we have to match Privacy Manager IDs to Access Manager IDs.
This is required in order to call out from Privacy Manager to Access Manager
when requesting a group membership evaluation of people accessing the
system. The actual group membership information is maintained in the LDAP
directory by Tivoli Access Manager. The corresponding group mapping table
(depicted in Figure 4-2) as well as the user mapping table (shown in Figure 4-3
on page 96) is maintained within Tivoli Privacy Manager.

Figure 4-3 Tivoli Privacy Manager user mapping
When a provider logs on to the system, he needs to select the application he

wants to run in the purpose selector shown in Figure 4-4. By doing this the
provider implicitly selects his role and from that point onwards, Tivoli Privacy
Manager for e-business enforces access control and privacy rules according to
that role.
Figure 4-4 Selecting applications indicating the use of a certain role
In our example we use a patient enquiry application that allows doctors to query
details about patients. Since some of this data is highly sensitive, it is protected
according to our privacy rules. These rules may result in different access rights
according to the role the doctor has logged in as. For example, if the doctor logs
in as a researcher, he may not see as much details as he would if he had logged
in as an emergency ward worker.
Let us take a closer look at the different actors involved in our application
example.
4.5.5 The actors in the Tivoli Privacy Manager groups

Table 4-2 shows the participants defined to our system.
Table 4-2 Health provider (practitioners acting in our example)

Provider ID Name Suburb / City Zip code
County
YY Dr. Otto Travis Austin 75758
ZZ Dr. David Burnet Burnet 78521
UU Dr. Axel Laredo Alamo 79588
WW Dr. Martin Casino Atlantic City 82003
XX Dr. HaiFun RTP Raleigh 72003
򐂰 Dr. David is a member of three Tivoli Privacy Manager groups:

– General practitioner
– Emergency worker
– Independent blood researcher
򐂰 Dr. Otto is a member of three Tivoli Privacy Manager groups:
– AHC internal researcher
򐂰 Dr. HaiFun is a member of two Tivoli Privacy Manager groups:
򐂰 Dr. Martin is a member of two Tivoli Privacy Manager groups:
򐂰 Dr. Axel is a member of one Tivoli Privacy Manager group:

򐂰 Herb (Herbert) is a member in the Tivoli Privacy Manager patient group acting
on behalf of his minor dependents.
4.5.6 AHC privacy policy usage statements

In this section we define some of our AHC’s privacy policy usage statements and
show some examples of how they are used in the real world.
򐂰 Patienta may access all organizational information for the purpose of
Status_reports if they are the data owners and if they are authenticated by
user ID and password only.
򐂰 Patients may access all medical information for the purpose of Status_reports
if they are the data owners and if they are authenticated using the method for
strong authentication.
򐂰 Patients may access all medical and identity information for the purpose of
Status_reports if they are the data owners and if they use two-factor
authentication.
򐂰 PatientParents may access all organizational information of their dependents
for the purpose of Status_reports if they are listed as the ParentalGuardians
of the child, and if the child’s treatment was not BirthControlRelated, and if
the treatment was not STD_related, and if they have been authenticated by
user ID and password only, and if the child has consented to release the
record, and the practitioner has consented to release the record.
򐂰 PatientParents may access all medical information of their dependants for the
purpose of Status_reports if they are listed as the ParentalGuardians of the
child, and if the child’s treatment was not BirthControlRelated, and if the
treatment was not STD_related, and if they are authenticated using the
method for strong authentication, and if the child has consented to release
the record and the practitioner has consented to release the record.
򐂰 PreferredGeneralPractitioners may access all medical and identity
information for the purpose of Medical_Treatment if they are the nominated
preferred general practitioners, and if the patient has consented.
򐂰 GeneralPractitioners may access all medical and identity information for the
purpose of Medical_Treatment if they are the service providers and the
patient has consented and the other practitioners have consented.
򐂰 GeneralPractitioners and Nurses may access patient IDs for the purpose of
Medical_Treatment (for example LookUp Database to find Patient_ID
matching name).
򐂰 GeneralPractitioners and Nurses may access all medical data if the purpose
of the treatment is Emergency_treatment and if they are authenticated using
the method for strong authentication.
򐂰 GeneralPractitioners and Nurses may access all medical and identity
information for the purpose of Emergency_treatment if they are using a
workstation with a fixed, authenticated IP_address.
򐂰 AHC-Analysts may access medical and identity information for the purpose of
Bonus_calculation if the patient has consented, and the category for the
treatment was CheckUp.
򐂰 AHC-Researchers may access all medical information and patients’ sex, age
and area code for the purpose of Improve_Treatment if the patient has
consented, and the patient’s GeneralPractitioner has consented, and the
purpose of treatment was not STD_related.
򐂰 Independent Researchers may access all medical information for the purpose
of Medical_Research if the patient is from the same area code as the
practitioner, and the age of the patient is over 21, and the treatment was
STD_related.
򐂰 Independent Researchers may access all blood data for the purpose of
Blood_Level_Supply_E-mail if the patient has consented, and the purpose of
the treatment was not STD_related.
򐂰 Independent Researchers may access all medical information for the purpose
of Medical_Research if the blood researcher is from the same area code as
the patient, and the patient has consented, and the patient’s
GeneralPractitioner has consented, and the treatment was Blood_Test, and
the purpose of the treatment was not STD_related.
Examples
In our examples we show four use cases of our privacy policy usage statements
above. Table 4-3 lists our example patient data with the matching patient name
and ID.
Table 4-3 Patient records

Patient Patient City Street Birthday Parent e-mail Health
ID name plan
03 Heidi Austin Burnet 07/10/85 Herb heidi@heidi.com public
02 Mary Austin MoPac 05/10/87 Herb mary@mary.com public
01 Bob Houston Apollo 08/03/49 n/a bob@bob.com HMO
00 Tony Dallas Apollo 11/10/54 n/a tony@tony.com HMO
04 Kelly Miami Beach 06/09/68 n/a kelly@kelly.com HMO
1. In the first example, parents can see their children’s health records if the
children have not opted out or the consultation was not related to birth control

or to an STD-treatment. The status report as seen by Heidi’s and Mary’s
parental guardians is displayed in Figure 4-5.
Figure 4-5 Status Report seen by the parental guardians of Heidi and Mary
Looking at the reports of a preferred general practitioner, we see a significant

difference in the listing of the dependent Heidi with patient ID 03 (see
Figure 4-6 on page 101). Dr. HaiFun can see only the records with both
patient and provider consent besides his own records with provider ID XX. If a
patient has visited another specialist who did not give his consent, Dr. HaiFun
is not able to see that record.
The complete overview of all patient data in our example can only be obtained
by looking into the emergency record.
Figure 4-6 Records for PGP Dr. HaiFun
2. Your preferred general practitioner can see a medical treatment in his medical
records if a patient has undergone another treatment, for example as a
second qualified opinion, executed by another practitioner, if the patient and
the other practitioner have consented to show the record. Take a look at
Figure 4-7 on page 102 for an overview of Dr. Dave’s patient and medical
records showing treatment from Dr. Otto for Tony.

Figure 4-7 Records for PGP Dr. Dave
3. A health checkup can be seen from an AHC Analyst if the health plan
currently in place between patient and AHC does allow them to monitor
appropriate participations of the patient in the program so they can approve a
bonus without manually checking any bonus certificates the doctor might
have to sign and the patient has to mail in to AHC.
4. An independent researcher from a non-profit blood donor organization can
make the system send e-mail to all subscribed blood donors of a special
blood type if the emergency system is very low on supplies of blood group
0-extragood, without knowing the name or any other details from the
subscribed donors. An example list of people who have consented to be
selected and the reason for treatment was not excluded by a legal issue (such
as STD-related) is shown in Figure 4-8 on page 103. The researcher himself
does not see any patient details but only selects individual records. The
e-mails are sent by the application anonymously.
Figure 4-8 List of blood research records
4.5.7 Risk assessment

In this section we briefly analyze some of the threats and weaknesses of the
system and give some recommendations for mitigation.
򐂰 Possible security threats are:
– Unauthorized access by an external attacker
– Misuse by users or administrators from an internal network
򐂰 Possible security weaknesses are:
– Insecure systems or applications
– Application failures
– Lost or stolen passwords
򐂰 Possible privacy threats are:
– Application failures
– Configuration failures defining policies
򐂰 Possible privacy weaknesses are:
– Use other’s identity or role
– Misuse of applications (such as emergency application) to retrieve more
data
– Data might not be protected properly due to incomplete rule sets

Initial security risk assessment
The following things can happen due to the listed threats and weaknesses:
򐂰 Damage or manipulation of data in user or policy repositories
򐂰 Manipulation of configuration information in critical systems or applications
򐂰 Misuse of systems or applications
򐂰 Writing false data to the target database intentionally or by accident
Security recommendations
To protect the critical data in our repositories, personalized strong authentication
methods such as SmartCards with certificates or biometrics should be used as
tokens to authenticate authorized participants properly.
To prevent data being collected within a company by unauthorized people,

printing of data has to be restricted to certain controlled points (no print-outs)
with physical access control, and attachments sent out with e-mail should be
restricted or at least monitored.
Other security architecture considerations include but are not limited to the
following list of tasks:
򐂰 Improve network 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 with authentication and authorization capabilities for
access control to administration interfaces.
򐂰 Place critical service and support servers in separate networks and block
access using routers or firewalls.
򐂰 Improve system security to control activity on systems.
򐂰 Remove unneeded components.
A more complete discussion on these topics can be found in the IBM Redbook
Enterprise Security Architecture with IBM Tivoli Solutions, SG24-6014.
4.6 Technical implementation

This section describes the solution architecture and the implementation of the
monitor. An overview of the application design is presented. The focus of the
chapter is the integration of the Tivoli Privacy Manager for e-business Reference
Monitor into the application. The section follows the general analysis and design
considerations required when developing a new monitor.
4.6.1 Solution architecture

AHC has selected to develop the new application system on the IBM WebSphere
Application Server J2EE platform. A Web-based application will be developed to
enable the sharing of medical information with each of the actors in the AHC
business. The implementation architecture overview is illustrated in Figure 4-9.
Access Manager
Access Manager User Registry
(LDAP)
Access
Online Manager
External
iv_user Health JRTE
WebSEAL
Application
Application
Privacy
Privacy
Manager
Montor
WebSphere WebSphere
Privacy Manager
Application
Policy +
Database
Configuration
Internet
DMZ Internal Production Network
Figure 4-9 Application architecture overview
Since access to the source code is available, the privacy solution design will
employ an embedded Application Callout Monitor.

4.6.2 Monitor design
This section describes the design of the Application Callout Monitor. The
discussion focuses on the main design considerations required for privacy
monitors.
Monitored application software design

The application design with the embedded monitor is illustrated in Figure 4-10.
PrivateMedicalDAO
Command Factory (Wrapper)
Privacy
Controller Enforcement
Servlet Value and Access MedicalDAOImpl
Objects
Business
Logic
PrivatePatientDAO
BusinessCommand (Wrapper)
(Emergency,
Client or Research ... ) Value Privacy
Browser Objects Enforcement
PatientDAOImpl
and Access
VIEW Storage
(Emergency, System
Research ...)
Thread
Context
MonitorSessionEJB
PatientDAOImpl
AHC
Monitor
Assistant
Tivoli Privacy MedicalDAOImpl
Manager
Reference Monitor
WebSphere Application Server
Figure 4-10 Monitored application software design
The Web application conforms to the standard J2EE application patterns. The
application is structured along well-defined areas of responsibility related to
presentation layer, business layer, and data access layer.
The main page of the application allows a user to log in and search for multiple or
individual records related to the patient’s identity and medical history details. For
our example, a combo list allows the user to specify a business purpose.
Purpose identification is discussed further in the following sections.
A controller servlet receives all URL requests. The servlet employs the command
strategy as a link to the business logic. Command objects implement a Java
interface, and are created by the controller using a factory. Concrete instances
are created based on the purpose encoded into the requested URL.
This existence of a well-defined data access layer is significant for the integration
of the callout monitor. This layer is closest to the storage system, and is the
primary location for the monitor callouts. In our example, the data access layer is
represented by the MedicalDAOImpl and PatientDAOImpl objects.
Reference monitor integration

The Tivoli Privacy Manager for e-business Reference Monitor is used as the
foundation of the monitor design. For this implementation, it has been decided to
embed the Reference Monitor within its own stateless session bean. The session
bean interface exposes methods for PII access, submission, and real-time
conformance checks. The bean interface is shown Example 4-1.
Example 4-1 Reference monitor session bean remote interface

/**
* Remote interface for Enterprise Bean: TPMMonitorBean
*
* This bean is a wrapper for the TPM Reference Monitor
* API. The wrapper allows for J2EE container services
* to managed specifically for the reference monitor.
*
* Additional benefit can be derived through potential
* reuse of the bean for non java language environments,
* and monitor distribution.
*/
public interface TPMMonitorBean extends javax.ejb.EJBObject {
/**
* Wrapper method of ReferenceMonitor.monitoredItemConsent.
*
* @see ReferenceMonitor#monitoredItemConsent
*/
public void monitoredItemConsent(String masterKeyValue,
ArrayList monitoredItemNames,
int consentOperation)
throws ReferenceMonitorApplicationException,
ReferenceMonitorRemoteException,
MonitorAssistantException,
java.rmi.RemoteException;
/**
*

*/
public void monitoredItemAccess(String masterKeyValue,
int accessOperation,
String userid,
String assertedUserid,
String applTask,
ConformanceCheckResults confResults)
throws
ReferenceMonitorApplicationException,
/**
*
*/
public ConformanceCheckResults monitoredItemConformanceCheck (
String masterKeyValue,
String userid,
String applTask)
throws
}
The primary reason for the session bean wrapper is to allow for the declarative
management of J2EE XA transaction context. In some situations it may not be
desirable to include the Reference Monitor in the same transaction context as the
monitored application. Specifically, ReferenceMonitor.init() typically needs to
execute outside the transaction context of a monitored application. The
deployment descriptor marks the init method with TransactionNotSupported.
The implementation of each of the wrapped methods is relatively simple. The

example of monitoredItemAccess is shown in Example 4-2.
Example 4-2 Reference monitor session bean implementation

/**
* Bean implementation class for Enterprise Bean: TPMMonitorBean
*/
public class TPMMonitorBeanBean implements javax.ejb.SessionBean {
private static final ReferenceMonitor refMon =

ReferenceMonitorFactory.getInstance();
public void monitoredItemAccess(String masterKeyValue,

String userid,
String applTask,
ConformanceCheckResults confResults)
throws
MonitorAssistantException {
refMon.monitoredItemAccess(masterKeyValue, monitoredItemNames,
accessOperation, userid, assertedUserid,
applTask, confResults);
}
Storage location registration and identification

Using the Reference Monitor, storage location registration occurs during
ReferenceMonitor.init(). The init() method invokes the
MonitorAssistantInterface.lookupMonitoredItemNames() callback. The init()
method is invoked during the ejbCreate() lifecycle method on the session bean
wrapper. This is shown in Example 4-3.
Example 4-3 Reference monitor initialization

/**
* ejbCreate
* Initialize the ReferenceMonitor. This is done by loading
* a properties file into a java.util.Properties object,
* instantiating the MonitorAssistant, and calling init()
* on the ReferenceMonitor.
*/
public void ejbCreate() throws javax.ejb.CreateException {
// Get the Reference Monitor Properties Object
Properties monProps = new Properties();
String monPropFilename = MONITOR_PROPERTIES;
try {
monProps.load(new FileInputStream(monPropFilename));
} catch (...) {
throw new CeateException(...);
}

// Get the Monitor Assistant Object
MonitorAssistantInterface monAssist = new AhcMonitorAssistant();
// Call init.
try {
refMon.init(monAssist, monProps);
} catch (ReferenceMonitorException e) {
throw new CeateException(...);
}
}
For this J2EE application, the storage system is represented by the data access
objects (DAO), specifically PatientRecDAO and MedicalRecDAO and the value
objects they return.
For this example, the storage location names are defined as constant strings on
each of the DAOs. An example is shown in Example 4-4.
Example 4-4 Storage location names

public interface PatientRecDAO {
//
// Storage location names that this DAO knows about
//
public static final String PATIENTID="PatientId";
public static final String PATIENTNAME= "PatientName";
public static final String CITYCD = "City-Cd";
public static final String STREET = "Street";
public static final String BIRTHDAY = "Birthday";
public static final String PARENT = "Parent";
public static final String EMAIL = "eMail";
public static final String HEALTHPLAN= "HealthPlan";
Other options exist for obtaining the storage location name. For example, if the
DAO handles access to a relational database using JDBC, it might be possible to
use the JDBC metadata objects to obtain the column names within the database.
Another option might consider that the property names of the value objects
returned from the DAO are the storage locations. Using Java class reflection, it is
possible to obtain the storage locations names.
The implementation of getMonitoredItemNames is shown in Example 4-5.
Example 4-5 MonitorAssistant get monitored item names

public class AhcMonitorAssistant implements MonitorAssistantInterface {
public Hashtable getMonitoredItemNames() throws
MonitorAssistantException {
return StorageNamesHelper.getMonitoredItemNames();
}
The implementation of the StorageNamesHelper class is shown in Example 4-6.

It is a class that populates the resulting hash table according to the Reference
Monitor documentation. The helper class is used to encapsulate the storage
name lookup logic.
Example 4-6 StorageNamesHelper

public final class StorageNamesHelper {
private static final String DESCRIPTION = "DESCRIPTION";
/**
* Worker method for getMonitoredItemNames. Sets up
* name as a key into returnValue. The name is associated
* with a hashtable represented attributes about the storage
* location name. The only attribute currently supported
* is DESCRIPTION.
*/
private static final void addItem(
String name,
String desc,
Hashtable returnVal) {
// create the Hashtable for the description
Hashtable monitoredNameEntry = new Hashtable();
// store the description in the Hashtable
monitoredNameEntry.put(DESCRIPTION, desc);
// store the monitored item in the return value
returnVal.put(name, monitoredNameEntry);
}
/**
* This method provides the implementation of the
* AhcMonitorAssistant.getMonitoredItemNames().
*
* The storage location names are available as constant
* strings on each of the DAO interfaces for Patient,
* Provider, and Medical DOA's.
*
* @return The hastable containing storage locations
* to be registered for Patient, Provider, and Medical
* records.
*/
public static final Hashtable getMonitoredItemNames() {
// initialize the return value
Hashtable returnValue = new Hashtable();

// Add all of the monitored item names and their descriptions to the
// returnValue.
// Patient locations
addItem(
PatientRecDAO.PATIENTID,
PatientRecDAO.PATIENTID_DESC,
returnValue);
addItem(
PatientRecDAO.BIRTHDAY,
PatientRecDAO.BIRTHDAY_DESC,
returnValue);
addItem(
PatientRecDAO.CITYCD,
PatientRecDAO.CITYCD_DESC,
returnValue);
// etc...
return returnValue;
}
Virtual storage locations

Along with the names from the DAOs, the monitor supports and registers two
virtual storage locations. The locations are:
򐂰 virtual.accessorId
The identity of the entity accessing data. This location is supported by the
monitor for the policy statement related to parents accessing their children’s
medical data. This location is referenced by a condition on this policy rule.
򐂰 virtual.authenticationType
The strength of authentication used to log in to the online health system. This
location is supported by the monitor for the policy statement related to parents
accessing their children’s medical data. This location is referenced by a
condition on this policy rule.
Virtual storage locations are usually required when privacy policy rules have
conditions that refer to data or state information not stored in the storage system.
The locations typically represent temporary state information about the
transaction or execution context of the given data access at a given point in time.
Data subject identification

The privacy policy presented in 4.5.6, “AHC privacy policy usage statements” on
page 98 is written in terms of protection of patient data. Given this, a storage
location has to be capable of uniquely identifying patients, and any other
patient-owned data that needs to be identified. For the AHC online system, the
storage location named PatientId has been chosen. This location uniquely
identifies a record in the patient table. It can also identify each medical history
record in the medical history table.
The PatientId represents the master key location for the Reference Monitor. The
AhcMonitorAssistant informs the Reference Monitor of the master key through
the getMonitoredItemMasterKeyName() method. This is shown in Example 4-7.
Example 4-7 Master key registration

public String getMonitoredItemMasterKeyName()
throws MonitorAssistantException {
return PatientRecDAO.PATIENTID;
}
Data user identification

The Reference Monitor API requires that a value be supplied for the user identity
on real-time conformance checks and access notifications. The AHC online
system requires users to authenticate via Tivoli Access Manager WebSEAL.
Once authenticated, WebSEAL inserts the iv-user header and forwards the
request onto the WebSphere servlet container hosting the application. It is a
simple task to extract the header value from the request using
HttpServletRequest.getHeader(“iv-user”). If WebSEAL is not part of the
solution, another possibility to determine user identification is the result value
from the method HttpServletRequest.getRemoteUser().
Note: This example has been developed using WebSphere Application Server
V4, which supports the Servlet Specification Version 2.2. Under Servlet
Specification Version 2.3, it might also be possible to use
HttpServletRequest.getUserPrincipal() to determine the authenticated user’s
identity.
Propagating user identity to data access objects

A point to note about determining the user’s identity is the location within the
application. The identity value is being extracted from the servlet request.
Processing of the request is the responsibility of the presentation logic. However,
as described in “PII access detection and notification” on page 114, the monitor
callout code is located within the data access layer. Therefore, a technique for
making the value available to the callout code is required.
The technique used for this example is to modify the business logic and data
access logic invocation methods to include a parameter for the accessor value.
This is feasible because the application does not have a high level of complexity.

Another option is to store the value of the accessor using the ThreadLocal
storage. The presentation logic is responsible for setting the value. The callout
code may then extract the value from the ThreadLocal storage when required.
Application task identification

Application tasks relate to privacy policy purposes. Identification of the
application is often the most difficult part of implementing a monitor. For the AHC
online application, it has been decided to identify the task as the name of the
command object used to service a given request. A command object exists for
each of the major functions of the application. These include emergency,
research, status reporting, and so on.
Propagating purpose to data access objects

As is the case for user identity, meaningful task identification is often easier at the
higher presentation logic layers than it is within the application. The choice of
which command object to use is the responsibility of the AhcController servlet.
The controller makes the determination based on the URL and URL parameters.
The same technique that was used for identity propagation is used for application
task value propagation to the data access layer.
PII access detection and notification

The strategy for detecting data access is based on wrapping the core
implementation classes of the data access objects. Each of the DAOs within the
application are defined by Java interfaces as shown in Example 4-8. Concrete
implementations of the interface types are acquired by the application business
logic through a factory.
Example 4-8 Data access object interfaces

public interface PatientRecDAO {
/**
* This method retrieves the patient record object for the
* patient identified by key.
*
* @param patientId The patient id for which identity
* data should be obtained.
* @result The PatientRecVO populated with values from the
* storage system.
* @throws DataAccessException if one the following occurs:
* No records exists for the given key.
* An error occured reading the database.
*/
public PatientRecVO findByKey(String patientId) throws
DataAccessException;
/**
* This method retrieves all patient record objects
*
* @result A list of PatientRecVO populated with
* values from the storage system.
*/
public List findAll() throws DataAccessException;
public interface MedicalRecDAO {
/**
* This method retrieves the medical record object for the
* patient identified by key.
*
* @param patientId The patient id for which medical service data
should be read.
* @result The MedicalRecordVO populated with values from the database.
* The access does not conform to privacy policy.
*/
public MedicalRecVO findByKey(String patientId) throws
DataAccessException;
public List findAll() throws DataAccessException;
The core implementation of the DAO interfaces are PatientRecDAOImpl and

MedicalRecDAOImpl. These implementation classes are wrapped by
PrivatePatientRecDAO and PrivateMedicalRecDAO respectively. The DAO
factory has been modified to return instances of the wrapper objects. A sample of
PrivateMedicalRecDAO is shown in Example 4-9.
Example 4-9 Access detection using DAO wrappers

public class PrivateMedicalRecDAO implements MedicalRecDAO {
// Wrapped implementation
private MedicalRecDAO daoImpl = null;
// The entity using this DAO

private String accessorId = "";
// The business or application purpose

// for using this DAO
private String purpose = "";
/**
* Disabled
*/
private PrivateMedicalRecDAO() {
super();
}
/**
* Create a new wrapper for a MedicalRecDAO.
*
* @param dao The concrete implementation of the DAO
* to be wrapped.
* @param accessorId The id credential of the user
* performing operation with this DAO.
* @param purpose The business or application purpose
* for using this DAO.
*/
public PrivateMedicalRecDAO(MedicalRecDAO dao,
String accessorId,
String purpose) {
super();
this.daoImpl = dao;
this.accessorId = accessorId;
this.purpose = purpose;
}
/**
* A privacy enabled implementation of database lookup. This
* method retrieves the medical record object for the
* patient identified by key. A privacy enforcement check
* and access notification is performed against TPMS.
* Enforcement is done by obfuscating property values of
* the result value object based on conformance check.
* The enforcement achieves field level access control.
*
* @param patientId The patient id for which medical service
* data should be read.
* @result The MedicalRecordVO populated with values from the database.
* @return MedicalRecVO object that may have obfuscated property
* values based on privacy conformance checks
*/
public MedicalRecVO findByKey(String patientId) throws
DataAccessException {
// do the real data operation
MedicalRecVO result = this.daoImpl.findByKey(patientId);
// do a conformance check and enforcement.
PrivacyEnforcement enforcement = new
PrivacyEnforcement(this.accessorId, this.purpose);
enforcement.enforcePrivacy(result);
// do an access notification
PrivacyAccess access = enforcement.createPrivacyAccess();
access.accessNotifcation(result);
return result;
}
/**
* For each value object
*/
public List findAll() throws DataAccessException {
// do the real access operation
List result = this.daoImpl.findAll();
// for each value object, do a conformance check,

// enforcement, and access notification.
Iterator i = result.iterator();
while (i.hasNext()) {
MedicalRecVO medRec = (MedicalRecVO)i.next();
PrivacyEnforcement enforcement = new
PrivacyEnforcement(this.accessorId, this.purpose);
enforcement.enforcePrivacy(medRec);
PrivacyAccess access = enforcement.createPrivacyAccess();
access.accessNotifcation(medRec);
}
return result;
}
}
Each of the find methods inherited from the interface definition use the wrapped
DAO implementation to perform the actual data accesses. However, after the
access has returned control to the privacy wrapper, conformance checks,
enforcement and access notification are performed against the Tivoli Privacy
Manager server.
Real-time enforcement
Real-time enforcement is linked very closely with access detection. As shown in
Example 4-9 on page 115, the enforcement occurs before the access

notification. It is done this way so that only conformant (for example successful)
accesses are reported to the Tivoli Privacy Manager server.
Real-time enforcement requires that a conformance check be performed against

the Tivoli Privacy Manager server. The results of this are used to filter specific
values from the value objects or result set. From Example 4-9 on page 115, it is
worth noting that for findAll(), enforcement and access notification is performed
for each value object. This is done because the privacy policy requires a
fine-grained consent from provider and patient to release the record. These
consents are collected and stored with each medical record, and therefore must
be considered individually from a privacy disclosure perspective.
The conformance check callout to the Tivoli Privacy Manager server, and
enforcement has been encapsulated in the class PrivacyEnforcement. This class
has methods to handle MedicalRecVO and PatientRecVO objects. Example 4-10
shows the logic related to MedicalRecVO enforcement.
Example 4-10 Privacy enforcement for medical value object

public class PrivacyEnforcement {
// Non conformant replacement value
private static final String ENFORCEMENT_VALUE= "****";
private String accessorId = "";

private String purpose = "";
private ConformanceCheckResults ccr = null;
private ArrayList accessedItems = new ArrayList();
private PrivacyEnforcement() {
super();
}
public PrivacyEnforcement(String accessorId, String purpose) {

super();
this.setAccessorId(accessorId);
this.setPurpose(purpose);
}
/**
* Factory for PrivacyAccess notification handler.
* This is the only way to create such objects.
*/
public PrivacyAccess createPrivacyAccess() {
return new PrivacyAccess(this.getAccessorId(),
this.getPurpose(),
this.getAccessedItems(),
this.getCcr());
}
/**
* Do a conformance check and enforcement for the
* given MedicalRecVO. This method uses MonitorManager
* to do the JNDI lookup of the Refmon wrapper bean.
*/
public void enforcePrivacy(MedicalRecVO medRec)
throws DataAccessException {
try {
// JNDI lookup wrapper
MonitorManager mon = new MonitorManager();
// Set context information that will be
// required by the AhcMonitorAssistant.
// PrivacyThreadContext is a wrapper for
// ThreadLocal storage.
PrivacyThreadContext.setContextItem(
PrivacyThreadContext.MEDICAL_RECORD, medRec);
PrivacyThreadContext.setContextItem(
PrivacyThreadContext.ACCESSOR_ID, this.getAccessorId());
// do the conformance check
ConformanceCheckResults ccr =
mon.monitoredItemConformanceCheck(medRec.getPatientId(),
StorageNamesHelper.getMedicalRecNames(),
ReferenceMonitor.ACCESS_FOR_READ,
this.getAccessorId(),
null,
this.getPurpose());
this.setCcr(ccr);
// now filter the result value object properties
this.enforcePrivacy(medRec, this.getCcr());
} catch (MonitorManagerException x) {
// handle error
} catch (ReferenceMonitorException x) {
// handle error
}
}
/**
* For each false value present in the CCR, set the
* corresponding property value on the MedicalRecVO.
*
* For each true value present in the CCR, add the storage
* location name to the list of conformant accesses.
*/
private void enforcePrivacy(MedicalRecVO medRec,
ConformanceCheckResults ccr) {
ArrayList ccrList = ccr.getConformanceResults();

ArrayList namesList = StorageNamesHelper.getMedicalRecNames();
Iterator i = ccrList.iterator();
Iterator j = namesList.iterator();
while (i.hasNext() && j.hasNext()) {
Boolean isAllowed = (Boolean)i.next();
String name = (String)j.next();
if (isAllowed.booleanValue()) {
// add to list of conformant access
this.getAccessedItems().add(name);
} else {
// filter porperty value
if (name.equals(MedicalRecDAO.BLOODGRP)) {
medRec.setBloodGroup(ENFORCEMENT_VALUE);
continue;
}
if (name.equals(MedicalRecDAO.CATEGORY)) {
medRec.setCategory(ENFORCEMENT_VALUE);
continue;
}
// etc ...
}
}
}
Of particular interest in the example above is the use of the thread local storage.
Before the enforcement callout code invokes the Reference Monitor, the value
object being considered and the accessor identity value are placed in the thread
local storage. This is done to make them available to
AhcMonitorAssistant.lookupMonitoredItemValues(). The Reference Monitor API
does not provide any means to accomplish this. This technique is useful for
virtual storage locations. It also helps to improve performance, since the values
already read from the storage system are available in the value object.
PII submission detection

Submission detection is based on the same strategy as access detection. The
privacy wrapper DAOs invoke monitoredItemAccess for methods that represent
write operations.
Conditional value retrieval

During the execution of ReferenceMonitor.monitoredItemConformanceCheck(),
the Reference Monitor requires values to be retrieved for storage locations that
have been mapped to policy rule conditions. The Reference Monitor uses the
callback methods on the MonitorAssitantInterface.lookupMonitoredItemValues()
to do this. The implementation from AhcMonitorAssistant is shown in
Example 4-11 on page 121.
Example 4-11 Lookup monitored item values
public Hashtable lookupMonitoredItemValues(
ArrayList monitoredItemNames)
throws MonitorAssistantException {
Hashtable result = new Hashtable();
Object contextData = PrivacyThreadContext.getContextItem(

PrivacyThreadContext.MEDICAL_RECORD);
if (contextData != null) {
MedicalRecVO vo = (MedicalRecVO)contextData;
result = LookupValueHelper.lookupMedicalMonitoredItemValues(
masterKeyValue,
monitoredItemNames,
vo);
}
contextData = PrivacyThreadContext.getContextItem(
PrivacyThreadContext.PATIENT_RECORD);
if (contextData != null) {
PatientRecVO vo = (PatientRecVO)contextData;
result = LookupValueHelper.lookupPatientMonitoredItemValues(
masterKeyValue,
monitoredItemNames,
vo);
}
return result;
}
As can be seen, the thread local values are retrieved. A helper class performs
the core work of the lookup. The helper class implementation is shown in
Example 4-12.
Example 4-12 Lookup values helper

public class LookupValueHelper {
/**
* The lookup has been triggered from an access to a medical
* history record.
* Iterate through the list of monitoredItemNames an set
* its value in the result hashtable. It the name is an
* attribute of Patient data, then get the patient data from
* the storage system based on masterKeyValue.
*/
public static Hashtable lookupMedicalMonitoredItemValues(

MedicalRecVO rec) {
Hashtable result = new Hashtable();
PatientRecVO patVO = null;

Iterator i = monitoredItemNames.iterator();
while (i.hasNext()) {
String name = (String) i.next();
// is the name an attribute of the medical

// record
if (name.equals(MedicalRecDAO.BLOODGRP)) {
result.put(name, rec.getBloodGroup());
continue;
}
if (name.equals(MedicalRecDAO.CATEGORY)) {
result.put(name, rec.getCategory());
continue;
}
// etc...
// is the name one of the virtual storage

// locations
if (name.equals(VirtualStorageLocation.ACCESSOR_ID)) {
String val = (String)PrivacyThreadContext.getContextItem(
PrivacyThreadContext.ACCESSOR_ID);
if (val != null) {
result.put(name, val);
} else {
result.put(name, "");
}
continue;
}
if (name.equals(VirtualStorageLocation.AUTHENTICATION_TYPE)) {
String val = (String)PrivacyThreadContext.getContextItem(
PrivacyThreadContext.ACCESSOR_AUTH_TYPE);
if (val != null) {
result.put(name, val);
} else {
}
continue;
}
// is the name an attribute of patient data

try {
if (name.equals(PatientRecDAO.BIRTHDAY)) {
if (patVO == null) {
patVO = getPatientRecordForKey(masterKeyValue);
}
result.put(name, patVO.getBirthday());
continue;
}
if (name.equals(PatientRecDAO.CITYCD)) {
if (patVO == null) {
patVO = getPatientRecordForKey(masterKeyValue);
}
result.put(name, patVO.getCityCd());
continue;
}
// etc...
} catch (DataAccessException x) {
x.printStackTrace(System.out);
}
}
return result;
}
/**
* Get a patient identity record from the data base.
* This method uses the core PatientRecDAOImpl class to
* do the lookup. Don't use the PrivatePatientRecDAO
* because that would trigger the whole conformance
* and lookup logic again resulting in a infinite
* loop.
*/
private static PatientRecVO getPatientRecordForKey(String key)
throws DataAccessException {
PatientRecVO result = null;
PatientRecDAO dao = new PatientRecDAOImpl();
result = dao.findByKey(key);
return result;
}
4.7 Conclusion
The example code discussed satisfies the needs of the four use cases
mentioned in 4.5.6, “AHC privacy policy usage statements” on page 98. The next
steps for such a project would definitely include testing use cases that exercise

other data usages scenarios based on the policy description in 4.5.6, “AHC
privacy policy usage statements” on page 98.
The design outlined, based on monitoring at the data access layer, provides an
extensible framework for ongoing enhancements to the application. If the
application data model is expanded (for example, new tables and data access
objects), then a corresponding privacy wrapper for the DAO can be easily
implemented. If access to new conditional values is required, the use of the
Reference Monitor helps to centralize implementation in the Monitor Assistant.
This is also true for policy changes that may require new purposes and storage
locations.
5
Chapter 5. Human Services application

based on Siebel 7
Some individuals have significant problems in managing the challenges of life.
Often they do not understand choices they have and options they can select
from. Some individuals are not aware of benefits they are legally entitled to,
whereas others try to overuse the systems for their own sake.
Most of these people need help from a third party which is typically the
government or a local organization helping them to get along with the necessities
of their daily life.
In full respect of the situation an individual might suffer from, the functional
requirements of a system supporting named situations can best be described as
Customer Relation Management (CRM), where client representatives act on
behalf of the client. They have to follow legal guidelines and need to respect
options and choices made by the client given in writing or over the telephone.
Acting on behalf of a client is a very common situation for any call center and
must therefore be a key component of every CRM system. However, in this
section we focus on the privacy issue.

5.1 Our company (Authority for Social Administration)
The government has established local organizations in every community called
the Authority for Social Administration (ASA) to help and support people in
need. The Authority for Social Administration is a local authority committed to
ensure that all citizens have access to quality services that protect and enhance
the community’s physical, mental and social well-being. ASA is offering help
tailored to the needs and problems of all affected individuals. In this way the
Authority for Social Administration contributes significantly to stabilizing the
community by increasing the level of social freedom for both community and
citizen.
The ASA understands itself as the attorney of citizens who find themselves in
emergency situations resulting from a personal or economic catastrophe.
Supported situations might also result if this person is not capable of participating
in the regular social life of the community without help from others.
To serve citizens best, the ASA is organized into multiple service units ( hereafter
called branches). Every branch is typically named according to the reason the
individual turns to the ASA, and employees are well trained for their particular
topics.
Separation of duties of the various branches of the ASA is a legal requirement.

Regulations say that access to information regarding personnel, medical and
economic data of an individual must be restricted to authorized users only. This is
also to ensure that an affected person receives full benefits and support without
discrimination related to his or her family, individual preferences, disabilities, or
other handicaps.
Therefore the ASA needs to maintain multiple databases, one for each branch.
Within the branch, access rights to certain client data is restricted to a particular
case worker only.
Note: The general privacy requirements simply state that access to data must
only be given to people approved for a certain set of data of a client. Data
access for unauthorized persons must be prevented by any means.
Checking further details of this regulation shows that an approval for any
individual worker only covers a few data entries out of the full range of client
data stored in the multi-branch databases of the ASA. But access rights must
also relate to the purpose of the request. To manage this Matrix of Rights is
perhaps the most challenging requirement we have been working through.
5.2 Architecture and procedures
The ASA is organized into multiple branches, which are tasked to help citizens
with their current needs. Within every branch, case workers deal with client
cases. Every branch has its own dedicated set of workers, and interaction across
branches is kept to the absolute minimum. Also, within a single branch
communication between workers about individual issues of a client is very
restricted.
Each item of information passed along to another worker or another branch has
to contain a reason for request and the requester has to prove the need to know.
Managers are not allowed to see details of client data, but need to have a basic
knowledge about any case. Problematic situations with a client can be escalated
to management, and management becomes responsible for solving the issues.
5.2.1 Organization of the Authority for Social Administration

An Authority for Social Administration is typically organized into the following
branches:
򐂰 Adoption
򐂰 Aged Care
򐂰 Child Protection
򐂰 Disability Services
򐂰 Family Support
򐂰 Home and Community Care
򐂰 Juvenile Justice
򐂰 Mental Health
򐂰 Problem Gambling
򐂰 Public Health
򐂰 Public Housing
In the remainder of this chapter we do not cover all branches and do not discuss
any specific implications, but rather want to use a particular case with an artificial
set of characters to better illustrate the current operation model. In this way, it is
much easier to describe the shortfall of the actual implementation and discuss
possible improvements that can be achieved using IBM Tivoli Privacy Manager
working with the ASA Siebel application.
The basic set of client data is very similar within every branch, but separation of
data is a legal requirement.
Chapter 5. Human Services application based on Siebel 7 127

5.2.2 Client data
We start with the typical data everyone expects to see first:
򐂰 Client name
򐂰 Sex
򐂰 Date of birth
򐂰 Address
򐂰 Telephone number (numbers) and e-mail-address
For every client a complete set of data is stored in the branch-related database
where the client requests help. Therefore, the client has individual customer IDs
in every single branch. A graphical representation of the distinct databases is
shown in Figure 5-1.
In each individual’s data container, additional information on the service is stored:

򐂰 Name of case worker
򐂰 Name of lead worker
򐂰 Telephone number, and contact address of workers
Name Name Name Name Name

Address Address Address Address Address
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
ID Housing ID Mental ID Disability ID Family ID Juvenile
Public Mental Disability Family Juvenile

Housing Health Service Support Justice
Figure 5-1 Separated databases for multiple ASA branches
5.2.3 What PII data do we have?

In our scenario, PII is not exclusively used as personal information that makes it
possible to trace a person, but it is rather considered to be a very fine-grained,
programmable data protection layer to restricted access to data elements from
unauthorized people.
We categorize data into data blocks according to the special needs of every
individual branch:
򐂰 Personal identity data (name, address, phone number, etc.)
򐂰 Personal preferences data (language, religion, etc.)
򐂰 Personal health-related data (disabilities, treatments, drugs, etc.
򐂰 Personal finance-related data (income, benefit plan, spending behavior, etc.)
򐂰 Personal identity-related historic data (alias, foster, caretaker, etc.)
򐂰 Personal behavior-related data (friends, contacts, anti-social, violent, etc.)
This is an arbitrary categorization and can be different for every purpose.
Note: The basic data set of our individuals and the requirements exploited in
our human services example are very similar to any insurance company or
financial institution maintaining customer data-handling contracts, connecting
insurance agencies and providing help centers.
The challenging part of this chapter is to explain the special situations the
clients of human services are involved in, the special data case workers need
to retrieve on behalf of their clients, and the purpose this data is used for.
Human services is one of the most challenging use cases and definitively
requires the most secure solution to protect data from unauthorized access.
Let us take a closer look at some data that is collected by the case workers. This
data includes many delicate details that are typically stored in the client’s data
record within the different branch databases.
5.2.4 Examples of data needed within branches of ASA

An extract of personal data stored on an average client indicates how sensitive
the ASA data can be. Most of the time, a case worker needs to store even more
details about his client than we describe.
Relevant data is often split into two parts: Data fields indicating evidence and a
course result, and data fields with details on the client. Both field types are
protected individually and by separate privacy rules.
򐂰 Child Protection data
– (Preferred) name, sex, age, address
– Parents (name, address, age, occupation, foster parents Y/N)
– Siblings (Y/N, name, sex, age, school, step-siblings Y/N)
– School (address, contact person, school problems)
– Benefits from ASA - Child Protection unit
• Case worker
• Recommended accommodation
• Other benefits and support
– Alias names
– Relatives (address, relation, caretaker Y/N)

– History
• Disabilities (Y/N, details)
• Abused (Y/N, details)
• Treatments (Y/N, details, such as depression, surgeries, etc.)
– Name and address of friends the child would go to in emergencies
– Name and address of associates the child visits regularly
The Juvenile Justice branch has similar entries but includes more Y/N flags:
򐂰 Juvenile Justice
– (Preferred) name, sex, age, address
• Lives alone Y/N
• Has partner Y/N
• Contact to parents Y/N
– Alias names
– Parents, name, address, occupation Y/N, details, police record Y/N
• Divorced Y/N, (responsible parent)
• Single parent Y/N
• Foster Y/N
• Caretaker (carer) Y/N, address, name of birth, parents, relatives Y/N
– Siblings Y/N, name, sex, age, school, step-siblings Y/N
– Education
• Contact school worker
• School Y/N, knows conviction Y/N, rude Y/N, and so on
• Apprenticeship Y/N, company, knows conviction Y/N, rude Y/N
– Behavior
• Contact street worker
• Anti-social Y/N, details
• Rude Y/N, details (responds to reasonable facts, objections)
• Violent Y/N, details (contacts, and so on)
• Drugs Y/N, details (contacts, and so on)
• Steals Y/N, details (contacts, and so on)
– Benefits from the ASA - Juvenile Justice
• Case worker
• Recommended accommodation
• Treatments, therapies
– Previous convictions still active Y/N, details
– Police record Y/N, details
– Under strict observation Y/N, details
– Contact information
• Name and address of friends
• Name and address of associates the child visits regularly
• Confessed membership with groups Y/N, details
򐂰 Public Housing
– Name, address, sex, age
• Martial status (married Y/N since, divorced Y/N since, single Y/N)
• Partner Y/N
• Children (name, sex, age, school Y/N, including step and foster
children)
• Number of persons in household
– Occupation
• Applicant: training, employed Y/N, income, details
• Partner Y/N: training, employed Y/N, income, details
• Other adults Y/N: education, employed Y/N, income, details
– Benefits from the ASA - Public Housing branch
• Case worker
• Approved number of rooms
• Actual number of rooms
• Other benefits and support
򐂰 Mental Health
– Name, address, sex, age
– Spouse Y/N
– Caretaker Y/N, name, address
– Children Y/N, name, sex, age, school, problems, active foster Y/N
– Employed Y/N, (employer knows about problem: Y/N), contact worker
– Personal situation
• On medicine Y/N, drugs Y/N, mental confusion Y/N, suicidal Y/N
(speaks about it, committed attempts), can live alone Y/N
– Medical history
• Disabilities Y/N, details
• Abused Y/N, details
• Raped Y/N, details
• Active treatments Y/N, details (depression, surgeries, and so on)
• Former treatments Y/N, details

– Benefits from the ASA - Mental Health branch
• Case worker
• Previous therapies Y/N, details
• Ongoing health plan Y/N, details
• Recommended accommodation, details, single room Y/N
5.2.5 Which privacy policy matches my consent?

A client who is asked to consent to a policy may want to study very carefully the
privacy policy attached to this particular set of data and compare how the data
can be used either within a single branch of the ASA or across the ASA, or if it
can be given to an external ASA partner. Most clients will probably not consent to
sharing their data outside the involved ASA branch.
5.2.6 Case worker

Whenever a client addresses the ASA, or the ASA is called to action by other
state agencies (law enforcement, hospitals, and so on) a case worker is assigned
to handle the event. There are different types of case workers employed at the
ASA:
򐂰 Lead case worker (manages case workers in multiple branches)
򐂰 Case worker (individual practitioners with expertise in a distinct branch who
collect and maintain detailed case data)
򐂰 Front desk worker (has insights in general client data, all branches)
򐂰 Delivery case worker (delivers special service, address data only)
The ASA department manager assigns case workers or lead case workers, but
cannot see detailed client data.
5.2.7 An atypical household: The Privacy Manager family

For our specific scenario, we want to introduce you to our family. You may think
that all the individual facts that are presented within this one family do not reflect
a typical household, and you are probably right. We are simply trying to create
different cases within one family involving different case workers in different ASA
branches. This scenario helps us to describe the privacy implications within our
business environment based on one family profile.
Figure 5-2 An atypical household: The Privacy Manager family
People acting in our scenario

The following sections briefly describe the members of our family, their roles, and
the consent they have given to use their data. Using the names, we explain the
current environment and operation of the ASA as well as the improvements
related to data privacy that are possible using IBM Tivoli Privacy Manager.
The household members

򐂰 Mary, 42, mother
– Hearing problems (proven disability for the last five years)
– Husband in jail because of murder
Mary has consented that her ASA benefit data can be shared between
branches.
򐂰 Jim, 6, Mary’s youngest son (foster son)
– Assaulted by Mary’s husband, therefore he still suffers from severe
depression (child care)
Mary has used her opt-out privilege for Jim’s foster data, so this data cannot
be shared with any other ASA department. She did it because her husband

has assaulted Jim, and to make sure that Jim’s school does not know about
the real family status of Jim.
򐂰 Peter, 14, Mary’s son and her educational challenge
– Peter has a lot of trouble with authorities; he is under juvenile justice
supervision, and needs to report to his case worker daily.
򐂰 Bob, 16, Mary’s eldest son, wheelchair (proven disability for the last 10 years)
򐂰 Paul, 17, stepson of Matthew, household member (child care)
򐂰 Matthew, 45, male friend of Mary, stepfather of Paul, unemployed
– Well known because of his violent manner
– Mistreats some household members since he moved in
Matthew has consented that his unemployment benefits can be shared with
other departments to properly calculate benefits for housing and family
support.
򐂰 Other participants
– Good, Bad and Ugly are named friends of Peter
Services provided
Table 5-1 gives an overview of what services are provided by the ASA.
Table 5-1 Services rendered

Housing Disability Child Juvenile Mental Unempl Relation
Protection Justice Health oyment
Mary x x Mother
Jim x x x Foster-son
Peter x x Son
Bob x x x Son
Paul x x Household
member,
foster care
Matthew x x Mary’s
friend, Paul’s
stepfather
Case worker acting

We have five case workers that are involved in the interaction between clients
and across branches of the ASA.
򐂰 Ann: case worker_1, Housing, assigned to Mary, Jim, Bob, Peter and Paul.
򐂰 Betty: case worker_2, Disability, assigned to Mary and Bob.
򐂰 Charlie: case worker_3: Child Protection, assigned to Jim and Bob.
Bob informs Charlie about violence of Matthew towards his step-son Paul, Jim
and Mary and his violence influence on Peter.
򐂰 Dan: case worker_4: Juvenile Justice, assigned to Peter.
򐂰 Egon: Family case worker for Mary and assigned lead case worker for this
household. He enrolls Matthew and Peter as new household members and
adds Matthew as new partner of Mary.
򐂰 Fran is the front-desk case worker taking calls from police, hospitals and so
on.
Current operation of ASA with our household

The current operational model for the ASA provides case workers with certain
insights into client data of their particular branch, but only to a limited extent. A
health care practitioner is also considered a case worker storing health-related
data of the client — but he should not see any other than health-related data.
After a client appointment, the case worker performs the following tasks:
򐂰 Write a report.
򐂰 Store some of the data in the branch-related database.
򐂰 Send a visitation memo to the lead case worker.
As the lead case worker, Egon is informed by the individual case worker on his
current activities. He can maintain his own folder to archive team results, but
cannot access any data other than that within his own branch.
Example: Client consultation

Mary goes to her housing case worker Ann because she wants Ann to explain to
her in detail the amount of money she currently gets from the housing branch.
The housing benefits are based on some very generic statements such as:
򐂰 Marital status, age, number of persons in household and so on
򐂰 Income
򐂰 Number and age of children
򐂰 Bonus (based on degree of disabilities, social programs and therapies they
participate in)
However, Ann can only see the extra benefits Mary gets from public housing and
she cannot access the data of the other branches to check for the extra benefits
Mary would be entitled due to a Bonus (see list above). Also, Ann cannot access
the income of the other household members and she cannot see the latest
changes made by Egon entering Matthew and Peter as new household

members. The current ASA system cannot reflect the consent given by Matthew
to show his benefits.
Ann expects the paperwork to be available soon and asks Mary to return for
another appointment. Because Mary needs to take a half day off to make it to the
ASA office, this is very inconvenient. Although Ann trusts Mary, she cannot sign
for any additional benefits before any confirmation from the other branches is
available.
If Mary wanted to have a consolidated entitlement on her benefits from the ASA,
she could go to the supervising manager. He can pull together all papers and
data needed. She could also ask him to start working on her additional requests
for more benefits. At the end he would make a fair judgment, but Mary does not
feel comfortable with this procedure, because this calculation is done manually,
and the supervisor will have very deep knowledge of all her very personal data
and those of the children. On top of this, the supervisor process is also
acknowledged to be very slow.
5.2.8 Other shortfalls of the current situation

The ASA has recently implemented a CRM application based on Siebel.
However, they have not yet implemented an appropriate privacy policy according
to the highly complex environment of the ASA and the dependencies described
above. To meet the privacy requirements, a very fine-grained protection of client
data to the level of single-worker_single-client-datafield is needed, without
spending to0 much effort customizing every business object.
It is very challenging to match the dynamic situation of having a multitude of case

workers assigned to many different virtual household teams and simultaneously
controlling access to any single data element of every individual client.
The ASA further requires that the implementation must be easy and flexible
enough to maintain and change existing privacy definition and protection rules,
so the ASA can easily solve the following tasks:
򐂰 Adapt to changing reasons and rules why benefits are given to clients.
򐂰 Make use of knowledge other parties have gained about ASA clients.
򐂰 Include latest direction and policies from the government.
򐂰 Comply with new guidelines released by the Social Security Administration.
It repeatedly happens that management can access too many details on client
data, which has caused some irritation and has biased management in their
decision. Since management must assign a lead case worker, they need to see
certain data before they can decide on a lead case worker acting for a certain
household. They also have to adjust and balance the workload for every case
worker and therefore need to figure out the case workers’ priorities to protect
most wanted case workers. An alert-notification capability to enhance case
worker safety was a key issue for many years and is urgently needed. However,
alert notification needs the same granularity as we have discussed for the client
data.
Example: Inquiries from police and hospitals

Let us assume a police officer is calling the ASA because a juvenile has been
taken into custody for shoplifting. The officer asks the front-desk worker Fran for
any existing evidence or records on the juvenile.
What would be a proper way to respond to a Police_Inquiry?
As of today, the front-desk worker Fran can connect the police with any juvenile
case worker on the phone to discuss the actual police case. The case worker
does not have access to any information on the juvenile’s history with the ASA,
nor does he know this juvenile by heart, nor his parents or friends, because he
might not be responsible for the district the juvenile lives.
Later we will return to this scenario and check how the new business vision
changes this inquiry.
Be aware that the ASA will become involved in this case anyhow, because at
the end they need to work with the juvenile and with his parents.
The ASA will be called in on the court hearing of the juvenile, and therefore
needs to assign a case worker for the juvenile.
Therefore, it might be very beneficial for both juvenile and ASA to start this
interactive process as soon as a police call comes in.
5.3 Corporate business vision and objectives

The ASA was running multiple projects trying to find out how to enhance
efficiency of operation by improving communication between case workers and
by sharing data more intelligently, but all these efforts have come to a quick stop
as soon as privacy issues have been raised by the legal department checking the
applications. Protection of clients’ privacy when dealing with confidential data is a
cornerstone of every human service department. Any information passed to
another person has to clear privacy regulation first.
However, after a recent violent incident at the local school, all media have raised
severe doubts about the ASA’s performance and efficiency. The media have
pointed to the fact that the ASA’s client data is not shared between workers
across branches. Some journalists have done some quick research on the case,

ignoring the privacy of victims and witnesses, but revealed the following for this
particular case:
򐂰 Many ASA case workers have been working with members of the household
of the violent juvenile, including juvenile service.
򐂰 Peter’s case worker and his mother knew about certain problems the juvenile
had at school. He had previously assaulted some of his schoolmates and
made aggressive remarks to one of his teachers. He was also strongly
influenced by the violence of juveniles that he was spending a great amount
of time with, and by his single mother’s violent male friend Matthew, living in
the same household.
򐂰 Matthew himself had two case workers assigned to him, since he was
receiving unemployment benefits from one branch, and was under
surveillance of police because of multiple violent incidents after football
games.
򐂰 The mother had three individual case workers assigned to help her with
housing and family care. She also received benefits and treatment because of
her disability and has been counselled because of mental problems in the
past.
򐂰 Before the violent school incident committed by Peter, the ASA also received
a request for information from the local police asking for evidence on violence
for some juveniles that Peter was acquainted with, but the ASA did not
respond reasonably.
Since these details have been broadcast all over the media, they are generating
strong pressure on the ASA management to revise procedures and come up with
a conclusive answer to improve operational efficiency and protect the privacy of
client data to a level that is legally requested.
The ASA needs to make client data access more convenient and efficient for
case workers and for other staff.

The ASA senior management wants clients to be considered in a more holistic
manner. Therefore they facilitate the coordination of client services and
collaboration between branches to enable ASA’s vision of a more holistic,
client-focused care.
ASA management needs to provide appropriate client linkage across branches

to share basic information for cross-branch clients. They want to link the
client-based system between public housing, child protection, juvenile justice and
disability services as soon as possible.
They also want to be ensured that no modification of existing applications will be
needed when extending this project to other branches in the future by
externalizing the complex data protection issue outside of their Siebel
application.
This external privacy layer needs to take care of privacy issues related to legal
requirements of the four branches that will be linked together in the first project
phase, but also needs to be extendable for future requirements of the other
branches, which are planned to be integrated in the next project phase.
The privacy layer also needs to take care of any adjustments according to
upcoming privacy rules and regimentation either due to legal changes or (much
more likely) to changes in political guidance without touching the implemented
and operational Siebel CRM applications.
The privacy layer is also intended to support an easier integration and more
effective communication with participants working outside of the ASA offices but
linked into the ASA information flow, such as general health care practitioners,
nurses, and so on.
ASA management decided to implement a Privacy-enhanced ASA Datafield

Restriction Engine called PADRE. It is a sublayer intercepting the Siebel
customer database requests submitted by a business object. It reveals the
appropriate information needed by a case worker according to the Siebel setup,
if an externally applied privacy policy for this single data field matches the
approved Business_Call of a case worker.
5.4.1 Business value of the integration of Siebel and PADRE

Management is committed to use Siebel for Client Relation Management but
wants to enhance the privacy of client data. They also want to be fully auditable
for the purpose of any data is being used. Therefore, Siebel will only show the
requested data to the case worker, if the request is approved by an externally
applied privacy policy. PADRE is going to be implemented as a sublayer
intercepting requests to the Siebel Customer Database. Using Siebel in context
with PADRE enables the ASA to look at their clients in a more holistic manner.
򐂰 PADRE is designed as a thin information request translator and an
enforcement layer able to understand and interpret data requests submitted
from the CRM system to ensure full privacy of clients’ data.
򐂰 The system works with the preferred client name, which will be valid for any
lookup in all branches of the ASA to describe a client. Therefore, PADRE will
fuel ASA’s mission and vision to focus on client care.

򐂰 It will assist and enhance the communication between case workers in charge
of a single client or a household providing shared access to data ensuring full
privacy of client data.
򐂰 The first project phase will link information between public housing, child
protection, juvenile justice, and disability services.
򐂰 PADRE will support Siebel to handle alerts across branches.
򐂰 It will create audit reports for all data fields that have been accessed by listing
the accessing user ID and the purpose for accessing this data from the
application. If data is investigated on behalf of a client, it will also report the
asserted client ID.
5.4.2 Benefits of the privacy enhanced system PADRE

The ASA has discussed in detail the following benefits they want from a privacy
enhanced system:
򐂰 Case worker
– Can see if new client already exists within ASA.
– Can see and verify basic information on client (name, address, and so on).
– Can see names of case workers at the other branches.
– Has certain access to clients’ data from other branches (also depending
on the consent of this client).
– Gets more access if assigned to the extended client team.
򐂰 PADRE
– Reduces efforts for gathering data.
– Improves correctness of entered data.
– Avoids multiple entries for the same client.
– Allows consolidation of client data in one single database (long term).
– Makes it much harder for a client to provide false data intentionally.
– Helps to reduce false payments obtained by fraud.
– Enhances the operation of the ASA.
– Significantly reduces the administrative burden on the case worker.
– Requests less administrative data from the client and provides more time
to verify data and improve service by reusing existing information.
– Significantly increases mobility of the case worker providing secure and
private interaction via the Web from any place a case worker needs to look
up client data.
Management and case worker require many business functions to request client
data in order to get their jobs done, but they also need new functions to improve
and enrich client support.
The goal is to have Tivoli Privacy Manager implemented so that the ASA can
work with basic Siebel objects, prevent safeguarded data from being displayed
with Privacy Manager intercepting and checking storage location mapping, P3P
rules, and other privacy conditions.
Although Siebel functions are more preconfigured compared to the basic Web
applications we described in Chapter 4, “Health care provider using a
WebSphere application” on page 79, they are not as standardized as the Web
container described in Chapter 6, “Financial provider using multiple J2EE
applications” on page 175. Let us discuss the requirements reflecting the
scenarios we have discussed at the beginning of this chapter when describing
the shortfalls of the current ASA system.
We focus on a few situations describing typical cases for ASA:

򐂰 Policy inquiry answered by front desk worker — the call is taken by Fran and
supported by other workers.
򐂰 Hospital calls front desk — the call is taken by Fran.
򐂰 Benefit calculation for public housing — Ann is working with information
across branches.
򐂰 Nomination for a client therapy by Betty (disability service) and Egon (family,
lead case worker).
򐂰 Violence prevention — Egon works together with case workers from other
branches.
򐂰 Case worker assignment by management.
5.5.1 Front desk handles calls from police and hospital

The first example describes inquiry calls coming from other government
agencies such as a hospital or the police to the ASA front desk where Fran is
picking up the call.
Call from police on juvenile shoplifting

A police officer is calling the ASA, because the police has taken a juvenile into
custody for shoplifting. The police officer is asking the front desk worker Fran
about any existing evidence on the juvenile.

The front desk worker can view certain data of all existing ASA clients. This is the
list of data accessible to the front desk to evaluate_client for a police call:
򐂰 Client name
򐂰 Parental guardians
򐂰 Lives with household (flag)
򐂰 Assigned case workers
򐂰 Client’s behavior flag (violence)
򐂰 Household members’ behavior flag (if any)
Using this request, the front desk worker can find the juvenile (and his parents) in
the ASA database with the following intentional omissions:
򐂰 She cannot see other branch data for the juvenile or the parents.
򐂰 She can only verify basic dependencies, such as who the existing case
workers are.
If the police provides more detailed information in the call by specifically asking
the ASA for Peter’s case (evaluate_police, Peter) more immediate actions are
possible.
򐂰 Fran finds Peter in the ASA database and can see or initiate the following:
– Name verification OK; the ASA can handle it.
– No address is displayed because Peter’s age is under 18 years.
– Lives at home flag shows (Y).
– Parental guardian shows (Mary, mother).
– Display lead case worker (Egon).
– Show behavior flag (Y).
– Post an alert to Egon to have Peter picked up by his parents.
– Copy Dan (case worker juvenile) for more information and preparation.
򐂰 Thereafter Egon checks the data using the ASA function assess_household.
– He informs Mary to go to the police station to pick up Peter.
– He can see the Violence flag of Matthew and react appropriately.
– He and Dan can work with the police and other authorities to find some
treatments for Peter.
Call from a hospital on a woman breakdown

What would be a proper way to respond to a social_inquiry?
Mary has been picked up in the streets having a total breakdown. She has been
taken to a hospital for checkup and treatment. The hospital calls the front desk
and talks to Fran. This is the list of data accessible to the front desk to
evaluate_health for a hospital call:
򐂰 Client name
򐂰 Parental guardians
򐂰 Emergency contact
򐂰 Lives with household (flag)
򐂰 Household members’ behavior flag (violence)
򐂰 Assigned case worker
򐂰 Personal health status including medical history, active treatment, takes
drugs, suicidal, and so on
Fran can see the following details of Mary’s data by accessing the
evaluate_health function:
򐂰 Name and address (verification OK; ASA: we know her and can handle case)
򐂰 Lives with household (Y)
򐂰 Can live alone (Y)
򐂰 Medical history (Y)
򐂰 On medicine/drugs (N)
򐂰 Ongoing therapy (Y)
򐂰 Dangerous (N)
򐂰 Mental confusion (N)
򐂰 Suicidal (N)
򐂰 Truly responds to questions (Y)
򐂰 Emergency contact: (household, name, address)
򐂰 Violence-alarm household (Y) (this is Matthew, but we show no names)
򐂰 Displays family case worker: Egon
򐂰 Displays disability case worker: Betty
Fran notifies Betty to check with Mary immediately, and she informs the family
case worker Egon to initiate the next steps.
Benefits of the new process

This process can provide similar results when a school secretary calls the ASA
front desk on behalf of a teacher reporting a bruised or abused child. It can help
if neighbors are calling the ASA child protection agency because they have
observed multiple situations of domestic violence.
This system finally provides information needed by every case worker so that
he/she is much better prepared to work more efficiently in his client’s best
interest, also supporting parents, police, and community as much as possible.
The new process positions the ASA as a valuable service provider to police and
community and not as a simple data provider as before.
򐂰 It prevents information being disclosed to the police that is not really needed
in this situation.
򐂰 It initiates a proper enrollment process for a new case, providing the most
correct information and dependencies and at the same time preventing
duplication.

򐂰 It assigns responsible case workers and ensures a proper information flow.
򐂰 It initiates the right contact between the police and the responsible case
worker.
򐂰 It jump starts a new case worker team.
Be aware that the ASA will become involved in this case anyhow. Therefore it
is very beneficial for all parties to start the interactive process as soon as
possible.
5.5.2 Public housing calculating benefits

Mary talks to her case worker Ann, because she has new household members to
report and also some recommendations from other ASA branches to improve
housing conditions. She wants Ann to recalculate her benefits because she
expects to receive more money for housing due to the latest changes.
Mary has given her consent that the ASA branches can share certain data. Also,
Matthew has agreed that his data can be shared for housing benefits.
򐂰 Mary has consented to allow the housing branch to see all her
housing-related data.
򐂰 Mary has not given permission to housing to see details about her foster-son
Jim (this data is kept in the child care branch).
򐂰 Mary has not consented to allow any other branches to see her data.
Let us take a look at the housing list as Ann can see it using the business
function calculate_benefits. The detailed information in brackets ( ) is not
displayed to Ann. It is only given here for better understanding and visualization
of data access being prevented by Privacy Manager.
򐂰 Client name, address
򐂰 Household members
򐂰 Household member(s) income
򐂰 Household member(s) benefits from all ASA branches
򐂰 Qualifying housing statements from other ASA branches (recommended
accommodation data field)
The following is the housing detail list for Mary.

򐂰 Address: Manhattan, NY, 42nd Street, 19th Floor, Tel. (190) 666 9999
򐂰 Partner: Matthew, 45, approved; Egon: Lead case worker/Family service
򐂰 Children
– Jim 6
– Peter 14
– Bob 16
– Paul 17, approved; Egon: Family, Lead (for Charlie: Child care, Foster)
򐂰 Income:
– Employer: Penthouse Cleaners: $12,000 per year
– Benefits ASA Family support $8,000 per year
– Benefits ASA child care: $4,800 per year (Jim, foster parents)
– Benefits ASA disability Mary: $1,200 per year
– Benefits ASA disability Bob: $4,800 per year
– Benefits ASA child care Paul: $2,400 (foster, 50% step-son Matthew)
– Benefits ASA Unemployment Matthew: $8,000 per year (unemployment
support)
򐂰 Housing status: 3 bedrooms
– (Needed: 5 bedrooms)
򐂰 For housing from other branches:
– Mary: bigger bedroom urgently needed, Egon: Family
(Egon: Matthew acting as family father - double bedroom)
– Bob: bigger room needed, Betty: Disability
(Betty: extended room for wheelchair to fit in)
– Jim: separate room, Charlie: Child care
(Charlie: Jim suffers from abuse and attitude by Matthew)
– Paul: separate room, growing up fast, Charlie: Child care
(Charlie: suffers from violence and attitude of his stepfather)
– Peter: separate room, Dan: Juvenile
(Dan: strong violent, Charlie: violent to brothers)
Note: Ann cannot see the details why the case workers from the other
branches have requested more room, but she can read the room-statements in
the housing field for Mary. She also cannot find out how Matthew makes his
money nor what the relations between Mary, Jim, Peter, and Matthew are.
5.5.3 Enroll in recovery therapy

Mary becomes depressed and starts talking about suicide. She is stressed out
with all the difficulties she has with her children, her own disability, and also the
special care she has to give to her handicapped son Bob every day.

Her disability worker Betty becomes aware of this critical situation. She proposes
to enroll her in a recovery therapy for Heavy Duty Mothers, which would give her
relief for approximately four weeks and would help to restore her health. As
usual, available space is very limited and the enrollment time is extremely short.
Lead case worker Egon needs to pull together all personal data of Mary including
all qualifying disabilities from herself and all other household members. If
completed quickly he could submit the enrollment document with his laptop right
from Mary’s house and fulfill the enrollment time line.
Some data fields are not immediately accessible to Egon because of missing
consent from Mary to share data (child care and so on). However, since the
changing of consent has become an online process at the ASA, Mary can
change her consent online while Egon is still present at the house. This helps
Egon pull all necessary data for an enrollment right after the changes have been
made by Mary using his laptop.
Let us take a look at the list as Egon can see it using the business function
assess_case:
򐂰 Name, address
򐂰 Household member(s)
򐂰 Household member(s) occupation
򐂰 Household gross income
򐂰 Household member(s) handicaps:
– Qualifying disabilities (own, others)
– Qualifying mental health problems (own, other)
– Qualifying partner situation (unemployed, violent)
Let us take a look at the family support detail list for Mary:
򐂰 Address: Manhattan, NY, 42nd Street, 19th Floor, Tel. (190) 666 9999
򐂰 Partner: Matthew, 45, unemployed
򐂰 Children
– Jim 6, Kindergarten
– Peter 14, School
– Bob 16, School
– Paul 17, Apprenticeship
򐂰 Total persons in household: 6
– Requestee takes care of 5 persons
򐂰 Total household income: $42,000
– Requestee regularly employed: Y, employer: Penthouse Cleaners
– Last participation at a mother recovery program: 1999
򐂰 Health Status:
– Mary: Mental Health, level 3, Betty (Mental health)
(mental drugs since 1999, suicide attempt 1999, 2001)
򐂰 Disability Status
– Mary: Hearing, 50% (Mental health)
– Bob: Wheelchair, 100% (Disability service)
򐂰 Ongoing ASA treatment support for the household: temporary substitute for
mother needed
– Jim, ongoing therapy (Child care)
– Peter, difficult education (Juvenile justice)
– Bob, handicapped wheelchair (Disability service)
– Paul, special care needed (Child care)
– Matthew, home, violent (Family care)
5.5.4 Violence consultation of Mary on behalf of Peter

Peter is violent against his youngest brother Jim. Violence happens typically
when Mary is at work and is tolerated by Matthew (unemployed and violent).
Peter is also very violent at school, where he has beaten up two classmates and
has committed violence against a teacher on July 24, 2003.
Let us take a look at the data as the case worker can see it using the business
function assess_behavior:
򐂰 Client name, address
򐂰 Parental guardian
򐂰 Household member(s) violence flag
򐂰 Client behavior information
– Client home behavior
– Client school behavior
– Client named_friends
򐂰 Client named_friend behavior
The child case worker Charlie, who is responsible for Jim, asks the family case
worker Egon for help and proposes a consultation between Egon and Mary.
Mary wants to get a better understanding of Peter’s behavior in the other

environments to act in advance before the situation is getting worse for Peter.
They discuss the violence situation at school, which was not known by Mary, and
discover that Mary’s partner, Matthew, knew about it, but has not discussed the

situation with Mary. He has also hidden an alarming letter to Mary from the
principal.
Egon and Mary also discuss the possible negative influence of the friends Peter
is spending a great amount of time with.
򐂰 Mary gives the names of three of Peter’s friends to Egon: (Good, Bad, Ugly).
򐂰 The names were also given by Peter to Dan (his juvenile justice case worker),
so they are already stored in Peter’s data in the juvenile branch.
Egon can check the behavior flag of the named friends’ Juvenile Justice records
executing the function access_behavior provided by Mary’s ID. Mary’s ID also
enables the case worker to look up Peter’s data because Mary is the parental
guardian of Peter. Egon cannot see any details of the entries, because the data
has been entered by the general school case worker Scott after his session with
the school principal.
To avoid misuse, the requestor ID, date, and purpose of this request are written
to an audit log.
Here are the results being displayed after Egon’s access_behavior request:
򐂰 Good, named_friend, violence: N
򐂰 Bad, named_friend, violence: Y
򐂰 Ugly, named_friend, violence: N
Asserted IDs (not implemented in the current Siebel monitor)

Up to now we know that a case worker can check the database of assigned
clients with given privileges. Customer relations might need to look up data from
a different person who is associated with the name or an identity of an actual
client.
Let us take a look at an example. Jim’s name and medical number are explicitly
stored in the Family Support record for Mary within the data block Children
(Jim).
If a Privacy Manager rule allows an application to read Jim’s medical number, it

can check for the person on whose behalf the case worker is requesting this
data. Jim’s ID number can be asserted in addition to the requestee ID (case
worker) and sent with the application request to Privacy Manager. Privacy
Manager can allow data access if the asserted ID and the data owner (Jim)
match according to the actual rule in place.
The ASA system offers the capability to read the behavior flag of any client and
returns the violence flag if there is any evidence filled in by street case worker
Rody.
Lead case worker Egon is approved to check the ASA system for
violence_evidence but must assert Peter’s name while he is consulting Mary
(mother) before he can submit a request to check the contact-field in Peter’s
record. The request actually returns the listed names of the three juveniles that
Peter has explicitly listed.
An individual consultation between Mary and the street case worker Rody also
revealed that Peter was spending a lot of time with a gang known for small drug
deals and strong violence. Although further details are not provided, the given
answer check with case worker xyz to discuss details of contacts is good enough
for every guardian to start a discussion with the juvenile and make plans about
how to improve the situation.
Note: To prevent misuse of this function, every request to a target client is

logged for audit purposes. All details such as date and time, asserted client
name, requesting case worker ID, and purpose of the request are recorded.
5.5.5 Management assigns a case worker

For each client situation, management needs to assign a case worker. If a case
is more complex and needs to include cross-branch information, they also need
to assign a lead case worker to coordinate the ASA services for this household
and to prevent misuse by hiding client facts or information from the ASA.
Let us take a look at the data as management can see it using the business
function assign_case worker:
򐂰 Client name
򐂰 Client demographics
򐂰 Client branch IDs
򐂰 Client benefits
򐂰 Household member(s)
򐂰 Household member(s) demographics
򐂰 Household member(s) disabilities
򐂰 Ho us hold behavior flag
Management needs to see certain data of the client, including benefits that have
been requested, but also the number of household members and difficulties a
case worker may have to face when working with the household to make the best
use of the skills a case worker provides.
5.5.6 ASA privacy policy usage statements

This section introduces the privacy policy usage statements that are applicable to
our sample scenario.

򐂰 The PII data needed for various applications can consist of data from various
areas. It can be arranged hierarchically to ease definition.
In our examples, the PII data needed to perform a certain task is highlighted
in the gray boxes. To illustrate the purpose, we are using names similar to
those used for the tasks that use the PII.
򐂰 A PublicHousing Case Worker may access the data block calculate_benefits
across branches for the purpose of calculate_benefits if the case worker is in
an Assigned Client Group and the client has consented.
򐂰 A Case worker may access ParentalData from the ChildProtection
department for the purpose of assess_case if the case worker is in an
Assigned Client Group and the client has consented.
򐂰 A Case worker may access the assigned case worker from other branches if
the client has consented.
򐂰 A Case worker may access a client branch ID from other branches if the
client has consented.
򐂰 A Case worker may access client demographic data for the purpose of
assess_case, if the client last_name starts with A to F.
򐂰 A Case worker may access client demographic data for the purpose of
assess_case if the client ASA-number is between 2000 and 6000.
򐂰 A Front_Desk Case worker may access the data block evaluate_client for the
purpose of answering a police call.
򐂰 A Front_Desk Case worker may access the data block evaluate_health for the
purpose of answering a hospital call.
򐂰 A Lead case worker may access the data block client_behavior for the
purpose of assess_behavior while consulting the client’s parents.
򐂰 A Lead case worker may access the cross-branch data block assess_case for
the purpose of enroll_for_therapy if the client has consented.
򐂰 A Lead case worker may access the case_worker field for the purpose of
assign_case_worker.
򐂰 Management may access the case_worker field for the purpose of assign case
worker.
򐂰 Management may access the data block management_assessment for the
purpose of assign case worker or assign lead case worker.
򐂰 Management may access the case_worker field for the purpose of
assess_case.
򐂰 A Case worker assignment is written to the audit log if the case worker is in
assigned user group.
5.6 Implementation architecture
The ASA has an already established application environment based on Siebel.
The functions required for case management are analogous to the concepts
implemented by CRM systems. This is of course the primary function of Siebel.
So the goal of this privacy monitoring implementation is the integration of the
Tivoli Privacy Manager server and a privacy monitor into Siebel. The high-level
architecture is illustrated in Figure 5-3 on page 152.
Note: A customizable version of the Siebel monitor integration discussed in

this chapter is available from IBM Tivoli and can be obtained through your
technical IBM contact.

Siebel Web
Client
Siebel Host Privacy Manager Host
Siebel Server WebSphere WebSphere
Monitor
Reference Privacy
Exit Point
Monitor Manager
(eScript)
Database
Figure 5-3 Siebel monitor integration architecture
The main elements of the integration are as follows:

򐂰 Siebel eBusiness Applications Version 7.5.2
򐂰 IBM WebSphere Application Server Version 4.0.4 for the monitor
򐂰 Tivoli Privacy Manager Server Version 1.1
5.7 Technical implementation
This section describes the technical implementation of the Privacy Manager and
Siebel integration. Technical background information related to Siebel and the
generic privacy monitor for Siebel is also presented.
5.7.1 Siebel architecture background

Siebel is primarily a Customer Relationship Management (CRM) application
environment. It has application modules for the delivery of online automated
customer and employee service delivery. It also offers a range of modules
tailored to industry segments, such as financial and pharmaceutical.
Applications are delivered to clients via Web-based interfaces, typically a

browser. Client requests are routed through a Web server that has been installed
with the Siebel Web extensions. The Web server then forwards the request to the
Siebel Gateway server. The gateway in turn dispatches the request to one of
potentially many Siebel application servers.
Applications running on the Siebel server are built on top of the standard Siebel
architecture. A summary illustration of the Siebel application architecture is
shown in Figure 5-4 on page 154.

B ro w s e r D e s k to p C lie n t
P re s e n ta tio n L a ye r
(C o n tro ls , A p p le ts , V ie w s , S c r e e n s )
B u s in e s s O b je c ts
B u s in e s s C o m p o n e n ts
D a ta A b s tr a tio n L a ye r
D a ta b a s e
Figure 5-4 Siebel application architecture
The Siebel architecture requires that access to its stored data must follow this
sequence. The presentation layer is typically defined in terms of HTML.
Components of the presentation (for example, applets, controls, and so on) are
linked to Siebel Business Objects. The Business Objects represent major
functional areas or entities within an organization. For example, the ASA may
define a Business Object for a client case. The Business Objects are linked to
Business Components. A Business Component represents the data of major
entities within an organization. The components are composed of fields that map
to table columns managed by the data abstraction layer. A Business Component
may be used or referenced by multiple Business Objects.
External programmatic access to Siebel data is also supported. External access

is performed through Business Objects.
5.7.2 Monitor architecture background
As with all monitors, the key design decision is where to place the monitor. Based
on the Siebel server application architecture and the general principle of
monitoring close to the data, the monitor has been integrated into the Business
Component layer. The monitor design is illustrated in Figure 5-5.
Siebel Server WebSphere
Presentation Layer
(Applets, Controls, Views, Screens)
Privacy Manager
Server
Business Objects
WebSphere
Reference
Monitor
Business Components
TPM Business Servlce
Locate Storage
Component Monitor
PII Operation Locations and
QueryEvent Assistant
Values
Web
TPM Web Serivce
Data Abstration Layer Service
Proxy
Adapter
Database
Figure 5-5 Siebel monitor design
The first point to note about the monitor is that it has distributed components
executing within Siebel and WebSphere Application Server. This is required
because the detection of PII access and submission resides within a Business
Component event trigger implemented using native Siebel eScript. Instances of
Business Components allow for the registration and triggering of events when
they are accessed. A challenge for this integration is to enable the invocation of
the Java-based Reference Monitor from this eScript code. Since the PII access
and submission detection is based on Siebel event triggers, the Siebel monitor is
classified as an application exit point style of monitor.

Important: The Siebel eScript event handlers that invoke the monitor on a
given Business Component are BusComp_Query and
BusComp_WriteRecord. Use of the monitor requires customization of these
handlers by the deployer of the monitor. Examples of the customization
required are shipped with the adapter distribution.
Once detected (for example, triggered), the event handling code invokes a Siebel
Business Service. This Business Service then forwards the call onto the
Reference Monitor, which is running in a WebSphere server. SOAP/HTTP is
used to transport the calls. The SOAP invocation activates an EJB-based Web
service adapter for the Reference Monitor.
Storage location names and conditional value retrieval are performed by the
Monitor Assistant and Privacy Manager Siebel Business Service. As always with
the Reference Monitor, the Monitor Assistant is requested to obtain the values of
given storage location names identified by a master key value. The Monitor
Assistant forwards this request to the Privacy Manager Business Service via
Siebels J2C Connector. Some eScript code executing in the Business Service
interrogates the target Business Objects and Components for the required
values. The results are then returned to the Monitor Assistant and Reference
Monitor.
Enforcement strategies
Enforcement of governing privacy policy is a non-rivial task within Siebel. A
number of strategies exist for enforcement, all of which involve customized
eScript coding in the Business Component event handlers. This code must be
supplied by the installer of the monitor. Fortunately, the adapter distribution
supplies sample eScript code that may be used as the basis for the
customization. The enforcement sample code is available in query.txt. This is an
example of the type of customization required for the BusComp_Query event.
This event is triggered when a given Business Component is accessed to be
read. This event handler is the recommended location for PII access detection
because all data operations within Siebel flow through the Business Components
and the monitor models storage locations as Business Component attribute
fields.
Real-time enforcement check

Once the access has been detected, Tivoli Privacy Manager server may be
requested to perform a real-time enforcement check. This is done by invoking the
Privacy Manager Siebel Business service from the BusComp_Query event
handler. The sample eScript code extract in Example 5-1 on page 157
demonstrates this.
Example 5-1 Real-time enforcement check within BusComp_Query
// Load the Privacy Manager Business Service
var tpmSvc = TheApplication().GetService("PrivacyManager");
// access context attributes

var access = TheApplication().NewPropertySet();
// return value from Privacy Manager

var nonConformants = TheApplication().NewPropertySet();
// Set userid and purpose

with (access) {
SetProperty ("userId", loginName);
SetProperty ("applTask", applTask);
SetProperty ("bcName", bcName);
SetProperty ("timeInt", timeInt);
SetProperty ("monitorProxy", monitorProxy);
}
// Gather accessed field names and add them to the access

// context
...
// Forward the PII access to TPM

tpmSvc.InvokeMethod("piiAccess", access, nonConformants);
With enforcement check results now available from Tivoli Privacy Manager
server, the required enforcement strategy may be employed.
No enforcement
One enforcement option supported by the monitor is no enforcement. This is
done by setting var enforcementOption = 0 in the eScript declarations of the
monitored Business Component. For a detailed configuration, see IBM Tivoli
Privacy Manager for e-business Monitor Developer’s Guide, Version 1.2,
SC32-1286.
Deny all data

Another strategy for enforcement is to deny the requester access to all data if any
single monitored item is non-conformant. This is done by setting var
enforcementOption = 1 in the eScript declarations of the monitored Business
Component. The enforcement is achieved by raising an application level
exception. The code, shown in Example 5-2 on page 158, from the installed
sample code does this from the BusComp_Query event handler.

Example 5-2 Deny access to all data
/*************************************************************/
/* the non-conformant records and ids are retrieved from TPM */
/*************************************************************/
/* Deal with non-conformant accesses, if any
* the property "conformant" is "false" if there is at least one
* record's field non-conformant
**/
var conformance = nonConformants.GetProperty("conformant");
if (conformance == "false") {
if (trace == 1) {
// do some tracing
};
if (enforcementOption == 1) {
// Raise an application exception to deny access to all data
TheApplication().RaiseErrorText(“...");
};
This type of enforcement strategy is probably best suited to Siebel screens

based on a form applet. If the screen contains list applets, the enforcement
strategies discussed below are probably better suited.
Record-level enforcement
Record-level enforcement can be achieved by refining the query to exclude the
non-conformant records accessed. It is supported by the integration monitor. It
may be configured by setting var enforcementOption = 2 in the eScript
declarations of the monitored Business Component. This type of enforcement is
best suited to Siebel screens based on list applets. The idea is to remove an
entire row from the display if at least one field of the row is non-conformant. A
record is flagged as non-conformant in the conformance result property set from
the Privacy Manager Business Service. The code from the sample
BusComp_Query eScript, shown in Example 5-3, implements record-level
enforcement.
Example 5-3 Record level enforcement

svc.InvokeMethod("piiAccess", access, nonConformants);
var recordCount = nonConformants.GetChildCount();
var aRecordsNonConformant = new Array();
for (var i = 0; i < recordCount; i++) {
var record = nonConformants.GetChild(i);
var recordId = record.GetValue();
// Setup an array of strings that will help build
// a refine query statement to exclude the non conformant
// record ids, eg Id does not equal ‘123’.
aRecordsNonConformant[i] = "[Id]<>'" + ToString(recordId) + "'";
};
}
var searchst = aRecordsNonConformant.join(" AND ");
// Refine the query
this.RefineQuery();
this.SetSearchExpr(searchst);
// prevent recursion
enterEventFlag = 1;
this.ExecuteQuery();
enterEventFlag = 0;
this.ClearToQuery();
}
Field-level enforcement
Field-level enforcement requires significant setup and configuration in Siebel.
The intuitive approach would be to modify the value of the given non-conformant
field within the query event handler of the monitored Business Component.
However, this has the unfortunate effect of updating the actual value stored in the
database with the enforcement value. This behavior results because Siebel
commits updates made to a Business Component to the database.
Using calculated fields

The recommended technique implemented in the sample BusComp_Query
eScript code is based on the idea of displaying and applying enforcement to
copies of the Business Component fields. The sample code expects that the
monitored Business Component definition has been modified to include
calculated fields with a name prefix “Copy of”. Furthermore, the Siebel screens
and applets that use the monitored Business Component need to be linked to the
“Copy of” fields. The presentation components should not directly obtain the
values of the base fields of the Business Component. An example definition for
the Contact Business Component, shown in Example 5-4, helps to illustrate this.
Example 5-4 Business component definition for field level enforcement

Contact
Name
Address
Phone
...
Copy of Name
Copy of Address

Copy of Phone
...
The sample code required in BusComp_Query for field-level enforcement is

illustrated in Example 5-5.
Example 5-5 Field level enforcement for BusComp_Query

svc.InvokeMethod("piiAccess", access, nonConformants);
var recordCount = nonConformants.GetChildCount();
for (var i = 0; i < recordCount; i++) {
var record = nonConformants.GetChild(i);
var recordId = record.GetValue();
var fieldCount = record.GetChildCount();
/* Get the record Object on "this" */
var isRecord = this.FirstRecord();
while (isRecord) {
var recId = GetFieldValue("Id");
if (recId == recordId) {
for (var j = 0; j < fieldCount; j++) {
var field = record.GetChild(j);
var fieldId = field.GetValue();
var fieldName = aActiveFieldsName[fieldId];
try{
TheApplication().SetSharedGlobal("DOSUBMISSION",
"NO");
//ActivateField("Copy of " + fieldName);
SetFieldValue("Copy of " + fieldName, "XXXXXXX");
"YES");
}catch(e){
"YES");
}finally{
"YES");
}
}
}
isRecord = this.NextRecord();
}
}
}
}
}
Enforcement at presentation layer

The enforcement strategies discussed above are based on enforcement logic
located at the monitored Business Component. Another possible way to enforce
privacy policy is to hide data with custom code at the presentation layer. For
Siebel clients running in Standard Interactivity mode, it is possible to register
custom code for applet events. For example, the WebApplet_ShowControl event
allows custom code to modify the HTML generated by the Siebel Web Engine.
This technique relies on the mapping of applet controls to individual Business

Component fields within Siebel. The signature of the event is as follows:
WebApplet_ShowControl(controlName, property, mode, &HTML)
Enforcement can be achieved by setting the value of HTML to “XXXXX”, for

example. A requirement for this technique is to make the list of non-conformant
Business Component fields available to the event handler code. A possible way
to do this is to have the section of code that is responsible for real-time
enforcement checks at the Business Component,write the non-conformant field
names into a section of the application shared context. The shared context can
be read by the WebApplet_ShowControl event handler in order to perform the
enforcement.
5.7.3 Siebel setup

A benefit for ASA that is derived from using Siebel as the application platform is
that all data can be managed and accessed centrally. Each of the ASA branches
access the data from its own custom Siebel applications. These applications in
turn are linked to branch-specific Business Objects. From here, the Business
Components are shared. By default, the monitor determines the purpose from
the Business Object name that accesses a given Business Component.
However, custom code can determine purpose by alternate methods if required.
The setup is illustrated in Figure 5-6 on page 162.

Siebel Server WebSphere
Public Housing Juvenile Justice

Presentation Presentation
Privacy Manager
Server

Business Objects Business Objects
WebSphere
Business Business
Reference
Components Components
Monitor
Component Component TPM Business Servlce

QueryEvent QueryEvent
Locate Storage
Monitor
PII Operation Locations and
Assistant
Values
Web
TPM Web Serivce
Data Abstration Layer Service
Proxy
Adapter
Database
Figure 5-6 Siebel application environment setup
The monitored Business Components are described below. Note that the Copy
Of prefixed field names are defined to enable the eScript code with the
BusComp_Query event handlers to enforce privacy policy. These fields are
registered as storage locations within Tivoli Privacy Manager server and are
classified as PII.
Important: Business Component field names are registered as storage
locations by the Siebel monitor. Those locations that are classified as PII
within Privacy Manager must have a corresponding “Copy Of” prefixed name
defined within the Siebel Business Component. This is a requirement for the
recommended enforcement technique of the monitor. See discussion of
Enforcement Strategies in the previous sections.
The ASA has defined one shared Business Component that can be used to
reconcile all branch client identifiers with the global identifier for a given client.
This Business Component is shown in Example 5-6. This Business Component
will be nominated as the master Business Component in the configuration of the
monitor.
Example 5-6 Master Business Component

AsaClient
Id
HousingId
JJId
ChildProtectionId
The Business Components for Public Housing defined within Siebel are shown in
Example 5-7.
Example 5-7 Housing Business Components

HOUSING_PROPERTY
Address
PropertyId
NumberOfRooms
HOUSING_CLIENTS
AsaClientId
HousingId
PropertyId
Name
Copy Of Name
Sex
Copy Of Sex
Age
Copy Of Age
Marital Status
Copy Of Marital Status
Partner
Copy Of Partner
Occupation
Copy of Occupation

Income
Copy Of Income
PartnerOccupation
Copy of PartnerOccupation
PartnerIncome
Copy Of PartnerIncome
Assigned Caseworker
ConsentToJuvenile
ConsentToChildProtection
ApprovedNumberOfRooms
The Business Components for Child Protection defined within Siebel are shown
in Example 5-8.
Example 5-8 Child Protection Business Components

CHILD_CLIENT
AsaClientId
ChildProtectionId
Name
Copy Of Name
PreferredName
Copy Of PreferredName
Address
Copy Of Address
ParentId
FosterParentId
CaretakerId
SchoolAddress
SchoolContactName
SchoolProblemCode
AssignCaseWorker
RecommendedRoom
AliasName
Copy Of AliasName
AsaBenefitAmount
HasDisabilities
IsAbused
HasMedicalTreatments
EmergencyName
EmergencyAddress
CHILD_PARENTS
AsaClientId
ChildProtectionId
Name
Copy Of Name
Address
Copy Of Address
Age
Copy Of Age
Occupation
Copy Of Occupation
CHILD_SIBLINGS
AsaClientId
Name
Copy Of Name
Sex
Copy Of Sex
Age
Copy Of Age
School
Copy Of School
IsStep
CHILD_FOSTER_PARENTS
AsaClientId
ChildProtectionId
Name
Copy Of Name
Address
Copy Of Address
Age
Copy Of Age
Occupation
Copy Of Occupation
CHILD_CARETAKERS
AsaClientId
ChildProtectionId
Name
Copy Of Name
Address
Copy Of Address
Age
Copy Of Age
Occupation
Copy Of Occupation
The Business Components for Juvenile Justice defined within Siebel are shown
in Example 5-9.
Example 5-9 Juvenile Justice Business Components

JJ_CLIENT
AsaClientId
JJId

AssignedCaseworker
Name
Copy Of Name
PreferredName
Age
Copy Of Age
Sex
Copy Of Sex
Address
Copy Of Address
LivesAlone
Copy Of LivesAlone
HasPartner
Copy Of HasPartner
HasParentContact
Copy Of HasParentContact
AliasName
Copy Of AliasName
ParentName
Copy Of ParentName
ParentAddress
Copy Of ParentAddress
ParentMaritalStatus
Copy Of ParentMaritalStatus
ParentIsFoster
Copy Of ParentIsFoster
ParentIsCaretaker
Copy Of ParentIsCaretaker
IsAntiSocial
Copy Of IsAntiSocial
IsRude
Copy Of IsRude
IsViolent
Copy Of IsViolent
TakesDrugs
Copy Of TakesDrugs
DoesSteal
Copy Of DoesSteal
RecommendedRoom
HasActiveConvictions
Copy Of HasActiveConvictions
HasPoliceRecord
Copy Of HasPoliceRecord
GroupMemberNames
Copy Of GroupMemeberNames
JJ_CLIENT_SIBLINGS
AsaClientId
Name
Copy Of Name
Sex
Copy Of Sex
Age
Copy Of Age
School
Copy Of School
IsStep
JJ_CLIENT_ASSOCIATES
Name
Address
VisitsRegularly
The Business Components for Mental Health defined within Siebel are shown in
Example 5-10.
Example 5-10 Mental Health Business Components

MH_CLIENT
AsaClientId
MHId
AssignedCaseworker
Name
Copy Of Name
PreferredName
Age
Copy Of Age
Sex
Copy Of Sex
Address
Copy Of Address
Spouse
Copy Of Spouse
HasCareTaker
Copy Of HasCareTaker
CaretakerName
Copy Of CaretakerName
CaretakerAddress
Copy Of CaretakerAddress
IsEmployed
Copy Of IsEmployed
EmployerKnowsProblems
Copy Of EmployerKnowsProblems
EmployerContactWorker
Copy Of EmployerContactWorker
OnMedication

Copy Of OnMedication
HasMentalConfusion
Copy Of HasMentalConfusion
IsSuicidal
Copy Of IsSuicidal
CanLiveAlone
Copy Of CanLiveAlone
HasPreviousTherapies
Copy Of HasPreviousThreapies
PreviousTherapiesDetails
Copy Of PreviousTherapiesDetails
HasHealthPlan
Copy Of HasHealthPlan
HealthPlanDetails
Copy Of HealthPlanDetails
RecommendedAccomodation
MH_CLIENT_CHILDREN
AsaClientId
Name
Copy Of Name
Age
Copy Of Age
Sex
Copy Of Sex
School
Copy Of School
Problems
Copy Of Problems
IsFoster
Copy Of IsFoster
MH_CLIENT_MEDICAL_HISTORY
AsaClientId
HasDisabilities
Copy Of HasDisabilities
DisabilityDetails
Copy Of DisabilityDetails
IsAbused
Copy Of IsAbused
AbusedDetails
Copy Of AbusedDetails
IsRaped
Copy Of IsRaped
RapedDetails
Copy Of RapedDetails
HasCurrentTreatments
Copy Of HasCurrentTreatments
CurrentTreatmentsDetails
Copy Of CurrentTreatmentsDetails
HasPreviousTreatments
Copy Of HasPreviousTreatments
PreviousTreatmentsDetails
Copy Of PreviousTreatmentsDetails
The Business Components are referenced by Business Objects. The Business

Objects have been defined in terms of the search or usage purpose. Some of the
Business Objects defined within the ASA Siebel environment are:
򐂰 Police_Inquiry
򐂰 Hospital_Inquiry
򐂰 Housing_Benefits
򐂰 Therapy_Enrollment
򐂰 Violence_Prevention
򐂰 CaseWorker_Assignment
Components of the Siebel privacy monitor must be deployed within Siebel. The
primary tasks needed to deploy the monitor components into Siebel are:
1. Import the monitor project, TPM.sif, into Siebel. This will set up the
TPM_Discovery and PrivacyManager Business Services used to
communicate to and from Tivoli Privacy Manager server.
2. Complete eScript for conditional value lookup. This is done by customizing
the CustomizedTargetBcLookup function on the TPM_Discovery Business
Service.
3. Create a Web service to enable the outbound communication to Tivoli Privacy
Manager server. This is done by importing the PMRefmonEJB.wsdl definition
file into Siebel.
4. Deploy eScript into each of the monitored Business Components. This
includes:
– Defining the master key for monitoring. For the scenario, the master key
used will be AsaClientId, since this an intra-branch global identifier within
ASA. This field is present on all Business Components with ASA. This is
done by setting var bcMasterKeyField = "AsaClientId"; in the
declarations sections of the monitored Business Components.
– Adding the code from the getbcfields.txt file to the declarations section of
the monitored Business Components. This enables the monitor to
dynamically obtain the list of Business Component field names to be
monitored.
– Setting up the PII access detection eScript code in the BusComp_Query
event handler of the monitored Business Components. The template
eScript code for this is available in the query.txt file.

These tasks are documented in the IBM Tivoli Privacy Manager Siebel
eBusiness Applications Integration Guide for the monitor.
5.7.4 Monitor setup

As illustrated in Figure 5-5 on page 155, the Siebel monitor has a component
that runs within a WebSphere application server. The monitor integration guide
details the tasks required to deploy the monitor into the application server.
The monitor allows for a number of configurations and customizations via its
property files. The property files are:
򐂰 com_ibm_tivoli_integration_pm_refmon.properties
This is the set of properties that define the behavior of the Reference Monitor.
See the Reference Monitor Guide for details.
򐂰 J2EE.properties
The set of properties required by the Monitor SDK. The properties in this file
enable communication between the monitor and Tivoli Privacy Manager
server. See the Monitor Developer’s Guide for details.
򐂰 Siebel.properties
The set of properties that define the connection used by the monitor to
communicate to Siebel. See the following section.
򐂰 com_ibm_tivoli_integration_pm_siebelassist.properties
The set of properties that define how and what information is registered with
Tivoli Privacy Manager server. See the discussion below.
Siebel.properties
An example of the property configuration is shown in Example 5-11.
Example 5-11 Siebel.properties

siebel.connection.string=siebel://asasiebel752a/siebel752/SCCObjMgr_enu/asasieb
el
siebel.user.name=SMON
siebel.user.password=SMON
siebel.user.language=enu
siebel.user.encrypted=false
siebel.conmgr.txtimeout=3600
siebel.conmgr.poolsize=3
siebel.conmgr.sesstimeout=300000
siebel.conmgr.retry=5
siebel.conmgr.jce=0
The most critical items to configure in this file are siebel.user.name,
siebel.user.password, and siebel.connection.string. The user name and
password should allow read access to the Siebel Business Object Repository
and the monitored Business Components.
The connection string value is composed of names of the Siebel gateway server,
Siebel server name, Siebel object manager name, and host name of the Siebel
server. The general form of the siebel.connection.string as follows:
siebel://<gateway>:<port>/<siebel enterprise name>/<object manager
name>/<siebel server name>.
See Siebel eBusiness Application Integration Volume III for further details.
Monitor assistant properties

An example of the property file configuration used for this scenario is shown in
Example 5-12.
Example 5-12 Monitor assistant property file

# real time enforcement supported (true/false)
siebelassistant.realtimeEnforcementSupport=true
# Siebel JCA Connector Factory reference

siebelassistant.j2c.jndi.name=jca/SiebelFactory
# master key identification

siebelassistant.masterKey=AsaClient.Id
# storage location filter

siebelassistant.sLocs.filterCount=12
siebelassistant.sLocs.filter.1=HOUSING_PROPERTY
siebelassistant.sLocs.filter.2=HOUSING_CLIENT
siebelassistant.sLocs.filter.3=CHILD_CLIENT
siebelassistant.sLocs.filter.4=CHILD_PARENTS
siebelassistant.sLocs.filter.5=CHILD_FOSTER_PARENTS
siebelassistant.sLocs.filter.6=CHILD_CARETAKERS
siebelassistant.sLocs.filter.7=CHILD_SIBLINGS
siebelassistant.sLocs.filter.8=JJ_CLIENT
siebelassistant.sLocs.filter.9=JJ_CLIENT_ASSOCIATES
siebelassistant.sLocs.filter.10=MH_CLIENT
siebelassistant.sLocs.filter.11=MH_CLIENT_CHILDREN
siebelassistant.sLocs.filter.12=MH_CLIENT_MEDICAL_HISTORY
# purpose filter
siebelassistant.purpose.filterCount=4
siebelassistant.purpose.filter.1=PoliceInquiry
siebelassistant.purpose.filter.2=HospitalInquiry
siebelassistant.purpose.filter.3=HousingBenefits

siebelassistant.purpose.filter.4=TherapyEnrolment
siebelassistant.purpose.filter.5=ViolencePrevention
siebelassistant.purpose.filter.6=CaseWorkerAssignment
# custom storage location

siebelassistant.sLocs.customCount=0
# custom purpose
siebelassistant.purpose.customCount=0
The master key is nominated as the client identifier field of the AsaClient
Business Component.
The storage locations are limited to the Business Components described for the
scenario. The storage location filter helps to narrow the components and their
fields that need to be monitored.
The purpose filter has been used to limit the number of Business Objects that the
monitor needs to interrogate for applTask registration. The Business Object
names listed in the configuration file are those that reference the monitored
Business Components named in the storage location filters.
5.7.5 Tivoli Access Manager setup

Users and groups have been set up in the Tivoli Access Manager installation
used by the Tivoli Privacy Manager server. The users and groups reflect those
described in the scenario actors section. The pdadmin script used to populate
Access Manager is shown in Example 5-13.
Example 5-13 Access manager setup script

group create am_asa_front_desk cn=am_asa_front_desk,ou=departments,o=privacyinc
cn=am_asa_front_desk
group create am_asa_management cn=am_asa_management,ou=departments,o=privacyinc
cn=am_asa_management
group create am_asa_child_protection
cn=am_asa_child_protection,ou=departments,o=privacyinc
cn=am_asa_child_protection
group create am_asa_juvenile_justice
cn=am_asa_juvenile_justice,ou=departments,o=privacyinc
cn=am_asa_juvenile_justice
group create am_asa_public_housing
cn=am_asa_public_housing,ou=departments,o=privacyinc cn=am_asa_public_housing
group create am_asa_mental_health
cn=am_asa_mental_health,ou=departments,o=privacyinc cn=am_asa_mental_health
group create am_asa_unemployment
cn=am_asa_unemployment,ou=departments,o=privacyinc cn=am_asa_unemployment
group create am_asa_disability
cn=am_asa_disablility,ou=departments,o=privacyinc cn=am_asa_disability
group create am_asa_family_support
cn=am_asa_family_support,ou=departments,o=privacyinc cn=am_asa_family_support
user create ann cn=ann,ou=departments,o=privacyinc cn=ann sn=ann passw0rd
am_asa_public_housing
user modify ann account-valid yes
user create betty cn=betty,ou=departments,o=privacyinc cn=betty sn=betty
passw0rd am_asa_disability
user modify betty account-valid yes
user create charlie cn=charlie,ou=departments,o=privacyinc cn=charlie
sn=charlie passw0rd am_asa_child_protection
user modify charlie account-valid yes
user create dan cn=dan,ou=departments,o=privacyinc cn=dan sn=dan passw0rd
am_asa_juvenile_justice
user modify dan account-valid yes
user create egon cn=egon,ou=departments,o=privacyinc cn=egon sn=egon passw0rd
am_asa_family_support
user modify egon account-valid yes
user create fran cn=fran,ou=departments,o=privacyinc cn=fran sn=fran passw0rd
am_asa_front_desk
user modify fran account-valid yes
5.8 Conclusion
This chapter has presented a description of a generic social service
organization. We have discussed some of the privacy-related challenges that
confront such organizations when they wish to share sensitive information about
individuals within distinct parts of the organization. The key challenge for these
organizations is to enable parts of the organization to access an individual’s
details effectively and efficiently, while respecting the personal choices and
privacy rights of the individuals. The purpose for which information is being
accessed is a primary factor in enabling information sharing.
In the particular scenario of this chapter, an integration between Siebel

eBusiness Applications and Tivoli Privacy Manager demonstrated how such
challenges can be solved at the technology level. Using Tivoli Privacy Manager,
the rich features and architecture of Siebel were enhanced to enable sharing of
an individual’s information.

6
Chapter 6. Financial provider using

multiple J2EE applications
Over the past decade, the global financial services market has experienced
sweeping changes. The industry has become more integrated, the level of
competition has increased, and new financial products continue to emerge. While
banks, securities firms, and insurance companies once represented distinct
segments of the financial services industry, these traditional classifications are
now becoming blurred.
The liberalization of financial markets in countries around the world has been a
major factor in this drive toward globalization. Banks, securities brokers, and
insurance firms can now compete in markets all over the world. The gradual
deregulation of the financial services industry within the United States has also
been an important driver for this growth. The elimination of barriers to geographic
expansion and the loosening of other regulations, such as the Glass Steagall
Act1, has paved the way for a wave of mergers among banking, insurance, and
securities firms throughout the United States.
1
The Glass-Steagall act was a 1933 United States national law separating investment banking and
commercial banking firms. It also prohibited banks from owning corporate stock. It was designed to
confront the problem that banks in the Great Depression collapsed because they held a lot of stock.
An interesting time line can be found at:
http://www.pbs.org/wgbh/pages/frontline/shows/wallstreet/weill/demise.html

Another trend that influences the industry very much is the use of the Internet.
Information technology is offering financial institutions many new channels for
interacting with consumers, and it facilitates the collection and analysis of market
data. It will be increasingly important for companies to lower transaction costs
and to keep up with market developments. Access to better financial information
is also making customers more discerning and demanding. Customers will
increasingly turn to the Internet as a convenient mode of conducting financial
transactions.
Our sample scenario involves a fictitious financial institution called Red Planet
Finance (RPF), which follows this trends. RPF as it is structured today came into
existence through mergers with corporations of the banking, insurance and
trading segments. This allows a lot of cross-selling opportunities and the
development of new financial products that are offered over the Internet.
6.1 Company structure and profile

This chapter provides an introduction to the overall structure of Red Planet
Financial (RPF) corporation, including its business profile, their current IT
architecture and infrastructure, and their medium-term business vision and
objectives.
Note: All names and references to company and other business institutions
used in this chapter are fictitious. Any match with a real company or institution
is coincidental.
RPF is one of the leading financial institutions in the United States. RPF provides
a diverse variety of financial products to its customers, including banking,
securities/commodities trading, and insurance.
The following sections describe:

򐂰 The geographical distribution of RPF
򐂰 The company organization
Note: The following sections describe the company information relevant to a

Privacy Manager implementation and are not intended to be a complete
description of the company.
6.1.1 Geographical distribution of RPF

RPF is based in New York City, with the corporate head office and the central IT
data centers in Long Island. There are RPF offices all over the United States and
Canada. All IT systems that run Web-accessible applications are centralized in
Long Island. Backup and recovery data centers are also located there. It is
planned that existing regional data centers of merged firms will be shut down and
consolidated with the central data centers in Long Island. This is part of a
company-wide applied consolidation strategy to improve business process
performance and save costs.
6.1.2 Organization of RPF

After the merger of the diverse financial institutions, RPF was reorganized. The
organization was split into three functional areas: private banking, investment
banking, and insurance. Additionally, a cross-functional customer relationship
department was established.
Besides the internal organization, the Internet presence of rpf.com was

organized according to customer needs. Different Web portals for individuals,
small businesses, private wealth management, and corporate banking were
established.
The customer relationship department is structured to build an interface between

the customer-oriented Web portals and the internal functional areas. The
following tasks are assigned to the customer relationship department:
򐂰 Offer customers new products and services that are tailored to their individual
needs.
򐂰 Analyze the customers’ needs to provide useful product information on the
Web.
򐂰 Suggest ways to improve the Web portals to allow customers to do their
financial tasks online efficiently.
6.2 Current architecture

In this section we describe the current IT environment at RPF. We discuss:
򐂰 The Web-based application infrastructure
򐂰 The site map of the customer Web portal
򐂰 The site map of the employee Web portals
򐂰 Application scenarios
򐂰 Privacy issues
6.2.1 Overview of the Web-based application infrastructure

The IT application infrastructure of RPF moved to Web-based applications with
different applications for the functional areas of private banking, investment
Chapter 6. Financial provider using multiple J2EE applications 177

banking and insurance. Basically all applications use Java technology on
application servers connected to back-end mainframe and database systems.
6.2.2 Outline of the customer Web portals

From the rpf.com home page, customers can access different Web portals
targeted to a special customer category. Individuals go to the private-banking
individual Web portal, which provides the following services:
򐂰 Money transfer
򐂰 Checking
򐂰 Saving
򐂰 Debit/credit cards
򐂰 Investments and funds transfer
򐂰 Auto financing
򐂰 Education financing
򐂰 Mortgage and home financing
򐂰 Home/auto/life insurance
Small business owners go to the private-banking SMB Web portal, which

provides the following services:
򐂰 Business checking
򐂰 Credit
򐂰 Leasing
򐂰 Business credit card
򐂰 Foreign exchange
򐂰 Payroll service
򐂰 Casualty/property insurance
򐂰 Savings
򐂰 Investments
򐂰 Web-selling e-business tools
Customers with a Private Wealth Management account go to the private-banking

PWM Web portal, which provides the following services:
򐂰 Investments management
򐂰 Foreign currency management
򐂰 Individual financial solutions
򐂰 Property management
򐂰 Real estate management
򐂰 Financial research
Corporate customers go to corporate banking Web portal, which provides the

following services:
򐂰 Corporate finance
򐂰 Global trade
򐂰 Risk management
򐂰 Cash management
򐂰 Commodities
򐂰 International business
򐂰 Financial research
6.2.3 Outline of company-internal financial applications

From the intra-rpf.com intranet page, employees can access different Web
portals targeted to their daily operational tasks. The following are examples of
finance applications the employees use. Banking employees go to the banking
Web portal, which provides the following services:
򐂰 Customer data and identity management
򐂰 Checking account management
򐂰 Savings account management
򐂰 Auto loans account management
Investment banking employees go the investment banking Web portal, which

provides the following services:
򐂰 Investment bank account management
򐂰 Investment research
Insurance employees go the insurance Web portal, which provides the following
services:
򐂰 Term life insurance management
򐂰 Auto insurance management
6.2.4 Current shortcomings

This section describes the current shortcomings in RPF as they are seen from a
customer’s point of view and from the business view.
Customer’s view
Since the merger, the customers are no longer aware how their data is shared in
the global finance corporation. It is also not clear to them which rules apply to the
consent they have given to one or more of the pre-merger companies. The
customers now need a single point of contact where they can define and modify
their consent for all the data that is stored by RPF.

Business view
From RPF‘s point of view, one of the most important advantages of the merger
was to leverage the customer data and make use of cross-selling opportunities.
Since customers are becoming more sensitive about their personal data, these
issues need to be addressed to maintain the customers’ trust. Customer data
should be shared only with the consent of the customer. An ability to collect this
consent and then leverage the data is needed.
Also, because all the finance applications are Web-based and easily accessible,
company-internal privacy policies need to be defined and implemented to assure
that employees access only the data they need for their daily work. Otherwise,
data could be used for unintended purposes.
On the other hand, where reasonable and consent from the customer is given,
financial applications should share common data to offer better service and
products to the customers. For example, if a customer of the insurance
department is opening a bank account, his already collected general personal
data and his identity data could be used to process the task faster and more
conveniently.
6.2.5 Privacy issues

As a consequence of the new company organization, the new IT architecture,
and the changes in the sensitivities of customers concerning privacy, the
following facts raise privacy issues that need to be addressed:
򐂰 Easily accessible Web applications
򐂰 More employees get intranet access to more data
򐂰 Upcoming new laws and regulations
򐂰 Presence in a global market means different data protection laws can be
applied
In the following sections these privacy issues are explained in detail.
Easily accessible Web applications

Since existing applications were converted to Web applications, they can be
accessed more easily by employees, customers and partners. Privacy policy
rules for legacy applications were hardcoded in the computer programs before.
The compliance with privacy policy rules now have to be enforced for Web
applications as well.
More employees get intranet access to more data

Through the merger of the distinct financial businesses, more and more
employees from different departments with different interests can access data
with privacy-sensitive content. The company privacy policy needs to be refined
and detailed to address these new facts in order to maintain customers’ trust.
Upcoming new laws

Upcoming new laws to protect data privacy and more restrictions on the handling
of sensitive data influence how data is stored and accessed by employees,
customers, and partners. A flexible way to enforce quickly changing privacy
policies is needed.
Global market presence

Globally acting companies have to cope with different data-protection and
privacy rules in different countries, and different state-level rules exist even within
one country.
6.3 Corporate business vision and objectives

Traditionally the banking business has a lot to do with trust. Basically banking is
trust. A customer brings his savings only to a bank that he deems trustworthy.
Only employees the customer trusts should have access to certain
personal-sensitive data. This has not changed in an e-business banking world.
The following sections describe RPF‘s vision, objectives, and corporate privacy
policy.
6.3.1 Business vision

RPF has already implemented its internal operational systems used by
employees as Web-based applications. For customers, a set of online banking
functions is available through Web portals. This application infrastructure is
flexible to adjust to new market requirements, it scales well, is reliable, and can
be moved to places were operational costs are low.
Caused by the merger of private banking, investment banking, and insurance a

vast amount of customer-related data is available and can be analyzed, mined,
and used to offer customers better service.
RPF sees trust as the basis for any customer relationship. Therefore, the
customers’ privacy needs to be respected and handled individually.
To establish and maintain trust, extensive logging and reporting will help to
answer any questions raised by the customers and to satisfy any audit by
company-internal controlling or government agencies.

The following objectives are the result of these business visions.
6.3.2 Objectives
RPF wants to do everything possible to assure the customers’ trust in RPF. In
order to reach this goal, RPF wants to give its customers any option to let them
decide how their personal data is used and exchanged. The privacy policy
statements on Web sites should be given more than lip service; they have to be
implemented in real operational systems.
RPF wants to deploy a corporate privacy management solution to be operated

efficiently and correctly following the corporate privacy policy and the options
chosen by the customer.
The privacy management solution should cover all Web-based banking

applications that are used by employees, customers, and partners. All
applications need to be monitored to check if data is accessed and exposed in
compliance with privacy policies.
Logging and reporting functions must be used to record any data item accessed
by employees, customers, or partners.
The privacy management solution need to be flexible, so that any changes in

privacy policies can be adjusted quickly. Also, any new privacy policy arising from
new laws and regulations should be implementable quickly.
6.3.3 Corporate privacy policy

RPF as a forward-thinking company wants to let its customers know what is
being done with their data. For this reason RPF has defined a very
customer-friendly privacy policy. The aim of the RPF privacy policy is to establish
a trust relationship with their customers. RPF is aware of privacy issues and
respects the privacy of its customers.
RPF collects personal data to offer its customers individual banking solutions and
products tailored to the customer’s need. RPF also wants to offer its customers
product information that can be of interest for the customer. However, whenever
personal data is collected the customer is informed.
In the corporate privacy policy, RPF states which RPF companies and which
customers are covered by the privacy policy. RPF gives its customers choices
about how personal data is shared between RPF companies and with external
companies. The customers have options down to the data element. For certain
businesses, RPF has defined special privacy policies.
RPF has developed a Web page where customers can give their consent to
certain data-handling and data-sharing tasks.
6.3.4 Expected benefits

Privacy policy rules for legacy applications were hardcoded in the computer
programs before. Whenever the privacy policy rules changed (for example a law
changed), the application code had to be adapted. RPF expects that the privacy
management solution provides a more flexible way to implement privacy policy
rules quickly and efficiently.
The RPF company-internal privacy policy was difficult to implement because

legacy applications were running on different systems and did not have a
common user interface. Company-internal policies had to be enforced in a
labor-intensive process, involving many administrators defining the access rights
for certain employees. Now since all legacy applications share a common
front-end based on Web application technology, such as servlets and JSPs, the
company-internal privacy policy can be enforced at this Web-based interface.
The privacy management solution should be able to interface at the common GUI
to enforce the privacy policy. It is expected that the existing Web-based
applications do not need to be changed to enable privacy.
At present, the RPF customers do not have the possibility to choose from options
defining which data items can be exchanged inside RPF and outside RPF to
partners. The new privacy management solution must provide these options to
the customers.
6.4 Project layout and implementation

Based on the corporate business vision, RPF has decided to implement a
solution with IBM Tivoli Privacy Manager using the Declarative Privacy
Monitoring (DPM) method in the RPF Privacy Enablement Project.
The Declarative Privacy Monitoring method is a semi-automated procedure to

define Privacy Manager monitors and record consent to policies. Monitors control
that certain privacy policies are adhered to when data is accessed. The method
is named Declarative Privacy Monitoring because the applications that need to
be privacy-enabled do not need to be changed. Instead, all details about
intercepting a data-access routine for privacy-monitoring reasons are declared in
a configuration file. Thus all privacy rules for all applications of a company that is
running a certain application server environment are defined at a central point.
This definition is done in an XML file using syntax that must adhere to the
declarative monitor XML schema.

The applications that need to be privacy-enabled must be analyzed, data
elements for monitoring need to be identified, and the monitors need to be
declared in an XML file. Technical details about the implementation are
described in 6.8, “DPM monitor technical implementation” on page 208.
The DPM solution is implemented in three phases, as described in the following

sections.
6.4.1 Phase 1: Privacy policy design

This phase contains the definitions necessary to implement privacy policies.
Note: The phase of privacy policy design applies not only to this particular
DPM solution but is common to all Tivoli Privacy Manager for e-business
implementations.
Phase 1 is split into two separate tasks:

򐂰 Phase 1A
We define the privacy policy independently of the applications by describing
data categories and purposes relevant to the business and legal
requirements. The Tivoli Privacy Manager for e-business console is used to
define these policies. These policies can later be published on a Web page for
public reference.
򐂰 Phase 1B
The application is analyzed for data items that need to be monitored and
tasks that are performed. This information is edited into the privacy descriptor
XML file.
The Tivoli Privacy Manager for e-business console is used to map between
the monitored items of the application and tasks of the application and the
privacy policy categories and purposes.
The follwing are parts of the complete phase 1:

1. Definition of the privacy policies as they appear on a Web page.
2. Definition of data elements where the customers can choose how these data
elements can be shared between RPF departments.
3. Definition of data elements that can be shared by RPF departments and
purpose of use, according to RPF-internal regulations.
4. Identification of applications (defines the purpose) that access data elements
defined above.
5. Identification of job roles that use the above-defined applications.
6. Grouping of employees who take on the above job roles.
7. Definition of a report compilation schedule.
The deliverables of this phase are:

򐂰 Privacy policy
򐂰 Company-internal data-sharing policies
򐂰 Privacy policy design document with:
– List of customer opt-in data elements
– List of RPF exchangeable data elements
– List of applications
– List of job roles
– List of job groups
– Report compilation schedule
6.4.2 Phase 2: Monitor descriptors

Based on the output of phase 1, the monitor descriptors in the XML file are done.
The following are the contents of the XML file:
Monitor Definition Defines the monitor name, key of the subject, group
items to be monitored, the items themselves, and an
item description.
Task Definition Defines tasks that are performed by the various
components of the application. Tasks are mapped to
purposes using the Tivoli Privacy Manager for
e-business console.
Identity Setup Point Defines where the identity information comes from.
Task Setup Point Specifies which components perform which task.
Operation Point Specifies which components perform which operations
on privacy-sensitive data.
The deliverable of this phase is the declarative XML file.
6.4.3 Phase 3: Implementation

In this phase, the privacy rules are deployed in the Privacy Manager server, the
plug-in classes for the operation point descriptors are written, and the declarative
XML file is deployed to the WebSphere Application Server.
The application must be started before the Tivoli Privacy Manager for e-business
console can be used to map the privacy policy to the monitors defined in the
privacy descriptor XML file.

The deliverables of this phase are the running and tested privacy-enabled
Web-based J2EE applications.

This section describes real-world scenarios in the global financial institution with
the new possibilities to provide all-embracing support for their customers. The
section is partitioned according to the view of customers, the diverse
banking//trading departments, and the customer relationship department. The
benefits for each groups are also listed.
6.5.1 Customer’s view

Let us take a closer look at the scenarios and the customer benefits.
Scenario
The customers should be given the possibility to choose if the following
personally identifiable information (PII) can be shared among RPF’s
departments:
򐂰 General personal data (first name, initial, last name, birthday, birthplace, sex)
򐂰 Identity (identity card number, passport number, driver’s license number,
social security number, address, phone number)
򐂰 Bank data for bank giro/checking accounts (balance, monthly statement,
record of money transfers)
򐂰 Bank data for saving accounts (balance, interest rate)
򐂰 Bank data for loans (balance, monthly payments, interest rate)
򐂰 Insurance data for term life insurance (insurance sum)
򐂰 Insurance data for auto insurance (type of insurance -
comprehensive/non-comprehensive)
򐂰 Trading data (deposit, portfolio of securities, portfolio of stocks, portfolio of
options, record of transactions)
Customer benefits
򐂰 Error-prone tasks such as data registration can be automated, and data need
be provided only once by the customer.
򐂰 Contracts can be processed faster, and customers get what they want faster.
򐂰 RPF can make offers that are tailored to the customer’s needs.
6.5.2 Banking department’s view
Let us take a closer look at the scenarios and the banking department benefits.
Scenarios
For certain purposes, the banking department wants to access the following data
elements:
򐂰 Identity data (purpose: opening of an account)
򐂰 Balance of bank giro/checking accounts (purpose: withdrawal)
򐂰 Balance of saving accounts (purpose: withdrawal)
򐂰 Credit limit of loans (purpose: checking, withdrawal)
򐂰 Insurance sum of term life insurance (purpose: provision of loans depends on
a sufficient term life insurance)
򐂰 Type of auto insurance (purpose: auto financing is only possible if car is
insured with comprehensive coverage)
򐂰 Trading account portfolio (purpose: secure loans in case of personal
bankruptcy)
Banking department benefits

򐂰 Existing identity data of new banking customer can be used, because the new
customer is already a customer of at least one of the other departments.
򐂰 Loan contracts can be closed faster because of access to insurance data
(term life insurance or auto insurance).
򐂰 Loans can be secured easier in case of personal bankruptcy.
6.5.3 Insurance department’s view

Let us take a closer look at the scenarios and the insurance department benefits.
Scenarios
For certain purposes, the insurance department wants to access the following
data elements:
򐂰 Identity data (purpose: close of new insurance agreement)
򐂰 Bank account number of bank giro/checking accounts (purpose: direct debit
after close of new insurance agreement)

Insurance department benefits
򐂰 Insurance agreements can be closed faster, because the necessary
prerequisites (such as identity, bank account number) are directly accessible.
6.5.4 Trading department’s view

Let us take a closer look at the scenarios and the trading department benefits.
Scenario
For certain purposes, the trading department wants to access the following data
elements:
򐂰 Identity data (purpose: opening of new deposit)
Trading department benefits

򐂰 Trading deals can be closed faster, because the necessary prerequisites
(such as identity, bank account number) are directly accessible.
6.5.5 Customer relationship department’s view

Let us take a closer look at the scenarios and the RPF benefits.
Scenarios
Basically the customer relationship department wants to cross-analyze customer
data to provide better customer information and to leverage cross-selling
opportunities. However, when analyzing customer data the customer relationship
department has to respect the customers defined privacy policy rules.
For certain purposes, the customer relationship department wants to access the
following data elements:
򐂰 Identity data (purpose: save customer data to cross-analyze).
򐂰 Bank data of loans (purpose: offer insurance for the new car to a bank
customer who signs an auto-financing contract).
򐂰 Bank data of savings account (purpose: offer higher earning investment
options such as securities and stocks to a bank customer who has a certain
amount of savings).
򐂰 Monthly bank statements (purpose: analyze customers’ money transfers for
trading and insurance to bank accounts of competing firms in order to offer
them the equivalent or better products of RPF).
򐂰 Trading data (purpose: if a customer’s investment strategy was not successful
and he lost money on stocks, the customer relationship department can offer
less riskier investments such as savings accounts or life insurance).
RPF benefits
Since the customer relationship department actions reach across all
departments, it benefits RPF as a whole, so this section is called RPF benefits.
򐂰 Sales can be optimized across all departments.
򐂰 Highly targeted product offers can be launched.

The functional requirements for data access to customer data and the privacy
rules that need to be applied are derived from the real-world situations described
in 6.3, “Corporate business vision and objectives” on page 181.
򐂰 A mechanism is needed to incorporate the customers’ privacy rules into Tivoli
Privacy Manager.
򐂰 General personal data and identity data need to be migrated to a separate
database that can be accessed by all finance applications.
򐂰 GUIs and Java code need to be developed to access cross-department data.
򐂰 In general, privacy monitors need to be developed and deployed to control the
defined privacy rules. In our DPM scenario, the privacy monitors are not
developed by the user, but are configured using privacy descriptor XML files
and plug-in classes.
6.6.1 Data design

This section lists the simplified database tables for RPF. The data design is
derived from the above-described scenarios. The database tables define the
personally identifiable information (PII).
The table GeneralPersonalData contains the following columns:

򐂰 Customer#
򐂰 Firstname
򐂰 Initial
򐂰 Lastname
򐂰 Birthday
򐂰 Birthplace
򐂰 Sex
򐂰 EmailAddress

The table IdentityData contains the following columns:
򐂰 Customer#
򐂰 IdentityCard#
򐂰 Passport#
򐂰 DriverLicense#
򐂰 SocialSecurity#
򐂰 Address
򐂰 PhoneNumber
The table BankCheckingAccount contains the following columns:

򐂰 Customer#
򐂰 BankCheckingAccout#
򐂰 Balance
򐂰 ReferenceRecordofTransfers
The table RecordOfTransfers contains the following columns:

򐂰 Record#
򐂰 Receiver
򐂰 DateofTransfer
򐂰 Amount
The table SavingsAccount contains the following columns:

򐂰 Customer#
򐂰 SavingsAccount#
򐂰 Balance
򐂰 InterestRate
The table AutoLoanAccount contains the following columns:

򐂰 Customer#
򐂰 AutoLoanAccount#
򐂰 Balance
򐂰 MonthlyDownPayment
򐂰 InterestRate
The table TermLifeInsurance contains the following columns:

򐂰 Customer#
򐂰 TermLifeInsuranceContract#
򐂰 InsuranceSum
򐂰 MonthlyPayment
The table AutoInsurance contains the following columns:

򐂰 Customer#
򐂰 AutoInsurancePolicy#
򐂰 Coverage
򐂰 Payment
򐂰 PaymentType
򐂰 No-claimsBonus
򐂰 Deductible
The table TradingAccount contains the following columns:

򐂰 Customer#
򐂰 TradingAccount#
򐂰 Deposits
򐂰 PortfolioStocks
򐂰 PortfolioSecurities
򐂰 PortfolioOptions
򐂰 ReferenceRecordTransactions
6.6.2 Privacy rules

In this section we describe the privacy rules that apply to a collection of finance
applications. The following rules are a subset of all rules that can be derived from
the above-described scenarios. The privacy rules are described in pseudo-code
following the general syntax:
RULE-Identifier
WHO
MAY ACCESS WHAT
FOR WHAT PURPOSE
IF CONDITIONS
RULE_END
The WHO clause refers to the groups defined in 6.5, “Business requirements” on
page 186. The MAY ACCESS WHAT clauses refer to the PII defined in 6.6.1, “Data
design” on page 189. The FOR WHAT PURPOSE and the IF CONDITIONS clauses are
self-describing.
Note: This is a simplified example where the data categories happen to

exactly match the database tables. In a real-world environment, you will
probably encounter a more complex mapping.
򐂰 Rule 1
RULE_1
WHO
Customer
MAY ACCESS WHAT
GeneralPersonalData
IdentityData

BankCheckingAccount
RecordofTransfers
SavingsAccount
AutoLoanAccount
TermLifeInsurance
AutoInsurance
TradingAccount
FOR WHAT PURPOSE
Status_Listing
IF CONDITIONS
Customer = DataOwner
RULE_END
򐂰 Rule 2
RULE_2
WHO
Customer
MAY ACCESS WHAT
IdentityData
FOR WHAT PURPOSE
Address_Update OR
PhoneNumber_Update
IF CONDITIONS
Customer = DataOwner
RULE_END
򐂰 Rule 3
RULE_3
WHO
Bank_Employees
Insurance_Employees
Trading_Employees
MAY ACCESS WHAT
IdentityData
FOR WHAT PURPOSE
Address_Update OR
PhoneNumber_Update
IF CONDITIONS
Customer_Consent
RULE_END
򐂰 Rule 4
RULE_4
WHO
Bank_Employees
MAY ACCESS WHAT
TermLifeInsurance
FOR WHAT PURPOSE
Check_if_loan_repayment_is_guaranteed
IF CONDITIONS
Customer_Consent
RULE_END
򐂰 Rule 5
RULE_5
WHO
Bank_Employees
MAY ACCESS WHAT
AutoInsurance
FOR WHAT PURPOSE
Check_full_coverage_for_auto_loan
IF CONDITIONS
Customer_Consent
RULE_END
򐂰 Rule 6
RULE_6
WHO
Insurance_Employee
MAY ACCESS WHAT
BankCheckingAccount
FOR WHAT PURPOSE
Get_BankAccountNumber_for_direct_debit
IF CONDITIONS
Customer_Consent
RULE_END
򐂰 Rule 7
RULE_7
WHO
Trading_Employee
MAY ACCESS WHAT
IdentityData OR
GeneralPersonalData
FOR WHAT PURPOSE
Open_TradingAccount_for_existing_customer
IF CONDITIONS
Customer_Consent
RULE_END
򐂰 Rule 8
RULE_8
WHO
Bank_Employee
MAY ACCESS WHAT
TradingAccount
FOR WHAT PURPOSE
Check_Portfolio

IF CONDITIONS
DataOwnerFiledPersonalBankruptcy
RULE_END
򐂰 Rule 9
RULE_9
WHO
CRM_Employee
MAY ACCESS WHAT
AutoLoanAccout (New contracts)
FOR WHAT PURPOSE
Offer_AutoInsurance
IF CONDITIONS
Customer_Consent
RULE_END
For a better understanding, look at Figure 6-1, which illustrates RULE_7.
Defined groups Defined types of PII Defined purposes
MAY ACCESS FOR PURPOSE OF
General Personal Data
Open trading
account for existing
customer
Trading Department Employees
Identity Data
Figure 6-1 Rule 7
Figure 6-2 on page 195 shows cross-department data access. This illustrates
RULE_5 and RULE_6.
Defined groups Defined types of PII Defined purposes
MAY ACCESS FOR PURPOSE OF
Manage contract
(for example: increase
insurance sum)
Term Life Insurance
Insurance Department Employees

Check if loan
repayment is
guaranteed
Manage contract (for

example: give a no-
claims bonus)
Car Insurance
Bank Department Employees
Check car insurance,
auto loans require full
coverage
Figure 6-2 Rule_5 and Rule_6
6.6.3 Risk assessment

The following sections examine what privacy risks exist in the above-described
scenario. Security risks are not considered. It is assumed that security is
implemented correctly and is working.
򐂰 Possible privacy threats are:
– Unauthorized data access by an external hacker.
– Unauthorized data access by an internal employee.
򐂰 Possible privacy weaknesses are:
– Design errors when designing privacy rules.
– Laws and regulations in privacy rules are not implemented carefully
enough.
– Translation errors when privacy policy is described in the declarative XML
file, when Declarative Privacy Monitoring is used.
– Application failures.
򐂰 Possible consequences are:
– Fines because laws or regulations are disregarded.
– Loss of customers trust and loss of business.

򐂰 Privacy recommendations:
– Careful, detailed design of privacy rules.
– Check of privacy rules from a lawyer who is a specialist in the field.
6.7 Implementation architecture for declarative privacy

The Declarative Privacy Monitoring (DPM) technology removes the need for
applications to be privacy aware by retrieving the privacy policy management
information from a declarative XML privacy descriptor file. This file includes
information on how end-user identity is determined, what business tasks are
being performed, and what personally identifiable information (PII) is accessed.
To implement this technology, the Java 2 Enterprise Edition components, namely

servlets and JSPs in the Web container, have to support the Java Servlet
Specification 2.3 or above. This version is required because the Web container
invokes a customized ServletContextListener during Web application load time,
and a customized ServletFilter whenever the specific servlet is invoked.
The invoked ServletContextListener creates the DPM monitors that are defined
in the XML privacy deployment descriptors and initializes them. Whenever the
specific servlets that are associated with the XML privacy deployment
descriptors are invoked, the ServletFilter intercepts the servlet requests and
interacts with the DPM monitors before or after the servlet or JSP execution to
enforce the privacy policies.
Note: At the time we wrote this redbook, DPM V1.1 was the available version.
In the upcoming release of DPM V1.2, privacy deployment descriptors can
also be associated with EJB component methods. WebSphere Application
Server Enterprise Edition 5.0 or later is needed to support the enforcement of
these EJB descriptors. Wherever possible, we outline differences for the
upcoming V1.2 implementation.
6.7.1 Declarative Privacy Monitoring concept

IBM has developed the DPM framework that interacts with Privacy Manager to
provide the privacy monitor services. The services include monitoring PII access,
enforcing the privacy policies and logging auditable data on execution of a servlet
(or EJB when using DPM V1.2) component method to access personal data or
perform other privacy operations. Customers need to provide the XML privacy
descriptor file and a few operational plug-in classes to develop their Web
application DPM monitors. Implementation architecture overview is shown in
Figure 6-3 on page 197. Before we explore how customers can develop DPM
monitors to observe the business model described above, we discuss a few
points that help customers to better understand this framework.
Web application call Web Module

plugin
plugin
Web Module
log / authorize
DPM
Web Container Monitor
Deployment
Descriptors Tivoli Privacy
(including Security Manager
Descriptors)
EJB Module
Privacy Deployment EJB Module

Descriptors
EJB Container
J2EE App Server
Figure 6-3 Declarative Privacy Monitoring overview
DPM monitor implementation

The DPM monitor implements the functions of creating, deploying, and
administering privacy policies, as well as checking conformance to policies and
logging auditable data on data access. Customer can modify the PrivacyMonitor
class that interacts with a privacy policy service provider product to log or enforce
data access.
Today the IBM Declarative Privacy Monitoring framework has implemented the
DPM monitor object that interacts with Privacy Manager to provide the DPM
monitor services. Thus there is no need for customers to implement their own
DPM monitor. However, if customers want to develop their own DPM monitor
class, they need to implement a subclass of PrivacyMonitor and supply the
proper monitorClassName with the value of the customer’s own DPM monitor
class name in the file monitor.properties. This file is located in the WAR archive
as WEB-INF\monitor.properties. The monitor classes are suggested to be placed
in com\ibm\dpm\impl\mymonitor (mymonitor is just an example).
Note on V1.2: In DPM V1.2, this file is located in the dpm.jar file as
com\ibm\dpm\resources\monitor.properties.

Relation between Web applications and DPM monitors
During Web application load time, the DPM ServletContextListener is invoked to
first create the PrivacyService singleton. The PrivacyService instance performs
the following functions:
򐂰 Process the XML privacy deployment descriptor file.
򐂰 Create PrivacyMonitor instances and pass them the appropriate Monitor
Definition and Task Definition privacy descriptor information.
򐂰 Save the privacy metadata that is associated with the operational privacy
descriptors (Task Setup Point, Identity Setup Point, and Operation Point) after
the XML privacy deployment descriptor file is processed. This metadata is
used by the ServletFilter in the runtime (servlets and JSPs invocation time) to
determine the following:
– The end user identity that is accessing PII data
– The business tasks that are being performed
– The accessed PII data
Since PrivacyService is created as a singleton, there is only one PrivacyService

instance per JVM. It means that multiple applications under the same Web virtual
host share the same PrivacyService instance. Thus, if different applications
declare the same DPM monitor name in their privacy deployment descriptor files,
this monitor is not created again if it already exists. The PrivacyService passes
all Monitor Definition and Task Definition descriptor information to the appropriate
PrivacyMonitor subclass. The PrivacyMonitor implementation registers or
updates monitor information with Tivoli Privacy Manager for e-business. In
summary, the PrivacyService and DPM monitors are shared by multiple Web
applications (and EJB modules — in DPM V1.2).
Relation between servlets and DPM monitors

Since Task Definition, Task Setup Point and Identity Setup Points can be
associated with more than one monitor using a monitorScope naming pattern,
servlets or JSP (or EJB in DPM V1.2) performing tasks may access data from
multiple monitors. Similarly, identity may be determined in the same manner for
multiple monitors. Therefore, the task and identity-related descriptors support a
monitorScope that can be specified in the privacy deployment descriptor.
However, monitor definition information and operation points apply to a specific
monitor. A servlet or JSP (or EJB in DPM V1.2) that accesses data from multiple
monitors would have multiple Operation Point descriptors, one for each monitor.
An example with two DPM monitors defined is shown in Figure 6-4 on page 199.
One has the name AutoInsurancePolicy and the other AutoInsurancePayment.
They contain monitored items from the auto insurance policy and auto insurance
payment databases, respectively. The viewAutoInsurance servlet is invoked to
look at details regarding a customer’s auto insurance policy and insurance
payment. It uses monitored items from both the AutoInsurancePolicy and the
AutoInsurancePayment DPM monitor. Therefore, when the servlet runs, both
monitors are called to log and enforce access to the respective items.
AutoInsurancePolicy
dskey=customer#
autoInsuran- /viewAutoInsurance
cePolicy# coverage
View customer auto insurance policy
customer# AutoInsurancePolicy#
Customer#
Coverage
AutoInsurancePayment View customer auto insurance payment

dskey=customer# Payment
Deductible
payment noclaims-Bonus
deductible
noclaims-
Bonus
Figure 6-4 Servlet and DPM monitors
Configuration
Several properties in DPM are defined in the monitor.properties file for
customizing and configuration. The monitor.properties file is located as
WEB-INF/monitor.properties in the WAR archive (in DPM V1.2, this file must be
in the CLASSPATH at com/ibm/dpm/resources/monitor.properties). The
configurable items are defined as follows:
monitorClassName Key to property object for the PrivacyMonitor
implementation class.
Default:
com.ibm.dpm.impl.sdkmonitor.SDKPrivacyMonitorImpl
logFileName Key to property object for log file name.
Default: dpm.log
loggerName Key to property object for the name of the logger.
Default: com.ibm.dpm
(In DPM V1.2, the log-related properties are located in
the file com/ibm/dpm/resources/logger.properties)
loggerClassName Key to property object for Logger implementation class.
Default: com.ibm.dpm.util.logging.JLogLogger
loggerLevel Key to property object for logging level, for example
SEVERE, WARNING, INFO, and so on.
Default: WARNING

descriptorFileName Key to property object for privacy deployment descriptor
XML file.
Default: WEB-INF/privacyConfig.xml
monitor.userid Key to properties object containing the monitor user ID.
This field is required if the key monitorClassName is
defined as default (using Privacy Manager).
monitor.password Key to properties object containing the monitor
password.
This field is required if the key monitorClassName is
defined as default (using Privacy Manager).
Required items for using DPM monitors

There are a couple of items that are required when you want to use the DPM
monitors:
򐂰 Create an XML privacy deployment descriptor file that defines the privacy
semantics of each Web application to be monitored.
򐂰 Develop plug-in classes that provide specific information about the monitored
Web applications in the runtime environment. The only required plug-in class
is the implementation of the ServletOperationInfo interface (see “Required
plug-in class - OperationInfo” on page 207). This customized plug-in class
name is specified in the <privacyOperationPoint> element in the privacy
deployment descriptor as described in “<privacyOperationPoint> element” on
page 205.
Restrictions
The DPM is designed to be used in a Web container that supports Java Servlet
Specification 2.4. It can be used in Web containers that only support Java Servlet
Specification 2.3, but with limitations. The version 2.4 specification supports the
invocation of servlet filters on a Web component method execution whether it is
either the target of the HTTP request itself, the target of a subsequent
RequestDispatcher call to another JSP, or the servlet still processing the same
request. But in version 2.3, servlet filters can only be invoked on servlets and
JSPs that are the original target of an HTTP request. To use privacy descriptors
associated with EJB component methods, WebSphere Application Server
Enterprise Edition 5.0 or later is required.
Important: Because the most current Web application platforms only support
Java Servlet Specification 2.3, the implementation of the servlet filter monitor
discussed in the following section is based on Java Servlet Specification 2.3.
This means that the DPM ServletFilter is invoked on servlets and JSPs only at
the original level of an HTTP request (for example not called using the
RequestDispatcher).
6.7.2 Declarative XML privacy deployment descriptor file
Each monitored Web or J2EE application should include an XML privacy
deployment descriptor file in each Web module that describes the privacy
semantics associated with the servlets and JSPs in that module. In addition, one
or more of these XML files can have the descriptors that describe the privacy
semantics of any EJBs used in the application. This XML privacy deployment
descriptor file is the first item required for developing DPM monitors. The entries
in the XML file are of two types: definitional and operational privacy deployment
descriptors. Let us take a closer look at these descriptors.
Definitional descriptors
The definitional descriptors are not associated with specific servlets, JSPs, or
EJBs. Rather, they may apply to any J2EE components in one or more
applications. These do not need to change just because a new component is
added to the system. However, they can be extended when new components
include additional monitor data items or perform new business tasks. Definitional
descriptors answer the following questions:
򐂰 What are the resource items that need to be monitored?
򐂰 What are the business tasks that may be performed?
Operational descriptors
Operational descriptors are associated with specific servlets, JSPs, or EJBs. The
privacy semantics of a particular component is described using these
descriptors, and answer the following questions:
򐂰 At which component method(s) should the data user identity be determined,
and how?
򐂰 At which component method(s) does a new business task begin, or what
default task should be assumed if none has been established?
򐂰 At what component method(s) do PII operations occur?
Thus, when a specific servlet, JSP, or EJB method is executed, the end user
identity, the business tasks being performed, and current accessed PIIs can be
determined.
Specify components associated with operational descriptors

To specify the servlets or JSPs to be associated to the operational descriptors,
the subelement <p:web-resource-collection> in the operational descriptor is
used. The corresponding servlets or JSPs are specified in the subelement
<p:url-pattern> of <p:web-resource-collection>. The DPM code then uses
the element <servlet-mapping> in the Web deployment descriptors (Web.xml) to
resolve the underlying servlets. To specify an EJB associated with an operation

descriptor, the subelement <p:ejb-resource-collection> is used. This holds
one or more <p:method> elements that provide the EJB name and method name.
A method name of "*" can be used to denote all the methods of the EJB.
After the operational descriptor has been processed, the DPM framework stores
the component name, method name and associated operational descriptors
(actually the descriptor metadata) in a table. Thus, when the servlet, JSP, or EJB
is executed, the DPM ServletFilter or WebSphere EJB collaborator can retrieve
the appropriate operational privacy descriptor metadata for that component
method and perform the privacy monitor services.
Again, the servlets or JSPs specification in operational descriptors are based on

Java Servlet Specification 2.4 (refer to “Restrictions” on page 200 for limitations
when using Version 2.3).
Both definitional and operational descriptors have individual elements for further
privacy semantic information. Let us take a closer look at those elements.
Definitional descriptor elements

The definitional privacy deployment descriptor elements are summarized in the
following sections.
<privacyMonitorDefinition> element
The <privacyMonitorDefinition> descriptor element defines a DPM monitor, or
adds to an existing monitor definition. The primary purpose of this descriptor is to
specify resource items that need to be monitored. These include both personally
identifiable information (PII) and other information that may be useful in the
evaluation of privacy policy conditions. Therefore, the resource items known to
the application components (includes servlets, JSPs and EJBs) being monitored
would be included here.
The grouping of monitored items into different named monitors is generally done
based on the item that should be associated with a data subject. For example,
auto insurance policy data is accessed via customer number; therefore, auto
insurance policy data is grouped in a <privacyMonitorDefinition> with the
subject key, customer number.
The <privacyMonitorDefinition> descriptor always includes the monitor name.

It may specify monitored items either as a static set of monitored item definitions,
or by naming a generator plug-in class that is called to get the list of monitored
items (see “MonitoredItemDefinitionGenerator” on page 208). This plug-in class
is called when the descriptor is processed during Web application startup. The
<privacyMonitorDefinition> descriptor must specify a data subject key that is
the name of a monitored item. This subject key is used as a master key to
retrieve the values of monitored items if necessary at runtime. The descriptor
may also specify a set of monitor attributes, which are arbitrary name/value pairs.
The monitor attributes are not used by the DPM code, but are passed to the
privacy monitor classes, which may use them for implementation specific
function.
An example of a <privacyMonitorDefinition> descriptor is shown in

<privacyTaskDefinition> element
The <privacyTaskDefinition> descriptor element defines a set of business
tasks that may be performed by the application components being monitored.
These tasks do not have to correspond to transactions or units of work in an
application; they may be conceptual. These tasks are used to determine the
purpose of a PII operation. It is up to the privacy monitor implementation and its
underlying privacy service product to provide the mapping between task and
purpose.
The <privacyTaskDefinition> descriptor always includes a monitor scope. The

monitor scope may be a monitor name or a pattern that is used to match monitor
names. In this way, tasks may be defined once but may be associated with more
than one monitor. For example, an enterprise might have a single set of task
names that encompass all their business processes. The
<privacyTaskDefinition> contains either a static list of task names or the class
name of a task name generator plug-in class (see “TaskDefinitionGenerator” on
page 208), or both. If both are specified, the task names are the combination of
static and dynamic names.
An example of a <privacyTaskDefinition> descriptor is shown in Example 6-3

on page 213.
Operational descriptor elements

The operational privacy deployment descriptor elements are summarized in the
following sections.
<privacyIdentitySetupPoint> element
The <privacyIdentitySetupPoint> element is an operational descriptor
associated with servlets or JSPs that are points at which data user identity
should be determined for use in privacy policy conformance checks. In DPM V1.2
this is renamed to <webPrivacyIdenittySetupPoint> and there is also an
<ejbPrivacyIdentitySetupPoint>. The DPM code intercepts invocations of the
associated servlets or JSPs, determines the user identity as specified in the
descriptor, and saves that user identity for use in subsequent PII operation
conformance checks. This ensures that even if this thread performs a PII
operation under some other user identity, for example, a system identity used to

access a database, the privacy conformance check uses the correct data user
identity.
The <privacyIdentitySetupPoint> element always includes a monitor scope

and the set of associated servlets or JSPs. The monitor scope can be a monitor
name, or it can be a pattern that matches one or more monitor names. In this
way, an identity point can be defined once for a set of servlets and can apply to
one or more monitors. The <privacyIdentitySetupPoint> also specifies the
source from which the user identity should be determined. This can be any of the
following:
򐂰 The current J2EE remote user
򐂰 A particular principal class of the current JAAS subject
򐂰 The value in a specified header element of the current HTTP servlet request
򐂰 The value in the specified attribute of the current HTTP session
򐂰 A value specified in the descriptor
An example of a <privacyIdentitySetupPoint> descriptor is shown in

Note V1.2: In DPM V1.2, identity setup is associated with servlets and JSPs
using <webPrivacyIdentitySetupPoint>. Identity setup can also be associated
with an EJB using a <ejbPrivacyIdentityPoint> descriptor element.
<privacyTaskSetupPoint> element
The <privacyTaskSetupPoint> element is an operational descriptor associated
with servlets or JSPs that are points at which a new business task is established,
or that provide a default business task if no task has yet been established for a
request. This task information is used to determine the purpose of subsequent
PII operations. The DPM code intercepts invocations of the associated servlets,
modifies the current business task information associated with the request, and
saves that task information for use in subsequent PII operation conformance
checks.
Note V1.2: In DPM 1.2, this element is named <webPrivacyTaskSetupPoint>

when associated with servlets and JSPs, and <ejbTaskSetupPoint> when
associated with EJBs.
The <privacyTaskSetupPoint> element always includes a monitor scope and the

set of associated servlets or JSPs. The monitor scope can be a monitor name or
it can be a pattern that matches one or more monitor names. In this way, a task
setup point can be defined once for a set of servlets or JSPs and can apply to
one or more monitors. The <privacyTaskSetupPoint> has either a
<taskModifier> subelement that provides the task name and specifies how that
should be used to modify the current business task associated with the request,
or the name of a generator plug-in class (see “TaskDefinitionGenerator” on
page 208) that provide the task name dynamically in the runtime.
An example of a <privacyTaskSetupPoint> descriptor is shown in Example 6-5

on page 214.
<privacyOperationPoint> element
The <privacyOperationPoint> element is an operational descriptor associated
with servlets or JSPs that are points at which operations on personally
identifiable information are performed. The DPM code intercepts invocations of
the associated servlets specified in this descriptor and calls the appropriate
privacy monitor classes to interact with the underlying privacy services to log PII
operations and check conformance to privacy policies.
Note V1.2: In DPM V1.2, this element is called <webOperationPoint> when

the operation is associated with servlets or JSPs, and <ejbOperationPoint>
when associated with EJBs.
The <privacyOperationPoint> element always includes a monitor name

(monitor scope not allowed) and the set of associated servlets or JSPs. Unlike
task and identity setup points, operation points are specific to a single monitor.
The <privacyOperationPoint> must specify the class name of a plug-in class
(see “Required plug-in class - OperationInfo” on page 207). This class is
responsible for providing additional operational information about the items that
are accessed by the associated servlets, the value of the data subject key (the
master key for the accessed items), and any other monitored item values
requested.
The <privacyOperationPoint> also specifies whether conformance should be

enforced, and what PII operations are performed by the servlet. If conformance
does not have to be enforced, the underlying privacy monitor services would use
a background thread to log the operation and whether it conformed with the
privacy policies. If enforcement is needed, then the privacy monitor class checks
for conformance. If an operation is non-conformant, the privacy monitor class
calls the ServletOperatioinInfo plug-in class to allow it to handle the error by
removing data from the HTTP response. If the plug-in class cannot make the
result conformant, the privacy monitor services will throw a
PrivacyCheckException.
Operations in <privacyOperationPoint> are specified using the values from the

OperationEnum type. (com.ibm.dpm.descriptors.OperationEnum is defined in the
Javadoc; see 6.7.4, “Declarative Privacy Monitoring download site” on
page 208.) The following OperationEnum values match the operations defined in

the IBM Enterprise Privacy Architecture (refer to 2.5, “The IBM Enterprise
Privacy Architecture” on page 53):
򐂰 CREATE
Creates, collects, or submits new PII.
򐂰 DELETE
Deletes PII from its persistent storage.
򐂰 UPDATE
Modifies PII values.
򐂰 ACCESS
Retrieves PII for use by the data subject of the PII.
򐂰 USE
Retrieves PII for use by a data user that is internal to the enterprise whose
privacy policies are being enforced.
򐂰 DISCLOSE
Retrieves PII for disclosure to a data user that is external to the enterprise
whose privacy policies are being enforced.
򐂰 GRANT_CONSENT
Grants consent for a specified data subject to the policies currently in force for
the specified PII.
򐂰 WITHDRAW_CONSENT
Withdraws consent for a specified data subject to the policies currently in
force for the specified PII.
For more information on how to use the correct syntax of operations in

<privacyOperationPoint>, refer to Example A-2 on page 241.
In the PrivacyMonitor implementation we map CREATE and GRANT_CONSENT

to a submission record and we map DELETE, UPDATE, ACCESS, USE, and
DISCLOSE to an access record and conformance check.
WITHDRAW_CONSENT is not handled.
Example 6-6 on page 215 is an example of a <privacyOperationPoint>

descriptor.
File creation
The XML syntax in this file must conform to the privacyDescriptors.xsd XML
schema (see Example A-3 on page 243). The default name of the XML privacy
deployment descriptor file is WEB-INF/privacyConfig.xml, located in the WAR
archive. The file name can be configured in the monitor.properties file with the
property key: descriptorFileName (see “Configuration” on page 199).
Important: If the file name is re-defined in monitor.properties, this privacy

descriptor file must be placed in the Web container class path such that it can
be found by the Web container class loader. Otherwise, the privacy monitors
cannot start because the ServletContextListener fails to initialize these
monitors at Web application startup.
6.7.3 Plug-in classes

An additional package, called com.ibm.dpm.plugins, holds the interfaces and
classes used for plug-in class development. As described previously, some
privacy descriptors allow a plug-in class name to be provided. In those cases, an
instance of the class is instantiated and called to provide information that may be
dynamically determined at runtime. All plug-in classes must extend the
MonitorPluginImpl abstract class. Proper implementation of this class ensures
that plug-in objects are singletons. Methods of the plug-in classes may throw a
PrivacyPluginException. This exception supports nesting other exceptions within
it. The details of the MonitorPluginImpl abstract class that the plug-in class must
extend, and the interfaces that the plug-in classes must implement, are provided
in the Javadoc (com.ibm.dpm.plugins package are defined in the Javadoc; refer
to 6.7.4, “Declarative Privacy Monitoring download site” on page 208).
The com.ibm.dpm.plugins package includes the following components.
Required plug-in class - OperationInfo

The only required plug-in classes for DPM are those for
<webPrivacyOperationPoint> elements and for <ejbPrivacyOperationPoint>
elements. Subclasses implement either the ServletOperationInfo or
EjbOperationInfo interface and must extend the MonitorPluginImpl abstract class.
These plug-in classes are invoked when the associated servlets or EJBs perform
the PII operations. The plug-in is called by the monitor to provide additional
operational information about the items that are accessed by the servlet, the data
subject key value, and any other monitored item values if requested.
TaskModifierGenerator
Plug-in classes can optionally be associated with <webPrivacySetupPoint> or
<ejbPrivacySetupPoint> elements. These classes return a TaskModifier object
that is used to establish the current task for an associated servlet in the runtime.
These classes implement either the ServletTaskModifierGenerator or
EjbTaskModifierGenerator interface and must extend the MonitorPluginImpl
abstract class.

TaskDefinitionGenerator
This plug-in class returns a list of task names at runtime to be defined for one or
more monitors The generator class must implement the TaskDefinitionGenerator
interface and subclass the MonitorPlluginImpl abstract class.
If specified, this generator class is instantiated and called when the

<privacyTaskDefinition> descriptor is processed at Web application startup
time.
MonitoredItemDefinitionGenerator
This plug-in class returns a list of monitored item at runtime to be defined for a
monitor.
The generator class must implement the MonitoredItemDefinitionGenerator

interface and subclass the MonitorPluginImpl abstract class. If this class is
specified, it is called when the <privacyMonitorDefinition> descriptor is
processed during Web application startup.
6.7.4 Declarative Privacy Monitoring download site

The IBM Declarative Privacy Monitoring framework and related information are
available at the IBM alphaWorks test site:
http://www.alphaworks.ibm.com/tech/dpm
This Web site provides DPM Javadoc, required Java packages, and Readme
files. It also includes a demonstration program to show how DPM code can be
used in a very generic business model. It would be good practice to download
and experience this DPM demonstration program to understand the
implementation of the auto insurance business model discussed in the following
section.
6.8 DPM monitor technical implementation

The following sections describe how to implement DPM monitors for an auto
insurance business Web application. It includes editing a P3P policy and creating
a privacy deployment descriptor XML file and the associated plug-in classes.
This sample is designed to run with DPM V1.1, which supports privacy
descriptors on servlets and JSPs. DPM V1.2 also supports privacy descriptors
for EJBs.
6.8.1 Implementation overview
In this section, an overview diagram is provided to illustrate how these DPM
monitors operate in a Java 2 Enterprise Edition environment.
To demonstrate this implementation simpler, the servlets or JSPs that display the
customer’s auto insurance data page are defined as
<url-pattern>/viewInsuranceData</url-pattern> in the <servlet-mapping>
element in Web deployment descriptors (Web.xml). The Web deployment
descriptor file resides in the WAR archive of this auto insurance Web application.
viewautoInsurance
Auto Insurance Web
application
plugin
plugin
log / authorize
AutoInsuranceP
aymentMonitor Tivoli Privacy
Deployment
Descriptors Manager
AutoInsuranceP
(including Security Web Container olicyMonitor
Descriptors)
Privacy Deployment
Descriptors
J2EE App Server
Figure 6-5 DPM monitor implementation overview
6.8.2 System setup

The following tasks have to be performed as setup:.
򐂰 Create user IDs in a local OS
– User: “customerA”
– User: “customerB”
– User: “insuranceEmployee”
– User: “banker”
򐂰 Create users and groups in Tivoli Access Manager
– User: “customer” in “CustomerGroup” group
– User: “insuranceEmployee” in “InsuranceGroup”
– User: “banker” in “BankingGroup”

6.8.3 Create a P3P policy
The first step of the implementation is to create a P3P policy that defines the
privacy semantics of displaying customer auto insurance data. Privacy
Manager’s Policy Editor GUI is used to edit this P3P policy. The PII types,
purposes, groups and associated statements that are required in this policy are
as follows:
򐂰 Add following PII types:
– autoinsurance.payment
– autoinsurance.policy
򐂰 Add following purpose:
– view-autoinsurance
򐂰 Add following groups:
– CustomerGroup
– InsuranceGroup
– BankingGroup
򐂰 Add AutoInsurancePolicy. It contains:
– PII Types:
• autoinsurance.policy
– Purpose:
• view-autoinsurance
– Groups:
• CustomerGroup with condition: must be the data owner
• InsuranceGroup
• BankingGroup
򐂰 Add AutoInsurancePayment. It contains:
– PII Types:
• autoinsurance.payment
– Purpose:
• view-autoinsurance
– Groups:
• CustomerGroup with condition: must be the data owner
• BankingGroup with condition: customer must opt-in
• InsuranceGroup
After the policy editing is completed, change the P3P policy state from “Draft” to
“Published”.
See Example A-1 on page 237 as an example of a P3P policy file.
6.8.4 Create a declarative privacy deployment descriptor XML file

The second step of implementation is to create a declarative privacy deployment
descriptor XML file that describes the privacy semantics for this auto insurance
Web application. The required descriptors are described as follows:
򐂰 <privacyMonitorDefinition> descriptor
There are two monitors defined:
– AutoInsurancePolicyMonitor
This monitor monitors the items that associate with the auto insurance
policy, for example, customer#, autoInsurancePolicy#, coverage.
– AutoInsurancePaymentMonitor
This monitor monitors the items that associate with the auto insurance
payment, for example, payment, noclaimsBonus, deductible.
򐂰 <p:subjectKeyName>
“customerNo”. This is the subject key defined for both monitors. It is used as a
master key to retrieve the values of monitored items in the runtime.
Example 6-1 shows the <privacyMonitorDefinition> descriptor for

AutoInsurancePolicyMonitor.
Example 6-1 AutoInsurancePolicyMonitor <privacyMonitorDefinition> descriptor

<p:privacyMonitorDefinition>
<p:monitorName>AutoInsurancePolicyMonitor</p:monitorName>
<p:subjectKeyName>customerNo</p:subjectKeyName>
<p:monitoredItemDefinitionGroup>
<p:monitoredItemDefinition>
<p:monitoredItemName>customerNo</p:monitoredItemName>
<p:description>Auto insurance customer number</p:description>
</p:monitoredItemDefinition>
<p:monitoredItemName>autoInsurancePolicyNo</p:monitoredItemName>
<p:monitoredItemName>currentUserid</p:monitoredItemName>
<p:monitoredItemName>coverage</p:monitoredItemName>
</p:monitoredItemDefinitionGroup>
</p:privacyMonitorDefinition>

Important: The DPM definition of a monitored item includes both PII
information and other information needed to evaluate conditions in the privacy
policy. So, in our example, customerInfoOptin and currentUserid might not
be considered PII, but they must be defined as monitored items because they
are used in evaluating privacy policy rules.
If the monitor items are retrieved from the underlying EJB JARs in the runtime,
the list of monitored items can be retrieved by naming a generator plug-in class
that will be called to get the list of monitored items at Web application load time.
For example:
<p:generatorClassName>
com.myorg.autoprivacy.AutoPolicyMonitoredItemGenerator
</p:generatorClassName>
The sample code is shown in Example 6-2.
Example 6-2 MonitoredItemGenerator plug-in class

import java.beans.BeanInfo;
import java.beans.Introspector;
import java.beans.PropertyDescriptor;
import com.ibm.dpm.descriptors.MonitoredItemDefinition;
import com.ibm.dpm.descriptors.MonitoredItemDefinitionFactory;
import com.ibm.dpm.plugins.MonitorPluginImpl;
import com.ibm.dpm.plugins.MonitoredItemDefinitionGenerator;
import com.ibm.dpm.plugins.PrivacyPluginException;
import com.ibm.dpm.util.ReadCollection;
/**
* Plug-in class that generates the monitored items corresponding to the
* properties of an AutoPolicy EJB
*/
public class AutoPolicyMonitoredItemGenerator
extends MonitorPluginImpl
implements MonitoredItemDefinitionGenerator {
/**
* Returns a collection of MonitoredItemDefintions corresponding to each
* propery of the Java Bean class specified. The name of each monitored
item is the name
* of the corresponding Java Bean property. The item description is set to
the property
* short description from the PropertyDescriptor.
*/
static public ReadCollection getBeanMonitoredItemDefinitions(String
beanClassName)
throws PrivacyPluginException {
Set items = new HashSet();
try {
Class beanClass = Class.forName(beanClassName);
BeanInfo beanInfo = Introspector.getBeanInfo(beanClass);
PropertyDescriptor[] props = beanInfo.getPropertyDescriptors();
String itemName = null;
String description = null;
MonitoredItemDefinition itemDef = null;
for (int i = 0; i < props.length; i++) {
itemName = props[i].getName();
description = props[i].getShortDescription();
itemDef =
MonitoredItemDefinitionFactory.create(itemName,description);
items.add(itemDef);
}
} catch (Exception e) {
PrivacyPluginException ppe = new PrivacyPluginException(
“Could not get properties of Java Bean class =
‘”+beanClassName+”’.”,e);
throw ppe;
}
return ReadCollectionFactory.create(items);
}
<privacyTaskDefinition> descriptor
Since there is only one task defined in this implementation, the static task name
is defined in this descriptor.
򐂰 Static task name: ViewautoInsurance.
򐂰 monitorScope: “AutoInsurance*”, so it covers both monitors defined above.
Example 6-3 shows the <privacyTaskDefinition> descriptor.
Example 6-3 <privacyTaskDefinition> descriptor

<p:privacyTaskDefinition>
<p:monitorScope>AutoInsurance*</p:monitorScope>
<p:taskName>ViewautoInsurance</p:taskName>
</p:privacyTaskDefinition>
<privacyIdentitySetupPoint> descriptor
In this implementation, the user identity is defined as the current J2EE remote
user.
򐂰 <p:url-pattern> “/viewInsuranceData”.
“/viewautoInsurance” is defined to match the URL pattern defined in the
servlet mapping in the Web deployment descriptors.
Example 6-4 shows the <privacyIdentitySetupPoint> descriptor.

Example 6-4 <privacyIdentitySetupPoint> descriptor
<p:privacyIdentitySetupPoint>
<p:userIdentitySource>J2EE</p:userIdentitySource>
<p:principalClassName></p:principalClassName>
<p:headerElementName></p:headerElementName>
<p:sessionAttributeName></p:sessionAttributeName>
<p:assertedUserIdentity></p:assertedUserIdentity>
<p:Web-resource-collection>
<p:Web-resource-name>AutoInsuranceEntryServlets</p:Web-resource-name>
<p:description>AutoInsurance http entry points</p:description>
<p:url-pattern>/viewautoInsurance</p:url-pattern>
</p:Web-resource-collection>
</p:privacyIdentitySetupPoint>
<privacyTaskSetupPoint> descriptor
Since there is only one task defined in this implementation, the static task name
is defined in this descriptor.
򐂰 Static task name: “ViewautoInsurance”
򐂰 <p:url-pattern>: /viewInsuranceData
Example 6-5 shows the <privacyTaskSetupPoint> descriptor.
Example 6-5 <privacyTaskSetupPoint> descriptor

<p:privacyTaskSetupPoint>
<p:taskModifier>
<p:taskModification>PUSH</p:taskModification>
</p:taskModifier><p:Web-resource-collection>
<p:Web-resource-name>AutoInsuranceEntryServlets</p:Web-resource-name>
</p:privacyTaskSetupPoint>
<privacyOperationSetupPoint> descriptor
This <privacyOperationSetupPoint> descriptor is specified for
“AutoInsurancePolicyMonitor” monitor.
򐂰 <p:monitorName>:“AutoInsurancePolicyMonitor”
򐂰 <p:enforcement>: ”true”
򐂰 <p:operation>: ”USE”. The monitored items are retrieved for use by a data
user.
򐂰 <p:operationInfoClassName>: See 6.8.5, “Provide privacyOperationPoint
descriptor plug-in classes” on page 215.
򐂰 <p:url-pattern>: /viewInsuranceData
Example 6-6 shows the <privacyOperationSetupPoint> descriptor for

“AutoInsurancePolicyMonitor”.
Example 6-6 AutoInsurancePolicyMonitor <privacyOperationSetupPoint> descriptor

<p:privacyOperationPoint>
<p:monitorName>
AutoInsurancePolicyMonitor
</p:monitorName>
<p:operation>USE</p:operation>
<p:enforcement>true</p:enforcement>
<p:operationInfoClassName>
com.myorg.autoprivacy.ViewPolicyActivity
</p:operationInfoClassName>
<p:Web-resource-collection>
<p:Web-resource-name>viewautoInsuranceResults</p:Web-resource-name>
</p:privacyOperationPoint>
Sample file
Example A-2 on page 241 is an example of the declarative privacy deployment
descriptor XML file.
6.8.5 Provide privacyOperationPoint descriptor plug-in classes

This plug-in class implements the ServletOperationInfo interface. See
Example 6-7.
Example 6-7 Class ServletOperationInfo

public class ViewPolicyActivity
extends MonitorPluginImpl
implements ServletOperationInfo
{
.
.
.
}
The three methods defined in the interface must be implemented in this class.
The following sections provide a sample of these methods.

getSubjectItemGroups method
Example 6-8 shows sample code of the getSubjectItemGroups method.
Example 6-8 getSubjectItemGroups method

/**
* Returns a collection containing a single SubjectItemGroup with one
data subject key
* set to the customerNo value specified in the “customerNo” request
parameters, and the names
* of monitored items corresponding to the /viewautoInsurance servlet
viewed data.
* @see
com.ibm.dpm.plugins.ServletOperationInfo#getSubjectItemGroups(ServletRequest,
ServletResponse)
*/
public ReadCollection getSubjectItemGroups(
ServletRequest request,
ServletResponse response,
String monitorName)
Set groups = new HashSet();

Set itemNames = new HashSet();
Set subjectKeys = new HashSet();
// set data subject keys

String customerNo = null;
String[] fromCustomerNo = request.getParameterValues(“customerNo”);
if (fromCustomerNo != null) {
customerNo = fromCustomerNo[0];
if (customerNo != null) {
subjectKeys.add(customerNo);
}
}
// The monitor items could be retrieve dynamically from

java.beans.Introspector
itemNames.add(“customerNo”);
itemNames.add(“autoInsurancePolicyNo”);
itemNames.add(“coverage”);
// create a SubjectItemGroup using the data subject keys and item names
SubjectItemGroup itemGroup = SubjectItemGroupFactory.create(
ReadCollectionFactory.create(subjectKeys),
ReadCollectionFactory.create(itemNames));
// put the SubjectItemGroup in a collection and return it

groups.add(itemGroup);
return ReadCollectionFactory.create(groups);
}
getItemValues method
Example 6-9 shows the getItemValues method.
Example 6-9 getItemValues method

/**
* Return the requested values of any monitored item associated with an
autoPolicy monitor
* @see com.ibm.dpm.plugins.OperationInfo#getItemValues(String, Set)
*/
public ReadMap getItemValues(
String monitorName,
String subjectKey,
ReadCollection monitoredItemNames)
Map itemMap = new HashMap();

if ((subjectKey != null) && (monitoredItemNames != null) &&
!(monitoredItemNames.isEmpty())) {
//Assume the monitor items values are from EJB jars.
//The following EJB home and remote object and JNDI name just made for
the sample....
AutoPolicyHome autoPolicyHome = null;
AutoPolicyEJB autoPolicyEJB = null;
try {
// get EJB
Context ctx = new InitialContext();
Object homeObject =
ctx.lookup(“java:comp/env/AutoPolicyRefs/AutoPolicy”);
autoPolicyHome = (AutoPolicyHome)
javax.rmi.PortableRemoteObject.narrow(
homeObject, AutoPolicyHome.class );
autoPolicyEJB = AutoPolicyHome.findByPrimaryKey(subjectKey);
// get requested item values
ReadIterator iter = monitoredItemNames.iterator();
String itemName = null;
String itemValue = null;
while (iter.hasNext()) {
itemName = (String) iter.next();
if (itemName.equals(“customerNo”)) {
itemValue = subjectKey;

itemMap.put(itemName, itemValue);
} else if (itemName.equals(“autoInsurancePolicyNo”)) {
itemValue = autoPolicyEJB.getAutoInsurancePolicyNo();
} else if (itemName.equals(“coverage”)) {
itemValue = autoPolicyEJB.getCoverage();
} else if (itemName.equals(“currentUserid”)) {
itemValue = ((HttpServletRequest)request).getRemoteUser();
}
}
}
// Determine approximate cause of failure.
catch (NamingException e) {
throw new PrivacyPluginException(“Failed getting AutoPolicyHome\n”,e);
}
catch (RemoteException e) {
throw new PrivacyPluginException(“Failed finding AutoPolicy bean\n”,e);
}
catch (Exception e) {
throw new PrivacyPluginException(“Failed getting auto Policy data
values\n”,e);
}
}//if ((subjectKey != null)
return ReadMapFactory.create(itemMap);
handleError method
Example 6-10 shows the handleError method.
Example 6-10 handleError method

/**
*blank out the non-conformance data values in the response 
* @see
com.ibm.dpm.plugins.ServletOperationInfo#handleError(ServletRequest,
ServletResponse, Map)
*/
public boolean handleError(
String monitorName,
String subjectKey,
ReadMap results)
//Assume results contain the pair of the non conformant item name, and its
value
ByteArrayOutputStream outStream =
PrivacyServiceHelper.getServletResponseByteArrayOutputStream(response);
String outString = outStream.toString();

StringBuffer buf = new StringBuffer(outString);
ReadIterator nameIter = results.getKeys();
String name = null;
int index;
int i;
int len;
String value = null;
String extendedValue = null;
while (nameIter.hasNext()) {
name = (String) nameIter.next();
value = (String) results.get(name);
extendedValue = “\”>” + value;
len = value.length();
index = 0;
// replace all occurences of the value with ‘X’ characters
while (true) {
index = outString.indexOf(extendedValue, len + index);
index = index + 2;
if (index >= 2 ) {
for (i=0; i<len; i++) {
buf.setCharAt(index+i,’X’);
}
} else {
break;
}
}
}
// replace the response
boolean returnValue = false;
outStream.reset();
try {
outStream.write((buf.toString()).getBytes());
returnValue = true;
} catch (Exception e) {
throw new PrivacyPluginException(“Failed blocking auto Policy non
conformant item data\n”,e);
}
return returnValue;
}

Important: Note that the above code might not work for every Java 2
Enterprise Edition environment. The code shown here serves only as an
example.
6.8.6 Deploy monitors in Privacy Manager

Once the privacy deployment descriptor XML file is completed, this file needs to
be placed in the WAR archive (see “File creation” on page 206). Then the auto
insurance Web application also needs to re-start to register these two monitors in
Privacy Manager. After the auto insurance Web application starts successfully,
the next step is to log on to the Privacy Manager home page and work on the
monitor deployment (use the links in the Deploy Privacy Policies section in the
Privacy Manager home page). The following sections provide the steps involved
in monitor deployment.
Classify storage locations

The monitored items defined in <p:privacyMonitorDefinition> will be registered
as storage locations in Privacy Manager. These storage locations need to be
classified first. The storage location classification should be similar to Figure 6-6
on page 220 and Figure 6-7 on page 221.
Figure 6-6 AutoInsurancePolicyMonitor storage location classification
Figure 6-7 AutoInsurancePaymentMonitor storage location classification
PII mapping
The PII mapping should look similar to Figure 6-8 on page 222 and Figure 6-9 on
page 222.

Figure 6-8 AutoInsurancePolicyMonitor PII mapping
Figure 6-9 AutoInsurancePaymentMonitor PII mapping
Condition Rule mapping
During PII mapping, if there are any condition rules that associate to the
purposes or groups, these condition rules must be mapped to the registered
storage locations. Figure 6-10 shows the mapping of data owner can see his/her
own data subject rule for the AutoInsurancePolicyMonitor monitor.
Figure 6-10 AutoInsurancePolicyMonitor condition rule mapping
For the AutoInsurancePaymentMonitor the data user/data subject rule mapping

is identical to the AutoInsurancePolicyMonitor. But the
AutoInsurancePaymentMonitor has one more rule; this is the customer opt-in
rule for the banker to see the payment information. The condition rule mapping
should look similar to Figure 6-11 on page 224.

Figure 6-11 AutoInsurancePaymentMonitor customer opt-in rule mapping
Purpose mapping
The task name defined in <p:privacyTaskDefinition> will be mapped to a
purpose in Privacy Manager. The purpose mapping should look similar to
Figure 6-12 AutoInsurancePolicyMonitor Purpose mapping
The AutoInsurancePaymentMonitor purpose mappings should be identical to the

mappings in the AutoInsurancePolicyMonitor.
Access ID mapping
In the <p:privacyIdentitySetupPoint>, the current J2EE remote user is defined
as the user identity. Thus, the users that log in to the viewautoInsurance page
would be mapped to the ID defined in Tivoli Access Manager. The access ID
mapping is shown in Figure 6-13 on page 226.

Figure 6-13 AutoInsurancePolicyMonitor access ID mapping
The AutoInsurancePaymentMonitor access ID mappings should be identical to

the mappings in the AutoInsurancePolicyMonitor.
Group mapping
The groups defined in the P3P policies need to be mapped to the Tivoli Access
Manager groups for runtime privacy policy conformance check. The Group
mappings are shown in Figure 6-14 on page 227.
Figure 6-14 P3P AutoInsurance policy group mapping
To demonstrate the implementation in a simpler way, the Choose Consent

Requirement for underlying P3P policy AutoInsurance is selected as Implicit.
Once Deploy Policy is selected (Figure 6-15 on page 228), these two monitors
are deployed and ready to monitor PII when the /viewautoInsurance page is
requested.

Figure 6-15 Deploy AutoInsurance Policy
6.8.7 Enforce privacy policies in auto insurance application

When the viewautoInsurance page is requested, the DPM servlet filter is invoked
to call these two monitors to enforce the privacy policies that we have described
above. The rules (statements in P3P) of our privacy policies consist of types of
data being accessed, groups that the accessors belonged to, and purposes of
the access. Since there is only one task-purpose mapping being defined in the
monitors, the different J2EE remote users and different PII data types would
apply to different privacy policies. The following sections describe these different
scenarios.
User customerA logs in

1. He requests the customerA auto insurance record. Since customerA is
getting his own data, all the auto insurance data and payment information is
displayed. Figure 6-16 on page 229 shows the resulting page.
Figure 6-16 CustomerA auto insurance data
2. He requests the customerB auto insurance record. CustomerA should not see
CustomerB’s auto insurance record, so all PIIs are blocked. Figure 6-17 on
page 230 shows the resulting page.

Figure 6-17 CustomerB auto insurance data (all blocked)
User customerB logs in

1. He requests the customerA auto insurance record. CustomerB should not see
CustomerA’s auto insurance, so all PIIs are blocked. Figure 6-18 on page 231
shows the resulting page.
Figure 6-18 Customer A auto insurance data (all blocked)
2. He requests the customerB auto insurance record. Since customerB is

getting his own data, all the auto insurance data and payment information is

Figure 6-19 CustomerB auto insurance data
User insuranceEmployee logs in

1. He requests the customerA auto insurance record. Since the
insuranceEmployee can see all customer auto insurance records, all data is
Figure 6-20 CustomerA auto insurance data
2. He requests the customerB auto insurance record. The scenario is the same
as above.
User banker logs in

1. He requests the customerA auto insurance record. Banker is allowed to see a
customer’s auto insurance policy, but might not be allowed to see the
customer’s auto insurance payment unless the customer has set the opt-in
choice. Since customerA has not set the opt-in choice, the banker would not
be able to see customerA auto insurance payment. Figure 6-21 on page 234
shows the resulting page.

Figure 6-21 Customer A auto insurance data (payment blocked)
2. He requests the customerB auto insurance record. Banker would see both
customerB’s auto insurance data and his payment if customerB sets the
opt-in choice. Otherwise, customerB’s payment information would also be
blocked.
6.9 Conclusion
The above sections have described how to develop the DMP monitors in a Java 2
Enterprise Edition environment. The development includes creating a declarative
privacy deployment descriptor XML file and plug-in classes, but it has no
interaction with the underlying monitored auto insurance Web application. Thus,
it demonstrates the Declarative Privacy Monitoring technology that removes the
need for applications to be privacy aware.
Part 3
Part 3 Appendixes

A
Appendix A. Declarative Privacy

Monitoring
This appendix provides the P3P policy file (in Example A-1) and the declarative
privacy deployment descriptor XML file (in Example A-2 on page 241), which are
used in the Declarative Privacy Monitoring implementation. The schema file of
the declarative privacy deployment XML descriptors is displayed in Example A-3
on page 243.
Example: A-1 Auto insurance Web application P3P policy file

<?xml version="1.0" encoding="UTF-8"?>
<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<DATASCHEMA>
<DATA-DEF name="autoinsurance.policy" short-description="Customer auto
insurance policy information"/>
<DATA-DEF name="autoinsurance.payment" short-description="Customer auto
insurance payment detail"/>
<EXTENSION optional="yes">
<DATA-SCHEMA-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<PURPOSE-SCHEMA>
<PURPOSE purposeTag="other-purpose">
<NAME>view-autoinsurance</NAME>
<DESCRIPTION>View customer auto insurance</DESCRIPTION>
</PURPOSE>
</PURPOSE-SCHEMA>
<GROUP-SCHEMA>

<GROUP recipientTag="ours">
<NAME>BankingGroup</NAME>
<DESCRIPTION>Employees of the bank , i.e. teller, manager,
etc.</DESCRIPTION>
</GROUP>
<NAME>InsuranceGroup</NAME>
<DESCRIPTION>Employees of the Insurance company, i.e.
insurance officer, manager, etc.</DESCRIPTION>
</GROUP>
<NAME>CustomerGoup</NAME>
<DESCRIPTION>Auto Insurance policy owner</DESCRIPTION>
</GROUP>
</GROUP-SCHEMA>
</DATA-SCHEMA-EXT>
</EXTENSION>
</DATASCHEMA>
<POLICY discuri="http://www.Banker2002.com/Policy"
name="AutoInsurance" opturi="http://www.Banker2002.com/UserChoice">
<POLICY-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<POLICY-VERSION>1</POLICY-VERSION>
<POLICY-DESCRIPTION>AutoInsurance policy</POLICY-DESCRIPTION>
</POLICY-EXT>
</EXTENSION>
<ENTITY>
<DATA-GROUP>
<DATA ref="#business.name">Banker2002 Credit Union</DATA>
<DATA ref="#business.department">Customer Service</DATA>
<DATA ref="#business.contact-info.postal.street">123 4th Street</DATA>
<DATA ref="#business.contact-info.postal.city">Paris</DATA>
<DATA ref="#business.contact-info.postal.stateprov">TX</DATA>
<DATA ref="#business.contact-info.postal.postalcode">12345</DATA>
<DATA ref="#business.contact-info.postal.country">USA</DATA>
<DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
<DATA ref="#business.contact-info.telecom.telephone.loccode">111</DATA>
<DATA
ref="#business.contact-info.telecom.telephone.number">123-4567</DATA>
<DATA
ref="#business.contact-info.telecom.telephone.comment">Please
don't</DATA>
<DATA
ref="#business.contact-info.online.email">contact_us@banker2002.com</DATA>
</DATA-GROUP>
</ENTITY>
<ACCESS>
<all/>
</ACCESS>
<DISPUTES-GROUP>
<DISPUTES resolution-type="service"
service="http://banker2002.com/cust_serv"
short-description="Banker2002.com Customer Service">
<LONG-DESCRIPTION>Questions regarding your account can be
directed to Banker2002.com. Contact us by email at
contact_us@banker2002.com.</LONG-DESCRIPTION>
<REMEDIES>
<correct/>
</REMEDIES>
</DISPUTES>
</DISPUTES-GROUP>
<STATEMENT>
<STATEMENT-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<DESCRIPTION>AutoInsurancePolicy</DESCRIPTION>
</STATEMENT-EXT>
</EXTENSION>
<PURPOSE>
<other-purpose required="always">view-autoinsurance: View
customer auto insurance</other-purpose>
</PURPOSE>
<RECIPIENT>
<ours>
<recipient-description>BankingGroup: Employees of the bank ,
i.e. teller, manager, etc.</recipient-description>
</ours>
<ours>
<recipient-description>InsuranceGroup: Employees of the
Insurance company, i.e. insurance officer, manager,
etc.</recipient-description>
</ours>
<ours>
<recipient-description>CustomerGoup: Auto Insurance policy
owner</recipient-description>
</ours>
<RECIPIENT-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<RECIPIENT-VALUE-EXT recipientTag="ours">
<RECIPIENT-KEY>CustomerGoup</RECIPIENT-KEY>
<CR
description="Customers can view their own information."
leftSide="data user" operation="Equal" rightSide="data
subject"/>
</RECIPIENT-VALUE-EXT>
</RECIPIENT-EXT>
</EXTENSION>
</RECIPIENT>
<RETENTION>
Appendix A. Declarative Privacy Monitoring 239

<no-retention/>
</RETENTION>
<DATA-GROUP base="">
<DATA optional="no" ref="#autoinsurance.policy">
<CATEGORIES>
<purchase/>
</CATEGORIES>
</DATA>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<STATEMENT-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<DESCRIPTION>AutoInsurancePayment</DESCRIPTION>
</STATEMENT-EXT>
</EXTENSION>
<PURPOSE>
<other-purpose required="always">view-autoinsurance: View
customer auto insurance</other-purpose>
</PURPOSE>
<RECIPIENT>
<ours>
<recipient-description>BankingGroup: Employees of the bank ,
i.e. teller, manager, etc.</recipient-description>
</ours>
<ours>
<recipient-description>InsuranceGroup: Employees of the
Insurance company, i.e. insurance officer, manager,
etc.</recipient-description>
</ours>
<ours>
<recipient-description>CustomerGoup: Auto Insurance policy
owner</recipient-description>
</ours>
<RECIPIENT-EXT xmlns="http://www.ibm.com/BTB/ALPHA/P3P">
<RECIPIENT-KEY>BankingGroup</RECIPIENT-KEY>
<CR description="Customer must opt-in"
leftSide="payment information choice" operation="Equal"
rightSide="true"/>
<RECIPIENT-KEY>CustomerGoup</RECIPIENT-KEY>
<CR
description="Customers can view their own information."
leftSide="data user" operation="Equal" rightSide="data
subject"/>
</RECIPIENT-EXT>
</EXTENSION>
</RECIPIENT>
<RETENTION>
<no-retention/>
</RETENTION>
<DATA-GROUP base="">
<DATA optional="no" ref="#autoinsurance.payment">
<CATEGORIES>
<financial/>
</CATEGORIES>
</DATA>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</POLICIES>
Example: A-2 Auto insurance Web application privacy descriptor XML file
<p:privacyDescriptors xmlns:p="http://www.ibm.com/2003/PrivacyServices"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/2003/PrivacyServices
../../../J2eePrivacyMonitor/com/ibm/dpm/resources/privacyDescriptors.xsd “>
<p:monitoredItemName>autoInsurancePolicyNo</p:monitoredItemName>
<p:monitoredItemName>coverage</p:monitoredItemName>
<p:monitorName>AutoInsurancePaymentMonitor</p:monitorName>

<p:monitoredItemName>paymentType</p:monitoredItemName>
<p:description>Type of payment, monthly or yearly</p:description>
<p:monitoredItemName>payment</p:monitoredItemName>
<p:monitoredItemName>noclaimsBonus</p:monitoredItemName>
<p:description>Bonus if no insurance claim</p:description>
<p:description>transient value set to the current Userid from the
PrivacyContext</p:description>
<p:monitoredItemName>deductible</p:monitoredItemName>
<p:monitoredItemName>customerInfoOptin</p:monitoredItemName>
<p:privacyTaskDefinition>
</p:privacyTaskDefinition>
<p:privacyIdentitySetupPoint>
<p:userIdentitySource>J2EE</p:userIdentitySource>
<p:principalClassName></p:principalClassName>
<p:headerElementName></p:headerElementName>
<p:sessionAttributeName></p:sessionAttributeName>
<p:assertedUserIdentity></p:assertedUserIdentity>
<p:web-resource-collection>
<p:web-resource-name>AutoInsuranceEntryServlets</p:web-resource-name>
</p:web-resource-collection>
</p:privacyIdentitySetupPoint>
<p:privacyTaskSetupPoint>
<p:taskModifier>
<p:taskModification>PUSH</p:taskModification>
</p:taskModifier><p:web-resource-collection>
<p:web-resource-name>AutoInsuranceEntryServlets</p:web-resource-name>
</p:privacyTaskSetupPoint>
<p:operationInfoClassName>com.ibm.banker2003privacy.ViewEmployeeActivity</p:ope
rationInfoClassName>
<p:web-resource-name>viewautoInsuranceResults</p:web-resource-name>
<p:monitorName>AutoInsurancePaymentMonitor</p:monitorName>
<p:operationInfoClassName>com.ibm.banker2003privacy.CreateAccountActivity</p:op
erationInfoClassName>
<p:web-resource-name>CreateAccount</p:web-resource-name>
</p:privacyDescriptors>
Example: A-3 Declarative privacy deployment XML descriptor schema file

<xs:schema targetNamespace="http://www.ibm.com/2003/PrivacyServices"
xmlns="http://www.ibm.com/2003/PrivacyServices"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
version="Id: PrivacyDescriptors.xsd v 0.2 2002/07/15" xml:lang="EN">
<xs:complexType name="PrivacyDescriptors">
<xs:sequence>
<xs:element name="privacyMonitorDefinition"
type="PrivacyMonitorDefinition" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="privacyTaskDefinition" type="PrivacyTaskDefinition"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="privacyIdentitySetupPoint"
type="PrivacyIdentitySetupPoint" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="privacyTaskSetupPoint" type="PrivacyTaskSetupPoint"
minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="privacyStorageActivityPoint"
type="PrivacyStorageActivityPoint" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="privacyDescriptors" type="PrivacyDescriptors"
abstract="false"/>
<xs:complexType name="Web-resource-collection">
<xs:sequence>
<xs:element name="web-resource-name" type="xs:string" minOccurs="0"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:element name="url-pattern" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="http-method" type="HttpMethodEnum" minOccurs="0"
</xs:sequence>
</xs:complexType>
<xs:simpleType name="HttpMethodEnum">
<xs:restriction base="xs:string">
<xs:enumeration value="GET"/>
<xs:enumeration value="PUT"/>
<xs:enumeration value="POST"/>
<xs:enumeration value="TRACE"/>
<xs:enumeration value="OPTIONS"/>
<xs:enumeration value="DELETE"/>
<xs:enumeration value="HEADER"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="PrivacyTaskDefinition">
<xs:sequence>
<xs:element name="monitorScope" type="xs:string"/>
<xs:element name="taskName" type="xs:string" minOccurs="0"
<xs:element name="generatorClassName" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MonitoredItemDefinition">
<xs:sequence>
<xs:element name="monitoredItemName" type="xs:string"/>
<xs:element name="description" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="TaskModifierEnum">
<xs:enumeration value="ADD_IF_EMPTY"/>
<xs:enumeration value="PUSH"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="PrivacyStorageActivityPoint">
<xs:sequence>
<xs:element name="monitorName" type="xs:string"/>
<xs:element name="submission" type="xs:boolean" minOccurs="0"/>
<xs:element name="access" type="xs:boolean" minOccurs="0"/>
<xs:element name="enforcement" type="xs:boolean" minOccurs="0"/>
<xs:element name="storageActivityInfoClassName" type="xs:string"/>
<xs:element name="web-resource-collection"
type="Web-resource-collection"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PrivacyIdentitySetupPoint">
<xs:sequence>
<xs:element name="userIdentitySource" type="UserIdentitySourceEnum"/>
<xs:element name="principalClassName" type="xs:string"
minOccurs="0"/>
<xs:element name="headerElementName" type="xs:string" minOccurs="0"/>
<xs:element name="sessionAttributeName" type="xs:string"
minOccurs="0"/>
<xs:element name="assertedUserIdentity" type="xs:string"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PrivacyTaskSetupPoint">
<xs:sequence>
minOccurs="0"/>
<xs:element name="taskModifier" type="TaskModifier" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PrivacyMonitorDefinition">
<xs:sequence>
<xs:element name="monitorName" type="xs:string"/>
<xs:element name="monitorAttribute" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

minOccurs="0"/>
<xs:element name="subjectKeyName" type="xs:string"/>
<xs:element name="monitoredItemDefinitionGroup" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="monitoredItemDefinition"
type="MonitoredItemDefinition" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="TaskModifier">
<xs:sequence>
<xs:element name="taskName" type="xs:string"/>
<xs:element name="taskModification" type="TaskModifierEnum"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="UserIdentitySourceEnum">
<xs:enumeration value="J2EE"/>
<xs:enumeration value="JAAS"/>
<xs:enumeration value="HEADER"/>
<xs:enumeration value="ASSERTED"/>
<xs:enumeration value="SESSION"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
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 248. Note that some of the documents referenced here may be available
in softcopy only.
򐂰 Enterprise Security Architecture with IBM Tivoli Solutions, SG24-6014
򐂰 LDAP Implementation Cookbook, SG24-5110
򐂰 DB2 Warehouse Management: High Availability and Problem Determination
Guide, SG24-6544
Other publications
These publications are also relevant as further information sources:
򐂰 IBM Tivoli Privacy Manager for e-business Planning Guide Version 1.1,
SC32-4789
򐂰 IBM Tivoli Privacy Manager for e-business Monitor Developer’s Guide Version
1.1, SC32-4790
򐂰 IBM Tivoli Privacy Manager for e-business Installation Guide Version 1.1,
SC32-4791
򐂰 IBM Tivoli Privacy Manager for e-business Problem Determination Guide
Version 1.1, SC32-4792
򐂰 IBM Tivoli Privacy Manager for e-business, Reference Monitor Guide, Version
1.1
򐂰 IBM Tivoli Privacy Manager for e-business Monitor Developer’s Guide,
Version 1.2, SC32-1286

Online resources
These Web sites and URLs are also relevant as further information sources:
򐂰 The Center for Democracy & Technology (CDT) Web site contains the
Briefing Materials on the European Union Directive on Data Protection:
http://www.cdt.org/privacy/eudirective/
򐂰 The OECD Web site provides many different articles on the background of
privacy guidelines:
http://www.oecd.org
򐂰 The OECD Privacy Policy Wizard can be found at:
http://cs3-hq.oecd.org/scripts/pwv3/PWPart1.htm
򐂰 The IBM Declarative Privacy Monitoring framework and related information
are available at the IBM alphaWorks test site:
http://www.alphaworks.ibm.com/tech/dpm
򐂰 The Fair Information Practices report from the Federal Trade Commission
submitted to Congress in May 2000 can be found at:
http://www.ftc.gov/reports/privacy2000/privacy2000.pdf
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
Index
A B
bean interface
access control 4
... for Reference Monitor 107
granularity 14
benchmark
standard 12
privacy 7
access ID
blood researcher 90
mapping 225
BS 7799 11
Access Manager 28, 30, 37
business layer 106
Java Runtime Environment 41
Business Process Monitor 76
WebSEAL 113
business purpose 13
access notification 117
business requirements
access/participation 8
health care environment 85
administrative users 35
human services environment 138
AIX
J2EE banking environment 186
performance considerations 49
alphaWorks 208
analyst 87 C
anonymization 82 Callout Monitor 105
Application Callout Monitor 70, 105 Chief Information Security Officer 17
application components 28 Chief Privacy Officer 16
Application Exit Point Monitor 68, 155 choice 22
application task identification 114 choice/consent 8
approval 5 class name 10
architecture classification
dedicated server 38 ... of data or information 9
enterprise server 44 classification of information 5
logical components 28 client-server application 28
physical components 38 command object 114
asserted user credentials 23 component architecture
auditor 18 dedicated server 38
auditor role 35 enterprise server 44
authentication 4, 28 high availability 46
centralized 30 IBM Enterprise Privacy Architecture 55
standard 11 logical 28
strength 91 physical 38
two-factor 92 scalability 46
authorization 28 condition rule mapping 223
centralized 30 condition rules 52
procedure 14 confidentiality 17
transaction level 23 conformance check 117–118
availability 17 consent 13, 22, 32, 89, 91, 118
awareness/notice 8 collection procedure 15
explicit 88
consent/choice 8

corporate privacy policy 182 E
credentials 11 e-business on demand 32
custodian 15 EJB component methods 196
... of data 10 emergency 88
standard 12 emergency team 89
enforcement
real-time 117
D
data enforcement on 52
access layer 106 Enterprise Java Bean container 40
access object 110, 113 enterprise server configuration 44
access object interfaces 114 eScript 155
authorization procedure 14 event triggers 155
authorization standard 14
classification 9, 17, 19, 22 F
consent standard 13 federated database 20
custodian 10 financial loss 3
handling requirements 11, 19 functional requirements
logging standard 13 health care environment 87
owner 10 human services environment 141
ownership 22 J2EE banking environment 189
ownership standard 12
data category 184
data design 189 G
general practitioner 87–88
Data Disclosure Management 24
governance
Data source connection pool size 51
privacy 5, 15
data subject
granularity 14
identification 112
group definition standard 11
database administrator 20
Database Managed Space 50
DB2 30 H
high availability 47 Health Data System
performance considerations 50 participants 87
declarative management 108 health service analyst 90
Declarative Monitor 73 high availability 46
declarative privacy monitoring 183, 196 HIPAA 37
dedicated server configuration 38 hospital 88
definitional descriptors 202 Human Resources Officer 19
de-identified data 82
dependant 88
dependent 87
I
IBM alphaWorks 208
deployment descriptors 74
IBM Enterprise Privacy Architecture 53
deployment of privacy monitor 220
component architecture 55
descriptor
IBM Tivoli Access Manager
definitional 202
see Access Manager
operational 203
IBM WebSphere Application Server
descriptorFileName 200
see WebSphere Application Server
Directory and Security Node 58
identification
disclosure management 18
standard 11
identity setup point 185, 198 DPM implementation 197
identity theft 13 high availability 48
IIOP communication 37 HIPAA 37
implementation architecture patterns 63
J2EE banking environment 196 proxy monitor 65
information classification 5 request 35
instance authorization 24 Siebel architecture 151
integrity 17 Siebel deployment 169
integrity/security 9 Software Development Kit 36, 40, 64
internal health researcher 90 XML file descriptor 185
ISO 17799 11–12 monitor.password 200
monitor.properties file 199
monitor.userid 200
J monitorClassName 199
J2EE
monitored system 34
application pattern 106
MonitoredItemDefinitionGenerator 208
deployment descriptors 74
monitoring 86
Java Servlet Specification 196, 200
MonitorPluginImpl 207
JVM maximum heap size 52
monitorScope 198
JVM starting heap size 51
L N
network protocols
LDAP
dedicated server configuration 42
replication 47
notice/awareness 8
LDAP directory 30
nurse 88
LDAP Monitor 66
liability 3
logFileName 199 O
loggerClassName 199 obligation 54
loggerLevel 199 operation point 185, 198
loggerName 199 operational descriptors 203
logging 18, 24, 196 OperationEnum values 205
logging standard 13 OperationInfo 207
logical component architecture 28 opt-in/opt-out 7–8, 56, 91
opt-inpt-out 185
ORB thread pool size 51
M owner
master key registration 113
... of data 10
Metadata Processor 67
monitor 32–33, 36, 40
Application Callout Monitor 70, 106 P
Application Exit Point Monitor 68, 155 P3P policies 36
Business Process Monitor 76 P3P policy 210, 227
communication protocol 37 P3P policy file 237
component responsibility 64 participants 87
Declarative Monitor 73 participation/access 8
declarative privacy monitoring 183, 196 password
definition 185 stolen, risk 103
deployment 220 patient 87–88
Index 251
patterns for monitor design 63 threats 103
performance wrapper 117
improve 120 XML descriptor file 196
performance considerations 48 Privacy Context object 72
physical component architecture 38 Privacy Data Handling Node 57
PII Privacy Database Server 41
access detection 156 Privacy Manager Console 34
data 150 Privacy Server 34, 40
data types 228 high availability 48
mapping 221 performance considerations 52
plug-in class 207 Privacy Service Node 58
policy privacyIdentitySetupPoint descriptor 213
corporate 3 privacyIdentitySetupPoint element 203
policy enforcement point 36 privacyMonitorDefinition descriptor 211
policy group 93 privacyMonitorDefinition element 202
practice privacyOperationPoint element 205
privacy 5 privacyOperationSetupPoint descriptor 214
practices 4 PrivacyServletContextListener 75
preferred general practitioner 87–88 PrivacyServletFilter 75
Prepared statement cache size 51 privacyTaskDefinition descriptor 213
presentation layer 106 privacyTaskDefinition element 203
privacy 28 privacyTaskSetupPoint descriptor 214
administrators 35 privacyTaskSetupPoint element 204
auditor 35 procedures 4
benchmark 7 property rights 22
centralized service 32 Protocol Adapter 67
corporate policy 182 protocols
data design 189 dedicated server configuration 42
database 36 proxy monitor 65
deny all data (Siebel) 157 purpose 13, 28, 35–36, 184, 210, 223
deployment descriptor XML file 184, 200–201, classification 20
206, 211, 241 determination (Siebel) 161
enforcement 117 mapping 224
field level enforcement (Siebel) 159
governance 5, 15
management architecture 32
R
real-time enforcement 117
management components 34
recipient category 93
management requirements 16
Redbooks Web site 248
monitor 32, 36
Contact us xiv
no enforcement (Siebel) 157
Reference Monitor 37, 65, 107
policies 41
Siebel integration 155
policy 8, 54
storage location 109
policy conformance check 37
replication
policy design 184
LDAP 47
policy usage statements 149
report definition 36
presentation layer enforcement (Siebel) 161
researcher 87
record level enforcement (Siebel) 158
residual risk 3
rules 191
retention policy 15
statement 7, 9
risk System Managed Space 50
data exposure 91
mitigation 17
risk assessment
T
task definition 185, 198
health care system 103
task setup point 185, 198
J2EE banking environment 195
TaskDefinitionGenerator 208
Role Based Access Control 12
TaskModifierGenerator 207
role definition standard 11
technical implementation
roles and responsibilities 10
health care environment 104
human services environment 153
S J2EE banking environment 208
scalability 46 Transport Adapter 66
scope of classification 10 trust relationship 15
security two-factor-authentication 92
threats 103
security/integrity 9
segmentation criteria 10
U
User Interaction Node 56
separation of duty 126
servlet specification 113
ServletContextListener 196, 207 V
ServletFilter 196 virtual storage location 112
ServletOperationInfo 200, 215
session bean
W
... for Reference Monitor 107 Web container max threads 50
Siebel WebSEAL
Access Manager setup 172 authentication 113
architecture background 153 WebSphere Application Server
deny all privacy data 157 performance considerations 50
eScript 155 server group 48
field level privacy enforcement 159 Windows
monitor deployment 169 performance considerations 49
no privacy enforcement 157
presentation layer privacy enforcement 161
purpose determination 161
record level privacy enforcement 158
Siebel.properties 170
SOAP 156
Solaris
performance considerations 49
standards 4
storage location 35, 156
classification 220
condition rule mapping 223
registration 37, 109
virtual 112
Storage System Adapter 66
submission detection 120
Support Tools Node 57
Index 253
IBM Tivoli Privacy Manager Solution Design and Best Practices
(0.5” spine)
0.475”<->0.875”
250 <-> 459 pages
Back cover ®
IBM Tivoli Privacy

Manager
Solution Design and Best Practices
Privacy policy and Conducting business today involves more and more personal
governance information of the parties involved in the transactions. This is INTERNATIONAL
discussion not limited to e-business but applies to all companies that use TECHNICAL
computer technology for business processes in order to store SUPPORT
Solution architecture data. In this era of e-business, people have become aware ORGANIZATION
that their personal information is used in multiple places and
and design
are asking questions about the whereabouts of these assets.
IBM Tivoli Privacy Manager provides an enterprise-wide
Real-life best system that enables a company to use the personally BUILDING TECHNICAL
practices identifiable information (PII) it collects according to the INFORMATION BASED ON
PRACTICAL EXPERIENCE
principles of Fair Information Practices and to monitor and
enforce its compliance with those principles. The Chief
Privacy Officer has the ability to prove what kind of PII his IBM Redbooks are developed by
company is using, where it is stored and who accessed this the IBM International Technical
data at any given time. This helps the enterprise to win the Support Organization. Experts
trust of their customers and partners. from IBM, Customers and
Partners from around the world
This IBM Redbook helps privacy and security officers as well create timely technical
as their staff to understand and implement the IBM Tivoli information based on realistic
Privacy Manager in an enterprise environment. The book scenarios. Specific
covers the design and architecture of Tivoli Privacy Manager recommendations are provided
and looks at the impact of privacy issues on an enterprise’s to help you implement IT
solutions more effectively in
policy, standards, and procedures. Three specific customer your environment.
scenarios with different business requirements and technical
implementations are discussed, ranging from a WebSphere
application to Siebel 7 integration. A more generalized topic
on Monitor patterns is also included. For more information:
ibm.com/redbooks
SG24-6999-00 ISBN 0738453056

IBM Tivoli Privacy Manager

Uploaded by

Document Information

Original Description:

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

IBM Tivoli Privacy Manager

Uploaded by

Copyright:

Available Formats

Front cover

IBM Tivoli Privacyy

Solution architecture and

Real-life best practices

IBM Tivoli Privacy Manager Solution Design and

First Edition (December 2003)

© Copyright International Business Machines Corporation 2003. All rights reserved.

Part 1. Drivers and architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Enterprise policy, standards and procedures . . . . . . . . . . . . . . 3

Chapter 2. Tivoli Privacy Manager architecture . . . . . . . . . . . . . . . . . . . . . 27

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

Part 2. Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapter 3. Monitor patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 4. Health care provider using a WebSphere application . . . . . . . 79

Chapter 5. Human Services application based on Siebel 7 . . . . . . . . . . 125

Chapter 6. Financial provider using multiple J2EE applications . . . . . . 175

Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

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

The following terms are trademarks of other companies:

IBM Tivoli® Privacy Manager provides an enterprise-wide system that enables a

Part 2, “Best practices” on page 61 discusses three specific customer scenarios

The team that wrote this redbook

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

Axel Buecker is a Certified Consulting Software I/T Specialist at the

Hai-Fun Wu is a software engineer in the Tivoli Privacy Manager development

Thanks to the following people for their contributions to this project:

Calvin Powers, John Harter, Phil Fritz, Steven Adler

Dr. Paul Ashley

Dr. Larry Ponemon, Ponemon Institute

Become a published author

We want our Redbooks™ to be as helpful as possible. Send us your comments

Part 1 Drivers and

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

Chapter 1. Enterprise policy, standards

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

ProceduresPractices ProceduresPractices Procedures Technical

Figure 1-1 Dynamics for policy, standards, practices and procedures

Corporate policy vs corporate policies:

1.1 Standards, practices and procedures

The standards are then mapped to practices and/or procedures.

The practices are descriptions of practical implementation of the standards on

The procedures document the single steps to be applied to requests, the

While the implementation of privacy practices can be achieved by using

Tip: Approval procedures are often implemented by sending e-mail or

1.2 Privacy governance

Chapter 1. Enterprise policy, standards and procedures 5

This governance program will usually be implemented by a team of people and

The privacy governance documents are developed to enhance the business

A simple analogy may help illustrate some of the basic requirements.

1.3 Privacy governance documents

Chapter 1. Enterprise policy, standards and procedures 7

1.3.2 Privacy statement

1.3.3 Information classification and control standard

Chapter 1. Enterprise policy, standards and procedures 9

1.3.4 User authentication standard

1.3.5 Role and group definition standards

Organizations that use roles tend to have a mutually exclusive approach to

Chapter 1. Enterprise policy, standards and procedures 11

1.3.6 Access control standards

1.3.7 Data ownership and custodian standard

1.3.8 Data logging standard

1.3.9 Data subject choice and consent standard