Develop and Deploy A Websphere Portal Solution

Front cover
Develop and Deploy a

Secure Portal Solution
Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Solution architecture and technologies

for a secure portal
Deploy a secure portal runtime

environment
Develop and deploy

secure portal application
John Ganci
Hinrich Boog
Melanie Fletcher
Brett Gordon
Ashwin Manekar
Normunds Saumanis
Kai Schwidder
Jonas Tingeborn
ibm.com/redbooks
International Technical Support Organization
Develop and Deploy a Secure Portal Solution

Using WebSphere Portal V5 and Tivoli Access
Manager V5.1
August 2004
SG24-6325-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page xiii.
First Edition (August 2004)
This edition applies to IBM WebSphere Portal Extend for Multiplatforms V5.0.2.1 and IBM Tivoli
Access Manager for e-business V5.1.0.2 on the Microsoft Windows platform.
© Copyright International Business Machines Corporation 2004. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Part 1. Introduction to secure portal solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Secure portal solution overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Key concepts of a secure portal solution . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Secure portal solution high level architecture . . . . . . . . . . . . . . . . . . . 5
1.2 Solution software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Runtime environment solution software . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Development environment solution software . . . . . . . . . . . . . . . . . . . 8
1.3 Target audience of redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Roles and skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 Matching redbook topics to roles and skills. . . . . . . . . . . . . . . . . . . . 11
Chapter 2. Security fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Security domain and risk management . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Source of vulnerability and intruder reconnaissance . . . . . . . . . . . . 15
2.1.2 Physical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Logical security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.4 Security policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.5 Security risk management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Method for Architecting Secure Solutions (MASS) . . . . . . . . . . . . . . . . . . 25
2.3 Security fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Public Key Infrastructure (PKI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 WebSphere Portal security model. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.3 Tivoli Access Manager security model . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.5 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.6 WebSphere Portal Credential Vault . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.7 Tivoli Access Manager Global Sign-on (GSO) . . . . . . . . . . . . . . . . . 46
Chapter 3. Architecture and topology selection. . . . . . . . . . . . . . . . . . . . . 51
© Copyright IBM Corp. 2004. All rights reserved. iii

3.1 Topology definition and operational model . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.1 Operational model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.2 Topology zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.3 Conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.1.4 Specified model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.5 Security interaction patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2 Runtime environment topology selection . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.1 Entry runtime topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2.2 Enterprise runtime topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.2.3 Extended enterprise runtime topology . . . . . . . . . . . . . . . . . . . . . . . 79
3.3 Development environment topology selection. . . . . . . . . . . . . . . . . . . . . . 81
3.3.1 Conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.3.2 Specified model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.3.3 All-in-one approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.3.4 Develop and deploy without debug . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.5 Develop, deploy, and remote debugging . . . . . . . . . . . . . . . . . . . . . 88
3.3.6 Develop using a shared security infrastructure . . . . . . . . . . . . . . . . . 90
Chapter 4. Design and integration guidelines . . . . . . . . . . . . . . . . . . . . . . 93

4.1 Security and design guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.1.1 Design principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.1.2 WebSphere Portal vs Tivoli Access Manager authorization . . . . . . . 95
4.1.3 Single sign-on guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.1.4 Identity management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.1.5 Adding an external Web server for WebSphere Portal . . . . . . . . . . 107
4.2 Product-specific integration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.2.1 WebSEAL junctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.2 Junction considerations for use with TAI. . . . . . . . . . . . . . . . . . . . . 109
4.2.3 Handling of back-end application cookies. . . . . . . . . . . . . . . . . . . . 110
4.2.4 Junction Mapping Table (JMT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2.5 WebSEAL URL-based access control . . . . . . . . . . . . . . . . . . . . . . 112
4.2.6 Access control of WebSphere Portal resources . . . . . . . . . . . . . . . 113
4.2.7 Access control of resources within portlet applications . . . . . . . . . . 113
4.2.8 WebSEAL and WebSphere Portal session considerations . . . . . . . 114
4.3 Sequence diagrams for common access patterns . . . . . . . . . . . . . . . . . 115
4.3.1 UCT1: Access unprotected portal page . . . . . . . . . . . . . . . . . . . . . 116
4.3.2 UCT2: Access protected portal page, provide valid credentials . . . 117
4.3.3 UCT3: Access protected portal page with existing valid session . . 119
4.3.4 UCT4: Access protected portal page with invalid credentials . . . . . 120
4.3.5 UCT5: WebSEAL session times out before portal session . . . . . . . 121
4.3.6 UCT6: Portal session times out before WebSEAL session. . . . . . . 124
4.3.7 UCT7: Both WebSEAL and WebSphere Portal sessions time out . 127
4.3.8 UCT8: WebSphere Portal logout after WebSEAL session timeout. 131
iv Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4.4 Component connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Part 2. ITSO working example secure portal solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Chapter 5. Requirements and solution design. . . . . . . . . . . . . . . . . . . . . 143

5.1 Business scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.1.1 Initial context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.1.2 Business challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.2 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.2.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.2.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.3 Use case model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.3.1 Use case overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.3.2 Front-end use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
5.3.3 Administrative use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.4.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.4.2 Architecture decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.4.3 Selected runtime environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.4.4 Selected development environment . . . . . . . . . . . . . . . . . . . . . . . . 174
Chapter 6. Install the runtime environment . . . . . . . . . . . . . . . . . . . . . . . 175

6.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
6.1.1 Hardware and software prerequisites . . . . . . . . . . . . . . . . . . . . . . . 177
6.1.2 Hardware used within the ITSO runtime environment . . . . . . . . . . 178
6.1.3 Software used within the ITSO runtime environment . . . . . . . . . . . 178
6.1.4 Software installation paths and variables . . . . . . . . . . . . . . . . . . . . 181
6.1.5 Using VMWare and Ghost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.2 Implement the Policy Server node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.2.1 Windows 2000 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.2.2 DB2 Universal Database installation. . . . . . . . . . . . . . . . . . . . . . . . 184
6.2.3 IBM GSKit upgrade installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.2.4 Java Runtime Environment (JRE) V1.3.1 installation . . . . . . . . . . . 192
6.2.5 Tivoli Directory Server installation. . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.2.6 Tivoli Directory Server configuration . . . . . . . . . . . . . . . . . . . . . . . . 195
6.2.7 Tivoli Web Administration Tool installation . . . . . . . . . . . . . . . . . . . 196
6.2.8 Configure Directory Server for Tivoli Access Manager . . . . . . . . . . 206
6.2.9 Tivoli Access Manager installation . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.2.10 Tivoli Access Manager configuration . . . . . . . . . . . . . . . . . . . . . . 208
6.2.11 Tivoli Access Manager Web Portal Manager installation . . . . . . . 213
6.2.12 Tivoli Access Manager V5.1 Base Fixpack 2 installation . . . . . . . 216
6.3 Implement the Reverse Proxy node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
6.3.2 Install GSKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Contents v
6.3.3 Install Java Runtime Environment (JRE) . . . . . . . . . . . . . . . . . . . . 219
6.3.4 Install Tivoli Directory Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.3.5 Tivoli Access Manager - WebSEAL installation . . . . . . . . . . . . . . . 220
6.3.6 Tivoli Access Manager - WebSEAL configuration. . . . . . . . . . . . . . 222
6.3.7 Tivoli Access Manager V5.1 Base Fixpack 2 installation . . . . . . . . 225
6.3.8 Tivoli Access Manager V5.1 WebSEAL Fixpack 2 installation . . . . 226
6.4 Implement the Portal Server node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.4.2 WebSphere Portal Server V5.0 installation. . . . . . . . . . . . . . . . . . . 228
6.4.3 WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2)
installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.4.4 WebSphere Application Server V5.0.2 Fixes installation . . . . . . . . 237
6.4.5 WebSphere Portal V5 Fixpack 2 (V5.0.2) installation . . . . . . . . . . . 240
6.4.6 WebSphere Application Server Enterprise V5.0.2 Cumulative Fix
(V5.0.2.3) installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
6.4.7 WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) installation. 251
6.4.9 Tivoli Access Manager Java Runtime Environment installation . . . 255
6.4.10 DB2 Universal Database installation . . . . . . . . . . . . . . . . . . . . . . . 257
Chapter 7. Configure the runtime environment . . . . . . . . . . . . . . . . . . . . 259

7.1 Configure WebSphere Portal for DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
7.2 Configure WebSphere Portal for IBM HTTP Server . . . . . . . . . . . . . . . . 264
7.3 Configure WebSphere Portal for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 266
7.3.1 Create a suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
7.3.2 Create LDIF file containing users and groups . . . . . . . . . . . . . . . . . 267
7.3.3 Import the LDIF file (wp-itso.ldif) to create users and groups . . . . . 268
7.3.4 Enable LDAP security for WebSphere Portal . . . . . . . . . . . . . . . . . 269
7.3.5 Verify the LDAP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
7.4 Enable mutual SSL between WebSEAL and WebSphere Portal . . . . . . 276
7.4.1 IBM HTTP Server SSL configuration . . . . . . . . . . . . . . . . . . . . . . . 277
7.4.2 Configure WebSphere Portal for SSL . . . . . . . . . . . . . . . . . . . . . . . 281
7.4.3 Export IBM HTTP Server CA certificate . . . . . . . . . . . . . . . . . . . . . 283
7.4.4 Import IBM HTTP Server certificate into WebSEAL keystore . . . . . 284
7.4.5 Export WebSEAL certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
7.4.6 Import WebSEAL certificate into IBM HTTP Server keystore . . . . . 287
7.4.7 Enable mutual SSL for IBM HTTP Server . . . . . . . . . . . . . . . . . . . . 288
7.5 Configure portal authentication with TAM using TAI . . . . . . . . . . . . . . . . 289
7.5.1 Apply Tivoli Access Manager ACLs to new LDAP suffixes . . . . . . . 290
7.5.2 Define additional MIME types for WebSphere Application Server . 296
7.5.3 Create a WebSEAL junction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
7.5.4 Enable forms authentication on WebSEAL . . . . . . . . . . . . . . . . . . . 300
7.5.5 Configure WebSEAL to modify URLs to back-end systems . . . . . . 301
vi Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7.5.6 Configure additional WebSEAL parameters . . . . . . . . . . . . . . . . . . 303
7.5.7 Import WebSphere Portal users and groups into TAM . . . . . . . . . . 303
7.5.8 Define access controls for WebSphere Portal URIs . . . . . . . . . . . . 304
7.5.9 Configure the junction mapping table . . . . . . . . . . . . . . . . . . . . . . . 307
7.5.10 Configure SSO for WebSEAL and WebSphere via TAI . . . . . . . . 308
7.5.11 Configure Portal login/logout for use with WebSEAL . . . . . . . . . . 313
7.6 Configure Portal for authorization with TAM . . . . . . . . . . . . . . . . . . . . . . 322
7.6.1 Configure the SSL between WebSphere and TAM. . . . . . . . . . . . . 322
7.6.2 Implement JAAS authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
7.6.3 Modify WebSphere Portal configuration files . . . . . . . . . . . . . . . . . 331
7.6.4 Verify entries in TAM for Portal external authorization . . . . . . . . . . 336
7.6.5 Example for externalizing a resource . . . . . . . . . . . . . . . . . . . . . . . 337
7.7 Integrate the Credential Vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
7.7.1 Credential Vault overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
7.7.2 Configure the Credential Vault for Tivoli Access Manager . . . . . . . 348
7.7.3 Verify the Credential Vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
7.8 Additional configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
7.8.1 Configure WebSEAL and WebSphere Portal sesssion timeouts . . 356
7.8.2 Configure WebSEAL to handle favicon.ico . . . . . . . . . . . . . . . . . . . 359
Chapter 8. Implement the development environment . . . . . . . . . . . . . . . 361

8.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
8.1.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
8.1.2 Hardware used within the ITSO development environment . . . . . . 363
8.1.3 Software used within the ITSO development environment . . . . . . . 364
8.1.4 VMWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
8.2 Implement the Repository node (optional) . . . . . . . . . . . . . . . . . . . . . . . 366
8.3 Implement the Policy Server node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
8.4 Implement the Reverse Proxy node (optional) . . . . . . . . . . . . . . . . . . . . 366
8.5 Implement the Development node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
8.5.1 Windows 2000 installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
8.5.2 WebSphere Studio Application Developer V5.1.1 installation. . . . . 369
8.5.3 WebSphere Studio Application Developer V5.1.1 Interim Fix 002
installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
8.5.4 WebSphere Studio Application Developer - WebSphere Test
Environment fixpack installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
8.5.5 WebSphere Portal Toolkit and test environment installation. . . . . . 378
8.5.6 Verify the Portal Toolkit and Test Environment installation. . . . . . . 380
8.5.8 Tivoli Access Manager Java Runtime Environment installation . . . 381
8.5.9 Configure the SSL between the WTE and TAM . . . . . . . . . . . . . . . 383
8.5.10 Verify the TAM configuration within WebSphere Studio . . . . . . . . 384
8.5.11 CVS client configuration for WebSphere Studio . . . . . . . . . . . . . . 386
Contents vii
8.6 Configure WebSphere Portal for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 386
8.6.1 Create a suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
8.6.2 Import the LDIF file (wp-itso.ldif) to create users and groups . . . . . 387
8.6.3 Enable LDAP security for WebSphere Portal . . . . . . . . . . . . . . . . . 388
8.6.4 Stop/start servers in WebSphere Test Environment . . . . . . . . . . . . 392
8.6.5 Verify the LDAP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
8.6.6 Disable LDAP security in WebSphere Portal . . . . . . . . . . . . . . . . . 394
8.7 Additional configuration (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Chapter 9. Develop the secure portal application . . . . . . . . . . . . . . . . . . 395

9.1 Architecture and design of the ITSO example. . . . . . . . . . . . . . . . . . . . . 396
9.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
9.1.2 Deployment units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
9.1.3 Method level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
9.2 Prepare the workbench for the ITSO Bank example . . . . . . . . . . . . . . . . 401
9.2.1 ITSO Bank sample code download and unpack . . . . . . . . . . . . . . . 402
9.2.2 Import the sample project into the workbench . . . . . . . . . . . . . . . . 402
9.2.3 Team development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
9.2.4 Prepare the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
9.2.5 Prepare the back-end EJB server . . . . . . . . . . . . . . . . . . . . . . . . . . 412
9.2.6 Prepare the front-end portal server . . . . . . . . . . . . . . . . . . . . . . . . . 418
9.2.7 Run the ITSO Bank application in the test environment . . . . . . . . . 420
9.3 Using the Tivoli Access Manager APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 421
9.3.1 The portlet application without Tivoli Access Manager . . . . . . . . . . 422
9.3.2 The portlet application using Tivoli Access Manager . . . . . . . . . . . 423
9.4 Using the WebSphere Portal Credential Vault . . . . . . . . . . . . . . . . . . . . 425
Chapter 10. Deploy the secure portal application . . . . . . . . . . . . . . . . . . 433

10.1 ITSO Bank application overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
10.2 Deploy the ITSO Bank back-end application. . . . . . . . . . . . . . . . . . . . . 434
10.2.1 Create an application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
10.2.2 ITSO Bank sample code download and unpack . . . . . . . . . . . . . . 436
10.2.3 Create the ITSO Bank application database . . . . . . . . . . . . . . . . . 437
10.2.4 Add ITSOid attribute to the LDAP schema . . . . . . . . . . . . . . . . . . 437
10.2.5 Create the groups and users for the ITSO Bank application. . . . . 438
10.2.6 Create the ITSOBankDataSource data source . . . . . . . . . . . . . . . 440
10.2.7 Deploy the back-end application EAR. . . . . . . . . . . . . . . . . . . . . . 443
10.3 Deploy the ITSO Bank portal application . . . . . . . . . . . . . . . . . . . . . . . 446
10.3.1 ITSO Bank sample code download and unpack . . . . . . . . . . . . . . 446
10.3.2 Modify properties files and repackage WAR . . . . . . . . . . . . . . . . . 446
10.3.3 Modify the wmmLDAPServerAttributes.xml file. . . . . . . . . . . . . . . 449
10.3.4 Install portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
10.3.5 Create portal pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
viii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
10.3.6 Add portlets to pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
10.3.7 Modify resource permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
10.3.8 Verify ITSO Bank application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
10.3.9 Externalize the ITSO Bank resources . . . . . . . . . . . . . . . . . . . . . . 467
Chapter 11. Security hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

11.1 Configure CSIv2 SSL settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
11.1.1 Create SSL keys for CSIv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
11.1.2 Configure the SSL repertoire for CSIv2 . . . . . . . . . . . . . . . . . . . . 474
11.2 Enable SSL for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
11.2.1 Enable LDAP server for SSL connections . . . . . . . . . . . . . . . . . . 476
11.2.2 Enable SSL for Tivoli Access Manager LDAP connections . . . . . 478
11.2.3 Enable SSL for WebSEAL LDAP connections . . . . . . . . . . . . . . . 480
11.2.4 Enable SSL for WebSphere LDAP connection . . . . . . . . . . . . . . . 481
11.2.5 Enable SSL for WebSphere Portal LDAP connections . . . . . . . . . 484
11.2.6 Enable SSL for Web Admin Tool LDAP connection . . . . . . . . . . . 487
11.2.7 Configure Tivoli Directory Server client utilities for SSL . . . . . . . . 488
11.2.8 Disable non-SSL access to Tivoli Directory Server. . . . . . . . . . . . 489
11.3 Replace the default SSL certificates for the SOAP connector . . . . . . . 490
11.3.1 Configure SSL certificate and repertoire for SOAP connector . . . 491
11.3.2 Configure WebSphere administration utilities . . . . . . . . . . . . . . . . 494
11.3.3 Configure WebSphere Portal SOAP connection credentials . . . . 495
11.4 Additional security hardening guidelines . . . . . . . . . . . . . . . . . . . . . . . . 501
11.4.1 Secure a WebSphere Network Deployment environment. . . . . . . 501
11.4.2 Disable the IBM HTTP Server Administration service. . . . . . . . . . 502
11.4.3 Disable the IBM HTTP Server on the Policy Server node. . . . . . . 502
Chapter 12. Manage a secure portal solution. . . . . . . . . . . . . . . . . . . . . . 503

12.1 Tivoli administration tools and common tasks . . . . . . . . . . . . . . . . . . . . 504
12.1.1 Tivoli Directory Server processes . . . . . . . . . . . . . . . . . . . . . . . . . 504
12.1.2 Tivoli Directory Server - Configuration Tool (ldapxcfg) . . . . . . . . . 506
12.1.3 Tivoli Directory Server - Web Administration Tool . . . . . . . . . . . . 507
12.1.4 Tivoli Directory Server - Command line utilities . . . . . . . . . . . . . . 510
12.1.5 Tivoli Access Manager - Servers . . . . . . . . . . . . . . . . . . . . . . . . . 511
12.1.6 Tivoli Access Manager - pdadmin . . . . . . . . . . . . . . . . . . . . . . . . . 511
12.1.7 Tivoli Access Manager - Web Portal Manager . . . . . . . . . . . . . . . 513
12.1.8 User management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
12.1.9 Customize the WebSEAL HTML pages . . . . . . . . . . . . . . . . . . . . 519
12.1.10 Externalized role management . . . . . . . . . . . . . . . . . . . . . . . . . . 524
12.1.11 Favicon configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
12.2 WebSphere administration tools and common tasks . . . . . . . . . . . . . . 531
12.2.1 WebSphere Application Server - Administrative console . . . . . . . 531
12.2.2 WebSphere Application Server - Scripting program . . . . . . . . . . . 532
Contents ix
12.2.3 WebSphere Application Server - Command-line tools . . . . . . . . . 533
12.2.4 WebSphere Portal - Web administration . . . . . . . . . . . . . . . . . . . . 535
12.2.5 WebSphere Portal - XMLAccess. . . . . . . . . . . . . . . . . . . . . . . . . . 544
12.2.6 Externalize virtual resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
12.3 Start and stop servers for ITSO example nodes . . . . . . . . . . . . . . . . . . 548
12.4 Back up and restore of key configuration files and databases . . . . . . . 549
12.4.1 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
12.4.2 Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
12.5 Verifying the ITSO Bank application and runtime . . . . . . . . . . . . . . . . . 557
12.5.1 Banking application login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
12.5.2 Add user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
12.5.3 Modify user information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
12.5.4 View account balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
12.5.5 Transfer funds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Appendix A. Troubleshooting a secure portal solution. . . . . . . . . . . . . . 573

Common issues encountered in a secure portal . . . . . . . . . . . . . . . . . . . . . . 574
Common problems and solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Secure portal tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Runtime log files for server components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Logs - WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Logs - WebSphere Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Logs - Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Gathering runtime tracing for security issues . . . . . . . . . . . . . . . . . . . . . . . . . 591
Tracing authentication issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Tracing authorization issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Tracing Credential Vault issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Problems fixed in the portal for external access control . . . . . . . . . . . . . . . . . 594
WebSphere Portal V5 Fixpack 2 (V5.0.2) . . . . . . . . . . . . . . . . . . . . . . . . . 594
WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) . . . . . . . . . . . . . . . 595
Individual fixes for WebSphere Portal V5.0.2.1. . . . . . . . . . . . . . . . . . . . . 596
Appendix B. Configure single sign-on using LTPA . . . . . . . . . . . . . . . . . 597

Prerequisite steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
LTPA configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Apply Tivoli Access Manager ACLs to new LDAP suffix . . . . . . . . . . . . . . 598
Define additional MIME types for WebSphere Application Server . . . . . . 599
Export LTPA encryption keys from the WebSphere Application Server . . 599
Create a WebSEAL junction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Enable forms authentication on WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . 601
Configure WebSEAL to modify URLs to back-end systems . . . . . . . . . . . 601
Configure additional WebSEAL parameters . . . . . . . . . . . . . . . . . . . . . . . 601
x Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Import WebSphere Portal users and groups into TAM . . . . . . . . . . . . . . . 601
Define access controls for WebSphere Portal URIs . . . . . . . . . . . . . . . . . 602
Configure the junction mapping table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Configure Portal login/logout for WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 602
Appendix C. CVS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603

CVS overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
CVSNT Server implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
CVS Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
CVS Server repository configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Create CVS users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
CVS Client configuration for WebSphere Studio Application Developer . . . . 610
Set CVS DTD file extension to ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Label decorations for CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Setting up the repository location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Appendix D. Automate deployment tasks. . . . . . . . . . . . . . . . . . . . . . . . . 613

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Deployment walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Solution structuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Populating the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Concepts and background discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
ITSO WebSphere Portal development starter kit . . . . . . . . . . . . . . . . . . . 627
wpdsk-util command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Appendix E. Node descriptions for architecture models . . . . . . . . . . . . 645

Conceptual model node description for the runtime environment . . . . . . . . . 646
Specified model node description for the runtime environment . . . . . . . . . . . 656
Conceptual model node descriptions for development . . . . . . . . . . . . . . . . . 670
Specified model node description for development and test environment . . . 676
Appendix F. Additional material. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
System requirements for downloading the Web material . . . . . . . . . . . . . 684
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Description of sample code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Contents xi
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
xii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
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. 2004. All rights reserved. xiii

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® HACMP™ Redbooks™

Balance® IBM® Redbooks (logo) ™
ClearCase® ibm.com® Sametime®
Cloudscape™ Lotus Notes® Tivoli®
developerWorks® Lotus® WebSphere®
Domino® NetView® xSeries®
DB2 Universal Database™ Notes®
DB2® Rational®
The following terms are trademarks of other companies:
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
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.
xiv Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Preface
Portals provide a personalized single point of access to applications, content,

and processes through a Web interface. Secure portal solutions are needed to
address the common security challenges, such as authentication, authorization
and single sign-on.
This IBM Redbook and sample code will provide IT architects, developers, IT
specialists, and administrators with the critical knowledge the design, develop,
deploy and manage a secure portal solution using IBM® Tivoli Access Manager
V5.1.0.2 and IBM WebSphere® Portal V5.0.2.1.
Part 1, “Introduction to secure portal solutions” on page 1, introduces key

concepts and provides an in-depth look at the secure portal solution architecture,
topology selection, design and integration guidelines.
Part 2, “ITSO working example secure portal solution” on page 141, describes
how to implement an end-to-end secure portal solution. This part includes a
business scenario, requirements, design, implementation of the runtime and
development environments, application development and deployment, and
administration of the secure portal solution.
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, Raleigh Center.
© Copyright IBM Corp. 2004. All rights reserved. xv

Figure 1 The IBM Redbook team (left to right, 1st row: John Ganci, Normunds Saumanis; 2nd row: Brett
Gordon, Jonas Tingeborn, Melanie Fletcher, Hinrich Boog, Ashwin Manekar, Kai Schwidder)
John Ganci is a Senior Software Engineer, WebSphere Specialist at the IBM

ITSO, Raleigh Center. He writes extensively and teaches classes on WebSphere
and related topics. John has 14 years of experience in product and application
design, development, system testing, and consulting. His areas of expertise
include e-commerce, WebSphere Application Server, portals, pervasive
computing, Linux and Java™ programming.
Hinrich Boog is an IT Specialist in the IBM e-business Innovation Center

Hamburg, Germany. He has several years of experience in application
development and IT consulting for e-business solutions. He holds a degree in
Computer Science (major) and Russian language (minor) from Freie Universität
Berlin, Germany. His areas of expertise include J2EE applications, enterprise
portals and Web content management. He is a Sun Certified Web Component
Developer.
xvi Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Melanie Fletcher is a Software Engineer in the Gold Coast IBM Tivoli® lab,
Australia. She has extensive experience with the Tivoli Access Manager security
products ranging from functional verification testing to consulting. She holds a
degree in Business and a Masters of Information Technology from the
Queensland University of Technology, Australia. Her areas of expertise include
security solutions using Tivoli Access Manager and Tivoli Identity Manager.
Brett Gordon is a Software Engineer in the IBM Software Group, USA. He has
over five years of experience in technical support for IBM Lotus® Software. He
holds a degree in international economics from the University of Texas at Austin,
and he is currently pursuing a Masters degree in Computer Networking from
North Carolina State University in Raleigh. His areas of expertise include
integration, security, and administration of WebSphere Portal and Lotus
Domino®. He is an IBM Certified System Administrator for WebSphere Portal
V5.
Ashwin Manekar is a Software Engineer in IBM Software Group Solution Test,

USA. He has eight years of experience in application development and IT
Consulting for e-business solutions. He holds a Masters degree in Computer
Science from the University of North Carolina at Charlotte, USA. His areas of
expertise include developing J2EE enterprise applications, portlet development,
Click-To-Action technolog,y and Web applications. He has published several
papers in the area of WebSphere Portal environment setup and portlet
development on the IBM developerWorks® technical forum.
Normunds Saumanis is an IT Architect in IBM Global Services, Latvia. He has

over 10 years experience in systems support, systems integration, application
development and IT consulting. He holds a degree in Computer Science from
Michigan State University, USA. His areas of expertise include AIX/UNIX®
systems support, IT infrastructure design and operations, systems integration,
Java, pervasive and Web applications, and IBM WebSphere.
Kai Schwidder is an IT Architect in the IBM Software Group, Switzerland. He

has 14 years of experience in the fields of consulting, application development,
and systems integration for e-business and e-commerce solutions. He holds a
degree in Computer Science from the Technical University in Berlin, Germany.
His areas of expertise include systems integration, application architecture and
development, business to technology consulting, technical team leadership,
WebSphere Portal, Tivoli Access Manager, WebSphere Commerce, and
WebSphere MQ.
Jonas Tingeborn is an IT Specialist in IBM Global Services, Sweden. He has

worked at IBM for six years, of which the last four spent at various e-business
engagements for different customers. His focus areas and previous project roles
include application development, e-business consulting, and configuration
management with WebSphere Portal, J2EE and Linux.
Preface xvii
Thanks to the following people for their contributions to this project:
Tinny Ng, IBM Canada

Michele Galic, IBM USA
Allison Halliday, IBM Sweeden
Andrew Hatzikyriacos, South Africa
Maria Munaro, IBM Venezuela
Sailaja Parepalli, Miraclesoftware Systems Inc., USA
David Yang, IBM USA
Gianluca Gargaro, IBM Italy
Steven Tuttle, IBM ITSO Raleigh Center, USA
William Tworek, IBM ITSO Cambridge Center, USA
Axel Buecker, IBM ITSO Austin Center, USA
Ray Neucom, IBM USA
Paul Kelsey, IBM USA
Masanobu Ida, IBM Japan
Stefan Schmitt, IBM Germany
Daniel Kipfer, IBM Switzerland
Julie Czubik, ITSO Poughkeepsie Center, USA
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!
xviii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
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. HZ8 Building 662
P.O. Box 12195
Research Triangle Park, NC 27709-2195
Preface xix
xx Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Part 1
Part 1 Introduction to
secure portal
solutions
© Copyright IBM Corp. 2004. All rights reserved. 1

2 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
1
Chapter 1. Introduction
Nearly every e-business needs a secure infrastructure for hosting Web-based
applications such as a secure portal. There are several common challenges that
businesses face when implementing secure portal solutions. First, the site needs
to provide a means of determining who is accessing the site (authentication).
Second, the site needs the capability to permit or deny access to resources
based on the policies and users/groups who access the resources
(authorization). Third, users desire to only log on once for access to applications
to which they have been granted access (single sign-on).
In some cases, businesses have tried to pioneer these solutions on their own.
This can be a very costly and risky approach to Web-based security. As the
complexity of Web sites increases to meet e-business needs, there is a growing
expectation for IT shops to deploy solutions in a very timely fashion. To solve
these infrastructure and security needs, many companies look to leverage
middleware software technologies that provide an integrated solution for
authentication, authorization and single sign-on. When companies invest in
secure portal solutions from IBM using Tivoli Access Manager and WebSphere
Portal, they get a proven production-ready secure portal solution that can
dramatically accelerate their time to market.
The focus of this chapter is to introduce the key concepts of a secure portal
solution, outline the solution software, and define the target audience of the
publication.

1.1 Secure portal solution overview
This section includes an overview of the key concepts and solution architecture
of a secure portal solution.
1.1.1 Key concepts of a secure portal solution

This section includes a brief description of the key concepts of a secure portal
solution when using IBM WebSphere Portal and Tivoli Access Manager.
Authentication
Authentication is a process where the client identity is validated. The client can
be an end user, a machine or an application. Authentication uses the identity of
the user, authenticated or unauthenticated, to acquire the credentials of the user
with the objective of determining if the user has the proper permissions for the
requested resource.
Authorization
The authorization process provides the capability to permit or deny access to
resources based on the policies and users that access the resources. If the
resource is protected, the user will first be authenticated to determine their
identity, and then the privileges defined for the desired resource will be checked.
Shared LDAP user registry

The user registry is stored under a root LDAP suffix (for example,
dc=itso,dc=ibm,dc=com) in the LDAP repository. In a secure portal solution,
Tivoli Access Manager, WebSphere Portal and WebSphere Application Server
reference the same user registry, since they are configured to connect to and
use the same Tivoli Directory Server LDAP repository.
Single sign-on
Single sign-on provides users with the ability to log on once (authenticate) and
be able to access resources or applications within the enterprise the user has
been granted permissions.
Credential Vault
WebSphere Portal includes the Credential Service and Credential Vault features
to allow portlet applications to pass user credentials to a back-end application.
The Credential Vault is a portal service that helps portlets and portal users
manage multiple identities. When using Tivoli Access Manager with WebSphere
Portal to create a secure portal solution, the credential storage for the Credential
Vault can be moved to the Tivoli Access Manager Global Sign-on (GSO)
lockbox.
1.1.2 Secure portal solution high level architecture

There are many possible runtime topologies that can be implemented for a
secure portal solution, depending on the security, performance, scalability and
integration needs of the business. Figure 1-1 depicts the high level secure portal
solution architecture. The figure includes the ficticious ITSO Bank secure portal
application. The solution architecture can be applied to many types of
applications.
Outside Zone Demilitarized Zone Production Zone
Portal Server Backend Server

Public Key ITSO Bank ITSO Bank
Infrastructure Portlets EJBs
WebSphere WebSphere
Portal Application
I
Server
N
T Reverse
Web Request
E Proxy
WMM ITSO Bank
Protocol Firewall
Domain Firewall
Browser Response R
Client TAM
N WebSEAL
E
T
Policy Directory
Server Server
Domain Name TAM Tivoli Directory
Server Policy Server Server
TAM LDAP
Authorization User Registry
Server
Authorization
Figure 1-1 Secure portal solution high level architecture
The following example illustrates how a customer using a Web browser would
interact with the ITSO Bank secure portal solution to access a protected resource
such as a customer account balance. We will first log on to the ITSO Bank site to
outline the process of authentication, and then highlight the process of
authorization to the secure portal page.
1. Authenticate the customer.
a. The customer enters a URL in the Web browser to access a resource that
is protected by the WebSEAL.
Chapter 1. Introduction 5
b. The WebSEAL determines that the user has attempted to access a
protected resource and will prompt the user with a logon page.
c. The user enters her username and password in the logon form and then
submits them to the WebSEAL.
d. The WebSEAL then interacts with the Tivoli Access Manager Policy
Server and Tivoli Directory Server to validate the identity of the user in the
Tivoli Access Manager user registry.
e. The WebSEAL uses the validated identity to obtain a credential for that
user.
2. Authorized access to the secure resource.
In this example, the customer would like to view her account balance.
a. The WebSEAL interacts with the Tivoli Access Manager authorization
services with the user credentials to permit or deny access to protected
objects (for example, bank account balance) after evaluating the access
control list (ACL) permissions and protected object policy (POP).
b. WebSEAL forwards the request to WebSphere Portal.
c. The account balance portlet interacts with the back-end EJBs to retrieve
the customer account balance.
d. The WebSEAL sends the response to the Web browser client to display
the contents of the portal page.
1.2 Solution software

This section highlights the software we used in the ITSO working example
secure portal solution for both the runtime and development environments.
1.2.1 Runtime environment solution software

The majority of the runtime environment software used in the ITSO secure portal
solution are included in IBM WebSphere Portal Extend for Multiplatforms V5.0.2
and IBM Tivoli Access Manager for e-business V5.1. In addition, we used the
most current fixpack levels of software for these software suites, in some cases
to fix known problems and in others to fully validate the functionality when
integrated. We chose to use the Microsoft® Windows® 2000 Server with Service
Pack 4 as the operating system platform.
As described in Chapter 3, “Architecture and topology selection” on page 51,

there are many possible configurations for a secure portal depending on your
security, scalability and performance needs. In 3.2, “Runtime environment
topology selection” on page 69, we define three topologies (entry, enterprise,
extended enterprise). In addition, we provide guidance on selecting the
appropriate runtime topology, as well as define by node the software products
and levels.
Table 1-1 lists the software products and levels included with IBM Tivoli Access
Manager for e-business V5.1, as well as the fixpack levels we used to implement
the secure portal runtime environment for the ITSO working example.
Table 1-1 Software included with Tivoli Access Manager V5.1 and fixpack levels used by the ITSO
Tivoli Access Manager bundled software Tivoli Access Manager ITSO example
product name bundled software fixpack version
version
IBM DB2® UDB, Enterprise Server Edition 8.1 8.1.4.428

Note: 8.1 + Fixpack 4a
IBM GSKit 7.0.1.9 7.0.1.16
IBM Java Runtime Environment (JRE) 1.3.1 1.3.1
IBM WebSphere Application Server 5.0.2 5.0.2

Note: Used to host Web administration tools.
IBM Tivoli Directory Server 5.2 5.2

* Directory Server
* Directory Client SDK
* Web Administration Tool
IBM Tivoli Access Manager for e-business 5.1 5.1.0.2

* Access Manager Runtime Note: 5.1 + TAM Base
* Access Manager Java Runtime Environment Fixpack 2 + WebSEAL
(PDJRTE) Fixpack 2
* Access Manager Policy Server
* Access Manager Authorization Server
* Access Manager Web Portal Manager
* Access Manager Web Security Environment
*Access Manager WebSEAL
Table 1-2 lists the software products and levels included with IBM WebSphere
Portal Extend for Multiplatforms V5.0.2, as well as the fixpack levels we used to
implement the secure portal runtime environment for the ITSO working example.
Table 1-2 Software included with WebSphere Portal V5.0.2 Extend and fixpack levels used by the ITSO
WebSphere Portal Extend bundled software WebSphere Portal ITSO example
product name bundled software fixpack version
version
IBM DB2 UDB, Enterprise Server Edition 8.1.1 8.1.4.428

IBM WebSphere Application Server Enterprise

* WebSphere Application Server (Base) 5.0.2 5.0.2.3
Note: 5.0 + Fixpack 2 + Note: 5.0 + Fixpack 2 +
Fixes Cumulative Base Fix 3 +
Fixes
* Programming Module Enhancement (PME) 5.0.2 5.0.2.2

Note: 5.0 + Fixpack 2 Note: 5.0 + Fixpack 2 +
Cumulative PME Fix 2
IBM Tivoli Directory Server 5.1 5.2

* Directory Server
IBM WebSphere Portal Extend for 5.0.2 5.0.2.1

Multiplatforms Note: 5.0 + Fixpack 2 + Note: 5.0 + Fixpack 2 +
* WebSphere Portal Fixes Cumulative Fix 1 + Fixes
* WebSphere Portal Content Publisher
Note: Although we used IBM WebSphere Portal Extend for Multiplatforms

V5.0.2, the solution should also work with WebSphere Portal Enable.
1.2.2 Development environment solution software

Like the runtime environment, there are several possible configurations for
implementing a secure portal development environment. The development
environment topologies, software products, and levels are described in detail in
3.3, “Development environment topology selection” on page 81.
The software we used was included with IBM WebSphere Portal Extend for
Multiplatforms V5.0.2, IBM Tivoli Access Manager for e-business V5.1, and
fixpack downloads. In addition, we used IBM WebSphere Studio Application
Developer V5.1 in place of the WebSphere Portal supplied IBM WebSphere
Studio Site Developer V5.1, in large part because the ITSO Bank sample secure
portal application includes both front-end portlets and back-end EJBs, which
require the Application Developer Edition. We used both Microsoft Windows
2000 Professional and Server Editions, plus Service Pack 4 as the operating
system platform for the ITSO development environment.
For simplicity, we provide the software levels used for the ITSO-defined
all-in-one approach development environment. The all-in-one approach includes
one physical machine, and potentially two VMWare virtual machines to host the
unit testing nodes. For example, the ITSO all-in-one development environment
includes the following “nodes” on one physical system:
򐂰 Development node - All application development-related software is installed
on the physical system. For details on the software components and levels
used refer to Table 1-3 on page 9.
򐂰 Policy Server node - This VMWare virtual machine is used to host the Tivoli
Directory Server, Tivoli Access Manager Policy Server, and Authorization
Server for unit testing. The software levels used for this node are the same as
the Tivoli components listed in Table 1-1 on page 7.
򐂰 Reverse Proxy node - This VMWare virtual machine is optionally used to host
the WebSEAL for unique testing scenarios needed in the development
environment. The software levels used for this node are the same as the
Tivoli components listed in Table 1-1 on page 7.
Note: Detailed procedures for implementing the ITSO all-in-one secure portal
development environment can be found in Chapter 8, “Implement the
development environment” on page 361.
Table 1-3 Development node

Software Version
Microsoft Windows 2000 2000 + Service Pack 4
IBM WebSphere Studio Application 5.1.1

Developer
IBM WebSphere Test Environment 5.0.2.3

included with WebSphere Studio Note: Fixpack 2 + Cumulative Fix 3 +
Application Developer Fixes
IBM WebSphere Portal Toolkit and Test 5.0.2.1

Environment
IBM Java Runtime Environment (JRE) 1.3.1
IBM Tivoli Access Manager for e-business 5.1.0.2

* Access Manager Java Runtime Note: 5.1 + Base Fixpack 2
Environment (PDJRTE)
Note: In the development environment, we chose to use the Cloudscape™
included with WebSphere Studio Application Developer to host the ITSO Bank
database. In the runtime environment we used DB2 UDB.
1.3 Target audience of redbook

This redbook includes architecture, design, development, integration,
deployment and administration topics. The target audience for this redbook can
be best matched by role to the topic of interest within the publication.
The secure portal solution found in this redbook is largely targeted at enterprise
customers. Tivoli Access Manager provides the secure portal solution a proven
authentication, authorization, and single sign-on solutions. SMB customers that
do not have the security and back-end integration requirements of an enterprise
business may opt for a secure portal solution without the use of Tivoli Access
Manager.
1.3.1 Roles and skills

This section includes a brief description of the roles needed for a team to execute
a secure portal project during the development life-cycle, with the objective of
mapping the redbook topics to roles and skills.
IT architect
The IT architect looks after the overall project technical architecture/design,
quality assurance of the solution, knowledge transfer to customer, and mentoring
to the project technical team members. The architect should have WebSphere
Portal and Tivoli Access Manager architecture and design skills.
Security architect
The role of a security architect is to eliminate or greatly reduce the possibility of
an intruder attack. When developing a strategy for providing a secure portal
solution it is critical that the security architect understand the areas of risk and
ensure that the solution architecture addresses the known risk categories.
IT specialist
The role of IT specialist represents a wide range of technical specialists,
including systems administrator, database administrator, pre-sales support,
technical support, and tester.
Portal developer
The portal developer is responsible for developing the portlets for the secure
portal solution. In small projects, a developer may perform several roles,
including J2EE application developer, portal developer, and Web designer.
J2EE developer
The J2EE developer is responsible for developing such application code as EJBs
and servlets for back-end applications.
Project manager
The project manager is responsible for managing and leading the project team
along all phases of the project and also acts as a contact point to interact with the
customer. The project manager should have an understanding of WebSphere
Portal and Tivoli Access Manager, and concepts of a secure portal solution.
Security administrator
The security administrator is responsible for implementing the access control list
(ACL) policies and protected object policies (POP) for protected resources.
Portal administrator
The portal administrator role is responsible for deploying portlets and managing
the portal server, including security-related tasks and troubleshooting.
1.3.2 Matching redbook topics to roles and skills

Table 1-4 provides a summary of the redbook topics by part and
chapter/appendix for the defined roles and skills.
Table 1-4 Matching redbook topics to roles and skills

Chapter/appendix Primary Secondary
Part 1, “Introduction to secure portal solutions” on page 1
Chapter 1, “Introduction” on page 3 All user roles
Chapter 2, “Security fundamentals” on page 13 All user roles
Chapter 3, “Architecture and topology selection” on IT architect All user roles

page 51 Security architect
Chapter 4, “Design and integration guidelines” on IT architect All user roles

Part 2, “ITSO working example secure portal solution” on page 141
Chapter/appendix Primary Secondary
Chapter 5, “Requirements and solution design” on IT architect All user roles

Project manager
Chapter 6, “Install the runtime environment” on IT specialist IT architect

page 175
Chapter 7, “Configure the runtime environment” on IT specialist IT architect

page 259 Security administrator Security architect
Portal administrator
Chapter 8, “Implement the development Portal developer IT architect

environment” on page 361 J2EE developer IT specialist
Chapter 9, “Develop the secure portal application” Portal developer IT architect

on page 395 J2EE developer
Chapter 10, “Deploy the secure portal application” IT specialist Portal developer
on page 433 Portal administrator J2EE developer
Security administrator IT architect
Chapter 11, “Security hardening” on page 471 IT specialist IT architect

Security administrator Security architect
Chapter 12, “Manage a secure portal solution” on Portal administrator IT specialist

page 503 Security administrator IT architect
Part 3, “Appendixes” on page 571
Appendix A, “Troubleshooting a secure portal IT specialist Portal developer

solution” on page 573 Portal administrator J2EE developer
Appendix B, “Configure single sign-on using LTPA” IT specialist IT architect

on page 597 Security administrator Security architect
Appendix C, “CVS configuration” on page 603 Portal developer IT architect

J2EE developer IT specialist
Appendix D, “Automate deployment tasks” on IT specialist Portal developer

page 613 Portal administrator J2EE developer
Appendix E, “Node descriptions for architecture IT architect All user roles

models” on page 645 Security architect
Appendix F, “Additional material” on page 683 IT specialist IT architect

Note: Sample configuration files and ITSO Bank Portal developer
sample secure portal application J2EE developer
2
Chapter 2. Security fundamentals

This chapter introduces categories of security in the security domain, with the
objective of communicating the scope of the topics addressed in this redbook.
Once the security topics are defined a risk analysis can be performed. Security
risks can be greatly reduced by adopting a defined and proven security
methodology such as the IBM Method for Architecting Secure Solutions (MASS).
Lastly, this chapter includes a detailed description of how authentication,
authorization, and single sign-on work when using Tivoli Access Manager and
WebSphere Portal.
This chapter is organized into the following sections:

򐂰 Security domain and risk management
򐂰 Method for Architecting Secure Solutions (MASS)
򐂰 Security fundamentals

2.1 Security domain and risk management
Security is a very vast topic. When developing a strategy for providing a secure
environment for your company’s Web site and applications, it is critical to
understand the areas of security risk as well as how to reduce security risk.
Attention: The security focus in this redbook for the secure portal solution is
as follows (see Figure 2-1):
򐂰 Applications
򐂰 Middleware and application software
Both WebSphere Portal and Tivoli Access Manager include infrastructure

components and APIs to help implement authentication, single sign-on, and
authorization for the above-mentioned security categories. The remaining
security categories displayed in Figure 2-1 need to be addressed using other
tools and processes.
Security Policy
Security Policies and Procedure
Security Management and Audit
Risk Analysis
Logical Security
Applications
Vulnerability and
Intruder Reconnaissance Middleware and Application Software
Operating System
Network Software and Communications
Physical Security
Systems Hardware
Physical Network
Building and Access to Systems
Figure 2-1 Elements of the security domain
As you can see from Figure 2-1, many of these topics are common to all Web
applications. This section introduces the concepts of each security category and
provides reference information for further reading.
Tip: We recommend that you refer to the following reference information to

further understand the general security issues common to Web environments:
򐂰 System Administration, Networking and Security Institute (SANS):
http://www.sans.org/
򐂰 The Center for Internet Security (CIS):
http://www.cisecurity.org/
򐂰 Enterprise Security Architecture Using IBM Tivoli Security Solutions,
SG24-6014
򐂰 IBM WebSphere V5.0 Security, WebSphere Handbook Series, SG24-6573
򐂰 Hacking Exposed: Network Security Secrets & Solutions, Third Edition,
Stuart McClure et al.
2.1.1 Source of vulnerability and intruder reconnaissance

The most common source of security problems is employees making mistakes.
The actual threat from hackers and viruses is much smaller than most people
would anticipate. Having policies and procedures in place helps you address
your risks. However, they will not directly cover the human factor errors.
Managing and auditing your security enables you to perform checks and
discover some errors and correct them. However, if discovered, they may have
already been the cause of a security breach.
Intruder reconnaissance
It is important that the security architect, IT architect, network administrator,
security administrator, and IT specialist understand that intruders are
opportunistic. Before your site is hacked, the intruder will often investigate your
organization. The intruder will look for known vulnerabilities in the network,
operating system, middleware software, and application architecture.
After the reconnaissance phase, the hacker will begin to systematically launch
an attack to gain access to your company’s systems and information. It is up to
you to understand the common vulnerabilities that intruders use and take
corrective action to deny the attack. The network administrator can use these
same techniques to discover what information may be gathered by an intruder.
Chapter 2. Security fundamentals 15

The reconnaissance information from your organization is gathered by using
systematic techniques such as the following:
򐂰 Footprinting
Footprinting provides the intruder with the information about your systems
connected to the Internet gathered by probing the resources without actually
touching them. When the network administrator performs the footprinting
activity, they are looking to discover what knowledge the intruder could
obtain.
Some common examples of footprinting include Domain Name System
queries, searches, and traceroutes. This is all done with the objective of
building a detailed footprint of your network to be used for an attack.
򐂰 Scanning
Once he has gained knowledge of the organization from footprinting, the
intruder uses this information for the next technique, called scanning.
Scanning is the process of interrogating your network systems for available
ports; resources such as shares, accounts, operating system types and
versions; and other opportunistic avenues to take advantage of your systems.
Some common examples of scanning include port scanning, ICMP scanning,
ping sweeps, and operating system detection. These techniques, alongside
many tools available to facilitate scanning, can provide an intruder a mapping
of your network by IP, and ports and services ready for attack. Properly
implementing firewalls can go a long way towards the prevention of scanning.
򐂰 Enumeration
Enumeration is the process of directly interrogating a system to extract
account names or services from the system to launch a more refined attack.
The key distinction between this type of intrusion is the aggressive and active
nature on your system. The type of activity can often be logged, which is an
important element of security.
Common examples of enumeration are Windows network resources and
shares, Windows/UNIX/Linux users and groups, SNMP daemon or service
running without being tightly secured, and applications available to exploit.
Where to find more information

We recommend the following sources for more detailed information on intruder
reconnaissance, how to take corrective action, and tools available:
򐂰 A good source for understanding how to identify vulnerability is the article
"Vulnerability Identification and Remediation Through Best Security
Practices", by BJ Bellemay Jr, SANS Institute Reading Room, December 7,
2001 found at:
http://rr.sans.org/practice/identification.php
򐂰 The book Hacking Exposed: Network Security Secrets & Solutions, Forth
Edition, by Stuart McClure et al, provides a good explanation of the process
and strategies used by intruders, as well as methods of denying the attack.
2.1.2 Physical security

Physical security does not often get very much attention, but it is an important
element of a security strategy. Physical security risks are those risks where there
is a real physical impact on your hardware and software. These risks are very
severe because most of them result in a total loss of hardware and data. If your
customer data is gone as a result of a fire or a stolen system, it does not matter
to your business how this happened. The fact is that it can be extremely
damaging to your business.
Physical security means protection against physical actions. It involves every

physical element around:
򐂰 The system or machine(s) where the application is running
򐂰 The room where the machines are operating, as well as access to the room
򐂰 The building where the machines are installed
򐂰 The site where the company is located
The listed elements have to be secured against intrusion and damage, be it

intentional or not.
Physical security also includes the protection of the physical communication

network:
򐂰 Ground lines
򐂰 Wireless connection
򐂰 Routers and switches
򐂰 Hardware firewalls
The communication network has to be protected against eavesdropping and

damage to the connection (cutting the line).
The subject of physical security goes much further than the objective of this book
allows. This short section is only intended as a reminder of the concept of
physical security.
2.1.3 Logical security

Logical security is related to particular IT solutions such as network, operating
systems, middleware and application software, and custom-built applications.

Applications
The application architecture can provide intruders an opportunistic entry point. In
a secure portal application, there are many areas of application-level security
that need to be examined, including the infrastructure-provided security, as well
as the infrastructure application level APIs.
It is important that the security architect and portal developer understand the
security infrastructure capabilities provided by the middleware and application
software for such topics as authentication, authorization and single sign-on.
The middleware and application software also include security-related APIs that
can be used to further leveraged to secure the application and provide added
functionality.
Tivoli Access Manager Authorization API

The Tivoli Access Manager Java runtime component includes the Java language
version of a subset of the Tivoli Access Manager authorization API. The
authorization API consists of a set of classes and methods that provide Java
applications with the ability to interact with Tivoli Access Manager to make
authentication and authorization decisions.
Note: For more information on the Tivoli Access Manager authorization APIs,
refer to the following:
򐂰 Section 9.3, “Using the Tivoli Access Manager APIs” on page 421,
includes an example of using the Tivoli Access Manager authorization
APIs for the ITSO Bank sample secure portal application.
򐂰 Authorization Java Classes Developer Reference, IBM Tivoli Access
Manager V5.1, SC32-1350, product guide.
SG24-6014.
WebSphere security
The IBM WebSphere Application Server V5 is a J2EE V1.3 compliant Java
application server, and it implements the required security services as they are
specified. IBM WebSphere Application Server security sits on top of the
operating system security and the security features provided by other
components, including the Java language, as shown in Figure 2-2.
WebSphere Application Resources
HTML
Servlet/JSP
EJBs
Naming WebServices
User Registry
JMX MBeans
Access Control
WebSphere Security WebSphere Security
J2EE Security API

Java Security
Corba Security / CSIv2
Java 2 Security
JVM 1.3
Platform Security Operating System Security
Figure 2-2 WebSphere Application Server environment security layers
For the ITSO working example, we will limit our WebSphere Application Server
security implementation to the WebSphere Security layer depicted in Figure 2-2.
The WebSphere Application Server provides the security infrastructure for

application security, which is transparent to the application developer. In most
cases the security is handled at deployment and runtime. Having said that, when
developing EJBs and servlets, there are a few security calls available if the
developer wants greater control of what the end user is allow to do beyond what
is provided by the WebSphere infrastructure.
There are two key topics we would like to highlight from the WebSphere security
model:
򐂰 EJB method level security
The EJB 2.0 specification defines two methods that allow programatic access
to the caller’s security context (javax.ejb.EJBContext):
– java.security.Principal getCallerPrincipal()
The getCallerPrincipal method allows the developer to get the name of
the current caller.

– Boolean isCallerinRole(String roleName)
The isCallerInRole method allows the developer to make additional
checks on the authorization rights of a user, which is not possible, or more
difficult, to perform through the deployment descriptor of the EJB.
򐂰 JAAS
Java Authentication and Authorization Services (JAAS) is a standard
extension to the Java 2 SDK V1.3 and it is part of Java 2 SDK V1.4. The
current version for JAAS is 1.0. The WebSphere Application Server V5 also
implements and uses JAAS for security purposes.
Note: For more detailed information on WebSphere Application Server

security, refer to the following:
򐂰 IBM WebSphere V5.0 Security, WebSphere Handbook Series,
SG24-6573, redbook
򐂰 Section 7.6.2, “Implement JAAS authentication” on page 324
򐂰 Section 9.1.3, “Method level security” on page 400
򐂰 The best way to learn JAAS is to start with the sample application that
comes with JAAS V1.0; download the extension from Sun’s Java site:
http://java.sun.com/products/jaas
Middleware and application software

Both middleware and application software provide security features for the
infrastructure used to host applications.
IBM middleware provides a scalable infrastructure to host applications and a rich

set of programming features and APIs for rapid custom application development.
Examples of middleware from IBM include:
򐂰 WebSphere Application Server
򐂰 WebSphere Portal
򐂰 Tivoli Access Manager
򐂰 WebSphere MQ
򐂰 WebSphere Commerce
IBM also offers a wide range of application software that also includes features
for scalability, hosting applications, and application development, such as:
򐂰 DB2 Universal Database™
򐂰 Lotus Notes® and Domino
Within the ITSO working example secure portal solution, we will leverage the
following security infrastructure features of WebSphere Application Server, Tivoli
Access Manager, WebSphere Portal and Tivoli Directory Server:
򐂰 Authentication
򐂰 Authorization
򐂰 Single sign-on
򐂰 Credential vault
Operating systems
Although the Microsoft Windows does have a high percentage of the overall
operating system market share, UNIX/Linux variants are mainstream within the
world of the Internet and Web application hosting.
The default settings of most operating system installations leave the system in an
unsecure state. For example, you will need to stop all unused ports, services,
and applications that are not needed.
򐂰 Microsoft Windows
Regardless of the operating system, it is important to keep current with
service levels. The service packs often contain fixes for security problems. It
seems as though every time you access the Microsoft site, there is some
critical security update that is needed for Windows.
Some common security issues on Windows include gaining access to
Administrator by password guessing, poor account policies, buffer overflows,
cracking the Security Accounts Manager (SAM), and back doors.
For more information on Windows 2000 security issues, refer to the following:
– Microsoft Security home page:
http://www.microsoft.com/security/default.asp
– SANS Institute, Information Reading Room for Windows 2000:
http://rr.sans.org/win2000/win2000_list.php
򐂰 IBM AIX®
For information on IBM AIX security issues, refer to the following:
– IBM AIX home page:
http://www.ibm.com/servers/aix/
– IBM AIX Service Bulletins and Security Advisories:
http://techsupport.services.ibm.com/server/nav?fetch=sbasa
– SANS Institute, Information Reading Room for general UNIX:
http://rr.sans.org/unix/unix_list.php

– A Secure Way to Protect Your Network: IBM SecureWay Firewall for AIX
V4.1, SG24-5855 redbook
– AIX V4.3 Elements of Security, SG24-5962, redbook
– IBM Host Integration in a Secure Network, SG24-5988, redbook
򐂰 Linux
– Linux Community Center for Security:
http://www.linuxsecurity.com/
– SANS Institute, Information on Linux:
http://www.sans.org/rr/catindex.php?cat_id=32
– Novell SuSe Linux:
• SuSe home (search on security):
http://www.suse.com/
• SuSe certification (focus on security):
http://www.suse.com/us/business/certifications
– Redhat Linux (search for security):
http://www.redhat.com
Network
There are a variety of elements of a network that need to be considered for a
security strategy. Most companies today use the Internet for Web applications
and protect their networks and systems with firewalls. All it takes is one dial-up
networking analog connection without proper security and your firewall strategy
has been circumvented. In this section, we highlight the key areas of security
consideration as they relate to the network.
򐂰 Firewalls
A properly configured firewall can go a long way to protect your network. All
too often administrators will rely on firewalls to be a cure-all for their security
strategy, and do not take the necessary corrective action for the other
elements identified. What happens if an intruder does bypass your firewall?
By learning certain information, such as what type of firewall your company
uses, an intruder can try to infiltrate your network using documented security
holes for the given firewall.
򐂰 Network devices
Through the use of scanning techniques, intruders can discover network
devices and information on your network such as CISCO routers, operating
system identification, SNMP devices, and switches.
򐂰 Virtual Private Network (VPN)
A Virtual Private Network or VPN is a private network that is configured to be
used within a public network such as the Internet. VPNs provide security over
the public network using encryption. The key point is that along with the many
benefits of VPNs, there is added risk of intruder attack.
2.1.4 Security policy

Security policies are guidelines for an organization; they can be part of a widely
accepted standard (ISO) or implemented by a certain organization or company.
Policies can define processes for different areas in an organization. Security

policies focus on security-related processes, for example, how to request a new
password, how to renew a password, and so on.
These guidelines are very important in implementing a robust security for the
whole system organization-wide.
2.1.5 Security risk management

Most of the security categories discussed address different sorts of risks for an
organization. It basically does not matter what kind of organization we are
looking at, because everybody is facing certain risks and everybody is striving for
maximum security.
That is why it is of immense importance that the overall enterprise security policy
is the responsibility of the top business management. They have to decide where
the major security risks for that type of business lie and how to proceed from
there. A security policy has to define how to deal with the different categories of
risks, as depicted in Figure 2-3.

Prevent Protect Mitigate Risk
Risk
Analysis
Security
Policy
Emergency
Plan
Residual
Risk
Figure 2-3 Risk categorization
For risk categorization:

1. First, you have to analyze where the major risks for your enterprise are in
order to define procedures that will help prevent these risks from happening.
2. The next step is to define a security policy to deal with assets where you
cannot prevent malicious actions without putting protective measures into
place.
3. In case protective measures are overcome, you need to have an emergency
plan that tells you what to do in those cases.
4. Because these problems are not solved simply by defining a security policy,
but require investing money for certain activities and countermeasures, it is
for the senior management to decide what residual risk can be accepted.
There are always insurance carriers who can provide coverage for these
residual risks.
2.2 Method for Architecting Secure Solutions (MASS)
In the previous section, we reviewed the key types of security within the security
domain. In this section, we provide a summary of how the Method for
Architecting Secure Solutions (MASS) can be used to analyze the security
category risks and develop the security solution architecture.
Note: For a detailed examination of the Method for Architecting Secure

Solutions (MASS), refer to the Method for Architecture Secure Solutions
chapter in the Enterprise Security Architecture Using IBM Tivoli Security
Solutions, SG24-6014, redbook.
The task of developing IT solutions that consistently and effectively apply

security principles has many challenges. The challenges include the complexity
of integrating the specified security functions within the several underlying
component architectures found in computing systems, the difficulty in developing
a comprehensive set of baseline requirements for security, and a lack of widely
accepted security design methods.
With the formalization of security evaluation criteria into an international standard

known as the Common Criteria, one of the barriers to a common approach for
developing extensible IT security architectures has been lowered; however,
more work remains.
For business activities that rely on IT, trust is dependent on both the nature of the
agreement between the participants and the correct and reliable operation of the
IT solution. The reliance on computerized processes for personal, business,
governmental, and legal functions is evolving into a dependency and a
presumption (not to be confused with trust) that the processes, and the IT
systems within which they execute, will function without flaw.
To date, the application of IT security countermeasures is generally limited to

addressing specific vulnerabilities, such as applying network and systems
management processes, hardening operating systems for publicly available
servers, applying and monitoring intrusion detection systems, configuring and
operating digital certificate servers, and installing and configuring firewalls.
Based on the evolution of destructive computer codes and viruses, the repeated
breaches of sensitive computer systems, and recurring incidents of compromise
of private information stored on networked computing systems, it is reasonable
to conclude that the effectiveness of security measures in computing solutions
needs to be improved. Security experts from government and industry expressed
the need for a more comprehensive approach to describing security
requirements and designing secure solutions.

We have outlined the key phases and tasks of the Method for Architecting a
Security (Mass):
1. Problem statement
2. Analysis
a. Security-specific taxonomies, models, and methods
b. Common Criteria
i. Security audit
ii. Communication
iii. Cryptographic support
iv. User data protection
v. Identification and authentication
vi. Management of security functions
vii. Privacy
viii.Protection of security functions
ix. Resource utilization
x. Component access
xi. Trusted path or channel
3. System model for security
Security subsystems
4. Developing security architectures
a. Business process model
b. Security design objectives
c. Selection and enumeration of subsystems
d. Documenting conceptual security architecture
5. Integration into the overall solution architecture
a. Solution models
b. Documenting architectural decisions
c. Use cases
d. Refining the functional design
e. Integrating requirements into component architectures
2.3 Security fundamentals

The focus of this section is on the following key security topics relevant to a
secure portal solution.
򐂰 Public Key Infrastructure (PKI)
򐂰 WebSphere Portal security model
򐂰 Tivoli Access Manager security model
򐂰 Authentication
򐂰 Authorization
򐂰 WebSphere Portal Credential Vault
򐂰 Tivoli Access Manager Global Sign-on (GSO)
2.3.1 Public Key Infrastructure (PKI)

Public Key Infrastructure (PKI) integrates public/private key cryptography, digital
certificates, and Certificate Authority (CA) to provide a secure method of
communications and transactions on the Web.
Cryptography
Cryptography is a technique used to convert data (plaintext) using an encryption
algorithm into a encrypted form (secret code) while being transmitted over a
network, and then decrypted back into the original data (plaintext) at the
destination. The encryption algorithm uses a key measured in bits (length)
depending on the cipher strength.
The primary types of cryptography are as follows:

򐂰 Private key cryptography
Uses same secret key to encrypt and decrypt a message.
򐂰 Public key cryptography
Uses a public key to encrypt and a private key to decrypt.
Private key cryptography

The private key cryptography (symmetric key encryption) method uses the same
secret key to encrypt and decrypt the message, as depicted in Figure 2-4. The
secret key is an encryption algorithm such as Data Encryption Standard (DES) or
Advanced Encryption Standard (AES).
Plain Text Encryption Cipher Text Decryption Plain Text
Figure 2-4 Private key cryptography

The advantages and disadvantages of secret key cryptography are as follows:
򐂰 The advantage of the secret key algorithms is that they are faster in
comparison to public key cryptography introduced in “Public key
cryptography” on page 28.
򐂰 The disadvantage is that the same key is needed for encryption and
decryption, and both parties must have the same keys.
In today‘s cryptography, the secret key does not belong to a person, but rather a
communication session. At the beginning of a session, one of the parties creates
a session key and delivers it to the other party so they can securely
communicate. At the end of the session, both parties delete the key and, if they
want to communicate again, must create another key.
Public key cryptography

The public key cryptography (asymmetric key encryption) method uses different
keys, such as the Riverst-Shamir-Adleman (RSA) algorithm created by RSA
Security Inc., for encrypting and decrypting. For example if you encrypt
something with key 1, you can only decrypt it with key 2, as shown in Figure 2-5.
Key 1 Key 2
Plain Text Encryption Cipher Text Decryption Plain Text
Figure 2-5 Public key cryptography
The public key cryptography method allows the use of one public key and the
other private. This means that the recipient has a private key that is kept secret,
and a public key available to everyone. If a user wants to send an encrypted
message to another person, the sender looks up the recipient’s public key
(certificate) and uses it to encrypt the message. The message can only be
decrypted by the recipient’s private key.
1 2 3
Alice B B Bob
Plain Text Public Encrypted Text Private Plain Text
Alice A A
Bob
Plain Text Private Encrypted Text Public Plain Text
Figure 2-6 Using public key cryptography
Figure 2-6 shows a sample communication between two persons (Alice and Bob)
using the public/private key cryptography.
1. Alice wants to communicate with Bob but she does not want anybody to read
the messages. She will use Bob‘s public key to encrypt the message.
2. Alice sends the encrypted message to Bob.
3. Bob uses his private key to decrypt the message.
4. If Bob wants to responsd, he will use Alice‘s public key for encryption.
The advantages and disadvantages of public key cryptography are as follows:

򐂰 The advantage of public/private key cryptography vs the public method is that
the recipient uses his own private key to decrypt the message. In other words,
the owner does not need to transmit his private key to anyone in order to have
their message decrypted, which reduces vulnerability and risk.
򐂰 The disadvantage of a public/private key cryptography is that performance
can be greatly reduced if large amounts of data are transmitted, because the
public key algorithms are relatively slow.
Certificates
A digital signature is used to ensure that an electronic document has not been
altered. Digital signatures rely on certain types of encryption to ensure
authentication. Encryption is the process of encoding all of the data that one
computer sends to another in a form that only the other computer will be able to

decode. Authentication is the process of verifying that information comes from a
trusted source.
There are several ways to authenticate a person or information on a computer,

however the most common are as follows:
򐂰 Private key encryption
򐂰 Public key encryption
Digital certificates encrypt data using Secure Sockets Layer (SSL) technology,
the industry-standard method for protecting Web communications. The SSL
security protocol provides data encryption, server authentication, message
integrity, and optional client authentication for a TCP/IP connection. Because
SSL is built into all major Web browsers and servers, simply installing a digital
certificate turns on the browser’s SSL capabilities.
Transmitting sensitive data, such as credit card numbers and other personal data
across the Web and intranets requires authentication to ensure that the
destination of the data is legitimate. Also, encryption is used to protect the data
against interception or tampering, and message integrity to ensure that the
information is not tampered with during transmission. SSL is the standard
technology used to protect information transmitted over the Web via HTTP
protocol and protects against site spoofing, data interception, and tampering.
Certificates, which are based on the open standard X.509, contain the following
information:
򐂰 Version number (certificate format)
򐂰 Serial number (unique value from CA)
򐂰 Algorithm ID (signing algorithm used)
򐂰 Issuer (name of CA)
򐂰 Period of validity (from and to)
򐂰 Subject (user’s name)
򐂰 Public key (user’s public key and name of algorithm)
򐂰 Digital signature
򐂰 Created by CA
򐂰 Encrypted with CA’s private key
Managing certificates can be arduous. You can install your own Public Key
Infrastructure (PKI) and maintain it, or use the services of a Certificate Authority
(CA), such as VeriSign. CAs issue digital certificates and validate the holder’s
identity and authority. They embed an individual’s or an organization’s public key
along with other identifying information into each digital certificate and then
cryptographically sign it as a tamper-proof seal, verifying the integrity of the data
within it and validating its use.
2.3.2 WebSphere Portal security model
This section highlights the key features of the WebSphere Portal security model.
Member services
Centralized administration of user identities, credentials, and permissions is
desirable in many environments. The portal server includes facilities for defining
portal users and managing user access rights. The user and group subsystem
includes Web pages where users can register and manage their own account
information, administration portlets for managing user accounts and group
information, plus a repository that stores all the information about portal users. It
provides services to create, read, update, and delete users or groups in the
repository. User profile information includes general information such as the
name of the user and user ID, plus preference information such as news topics of
interest, preferred language, and so on. A user might be a member of one or
more groups, and groups can contain other groups.
The default set of user profile attributes is based on the inetOrgPerson schema,
which is supported by most LDAP directories. The user repository might consist
of multiple data sources. By default, the repository consists of two data sources:
It is a combination of a database and a directory server. The database might be
any of the databases that are supported by WebSphere Portal. Any one of
several LDAP directory products are supported, including the Netscape (iPlanet)
Directory Server, Microsoft Active Directory, Novell eDirectory, Lotus Domino,
and IBM Directory Server.
The mapping of user profile attributes to LDAP object classes is defined in the file
wms.xml. This file specifies the names of the various data repositories and how
they are navigated to retrieve user and group information. These settings are
configured differently for each supported LDAP directory; if you want to try using
a directory that is not supported, these values would need to be set appropriately
for that directory server.
The file attributeMap.xml specifies the details of how each attribute is mapped to
the LDAP directory or database. This mapping file also includes metadata about
each attribute such as its data type, whether it is required, whether it can have
multiple values, and so on.
Administration
Administration of users and groups can be performed by users themselves
known as self care or by portal administrators. The portal server includes forms
for registering new users and administration portlets for updating user and group
information.

The registration and self-care forms are easily modified to accommodate new
attributes. You can add new data entry fields to the form, matching the field
identifiers with the new attribute names. The enrollment servlet will automatically
store the new data in the corresponding user attributes. The WebSphere Portal
Information Center includes more information about customizing the
implementation of the user repository, registration and self-care pages, and data
validation classes.
Authentication
Authentication is the process of establishing the identity of a user. Usually, the
portal server uses the authentication services that are provided by WebSphere
Application Server. Another option is to use a third-party authentication server
(such as Tivoli Access Manager or Netegrity SiteMinder) that has a trusted
association with the application server.
Identifying the user

WebSphere Portal uses form-based authentication. Form-based authentication
means that a user is prompted through an HTML form for the user ID and
password for authentication when trying to access the portal. The portal server
requests the application server to validate the authentication information against
a Lightweight Directory Access Protocol (LDAP) user registry.
WebSphere Application Server uses Lightweight Third Party Authentication

(LTPA) as the authentication mechanism. A Common Object Request Broker
Architecture (CORBA) credential is used to represent authenticated users and
their group memberships. When a user tries to access a protected resource, the
application server intercepts the request and redirects the request to the login
form. This form posts the user ID and password to the portal that requests the
application server to authenticate the user. If the user can be authenticated, a
valid CORBA credential is created and an LTPA cookie is stored on the user's
machine. When using the IBM Tivoli Access Manager WebSEAL, the LTPA
token can be cached, in which case the LTPA token is not sent to the client Web
browser.
Third-party authentication servers

If your system uses another third-party authentication server, trust needs to be
established between that proxy and WebSphere Application Server. This is done
using a Trust Association Interceptor (TAI) module, which converts security
information that is specific to the authentication proxy into a format that can be
handled by the application server. The supported authentication mechanism
depends on the capabilities of the third-party product.
When a user tries to access the portal, the third-party authentication proxy
intercepts the request and challenges the user to authenticate. After a successful
login, the original user request, along with additional security information in the
request header, is passed to the application server. The format and content of
this information is vendor specific. WebSphere Application Server uses the TAI
module (that is specific to the third-party product) to extract the necessary
security information from the request header.
TAI modules for IBM Tivoli Access Manager and Netegrity SiteMinder are
packaged with the portal server (all editions). The WebSphere Application Server
InfoCenter includes information about creating custom TAI modules for other
third-party Reverse Proxy servers.
Single Sign-On
The portal server provides comprehensive single sign-on (SSO) support. Users
want to be able to log on only once, and be known to the different parts of the
portal server with the same consistent user credentials. Users should not be
asked to do multiple logons simply because they access different portal
applications.
The portal server supports single sign-on realms using WebSphere Application
Server and authentication proxies. This means that the user needs to log on only
once to gain access to all enterprise applications that are installed within the
single sign-on realm.
The WebSphere Application Server uses Lightweight Third Party Authentication

(LTPA) tokens to provide single sign-on. When a user is authenticated, the portal
server creates an LTPA single sign-on cookie containing the authenticated user
credential. This encrypted cookie conforms to the format that is used by
WebSphere Application Server and can be decrypted by all application servers in
the shared domain, provided they all have the same cipher key. This cookie
enables all servers in the cluster to access the user credentials without additional
prompting, resulting in a seamless single sign-on experience for the user. To
benefit from the LTPA method of single sign-on, the browser of the user must
support cookies and have its support for session cookies enabled.
Credential Vault
Refer to 2.3.6, “WebSphere Portal Credential Vault” on page 44, for details.
Persistent connections
Portlets that depend on remote connections require some way of maintaining
that connection as users navigate through the portal. The portal provides a
persistent back-end connection service that maintains TCP/IP connections
across page changes. Some remote applications use forms-based logins and
store cookies during the login form processing. The HttpFormBasedCredential
can be used for handling these form-based logins and will store all the cookies

that are returned as a result. For subsequent calls, the portlet can then ask the
credential for an authenticated connection. This gives an HTTP connection with
these cookies already set in the header. This way, portlets can maintain
persistent, secure back-end connections.
Java security
The portal server implements the Java Authentication and Authorization Service
(JAAS) architecture. JAAS provides a means for authenticating subjects and for
providing fine-grained access control. JAAS is part of the standard Java security
model; it gives applications independence from the underlying authentication and
authorization mechanisms that are being used. JAAS performs login and logout
operations using a modular service provider interface. Credentials that are
established through the portal server JAAS login modules include CORBA
credentials, user and group distinguished names, user ID and password, and
LTPA tokens. In a distributed J2EE environment, portlets can use the JAAS API
to access JAAS-enabled back-end applications.
Authorization
After determining the identity of the user, the portal server consults locally
cached access control lists to determine which pages and portlets a user has
permission to access.
The portal server enforces access control to portal assets, including portlets,
pages, and user groups. The access control lists are stored in the portal
administration database. It is also possible to manage access control for specific
resources in an external security manager, such as IBM Tivoli Access Manager
or Netegrity SiteMinder.
Access permissions are maintained using the Access Control administration

portlet. Use this portlet to assign roles to individual users or to groups of users for
specific portlets, pages, or documents. Roles are permission sets, such as the
ability to view and update the corresponding item. Users can also delegate the
permissions they hold to other users. When a role is assigned to a user or a
group on a container (such as a page that contains portlets or other pages, or a
folder that contains other folders or documents), that role is inherited downward
through the hierarchy unless it is specifically blocked. This makes managing
access within a document library or an area of the portal easy.
Granting view access to a page or place means that other users will see pages
and places when they log in. Granting view access to a portlet means that users
can add it to their pages when they customize their portal experience. Granting
edit access means that a user can set the portlet settings or change the contents
of a page. Manage access means that a user can perform view and edit
operations, and can delete the portlet or page.
Delegated administration
Granting view access to administration portlets is an effective way of delegating
certain administrative tasks to other portal users. Those users can add the
administration portlets to their personal pages, and then can perform whatever
task the portlet is designed to do. This way, the user does not have to be given
all administrative privileges or be added to the portal administrator group. Her
administrative abilities are limited to only those tasks that are covered by the
authorized portlets.
2.3.3 Tivoli Access Manager security model

This section is intended to provide a high-level overview of the key components
of the Tivoli Access Manager security model.
Note: For more detailed information on Tivoli Access Manager security and
administration, refer to the following:
򐂰 Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360,
product guide
򐂰 WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1359, product guide
SG24-6014, redbook
򐂰 Enterprise Business Portals II with IBM Tivoli Access Manager,
SG24-6885
򐂰 IBM Tivoli Access Manager for e-business, REDP3677
򐂰 A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager
V4.1, SG24-6077
Features and components

In a secure portal solution, the Tivoli Access Manager provides the network
security policy management framework, which provides the following key
features:
򐂰 Authentication
򐂰 Authorization
򐂰 Web single sign-on
򐂰 Centralized security management
򐂰 Secure communication
򐂰 Programmatic authentication and authorization
– aznAPI (C API)
– PDPermission

– Java Authentication and Authorization Services (JAAS)
򐂰 A complete authentication/authorization solution for Web, WebSphere MQ,
enterprise and legacy applications
The key components of Tivoli Access Manager are as follows:

򐂰 Policy Server
򐂰 Authorization Server
򐂰 WebSEAL
򐂰 Administration tooling
– pdadmin command line utility
– Web Portal Manager
򐂰 Supporting software and databases (Tivoli Directory Server, WebSphere
Application Server, DB2)
WebSEAL functionality
The Tivoli Access Manager WebSEAL is a resource manager responsible for
protecting the Tivoli Access Manager protected object space. The WebSEAL first
determines the identity of the client, and then if valid with the system the user is
authenticated. The WebSEAL then uses the identity of the validated user to
acquire credentials and evaluate if the user has proper authorization to the
protected resource.
The WebSEAL provides an important element of the single sign-on solution and
integrate back-end application resources into the security policy solution.
The WebSEAL typically acts as a Reverse Proxy by receiving HTTP/HTTPS

requests from Web browser clients. After the user identity is validated,
credentials for the user are acquired. The WebSEAL request will be evaluated by
the Tivoli Access Manager authorization service and, if permitted, the content
from the resource will be retrieved from the WebSEAL or from a junctioned
application (for example, ITSO Bank secure portal front-end portlet).
WebSEAL junctions provide a TCP/IP connection between the WebSEAL and

the back-end application server. The primary objectives of a junction are to
provide protection to the back-end application and a junction point into the Web
object space.
Databases used to maintain security policies

The security policies for a Tivoli Access Manager secure domain are maintained
and governed by two key security structures:
򐂰 User registry database (LDAP directory database, Lotus Domino, Microsoft
Active Directory)
The user registry contains all users and groups allowed to participate in the
Tivoli Access Manager secure domain.
In the ITSO working example secure portal solution, the Tivoli Directory
Server LDAP directory database (for example, ldapdb) contains the user
registry shared by the Tivoli Directory Server, Tivoli Access Manager,
WebSphere Portal and WebSphere Application Server.
򐂰 Master authorization (policy) database
The Tivoli Access Manager authorization database contains a representation
of all resources in the protected objects space of the secure domain. The
security administrator is responsible for implementing the access control list
(ACL) policies and protected object policies (POP) for resources that require
protection, which are stored in the authorization database.
Protected object space

The protected object space is a hierarchical representation of resources included
in the secure domain.
The physical resources in the object space that can be protected are as follows:
򐂰 System resource: This is an actual file or application resource.
򐂰 Protected object: This is a logical view of a physical resource referenced by
the Tivoli Access Manager authorization service, Web Portal Manager, or
pdadmin command line utility.
The security administrator can define policy templates that can be attached to
the objects in the object space to secure the resource. Policy templates can be
created and attached to the following object space categories:
򐂰 Web objects: Web objects include resources addressed by an HTTP/HTTPS
request to the WebSEAL.
򐂰 Tivoli Access Manager management objects.
򐂰 User defined objects: User-defined objects include customer-defined tasks or
resources protected by applications that use the authorization APIs.
The security administrator protects resources in a secure domain by defining

access control lists (ACLs) and protected object policies (POPs), and then
applying the ACLs and POPs to the objects. The Tivoli Access Manager
authorization service evaluates these policies to determine if access should be
permitted to the protected resource. Policies can be explicit or inherited.

2.3.4 Authentication
Authentication is a process in which the client identity is validated. The client can
be an end user, a machine, or an application.
In a secure portal solution, the Tivoli Access Manager WebSEAL is used to

enforce a high degree of security in the domain by requiring that each client
provide proof of identity. When a client is authenticated with WebSEAL, the user
is also logged into other software components and applications that share the
same LDAP directory user registry and have been configured for single sign-on
(for example, Tivoli Access Manager, WebSphere Portal and WebSphere
Application Server).
There are several key points regarding the WebSEAL and authentication. First,
the WebSEAL supports a standard set of authentication methods, as well as the
ability to be customized to support other authentication methods. Second, the
WebSEAL server process is independent of the authentication methods. Third,
regardless of the type of authentication, the WebSEAL requires that the client
identity obtain the credentials for the user. Fourth, the Tivoli Access Manager
authorization services use the credentials to permit or deny access to protected
objects after evaluating the access control list (ACL) permissions and protected
object policy (POP).
Authentication goals
Although WebSEAL is independent of the authentication process, WebSEAL
requires the client identity be valid to successfully authenticate the client. There
are two key goals of the authentication process:
򐂰 Authentication method results in client identity
򐂰 WebSEAL uses the validated identity to retrieve credentials
Authentication method results in client identity

The client authentication is only successful if the user has an account in the Tivoli
Access Manager user registry or is processed successfully by a Cross-domain
Authentication Service (CDAS). Otherwise the user is designated as
unauthenticated. There are several methods available in WebSEAL to process
identity information properties, such as username and password, certificates,
and tokens to authenticate a client. This information can be used to establish a
secure session with the server.
WebSEAL uses the validated identity to retrieve credentials

Once WebSEAL determines the client identity with that of a registered user in the
Tivoli Access Manager user repository, the clients credentials are acquired. The
credential determine a users privileges in the secure domain. The credential
include a username, group memberships, and special extended security
attributes describe the user in a specific content.
If a user is not a member of the user registry (anonymous) WebSEAL builds an

unauthenticated credential for that user.
Remember that an ACL can contain special rules governing unauthenticated

users. These credentials are available to the authorization service that permits or
denies access to requested objects in the WebSEAL protected object space.
Client request session and authentication data

When WebSEAL receives a client request, WebSEAL looks for session data first,
followed by authentication data. The initial client request does not contain
session data.
򐂰 Session data: The session data identifies a specific connection between the
client and the WebSEAL. Session data is stored with the client and
accompanies subsequent requests by the client. It is used to re-identify the
client session to the WebSEAL and avoid the overhead of establishing a new
session for each request.
WebSEAL supports the following session data types, and searches the for
the session data in the request in the order listed:
– SSL ID (defined by the SSL protocol)
– Server-specific
– BA header data
– HTTP header data
– IP address
򐂰 Authentication data: The authentication data is information from the client that
identifies the client to the WebSEAL. Authentication data types include
client-side certificates, passwords, and token codes.
WebSEAL supports the following authentication types, and searches for the
authentication data in the request in the order listed in Table 2-1.
Table 2-1 Authentication methods supported by WebSEAL

Authentication method Supported connection type
Failover cookie HTTP and HTTPS
CDSSO ID token HTTP and HTTPS
Client-side certificate HTTPS
Token passcode HTTP and HTTPS

Authentication method Supported connection type
Forms authentication (username and password) HTTP and HTTPS
Note: The ITSO working example secure portal

solution used forms authentication.
SPNEGO (Keberos) HTTP and HTTPS
Basic authentication (username and password) HTTP and HTTPS
HTTP headers HTTP and HTTPS
IP address HTTP and HTTPS
Authentication process flow

A key function of the WebSEAL is to determine the identity of the client through
the authentication process. Sites such as a secure portal typically have both
resources that can be accessed by authenticated and unauthenticated users. In
either case, the identity is needed to determine the credentials of the user and
access to a resource.
Process flow for an authenticated user

We have included a process flow example for an authenticated user. For
example, a customer using a Web browser would like to access his account
balance in the ITSO Bank secure portal application.
1. The customer enters a URL in the Web browser to access a resource that is
protected by the WebSEAL.
2. The WebSEAL determines that the user has attempted to access a protected
resource and will prompt the user with a logon page.
3. The user enters his username and password in the logon form and then
submits them to the WebSEAL.
4. The WebSEAL then interacts with the Tivoli Access Manager Policy Server to
validate the identity of the user in the Tivoli Access Manager user registry.
Client authentication is successful only if the user has an account defined in
the Tivoli Access Manager user registry or is processed successfully by a
Cross-domain Authentication Service (CDAS). Otherwise the user is
designated as unauthenticated. Method-specific identity information, such as
passwords, tokens, and certificates, represent physical identity properties of
the user. This information can be used to establish a secure session with the
server.
5. The WebSEAL creates a session ID for the user.
6. The WebSEAL uses the validated identity to obtain a credential for that user.
7. The session ID and credential are stored as an entry in the WebSEAL
session/credential cache.
8. The WebSEAL interacts with the Tivoli Access Manager authorization
services with the user credentials to permit or deny access to protected
objects (for example, bank account balance) after evaluating the access
control list (ACL) permissions and protected object policy (POP).
9. When the user logs off, the cache entry for that user is removed and the
session is terminated with the WebSEAL.
Process flow for an authenticated user

There are many situations where resources of a site such as a secure portal will
include resources that are accessible by unauthenticated users. For example,
the ITSO Bank application home page does not require an authenticated user.
1. The customer enters a URL in the Web browser to access a resource that is
not protected by the WebSEAL.
2. The WebSEAL determines that the user has attempted to access a resource
that is not protected (no logon page).
3. The WebSEAL builds an unauthenticated credential for the user.
4. No entry is created in the WebSEAL session/credentials cache.
5. The user can access resources that contain the correct permissions for the
unauthenticated type category of user.
Note: Unauthenticated → authenticated:

1. If the user requires access to a resource not available to unauthenticated
users, WebSEAL prompts the user to log in.
2. A successful login changes the user’s status to authenticated.
3. If login is unsuccessful, a 403 Forbidden message is returned. The user
can still continue to access other resources that are available to
unauthenticated users.
2.3.5 Authorization
The authorization process provides the capability to permit or deny access to
resources based on the policies and users who access the resources.
Both WebSphere Portal and Tivoli Access Manager provide authorization

solutions. The focus of this redbook is on the Tivoli Access Manager
authorization framework for a secure portal solution.

Authorization goals
Many systems providers include an authorization solution that is tightly coupled
to the application. The end result is that many authorization solutions are
employed each with different methodologies and administration tooling. This
complicates integration, and increases the cost of ownership.
The goals and benefits of the Tivoli Access Manager authorization framework
used in the secure portal solution are as follows:
򐂰 Centralized management of security policies
This not only streamlines the administration and systems used to manage
authorozation, but also reduces the cost of ownership.
򐂰 Leverage functionality of authentication framework
By leveraging the authorization framework, application development is more
rapid, which translates into quicker time to market.
򐂰 Proven authorization solution
IBM Tivoli Access Manager provide security authorization architecture that
has been thoroughly tested and proven in a production environment.
Defining and applying ACLs and POPs

The security administrator protects resources in a secure domain by defining
access control lists (ACLs) and protected object policies (POPs), and then
applying the ACLs and POPs to the objects. The Tivoli Access Manager
authorization service evaluates these policies to determine if access should be
permitted to the protected resource.
򐂰 Access control lists (ACLs)
An access control list is a set of rules or permissions that determine what
operations can be performed on the resource and who can perform the task.
An ACL policy can be made up of one or more users and groups and
specified rights. ACLs can also be defined for unauthenticated users.
򐂰 Protected object policies (POPs)
ACLs can be viewed as a yes/no decision by the authorization service,
whereas protected object policies (POPs) contain additional conditions to be
evaluated by the authorization service.
򐂰 Authorization rules
Authorization rules further define conditions that must be met before access
to a resource is permitted. Rules allow you to make authorization decisions
based on the context and the environment surrounding the request, as well as
who is attempting the access, and what type of action is being attempted.
These conditions are evaluated as a Boolean expression to determine if the
request should be allowed or denied.
A security policy can be explicity applied or inherited. The Tivoli Access Manager
object space supports inheritence of ACLs, POPs and authentication rules. The
security administrator needs to apply explicit policies only at points of the
hierarchy where the rules change, as seen in Figure 2-7.
Explicit
Rule
Inherited
Rule
Management Web User-Defined

Objects Objects Objects
Figure 2-7 Tivoli Access Manager explicit and inherited policies
Authorization process flow

The following example outlines the Tivoli Access Manager authorization process
flow.
1. An authenticated client request for a resource is directed to the resource
manager server and intercepted by the policy enforcer process. For example,
the resource manager can be WebSEAL for HTTP/HTTPS access or another
application.
2. The policy enforcer process uses the authorization API to call the
authorization service for an authorization decision.
3. The authorization service performs an authorization check on the resource.
4. The decision to accept or deny the request is returned as a recommendation
to the resource manager (through the policy enforcer).
5. If the request is finally approved, the resource manager passes the request
on to the application responsible for the resource.
6. The client receives the results of the requested operation.

2.3.6 WebSphere Portal Credential Vault
IBM WebSphere Portal includes the Credential Service and Credential Vault
features to allow portlet applications to pass user credentials to a back-end
application. The Credential Vault is a portal service that helps portlets and portal
users manage multiple identities. The credential vault stores credentials that
allow portlets to log in to applications outside the portal realm on behalf of the
user.
By default, this credential implementation is the portal database, but it also can
be a third-party component or another custom repository. Examples of
credentials include username and password, SSL client certificates, and private
keys. When using Tivoli Access Manager with WebSphere Portal to create
secure portal solution, the credential storage for the Credential Vault can be
moved to the Tivoli Access Manager Global Sign-on (GSO) lockbox.
Vault Implementations
Vault Service WebSphere Portal Vault
User-managed Segment (U)
Slot Ua
Slot Ub
Slot Uc
Administrator-managed
Segment (A1)
Slot A1a
Slot A1b
Slot A1c
Other Vault Implementation

Administrator-managed
Segment (A2)
Slot A2a
Slot A2b
Slot A2c
Figure 2-8 Credential Vault organization
Figure 2-8 depicts the Credential Vault organization. We will describe the
following elements of the Credential Vault in more detail:
򐂰 Vault segment
򐂰 Vault slot
򐂰 Credential objects
Vault segment
A vault is broken down into vault segments. Vault segments can be user- or
administrator-managed. However, portlets can only create slots in user-managed
segments. Creating slots in administrator-managed segments is limited to the
administrator. Credential creation and retrieval can be carried out by both user
and administrator in the portlets. Vault segments map to specific vault
implementations through vault adapters. A vault adapter is a plug-in used to
provide the Credential Vault service access to a certain credential repository.
Vault slot
A vault segment is partitioned further into vault slots. The slot is the actual
location for the user credential. Non-shared slots are specific to both the
back-end application and the user. Shared slots are specific only to the back-end
application.
The credential vault provided by the WebSphere Portal distinguishes between

four different types of vault slots:
򐂰 A system slot stores system credentials where the actual secret is shared
among all users and portlets. In this case, a group of portlets shares the same
password.
򐂰 A shared slot stores user credentials that are shared among the user’s
portlets.
򐂰 A portlet private slot stores user credentials that are not shared among
portlets.
򐂰 An administrative slot allows each user to store a secret for an
administrator-defined resource.
Credential objects
Credentials are returned in the portal in the form of credential objects. These can
be passive or active. Passive credential objects are containers for the
credential’s secret that can then be retrieved by the portlet to authenticate with
back-end. Active credential objects hide the credential's secret from the portlet in
such a way that there is no way of extracting it out of the credential. In return,
active credential objects offer business methods that take care of all the
authentication. A common passive object type returns username and password
credentials. An example of active authentication is HTTP Basic Authentication.

2.3.7 Tivoli Access Manager Global Sign-on (GSO)
Most Web applications support basic authentication for checking authenticity and
obtaining a user’s identity information. When using this support, an application or
the server the application is running on maintains a database with user IDs and
passwords (in the most simple case). In general, it is the operating system-based
user management on multiple Web servers, containing lists of user IDs and
passwords. After challenging a user and obtaining a user ID and password, an
application would look up the matching entry and, if one was found, the user was
considered authenticated and his or her identity was associated with the
provided user ID. In more sophisticated environments, relational databases,
legacy applications, or LDAP-based repositories are targeting that scope.
Tivoli Access Manager supports a flexible single sign-on solution that features
the ability to provide alternative user IDs and passwords to the Web application
servers.
The integration is achieved by creating SSO-aware junctions between WebSEAL

and Web servers hosting the applications. The Tivoli Access Manager Global
Sign-on (GSO) resources and GSO resource groups must first be created in
Tivoli Access Manager for every application. When WebSEAL receives a request
for a resource located on the SSO-junctioned server, WebSEAL queries the
Access Manager user registry for the appropriate authentication information. The
user registry contains a database of mappings for each user registered for using
that application, which provides alternative user IDs and passwords for specific
resources. The values of user IDs and passwords should match those stored in
the application home user registry.
The visible advantage of the solution is that no changes are supposed to be

made on the application side. However, the following issues should be
considered:
򐂰 Synchronization of the user IDs and passwords in the application’s home user
registry and Access Manager user registry.
򐂰 Storage of SSO passwords in the Access Manager user registry in plain text,
as they should be passed through to the application in clear. They could be
protected from the disallowed access, such as LDAP ACLs.
A special situation emerges if Access Manager and the secured application

share the same repository for storing user data, as shown in Figure 2-9 on
page 47. An LDAP directory is the most suitable platform for maintaining
application-specific information about users and groups. Given compatible LDAP
schemas, many applications may share the same LDAP directory. LDAP
provides a standardized way of authenticating users based on user ID and
password stored as user attributes. However, it provides no flexibility in defining
object classes to be used for authenticating a user rather than performing a call
based on primary identification attributes of a user (user ID and password).
While using an Access Manager GSO junction, Access Manager uses specific
LDAP attributes for storing GSO information for every GSO user. As a result, the
GSO user ID and password provided for a specific junction are not necessarily
the same as the primary ones. However, a junctioned application sharing the
same LDAP repository would then try to authenticate a user using these values
against primary ones (by doing LDAP bind or compare). The need arises to keep
the values of primary user IDs and passwords the same as GSO IDs and
passwords.
inetOrgPerson
Primary user ID (uid)

Common Primary user password (userPassword)
attributes
Object classes
Application X user object
and attributes
used by
applications Application Y user object
sharing LDAP Synchronization
Access Manager user object (secUser)
principalName
Access Manager GSO user object (eGSOUser)
GSO resource for Application X

Object classes
used by User ID
Access Manager
User Password
GSO resource for Application Y
User ID
User Password
Figure 2-9 LDAP shared by Access Manager and other applications

The following issues should be considered while looking for solutions for
integrating Tivoli Access Manager and Web applications using the same LDAP
repository:
򐂰 Main username and password are allowed to be in clear.
Tivoli Access Manager GSO passwords are always in clear. The possibility of
protecting LDAP data based on ACLs always exists.
򐂰 Change in main password should be reflected in GSO password.
Changing the main password should be reflected in the change of the GSO
password for a particular user. This can transpire immediately, for example
after a user changes his password, or in a batch run on a regular basis. The
last situation presumes that main passwords are in clear.
Another way to resolve the LDAP “bind-issue” while sharing the same LDAP
repository between Access Manager and secured Web applications is
maintaining separate user entries. For example, a different subset of users is
defined and maintained for Access Manager and its secured application. A user
may have the DN=CN=Jon Doe,O=IBM,C=US and DN=CN=Jon
Doe,OU=Access Manager,O=IBM,C=US for use by applications and Access
Manager, respectively, as shown in Figure 2-10 on page 48.
O=IBM,C=US
OU=Access Manager,O=IBM,C=US
CN=Jon Doe,O=IBM,C=US CN=Jon Doe,OU=Access Manager,O=IBM,C=US
uid: JDoe uid: JonDoe

userPassword: secret userPassword: ********
applicationX secUser
principalName: JonDoe
applicationY
eGSOUser
GSO resource
Synchronization User ID: JDoe
User password: secret
Figure 2-10 Shared LDAP with separate user entries
As a result, while performing authentication, the application will try to bind using
its own user IDs and passwords. The GSO user IDs and passwords could be
kept in sync more easily with those maintained by an application. The trade-offs
of this solution are:
򐂰 The need to maintain the user information sets per application sharing the
same LDAP.
򐂰 As the same user identity would exist multiple times, it would raise the direct
cost if the licensing of the LDAP software is on a per-user basis.
Tivoli Identity Manager

To address the user ID and password synchronization issues, IBM Tivoli Identity
Manager software can be used. It provides capabilities for provisioning and
management of Tivoli Access Manager users and GSO credentials.
Figure 2-11 on page 50 depicts the Tivoli Identity Manager provisioning and
password management of Tivoli Access Manager users and GSO credentials.

TAM Directory
Person
TAM UserID
TAM
Policy Server
TAM GSO Credential
TAM GSO Credential
TAM Admin
TAM Admin
over SSL
over SSL
TAM GSO Credential
TAM Node
TAM TAMGSO
Agent Agent
over SSL
over SSL
DAML
DAML
ITIM Directory
Person
TAMAccount TAM TAMGSO

Service Services
TAMGSOAccount ITIM Server

TAMGSOAccount
TAMGSOAccount
Figure 2-11 Tivoli Identity Manager
Note: For more detailed information on Tivoli Identity Manager refer to the
following redbooks:
򐂰 Identity Management Design Guide with IBM Tivoli Identity Manager,
SG24-6996
SG24-6014
3
Chapter 3. Architecture and topology

selection
This chapter describes operational models for the runtime and development
environments for secure portal solutions. The objective of this chapter is to define
the components and provide guidelines on selecting the appropriate topology.

򐂰 Topology definition and operational model
򐂰 Runtime environment topology selection
򐂰 Development environment topology selection
Important: The topologies defined in this chapter are intended as guidance

for real customer engagements. The ITSO working example chapters found in
Part 2, “ITSO working example secure portal solution” on page 141,
implement the entry-level secure portal topology. The entry-level topology
includes a Reverse Proxy node, Policy Server node, and Portal Server node.

3.1 Topology definition and operational model
This section is organized into the following topics:
򐂰 Operational model overview
򐂰 Topology zones
򐂰 Conceptual model
򐂰 Specified model
򐂰 Security interaction patterns
3.1.1 Operational model overview

In today’s e-business environment, most companies regardless of size know that
access to the Internet is essential in order to compete in the global marketplace.
While the benefits of being connected to the Internet are significant, so are the
risks. Connecting a private network to the Internet gives employees and
business partners access to information, but also supplies a pathway for external
users to access a company’s private information. Frequent stories in the media
regarding intruders gaining access to information via the Internet illustrate the
need to implement network and application security.
The operational model represents a network of computer systems, their

associated peripherals, and the systems software, middleware, and application
software that they run.
In general, the operational model includes the following:

򐂰 One or more diagrams that show the topology and geographic distribution of
the system, the node definitions, and network connections, as well as how
users and external systems interact.
򐂰 A detailed description of each node.
򐂰 A mapping matrix of deployment units to nodes. Each deployment unit is a
convenient grouping of components from the software architecture.
򐂰 A description of the system management strategy.
򐂰 A description of middleware services and products and the key middleware
choices.
򐂰 Descriptions of walkthroughs, which describe the flow of a business activity
from a user all the way through the system and back to the user.
Depending on the stage of analysis and design, nodes and connections may be
conceptual, specified, or actual physical computer systems:
򐂰 Conceptual corresponds to an early stage of design. Conceptual nodes
ignore many technological limitations and focus on application software
components, deferring treatment of middleware and other software.
򐂰 Specified refers to a detailed specification of a computer platform or network.
Technological limitations are fully taken into account, but the detailed choice
of technology is not made.
򐂰 Physical refers to the specific types of computers, networks, and software
that make up the system.
Generally an operational model develops from conceptual, and specified to

physical. Depending on the complexity of the problem and the starting point, it
may not be necessary to go through all three stages. At any one time, different
parts of the description may be at different levels.
The operational model is the main description of the systems architecture.

Without an operational model, or something very similar, it is hard to see how a
systems architecture of any complexity can be designed and developed. The
most obvious consequence is that some non-functional requirements will not be
met, and this will not be realized until late in the project.
This chapter covers the conceptual and specified model. It is used to refine the
runtime environments as described in 3.2, “Runtime environment topology
selection” on page 69.
3.1.2 Topology zones

A good starting point is to construct a set of guiding principles to help develop the
necessary infrastructure. In the past, networks evolved, meaning that as the
need for a service or access to an application became necessary, the network
grew to accommodate the requests. There was no unique beginning or endpoint.
Network architectures now require the input of security specialists, application

developers, and network professionals. All of these individuals affect the process
of the flow of data and clients on the network. Each individual brings the
necessary information for assembling building blocks where the logical and
physical design needs and expectations are, giving a clearer representation of
the enterprise. Building an architectural model that represents key components
and the connections or interfaces between components allows for a visual
picture of the business needs.
Chapter 3. Architecture and topology selection 53

Looking at the enterprise in this manner gives you the opportunity to visualize the
relationships among your basic systems. It should also enable you to drill down
into each component for the visualization of additional relationships.
A global vision suggests that the enterprise is more than its physical boundaries.
But localizing that perspective reduces the complexity of trying to install,
implement, and manage a security solution. To achieve this, you can base the
solution on an integrated, standards-based architecture. An open and adaptable
architecture helps minimize unseen flaws that can compromise the entire
infrastructure and reduce the availability of applications and information.
Add security design objectives to architecture

Adding security design objectives into your architecture creates a framework to
organize and validate the business environment and security risks. The
immediate benefit is saved time and lower costs to reach the outcome. However,
using a tried methodology gives a better-quality result with a quantitative tracking
method.
Security design objectives should outline how to achieve the following:

򐂰 Deploy and manage trusted credentials.
򐂰 Control access to stored information consistent with roles, responsibilities,
and privacy policies.
򐂰 Control access and use of systems and processes consistent with roles and
responsibilities.
򐂰 Protect stored or in transit information consistent with its classification,
control, and flow policies.
򐂰 Assure the correct and reliable operation of components and services.
Defend against attacks.
򐂰 Defend against fraud.
The IBM Method for Architecting Secure Solutions (MASS) provides design
objectives or, more simply put, a starting point. MASS includes the Common
Criteria, which is compliant with international standards that are comprehensive
and well accepted. MASS provides a set of security domains to help define the
threats to an enterprise (including actors/users, flow control, authorization,
physical security, and so on). It enables you to assign information assets to your
security domains that become crucial in the high-level design of the architecture.
Domain zone categories

The client utilizes the network to access applications and data. This client can be
from either within your enterprise or outside of it. Using the concept of security
domains you can translate Figure 3-1 into something more targeted, as shown in
Figure 3-2 on page 59.
Outside Zone Demilitarized Zone Production Zone Internal Network
Restricted
Protocol Firewall
Domain Firewall
Domain Firewall
Uncontrolled Controlled Controlled
Domain Firewall
Secured
Management Zone
Figure 3-1 Domain zone categories
Let us briefly explain what these domain categories stand for:

Uncontrolled Refers to anything outside the control of an organization.
Access from the uncontrolled environment to systems in
the controlled zone could be via a wide number of
channels.
Controlled Restricts access between uncontrolled and restricted (a
traditional DMZ).
Restricted Access is restricted and controlled. Only authorized
individuals gain entrance and there is no direct
communication with external sources (Internet).
Secured Access is available only to a small group of highly trusted
users. Access to one secured area does not necessarily
give access to another.
External Controlled An external zone in which data is stored by business
partners external to the systems where there is limited
trust in the protection of data (for example, credit reporting
agencies, banks, and government agencies).

Constructing your environment in this manner enables internal users to see out,
but external users can not see in. The benefits of constructing security domains
this way are:
򐂰 They are clear and efficient.
򐂰 They are easy to explain.
򐂰 They are easy to work with.
򐂰 They provide a complete design and implementation view, enabling you to
avoid errors.
򐂰 Fewer errors mean a lower risk of exposure and loss.
򐂰 Consistent use of recognized standards (common criteria, IBM Architecture
Description Standard).
MASS uses the common criteria definition of risk management as a framework,

identifying four key steps in risk management:
򐂰 Identification of vulnerabilities
򐂰 Identification of threats or threat agents
򐂰 Determination of the risk imposed
򐂰 Identification of available counter measures
Security risk management plays a big part in designing a secure solution, but so
does security assurance. If we define the risks to the system we must also
assure that we counter measure those risks providing assurance for the
correctness and effectiveness of the security solution. You will see these domain
designs throughout the book. Figure 3-2 on page 59 has clearly marked firewalls
to help you become familiar and comfortable with the placement and domain
concept.
Network zones
We have to consider four types of network zones and their transport
classifications in our discussion:
򐂰 Internet (uncontrolled zone)
򐂰 Internet DMZ (controlled zone)
򐂰 Production zone (restricted zone)
򐂰 Intranet (controlled zone)
Internet (uncontrolled zone)

The Internet is a global network (a network of networks) connecting millions of
computers. It cannot be controlled and should not have any components in it.
Internet DMZ (controlled zone)
The Internet DMZ is generally a controlled zone that contains components with
which clients may directly communicate. It provides a buffer between the
uncontrolled Internet and internal networks. Because this DMZ is typically
bounded by two firewalls, there is an opportunity to control traffic at multiple
levels:
򐂰 Incoming traffic from the Internet to hosts in the DMZ
򐂰 Outgoing traffic from hosts in the DMZ to the Internet
򐂰 Incoming traffic from internal networks to hosts in the DMZ
򐂰 Outgoing traffic from hosts in the DMZ to internal networks
The transport between a controlled and an uncontrolled zone is classified as

public. The transport between a controlled and another controlled or a restricted
zone is classified as managed.
Production zone (restricted zone)

One or more network zones may be designated as restricted, that is, they
support functions to which access must be strictly controlled and, of course,
direct access from an uncontrolled network should not be permitted. As with an
Internet DMZ, a restricted network is typically bounded by one or more firewalls,
and incoming/outgoing traffic may be filtered as appropriate.
The transport between a restricted and a controlled zone is classified as

managed. The transport between a restricted and a secured zone is classified as
trusted.
Intranet (controlled zone)

Like the Internet DMZ, the corporate intranet is generally a controlled zone that
contains components with which clients may directly communicate. It provides a
buffer to the internal networks.
Management zone (secured zone)

One or more network zones may be designated as a secured zone. Access is
only available to a small group of authorized staff. Access into one area does not
necessarily give you access to another secured area.
The transport into a secured zone is classified as trusted.
Other networks
Keep in mind that the network examples we use do not necessarily include all
possible situations. There are organizations that extensively segment functions
into various networks. However, in general, the principles discussed here may be
translated easily into appropriate architectures for such environments.

Placement of various data components within network zones is both a reflection
of the security requirements in play and a choice based on an existing or planned
network infrastructure and levels of trust among the computing components
within the organization. Requirement issues often may be complex, especially
with regard to the specific behavior of certain applications. With a bit of
knowledge about the organization’s network environment and its security
policies, reasonable component placements are usually easy to identify.
e-business security requirement and MASS

The IBM e-business methodology fits nicely with MASS domain concepts. MASS
is built on open and accepted standards. e-business patterns originate in IBM
product divisions and are provided as operational models that are also based on
open standards and technologies. Notice that the principles of the “Six A’s” of
e-business factor nicely into the overall plan as well:
Authorization Allowing only users who are approved to access systems,
data, application, and networks (public and private).
Asset protection Keeping data confidential by ensuring that privacy rules
are enforced.
Accountability Identifying who did what, when.
Assurance The ability to confirm and validate the enforcement of
security.
Availability Keep systems, data, networks, and applications
reachable.
Administration Define, maintain, monitor, and modify policy information
consistently.
In order for your network security solution to work, it must be based on

consistent, corporate-wide policies. A successful deployment requires that an
effective link be forged from the management definition of policy to the
operational implementation of that policy.
Tip: Plan your security polices around your business model, not the other way
around.
3.1.3 Conceptual model

The conceptual model of a secure portal solution sketches all required nodes
and provides detailed information at a conceptual level. The level of abstraction
affects the description of the conceptual nodes. For example:
򐂰 Numbers and location of users
򐂰 Location and nature of interfaces to external systems
򐂰 Business-related deployment units and their operational requirements (such
as resources, availability and security)
򐂰 Geographical location of these deployment units and the associated
decisions about their replication, distribution, etc.
򐂰 Identifying the nodes and connections required
Portal Domain
Reverse Proxy
Portal
Server Backend Domain
Node
Web Server App Server
Caching Proxy
Reverse Proxy Node Node
Public Key
Infrastructure Instant
Collaboration
Messaging
Node
Node
Web
Development
Browser
Domain
Client
Load Balancer
Portal
Internet
Directory Replica Database Domain

Rich Development
Domain Firewall
Domain Firewall
Protocol Firewall
Domain
Client Node
Data
Directory Server
Node Node
Domain
Name
Caching Proxy
Reverse Proxy
Server Domain Firewall

Load Balancer Hot Standby
Access Manager Domain
Policy App Web

Server Server Server
Node Node Node
Wireless
Gateway
Directory Domain
App Web Data

Mobile Directory
Client Node
Node Node Node
Management Zone
Legend:
Data related flows
Security related flows
Figure 3-2 Conceptual model of a secure portal solution
To focus on a real-world solution, we focus on the production zone and internal

network excluding the outside and firewall nodes. The zone topology reflects a
representative production environment as follows:
򐂰 Outside zone
It contains the public key infrastructure, and user and domain name services
that access the portal from the Internet.

򐂰 Demilitarized zone
This zone restricts the access to/from internal services of the portal. It
contains dispatcher and proxy nodes for load balancing and Reverse Proxy
services. It provides the gateway to authenticate a user and to pass verified
requests to the production zone. Caching Proxy nodes provides services to
statically and dynamically cache content, which results in performance
improvements.
򐂰 Production zone
The production zone provides presentation and business logic services. It is
accessible from the demilitarized zone or the internal network. It host the
portal and back-end systems as well as the directory replicas.
򐂰 Management zone
The management zone contains all mission-critical assets. It hosts the master
directories and security services like the policy management and rule engine.
򐂰 Internal network
The corporate intranet provides a development domain. Within the developer
domain a set of development services is provided to develop secure portal
solutions.
Figure 3-3 on page 61 shows the conceptual model highlighting key functional
aspects of the logical nodes. We now look more closely at each of these nodes
and explain what role they play in the runtime.
• Static Page Serving • Data Source Connectivity
Authentication • Servlet Redirector
Portal Domain • Business Logic
(Also request routing • Transaction Management
Reverse Proxy
and authorization) Portal • Content Transcoding
Server Backend Domain
Node
Web Server App Server
Caching Proxy
Load Balancing Node Node
Reverse Proxy
• Content Transcoding
Public Key (Request routing) • Access Control List
Infrastructure • Content Aggregation Instant
Collaboration
• Document Management Messaging
Advanced Caching Node
• Document Editors Node
Web (Also request
routing and • Credential Services Development
Browser • UDDI Directory Services
dynamic caching) Domain
Client
Load Balancer
Asynchronous Synchronous Portal
Internet
Directory Replica Database Domain

Rich Interaction Interaction Development
Domain Firewall
Domain Firewall
Protocol Firewall
Domain
Client (e-Mail) (e-Meeting, etc.) Node
Data
Directory Server
Node Node • Authentication &
Domain
Authorization Engine
Caching Proxy
Name
Reverse Proxy
• Rule-Based Policies
Server Domain Firewall • Role-Based Policies
Load Balancer Hot Standby

• Database supporting LDAP
• User Records Policy App Web
• Group Data Server Server Server
• Organizational Data Node Node Node
Wireless • Credential Repository
Gateway
Directory Domain
App Web Data

Mobile Directory
Client Node
Node Node Node
Management Zone
Legend:
Data related flows
Figure 3-3 Conceptual model with node functions
“Conceptual model node description for the runtime environment” on page 646
includes a detailed description for the following conceptual nodes:
򐂰 Load Balancer node
򐂰 Reverse Proxy node
򐂰 Caching Proxy node
򐂰 Portal Server node
򐂰 Directory node
򐂰 Data Server node
򐂰 Web Server node
򐂰 App Server node
򐂰 Policy Server node
򐂰 Collaboration node
򐂰 Instant Messaging node
򐂰 Portal Development node

3.1.4 Specified model
Based on the given conceptual model, we refine the description of the nodes by
specifying the characteristics within the boundary of the associated domain. At
that stage technological limitations are fully taken into account, but the detailed
choice of technology is not made.
The following factors affect the description of the specified nodes depending on
various levels of abstraction:
򐂰 Detailed specifications of connections, computer system, operating systems
characteristics, and non-functional characteristics, communications protocols,
middleware, quantity, etc.
򐂰 Systems management style (centralized, distributed), and systems
management protocol (for example, SNMP, CMIP).
򐂰 Software distribution method (for example, push, pull, attended, unattended,
number of servers, etc.).
򐂰 Help desk, problem management, configuration management, change
management, performance management, network management, and other
system management procedures, etc.
򐂰 Simulations and prototypes are developed and run to verify design decisions.
Note: For a detailed description of specified model nodes, refer to “Specified

model node description for the runtime environment” on page 656.
Portal Domain
Caching Reverse
Proxy App Proxy
Backend Domain
Server
SECP1 Node SIRP
Web Web Server App Server
Browser SPPORTAL Node Node
Client
Reverse SPHTTPD SPBANK
Proxy Instant
Collaboration Development
SERP1 Messaging Domain
Node
Node
Portal
SPDOMINO SPSAMETIME Development
Caching Node
Domain Firewall
Load Directory Database Domain
Internet
Proxy Replica Domain SIDEVELOP

Balancer
Protocol Firewall
Domain Firewall
SECP2 Directory Data Server
SELB Node
Node
SPLDAPR SPDB
Reverse
Proxy Domain Firewall
SERP2
Policy App Web
Node Node Node
SMTAM SMWAS1 SMHTTP1
Directory Domain
App Web Data
Directory
Node
Node Node Node
SMLDAP SMWAS2 SMHTTP2 SMDB
Management Zone
Legend:
Data related flows
Figure 3-4 Specified model of a secure portal solution
Figure 3-4 shows the nodes that are specified in Table 3-1 on page 64.
Restriction: The specified model covers performance-relevant characteristics

and is not intended to provide high-availability aspects. Therefore only one
Load Balancer node is specified.
The naming conventions for the specified nodes are:

򐂰 S indicates it is a node of the specified operational model.
򐂰 E/P/M/I indicates it belongs to the external zone, the production zone, the
internal development zone within the intranet, or the management zone.
򐂰 An abbreviation for the service, for example TAM stands for Tivoli Access
Manager.
򐂰 An optional number to distinguish similar nodes within a zone.

The node interaction matrix is shown in Table 3-1. It describes the relationship of
specified nodes with their characteristics, for example, which type of
communication protocol is used.
Table 3-1 Node interaction matrix

From To Characteristics
User SELB HTTP (80), HTTPS (443)
SELB SERP1,SERP2 HTTP (80), HTTPS (443)
SERP1,SERP2 SECP1,SECP2 HTTP (80), HTTPS (443)
SERP1,SERP2 SPLDAPR LDAP(389), LDAPS(636)
SERP1,SERP2 SMTAM TAM_SSL(7135,7136)
SMTAM SERP1,SERP2 TAM_SSL(7234)
SECP1,SECP2 SPPORTAL HTTP (9081), HTTPS (9444)
SPPORTAL SPHTTPD HTTP(80), HTTPS(443)
SPHTTPD SPBANK HTTP(9082), HTTPS(9445)
SPPORTAL SPDOMINO HTTP(80), HTTPS(443)
SPPORTAL SPSAMETIME HTTP(80), HTTPS(443)
SPPORTAL,SPDOMIN SPLDAPR LDAP(389), LDAPS(636)

O,SPSAMETIME
SPLDAPR,SPPORTAL, SPDB Database client/server

SPBANK connection ports
(50000,50001)
SMLDAP SPLDAPR LDAP(389), LDAPS(636)
SMLDAP,SMWAS2,SM SMDB Database client/server

WAS1 connection ports
(50000,50001)
SMHTTP1 SMWAS1 HTTP(9080), HTTPS(9443)
SMTAM SMLDAP LDAP(389), LDAPS(636)
SIDEVELOP SPPORTAL FTP(21)
3.1.5 Security interaction patterns
Based on the given specified model, we identified the common security
interaction patterns to develop and deploy a secure portal. The identified security
interaction patterns are classified based on their characteristics:
򐂰 Infrastructure (deployment related)
򐂰 Application (development related)
Infrastructure
The deployment of secure portal solutions is related to the implemented
infrastructure and topology as described in 3.1.2, “Topology zones” on page 53.
In general we can identify two patterns:
򐂰 Access to non-secured resources
򐂰 Access to secure resources
Access to non-secured resources

A secure portal solution may have assets that are not protected at all. In general,
the portal provides public information and portlets that are accessible to the
public.
1 2
User Load Balancer
4
6
Reverse Proxy Application
5
Directory
Figure 3-5 Non-secured access
Therefore the interaction flow between the involved nodes is as follows:

1. A user browses and sends a request to the secure portal site.
2. The request is routed to the Load Balancer, which routes the request to the
next available Reverse Proxy.

3. The Reverse Proxy accesses the directory to verify if the requested resource
is protected.
4. The Reverse Proxy redirects the request to the back-end system, including
back-end related security credentials fetched from the directory.
5. The request is processed by the back-end and the result is passed to the
Reverse Proxy.
6. The Reverse Proxy redirects the response to the user’s browser.
Access to secure resources

A secure portal solution has assets which are protected. Therefore, the user has
to be authenticated and authorized to access the protected assets.
1 2
User Load Balancer
4 6
Reverse Proxy 7 Application
8
5
Policy Server
3
Directory
Figure 3-6 Secured access
Figure 3-6 is explained below:

1. A user browses and sends a request to the secure portal site.
2. The request is routed to the Load Balancer, which routes the request to the
next available Reverse Proxy.
3. The Reverse Proxy verifies the cached ACL-DB to check if the requested
resource is protected.
4. The user is prompted for identification (form-based login, certificates, etc.).
5. The user’s credentials are verified between the Reverse Proxy and Policy
Server. If access is granted the security credentials are associated with the
corresponding request.
6. If access is granted the Reverse Proxy redirects the request to the back-end
system, including back-end related security credentials.
7. The request is processed by the back-end and the result is passed to the
Reverse Proxy.
8. The Reverse Proxy redirects the response to the user’s browser.
Application
The application security variations are important in order to define the
relationship between the policy server capabilities and the runtime environment
for the application. An application can be classified as a collection of resources
such as HTML forms, JSPs, servlets, back-end classes, and beans. Each one of
the resources has some or no security context or interface. We can group the
application security into three main categories:
򐂰 Programmatic approach
򐂰 Declarative approach
򐂰 Mixed approach
Programmatic approach
When applications control security by themselves using an internal proprietary
process, code, and database to grant, deny, log, and manage security, they have
implemented programmatic access control. Generally, the applications request
principal information about users and resources, and they use security API calls
to retrieve access control information for those principals. Finally, the application
logic enforces security by granting or denying access to specific resources
provided by the application.
Using this approach, applications become the decision factor for security and
may even bypass important security checks. Usually this is done when there is
no general infrastructure in place to handle security. This encompasses all
resources for the application such as Web pages, back-end classes, and EJBs, if
available.
Declarative approach
Applications use declarative access control by using an external source for the
actual access control checking. There is no proprietary logic, and the application
communicates with the access control system using a specific and well-known
set of rules defined by an API interface. The application does not implement or
combine access rules, it just uses the ones provided, limiting the access control
check to what the API can offer.
After querying the access control subsystem as to whether a given principal may
access a requested resource, the application receives a simple yes or no
answer, and based on that answer it either grants or denies the respective

access. This can be considered the ideal situation, since it defines the scope and
responsibility of the application in the authorization request and transaction
execution steps. This also implies that the application does not control the actual
flow of the logic, and that it is more difficult, if not impossible, to bypass the
authorization layer in this case.
Mixed approach
This is not really a category of its own, but covers the situation where
applications benefit from the infrastructure available when possible (using
declarative techniques) and implement only a few special controls using
standard API calls (ideally compliant with JAAS, J2EE, or some other well-known
standard). We recommend that you carefully use the programmatic approach to
enhance the rule checking mechanism by providing fine-grained access controls
when there is a lack of native APIs to offer that capability, but still utilizing one
unique API set to handle the core requests.
Figure 3-7 shows each application component separated in secure/non-secure

sections. Since we want to discuss the security measures that we can
accommodate in Access Manager, we concentrate on examining the secure
components.
Application X
Transactional
Backend Interface Pages
Objects
Class Files (JSP, HTML,Portlets)
(EJB)
Non- Non- Non-

Secure Secure Secure
Secure Secure Secure
Figure 3-7 Simple application security categories
Figure 3-8 on page 69 provides a view for each secure component showing
which kind of controls we can add using access management capabilities, and
combining those possibilities with the application categories.
Application X
Transactional
Backend Interface pages
Objects
Class Files (JSP, HTML,Portlets)
(EJB)
Secure Secure
Secure Non- Non- Non-
Declarative: Declarative: Realms
Programmatic: Secure Secure Secure
Reverse Proxy (i.e. WebSeal) Programmatic: In-house or
Policy Server Permissions
Programmatic: Session Control Policy Server Permissions
Figure 3-8 Security options for each application component
Note: For more detailed information, refer to the WebSphere application

integration chapter in the Enterprise Security Architecture Using IBM Tivoli
Security Solutions, SG24-6014, redbook.
3.2 Runtime environment topology selection

Based on the given specified model, we refine the physical nodes by specifying
the characteristics within the boundary of the associated domain. At that stage
technological limitations are fully taken into account and the detailed choice of
technology is made. The following factors affect the description of the physical
nodes depending on various levels of abstraction:
򐂰 A UNIX system becomes more specific, such as IBM-AIX, SUN Solaris,
HP-UX.
򐂰 Systems management tools (for example, Tivoli products, IBM NetView®, HP
OpenView, etc.).

򐂰 Non-functional characteristics are specified, for example, latency of network
connections, availability, performance, network redundancy routes, and
equipment.
򐂰 High availability systems, for example, IBM HACMP™, multi-protocol Cisco
router, TCP/IP, SNA, IPX, OSPF, APPN-capable router
The physical operational model provides the necessary information to set up the
runtime environment and development environment.
Note: The sizing of the physical nodes is fictitious and does not reflect the
sizing requirements in a real-life production scenario.
The naming conventions for the physical nodes are listed below:
򐂰 P indicates it is a node of the physical operational model.
management zone, or the internal zone where the development domain is
located.
򐂰 An abbreviation for the machine’s host name, for example, PERP stands for
Reverse Proxy.
The node interaction matrix is shown for each runtime scenario. It describes the
relationship of physical nodes with their characteristics, for example, which type
of communication protocol is used.
3.2.1 Entry runtime topology
Note: The ITSO working example chapters found in Part 2, “ITSO working
example secure portal solution” on page 141, implement the entry runtime
topology for a secure portal solution.
The entry runtime topology is the minimal setup to deploy a secure portal
solution for a production environment. It consists of at least three physical nodes
as follows:
򐂰 The Reverse Proxy node, which provides the gateway to control access to the
back-end application in the production zone.
򐂰 The Portal Server node, which contains the portal solution, including
database components, Web server components, and application server
components.
򐂰 The Policy Server node, which encompass directory components, policy
components, and database components.
Figure 3-9 on page 72 illustrates the entry runtime model in detail. The
deployment of the node is based on best practices and follows the
recommendations of 3.1.2, “Topology zones” on page 53:
򐂰 The Reverse Proxy node is deployed within the controlled demilitarized zone.
򐂰 The Portal Server node is deployed within the restricted production zone
accessible via the Reverse Proxy from the outside.
򐂰 The Policy Server node is deployed within the secured management zone,
The entry runtime topology provides a consistent setup of the involved

component and provides the following capabilities:
򐂰 Secured access to the portal solution via the Reverse Proxy leveraging single
sign-on.
򐂰 Enterprise directory services within the management zone.
򐂰 Policy services to process access control, authentication and authorization
requests.
򐂰 Sophisticated portal environment to deploy, run and manage the secure
portal solution.
򐂰 Usage of the built-in Web server capability within the application server to
improve performance and to reduce the complexity.
Note: The entry runtime topology is well suited for a test/development

environment. In this case firewall settings might be out of scope.

• IBM WebSphere Portal Extend V5.0.2.1

• IBM WebSphere Application Server Enterprise 5.0.2.3
• IBM DB2 UDB 8.1.4, ESE
• IBM JRE 1.3.1
• Tivoli Access Manager 5.1 (PDJRTE)
• Microsoft Windows 2000 Server + SP4
Web • Tivoli Access Manager

Browser Portal/Backend Domain
5.1.0.2 (Runtime, PDJRTE,
Client Web Security, WebSeal)
• IBM GSKit 7.0.1.16 PPBANK
• IBM JRE 1.3.1
• Microsoft Windows 2000 SPPORTAL SPHTTPD SPBANK SPDB
Protocol Firewall
Domain Firewall
Server + SP4
Internet
Reverse Proxy Domain Firewall
PERP
Access Manager/Directory Domain
SERP1
PMTAM
SMTAM SMLDAP SMDB SMHTTP2
• Tivoli Access Manager 5.1.0.2

(Runtime, PDJRTE, Policy, Authorization, Web Portal Mgr)
• Tivoli Directory Server 5.2 (Server, Client SDK, Web
Administration Tool)
• IBM DB2 UDB 8.1.4, ESE
• IBM GSKit 7.0.1.16
• IBM JRE 1.3.1
• IBM WebSphere Application Server 5.0.2
• Microsoft Windows 2000 Server + SP4
Management Zone
Legend:
Data related flows
Figure 3-9 Physical model for the entry runtime
The entry runtime topology is limited as follows:

򐂰 Provides no high-availability and fail-over capabilities.
򐂰 Restrictions in terms of performance aspects.
򐂰 Support of vertical scalability aspects (for example, scalability is limited to the
given hardware box using logical partitioning and cloning aspects within the
application server).
However, it can scale up to an enterprise topology by adding additional nodes.

Figure 3-2 on page 73 gives a brief overview of the node interactions.
User PERP HTTP (80),

HTTPS(443)
PERP PPBANK HTTP(80)

(optional HTTPS(443))
PERP PMTAM LDAP(389)

(optional LDAPS(636))
TAM_SSL(7135,7136)
PMTAM PERP TAM_SSL(7234)
PPBANK PMTAM LDAP(389)

(optional LDAPS(636))
TAM_SSL(7135,7136)
3.2.2 Enterprise runtime topology

The enterprise runtime topology extends the entry runtime topology as follows:
򐂰 Extensive placement of specified nodes on a set of physical nodes.
򐂰 Performance capabilities to balance load behavior.
򐂰 Separation of directory capabilities and policy services.
򐂰 Provisioning of master directory entries to a set of replica directories.
Note: For more information on LDAP refer to the Understanding LDAP -

Design and Implementation, SG24-4986-01, redbook. Chapter 13,
“Replication,” includes good design guidelines for directory replicas.
The enterprise runtime extends the placement of nodes within the topology
zones as follows:
Demilitarized zone Load Balancer capabilities to dispatch incoming requests
from the outside zone to a cluster of managed servers.
Reverse/caching proxies to secure the access to
applications.
Production zone Separation of the Portal Server node and the involved
back-end systems.
Providing directory replica nodes, which are optimized for
read access only.
Database cluster for high availability.
Management zone Separation of the master enterprise directory and the
policy server capabilities including the administration
components.

The master enterprise directory rules the replication
schedules to synchronize the directory replicas.
From an architectural point of view their are two approaches to build a secure
demilitarized zone using:
򐂰 Reverse proxies
򐂰 Plug-ins
Reverse Proxy approach

The Reverse Proxy approach is the one of choice since it provides a solid
security infrastructure by introducing Reverse Proxy capabilities. For
performance reasons a set of Reverse Proxy nodes can be placed balanced
through the Load Balancer node. Each physical Reverse Proxy node caches
directory entries to improve performance while connected to directory replicas for
security reasons. In addition, they communicate via a secure channel with the
policy server to verify authorization and authentication requests. If access is
granted then the request is passed to the corresponding back-end system. For
each back-end system a so-called junction is defined, which rules the mapping.
For performance reasons the Reverse Proxy node is capable to handle incoming
HTTPS requests while passing HTTP requests to the back-end system.
Therefore the SSL processing time can be improved significantly if hardware
accelerators are used.
In a production zone the services will be split across a set of physical nodes such
that the portal-related tasks are handled by the Portal Server node, the back-end
systems are handled by dedicated physical nodes, and the directory read-only
replicas support the authentication requests as well as the advanced
configuration capabilities. In addition, the database node(s) provides high
availability features and scalability features for the enterprise.
The management zone contains a set of physical nodes to provide a master

enterprise directory and a centralized policy server including authorization
services. The master enterprise directory is enabled for read/write access within
the management zone to be manipulated either by the graphical user interface or
the policy server. Modified entries will be replicated according to the definitions of
the master enterprise node.
The Reverse Proxy approach provides a rich set of security settings, but it has to
be taken into account that the installation, configuration, deployment tasks are
complex. Therefore the setup has to be planned carefully.
Outside Zone Demilitarized Zone Production Zone WebSphere Internal Network
WebSphere Portal Extend 5.0.2.1 Application
Server 5.0.2.3
Portal Domain
Tivoli Access Manager 5.1.0.2
(WebSEAL) PPPORTAL
Backend Domain
Web SPPORTAL
Browser Reverse PPBANK
Proxy Lotus
Client Sametime
Lotus Domino/Notes SPBANK
SPHTTPD
PERP1
WebSphere Edge SERP1 PPNOTES PPST

Components Development
Tivoli Directory Server 5.2 SPDOMINO SPSAMETIME Domain
Load
Balancer Directory DB2 Database PIDEV
Internet
Replica Domain Domain

Protocol Firewall
Domain Firewall
Domain Firewall
PELB
SIDEVELOP
PPLDAPR PPDB
SELB
SPLDAPR SPDB
Reverse Tivoli Access Manager 5.1.0.2
Proxy (Policy and Authorization)
Domain Firewall
PERP2
SERP2
PMTAM
• Tivoli Directory Server 5.2
SMTAM SMWAS1 SMHTTP1 • DB2
(WebSEAL)
Directory Domain
PMLDAP
Management Zone
Legend:
Data related flows
Figure 3-10 Physical model of the enterprise model using reverse proxies
Restriction: The physical model covers performance-relevant characteristics


User PELB HTTP(80), HTTPS(443)
PELB PERP1,PERP2 HTTP(80), HTTPS(443)
PERP1,PERP2 PPLDAPR LDAP(389),

LDAPS(636)

PERP1,PERP2 PMTAM TAM_SSL(7135,7136)
PERP1,PERP2 PPORTAL HTTP(9081),

HTTPS(9444)
PPPORTAL PPBANK HTTP(80)
PPPORTAL PPST IIOP
PPPORTAL PPNOTES HTTP(80),HTTP(443)

IIOP
PPORTAL,PPBANK PPLDAPR LDAP(389),

LDAPS(636)
PPORTAL,PPLDAPR,PPB PPDB DB(50000,50001)

ANK
PMTAM PMLDAP LDAP(386),

LDAPS(636)
PMLDAP PPLDAPR LDAP(389),

LDAPS(636)
PIDEV PPPORTAL FTP(21)
Plug-in approach
The plug-in approach has the advantage of implementing a secure infrastructure
in three phases:
1. Implementation of the topology zones including the load balancing and
caching proxy components. Setting up the enterprise directory and policy
services without enabling the security capabilities in the demilitarized zone.
2. Enabling the plug-in capability to perform authorization and authentication
requests.
3. Leveraging the plug-in by extending existing Web servers.
For performance reasons, a set of Caching Proxy nodes can be provided

balanced through the Load Balancer node. Each physical Caching Proxy node
includes the security plug-in to connect to directory replicas for security reasons.
In addition, they communicate via a secure channel with the policy server to
verify authorization and authentication requests. If access is granted, then the
request is passed to the corresponding back-end system. For each back-end
system a so called junction is defined, which rules the mapping.
configuration capabilities. In addition, the database node(s) provides
high-availability features and scalability features for the enterprise.
Outside Zone Demilitarized Zone Production Zone WebSphere Internal Network

WebSphere Portal Extent 5.0.2.1
Application
Server 5.0.2.3
• WebSphere Caching Proxy Portal Domain
• Tivoli Access Manager
5.1.0.2 Plugin PPPORTAL Backend Domain
Web SPPORTAL
Caching/ PPBANK
Browser
Plugin Proxy Lotus
Client Lotus Domino/
SPHTTPD SPBANK Sametime
PECP1 Notes
WebSphere Edge SECP1 PPNOTES PPST

Components Tivoli Directory
Development
Server 5.2 SPDOMINO SPSAMETIME Domain
Load
Balancer Directory DB2 Database PIDEV
Internet
Replica Domain
Protocol Firewall
Domain
Domain Firewall
PELB
Domain Firewall
SIDEVELOP
SELB PPLDAPR PPDB
SPLDAPR SPDB
Caching/
Plugin Proxy Tivoli Access Manager
Domain Firewall
5.1.0.2 (Policy and
PECP2 Authorization.)
SECP2
PMTAM

• WebSphere Caching Proxy • Tivoli Directory
• Tivoli Access Manager Server 5.2
5.1.0.2 Plugin • DB2
Directory Domain
PMLDAP
Management Zone
Legend:
Data related flows
Figure 3-11 Physical model of the enterprise runtime based on security plug-ins

enterprise directory and a centralized policy server, including authorization

The plug-in approach provides a flexibility to enable existing components like
caching proxies and Web servers to support authentication and authorization
capabilities by leveraging a corporate security infrastructure.



LDAPS(636)
PMTAM PERP1,PERP2 TAM_SSL(7234)
PECP1,PECP2 PPORTAL HTTP(9081),

PPPORTAL PPBANK HTTP(80)
PPPORTAL PPST IIOP
PPPORTAL PPNOTES HTTP(80), HTTP(443)

IIOP

LDAPS(636)
PPORTAL,PPLDAPR,PPB PPDB DB(50000,50001)

ANK

LDAPS(636)

LDAPS(636)
PIDEV PPPORTAL FTP(21)
3.2.3 Extended enterprise runtime topology
The extended enterprise topology provides a very solid security infrastructure by
combining Reverse Proxy and caching proxy capabilities as follows:
򐂰 Strong secured demilitarized zone.
򐂰 High-availability and scalability capabilities within the demilitarized zone.
򐂰 Authentication and authorization requests are enforced.
򐂰 Advanced caching capabilities for static and dynamic content while the
request already passed the authentication and authorization process.
For performance aspects, a set of Reverse Proxy nodes can be placed balanced
through the Load Balancer node. Each physical Reverse Proxy node caches
directory entries to improve performance while connected to directory replicas for
security reasons. In addition, they communicate via a secure channel with the
policy server to verify authorization and authentication requests. If access is
granted, then the request is passed to the corresponding Caching Proxy nodes.
The caching proxies have the capability to cache static and dynamic content.
The Reverse Proxy node is capable of dispatching the request across a set of
caching proxies.
For performance reasons the Reverse Proxy node is capable of handling

incoming HTTPS requests while passing HTTP requests to the back-end system.
Therefore, the SSL processing time can be improved significantly if hardware
accelerators are being used.
configuration capabilities. In addition, the database node(s) provides
high-availability features and scalability features for the enterprise.

enterprise directory and a centralized policy server, including authorization
The extended enterprise runtime topology provides the richest set of security and
performance capabilities, but it has to be taken into account that the installation,
configuration, and deployment tasks are complex. Therefore the setup has to be
planned carefully.

WebSphere Portal Extend 5.0 • WebSphere Application
WebSphere Caching Proxy Server 5.0.2.3
Portal Domain • IBM HTTP Server 1.3.26 Reverse
Tivoli Access Manager Caching Proxy
5.1.0.2 (WebSEAL) Proxy PPPORTAL
Backend Domain PIRP
PECP2 SPPORTAL
Web
Reverse PPHTTP PPBANK SIRP
Browser SECP2
Proxy
Client
Lotus Domino/Notes SPHTTPD SPBANK
PERP1 Lotus Sametime
WebSphere Edge SERP1 PPNOTES PPST

Components Tivoli Directory
Caching Development
Server 5.2 SPDOMINO SPSAMETIME
Proxy Domain
Domain Firewall
Load
Domain Firewall
Balancer PECP1 Directory Database PIDEV
Internet
Replica Domain DB2 Domain

Protocol Firewall
PELB SECP1
SIDEVELOP
SELB PPLDAPR PPDB
WebSphere Caching Proxy SPLDAPR SPDB

Reverse
Proxy
Domain Firewall
PERP2 Tivoli Access Manager 5.1.0.2
(Policy and Authorization)
SERP2 Access Manager Domain
PMTAM

Tivoli Access Manager
5.1.0.2 (WebSEAL) • Tivoli Directory Server 5.2
• DB2
Directory Domain
PMLDAP
Management Zone
Legend:
Data related flows
Figure 3-12 Physical model of the extended enterprise runtime



LDAPS(636)
PMTAM PERP1,PERP2 TAM_SSL(7234)
PERP1,PERP2 PECP1,PECP2 HTTP(80), HTTPS(443)
PECP1,PECP2 PPORTAL HTTP(9081),

PPPORTAL PPHTTP HTTP(80),

PPHTTP PPBANK HTTP(9083)
PPPORTAL PPST IIOP
PPPORTAL PPNOTES HTTP(80), HTTP(443)

IIOP

LDAPS(636)
PPORTAL,PPLDAPR,PPB PPDB DB(50000)

ANK

LDAPS(636)

LDAPS(636)
PIDEV PIRP FTP(21)
3.3 Development environment topology selection

This section covers the topics to develop, test, integrate and deploy secure portal
solutions. Therefore the development and testing environment is critical in order
to:
򐂰 Develop and test the application in an infrastructure environment that
provides the necessary components.
򐂰 Design, develop, and test the applications leveraging the security-related
APIs.
Based upon the selected runtime topology, the life-cycle to develop and deploy
secure portal solutions covers the following stages:
򐂰 Develop and unit-test the solution (developer perspective).
򐂰 Integration tests based on a test environment (the solution perspective).

򐂰 Pre-production tests (performance analysis and tuning aspects).
򐂰 Deployment within the production (solution goes live).
Figure 3-13 illustrates the end-to-end steps to develop, test, optimize, and deploy
a secure portal solution. The developer develops source code and performs
unit-tests. If they pass the unit-test, a package is created with additional
information for integration on a test environment. When tests have passed, the
package is prepared for a pre-production deployment, including further release
documentation. Within the pre-production environment the performance
characteristics are analyzed and, if necessary, the solution has to be tuned. If it
passes the pre-production tests the package is ready to be deployed to a
production environment. At that time the secure portal solution is deployed and
accessible by the customers.
In case of an error, the application is analyzed within the pre-production

environment. The analysis outcome is passed to the developer based on a
trouble ticket, which contains detailed information about the error and its
behavior. The assigned developer fixes the error and passes the corrected
module to the test environment.
Development Test/Integration Pre-Production Production

(Optional)
Module A
Module B
Handover Handover Handover
Tuning Performs
Module C
Fix to be tested
Analysis Error
Passed to the developer
Module C
Figure 3-13 End-to-end development life-cycle
To derive a set of runtime topologies for development/test environments we

cover the following topics:
򐂰 Conceptual model of the involved nodes to set up a development and test
environment
򐂰 Specified model of the involved nodes with their characteristics
򐂰 A set of topologies to provide a development/test environment
򐂰 Teaming aspects when developing and deploying secure portal solutions
3.3.1 Conceptual model

The conceptual model of the development/test environment sketches all required
nodes and provides detailed information at a conceptual level. The level of
abstraction affects the description of the conceptual nodes, such as:
򐂰 Numbers and location of developers
򐂰 Location and nature of interfaces to external systems for testing purposes
򐂰 Business-related deployment units and their operational requirements (such
as resources, availability and security)
򐂰 Identifying the nodes and connections required for deployment information
Development Repository
Node Node
Reverse Proxy Portal Server

Node Node
Directory Server Data Server

Node Node
Policy Server
Node
Figure 3-14 Conceptual model of the development and test environment
Note: For a detailed description of the conceptual model nodes in the

development and test environment, refer to “Conceptual model node
descriptions for development” on page 670.

3.3.2 Specified model
Based on the given conceptual model, we refine the nodes by specifying the
characteristics within the boundary of the associated development/test domain.
At that stage technological limitations are fully taken into account but the detailed
choice of technology is not made. The following factors affect the description of
the specified nodes depending on various levels of abstraction:
򐂰 Detailed specifications of connections, computer system, operating systems
characteristics, and nonfunctional characteristics, communications protocols,
middleware, quantity, etc.
򐂰 Problem management, configuration management, change management,
performance management etc.
򐂰 Simulations and prototypes are developed and run to verify design decisions,
etc.
Development Repository
Node Node
SDWB SDREP
Reverse Proxy Portal Server

Node Node
SDRP SDPORTAL
Directory Server Data Server

Node Node
SDLDAP SDDB
Policy Server
Node
SDTAM
Figure 3-15 Specified model of the development and test environment
The naming conventions for the specified nodes are listed below:
򐂰 S indicates that it is a node of the specified operational model.
򐂰 D indicates that it belongs to the development zone within the internal
development zone.
򐂰 An abbreviation for the service, for example TAM stands for Tivoli Access
Manager.
Note: For a detailed description of the specified model nodes in the

development and test environment, refer to “Specified model node description
for development and test environment” on page 676.
3.3.3 All-in-one approach

The All-In-One approach has the aim to implement all specified components on
one physical machine. It implies that the underlying hardware is powerful enough
to run the instances of the selected software components (with performance
constraints). It is capable of providing a single development environment as
follows:
򐂰 An unique environment to develop secure portal solutions
򐂰 A single development environment with a maximum of independence
򐂰 Demonstration capabilities
򐂰 Full coverage of the required security aspects
It is not recommended for a test environment setup due to the following

restrictions:
򐂰 Lack of performance-relevant characteristics
򐂰 Lack of stress tests and integration tests
򐂰 Restricted support for team development
To implement the all-in-one approach, the developer node, the Portal Server
node, and the Repository node are installed on the physical node. This allows a
developer to develop portal-related assets and to test them without security
aspects. Enabling security capabilities leads to use of a virtualization engine
such as VMWare. We have to establish two virtual machines on the physical
node that implements the security components as follow:
򐂰 One virtual machine implements the Reverse Proxy node.
򐂰 One virtual machine implements the Policy Server node, Directory node, and
Data Server node.
Figure 3-16 illustrates the all-in-one approach with the deployed specified nodes
on the physical node and the virtualized nodes.

Physical Machine using VMWare for Test Nodes
SDWB
PDWB SDPORTAL
SDREP
(WebSEAL)
• WebSphere Studio Application

Developer 5.1.1
PDRP • WebSphere Portal Toolkit and
SDRP
Test Environment 5.0.2.1
• CVS
• Windows 2000 + SP4
SDTAM
PDTAM SDLDAP
SDDB
Legend :
• Tivoli Access Manager 5.1.0.2
Physical
(Policy and Authorization)
Virtual • Tivoli Directory Server 5.2
Figure 3-16 All-in-one approach

PDWB PDRP HTTP (80),

HTTPS(443)
PDRP PDWB HTTP(9081)

HTTPS(9444)
PDRP PDTAM LDAP(389)

LDAPS(636)
TAM_SSL(7135,7136)
PDWB PDTAM LDAP(389)

LDAPS(636)
3.3.4 Develop and deploy without debug
The develop and deploy without debug approach has the aim to provide:
򐂰 A development environment including tools to develop portlets without a
complete test environment covering the security aspects
򐂰 A test environment with a secure portal runtime environment
It is capable of providing a development environment as follows:

򐂰 An unique environment to develop portal assets
򐂰 Restricted testing capabilities
򐂰 Team development by sharing a repository instance
The test environment is capable to:

򐂰 Enabling performance-relevant tests
򐂰 Performing stress tests and integration tests
Figure 3-17 illustrates the develop and deploy without debug approach. The
specified Repository node is placed on a physical node. The developer has its
own specified development node installed. The test environment is shared
across all developers as follows:
򐂰 The specified Reverse Proxy node is placed on a physical node.
򐂰 The specified Portal Server node is placed on a physical node.
򐂰 The specified Policy Server node and specified Directory node are placed on
a physical node.
This approach assumes that a development process is in place to:

򐂰 Define how the developers are integrating their assets.
򐂰 Describe the deployment steps.
򐂰 Define the test scenario and procedures.

Development Domain Test Domain
PDWB PDRP PDPORTAL

SDWB SDRP SDPORTAL
• WebSphere Studio
Application W WebSphere Portal
Developer 5.1.1 PDREP Extend 5.0.2.1
• WebSphere Portal
SDREP
Toolkit 5.0.2.1 PDTAM
Tivoli Access SDTAM SDLDAP SDDB

CVS
Manager 5.1.0.2 • Tivoli Access Manager 5.1.0.2
(WebSEAL) (Policy and Authorization)
Figure 3-17 Develop and deploy without debug

PDWB PDREP HTTP (80),

HTTPS(443)
Repository(that is,
2431)
PDWB PDRP HTTP(80)

HTTPS(443)
PDRP PDTAM LDAPS(636)

TAM_SSL(7135)
PDRP PDPORTAL HTTP(9081),

HTTPS(9444)
PDPORTAL PDTAM LDAPS(636)
3.3.5 Develop, deploy, and remote debugging

The develop, deploy, and remote debugging approach has the aim to provide:
򐂰 A development environment including tools to develop portlets and to
remotely debug the secure portal asset
򐂰 A test environment with a secure portal setup that can be shared across the
developers for remote debugging sessions
򐂰 Full testing capabilities including security aspects
The test environment is capable to:

򐂰 Enabling performance-relevant tests
򐂰 Performing stress tests and integration tests
Figure 3-18 on page 89 illustrates the develop, deploy, and remote debugging
approach. The specified Repository node is placed on a physical node. The
developer has its own specified development node installed. The test
environment is shared across all developers as follows:
򐂰 The specified Portal Server node is placed on a physical node.
a physical node.
This approach assumes that a development process is in place to:

򐂰 Define how the developers are integrating their assets.
򐂰 Describe the deployment steps.
򐂰 Define the test scenario and procedures.
PDWB PDRP PDPORTAL

SDWB SDRP SDPORTAL
Tivoli Access Manager WebSphere Portal
• WebSphere Studio 5.1.0.2 (WebSEAL) Extend 5.0.2.3
PDREP
Application Developer 5.1.1
• WebSphere Portal Toolkit SDREP
PDTAM
5.0.2.1
SDTAM SDLDAP SDDB
CVS • Tivoli Access Manager 5.1.0.2 (Policy
and Authorization)
Figure 3-18 Develop, deploy, and remote debugging

Note: We assume that the Portal Server node is capable of supporting parallel
remote debugging sessions.


HTTPS(443)
Repository (that is,
2431)
PDWB PDRP HTTP(80)

HTTPS(443)

TAM_SSL(7135)

HTTPS(9444)
3.3.6 Develop using a shared security infrastructure

The develop using a shared security infrastructure approach has the aim to
provide:
򐂰 A standalone development environment including tools to develop portlets.
The secure Portal Server node is an integral part of deploying and testing the
solution.
򐂰 A test environment with the security-related specified nodes that are shared
across the development nodes.

򐂰 Full testing capabilities including security aspects
򐂰 An unique security setup for each developer
The test environment is capable of:

򐂰 Sharing a common security infrastructure
򐂰 Supporting a large team of development process
򐂰 Minimizing the required hardware investments
򐂰 Providing a secure portal integration environment
Figure 3-18 on page 89 illustrates the develop using a shared security
infrastructure approach. The specified Repository node is placed on a physical
node. The developer has its own specified development node installed. The test
environment is shared across all developers as follows:
a physical node.
򐂰 The specified Portal Server node is placed on a physical node to support the
deployment process for integration tests.
This approach provides a high degree of flexibility as follows:

򐂰 Each developer has its own unique development environment and test
environment.
򐂰 Development assets are shared via a centralized repository.
򐂰 The security-related tasks are separated such that each developer maintains
his settings.
򐂰 Integration and performance test when deploying the developed assets.

5.1.0.2 (WebSEAL)
PDWB PDRP
SDWB SDPORTAL SDRP

PDPORTAL
• WebSphere Studio
Application Developer 5.1.1 PDREP PDTAM
• WebSphere Portal Extend WebSphere Portal Extend
V5.0.1 SDREP V5.0.2.1
• Portal Toolkit 5.0.2.1
SDTAM SDLDAP SDDB
CVS • Tivoli Access Manager 5.1.0.2

(Policy & Authorization Servers)
Figure 3-19 Develop using a shared security infrastructure


HTTPS(443)
Repository (that is,
2431)
PDWB PDRP HTTP(80)

HTTPS(443)

TAM_SSL(7135)
PDRP PDWB HTTP(9081),

HTTPS(9444)
PDWB PDTAM LDAPS(636)

HTTPS(9444)
4
Chapter 4. Design and integration

guidelines
This chapter provides design and integration guidelines for secure portal
solutions. In addition, this chapter includes sequence diagrams for common
access patterns. Lastly, the secure portal architecture component connections
are depicted in a very detailed figure.

򐂰 Security and design guidelines
򐂰 Product-specific integration guidelines
򐂰 Sequence diagrams for common access patterns
򐂰 Component connections

4.1 Security and design guidelines
This section covers the security considerations when developing and deploying
secure portal solutions. It covers the following topics:
򐂰 Design principles
򐂰 WebSphere Portal vs Tivoli Access Manager authorization
򐂰 Single sign-on guidelines
򐂰 Identity management
򐂰 Adding an external Web server for WebSphere Portal
4.1.1 Design principles

The design of any architecture must be based on clearly defined and articulated
principles that form a foundation for the design process, that is, the principles
describe the objectives of the solution. Whenever in doubt about a design
decision, the principles should be used to map a path forward and to justify the
overall design.
Some key principles can be applied to an access control solution for secure
portals:
򐂰 Centralized authority
򐂰 Access decision evaluated on demand
򐂰 Capture authentication events and logs
Centralized authority
The security solution must have a central point of authority for security-related
information. This authority must support both centralized and distributed
management.
򐂰 Motivation: This principle drives the need for one source of authoritative,
security-related policy within an organization. It enables a consistent policy to
be applied across applications, systems, and throughout the organization
while providing a flexible administration framework that fits into and enhances
an organization’s operation capabilities.
򐂰 Implication: This principle implies a high degree of integration, broad
coverage, and flexibility required from the products that are chosen to support
it. Integration is one of the greatest challenges.
Access decision evaluated on demand

Access decisions must be evaluated where and when they are required, not at
the beginning of a transaction. Gated controls should be employed throughout
the solution. Putting all controls at the front door puts too much emphasis on the
concept of trust (that is, I have let you into my house and now you can do
whatever you like), creating an inherently less secure system.
򐂰 Motivation: The drivers for this principle are increased security and
performance:
– Increased security through more checks of a user’s or transaction’s
authority to perform a function.
– Increased performance as decisions get made when a user requires
something, meaning that unnecessary decisions about a user’s potential
activity will not be made up front.
򐂰 Implication: Requires good integration capability to enable a common security
service to permeate an environment. The majority of applications must be
able to use the security services.
Capture authentication events and logs

Sufficient logging is required to capture all authentication and access control
decision events and logs. The level of logging should be based on business and
security requirements, hence the security solution should provide comprehensive
and flexible logging coverage, allowing it to be customized.
򐂰 Motivation: Because no security solution is foolproof, it is essential to keep
good records of the transactions performed by the security system. An easily
manageable method of dealing with these records is essential.
򐂰 Implications: Strong integration is required to provide logging across multiple
systems. Mechanisms must be in place to collect, filter, analyze, and report
on audit data.
These principles are not intended to be comprehensive, but to highlight some

core objectives of the secure portal solution.
4.1.2 WebSphere Portal vs Tivoli Access Manager authorization

Both WebSphere Portal and Tivoli Access Manager provide authorization
solutions.
One key difference is that WebSphere Portal can only be used to manage
authorization for portal pages, portlets, and other portal resources, whereas
Tivoli Access Manager can manage authorization for many resource types
including portals, J2EE applications, legacy applications, printers, etc.
One of the greatest advantages of externalizing the WPS-role-to-user/group

mapping in Tivoli Access Manager V5.1 is that it is possible to use not only ACLs
that statically define Role membership, but also POPs, and most of all the new
Tivoli Access Manager V5.1 Authorization Rules.
Chapter 4. Design and integration guidelines 95

When using POP, for instance, you can define in which days of the weeks or in
which hours of the day a user is a "privileged user" for portlet A. Whe using the
Authorization Rule you can define a rule stating "User Pippo is Administrator for
Portlet A if he has received approval from administrative board". Also, you can
define an Authorization Rule that allows a money transfer page in the ITSO Bank
application to be viewed when the user’s account balance is $1000 or higher.
In Tivoli Access Manager you are able to dynamically add rules for role definition.
When using WPS you can only statically define users/groups that are in a
particular role definition.
Other key considerations are the customer requirements and existing

environment. For example, if authorization is only an issue for portal applications
and the application is self contained, then using WebSphere Portal to manage
authorization may be appropriate. On the other hand, if many application types
(portal, J2EE, legacy, etc.) on many servers, having a centralized authorization
solution using TAM may be more appropriate.
4.1.3 Single sign-on guidelines

There are several levels of integration that can be implemented between Tivoli
Access Manager and WebSphere Portal. Figure 4-1 illustrates the multiple
realms of single sign-on in an enterprise Web application environment.
In the ITSO working example runtime environment, the integration of WebSphere

Portal and Tivoli Access Manager is focused on Client-Web application single
sign-on issues. The example also illustrates how to use Tivoli Access Manager
Global Sign-On (GSO) Lockbox for WebSphere Portal Credential Vault
credential storage. Credential Vault is used to store user credentials for
Portal-Backend SSO.
To implement crosss-domain SSO, IBM Tivoli Access Manager WebSEAL

supports the ability to forward an authenticated identity from a user in one
security domain to a WebSEAL server in another security domain.
Cross-Domain SSO Client-Web App SSO Portal-Backend SSO
Web
Client Application
Back-end
Application
Client Portlet
Authentication WebSphere
Proxy Portal
Other Domain Portlet
Back-end
Authentication
Application
Proxy
Web
Application
Figure 4-1 Realms of single sign-on
Figure 4-2 illustrates the general request processing steps for WebSEAL
authentication and authorization when WebSEAL is configured to use
forms-based login and cookie based session IDs. Note that the diagram does not
include other processing that WebSEAL may perform, such as content filtering,
cookie handling, etc. These steps are common for both TAI- or LTPA-enabled
junctions. The internal details of the two highlighted steps differ between TAI and
LTPA junctions. They are illustrated in Figure 4-3 on page 102 and Figure 4-5 on
page 104, respectively.

User requests a URL
from a web browser
Is URL
WebSEAL No accessible to No
session exists? unauthenticated
users?
Yes Yes Create a session by

setting PD-S-
SESSION-ID cookie
in HTTP response
Is URL No
accessible to this
user?
Send HTTP 302
Yes response redirecting Create a new session
the web browser to by setting PD-S-
the WebSEAL login SESSION-ID cookie
page in HTTP response
Build HTTP request

to the junctioned
server User enters
username Send HTTP 302
and password response redirecting
and submits the web browser to
the form the original URL
Issue the HTTP
request and get the
response from the
junctioned server Web browser
Validate user
automatically
credentials in LDAP
requests the URL.
user registry
PD-S-SESSION-ID
session cookie is
sent to WebSEAL
Build HTTP response
for the user
No User credentials Yes
valid?
Send the response to Send an error

the user page
Display the WebSEAL

response
Figure 4-2 WebSEAL to Web application authentication flow
This section describes the following single sign-on capabilities when integrating
WebSphere Portal and Tivoli Access Manager:
򐂰 Credential Vault integration with GSO
򐂰 Trust Association Interceptor (TAI)
򐂰 LTPA token support
򐂰 Selecting a single sign-on solution
Credential Vault integration with GSO

WebSphere Portal provides an implementation of Vault Adapter
(com.ibm.wps.sso.vaultservice.AccessManager41VaultAdapter) that uses the
GSO Lockbox to store the user credentials. It allows you to consolidate the
sensitive user data into a single GSO repository.
Trust Association Interceptor (TAI)

When using Tivoli Access Manager for a secure portal solution, the WebSEAL is
used as Reverse Proxy and entry point to all service requests. The intent of this
implementation is to have WebSEAL as the only exposed entry point. As such, it
authenticates all requests that come in and provides course-granularity junction
point authorization.
When the WebSphere Application Server is used as a back-end server it further

exploits its fine-grained access control. The WebSEAL can pass HTTP requests
that include credentials of the authenticated used to the WebSphere Application
Server. The WebSphere Application Server then uses these credentials to
authorize the request.
WebSphere Application Server includes the Trust Association Interceptor Mode

within its security framework, which is capable of interfacing with third-party
objects that intercept requests issued by trusted proxy servers, such as
WebSEAL. These objects are collectively known as Trust Association
Interceptors (TAI) or simply interceptors. WebSphere Application Server includes
a TAI plug-in for the WebSEAL.
TAI implies that the WebSphere Application Server security application

recognizes and processes HTTP requests received from WebSEAL. WebSphere
and WebSEAL engage in a contract in which the former gives its full trust to the
latter, which means that WebSEAL applies its authentication policies on every
Web request that is dispatched to the WebSphere Application Server.
This trust is validated by the interceptors that reside in the WebSphere

Application Server environment for every request received. The method of
validation is agreed on by WebSEAL and the interceptor. Setting values for
parameters defined in the webseal.properties file that resides on the WebSphere
Application Server server determine the method of validation for the interceptors.

The TAI version that ships with Tivoli Access Manager V5.1 can be configured in
one of the following methods:
򐂰 Trust association with -b supply option
򐂰 Trust association with -B option
򐂰 Trust association using mutually authenticated SSL
Summary of how TAI works

The following example illustrates how trust association works when using
WebSphere Application Server Administration applications:
1. The browser requests a URI that WebSEAL recognizes to be a protected
resource.
2. WebSEAL prompts the user to provide a user ID and password (this can be
either via a Basic Authentication challenge or via a Custom Form).
3. WebSEAL authenticates the user.
4. After properly authenticating, WebSEAL forwards a modified HTTP request to
the back-end WebSphere server.
5. Depending on the configuration:
– Trust association with -b supply option
If the WebSEAL junction has been defined with -b supply, the modified
HTTP request contains the Basic Authentication header field with the
original client user ID and the dummy WebSEAL password. When
WebSphere Application Server TAI validates the request, it verifies in
LDAP that the password supplied in the BA header is valid for the user ID
specified in the com.ibm.websphere.security.WebSEAL.username
property for TAI. The actual client user ID encoded in the BA header is not
used by the TAI request validation.
Note: For junctions defined with the -b supply option, WebSEAL builds
the BA header using the actual client user ID. This means that
unauthenticated users can never access resources over these
junctions because WebSEAL cannot build the BA header without the
actual user ID.
– Trust association with -B option for SSL junctions

If the WebSEAL junction has been defined with the -B option, the modified
HTTP request contains a Basic Authentication header with the user ID that
was specified with the -U option and the password that was specified with
the -W option during junction creation. When WebSphere Application
Server TAI validates the request, it verifies in LDAP that the password
supplied in the BA header is valid for the user ID specified in the
com.ibm.websphere.security.WebSEAL.username property for TAI. The
dummy user ID encoded in the BA header is not used by the TAI request
validation.
In this case WebSEAL does not need an actual client user ID to build the
BA header, so unauthenticated user access is possible over this type of
junction.
Note: WebSEAL only supports the -B option for SSL junctions.
– Trust association using mutually authenticated SSL

Alternatively, if the junction between WebSEAL and WebSphere is a
mutually authenticated SSL junction and the property value of
com.ibm.websphere.security.WebSEAL.mutualSSL is yes, WebSphere
trusts the session and does not perform additional validation of BA
headers.
– No trust association
If a junction is created without one of the above mentioned -b supply, -B or
mutual SSL options, WebSphere Application Server TAI will not be able to
authenticate WebSEAL with either HTTP Basic Authentication or mutual
SSL. In this case TAI will not attempt to extract any user credentials from
the request headers and the request will be processed as if coming from
an unauthenticated user.
6. After authenticating WebSEAL, TAI extracts the value of the iv-user http
header and returns this as the authenticated user that should be used by
WebSphere authorization. This is done in the getAuthenticatedUsername()
method.
Note: The ITSO working example runtime environment configuration includes

a TAI example in 7.5.10, “Configure SSO for WebSEAL and WebSphere via
TAI” on page 308.
Figure 4-3 illustrates the WebSEAL request building and WebSphere Application
Server request processing steps in more detail for TAI-based single sign-on
using a junction created with the -b supply option.

Start building the TAI validates in LDAP
request to the the WebSEAL user id
junctioned server specified in TAI
username property with
the extracted password
Create BA header using

actual client id and
dummy password No
User/password
combination valid?
Yes
No
-c junction option
specified?
Extract client username

from iv_user header
Yes
Insert iv_user,
iv_groups, iv_creds
headers as specified by
No
-c option iv_user extracted
successfully?
Yes
Send request to
Use the extracted value
WebSphere Application WebSphere
as authenticated user id
Server authorization assumes
for WebSphere
unauthenticated user
authorization
TAI extracts the

password from BA
header Process the request in
WebSphere Application
Server
Send response back to

WebSEAL
Figure 4-3 WebSEAL request processing for TAI junction with -b supply option
LTPA token support
The WebSphere Application Server can be configured to use a Lightweight Third
Party Authentication (LTPA) token (that is, cookie) to provide single sign-on
across multiple servers. After the user has been authenticated by WebSphere,
an LTPA cookie is created and sent to the browser. The browser will return this
cookie on subsequent requests, enabling the origin WebSphere Application
Server (or other WebSphere Application Server within the same TCP domain) to
recognize the user. The LTPA cookie is protected by a 3DES key, which also
proves that it was created by a trusted source.
The Tivoli Access Manager WebSEAL can generate an LTPA token that will be
accepted by the WebSphere Application Server. WebSphere Application Server
trusts this LTPA token because it is encrypted with the correct shared key.
Figure 4-4 shows a WebSEAL junction that is configured to use LTPA. An LTPA
key is generated on the WebSphere machine and then exported to a keyfile
(protected by a password). This keyfile must then be manually copied to the
WebSEAL machine. When the junction to the WebSphere server is configured, it
is specified as an LTPA junction, and the keyfile and password are given as
parameters.
Key
3 File
WebSphere Application Server

HTTP Request
Internet WebSEAL 4
John John
Application
6
John 2
Bind
Directory 5
Username=?
Password=?
Figure 4-4 WebSEAL creates LTPA cookies for authenticated users
When a user authenticates to WebSEAL and requests a resource on this

junction, WebSEAL creates an LTPA cookie using the key from the keyfile. This
encrypted cookie contains the user’s Access Manager user ID and is included in
the HTTP request sent to the WebSphere server. When WebSphere receives the
HTTP request, it extracts the user ID from the LTPA cookie and uses it to build a
WebSphere credential for the user. It would be usual for WebSEAL and

WebSphere to share a registry to avoid synchronization problems. WebSphere
then applies its own authorization decision to the request.
Note: Appendix B, “Configure single sign-on using LTPA” on page 597,

includes a configuration example for using an LTPA token in a secure portal
single sign-on configuration.
Figure 4-5 illustrates the WebSEAL request building and WebSphere Application
Server request processing steps in more detail for LTPA-based single sign-on.
Start building the

request to the
junctioned server
Create LTPA token with No

LTPA token valid?
the current user id
Yes
Encrypt the LTPA token

with the imported LTPA Use the extracted value
encryption key as authenticated user id
for WebSphere
authorization
Send request to
WebSphere Application Use the extracted value
Server WebSphere
as authenticated user id
authorization assumes
for WebSphere
unauthenticated user
authorization
WAS decrypts the

LTPA token with its
LTPA encryption key
Process the request in

WebSphere Application
Server
Send response back to

WebSEAL
Figure 4-5 WebSEAL request processing for LTPA junction
Selecting a single sign-on solution

This section provides guidelines on selecting an appropriate single sign-on
solution for a secure portal solution.
If you assume that Tivoli Access Manager and WebSphere Portal (WebSphere
Application Server) share a common user registry, then GSO would be the last
choice for SSO. Instead, using either the Trust Association Interceptor (TAI) or
the LTPA support would be the preferred solution. GSO is the only option for the
following scenarios:
򐂰 When WebSEAL and WebSphere rely on different user registries, you may
need to supply a different user ID and password combination for the user to
WebSphere that is meaningful to the WebSphere user registry.
򐂰 There might be situations, even in the case of a shared user registry, where
-b GSO might be useful. For example, if internal users should be able to
connect to WebSphere directly using basic authentication and then have
indirect access through WebSEAL with WebSEAL being configured to
provide forms-based logon.
There are cases when LTPA is needed or desired:

򐂰 Use of LTPA would allow having a non-ssl junction without the restrictions of
TAI discussed in 4.2.2, “Junction considerations for use with TAI” on
page 109. On the other hand, the restrictions are really security features of
TAI. The inflexibility with TAI is really caused by WebSEAL junction
restrictions.
򐂰 LTPA can only be used if all the back-end servers (and possibly WebSEAL as
well) reside in the same domain. This is because the LTPA token is really a
domain cookie and will not be sent to servers in different domains. This is a
real drawback for LTPA.
Otherwise, we recommend the TAI option, because it is easy to configure and

maintain. There is no key distribution or periodic update required. TAI is also the
method used when WebSphere supports integration with third-party Reverse
Proxy security servers in general.
4.1.4 Identity management

Identity management is a comprehensive, process-oriented, and policy-driven
security approach that helps organizations consolidate identity data and
automate the deployment across the enterprise.
In order to effectively compete in today’s business environment, companies are

increasing the number of users (customers, employees, partners, and suppliers)
who are allowed to access information. As IT is challenged to do more with fewer
resources, managing user identities and their access to resources throughout the
identity life cycle is even more difficult. Typical IT environments have many local
administrators using manual processes to implement user changes across

multiple systems and applications. As identity management grows more costly, it
can inhibit the development and deployment of new business initiatives.
An integrated identity management solution can help get users, systems, and
applications online and productive fast, and maintain dynamic compliance to
increase the resiliency and security of the IT environment, while helping to
reduce costs and maximize return on investment. An identity management
solution has four key areas:
򐂰 Identity lifecycle management (user self-care, enrollment, and provisioning)
򐂰 Identity control (access and privacy control, single sign-on, and auditing)
򐂰 Identity federation (sharing user authentication and attribute information
among trusted Web services applications)
򐂰 Identity foundation (directory, directory integration, and workflow)
As the world of e-business gains global acceptance, the traditional processes of

corporate user administration are no longer able to cope with the demands of
increased scale and scope expected from them. Identity management is a
superset of older user provisioning systems that allows for the management of
identity and credential information for customers, partners, suppliers, automated
processes, corporate users, and others.
As organizations come to depend on their IT assets more, these assets attract

the attention of accounting and reporting standards. IT data and system assets
will increasingly become balance sheet line items, and therefore be subject to
different audit and compliance rules. Organizations must be able to demonstrate
due care, due diligence, improved security, and compliance with other financial
rules. We should realize that any entity using the IT systems run by an
organization must be included in the scope of identity management if we are to
have any chance of achieving these goals.
Tip: For more information on Identity Management refer to the following

redbooks:
SG24-6996
SG24-6014
4.1.5 Adding an external Web server for WebSphere Portal
In a production environment of a secure portal solution we have the following
approaches to process HTTP-requests:
򐂰 Using a standalone Web server, which routes HTTP-requests via a plug-in to
the portal server
򐂰 Using the embedded Web server of the application server
From a security point of view both approaches are feasible with different planning
and installation steps.
Standalone Web server

The main purpose of a standalone Web server is to serve static and dynamic
content. The static content is stored within the Web server’s file system (either
local or distributed). When accessing dynamic content, the Web server forwards
the request via an application server plug-in to the corresponding application
server. In case only dynamic requests are processed, this approach might result
in a performance decreases, as requests are always routed to the application
servers.
When using the standalone Web server, all application servers handled by the
application server plug-in are accessible through the same hostname and port of
the Web server. This allows us to have a single WebSEAL junction for accessing
applications running on separate application servers, such as server1 and
WebSphere_Portal.
Embedded HTTP server

In case we only serve dynamic content, we can omit the Web server by using the
embedded Web server capability within the application server. This streamlines
the processing of HTTP requests and could increase performance metrics.
When using this approach, each application server runs on a different port. As a
result, separate WebSEAL junctions are required for accessing each application
server.
4.2 Product-specific integration guidelines

This section describes Tivoli Access Manager and WebSphere Portal
product-specific architectural considerations. The following product-specific
features are discussed:
򐂰 WebSEAL junctions
򐂰 Junction considerations for use with TAI

򐂰 Handling of back-end application cookies
򐂰 Junction Mapping Table (JMT)
򐂰 WebSEAL URL-based access control
򐂰 Access control of WebSphere Portal resources
򐂰 Access control of resources within portlet applications
򐂰 WebSEAL and WebSphere Portal session considerations
4.2.1 WebSEAL junctions

Tivoli Access Manager WebSEAL uses junctions to map the protected Web
application servers to its own URI space. Each junction maps to a single Web
server (or a cluster of identical servers).
There are several options that define the junction scheme for WebSphere Portal.
򐂰 Number of junctions
– A single junction for all WebSphere Portal access
– Separate junctions for unauthenticated and authenticated user access to
WebSphere Portal
򐂰 Encryption for WebSEAL to WebSphere Portal communications
– Non-encrypted junction
– SSL encrypted junction with server-side certificate
– SSL encrypted junction with client and server certificates (mutual SSL)
򐂰 Cookie handling
– Junction created with -j option
– Junction created without -j option
Cookie handling options usually do not influence other aspects of junction

functionality. Requirements on the number of junctions and encryption, however,
impose certain limits on the possible junctioning schemes.
There are several questions that need to be prioritized and answered before
choosing a suitable junction scheme:
򐂰 Will the system allow unauthenticated access to some portal resources?
򐂰 Will the communication between client and WebSEAL be SSL encrypted?
򐂰 Will there be some resources accessible over non-encrypted connection, and
some accessible over SSL, thus requiring switching between HTTP and
HTTPS protocols?
򐂰 Does your planned URL scheme require the same base URL for both
unauthenticated and authenticated access, or does it specify separate base
URLs?
򐂰 What are the security requirements for the connection between Remote
Proxy node and Portal Server node?
򐂰 What are the performance requirements for the connection between Remote
Proxy node and Portal Server node?
Typically the most important decision will be the number of junctions, since it is
the only one that directly affects the user experience. This decision also has the
biggest technical impact.
If separate junctions will be implemented for authenticated and unauthenticated

access, it is possible to use either encrypted or non-encrypted connections from
WebSEAL to WebSphere Portal. However, two junctions can present some
problems if using WebSEAL Junction Mapping Table (JMT). Usually /wps path
would be mapped to the portal junction. If there are two portal junctions, /wps can
only be mapped to one of them. If a user accesses a portlet through the
non-mapped junction and clicks on a link with /wps base path, WebSEAL will
route the request through the mapped junction. This can cause unexpected
behavior for some applications. For more details on this issue see 4.2.4,
“Junction Mapping Table (JMT)” on page 112.
The other option, a single junction, solves the problem with JMT. However, it
imposes another limitation. If both authenticated and unauthenticated access
need to be provided over the same junction, it must use an SSL connection to
the Portal Server node. This limitation does not apply if only authenticated
access needs to be provided. For more details on this issue see 4.2.2, “Junction
considerations for use with TAI” on page 109.
4.2.2 Junction considerations for use with TAI

The Trust Association Interceptor plug-in provided with WebSphere Application
Server provides the following methods for establishing a trust relationship
between WebSEALl and WebSphere Application Server:
򐂰 Junction create with -b supply option
򐂰 Junction create without -b supply option using mutual SSL
򐂰 Custom TAI plug-in
Junction create with -b supply option

If the junction is created with the -b supply option, WebSEAL will send HTTP
Basic Authentication credentials with each request, identifying that the request
indeed comes from WebSEAL. WebSEAL will send the user ID of the currently

logged in user, and a dummy password defined in the webseald-<instance>.conf
file. The TAI plug-in only uses the password provided with Basic Authentication
header, the user id is ignored. The password is validated for the user ID defined
by the com.ibm.websphere.security.webseal.userId property for the TAI plug-in.
Even though the user ID specified in the request header is not used by TAI,
WebSEAL must provide it to generate the Basic Authentication header. If the
junction uses an encrypted connection (created with the -t ssl option), WebSEAL
can be configured to provide a dummy user ID for the Basic Authentication
credentials. If the junction uses a non-encrypted connection (created with the -t
tcp option), WebSEAL will always use the actual logged in user ID to generate
the Basic Authentication credentials. As a result, unauthenticated access is not
possible over a non-SSL junction if using TAI because there is no real user ID,
and the Basic Authentication credentials cannot be generated.
Junction create without -b supply option using mutual SSL

Alternatively, the connection between WebSEAL and WebSphere Application
Server can be established over a mutually authenticated SSL connection. In this
case the trust is established based on cryptographic certificates. The second
option is more secure and does not require the use of Basic Authentication
credentials, but imposes a performance penalty. This is the only available option
when providing authenticated and unauthenticated access over the same
junction and using unmodified, out-of-the-box components.
Custom TAI plug-in

The third alternative is to create a custom TAI plug-in for WebSphere Application
Server that accepts requests without Basic Authentication headers and without
mutual SSL. If you choose this approach, be aware that after such modification
the TAI plug-in will in effect treat all requests it receives as coming from a trusted
source. It increases the possibility of malicious security exploits and should not
be done in security conscious environments.
Note: For details on creating a custom TAI plug-in, refer to the IBM
WebSphere V5.0 Security, WebSphere Handbook Series, SG24-6573,
redbook.
4.2.3 Handling of back-end application cookies

Depending on the junction creation options, WebSEAL will handle the cookies
set by the back-end Web application in two different ways. In either case the
cookie value remains unmodified. See WebSEAL Administration Guide, IBM
Tivoli Access Manager V5.1, SC32-1359, for more information on junction
options.
Table 4-1 Naming convention for cookie examples
Description Value
Reverse Proxy node wswin1.itso.ral.ibm.com®
Portal Server node wpwin1.itso.ral.ibm.com
WebSEAL junction for /portal

portal access
The cookie handling examples use the following naming convention (Table 4-1).
򐂰 If the junction is created without specifying the -j option, WebSEAL will send
the back-end cookie to the client browser without modifying its name. It will
update the cookie path to reflect the junction from which it was set. The
following example illustrates cookie filtering for the /portal junction created
without the -j option (Table 4-2).
Table 4-2 WebSEAL cookie handling without -j option

Original cookie WebSEAL filtered cookie
Cookie name JSESSIONID JSESSIONID
Cookie path /wps /portal/wps
Server wpwin1.itso.ral.ibm.com wswin1.itso.ral.ibm.com
Note that the filtered cookie path is now set to /portal/wps and therefore the
browser will only send the JSESSIONID cookie with requests for URLs
beginning with /portal/wps.
򐂰 If the junction is created with specifying the -j option, WebSEAL will rename
the cookie before sending it to the client browser. The new cookie name
includes junction identification and is generated in the following form:
AMWEBJCT!<junction_name>!<original_cookie_name>
The following example illustrates cookie filtering for the /portal junction
created with the -j option (Table 4-3).
Table 4-3 WebSEAL cookie handling with -j option

Original cookie WebSEAL filtered cookie
Cookie name JSESSIONID AMWEBJCT!%2Fportal!JSESSIO

NID
Cookie path /wps /
Server wpwin1.itso.ral.ibm.com wswin1.itso.ral.ibm.com

Note that the filtered cookie path is now set to / and therefore the browser will
send the mangled JSESSIONID cookie with all requests to the Reverse Proxy
node. WebSEAL will decode the junction information in the mangled cookie
name and determine whether the cookie should be forwarded to the back-end
application.
4.2.4 Junction Mapping Table (JMT)

When accessing WebSphere Portal through WebSEAL, the junction name is
added to the base portal URL. For example, if the base portal URL is /wps, and
the WebSEAL junction name is /portal, the portal URL becomes /portal/wps.
Some applications, such as Resource Permissions portlet, do not work properly
with the junction name inserted into the URLs because they expect the portal to
be accessible at the /wps URL. The WebSEAL Junction Mapping Table can be
used to allow these applications to work as expected by mapping all requests for
the /wps URL to the /portal junction.
There are several limitations for using the Junction Mapping Table:
򐂰 JMT will not work properly with junctions created without the -j option.
When WebSphere Portal sets the JSESSIONID cookie, WebSEAL will filter it
as illustrated in Table 4-2 on page 111. The cookie path is set to /portal/wps. If
the user tries to access a URL beginning with /wps, the browser will not send
the JSESSIONID cookie with this request. Even though the link can be
accessed, the user session will be lost.
򐂰 JMT will not work properly if separate junctions are used for authenticated
and unauthenticated access to WebSphere Portal because JMT can only
map /wps URL to a single junction.
Suppose that there are two junctions created, for example /portal for
unauthenticated access and /sportal for authenticated access, and /wps is
mapped to /sportal. If an unauthenticated user accesses a /wps URL,
WebSEAL will map it to the protected junction and access will be denied.
If /wps is mapped to the unsecure /portal junction, and an authenticated user
attempts to access a portal resource, WebSEAL will allow the request
through, but WebSphere Portal may not allow access to protected resources
over an unsecure channel, and the request will fail.
4.2.5 WebSEAL URL-based access control

WebSEAL provides coarse-grained authorization based on URLs (see
Figure 4-6). This level of access control is configured using WebSEAL ACLs,
POPs, and Dynamic Rules Engine (Dynamic Rules are new in Tivoli Access
Manager V5.1). WebSEAL will allow access only when all conditions are met.
Request Deny Deny Deny
No No
ACL POP Rule Permit

Satisfied? Yes Satisfied? Yes Decision?
Access Object access Access

determined by characteristics determined
user/group (for example, dynamically,
permissions audit, time-of-day based on
or day-of-week) current
for all users and conditions
groups
Figure 4-6 WebSEAL URL authorization
The following example illustrates WebSEAL URL authorization by using only

ACLs, without defining additional POPs and Dynamic Rules. In the example
runtime environment, the following four ACLs are used:
򐂰 WP_all_access for URLs accessible to all users
򐂰 WP_authenticated_access for URLs accessible to authenticated users only
򐂰 WP_admin_access for URLs accessible to administrators only
򐂰 WP_no_access for denying access to some URLs completely
4.2.6 Access control of WebSphere Portal resources

Tivoli Access Manager supports the J2EE security model and JAAS; however,
these features are not fully leveraged in the WebSphere Portal environment.
WebSphere Portal implements its own authorization mechanism for access

control of its resources, such as pages and portlets. This provides finer grained
authorization than Java 2 security, but has the disadvantage of having to
maintain two separate security solutions (Tivoli Access Manager and
WebSphere Portal). However, WebSphere Portal allows you to delegate
authorization to an external authorization engine. We will use this feature to
delegate WebSphere Portal resource authorization to Tivoli Access Manager.
4.2.7 Access control of resources within portlet applications

In addition to WebSphere Portal authorization, which controls access to
resources such as portlets, portlet developers can use aznAPI to integrate Tivoli
Access Manager authorization services within their applications.

For details refer to Authorization Java Classes Developer Reference, IBM Tivoli
Access Manager V5.1, SC32-1350, product guide.
4.2.8 WebSEAL and WebSphere Portal session considerations

Both WebSEAL and WebSphere Portal establish sessions with the client
browser when initially accessed. These sessions are independent of each other,
but both must be valid in order for the system to work as expected.
WebSEAL user sessions

A WebSEAL session is established between the client browser and WebSEAL
after a user logs into WebSEAL. The session is maintained by either setting a
PD-S-SESSION-ID cookie on the client browser or by SSL Session-ID.
WebSEAL session is terminated when the user explicitly logs out by accessing
the /pkmslogout URL, or when session timeout occurs. WebSEAL has two
settings in the [session] stanza of the webseald-<webseal_instance>.conf file
that govern the session timeout.
򐂰 The inactive-timeout parameter sets the timeout value for user session
inactivity. By default, inactive-timeout is set to 600 seconds.
򐂰 The timeout parameter sets the maximum lifetime timeout value for all user
sessions stored in the WebSEAL session/credentials cache. This parameter
defines credential lifetime rather than session inactivity timeout. Its purpose is
to enhance security by forcing the user to reauthenticate when the specified
timeout limit is reached. By default, timeout is set to 3600 seconds.
Note: Both settings produce the same behavior - the user is requested by
WebSEAL to reauthenticate. All further references in this book to WebSEAL
session timeouts will not distinguish between session inactivity timeout and
maximum session lifetime timeout because the consequent system
interactions are the same.
WebSphere Portal user sessions

A WebSphere Portal session is established between the client browser and
WebSEAL when an authenticated user accesses any portal page and a session
does not already exist. Pages accessed by unauthenticated users may or may
not create a user session for WebSphere Portal, depending on how the portlets
are coded. If the WebSphere Portal session for an authenticated user is
invalidated for any reason, such as session inactivity timeout, the user may need
to log in again to be able to access portal resources. The WebSphere Portal
session is actually a standard J2EE Web application session and is handled by
WebSphere Application Server. The session is maintained by setting a
JSESSIONID cookie on the client browser. The WebSphere Portal session
timeout is defined by WebSphere_Portal application server session manager
settings in the WebSphere Application Server. By default, the session timeout is
set to 30 minutes.
The test use cases in “UCT5: WebSEAL session times out before portal session”
on page 121 through “UCT8: WebSphere Portal logout after WebSEAL session
timeout” on page 131 illustrate several common scenarios that can occur
because of WebSEAL and WebSphere Portal session issues. The behavior seen
in UCT6 through UCT8 would typically be perceived by the user as defective,
even though each component works exactly as designed.
There are two approaches that can be used to remedy the problem illustrated in
UCT6 and UCT7.
򐂰 One possible approach is to reconfigure WebSphere Portal to persist the user
sessions when they time out, instead of invalidating them. In standalone
portal setup such behavior could lead to possible user session-based security
exploits. However, when used together with Tivoli Access Manager, the user
sessions are authenticated and validated by WebSEAL. Since WebSphere
Portal in this setup trusts WebSEAL and does not perform its own user
validation, the WebSphere Portal sessions can be persisted when expiring
without compromising security. This is the approach we will use in our
example environment.
Enabling automatic persistence for expiring WebSphere Portal sessions has
another side effect—the sessions effectively are preserved in the database
forever. This can be a problem for high-volume sites, and sites that create
WebSphere Portal sessions for unauthenticated users. The unauthenticated
user sessions will be persisted at session expiration, but, being anonymous,
they will never be accessed again. In this case it is necessary to perform
regular cleanup of stale sessions from the database.
򐂰 Another approach is to set the session timeout in the WebSphere Application
Server session manager settings to No timeout.
The benefit of this approach is that the WebSphere Portal session database
will not get polluted with persisted expired sessions. The drawback is that
WebSphere Application Server will keep the sessions in memory indefinitely,
resulting in continuously decreasing performance and eventual depletion of
the JVM memory heap, thus requiring regular restarting of the
WebSphere_Portal application server.
4.3 Sequence diagrams for common access patterns

The following use cases illustrate the typical client access patterns; interactions
between client browser, WebSEAL and WebSphere Portal; and the system

response. For simplicity, the sequence diagrams only show interactions between
components that directly manipulate the user request/response flow in the
system.
Use cases UCT1 through UCT4 illustrate basic client access patterns. Use cases
UCT5–UCT8 illustrate several specific situations where each component
performs as designed, but the overall system response is not as expected.
Section 7.8, “Additional configuration” on page 356 provides some suggestions
for work arounds for these issues.
The use cases use the naming convention listed in Table 4-4.
Table 4-4 Naming convention for use cases

Description Value
Reverse Proxy node wswin1.itso.ral.ibm.com
Portal Server node wpwin1.itso.ral.ibm.com
WebSEAL junction for portal /portal

access
4.3.1 UCT1: Access unprotected portal page

This section includes a use case and sequence diagram for access to an
unprotected portal page.
Table 4-5 UCT1: Access unprotected portal page
Use Case ID: UCT1 UCT1: Access unprotected portal page
Description This use case is used to access an unprotected portal page.
Precondition None.
Actors Customer.
Main Scenario 1. Actor accesses unprotected portal page with an Web

browser.
2. System displays the requested page contents.
Browser WebSEAL Portal
GET /portal/wps/portal GET /wps/portal
HTTP 200 OK (default unprotected page) HTTP 200 OK (default unprotected page)
Figure 4-7 Sequence diagram - UCT1: Access unprotected portal page
The steps are:

1. The user tries to access unprotected from a Web browser at:
http://<webseal_fully_qualified_hostname>/portal/wps/portal
2. WebSEAL performs URL authorization and determines that the requested
resource is accessible to unauthenticated users.
3. WebSEAL forwards the request to the WebSphere Portal.
4. The WebSphere Portal sends a response with the requested content.
5. WebSEAL performs a response URL filtering and sends the response to the
user.
4.3.2 UCT2: Access protected portal page, provide valid credentials

This section includes a use case and sequence diagram for access to a
protected portal page with valid credentials.
Table 4-6 UCT2: Access protected portal page, valid credentials
Use Case ID: UCT2 UCT2: Access protected portal page, valid credentials
Description This use case is used to access a protected portal page

without an existing session. The actor provides valid
credentials.
Precondition The actor has to be a registered user in the system.
Actors Customer.
Main Scenario 1. Actor accesses protected portal page with a Web

browser.
2. System displays the login page.
3. Actor provides valid username and password and
submits the page.

GET /portal/wps/myportal
Set PD-S-SESSION-ID
HTTP 200 OK (login.html) cookie. Path: /
POST /pkmslogin.form
Set PD-S-SESSION-ID
HTTP 302 MOVED to /portal/wps/myportal cookie. Path: /
GET /portal/wps/myportal GET /wps/myportal

Set JSESSIONID
HTTP 200 OK (customized page) HTTP 200 OK (customized page) cookie. Path:/wps
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
Figure 4-8 Sequence diagram - UCT2: Access protected portal page, valid credentials
The steps are:

1. The user tries to access a customized page at:
https://<webseal_fully_qualified_hostname>/portal/wps/myportal
The browser does not send a PD-S-SESSION-ID cookie in the request.
resource is accessible only to authenticated users.
3. WebSEAL sends a login form (login.html) to the user. WebSEAL creates a
user session by setting the PD-S-SESSION-ID cookie in the response
headers.
4. The user enters a valid username and password and submits the login form
(POST /pkmslogin.form).
5. WebSEAL verifies the user credentials and sends a HTTP 302 Moved
Temporarily response to the user’s browser, setting the original page URI
(/portal/wps/myportal) in the Location header field. It will cause the browser to
immediately redirect to the specified URI.
6. The browser automatically makes a request to:
And sends the PD-S-SESSION-ID cookie in the request.
8. The WebSphere Portal sends a response with the requested content.
9. WebSEAL performs response URL and cookie filtering and sends the
response to the user.
4.3.3 UCT3: Access protected portal page with existing valid session
protected portal page with an existing valid session.
Table 4-7 UCT3: Access protected portal page with existing valid session
Use Case ID: UCT3 UCT3: Access protected portal page with existing
valid session
Description This use case is used to access a protected portal page with
an existing valid session.
Precondition The actor has to be a registered user in the system. The

actor needs to have established a valid WebSEAL session by
logging in.
Actors Customer.
Main Scenario 1. Actor accesses protected portal page with an HTML

browser.
2. System displays the requested page contents

HTTP 200 OK (customized page) HTTP 200 OK (customized page)
Send PD-S-SESSION-ID and

AMWEB!%2Fportal!JSESSIONID Send JSESSIONID cookie
cookies
Figure 4-9 Sequence diagram - UCT3: Access protected portal page with existing valid
session
The steps are:

1. The user tries to access a customized page at:
The browser sends the PD-S-SESSION-ID cookie in the request, identifying
an existing session. At this stage, the browser may or may not send a valid
JSESSIONID cookie identifying a WebSphere Portal session.
2. WebSEAL verifies that the session is valid based on the PD-S-SESSION-ID
cookie.
resource is accessible to the currently authenticated user.

5. The WebSphere Portal sends a response with the requested content. If the
JSESSIONID cookie was not sent with the request or had expired,
WebSphere Portal will create a new user session and set the JSESSIONID
cookie in the response header.
4.3.4 UCT4: Access protected portal page with invalid credentials

protected portal page with invalid credentials.
Table 4-8 UCT4: Access protected portal page, valid credentials
Use Case ID: UCT4 UCT4: Access protected portal page, valid credentials
Description This use case is used to access a protected portal page

without an existing session. The actor provides invalid
credentials.
Precondition None.
Actors Customer.

browser.
3. Actor provides invalid username and password
combination and submits the page.
4. System prohibits access to the requested resource and
sends Access Denied response.

Set PD-S-SESSION-
HTTP 200 OK (login.html) ID cookie. Path: /
HTTP 403 ACCESS DENIED
Figure 4-10 Sequence diagram - UCT4 Access protected portal page, invalid credentials
The steps are:
1. User tries to access customized page at:
The browser does not send a PD-S-SESSION-ID cookie in the request or
sends a cookie identifying an expired WebSEAL session.
resource is accessible only to authenticated users.
3. WebSEAL sends a login form (login.html) to the user.
4. The user enters an invalid username and password combination and submits
the login form (POST /pkmslogin.form).
5. WebSEAL verifies that the user credentials are invalid and sends the HTTP
403 Access Denied response to the user.
4.3.5 UCT5: WebSEAL session times out before portal session

This section includes a use case and sequence diagram when the WebSEAL
session times out before the WebSphere Portal session.
Table 4-9 UCT5: WebSEAL session times out before WebSphere Portal session
Use Case ID: UCT5 UCT5: WebSEAL session times out before WebSphere
Portal session
Description This use case is used to demonstrate WebSEAL session

timeout handling if WebSphere Portal has not expired. The
system behavior from the user point of view is as expected.
Preconditions 򐂰 The actor has to be a registered user in the system.

򐂰 The actor has not accessed any WebSEAL or portal
pages after restarting the browser to ensure there are no
established sessions.
򐂰 WebSEAL session timeout is set to 3 minutes.
򐂰 WebSphere Portal session timeout is set to 30 minutes.
Actors Customer.

Use Case ID: UCT5 UCT5: WebSEAL session times out before WebSphere
Portal session

browser.
submits the page.
5. After waiting 3 minutes the actor tries to access the
same page.
submits the page.
Set PD-S-SESSION-ID
HTTP 302 MOVED to /portal/wps/myportal

Set JSESSIONID
cookie. Path:/wps
cookie. Path:/
Wait more than 3 minutes for WebSEAL session timeout

AMWEB!%2Fportal!JSESSIONID cookies
Set PD-S-SESSION-ID
Set PD-S-SESSION-ID
cookie. Path: /
JSESSIONID
Send JSESSIONID cookie
session is still valid

Figure 4-11 Sequence diagram - UCT5: WebSEAL session times out before WebSphere Portal session
The steps are:

1. User accesses customized portal page the same way as illustrated in “UCT2:
Access protected portal page, provide valid credentials” on page 117.

2. The user waits more than 3, but less than 30, minutes before sending the next
request. At this time the WebSEAL session will be expired, but the
WebSphere Portal session will still be valid.
3. The ser tries to access the customized page at:
The browser sends the PD-S-SESSION-ID cookie in the request.
4. WebSEAL determines that the user session identified by the
PD-S-SESSION-ID cookie has expired.
5. WebSEAL sends the login form (login.html) to the user. WebSEAL creates a
new user session by setting the PD-S-SESSION-ID cookie in the response
headers.
7. WebSEAL verifies the user credentials and sends the HTTP 302 Moved
Temporarily response to the users browser, setting the original page URI
immediately redirect to the specified URI.
https://<webseal_full_hostname>/portal/wps/myportal
Sending the PD-S-SESSION-ID cookie in the request.
9. WebSEAL forwards the request to WebSphere Portal.
10.WebSphere Portal sends a response with the requested content. Since the
JSESSIONID cookie was with the request and the WebSphere Portal session
is still valid, WebSphere Portal processes the request as if there was no delay
and subsequent re-authentication at WebSEAL.
11.WebSEAL performs response URL and cookie filtering and sends the
4.3.6 UCT6: Portal session times out before WebSEAL session

This test case illustrates a situation where the WebSphere Portal session times
out before the WebSEAL session. When trying to access a portal page after
session timeout, the user receives an error message instructing you to establish
a new session. After clicking teh Login button, the system does not ask for a
username and password, and displays the personalized portal home page. Each
component works as designed, but the overall system behavior is not as typically
expected.
Table 4-10 UCT6: WebSphere Portal session times out before WebSEAL session
Use Case ID: UCT6 UCT6: WebSphere Portal session times out before
WebSEAL session
Description This use case is used to demonstrate WebSphere Portal

session timeout handling if the WebSEAL session has not
expired. The system behavior from the user point of view
may not be as expected.

pages after restarting the browser to ensure that there
are no established sessions.
Actors Customer.

browser.
submits the page.
same page.
6. System displays error message.
7. User clicks the Login button.
8. System displays protected home page without asking for
username/password.

Set PD-S-SESSION-ID
Set PD-S-SESSION-ID
HTTP 302 MOVED to /portal/wps/myportal cookie. Path: /

Set JSESSIONID
HTTP 200 OK (customized page) HTTP 200 OK (customized page) cookie. Path:/wps
cookie. Path:/
Wait more than 3 minutes for WebSphere Portal session inactivity timeout
PD-S-SESSION-ID session is still valid
JSESSIONID
Send JSESSIONID cookie session has expired
Set JSESSIONID
HTTP 302 MOVED to HTTP 302 MOVED to
cookie. Path:/wps
/wps/portal/!ut/p/.scr/ErrorSessionTimeout /wps/portal/!ut/p/.scr/ErrorSessionTimeout
GET GET
HTTP 200 OK (session timeout
HTTP 200 OK (session timeout message) message)
cookie. Path:/
User clicks the Log in link

AMWEB!%2Fportal!JSESSIONID cookies Send JSESSIONID cookie
GET /wps/myportal/!ut/p/.scr/Home GET /wps/myportal/!ut/p/.scr/Home

Set JSESSIONID
cookie. Path:/wps
HTTP 200 OK (customized home page) HTTP 200 OK (customized home page)
cookie. Path:/
Figure 4-12 UCT6: WebSphere Portal session times out before WebSEAL session
The steps are:

1. The user accesses customized portal page the same way as illustrated in
“UCT2: Access protected portal page, provide valid credentials” on page 117.
2. The user waits more than 3, but less than 30, minutes. The WebSphere
Portal session expires, while WebSEAL session is still valid.
3. The user tries to access the customized page at:
The browser sends the PD-S-SESSION-ID and
AMWEB!%2Fportal!JSESSIONID cookies in the request.
PD-S-SESSION-ID cookie is still valid and forwards the request to
WebSphere Portal. WebSEAL examines the
AMWEB!%2Fportal!JSESSIONID cookie, and reconstructs and inserts the
original JSESSIONID cookie in the HTTP request header.
5. WebSphere Portal determines that the session identified by the JSESSIONID
cookie has expired and displays an error message: Your portal session has
timed out because of no activity. Please start a new session at your
portal Home.
6. The user clicks the Log in link on the error page.
7. Since the PD-S-SESSION-ID session is valid, WebSEAL does not ask for
authentication, and forwards the request to WebSphere Portal.
8. WebSphere Portal generates a new User session object, renders the home
page for the logged-in user, and sets the JSESSIONID cookie in the response
headers.
4.3.7 UCT7: Both WebSEAL and WebSphere Portal sessions time out
This use case illustrates a situation where both WebSphere Portal and
WebSEAL sessions have timed out. When trying to access a portal page after
session timeout, the user receives a login prompt. After entering username and
password and submitting the form, the user receives an error message
instructing him to establish a new session. After clicking the Login button, the
system does not ask for a username and password, and displays the
personalized portal home page. Each component works as designed, but the
overall system behavior is not as desired.

Table 4-11 UCT7: Both WebSEAL and WebSphere Portal sessions time out
Use Case ID: UCT7 UCT7: Both WebSEAL and WebSphere Portal sessions
time out
Description This use case is used to demonstrate a situation when both

WebSEAL and WebSphere Portal sessions time out. The
system behavior from user point of view may not be as
expected.

pages after restarting the browser to ensure there are no
established sessions.
Actors Customer.

browser.
submits the page.
same page.
submits the page.
8. System displays a session timeout error message and
instructs the user to reestablish the session.
9. User clicks the Login button.
10. System displays protected home page without asking for
username/password.
Set PD-S-SESSION-ID
cookie. Path: /
HTTP 200 OK (login.html)
Set PD-S-SESSION-ID
cookie. Path: /
GET /portal/wps/myportal GET /wps/myportal Set JSESSIONID

cookie. Path:/wps
cookie. Path:/
Wait more than 3 minutes for both WebSEAL and WebSphere Portal session inactivity timeout

PD-S-SESSION-ID session has expired
Set PD-S-SESSION-ID
cookie. Path: /
Set PD-S-SESSION-ID
cookie. Path: /
Send PD-S-SESSION-ID and Send JSESSIONID cookie JSESSIONID

AMWEB!%2Fportal!JSESSIONID session has expired
cookies
Set AMWEB!%2Fportal!JSESSIONID Set JSESSIONID

cookie. Path:/ cookie. Path:/wps


GET GET
HTTP 200 OK (session timeout message) HTTP 200 OK (session timeout message)
User clicks the Log in link

AMWEB!%2Fportal!JSESSIONID
cookies Send JSESSIONID cookie
GET /wps/myportal/!ut/p/.scr/Home GET /wps/myportal/!ut/p/.scr/Home Set JSESSIONID

cookie. Path:/wps
HTTP 200 OK (customized home page) HTTP 200 OK (customized home page)
cookie. Path:/
Figure 4-13 UCT7: Both WebSEAL and WebSphere Portal sessions time out

The steps are:
1. The user accesses the customized portal page as illustrated in steps 1–9 in
“UCT5: WebSEAL session times out before portal session” on page 121.
2. The user waits more than 3 minutes. Both the WebSphere Portal session and
the WebSEAL session expire.
3. The user tries to access the customized page at:
The browser sends the PD-S-SESSION-ID cookie in the request.
headers.
Temporarily response to the user;s browser, setting the original page URI
immediately redirect to the specified URI. WebSEAL creates a new user
session by setting the PD-S-SESSION-ID cookie in the response headers.
https://<webseal_full_hostname>/portal/wps/myportal
Sending the PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID
cookies in the request.
10.WebSphere Portal determines that the session identified by the JSESSIONID
cookie has expired and displays an error message: Your portal session has
timed out because of no activity. Please start a new session at your
portal Home.
11.The user clicks the Log in link on the error page.
12.Since the PD-S-SESSION-ID session is valid, WebSEAL does not ask for
authentication and forwards the request to WebSphere Portal.
13.WebSphere Portal generates a new User session object, renders the home
page for the logged-in user, and sets the JSESSIONID cookie in the response
headers.
14.WebSEAL performs response URL and cookie filtering and sends the
4.3.8 UCT8: WebSphere Portal logout after WebSEAL session

timeout
This test case illustrates a situation where the user clicks the log out link on the
WebSphere Portal page after the WebSEAL session has timed out. After clicking
Log out, the user is requested to reauthenticate by WebSEAL by entering a
username and password. Each component works as designed, but the overall
system behavior is not as desired. The user should not be prompted for a
password when logging out.
Table 4-12 UCT8: WebSphere Portal logout after WebSEAL session timeout
Use Case ID: UCT8 UCT8: WebSphere Portal logout after WebSEAL
session timeout
Description This use case is used to demonstrate a situation when the

user clicks the Log out link after the WebSEAL session has
timed out. The system behavior from the user point of view is
not as expected.

򐂰 The actor has logged in and accessed protected portal
pages.
򐂰 WebSEAL session has timed out.
Actors Customer.
Main Scenario 1. Actor clicks the Log out link on the protected portal
page.
submits the page.
4. System performs logout and displays the home page for
unauthenticated portal users.

GET /portal/wps/myportal/!ut/p/.cmd/lo
PD-S-SESSION-ID
session has expired
User enters the username and password

HTTP 302 MOVED to Set PD-S-SESSION-ID
/portal/wps/myportal/!ut/p/.cmd/lo cookie. Path: /
GET /portal/wps/myportal/!ut/p/.cmd/lo GET /wps/myportal/!ut/p/.cmd/lo

/pkmslogout?filename=wpslogout.html /pkmslogout?filename=wpslogout.html
GET /pkmslogout?filename=wpslogout.html
HTTP 200 OK (WebSEAL logout message)
Browser redirects to /portal/wps/portal URL as specified in HTML REFRESH meta-tag

GET /portal/wps/portal GET /portal/wps/portal
HTTP 200 OK (default unprotected page) HTTP 200 OK (default unprotected page)
Figure 4-14 Sequence diagram - UCT8: WebSphere Portal logout after WebSEAL session timeout
The steps are:

1. A logged-in user has been inactive for some time and the WebSEAL session
has timed out. A protected portal page is still displayed in the user’s browser
and the user clicks the Log out link.
2. The browser sends a request to the /portal/wps/myportal/!ut/p/.cmd/lo URL,
which should invoke the WebSphere Portal logout command.
headers.
Temporarily response to the user’s browser, setting the original page URI
(/portal/wps/myportal/!ut/p/.cmd/lo) in the Location header field. It will cause
the browser to immediately redirect to the specified URI. WebSEAL creates a
headers.
https://<webseal_full_hostname>/portal/wps/myportal/!ut/p/.cmd/lo
Sending the PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID
cookies in the request.
9. The WebSphere Portal logout command invalidates the WebSphere Portal
session and sends a redirect to the WebSEAL logout URL
(/pkmslogout?filename=wpslogout.html).
10.WebSEAL invalidates the user session and displays the wpslogout.html
page.
11.The wpslogout.html page contains an HTML REFRESH meta-tag pointing to
the default unprotected portal page at:
http://<webseal_full_hostname>/portal/wps/portal
12.The browser automatically makes a request to the unprotected page.
13.The system displays the home page for unauthenticated users.
4.4 Component connections

Figure 4-15 on page 135 illustrates the network connections between
components of the entry runtime environment described in 3.2.1, “Entry runtime
topology” on page 70.
Figure 4-15 on page 135 depicts the runtime environment before security
hardening. Chapter 11, “Security hardening” on page 471 provides guidelines

and instructions for security hardening after a functional environment has been
built.
Client data Reverse Proxy node
wsadmin
Security
WebSphere Portal node startServer
infrastructure xmlaccess
stopServer
33
Administrative Policy Server node serverStatus
communications IHS Admin WAS Admin ...
HTTP
31 32 34 35 36
HTTP
HTTP
SOAP/HTTPS
SOAP/HTTPS
SOAP/HTTPS
:9443 server1 :8880
:8008
Admin Console
IHS Admin
Server :8881
WebSphere_Portal
:80 :80
:50000
WAS 22 DB2 PORTAL
/portal 3 HTTPS IHS :50001
1 HTTP :80 plugin 4 HTTP Portal core DB
junction :443 :9081 23 LDAP
HTTPS :443
2 24 IIOP ITSO Bank
:7234
WebSEAL ITSO Bank portlets 25 DB
User, IIOP
5 6
Portal Admin :50000
:8882
ITSOBankServer :50001
LD
:2810
AP
Policy Server/SSL
ITSO Bank back- 26 DB2

end application 27 LDAP
30
WebSphere Security
7 HTTP :8008 IHS Admin wsadmin
Server
startServer Access Manager Java
Runtime Environment
LDAP
:80 WAS stopServer
IHS Admin IHS 29 28
plugin serverStatus
Authorization aznAPI/SSL
...
Policy Server/SSL
10
HTTP
11
SOAP/HTTP
:9080
server1 :8880 :389 :389

8 HTTP
Admin Console LDAP
12 LDAP Admin
:3538
Admin :389
9 HTTP :9080 Daemon
IDS Web App 13 LDAP
LDAP Admin, :389 :389
TAM Admin,
14 LDAP
WAS Admin TAM WPM LDAP
:389
:50000
21 DB2 :50001
Access Manager Java LDAP DB
Runtime Environment
Policy Server/SSL
15 :389
TAM Administration/SSL
LDA
AP
P
LD
:7135 17 20
:7135
18 TAM Administration/SSL :7136
Authorization
Policy Server :7137
Server
16
Policy Server/SSL 19
:7135
:7135
Figure 4-15 Runtime environment component connection diagram

The steps are:
1. Connection from client browser to WebSEAL.
– Protocol: HTTP
– Port: 80
– Usage: Client requests
2. Secure connection from client browser to WebSEAL.
– Protocol: HTTPS
– Port: 443
– Usage: Client requests, WebSphere Portal administration
3. Secure connection for /portal junction from WebSEAL to IBM HTTP Server.
– Protocol: HTTPS
– Port: 443
– Usage: Client requests with iv-user credential if authenticated by
WebSEAL
4. Connection from IBM HTTP Server to WebSphere_Portal application server
HTTP transport.
– Protocol: HTTP
– Port: 9081
– Usage: Client requests with iv-user credential if authenticated by
WebSEAL
5. Secure connection from WebSEAL to Tivoli Access Manager Policy Server.
– Protocol: Tivoli Access Manager internal communications over SSL
– Port: 7135
– Usage: Tivoli Access Manager internal communications
6. Connection from WebSEAL to LDAP registry (Tivoli Directory Server).
– Protocol: LDAP
– Port: 389
– Usage: LDAP queries
7. Connection from IBM HTTP Server administrator browser to IHS Admin
Server on Policy Server node.
– Protocol: HTTP
– Port: 8008
– Usage: IBM HTTP Server administration
8. Connection from Tivoli Directory Server and Tivoli Access Manager
administrator browser to the Web server on Policy Server node.
– Protocol: HTTP
– Port: 80
– Usage: Tivoli Directory Server administration, Tivoli Access
Manager administration, WebSphere Application Server
administration
9. Connection from Tivoli Directory Server and Tivoli Access Manager
administrator browser to the HTTP transport port for server1 application
server on Policy Server node.
– Protocol: HTTP
– Port: 9080
administration
10.Connection from IBM HTTP Server to server1 application server HTTP
transport on the Policy Server node.
– Protocol: HTTP
– Port: 9080
administration
11.Connection from WebSphere Application Server administration utilities (for
example wsadmin, startServer, stopServer, serverStatus) to server1
application server SOAP JMX connector on the Policy Server node.
– Protocol: SOAP over HTTP
– Port: 8880
– Usage: server1 application server administration
12.Connection from Tivoli Directory Server Web Administration Tool
(IDSWebApp) application to Tivoli Directory Server directory administration
daemon.
– Protocol: Tivoli Directory Server internal communications (non-SSL)
– Port: 3538
– Usage: Tivoli Directory Server administration commands
13.Connection from Tivoli Directory Server Web Administration Tool
(IDSWebApp) application to LDAP registry (Tivoli Directory Server).
– Protocol: LDAP
– Port: 389
– Usage: LDAP queries and updates
14.Connection from Tivoli Access Manager Web Portal Manager (TAMWPM)
application to LDAP registry (Tivoli Directory Server).
– Protocol: LDAP
– Port: 389

15.Secure connection from Tivoli Access Manager Web Portal Manager
(TAMWPM) application to Tivoli Access Manager Policy Server.
– Port: 7135
16.Secure connection from Tivoli Access Manager Policy Server to WebSEAL.
– Port: 7234
17.Connection from Tivoli Access Manager Policy Server to LDAP registry (Tivoli
Directory Server).
– Protocol: LDAP
– Port: 389
– Usage: LDAP queries and updates
18.Secure connection from Tivoli Access Manager Policy Server to Tivoli Access
Manager Authorization Server.
– Port: 7137
19.Secure connection from Tivoli Access Manager Authorization Server to Tivoli
Access Manager Policy Server.
– Port: 7135
20.Connection from Tivoli Access Manager Authorization Server to LDAP
registry (Tivoli Directory Server).
– Protocol: LDAP
– Port: 389
21.Connection from Tivoli Directory Server to DB2 database (LDAPDB).
– Protocol: DB2 client
– Ports: 50000,50001
– Usage: DB2 queries and updates
22.Connection from WebSphere Portal application to DB2 databases (WPS50,
WPCP50, FDBK50).
– Port: 50000
23.Connection from WebSphere Portal application to LDAP registry (Tivoli
Directory Server).
– Protocol: LDAP
– Port: 389
24.Connection from ITSOBank portlet application to ITSOBank back-end
application.
– Protocol: RMI/IIOP
– Port: Dynamically assigned by WebSphere Application Server
– Usage: Remote EJB calls
25.Connection from ITSOBank portlet application to ITSOBankServer
application server JNDI service.
– Protocol: IIOP
– Port: 2910
– Usage: JNDI lookups
26.Connection from ITSOBank back-end application to DB2 database
(ITSOBANK).
– Port: 50000,50001
27.Connection from ITSO Bank application to LDAP registry (Tivoli Directory
Server).
– Protocol: LDAP
– Port: 389
28.Secure connection from WebSphere Application Server to Tivoli Access
Manager Policy Server.
– Port: 7135
29.Secure connection from WebSphere Application Server to Tivoli Access
Manager Authorization Server.
– Port: 7136
– Usage: Authorization requests
30.Connection from WebSphere Application Server security services to LDAP
registry (Tivoli Directory Server).
– Protocol: LDAP

– Port: 389
31.Connection from IBM HTTP Server administrator browser to IHS Admin
Server on Portal Server node.
– Protocol: HTTP
– Port: 8008
– Usage: IBM HTTP Server administration
32.Secure connection from WebSphere Application Server administrator
browser to server1 application server on Portal Server node.
– Protocol: HTTPS
– Port: 9443
– Usage: WebSphere Application Server administration
33.Connection from xmlaccess utility to WebSphere Portal HTTP server
– Protocol: HTTP
– Port: 80
– Usage: WebSphere Portal deployment/configuration commands and data
34.Secure connection from WebSphere Application Server administration
utilities (for example wsadmin, startServer, stopServer, serverStatus) to
server1 application server SOAP JMX connector on Portal Server node.
– Protocol: SOAP over HTTPS
– Port: 8880
– Usage: server1 application server administration
WebSphere_Portal application server SOAP JMX connector on Portal Server
node.
– Port: 8881
– Usage: WebSphere_Portal application server administration
ITSOBankServer application server SOAP JMX connector on Portal Server
node.
– Port: 8882
– Usage: ITSOBank application server administration
Part 2
Part 2 ITSO working

example secure
portal solution

5
Chapter 5. Requirements and solution

design
This chapter describes a basic business scenario for a secure portal solution. It
presents the functional and non-functional requirements for the scenario and
draws on these requirements to produce use cases identifying the user
interactions with the system. The requirements and use cases are fulfilled by
implementing the solution architecture, runtime and development environments,
and developing the application.
The business scenario used in this chapter is that of the fictitious ITSO Bank.
The ITSO Bank would like to implement a secure portal banking portal
application to extend the hours of operation to its customers. This scenario will
be used to illustrate the major phases of solution development for a secure portal
application and will thus be referred to in the remaining chapters.

򐂰 Business scenario
򐂰 Business requirements
򐂰 Use case model
򐂰 Architecture

5.1 Business scenario
This section explains the initial context of the ITSO Bank business scenario, and
describes the business challenges and drivers for the desired secure portal
solution.
5.1.1 Initial context

The ITSO Bank has developed a simple online banking application that runs on
WebSphere Portal. The solution is currently in its first release and is only
available internally within the bank for access by employees. As such, the
application presently has limited functionality and limited security.
The ITSO Bank wants to extend access to their customers and to do so must
deploy the current application within a proven security infrastructure.
The existing banking application includes the following features:

򐂰 User account creation
򐂰 User account deletion
򐂰 User account modification
򐂰 Transaction history query
򐂰 Account balance query
򐂰 Funds transfer
The banking portal provides a basic user interface that allows access to this
functionality depending on the user’s role of bank manager or customer. As a
bank manager, the user is authorized to access all features described above.
The customer role has a limited subset of functionality and is only authorized to
access the account balance query and funds transfer functions. This
authorization is currently determined by the user’s role assignment within the
WebSphere Portal Server.
As the application is currently only available internally to the bank, system

component placement is less complex than what it will be when deployed as a
secure application. At present, the internal network zone and the production
zone are the only zones of concern, as external access to the application is not
given. The development domain for the application is situated in the Internal
Network Zone, and the banking application and database domain are located
behind a firewall in the Production Zone, as displayed in Figure 5-1 on page 145.
Outside Zone DMZ Production Zone Internal Network
Intranet
Public Key Banking Internal

Infrastructure Application User
Protocol Firewall
Domain Firewall
Domain Firewall
I
N
T
E
Browser R
User N
E
T
Database Development
Domain Domain
Domain
Name Server
Figure 5-1 ITSO Bank’s current zone topology
5.1.2 Business challenges

After the successful deployment of the banking application within ITSO Bank’s
internal network, ITSO Bank management has decided to take the next step and
roll it out for external access by the bank’s customers. A number of business
challenges have been identified for this rollout including:
򐂰 ITSO Bank plans to host a number of Web applications in the future and
wishes to implement an authentication solution supporting single sign-on
across these applications to provide a unified banking experience.
򐂰 ITSO Bank has identified that their current organizational security policies are
inconsistent and inadequate. Management wants consistent security policies
to be applied across the whole organization, as well as the banking
application. This includes authorization to specific resource such as portlets
and back-end EJBs.
򐂰 ITSO Bank’s competitors are well trusted by their users, as they provide
security solutions that appear comprehensive and robust. In order to
compete, ITSO Bank must also generate a high level of trust through the
chosen security solution.
򐂰 The cost of security management must be reasonable and predictable; thus
the registry and security policies must be easily maintainable.
Chapter 5. Requirements and solution design 145

򐂰 ITSO Bank currently has a high level of customer growth (35 percent per
annum) and expects that this level of growth will be maintained over the next
two years. The solution must be able to handle this large influx of customer
registrations and transactions as the customer base expands.
򐂰 ITSO Bank expects that some areas of the banking application will contain
sensitive information in the future. ITSO Bank needs to ensure user integrity
in these areas and wishes for the user to prove himself with more than one
authentication mechanism before allowing access.
򐂰 ITSO Bank wishes to make the auditing easier for administrators; thus a
common audit trail for all Web applications is desirable.
򐂰 Customers must be able to access the banking application 24 hours a day,
seven days a week.
5.2 Business requirements

This section presents the business requirements for the ITSO Bank secure portal
business scenario. These requirements have been derived from the main user
groups of the banking application, as well as from the identified business
challenges identified earlier. This section is organized into functional and
non-functional requirements.
5.2.1 Functional requirements

This section documents what the system must be able to do and the set of
functions and tasks that it is required to perform. These requirements have been
recorded by the user group for those user groups accessing the core functionality
of the banking application.
ITSO Bank customer requirements

ITSO Bank was able to identify the following functional requirements of the
customer:
򐂰 Navigate the application intuitively.
򐂰 Perform banking transactions in a secure environment.
򐂰 Use single sign-on (SSO) to access to all banking applications the user has
access.
򐂰 Transfer funds between accounts.
򐂰 View their account balance online.
ITSO Bank manager requirements
The following functional requirements of the ITSO Bank manager have been
identified:
򐂰 Minimize staff training time for the application.
򐂰 View a history log of the customer’s transactions.
򐂰 Provide a single authentication and authorization security infrastructure for all
current and future banking applications.
򐂰 Delete unused customer accounts from the system.
򐂰 Access the customer’s account balance data quickly.
򐂰 Create new customer accounts.
򐂰 Modify customer information, for example, change their address.
Security administration requirements

Security administrators have identified the following requirements for the
solution:
򐂰 Configure the system for single sign-on authentication.
򐂰 Multiple forms of authentication must be possible to implement.
򐂰 Step-up authentication must be possible to implement.
򐂰 Session duration and session inactivity time-outs must be able to be
implemented.
򐂰 There must be the means for account lockout after a specified number of
invalid password attempts.
Portal administrator requirements

The portal administrators require the following in the solution:
򐂰 Security functionality must be fast to develop, test and maintain.
򐂰 Security functionality must use existing APIs to reduce the amount of
application code to develop, leading to faster development.
5.2.2 Non-functional requirements

The non-functional requirements for a system address those aspects of the
system that affect how well the system will perform. These aspects can have a
profound effect on how the users interact with the system and their acceptance
of and satisfaction with the system.

The non-functional aspects of the ITSO Bank system cover a broad range of
themes, such as the following:
򐂰 Performance
򐂰 Scalability
򐂰 Availability
򐂰 Maintainability
򐂰 Security
These non-functional requirements heavily dictate the design and development

of the operational model of the system including the computers, networks, and
other platforms that the application will execute on and the way the system is
configured and managed.
They also feed into the design of technical and application components.
Non-functional requirements therefore provide a basis for early system sizing
and cost estimates. Together with the functional requirements, the non-functional
requirements define the baseline against which the business system must be
designed.
This section also includes the following constraints that the system must conform
to or satisfy:
򐂰 Performance
򐂰 Scalability
򐂰 Availability
򐂰 Security
Performance
The performance requirements of a system are actually defined by a set of four
sub-requirements:
򐂰 Response time requirements
򐂰 Throughput requirements (dynamic volumetric requirements)
򐂰 Utilization requirements
򐂰 Static volumetric requirements
These sub-requirements must each be analyzed to properly define the

performance baseline to which the system must be designed. The system must
be designed to meet the required response times, while supporting the
throughput requirements mapped against the given static volumetric baseline, on
a system platform that does not exceed the stated utilization.
Each of these sub-requirements is briefly detailed below.
Response time requirements
Response time specifies the time within which the system must complete specific
processes, for example, the time within which the system must process a funds
transfer. It is important to focus on the requirements of the business when setting
response time targets rather than becoming seduced by the vision of sub-second
IT transaction response. The real driver for the business is its ability to perform a
business process in a time that will be acceptable to its customers. If this real
driver is overlooked, the cost of achieving the set response time may be greatly
inflated as oversized hardware may be purchased to achieve the result.
Table 5-1 on page 149 provides a set of generic response time bands required
for transactions of different levels of complexity within the ITSO Bank system.
Table 5-1 Response time requirements

Business High frequency Medium Low frequency
Transaction (for example, > frequency (for example, < 10
Complexity 100 time per day) (for example, > 10 times per day)
times per day but
< 100 times per
day)
Simple Transaction 1–2 2–3 3–4
Medium 3–5 4–7 5–10

Transaction
Complex 6–10 8–15 11–20

Transaction
Other > 20 > 30 > 40
Throughput requirements (dynamic volumetric requirements)

Throughput requirements specify a given number of business- or system-related
processes that the system must process within a given unit of time. For example:
򐂰 The number of account balance enquiries processed per day
򐂰 The number of new user registrations processed per day
This activity requires an understanding of the frequency of invocation of each of

the business processes of the system. Table 5-2 lists the throughput
requirements of the ITSO Bank application per use case.
Note: The use case details for the ITSO Bank can be found in 5.3, “Use case
model” on page 155.

Table 5-2 Throughput requirements
Use Information Volume Sizing Information
Cases Information
UCF1 Log in and out of the security Small 70% of 20000

UCF2 application: Authentication and customers per day =
UCA4 authorization. 14000
UCA5
UCF3 Add a new user to the application Medium 100 registrations per
registry: Customer details. amount of data day
20000 customer
accounts active
UCF4 Modify user information: Medium 10% of customers =

Customer details. amount of data 2000 per day
UCF5 Delete user: Customer details. Medium 0.05% customers =

amount of data 10 per day
UCF6 View transaction history: Data Large amount All customer

about user transactions. of data accounts once a
week
UCF7 View account balance: Account Small amount 70% of customers=

numbers and balance of data 14000 per day
information.
UCF8 Transfer funds: Account Small amount 70% of customers =

numbers, balance information, of data 14000 per day
transfer amounts.
UCA1 Add and delete portlet in Medium Once a month

UCA2 WebSphere Portal: Information to
publish.
UCA5 Configure security settings: Small Once a month

Security configuration data.
Utilization requirements
This sub-requirement specifies the maximum acceptable load placed on the
nodes of the business system when running the intended workload of the
system. The performance architect must size the system such that the overall
utilization of the key system components is within the bounds of acceptable
behavior when supporting this workload. The ITSO Bank has set the utilization
requirement such that all platform configurations for the solution should result in
a utilization of less of less than 70 percent. For example, the maximum
bandwidth usage must be no more than 70 percent of the actual bandwidth
available to the system.
Static volumetric requirements
This sub-requirement specifies the volume of data entities that exist within the
target system that, although relatively static, are likely to have a significant effect
on the overall sizing of the target system. Examples include the following:
򐂰 The number of business system users by type
򐂰 The number of different user locations
The ITSO Bank has identified the following static volumetric data:
򐂰 Current customer base is approximately 20000 users
򐂰 Current number of portal administrators is three
򐂰 Current number of security administrators is two
򐂰 Each user has on average two accounts with the bank
򐂰 95 percent of users are located in ITSO Bank’s home country
Scalability
Scalability can be defined as the ability to increase the number of users or
capabilities of a solution without making significant changes to the solution’s
systems or software. Together with performance requirements,
scalability-related requirements provide the baseline against which subsequent
performance engineering activities are scoped and executed.
It has been identified that ITSO Bank currently has a high level of customer
growth of 35 percent and ITSO Bank management expects that this level of
growth will be maintained over the next two years. ITSO Bank management
identified a business challenge in 5.1.2, “Business challenges” on page 145, that
the application should be able to handle this huge increase in customers.
Scalability is therefore a very important requirement of the solution.
Availability
Availability is simply the ability of a solution to perform its required function over a
stated period of time. Availability is usually expressed as a ratio of the time the
service is actually available for use of the stated service hours. In this section we
identify the expected availability for various functionality, fallback plans, recovery
requirements, and the number of acceptable outages per time period.
Availability requirements for the ITSO Bank application vary by use case; each
row of the following table represents a collection of use cases with common
availability requirements. For use case details please refer to Table 5-5 on
page 157.

Table 5-3 Availability requirements
Use Service Fallback Availability Recovery Number of
Cases hour plan req requirement outages
high/ acceptable
medium/
low*
UCF1 Almost Customer High 1 hour 2/year

UCF2 24 uses recovery
UCF7 hours telephone
UCF8 banking
UCF3 08:00 - Bank staff High 1 hour 4/year

UCF4 18:00 record data recovery
UCF5 in old
system
UCF6 08:00 - - Medium Next day 4/year

18:00 recovery
UCA1 20:00 - - M Next day 2/month

UCA2 24:00
UCA3
UCA4
UCA5 Almost - VH 1/2 hour 2/year

24
hours
Maintainability
Maintainability can be defined as ease of which a system can be restored to its
functional state when maintenance is performed on the system. ITSO Bank
identified in their business challenges that they require a solution where
maintenance of the security component of the system must have a reasonable
and predictable cost. They also identified a requirement of a common audit trail
for all applications to increase the ease of maintaining audit data. Maintainability
of the security component of the solution is therefore an important requirement
for ITSO Bank.
Security
The requirements of a security system can be categorized into five sub-systems:
򐂰 Audit
򐂰 Access control (authorization)
򐂰 Flow control
򐂰 Identity and credentials (authentication)
򐂰 Solution integrity
ITSO Bank has identified that in order to make the banking application available
to the customer, a comprehensive and robust security architecture must be
implemented. The chosen security architecture must therefore address all of the
five security sub-systems listed above. ITSO Bank needs to be able to assure
their customers that their accounts and personal details are protected from
attack and that the application data has integrity. As noted in ITSO Bank’s
business requirements, the bank also requires that the implemented security
solution provides a consistent level of security organization-wide and provides an
API to reduce application development time.
To address all the security requirements, ITSO Bank has decided to use IBM
Tivoli Access Manager for e-business V5.1 for their security architecture and the
associated APIs. The Tivoli Access Manager infrastructure will be used for
authentication, single sign-on, and authorization to resources.
System constraints
System constraints are business and technical constraints that impact the design
of the system, for example, geographical location constraints or existing
hardware or software that must be used. Since the ITSO Bank has already
written and internally deployed the application that will be modified to produce
the secure banking application, a number of system constraints have been
imposed. Table 5-4 lists the known system constraints for the ITSO Bank
production environment and the associated prerequisites, including mandatory
standards for the component structure.
Table 5-4 System constraints for ITSO Bank application

Constraint ID Comment
SC01 Portal Server

– IBM WebSphere Portal Extend for Multiplatforms V5.0.2
SC02 Database
– DB2 Universal Database V8.1, Enterprise Server Edition
SC03 Directory Server

– Tivoli Directory Server V5.2
SC04 Production servers

– 1 CPU, Intel® PIII, 1GHz
– 1152 MB main memory
– 18GB DASD
– 1 IBM Ethernet adapter
– Windows 2000 Server, Service Pack 4

Constraint ID Comment
SC05 Development workstations

– 1 CPU, Intel P4, 1.8GHz
– 1024 MB main memory
– 27GB hard disk
– 1 IBM Ethernet adapter
– Windows 2000 Professional, Service Pack 3
SC06 Client browsers

– Internet Explorer >= 5.5 or higher
– Netscape Navigator >= 4.7 or higher
SC07 Network
– TCP/IP and Ethernet
SC08 Separation of End User Component, Application Component, and

Data Component
– Each component can be amended without dependence on
amendments to any other components
SC09 Characteristics of Application Component

– Performs business function and validation
– Portable to other hardware and software platforms without
amendment
– Each application unit of work can be executed in isolation of
other application units of work
– Application units of work are separate from data accesses
– Access to some components requires an authorization check
on the user’s profile
SC10 Characteristics of Data Component

– Relational
– Maintain integrity at all times, whatever the application units
of work and whatever platform they are running on
– Fully recoverable at the level of the application unit of work
– Data accesses are always called from an application unit of
work
– Zero data duplication as a goal compromised only for
performance, recoverability, integrity, or security reasons
– Portable to other relational databases on other software and
hardware platforms
SC11 Security API

– Tivoli Access Manager APIs must be used when coding the
application’s authentication and authorization capabilities
5.3 Use case model
This section presents the use case model, which has been derived from analysis
of the identified business requirements. The use case model helps to break down
the requirements and shows how the users with specific roles will interact with
the system to achieve their goals. Textual descriptions provide further detail for
each use case.
5.3.1 Use case overview

This section describes the ITSO Bank scenario’s actors, provides a use case
diagram, and summarizes the use cases represented in the diagram.
Actors defined
The actors are people or systems outside of the ITSO Bank application that
interact with the system. This section identifies primary and secondary actors,
where a primary actor is one who uses the system’s main functionality, and a
secondary actor is one who performs administration or maintenance tasks on the
system. Figure 5-2 on page 155 depicts the actors of the ITSO Bank application.
Actors
Primary Secondary
Actors Actors
Customer Customer Bank Manager Portal Security

Service Administrator Administrator
Representative
Figure 5-2 ITSO Bank application actors
Primary actors
The primary actors in our business scenario are as follows:
򐂰 Customer
򐂰 Customer service representative

򐂰 Bank manager
Note: For the ITSO working example, we did not implement the Customer
Service Representative role.
Secondary actors
The secondary actors in our business scenario are as follows:
򐂰 Security Administrator
򐂰 Portal Administrator
Use case diagram

This section provides a use case diagram that graphically summarizes the
interactions of the actors with the system, as seen in Figure 5-3 on page 156.
ITSO Banking Application
Transfer Login to
Portal
Funds
Domain
Banking Logout of
Application Portal
Login Domain
Banking
Add
Application
Portlet
Customer Logout
View
Account Edit
Balance Portlet Portal
Administrator
Delete
Portal
Configure
Portal
Settings
Add
User
Modify
User
Information
View
Configure Contract
Security History
Settings
Delete Bank
Security User
Administrator Manager
Figure 5-3 Use case diagram
Summary of use cases
This section expands on the use case diagram by providing a brief description of
each use case including the name of the use case, the goals of the use case,
and the actors involved.
The primary actor, or front-end, use cases can be found in Table 5-5 and the
secondary actor, or administrative, use cases can be found in Table 5-6 on
page 157.
Table 5-5 Front-end use cases
Use Use case name Goal in context Actors

case ID
UCF1 Application login Log in to banking application. Manager

Customer
UCF2 Application logout Log out of banking application. Manager

Customer
UCF3 Add user Register a new customer and his Manager

information in the enterprise
directory.
UCF4 Modify user Update a user’s account details. Manager

information
UCF5 Delete user Delete a customer account Manager

including customer details.
UCF6 View transaction View the transaction history of a Manager

history customer.
UCF7 View account View the balance of a customer Manager

balance account. Customer
UCF8 Transfer funds Transfer funds from one account to Customer

another.
Table 5-6 Administrative use cases

case
ID
UCA1 Add portlet Deploy WebSphere portlet on the Portal

productive server. administrator
UCA2 Delete portlet Delete WebSphere portlet from the Portal

productive server. administrator

case
ID
UCA3 Login to Portal Log in to the WebSphere Portal Portal

domain Server administration interface. administrator
UCA4 Logout of Portal Log out of the WebSphere Portal Portal

domain Server administration interface. administrator
UCA5 Configure security Configure the settings of the security Security

settings product. administrator
5.3.2 Front-end use cases

This section provides details about the use cases where the actor accesses the
main functions of the application through the front-end of the banking application.
These use cases cover the manager and customer interactions with the ITSO
Bank application.
Table 5-7 UCF1: Application login
Use Case ID: Name UCF1: Application login
Description This use case is used by all front-end accessing actors to log
in to the ITSO Bank application.
Precondition Actor must be a registered user of the system.
Primary actors Bank manager, customer.
Secondary actor None.
Main Scenario 1. Actor fills out the login form.

a. User accesses the ITSO Bank site with browser.
b. Login form is presented.
c. Actor fills in user name and password.
2. Actor submits the login form.
3. System receives the login request and determines
identity.
4. System creates user credential.
5. Actor is logged in.
Alternatives 1. Log in actor using a different authentication mechanism.

2. System requires user to supply more than one
authentication mechanism to access a particular object.
User would provide the second method before being
given access to the object.
Use Case ID: Name UCF1: Application login
Chapter/section that 12.5.1, “Banking application login” on page 557.

fulfills use case
Table 5-8 UCF2: Application logout
Use Case ID: Name UCF2: Application logout
Description This use case is used by all front-end accessing actors to log
out of the ITSO Bank application.
Precondition Actor is logged in to the banking application.
Primary actor Bank manager/customer.
Main Scenario 1. Actor clicks the logout button.

2. Actor is logged out of the WebSphere Portal application
and Tivoli Access Manager.
Alternatives Actor closes browser and session is lost, thus logging the
user off.
Chapter/section that None.

fulfills use case
Table 5-9 UCF3: Add user
Use Case ID: Name UCF3: Add user
Description This is the use case used to add a new customer record to
the banking application.
Precondition Actor is logged into the banking application.
Primary actor Bank manager.

Use Case ID: Name UCF3: Add user
Main Scenario 1. Actor accesses the Add User page.

2. Actor fills out new user’s information in the form.
Compulsory fields are userid, password and date of
birth.
3. Actor clicks Add User to submit the form.
4. System asks actor to confirm user creation.
5. Actor clicks OK to confirm creation.
a. Form could be rejected due to missing compulsory
fields. Actor would be diverted back to step 2 to fill in
missing data.
6. New user information is added in the ITSO Bank
database and LDAP user registry using APIs ,and
confirmation of account creation is provided.
Alternatives 1. User could be manually provisioned using Tivoli Access

Manager.
2. In the future, Tivoli Identity Manager could be used for
provisioning users.
Chapter/section that 12.5.2, “Add user” on page 559.

fulfills use case
Table 5-10 UCF4: Modify user information
Use Case ID: Name UCF4: Modify user information
Description This is a primary use case to handle the modification of the

banking application’s users’ details.
Precondition Actor is logged in.
Main Scenario 1. Actor accesses the Modify User page.

2. Actor types in user id of customer in question and clicks
Query User in the Modify User portlet.
3. System finds user information in database.
4. System displays user information.
5. Actor makes necessary changes.
6. Actor clicks Modify user to submit form.
7. System asks actor to confirm modification.
8. Actor clicks OK to confirm modification.
9. System updates user record in database and displays
confirmation of update.
Use Case ID: Name UCF4: Modify user information
Alternatives User data could be manually updated in the enterprise

directory server and database.
Chapter/Section that 12.5.3, “Modify user information” on page 563.

fulfills use case
Table 5-11 UCF5: Delete user
Use Case ID: Name UCF5: Delete user
Description This is a primary use case to handle the deletion of a user

from the banking application.
Main Scenario 1. Actor accesses Modify User page.

2. Actor types in user ID of customer in question and clicks
Query User in the Modify User portlet.
3. System finds user information in database.
4. System clicks user information.
5. Actor presses Delete User button.
6. System asks user to confirm delete.
7. User clicks OK to confirm delete.
8. System deletes the user records from the database and
enterprise directory server and shows confirmation of
update.
Alternatives 1. User could be manually removed using Tivoli Access

Manager.
2. In the future, Tivoli Identity Manager could be used for
de-provisioning users.

fulfills use case
Table 5-12 UCF6: View transaction history
Use Case ID: Name UCF6: View transaction history
Description This is a primary use case for viewing a user’s transaction

history.

Use Case ID: Name UCF6: View transaction history
Main Scenario 1. Actor accesses Modify User page.

2. Actor types the user ID of customer in question into the
Transaction History portlet and clicks Search.
3. System finds user transaction history information in
database.
4. System displays user transaction history information.
Alternatives History information could be manually accessed with a

database query.
Chapter/Section that None.

fulfills use case
Table 5-13 UCF7: View account balance
Use Case ID: Name UCF7: View account balance
Description This is a primary use case for viewing a user’s account

balance.
Primary actor Bank manager/customer.
Main Scenario 1. Actor accesses Account Balance® portlet:

– If user is a customer this is located on the Access
Accounts page.
– If user is a bank manager this portlet is located on
the Modify User page.
2. Account balance is queried in the database.
– If actor is a customer no user ID is required.
– If actor is a bank manager, type a user ID in the
Userid field and click Query Accounts
3. Account balance is displayed.
Alternatives Account balance could be accessed manually with a

database query.
Chapter/section that 12.5.4, “View account balance” on page 566.

fulfills use case
Table 5-14 UCF8: Transfer funds
Use Case ID: Name UCF8: Transfer funds
Description This is a primary use case for transferring funds between a

user’s accounts.
Primary actor Customer.
Main Scenario 1. Actor browses to Transfer funds portlet on Access

Accounts page.
2. User fills in funds transfer form:
a. Actor selects account to transfer funds from.
b. Actor selects account to transfer funds to.
c. Actor fills in amount to transfer.
3. Actor clicks Execute to submit form.
4. System queries balance of account to ensure sufficient
funds.
a. Transfer may be rejected if insufficient funds exist.
Error message will be displayed and actor will be
redirected back to step 2.
5. System performs transfer and updates information in
database. Confirmation is displayed.
Alternatives None.
Chapter/Section that 12.5.5, “Transfer funds” on page 567.

fulfills use case
5.3.3 Administrative use cases

This section provides details for each of the administration use cases designed
for the maintenance of portlets and the application security.
Table 5-15 UCA1: Add portlet
Use Case ID: Name UCA1: Add portlet
Description This is a primary task to add a portlet to the ITSO Bank portal.
It covers the tasks to add an ITSO Bank portlet to a page.
Precondition Portal administrator is logged in.
Primary actor Portal administrator.

Use Case ID: Name UCA1: Add portlet
Main Scenario 1. Actor clicks Administration.

2. System displays portal user interface.
3. Actor clicks Manage portlets.
4. System displays all pages in content root.
5. Actor navigates to page she wishes to add portlet to.
6. System displays page.
7. Actor clicks Edit page layout (pencil icon).
8. System displays edit layout page.
9. Actor clicks Add portlet.
10. System displays search page.
11. Actor types ITSO into search field and clicks Search.
12. System displays a list of the ITSO portlets.
13. Actor selects portlet to add and clicks OK.
14. System adds portlet to page.
15. Actor clicks Done.
Alternatives None.
Chapter/Section that None.

fulfills use case
Table 5-16 UCA2: Delete portlet
Use Case ID: Name UCA2: Delete portlet
Description This is a primary task to delete a portlet from the ITSO Bank
portal. It covers the tasks to delete a portlet from a page.
Precondition None.
Main Scenario 1. Actor clicks Administration.

2. System displays portal user interface.
3. Actor clicks Manage portlets.
4. System displays all pages in content root.
5. Actor navigates to page he wishes to delete portlet from.
6. System displays page.
7. Actor clicks Edit page layout (pencil icon).
8. System displays edit layout page.
9. Actor clicks Delete portlet (trash can icon) for portlet
they wish to delete.
10. Actor clicks Done.
Alternatives None.
Use Case ID: Name UCA2: Delete portlet

fulfills use case
Table 5-17 UCA3:Login to portal domain
Use Case ID: Name UCA3: Login to portal domain
Description This use case is used to log in to the WebSphere Portal

administration interface.
Precondition Actor must be a registered user of the system.
Primary actors Portal administrator.
Main Scenario 1. Actor fills out the login form.

a. Actor goes to the WebSphere Portal administration
site with a browser.
b. Tivoli Access Manager login form is presented.
c. Actor fills in user name and password.
2. Actor submits the login form.
3. System receives the login request and makes
authentication and authorization decision.
4. System creates user credential.
5. Actor is logged in.
Alternatives 1. Log in actor using a different authentication mechanism.

2. System requires user to supply more than one
authentication mechanism to access a particular object.
User would provide the second method before being
given access to the object.

fulfills use case
Table 5-18 UCA4: Logout of portal domain
Use Case ID: Name UCA4: Logout of portal domain
Description This use case is used for logging out of the WebSphere
Portal administration interface.
Precondition Actor is logged in to the banking application.

Use Case ID: Name UCA4: Logout of portal domain
Main Scenario 1. Actor clicks the Logout button.

2. Actor is logged out of the WebSphere Portal application.
3. Actor is logged out of Tivoli Access Manager.
Alternatives Actor closes browser and session is lost, thus logging the
user off.

fulfills use case
Table 5-19 UCA5: Configure security settings
Use Case ID: Name UCA5: Configure security settings
Description This is the primary use case for making configuration

changes to the Tivoli Access Manager security settings.
Precondition Actor is logged into the Tivoli Access Manager administration

interface from the secure management zone.
Primary actors Security administrator.
Main Scenario 1. Actor browses to the configuration task of concern.

2. Actor makes configuration changes as necessary.
3. System updates configuration.
Alternatives Actor uses command line tool pdadmin to make security

configuration changes.
1. Actor types security configuration commands into
pdadmin.
2. System updates configuration.

fulfills use case
5.4 Architecture
This section presents a high-level architecture diagram of the proposed security
system for the ITSO Bank application. Analysis of the requirements and the use
case diagrams have provided us with the information we need to formulate a
security architecture that will meet the requirements of all the stakeholders of the
ITSO Bank application.
This section provides a brief architectural overview before detailing the key
concepts of the this high-level architecture, identifying architectural decisions
and introducing the selected runtime and development environments.
5.4.1 Architecture overview

This section presents the high-level component architecture (see Figure 5-4) as
well as key concepts. The architecture diagram is intended to graphically
summarize the key components of the ITSO Bank secure portal environment and
provide an understanding of how these components interact. It is not intended to
show options for high availability and scalability.
Internet Internet DMZ Production Zone
Portal
Portal Database
Reverse
Browser Proxy
I Management Zone
N
T
E
R Enterprise Directory
N
E Directory Database
T
Policy Master
Server Authorization
DB
Figure 5-4 ITSO Bank component diagram
Note: For further details about architecture models and high availability and
scalability options please see Chapter 3, “Architecture and topology selection”
on page 51. This high-level diagram maps to the selected runtime
environment discussed in Chapter 6, “Install the runtime environment” on
page 175.

Key concepts
The following descriptions detail the system-level architectural concepts of the
component diagram:
򐂰 Portal
This component enables users to access the WebSphere Portal functionality
of the ITSO Bank application using a Web browser. User requests are passed
to the portal server after the user is authenticated and deemed authorized to
make such requests by the security components. IBM WebSphere Portal
Extend for Multiplatforms V5.0.2.1 will be used.
򐂰 Portal database
The portal database provides a store for all data used by the ITSO Bank
application with the exception of the user data, which is stored in the
enterprise directory. Transaction history data and account balances are both
stored in the portal database. The ITSO Bank application will use IBM DB2
Universal Database V8.1.4 Enterprise Server Edition.
򐂰 Enterprise Directory Server
The enterprise directory provides an interface to the directory database,
where user profile data for all users of the ITSO Bank system is stored,
manipulated, and retrieved. Security components leverage this directory
when authenticating users, and the portal uses this directory to store data
associated with the user’s accounts. The enterprise directory used in the
ITSO Bank scenario will be Tivoli Directory Server V5.2.
򐂰 Policy server and authorization database
The policy server component maintains the master authorization database
that stores the protected objects’ space and the associated access control
lists and policies. The policy server replicates the master authorization
database to any other Access Manager Authorization Server that may be
configured in the secure domain and to applications such as WebSEAL and
third-party applications using the authorization API, configured in local cache
mode. The Policy Server and authorization database version to be used in the
ITSO Bank example is IBM Tivoli Access Manager for e-business V5.1.0.2.
򐂰 Reverse Proxy
The Reverse Proxy used in the ITSO Bank solution will be IBM Tivoli Access
Manager for e-business V5.1.0.2 WebSEAL. WebSEAL is more than a
Reverse Proxy, it is actually a high-performance, multi-threaded Web server
that applies a defined security policy to a protected object space, which also
has Reverse Proxy capabilities. All user requests in our architecture will first
be passed to WebSEAL, which will authenticate and authorize the user
before proxying the request to the application server where the requested
content lies. WebSEAL communicates with the Enterprise Directory Server
and the Policy Server for authentication and authorization decisions.
5.4.2 Architecture decisions

This section documents important decisions made about aspects of the chosen
architecture, including the structure of the system, software versions, and
protocols that must be used.
For the ITSO Bank working example, we have identified the following
architectural decisions:
򐂰 AD01: Product to use for the security architecture
򐂰 AD02: Authorization code to be used within application
򐂰 AD03: Where user data is to be stored
򐂰 AD04: Data component placement
򐂰 AD05: The protocol for user communication with the WebSEAL Reverse
Proxy server
򐂰 AD06: The protocol to be used for communication between WebSEAL and
the portal server
򐂰 AD07: Protocol to be used for communication with the directory server
These architectural decisions are detailed in the following tables.
Table 5-20 AD01: Product to be used for the security architecture

Architectural decision AD01
ID
Architectural Decision Which product should be used for the system’s security
architecture.
Problem Statement ITSO Bank wants to provide a robust and comprehensive

security architecture to secure the banking application from
unauthorized access and intrusion and to ensure users can
only access data that they are authorized to see.
Assumptions Security product must support configuration for WebSphere

Portal.

ID
Motivation Tivoli Access Manager provides a complete network

security and policy management solution, which when
combined with a corporate firewall system, can fully protect
a Web application from unauthorized access and intrusion.
Tivoli Access Manager provides an authentication and
authorization framework that ensures only authenticated
users will be able to access the banking functions that they
are authorized to access.
Alternatives 1. Use IBM Tivoli Access Manager for e-business V5.1

WebSEAL for security framework.
2. Use IBM Tivoli Access Manager for e-business V5.1
Web Server Plug-in for security framework.
3. Use another third-party security product.
Decision The first alternative was selected due to the well-known

secure integration with WebSphere Portal.
Table 5-21 AD02: Authorization code to be used within the application

Architectural Decision AD02
ID
Architectural Decision Which authorization code should be used for any

authorization decision within the banking application.
Problem Statement Application programming of security functionality is time and

resource intensive and often results in an organization
having a different set of security components for each
application. This makes the organization’s security policy
difficult and costly to maintain.
Assumptions None.
Motivation Tivoli Access Manager provides an authorization API that

allows developers to leverage the authorization functionality
of Tivoli Access Manager from within their applications.
Tivoli Access Manager can then remain the single store of
authorization rules and policies, which ensures the
organization’s security policy is fast and easy to maintain. As
a result, security functionality does not have to be written
and application development time is thus reduced.
Architectural Decision AD02
ID
Alternatives 1. Use Tivoli Access Manager authorization API for all

authorization decisions within the ITSO Bank
application.
2. Implement authorization decisions using the
WebSphere Portal APIs.
3. Write authorization code for every application within the
bank.
Decision The first alternative was selected to ensure all authorization

rules and policies are stored only within Tivoli Access
Manager.
Table 5-22 AD03: Where the user data is to be stored

ID
Architectural Decision Where the user data for the banking application is to be
stored.
Problem Statement Administration of user profiles becomes difficult when

multiple directories are used to store user profiles.
Assumptions Applications support the Lightweight Directory Access

Protocol (LDAP).
Motivation Using a single enterprise directory server to store all user

profile data needed by all the components of the solution
promotes easy maintenance of the set of user accounts.
Alternatives 1. Use Tivoli Directory Server V5.2 as the single

enterprise directory.
2. Use other third-party directory services that support the
LDAP protocol.
3. Use multiple directories to store user profile data.
Decision The first alternative was selected due to ease of integration

with both Tivoli Access Manager and WebSphere Portal.
Table 5-23 AD04: Data component placement

ID
Architectural Decision Where the main data components of the system are to be
located.

ID
Problem Statement Mission-critical data assets are stored within the ITSO Bank
databases. A possible attack from the Internet could result
in database manipulations with unknown side effects.
Assumptions Firewalls are set up and configured as defined by the ITSO

Bank security policies, ensuring the production and
management zones are restricted zones.
Motivation Data protection and access control.
Alternatives None.
Decision The Application server is to be located in the production

zone, and the and enterprise directory server and policy
server are to be located in the management zone.
Table 5-24 AD05: Protocol for user communication with WebSEAL

ID
Architectural Decision The protocol to be used for users to communicate with the
WebSEAL Reverse Proxy server.
Problem Statement The ITSO Bank application’s users must trust that their data
will be secure when accessing the ITSO Bank application.
Assumptions None.
Motivation To stop data interception.
Alternatives 1. Https can be used to encrypt user data for

communication between the user and WebSEAL.
2. Http can be used to communicate between the user and
WebSEAL.
Decision The first alternative was selected for authenticated access

to prevent interception sensitive user data.
The second alternative was selected for unauthenticated
access to improve performance.
Table 5-25 AD06: Protocol communication between WebSEAL and Portal server
ID
Architectural Decision The protocol to be used for communication between

WebSEAL and the portal server.
ID
Problem Statement Using HTTPS for all communications with the portal server
can lead to slow performance, especially in the case of
accessing image data. If the components that are
communicating are in trusted zones, then HTTP may be
used to increase performance. However, the use of HTTP
prevents unauthenticated access when TAI is used to
establish a trust relationship between WebSEAL and
WebSphere Portal.
Assumptions None.
Motivation Allow both authenticated and unauthenticated access over

the same junction.
Alternatives 1. Http can be used for communication between

WebSEAL and WebSphere Portal.
2. Https can be used to encrypt user data for
communication between WebSEAL and WebSphere
Portal.
Decision The second alternative was selected to allow both

authenticated and unauthenticated access.
Table 5-26 AD07: Protocol for communication with the directory server
ID
Architectural Decision The protocol to be used for users to communicate with the
directory server.
Problem Statement Sensitive user information is stored in the directory server,

and communication with the directory server should
therefore be secured.
Assumptions None.
Motivation To stop data interception.
Alternatives 1. Https can be used to encrypt user data for

communication between the user and WebSEAL.
2. HTTP could be used as the directory is located in a
secure zone.
Decision The first alternative was selected to increase security.

5.4.3 Selected runtime environment
We chose the entry runtime environment described in Chapter 3, “Architecture
and topology selection” on page 51, for the ITSO working example.
The implementation details are described in the following chapters:

򐂰 Chapter 6, “Install the runtime environment” on page 175
򐂰 Chapter 7, “Configure the runtime environment” on page 259
5.4.4 Selected development environment

We chose the all-in-one secure portal development environment configuration,
which is described in 3.3, “Development environment topology selection” on
page 81, for the ITSO working example.
The implementation details are described in Chapter 8, “Implement the

development environment” on page 361.
6
Chapter 6. Install the runtime

environment
This chapter describes how to install a secure portal runtime environment on the
Windows platform for the ITSO working example. The ITSO runtime environment
consists of three nodes: Reverse Proxy node, Portal node, and Policy Server
node. The procedures documented are intended to be used in conjunction with
the Tivoli Access Manager and WebSphere Portal product guides.
The value add of the ITSO working example runtime implementation is three fold.
First, we provide detailed procedures for installing the software components by
node. Second, the procedures include sample values that put into context the
information found in the product guides. Third, the procedures include best
practices, tips and workarounds based on our first-hand experiences.

򐂰 Planning
򐂰 Implement the Policy Server node
򐂰 Implement the Reverse Proxy node
򐂰 Implement the Portal Server node

6.1 Planning
This section describes the scenario for the ITSO working example runtime
environment, and provides information regarding the hardware and software
levels we used to implement the environment.
The implementation procedures for the ITSO working example runtime

environment (see Figure 6-1) will focus on the following nodes:
Note: We do not include procedures for implementing the firewalls.
Tivoli Access Manager IBM WebSphere Portal Extend V5.0.2.1

5.1.0.2 (Runtime, PDJRTE, IBM WebSphere Application Server
Web Security, WebSEAL) Enterprise 5.0.2.3
IBM GSKit 7.0.1.16 IBM DB2 UDB 8.1.4, ESE
IBM JRE 1.3.1 IBM JRE 1.3.1
Microsoft Windows 2000 Tivoli Access Manager 5.1 (PDJRTE)
Server + SP4 Microsoft Windows 2000 Server + SP4
I
N
Web T Reverse Proxy Portal Server
Browser E Node
R Node
Client
Protocol Firewall
N
Domain Firewall
wswin1 wpwin1
E
T
Domain Firewall
Policy Server
Node
tamwin1
Tivoli Access Manager 5.1.0.2 (Runtime, PDJRTE,

Policy, Authorization, Web Portal Mgr.)
Tivoli Directory Server 5.2 (Server, Client SDK,
Web Administration Tool)
IBM DB2 UDB 8.1.4, ESE
IBM GSKit 7.0.1.16
IBM JRE 1.3.1
IBM WebSphere Application Server V5.0.2
Microsoft Windows 2000 Server + SP4
Management Zone
Legend: Data related flows
Figure 6-1 ITSO working example: Secure Portal runtime environment on Windows
6.1.1 Hardware and software prerequisites

For detailed information on the hardware and software prerequisites, refer to the
following product installation guides and Web content:
򐂰 Base Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1362
򐂰 Web Security Installation Guide, IBM Tivoli Access Manager V5.1,
SC32-1361
򐂰 Installation and Configuration Guide, IBM Tivoli Directory Server V5.2,
SC32-1338
Chapter 6. Install the runtime environment 177

򐂰 IBM WebSphere Portal Extend for Multiplatforms V5.0.2 hardware and
software requirements:
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html#req5
6.1.2 Hardware used within the ITSO runtime environment

We used the following hardware within the ITSO working example secure portal
runtime environment on Windows:
– IBM eServer™ xSeries® 230 (8658-61Y)
• 1 CPU, Intel PIII 1 GHz
• 1152 MB main memory
• 18 GB DASD
• 1 IBM Ethernet adapter
• Hostname: tamwin1.itso.ral.ibm.com
– IBM eServer xSeries 230 (8658-61Y)
• 18 GB DASD
• Hostname: wpwin1.itso.ral.ibm.com
– IBM eServer xSeries 230 (8658-61Y)
• 18 GB DASD
• Hostname: wswin1.itso.ral.ibm.com
6.1.3 Software used within the ITSO runtime environment

We used the following software levels within the ITSO working example secure
portal runtime environment on Windows (Table 6-1, Table 6-2 on page 179, and
Table 6-3 on page 179).
Table 6-1 Policy Server node

Software Version
Microsoft Windows 2000 Server 2000 + Service Pack 4
IBM DB2 UDB, Enterprise Server Edition 8.1.4.428

Software Version
IBM GSKit 7.0.1.16
IBM WebSphere Application Server 5.0.2

Note: 5.0 + Fixpack 2
IBM Tivoli Directory Server 5.2

* Directory Server

* Access Manager Runtime Note: 5.1 + Base Fixpack 2
* Access Manager Java Runtime Environment
(PDJRTE)
Table 6-2 Reverse Proxy node

Software Version
IBM GSKit 7.0.1.16

* Access Manager Runtime Note: 5.1 + WebSEAL Fixpack 2 +
* Access Manager Java Runtime Environment Base Fixpack 2
(PDJRTE)
Table 6-3 Portal Server node

Software Version

Software Version
IBM WebSphere Application Server Enterprise

* WebSphere Application Server (Base) 5.0.2.3
Note: 5.0 + Fixpack 2 +
Cumulative Base Fix 3 + Fixes
* Programming Module Enhancement (PME) 5.0.2.2

Note: 5.0 + Fixpack 2 +
Cumulative PME Fix 2
IBM WebSphere Portal Extend for Multiplatforms 5.0.2.1

* WebSphere Portal Note: 5.0 + Fixpack 2 +
* WebSphere Portal Content Publisher Cumulative Fix 1 + Fixes


* Access Manager Java Runtime Environment Note: 5.1 + Base Fixpack 2
(PDJRTE)
IBM WebSphere Portal Extend for Multiplatforms V5.0.2 CDs

There are approximately 80 CDs included in the IBM WebSphere Portal Extend
for Multiplatforms V5.0.2. For the ITSO runtime environment on Windows 2000
Server, we used the CDs found in Table 6-4.
Note: Due to the vast number IBM WebSphere Portal Extend for
Multiplatforms V5.0.2 CDs and not so obvious naming of the CDs, we have
provided a listing of the CDs we used in our environment for reference
purposes (Table 6-4 on page 180).
Table 6-4 IBM WebSphere Portal Extend for Multiplatforms V5.0.2 CDs
CD WebSphere Portal component Version
Setup Portal Installer Version 5.0 for Multiplatforms

WebSphere Portal Toolkit Version 5.0
Portal InfoCenter Version 5.0.1
Fixpack WebSphere Portal 5.0 Fixpack Fixpack 2
1-1 WebSphere Application Server Enterprise for Windows Version 5.0
1-6 WebSphere Application Server Fixpack and Fixes for Fixpack 1 (V5.0.1)
Windows and Linux
CD WebSphere Portal component Version
1-17 WebSphere Application Server Fixpack and Fixes Fixpack 2 (V5.0.2)
2 WebSphere Portal Server Version 5.0

WebSphere Portal Content Publisher Version 5.0
Software downloads from IBM

In addition to the software included with IBM WebSphere Portal Extend for
Multiplatforms V5.0.2 and IBM Tivoli Access Manager for e-business V5.1, the
installation procedures found in this chapter provide instructions on how to
download and install newer fixpacks and fixes for the WebSphere Portal and
Tivoli Access Manager than are included in the CD distributions. Also, we use
IBM Tivoli Directory Server V5.2 in place of IBM Tivoli Directory Server V5.1 that
is included with both WebSphere Portal V5.0.2 and Tivoli Access Manager V5.1.
6.1.4 Software installation paths and variables

Table 6-5 lists the software installation paths and variables used to implement the
Policy Server node, Reverse Proxy node, and Portal Server node. We chose to
use short names for paths to reduce the number of characters included in the
Windows environment path and classpath. In addition, this can avoid problems
with spaces in the path. Lastly, we shortened the paths for quick access from the
command line.
Table 6-5 Software installation paths and variables

Software ITSO install path Variable
IBM DB2 UDB V8.1.2, Enterprise Server Edition c:\ibm\sqllib <db2_home>
IBM HTTP Server V1.3.26.2 c:\ibm\IBMHttpServer <ihs_home>
IBM WebSphere Application Server V5.0.2.1 c:\ibm\WebSphere\AppServer <was_home>
IBM WebSphere Portal V5.0.2.1 c:\ibm\WebSphere\PortalServer <wp_home>
IBM Tivoli Access Manager WebSEAL V5.1.0.2 c:\ibm\Tivoli\PDWeb <tws_home>
IBM Tivoli Access Manager V5.1.0.2 c:\ibm\Tivoli\tam <tam_home>
IBM Tivoli Directory Server V5.2 c:\ibm\ldap <tds_home>
IBM Java Runtime Environment (JRE) V1.3.1 c:\ibm\Java131 <jre_home>
IBM GSKit V7.0.1.16 c:\ibm\gsk7 <gsk7_home>

6.1.5 Using VMWare and Ghost
When developing the ITSO runtime implementation procedures on Windows, we
made extensive use of VMWare Workstation V4.5.1 and Symantec Ghost V7.5.
Ghost was used to capture a base Windows 2000 Server image of the base
operating system that could be quickly reloaded to a pristine state. The
advantage of using Ghost is that the software is installed on the native operating
system offers greater performance during testing. The downside is that the ghost
image is tied to the device drivers of the system type the image was created on
and thus is not portable to other system types.
VMWare was used to capture the system state during the installation and
configuration of the nodes. VWMare images can be copied from various system
types since the device drivers are virtualized. The downside is that system
performance is not as good as on a native operating system.
Note: VMWare Workstation V4.5.1 allows for greater than 1 GB of RAM to be

shared among VMWare images. In previous versions, the total usable RAM
was limited to 1 GB regardless of the number of VMWare images. We are big
fans of VMWare.
6.2 Implement the Policy Server node

This section describes how to install and configure the software components on
the Policy Server node.
Note: When installing and configuring the Policy Server node, we referenced
the following product guides and redbooks:
SC32-1338
򐂰 Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339
򐂰 Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360
V4.1, SG24-6077, redbook
SG24-6014, redbook
The high-level tasks to install the Policy Server node are as follows:
1. Windows 2000 Server installation
2. DB2 Universal Database installation
3. IBM GSKit upgrade installation
4. Java Runtime Environment (JRE) V1.3.1 installation
5. Tivoli Directory Server installation
6. Tivoli Directory Server configuration
7. Tivoli Web Administration Tool installation
8. Configure Directory Server for Tivoli Access Manager
9. Tivoli Access Manager installation
10.Tivoli Access Manager configuration
11.Tivoli Access Manager Web Portal Manager installation
12.Tivoli Access Manager V5.1 Base Fixpack 2 installation
6.2.1 Windows 2000 Server installation

This section highlights the key issues addressed when installing Microsoft
Windows 2000 Server, such as using Windows 2000 Service Pack level 4 and
user rights assigned to the administrator user needed later by DB2.
Windows 2000 Service Pack 4

In our example, we installed Windows 2000 Service Pack 4.
Windows 2000 service levels

We installed the latest Windows 2000 service level critical updates on top of
Service Pack 4.
Create admin user and assign user rights

To assign user rights to the administrator ID used by the WebSphere Commerce
DB2 owner during instance creation, do the following:
1. Log on to Windows as an administrator.
2. Create a user ID and add the user to the administrators group (for example,
we created a user called admin). Alternatively, use an existing administrator
user.
3. Click Start → Settings → Control Panel → Administrative Tools → Local
Security Policy.
4. From the Local Security Settings window, select and expand Local Policies
→ User Rights Assignment.
5. Ensure that the administrator user ID (for example, admin) has user right
assignments for the following Windows Local Security Policies needed for
DB2:
– Act as part of the operating.
– Create a token object.

– Increase quotas.
– Log on as a service.
– Replace a process-level token.
6. Log on as the administrator user ID created and rights assigned needed for
DB2.
Verify network configuration

Prior to installing the software components, it is important that you verify that
your network is configured properly. We recommend that you use a static TCP/IP
address and verify that the hostname can be resolved with the name server. For
example, we did the following from a command window:
ping <hostname>
ping <ip_address>
nslookup <hostname>
nslookup <ip_address>
Ensure that the fully qualified hostname is returned if resolved by a domain name
server. Alternatively, you may be using a host file for an environment such as
development (use ping instead of nslookup).
6.2.2 DB2 Universal Database installation

This section describes how to install the IBM DB2 Universal Database V8.1,
Enterprise Server Edition and supporting Fixpack 4a.
This section is organized into the following tasks:

򐂰 Install DB2 UDB V8.1.
򐂰 Install DB2 UDB V8.1 Fixpack 4a.
򐂰 Verify DB2 UDB.
Note: We found that IBM Tivoli Directory Server V5.2, IBM Tivoli Access
Manager for e-business V5.1, and IBM WebSphere Portal Extend for
Multiplatforms V5.0.2 all included different versions of IBM DB2 Universal
Database V8.1. When installing DB2 UDB it is important to understand the
licensing for the product it is included with. Information regarding the IBM
Software licensing can be found at:
http://www.ibm.com/software/sla/sladb.nsf/
There are many possibilities from which DB2 UDB can be installed:
򐂰 Existing DB2 UDB V8.1, Enterprise Server Edition database server
򐂰 New DB2 UDB licence for multi-user access
򐂰 Use on of the various DB2 UDB V8.1 CDs included.
We installed IBM DB2 Universal Database V8.1, Enterprise Server Edition

and Fixpack 4a (8.1.4.428).
Install DB2 UDB V8.1

To install the IBM DB2 V8.1 Enterprise Edition Server, complete the following
steps:
Note: Depending on the DB2 UDB V8.1 CD distribution you are using, the
installation panels may be slightly different than we have described.
1. Insert the DB2 UDB V8.1 Enterprise Server Edition CD.

2. Navigate to the <CD_Root> and run Setup to start the installation.
3. When the DB2 Installer window appears, click Install Products.
4. When the Select the Product to Install window appears, select DB2 UDB
Enterprise Server Edition (default and only option) and then click Next.
5. When the Welcome window for the DB2 Setup Wizard appears, click Next.
6. When the License Agreement window appears, review the agreement and
select I accept the terms in the license agreement and click Next.
7. When the Select the installation type window appears, select Typical and
then click Next.
8. When you see a warning message regarding connection to remote DB2
servers using APPC, click OK.
9. When the Select the Installation Action window appears, check Install DB2
UDB Enterprise Server Edition on this computer and then click Next.

Note: Take note of the Save your settings to response file checkbox. This
can be used to capture your selection options to be used for a future
installation.
10.When the Select the Installation Folder window appears, we entered

c:\ibm\sqllib and then clicked Next.
Note: The DB2 UDB installation with the Typical installation type takes
approximately 376 MB of disk space.
11.When the Set User Information for DB2 Administration Server window
appears, enter the following and then click Next:
– Domain: We left this field blank.
– User name: db2admin (default)
– Password: <password>
– Confirm password: <password>
– Check Use the same username and password for remaining DB2
services (default).
12.When the Setup the Administration Contact List appears, we accepted the
default settings (local) and then clicked Next.
13.When the warning message Notification SMTP server has not been
specified appears, click OK.
14.When the Configure DB2 instances window appears, we accepted the default
(DB2) and then clicked Next.
15.When the Prepare the DB2 tools catalog window appears, select Do not
prepare the DB2 tools catalog on this computer and then click Next.
16.When the Specify a contact for health monitor notification window appears,
select Defer the task after installation is complete, and then click Next.
17.When the Start copying files window appears, review the selected options
and then click Install.
18.When the Setup is Complete window appears, click Finish.
19.When the IBM DB2 First Steps window appears, click Exit First Steps.
Install DB2 UDB V8.1 Fixpack 4a

We installed IBM DB2 UDB V8.1 Fixpack 4a for 32 bit Windows. We chose to
use Fixpack 4a for several reasons. First, both Tivoli Directory Server V5.2 and
WebSphere Portal V5.0.2 officially support DB2 UDB V8.1 Fixpack 4a. Also, we
wanted to use the same version of DB2 Fixpack on all of the nodes.
Note: For more information regarding the contents of the IBM DB2 UDB V8.1
Fixpack 4a, refer the FixpackReadme.txt which can be found at:
http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8fphis
t.d2w/report#WIN-32
To download and install the IBM DB2 UDB V8.1 Fixpack 4a, do the following:
1. The IBM DB2 UDB V8.1 Fixpack 4a can be downloaded at:
http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8fphist.
d2w/report#WIN-32
2. We downloaded the FP4a_WR21338_ESE.exe, which is the fixpack 4a for
the IBM DB2 Universal Database V8.1, Enterprise Server Edition.
3. Stop all DB2 services in the Windows services.
Note: If you have trouble stopping any of the DB2 services, you can
proceed with the fixpack installation. When the DB2 Setup Wizard
launches for the fixpack, it will warn that certain processes are locking DB2
and will ask you if you want to shut them down. You can click Yes and the
Wizard will shut down the processes for you.
4. Install the IBM DB2 UDB V8.1 Fixpack 4a. We accepted the default
installation options.
5. We recommend that you restart your system after installing the fixpack to
ensure that all fixes are applied and active in memory.
6. The internal DB2 level is 8.1.4.428 after the installation of Fixpack 4a. In our
example, we do not have any existing databases that need special attention
(rebind DB2 utilities).
After the system has restarted, open a DB2 command window (or Windows
command window) and enter the following command:
db2level
It should return 8.1.4.428 after Fixpack 4a has been installed.

Note: Rebind DB2 utilities to existing databases.
If you have created databases before you installed the fixpack 4a, you will
need to rebind the DB2 utilities to the databases. This step is necessary for
the fixes to become effective on existing databases. The binding procedure
needs to be performed only once per database. Note, this is not required for
any database created after the fixpack is installed. We have summarized the
rebind procedure found in the FixpackReadme.txt.
To rebind existing DB2 UDB databases after installing Fixpack 4a enter the
following commands from a DB2 command window for each database:
db2 terminate
db2 CONNECT TO <dbname>
db2 BIND <DB2_home>\BND\@db2ubind.lst GRANT PUBLIC
db2 BIND <DB2_home>\BND\@db2cli.lst GRANT PUBLIC
db2 terminate
– Where <dbname> represents the name of a database to which the

utilities should be bound.
– Where <DB2_home> represents the directory where you have installed
DB2. The db2ubind.lst and db2cli.lst contains lists of required bind files
used by IBM DB2 UDB V8.1.
Verify DB2 UDB

After you install DB2 UDB V8.1 and fixpack, and have restarted your system, we
recommend that you verify that DB2 UDB is working properly.
Note: The DB2 First Steps application (installed by default if Typical

installation type is selected) can be used to create a sample database.
6.2.3 IBM GSKit upgrade installation

This section describes how to download and install IBM GSKit V7.0.1.16. The
GSKit is used to manage keystores and certificates. The GSKit includes the IBM
Key Management utility and libraries accessible to applications to create and
manage certificates.
There are two reasons that we need the new GSKit for the ITSO example
runtime environment. First, the GSKit V7.0.1.9 installed with the Tivoli Directory
Server V5.2 on the Policy Server node includes root certificates that have
expired. For this reason, users will not be able to create a new keystore using the
iKeyman utility. Second, the IBM GSKit V7.0.1.16 is a prerequisite for the Tivoli
Access Manager V5.1 Base Fixpack 2, which we install in 6.2.12, “Tivoli Access
Manager V5.1 Base Fixpack 2 installation” on page 216. In addition, the IBM
GSKit V7.0.1.16 addresses a potential denial-of-service attack vulnerability.
In our example, the Policy Server node includes three products that include a
version of the IBM GSKit, as seen in Table 6-6. In our example, we only need to
upgrade the IBM GSKit V7.0.1.9 to V7.0.1.16.
Note: The ITSO procedure installs the IBM GSKit V7.0.1.16 to be used by the
Tivoli products.
Table 6-6 GSKit versions included with IBM software

IBM software version IBM GSKit version
Tivoli Directory Server V5.2 7.0.1.9
Tivoli Access Manager V5.1 7.0.1.9
WebSphere Application Server V5.0.2 5.0.5.70

Note: GSKit is included with the IBM
HTTP Server V1.3.26 included on the
WebSphere Application Server CD.
Determine GSKit version installed

This section describes how to determine the version of GSKit an application is
configured to use in the Windows registry. If you are following the order of
installing components documented in this chapter, this section is not necessary,
since we will install the new GSKit prior to installing components that use it.
Note: The GSKit version can be obtained by using the gsk7ver.exe command
or by retrieving the version from the Windows registry. We chose to use the
Windows registry method, since we also needed the REGAPPS value in
addition to the version.
If you have not installed Tivoli Directory Server or other software containing the
IBM GSKit, you can skip this section. To determine the level of the GSKit
installed, do the following:
1. Start the Windows registry editor (regedit.exe) by clicking Start → Run and
entering regedit in the Open field, and then clicking OK.
2. Select and expand HKEY_LOCAL_MACHINE → SOFTWARE → IBM.
3. In our example, you will see both the GSK5 and GSK7 registry entries.

4. Select GSK7 → CurrentVersion. Record the data value for the version
name.
5. Select REGAPPS under the CurrentVersion. This will list the name of the
application using the GSKit. Record the name of the application using this
version of the GSKit (for example, LDAP).
Uninstall old GSKit

If following the ITSO procedure this section is not required.
Prior to installing the new IBM GSKit V7.0.1.16, if a GSKit already has been
installed, you must manually uninstall the existing IBM GSKit V7.0.1.9 as follows:
1. Ensure the IBM Tivoli Directory Server V5.2 Windows service has been
stopped, as well as other services that may be using the GSKit.
2. Open a command window and navigate to the c:\winnt directory.
3. Run the following command to uninstall the GSKit:
gsk7bui LDAP
Where LDAP is the name of the application using the GSKit recorded.
4. Verify that the GSK7 Windows registry has been removed.
5. Verify that the GSK7 directory has been removed (for example, C:\Program
Files\IBM\GSK7).
Note: If files still exist, such as DLLs, manually delete the C:\Program
Files\IBM\GSK7 directory after the services that locked the files have been
stopped.
Note: If you have previously installed applications that use the old GSKit
V7.0.1.9, they may have updated the system path to include the GSKit
installation path. If you decided to change the default GSKit installation path,
you may need to manually update the system path to include the correct
GSKit installation path.
For example, our procedure is now in an order that this problem will not be an
issue, but when we initially set up our environment we had already install the
Tivoli Access Manager Policy Server and Authorization Server. These
Windows services are started by the Access Manager Auto-Start Service,
which looks for the GSKit in the system path. If the GSKit path is not correct,
the services will not start. After updating the system path in the Windows
environment, you will need to restart your system.
Install GSKit V7.0.1.16
To download and install the IBM GSKit V7.0.1.16, do the following:
1. The IBM GSKit V7.0.1.16 can be obtained by one of the following methods:
– Request the GSKit V7.0.1.16 from IBM support at:
http://techsupport.services.ibm.com/guides/tivoli_contacts.html
or
– Download the IBM HTTP Server V1.3.28, which includes IBM GSKit
V7.0.1.16, at:
http://www-1.ibm.com/support/docview.wss?rs=177&context=SSEQTJ&uid=swg24
006718
Note: From the URL listed, you will have to log in as a registered user (or
register first). Once you navigate to the download page by platforms you
will see a listing of many fixes.
We downloaded the WINDOWSPQ86671IHS1.3.28.zip (PQ86671) for IBM

HTTP Server V1.3.28 to the c:\temp directory and unpacked the zip file.
2. Open a command window and navigate to the directory in which you have
unpacked the WINDOWSPQ86671IHS1.3.28.zip file.
3. Enter the following at the command line to extract the GSKit:
gsk7bas c:\temp
Where c:\temp is the directory to which to extract the GSKit installation files.
4. From the command window, navigate to the directory where you have
extracted the GSKit installation files (for example, c:\temp).
5. Run the GSKit installer as follows:
setup <application_name>
Where <application_name> is the name of the application using GSKit
V7.0.1.16. For example:
– Policy Server node application_name: LDAP
– Reverse Proxy node application name: policydirector
6. When the Welcome window appears, click Next.
7. When the Choose Destination Location window appears, we entered
c:\ibm\gsk7 for the destination folder from the Browse button. Click Next to
proceed.
8. When the setup is complete, click Finish.

6.2.4 Java Runtime Environment (JRE) V1.3.1 installation
In order to use the IBM Key Management Utility (iKeyman) included with the
GSKit, the Java Runtime Environment (JRE) V1.3.1 is required to be installed.
To install the IBM Java Runtime Environment V1.3.1, do the following:

1. Insert the IBM Tivoli Access Manager V5.1 Web Administration Tool CD.
2. Navigate to the <CD_Root>\Windows\JRE directory and run Install.exe to
start the JRE installer.
3. When the Choose Setup Language window appears, select the language for
the installation process (for example, English) and click OK.
5. When the License Agreement window appears, if in agreement click Yes to
continue.
6. When the Choose Destination Location window appears, click Browse to
change the installation directory. We entered c:\ibm\Java131 in the Path and
then clicked OK. When prompted to create the directory click Yes. Click Next
to continue.
7. When the Select Components window appears, check Java 2 Runtime
Environment and then click Next.
8. When prompted with the message Install this Java Runtime Environment
as the System JVM?, click Yes.
9. When the Start Copying Files Summary window appears, click Next to begin
copying files.
10.When the Setup Complete window appears, click Finish.
11.To verify that the JRE is installed and available as the System JVM, do the
following:
a. Verify that the java.exe is found in the c:\winnt\system32 directory, which
is copied to this directory as a result of clicking Yes in step eight.
b. Open a command window and enter the following:
java -version
It should return the following message:
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1)
Classic VM (build 1.3.1, J2RE 1.3.1 IBM Windows 32 build cn131-20021102
(JIT enabled: jitc))
6.2.5 Tivoli Directory Server installation
This section describes how to install the Tivoli Directory Server V5.2 on the
Policy Server node. WebSphere Portal V5.0.2 includes Tivoli Directory Server
V5.1, and Tivoli Access Manager V5.1 includes Tivoli Directory Server V5.2. We
chose to use Tivoli Directory Server V5.2 to verify the configuration with the
newer version and avoid GSKit issues with the older level.
Tivoli Directory Server V5.2 includes WebSphere Application Server Express

and Web Administration Tool used to manage the directory server. The Tivoli
Access Manager V5.1 includes the Tivoli Directory Server Web Administration
Tool, and the Tivoli Access Manager Web Portal Manager, which can both be
installed to the WebSphere Application Server provided with Tivoli Access
Manager. We choose to install the Web-based administration tools on a shared
WebSphere Application Server (not Express), since both the Tivoli Directory
Server and Tivoli Access Manager components are installed on the same node
for our scenario.
The high-level steps to install and configure the Tivoli Directory Server are as
follows:
򐂰 Create DB2 database owner
򐂰 Install Tivoli Directory Server
Create DB2 database owner

In our example, we granted the admin user the proper right assignments for a
DB2 user (see “Create admin user and assign user rights” on page 183). No
other action is needed.
Install Tivoli Directory Server

To install the Tivoli Directory Server V5.2 on the Policy Server node, do the
following:
1. Insert the Tivoli Directory Server V5.2 CD.
2. Navigate to the <CD_Root>\ismp folder, and run Setup.exe to start the install.
3. Select the installer language (for example, English), which is separate from
the Tivoli Directory Server language. Click OK.
4. When the Welcome page appears, click Next.
5. When the License Agreement page appears, review the terms and if in
agreement select I accepts the terms in the license agreement and then
click Next.
6. A page will display existing components. In our example, we have
preinstalled the IBM GSKit and IBM DB2 UDB. Click Next.

7. We installed Tivoli Directory Server in the c:\ibm\ldap directory.
8. Select the Tivoli Directory Server language (for example, English) and click
Next.
9. When the Select Features to install window appears, we selected the
following options, as seen in Figure 6-2 on page 194, and then clicked Next.
– Check Client SDK 5.2.
– Uncheck Web Administration Tool.
We will install the Web Administration Tool on a shared WebSphere
Application Server V5.0.2 server in a later step.
– Check Server 5.2.
– Uncheck IBM WebSphere Application Server - Express 5.0.
We will use a shared WebSphere Application Server instead of Express.
– Uncheck DB2 V8.1.
A newer level of DB2 UDB has already been installed.
– Uncheck GSKit.
A new level of the GSKit has already been installed.
Figure 6-2 Tivoli Directory Server - Select features
10.When the Installation Summary page appears, review the selections and click
Next to begin installing files.
11.When the installation completes, review the readme files for the client and
server and click Next.
12.When prompted, select Yes, restart my computer and click Next. Click
Finish.
6.2.6 Tivoli Directory Server configuration

After installing the Tivoli Directory Server V5.2 you will need to configure the
directory server.
Start the Tivoli Directory Server Configuration Tool

During the first restart of your system after the Tivoli Directory Server installation,
the Tivoli Directory Server - Configuration Tool will be launched automatically.
Alternatively, start the Directory Configuration tool by clicking Start → Programs

→ IBM Tivoli Directory Server V5.2 → Directory Configuration.
Set the administrator DN and password

To set the administrator distinguished name (DN) and password using the Tivoli
Directory Server Configuration Tool, do the following:
1. Select Administrator DN/password under Choose a task.
2. Enter the Administrator DN and password and click OK.
– Administrator DN: cn=root
– Password: <your_password>
3. When prompted with the Administrator DN and password successfully
updated message, click OK.
Create and configure the directory database

To create and configure the Tivoli Directory Server directory database from the
Tivoli Directory Server - Configuration Tool, do the following:
1. Select Configure database under Choose a task.
2. Select Create a new database and then click Next.
3. When the Configure database - user ID page appears, enter the user ID and
password created in “Create DB2 database owner” on page 193 (for example,
admin) and then click Next.
4. When the Configure database - database name page appears, enter the
database name to be created (for example, ldapdb) and click Next.
5. When the Configure database - database code page selection appears,
select Create a universal DB2 database (UTF-8/UCS-2) and click Next.
6. When the Configure database - database location appears, select the drive
(for example C) and click Next.

7. When the Configuration Summary page appears, review the selections and
click Finish.
8. During the configuration, the configuration status will be displayed. Notice that
a DB2 instance is created with the name of the user designated as the DB2
owner (for example, admin). When complete, click Close.
6.2.7 Tivoli Web Administration Tool installation

Both the Tivoli Directory Server V5.2 and Tivoli Access Manager V5.1 include the
Web Administration Tool used to manage the Tivoli Directory Server(s). The
Web Administration Tool found in both packages appears to be the same. There
are, however, a couple of key differences between the two in the way they
configured with packaged software components that we would like to point out.
򐂰 Web Administration Tool packaged with Tivoli Directory Server V5.2
The Tivoli Directory Server V5.2 Web Administration Tool is bundled with
WebSphere Application Server Express V5.0.2, which does not provide the
ability to enable WebSphere security. The Tivoli Directory Server V5.2 Web
Administration Tool can be installed as part of the Tivoli Directory Server
installation. Note, it is possible to install the Web Administration Tool on
WebSphere Application Server V5.0.2 (not included with Tivoli Directory
Server V5.2).
򐂰 Web Administration Tool packaged with Tivoli Access Manager V5.1
The Web Administration Tool packaged with Tivoli Access Manager V5.1 is
bundled with WebSphere Application Server V5.0.2. When the Web
Administration Tool is installed to the WebSphere Application Server it installs
the Web Administration Tool war file (IDSWebApp.war) and the Tivoli Web
Portal Manager war file ( .war). After the installation of the war files, they must
be deployed to the WebSphere Application Server application server (for
example, server1) manually. The Web Administration Tool is used to manage
the Tivoli Directory Server, and the Web Portal Manager is used to manage
the Tivoli Access Manager (alternative: pdadmin command line interface).
For the ITSO working example, we chose to install the Web Administration Tool
provided with Tivoli Access Manager V5.1 on WebSphere Application Server
V5.0.2, which will allow us to later configure WebSphere Application Server
security.
The high-level steps to install and configure the Web Administration Tool are as
follows:
򐂰 WebSphere Application Server installation
򐂰 Tivoli Directory Server Web Administration Tool installation
򐂰 Web Administration Tool configuration
WebSphere Application Server installation
This section describes how to install WebSphere Application Server V5.0 and
Fixpack 2 (V5.0.2) on the Policy Server node as a prerequisite to the Tivoli
Access Manager V5.1 Web Administration Tool.
Install WebSphere Application Server V5.0

To install the WebSphere Application Server V5.0, do the following:
1. Insert the Tivoli Access Manager V5.1 - Web Administration Tool CD.
2. Navigate to the <CD_Root>\windows\websphere\nt directory and run
Install.exe to start the WebSphere Application Server installer.
3. When the Select the desired language to be used for the installation wizard
appears, select the desired language (for example, English) and click OK.
4. When the Welcome page appears, click Next.
5. When the License Agreement page appears, review the terms and select I
accepts the terms in the license agreement, and then click Next.
6. When the Setup Type window appears, select Custom and click Next.
7. When the Features Selection window appears, we selected the features
displayed in Figure 6-3 on page 198 and then clicked Next.

Figure 6-3 WebSphere Application Server - Selected features
8. When the Features Installation directories window appears, we entered the

following and then clicked Next:
– WebSphere Application Server: c:\ibm\WebSphere\AppServer
– IBM HTTP Server: c:\ibm\IBMHttpServer
9. When the Node name and Host name window appears, we entered the
– Node name: tamwin1
– Host name or IP Address: tamwin1.itso.ral.ibm.com
10.When the Windows Services window appears, we entered the following and
then clicked Next:
– Deselect Run WebSphere Application Server as a service.
– Select Run IBM HTTP Server as a service.
– User ID: admin
11.When the Installation Summary window appears, review your selections and
then click Next to begin copying files.
12.When the Register window appears, take the appropriate action.
13.When the First Steps window appears, click Exit.
14.Click Finish on the Installation Wizard page.
Install WebSphere Application Server V5 Fixpack 2 (V5.0.2)

The IBM WebSphere Application Server V5 Fixpack 2 (V5.0.2) is a prerequisite
to the Tivoli Directory Server V5.2 Web Administration Tool included with Tivoli
Access Manager V5.1. WebSphere Application Server Fixpack 2 is included on
the Tivoli Access Manager V5.1 - WebSphere Fixpack CD or can be downloaded
from the IBM WebSphere Application Server support site.
To install the IBM WebSphere Application Server V5 Fixpack 2, do the following:

1. Ensure that you have stopped all WebSphere Application Server, application
servers and nodes.
2. Ensure that you have stopped the IBM HTTP Server and IBM HTTP
Administration Windows service (WebSphere plug-in fixes).
Note: The Fixpack will attempt to update the IBM HTTP Server and will not
be able to update the server if it is started.
3. Insert the Tivoli Access Manager V5.1 - WebSphere Fixpack CD.

4. Open a command window and navigate to the
<CD_Root>\windows\websphere_fixpack directory.
5. Copy WebSphere Application Server V5 Fixpack 2 to a temporary directory
on the target system (for example, c:\temp\was5.fp2). Note that the
WebSphere Update Installer Wizard needs write access.

6. Start the WebSphere Installation Update Wizard by running
updateWizard.bat, found in the temporary directory (for example,
c:\temp\was5.fp2).
7. When the WebSphere Update Installer language window appears, select the
appropriate language for the wizard (for example, English) and then click OK.
9. The WebSphere Update Installer should detect your current WebSphere
Application Server version and installation directory (for example,
c:\ibm\WebSphere\AppServer). Click Next.
10.Select Install fix packs and then click Next.
11.Enter the directory where you have copied the fixpack. For example, we
entered c:\temp\was5.fp2\fixpacks in the Fix pack directory text field, and
then clicked Next.
12.Select the was50_fp2_win fixpack (default) and then click Next.
13.You will be prompted for the directories for the IBM HTTP Server and the
WebSphere Application Server Embedded Messaging (not installed). We
entered the following and then clicked Next:
– Check IBM HTTP Server.
– IBM HTTP Server installation directory: c:\ibm\IBMHttpServer
– Uncheck Embedded Messaging (not installed).
14.Review the fixpack settings and then click Next to begin the fixpack
installation of files.
15.When the WebSphere Application Server V5 Fixpack 2 installation is
complete, click Finish.
Verify WebSphere Application Server V5.0.2

To verify the functionality of the WebSphere Application Server V5.0.2 after
installation, do the following:
1. Verify the WebSphere Application Server installation by clicking Start →
Programs → IBM WebSphere → First Steps.
2. From First Steps, click Verify Installation.
If the server is not started, it will start the server and perform some tests. You
will see console output with the status of each test run—passed.
Note: Alternatively, you can start the Install Verification by opening a

command prompt, navigating to the <was_home>\bin directory, and
running ivt.bat.
3. After completing the Verify Installation, click Exit from the First Steps page.
4. Ensure that the IBM HTTP Server (WebSphere plug-in) is started.
5. Ensure that the server1 application server is started. If not, start the server as
follows:
cd \ibm\WebSphere\AppServer\bin
startServer server1
Note: We have provided two methods to verify that server1 is started.

򐂰 Check server status (serverStatus)
To check the status of the server enter the following command in a
command window:
c:\ibm\WebSphere\AppServer\bin\serverStatus -all
The status of server1 should state that it is running.
򐂰 Review the startServer.log
Review the status of the server startup in the startServer.log. For
example, we used the gnu utility to view the logs:
tail -f c:\ibm\WebSphere\AppServer\logs\server1\startServer.log
You should see the following message:
Server server1 open for e-business
The server1 directory will not get created until the first time the
application server is started.
6. Start the WebSphere Application Server Administration Console by entering

the following URL in a Web browser:
http://<was_hostname>:9090/admin
7. Log on to the WebSphere Administration Console (for example, admin).
8. When done verifying the WebSphere Administration Console, click Logout to
close the Web browser.
9. Stop the server1 application server as follows:
stopServer.bat server1
Tivoli Directory Server Web Administration Tool installation

The installation of the Tivoli Directory Server Web Administration Tool packaged
with Tivoli Access Manager V5.1 (IBM Tivoli Access Manager Web
Administration Interfaces for Windows 2000 CD) first installs the war file for the

Web Administration Tool. After the war file is installed, the war file must be
manually deployed to IBM WebSphere Application Server V5.0.2.
Install Web Administration Tool

To install the Tivoli Web Administration Tool packaged with Tivoli Access
Manager V5.1 on the Policy Server node, do the following:
1. Insert the IBM Tivoli Access Manager Web Administration Interfaces for
Windows 2000 CD.
2. Navigate to the <CD_Root>\windows\Directory folder and run Setup.exe to
start the installation.
3. When the Install Shield language window appears, select the appropriate
language (for example, English), and then click OK.
4. When the Installing Current Version window appears, as seen in Figure 6-4,
click No.
Figure 6-4 Web Administration Tool installation - Current version

6. When Software License Agreement page appears, review the agreement and
then select I accept the terms in the license agreement. Click Next.
7. The installer will detect if application components have been installed. Review
and click Next.
8. Select the language for the Tivoli Directory Server (for example, English) and
click Next.
9. When the Select Features to Install page appears, we checked the following
and then clicked Next:
Note: Only check Web Administration Tool.
– Uncheck Client SDK 5.2.

– Check Web Administration Tool 5.2.
– Uncheck Server 5.2.
– Uncheck IBM WebSphere Application Server - Express 5.0.2.
– Uncheck DB2 V8.1.
– Uncheck GSKit.
10.When the Summary page appears, click Next to begin the installation.
11.When the Review Readme file appears, click Next.
12.When the installation is complete, you will be prompted to restart the system.
This is not necessary since we just installed the Web Administration Tool.
Select No, I will start my computer at a later time. Note, it is not necessary
in this case to restart, since the installer only copied the Web Administration
Tool war file (IDSWebApp.war). Click Next.
13.Click Finish.
Deploy Web Administration Tool on WebSphere Application Server

To deploy the Web Administration Tool on the WebSphere Application Server
server1, do the following:
1. Ensure that the WebSphere Application Server - server1 is started. If not,
start the server1 as follows:
c:\ibm\WebSphere\AppServer\bin\startServer server1
http://<hostname>:9090/admin
3. Log on to the Administration Console (for example, admin).
4. Click Applications → Install New Application in the console navigation
tree.
5. When the Preparing for application installation page appears, do the following
and then click Next:
– Path: Select the Local path radio button.
– Local Path: c:\ibm\ldap\idstools\IDSWebApp.war
This is the full path of the Web Administration Tool application standalone
IDSWebApp.war file.
Note: The file can either be on the client machine (the machine that
runs the Web browser) or on the server machine (the machine to which
the client is connected).
– Context Root: /IDSWebApp

6. When the Generate bindings page appears, we accepted the default settings
and clicked Next.

7. When the Step 1: Provide options to perform the installation page appears,
we accepted the default settings and clicked Next:
– Application Name: IDSWebApp_war (default)
8. When the Step 2: Map virtual hosts for Web modules page appears, we
entered the following and then clicked Next:
– Virtual Host: Select default_host (default).
– Web Module: Check IBM Tivoli Directory Server Web Application v2.0.
9. When the Step 3: Map modules to application servers page appears, we
accepted the default and then clicked Next.
10.When the Step 4: Summary Review installation options page appears, click
Finish.
11.When the configuration update is complete, click the Save to Master
Configuration link.
12.When the Save to Master Configuration page appears, click Save.
13.Start the Tivoli Directory Server - Web Administration Tool by clicking
Applications → Enterprise Applications.
14.From the Enterprise Application page, check IDSWebApp_war and then click
Start.
15.Click Logout.
Web Administration Tool configuration

This section describes how to configure the Tivoli Directory Server - Web
Administration Tool.
Define the directory server node to the Web Administration Tool

To define the directory server with the Web Administration tool, do the following:
1. Ensure that the WebSphere Application Server server1 is started.
2. Access the Web Administration Tool from a Web browser:
http://localhost:9080/IDSWebApp/IDSjsp/Login.jsp
3. From the Web Administration Tool, enter the following and then click Login:
– LDAP Hostname: Select Console Admin from the drop-down list.
– Username: superadmin (default)
– Password: secret (default)
4. Modify the default Console Administration user ID and password.
a. Select Console Administration → Change console administration
login.
b. When the Change Console administrator logon appears, enter the
following and click OK.
• Console administrator login: webadmin
We created the administrator webadmin, but this could be any name
you desire.
• Current password: <password> (default is secret)
c. Select Change console administrator password. Enter the current and
new password. Click OK.
5. Add the Directory Server node.
a. Click Console administration → Manage console servers.
b. Click Add.
c. Enter the Directory Server hostname and change the port numbers if not
using defaults (for example, tamwin1.itso.ral.ibm.com), and click OK.
• Port: 389
• Administration port: 3538
• Uncheck SSL enabled (default).
We will examine SSL enabling the connection to adminstration tools in
Chapter 11, “Security hardening” on page 471.
You should see the new server listed after adding it.
d. Click Logout from the Web Administration Tool.
Verify administration to directory server

Now that the Web Administration Tool is configured for the directory server, we
recommend that you verify it is working properly by connecting to the directory
server.
1. Ensure the Tivoli Directory Server V5.2 Windows service is started.
2. Access the Tivoli Directory Server Web Administration Tool from a Web
browser:
http://localhost:9080/IDSWebApp/IDSjsp/Login.jsp
3. From the Web Administration Tool, do the following and then click Login:
– Select the newly created server (for example, tamwin1.itso.ral.ibm.com)
from the drop-down list on the Login page.
– Username: cn=root
4. To start the Tivoli Directory Server, click Server administration →
Start/stop/restart server.
5. Click Start (do not Check Start/restart in configuration only mode).

You should see the status message Server started.
Change password encryption method

After the installation it is recommend that you change the password encryption
method from the default imask to SHA or crypt from the Web Administration Tool,
as defined in the Administration Guide, IBM Tivoli Directory Server V5.2,
SC32-1339, product guide. The primary reason is that imask is a two way
encoding format, and both SHA and crypt are one way.
We configured the password encryption as follows:

1. From the Web Administration Tool select Server administration → Manage
security properties.
2. From the Manage security properties page, click Password policy.
3. Select SHA from the Password encryption drop-down and then click OK at
the bottom of the page.
6.2.8 Configure Directory Server for Tivoli Access Manager

This section describes the configuration required between the Tivoli Directory
Server and Tivoli Access Manager.
Prepare schema definitions

Tivoli Access Manager schema definitions are added automatically during
installation of IBM Tivoli Directory Server V5.2.
Note: If you are using IBM Tivoli Directory Server V4.1 or V5.1 refer to the
Base Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1362, for
additional steps for preparing the schema.
Create a suffix for Tivoli Access Manager meta data

To create a suffix from the Tivoli Directory Server - Web Administration Tool for
the Tivoli Access Manager meta data, do the following:
1. From the Tivoli Directory Server - Web Administration Tool, select Server
administration → Manage server properties.
2. On the Manage server properties page, click Suffixes.
3. Enter Suffix DN secAuthority=Default and click Add.
4. Click OK at the bottom of the page to save the settings.
Attention: The first time we configured the runtime environment, we later
discovered while troubleshooting that the suffix was not saved. On our
system, the display resolution was set to 1024x768. The OK button to save
the settings was not visible unless you scrolled down the page. We have
added this note to click OK to save to alert others of this pitfall.
5. Click Logout, and close the Tivoli Directory Server - Web Administration Tool.
6.2.9 Tivoli Access Manager installation

This section describes how to install and configure the Tivoli Access Manager
V5.1 on the Policy Server node for the ITSO example.
When installing Tivoli Access Manager V5.1, you can set up the system using
one of the following installation methods:
򐂰 Installation wizard
This method is very useful if you are not experienced with using Tivoli Access
Manager and want to quickly implement a base configuration.
򐂰 Installation using native installation utilities by platform
We performed the installation using the native installation utilities. First, we
wanted to have greater control of how and where the components are
installed. Also, we wanted to have a better understanding of what was being
configured to build critical knowledge needed for debugging.
To install the IBM Tivoli Access Manager V5.1 Policy Server, do the following:
1. Ensure that the Tivoli Directory Server is started.
2. Ensure that the proper GSKit is installed.
The GSKit V7.0.1.9 included with the Tivoli Directory Server V5.2 contains
certificates that have expired. To address this issue we have downloaded and
installed a newer GSKit V7.1.0.16 in 6.2.3, “IBM GSKit upgrade installation”
on page 188.
3. Ensure that the Tivoli Directory Client SDK is installed.
In our example, the Tivoli Directory Client SDK was installed with the Tivoli
Directory Server V5.2.
4. Insert the Tivoli Access Manager Base for Windows NT®, Windows XP,
Windows 2000 and Windows 2003 CD.
5. Navigate to the <CD_Root>\windows\PolicyDirector\Disk Images\Disk1 folder
and run Setup.exe to start the installer.

6. When the Choose Setup Language window appears, select the desired
language (for example, English) and click OK.
8. When the License Agreement window appears, review the terms and, if in
agreement, click Yes.
9. When the Select Packages window appears, we checked the following
packages and then clicked Next:
– Check Access Manager Runtime.
– Check Access Manager Policy Server.
– Check Access Manager Authorization Server.
10.When the Choose Destination Directory window appears, we entered the
– Install destination directory: c:\ibm\Tivoli\tam
11.When the Summary/Start Copying Files window appears, review the
selections and then click Next.
12.When the installation is complete, select Yes, I will restart my computer
now and then click OK.
Note: Manually stopping the server prior to system restart (optional).
On occasion, if you do not stop the WebSphere Application Server from the
command line by entering the following, you may not be able to start the
WebSphere Application Server after the restart:
c:/ibm/WebSphere/AppServer/bin/stopServer server1
To resolve this issue, delete the file server.pid found in the

<was_home>/logs/server1 directory, and then restart the server.
6.2.10 Tivoli Access Manager configuration

This section describes how to configure the following Tivoli Access Manager
components as follows:
򐂰 Configure Access Manager Runtime.
򐂰 Configure Access Manager Policy Server.
򐂰 Configure Access Manager Authorization Server.
򐂰 Update Windows registry for Access Manager services.
򐂰 Tivoli Access Manager Windows services startup.
Configure Access Manager Runtime

To configure the Tivoli Access Manager Runtime, do the following:
1. Ensure that the Tivoli Directory Server is started.
2. Start the Access Manager Configuration by clicking Start → Programs →
IBM Tivoli Access Manager → Configuration.
Alternatively, open a command window and enter pdconfig, which is in the
environment after the system restart.
3. From the Access Manager Configuration, select Access Manager Runtime
and click Configure.
4. Select LDAP and click Next.
5. When the LDAP Server Information page appears, we entered the following
and then clicked Next:
– LDAP host name: tamwin1.itso.ral.ibm.com
– LDAP port number: 389
6. When the SSL with the registry server window appears, we selected No next
to enable SSL with the registry server and then clicked Next.
Note: We will configure SSL in Chapter 11, “Security hardening” on

page 471.
7. When the Logging Information page appears, we entered the following and
then clicked Next:
– Check Enable Tivoli Common Directory for logging.
– Log directory: c:\ibm\Tivoli\common
8. When the Configuration Summary page appears, review the settings and
click Finish.
The Access Manager Configuration tool should display configured status Yes for
Access Manager Runtime.
Configure Access Manager Policy Server

To configure the Tivoli Access Manager Policy Server, do the following:
1. From the Access Manager Configuration, select Access Manager Policy
Server and click Configure.
2. When the LDAP Administration ID page appears, we entered the following
and then clicked OK.
– LDAP administrator name: cn=root
– LDAP administrator password: <password>
3. When the Tivoli Access Manager administrator ID page appears, we entered
the following and then clicked OK:

– ID: sec_master (greyed out)
– Confirm password: <password>
4. When the Access Manager Policy Server SSL parameters page appears, we
accepted the default at this time and then clicked OK:
– SSL port: 7135
– SSL certificate lifecycle: 365
– SSL connection timeout: 7200
5. After the configuration is complete, you should see a message displayed like
Figure 6-5. Click OK.
Figure 6-5 Tivoli Access Manager Policy Server configuration success message
Tip: The first time we configured our environment, we received an error

dialog. We then reviewed the c:\ibm\Tivoli\tam\log\msg__config.log. We found
the error:
Error code 0x20 was received from the LDAP server. Error text: No such
object.
We later discovered that the suffix for Tivoli Access Manager meta data
(secAuthority=Default) was not saved. We have included a note in the section
where the suffix is added to ensure that you scroll down the page and click OK
to save the suffix. After successfully adding the suffix, we reran the Policy
Server configuration successfully.
The Access Manager Configuration tool should display configured status Yes for
Access Manager Policy Server.
Configure Access Manager Authorization Server

To configure the Tivoli Access Manager Authorization Server, do the following:
1. From the Access Manager Configuration, select Access Manager
Authorization Server and click Configure.
2. When the Domain Information window appears, enter Default in the Domain
field and click Next.
3. When the Policy Server Information window appears, we entered the
– Policy server hostname: tamwin1.itso.ral.ibm.com
– Policy server port: 7135
4. When the Administrator ID for domain Default window appears, we entered
sec_master, <password> and then clicked Next.
5. When the Authorization Server window appears, we entered the following and
then clicked OK:
– Local host name: tamwin1.itso.ral.ibm.com
– Administration request port: 7137
– Authorization request port: 7136
The Access Manager Configuration tool should display configured status Yes
for Access Manager Authorization Server.
6. Click Close to exit the Access Manager Configuration utility.
Update Windows registry for Access Manager services

While writing this redbook, we found that the Tivoli Access Manager V5.1,
Access Manager Policy Server Windows services did not start properly. We
discovered that the Windows registry for the Access Manager Policy Server
Windows service was not configured correctly by the Tivoli Access Manager
V5.1 installation program.
Note: If you install Tivoli Access Manager V5.1 to a path other than the default
installation path, you will see a Windows service startup error, as in
Figure 6-6.
Troubleshoot Windows service startup problem

To determine if you have the problem, do the following:
1. Stop the Access Manager Policy Server Windows service.
2. Start the Access Manager Policy Server Windows service.
3. If you see the error message seen in Figure 6-6, you will need to proceed to
“Update Windows registry” on page 212.

Figure 6-6 Access Manager Policy Server Windows service startup failure
Update Windows registry

To work around this configuration issue, we did the following:
1. Start the Registry Editor (regedit.exe).
2. To update the Access Manager Policy Server Windows service definition in
the registry, do the following:
a. Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IVMgr.
b. Double-click ImagePath.
c. From the Edit String window, we entered the following and then clicked
OK:
• Value data: c:\ibm\Tivoli\tam\bin\pdmgrd.exe
Note: We removed the li parameter, which we believe to be characters

inserted by the Tivoli Access Manager installer that cause this problem.
3. To update the Access Manager Authorization Server Windows service

definition in the registry, do the following:
a. Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IVACId.
b. Double-click ImagePath.
c. From the Edit String window, we entered the following and then clicked
OK:
• Value data: c:\ibm\Tivoli\TAM\bin\pdacld.exe
Note: We removed the li parameter, which we believe to be garbage

characters inserted by the Tivoli Access Manager installer.
4. Close the Registry Editor.
Tivoli Access Manager Windows services startup
In our example, we have installed Tivoli Directory Server and the Tivoli Access
Manager components on the same node (Policy Server node). The Tivoli Access
Manager - Access Manager Auto-Start Service is set to automatic startup by
default. The purpose of the Access Manager Auto-Start Service is to start other
Tivoli Access Manager services automatically, such as the Policy Server and
Authorization Server.
The Tivoli Access Manager services startup is dependent on the Tivoli Directory
Server being started. Even after attempting to make the Access Manager
Auto-Start Service dependent on the Tivoli Directory Server service startup, we
found that it timed-out. To resolve this issue, we set the Access Manager
Auto-Start Service to manual, and manually started the service after the Tivoli
Directory Server service had completed startup.
6.2.11 Tivoli Access Manager Web Portal Manager installation

This section describes how to install the Tivoli Access Manager V5.1 Web Portal
Manager. Like the Web Administration Tool, the Web Portal Manager war file is
first installed and then must be manually deployed to the WebSphere Application
Server V5.0.2.
The Tivoli Access Manager Web Portal Manager is a graphical Web-based

application used to manage Tivoli Access Manager security policies in a secure
domain. The Web-based Web Portal Manager is an alternative to the pdadmin
command line interface. It allows administrators to remotely access and
administer Tivoli Access Manager security policies.
We chose the native method of installation, since we already have a WebSphere

Application Server installed on the Policy Server node on which we can install
the Access Manager Web Portal Manager. Also, installation using the native
installation method promotes greater knowledge of the components and their
placement, which may be needed later for administration and troubleshooting.
This section includes the following tasks:

򐂰 Install Web Portal Manager and PDJRTE.
򐂰 Configure Web Portal Manager.
򐂰 Verify the Web Portal Manager.
Install Web Portal Manager and PDJRTE

To install the Tivoli Access Manager Web Portal Manager and the Access
Manager Java Runtime Environment (PDJRTE), do the following:
1. Ensure WebSphere Application Server V5.0.2 is installed.

In our example, since we are installing the Web Portal Manager on the same
node as the Tivoli Directory Server (Web Administration Tool), WebSphere
Application Server V5.0.2 has already been installed.
For details refer to “WebSphere Application Server installation” on page 197.
2. Ensure that the IBM Java Runtime Environment V1.3.1 is installed.
For details refer to 6.2.4, “Java Runtime Environment (JRE) V1.3.1
installation” on page 192.
Note: Configuring Web Portal Manager against JREs other than the IBM
JRE V1.3.1 may cause the configuration to fail.
3. Ensure that the following Windows services are started:

– IBM Tivoli Directory Server V5.2
– Access Manager Policy Server
4. Insert the IBM Tivoli Access Manager Web Administration Interfaces for
Windows 2000 CD.
and run Setup.exe to start the installation.
8. When the License Agreement window appears, if in agreement, click Yes to
continue.
– Check Access Manager Java Runtime Environment (PDJRTE).
– Check Access Manager Web Portal Manager.
Note: The Web Portal Manager war file and the runtime are installed to the
target system.
We intentionally installed the packages listed separately from the Tivoli

Access Manager installation above, to note the required packages for Web
Portal Manager in case it is installed on a separate node.
10.When the installation is complete you should see a dialog with the message
All Access Manager components have been installed. Installation
completed successfully. Click OK to exit.
Configure Web Portal Manager
To configure the PDJRTE and the Web Portal Manager, do the following:
1. Configure the Access Manager Java Runtime Environment (PDJRTE).
a. Open a command window and navigate to the following directory where
the Tivoli Access Manager components have been installed:
cd \ibm\Tivoli\tam\sbin
b. Run the following command to start the pdjrtecfg configuration tool:
pdjrtecfg -action config -interactive
c. From the Configuration Type window, select Full and then click Next.
d. When the Java Runtime Environment window appears, ensure that you
enter the JRE path to the WebSphere Application Server V5.0.2 JRE. In
our example, we entered the following and clicked Next:
JRE Path: c:\ibm\WebSphere\AppServer\java\jre
e. When the Policy Server Information window appears, we entered the
• Port: 7135
• Domain: Default
f. When the Logging Information window appears, we entered the following
and then clicked Finish:
• Check Enable Tivoli Common Directory for logging.
• Log directory: c:\ibm\Tivoli\common
This option is greyed out, and defaults to the path set during
configuration.
g. You should see a dialog with the message Configuration of Access
Manager Java Runtime Environment completed Successfully. Click OK.
2. Configure the Web Portal Manager.
a. Open a command window and navigate to the following directory where
the Tivoli Access Manager components have been installed:
cd \ibm\Tivoli\tam\sbin
b. Run the following command to start the Web Portal Manager configuration
tool:
amwpmcfg -action config -interactive
c. When the WebSphere Application Server Information window appears, we
accepted the detected path (for example, c:\ibm\WebSphere\AppServer)
and clicked Next.

d. When the Policy Server Information window appears, we entered the
following and clicked Next:
• Port: 7135
e. When the Administration Login window appears, we entered the following
and clicked Finish:
• Administration ID: sec_master
• Administrator password: <password>
• Domain: Default (greyed out)
f. You should see a dialog with the message Configuration of Access
Manager Web Portal Manager completed successfully. Click OK.
Verify the Web Portal Manager

To verify the Tivoli Access Manager Web Portal Manager, do the following:
1. Restart the following Windows services to pick up the configuration settings
for the newly deployed Web Portal Manager:
– IBM HTTP Server 1.3.26
– IBM WebSphere Application Server V5 - server1
2. Enter the following URL in a Web browser to access the Web Portal Manager:
http://<hostname>/pdadmin
Where <hostname> is the hostname where the Web Portal Manager is
deployed (for example, http://tamwin1.itso.ral.ibm.com/pdadmin).
3. When the Access Manager Login page appears, enter the following and then
click Login:
– Secure Domain: Default
– User ID: sec_master
4. Review the configuration options. To logout, click Sign off in the lower right of
the page.
6.2.12 Tivoli Access Manager V5.1 Base Fixpack 2 installation

To install Tivoli Access Manager V5.1 Base Fixpack 2, do the following:
Note: For more detailed information on installing the Tivoli Access Manager
V5.1 Base Fixpack 2, refer to the Readme, which can be found at:
http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2bT
ivoli+%2bAccess+%2bManager&uid=swg24006925&loc=en_US&cs=utf-8&cc=us&lang=all
1. Back up the Tivoli Access Manager V5.1 Base databases on the Policy
Server node be before installing Fixpack 2 as follows:
a. Create a database backup directory (for example, c:\ibm\tamdb.bak).
b. Open a command window and the following command:
pdbackup -action backup -list c:\ibm\Tivoli\tam\etc\pdbackup.lst -path
c:\ibm\tamdb.bak
2. Ensure that you have installed IBM GSKit V7.0.1.16, which is a prerequisite to
Fixpack 2.
Refer to 6.2.3, “IBM GSKit upgrade installation” on page 188 for details.
3. Ensure that the Tivoli Access Manager Windows services are stopped before
installing the fixpack:
– Access Manager Authorization Server
4. Ensure that the server1 application server where Web Portal Manager has
been deployed is stopped.
5. Download Tivoli Access Manager V5.1 Base Fixpack 2 from the following
URL to a temporary directory (for example, c:\temp\tam51.fp2) on the Policy
Server node:
http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2b
Tivoli+%2bAccess+%2bManager&uid=swg24006925&loc=en_US&cs=utf-8&cc=us&lang=a
ll
6. Navigate to the temporary directory where you downloaded the fixpack (for
example, c:\temp\tam51.fp2), and run 5.1-TAM-FP02-WIN.exe to start the
Access Manager V5.1 Fixpack Setup (5.1.0.2).
8. When the License Agreement window appears, review the terms, and if in
agreement click Yes.
9. When the installation is complete, click Finish.
10.When the Configuration Type window appears, select Full and click Next.
11.When the Java Runtime Environment window appears, specify the path to the
WebSphere Application Server JRE (for example,
c:\ibm\WebSphere\AppServer\java\jre) and then click Next.

Note: In our example, the PDJRTE was already configured prior to starting
the Fixpack 2 installation. When the dialog appears to configure the
PDJRTE, it gave us an error dialog that it was already configured. We
clicked OK and continued. Then clicked Cancel.
The Fixpack installer on Windows launches the PDJRTE configuration

automatically as part of the Fixpack installation, even though it is
configured in our example.
12.To verify that the Fixpack installation was successful, enter the following
command:
pdversion
This should return a list of components installed at the 5.1.0.2 level (Fixpack
2).
13.Restart the Access Manager Auto-Start Service Windows service.
– Access Manager Authorization Server.
– Access Manager Policy Server.
The installation and base configuration for the Policy Server node components is
complete.
6.3 Implement the Reverse Proxy node

This section describes the procedure we used to install and configure the
Reverse Proxy node for the ITSO working example runtime environment on
Windows.
Note: When installing and configuring the Reverse Proxy node, we referenced
the following product guides and redbook:
SC32-1361
SC32-1359
The high level tasks to install the Reverse Proxy node are as follows:
1. Windows 2000 Server installation.
2. Install GSKit.
3. Install Java Runtime Environment (JRE)
4. Install Tivoli Directory Client.
5. Tivoli Access Manager - WebSEAL installation.
6. Tivoli Access Manager - WebSEAL configuration.
7. Tivoli Access Manager V5.1 Base Fixpack 2 installation.
8. Tivoli Access Manager V5.1 WebSEAL Fixpack 2 installation.

Refer to 6.2.1, “Windows 2000 Server installation” on page 183, for details.
6.3.2 Install GSKit

In our example, we installed the IBM GSKit V7.0.1.16 on the Reverse Proxy
node. In this case the Windows registry entry for the application name is
policydirector.
For details as to why the IBM GSKit V7.0.1.16 is needed and how to install it,
refer to 6.2.3, “IBM GSKit upgrade installation” on page 188.
6.3.3 Install Java Runtime Environment (JRE)

The Java Runtime Environment is needed by the iKeyman utility installed with
the GSKit. The iKeyman is used to create the keystore and create certificates.
For details refer to “Java Runtime Environment (JRE) V1.3.1 installation” on

page 192.
6.3.4 Install Tivoli Directory Client

To install the Tivoli Directory Client V5.2 on the Reverse Proxy node, do the
following:
1. Insert the IBM Tivoli Access Manager Web Security for Windows 2000 CD.
2. Navigate to the <CD_Root>\windows\Directory folder and run Setup.exe to
start the installation program.
3. When the Select Language used by install Wizard window appears, select the
desired language (for example, English) and click OK.
5. When the License Agreement window appears, review the terms, and if in
agreement, select I accept the terms in the license agreement, and then
click Next.

6. The installer will detect applications that have already been installed (for
example, GSKit). Click Next.
7. When the Tivoli Directory Server V5.2 Installation Directory window appears,
we entered the following and then clicked Next:
– Installation directory: c:\ibm\ldap
8. Select the Tivoli Directory Server language (for example, English) and click
Next.
9. When the Select Features to install window appears, we selected the
following, and then clicked Next:
– Check Client SDK 5.2.
– Uncheck GSKit.
A new level of the GSKit has already been installed.
10.When the Summary page appears, review the selections and click Next.
11.When the installation completes, review the readme files for the client and
click Next.
12.When prompted, select Yes, restart my computer and click Next.
13.Click Finish.
6.3.5 Tivoli Access Manager - WebSEAL installation

The Tivoli Access Manager V5.1 WebSEAL can set up this system using one of
the following installation methods:
򐂰 Installation wizard
򐂰 Native installation utilities
For the ITSO working example, we chose to use the native installation utilities.
Install the Tivoli Access Manager WebSEAL

To install and configure a Tivoli Access Manager WebSEAL server system on
Windows, do the following:
1. Ensure that the following prerequisites have been met.
– Log on as a user with administrator privileges. In our example, we logged
in to Windows as the admin user we created with administrator privileges
prior to the installation.
– Ensure that the registry server (Tivoli Directory Server) and policy server
(Tivoli Access Manager Policy Server) are up and running in normal mode.
– Ensure that the GSKit is installed. In our example, the GSKit was installed
as part of the Tivoli Directory Server installation.
For details see “Install GSKit” on page 219.
– Ensure that the Java Runtime Environment is installed, which is required
by the iKeyman utility used by GSKit to create a keystore and certificates.
For details see “Install Java Runtime Environment (JRE)” on page 219.
– Ensure that the Tivoli Directory Client is installed.
For details see “Install Tivoli Directory Client” on page 219.
2. Insert the IBM Tivoli Access Manager Web Security for Windows 2000 CD.
and run Setup.exe to start the installation program.
4. When the Choose Setup Language window appears, select the desired
– Check Access Manager Runtime.
– Check Access Manager Java Runtime Environment.
– Check Access Manager Web Security Runtime.
– Check Access Manager WebSEAL.
8. Access Manager Runtime installation.
When the Access Manager Runtime Choose Destination Directory window
appears, we did the following:
a. Click Browse.
b. Enter the destination directory c:\ibm\Tivoli\tam and click OK.
c. Click Next.
d. When the Access Manager Runtime Installation Summary window
appears, click Next to begin copying files.
9. Access Manager Web Security Runtime installation.
a. When the Welcome Access Manager Web Security Runtime window
appeared, click Next.
b. When the License Agreement window appears, review the terms and, if in
c. When the Access Manager Java Runtime Environment Choose
Destination Directory window appears, we did the following:
i. Click Browse.

ii. Enter the Access Manager Web Security Runtime installation directory
c:\ibm\Tivoli\PDWebRTE and then click OK.
iii. Click Next.
d. When the installation is complete, select Yes, I want to restart my
computer now. Click Finish.
Note: Even though we have selected Yes, I want to restart my computer

now and clicked Finish, the installation program will continue to the Access
Manager WebSEAL installer.
10.Access Manager WebSEAL installation.

a. When the Welcome Access Manager WebSEAL window appears, click
Next.
b. When the License Agreement window appears, review the terms and, if in
c. When the Access Manager WebSEAL Choose Destination Directory
window appeared, we did the following:
i. Click Browse.
ii. Enter the Access Manager WebSEAL installation directory
c:\ibm\Tivoli\PDWeb and then click OK.
iii. Click Next.
d. When the installation is complete, select Yes, I want to restart my
computer now. Click OK. This time the system will restart.
6.3.6 Tivoli Access Manager - WebSEAL configuration

After the Tivoli Access Manager V5.1 WebSEAL and Web Security runtime are
installed, they must be configured.
To configure the Tivoli Access Manager Runtime and WebSEAL, do the

following:
1. Start the pdconfig configuration utility on the Reverse Proxy node by entering
the following in a command window:
pdconfig
2. From the Access Manager Configuration utility, select the Access Manager
Runtime package and click Configure.
a. When the Access Manager Policy Server Host window appears, select
Access Manager Policy Server is installed on another machine, enter
the following, and then click Next:
• Host name: tamwin1.itso.ral.ibm.com
• Listening port: 7135
b. When the Registry window appears, select LDAP and click Next.
c. When the Domain Information window appears, we accepted Default
(default-supplied value—do not change) in the Local domain name field
and then clicked Next.
d. When the LDAP Server Information window appears, we entered the
• LDAP host name: tamwin1.itso.ral.ibm.com
• LDAP port number: 389
e. When the SSL with the registry server window appears, we selected No
next to Enable SSL with the registry server and clicked Next.
Note: In a later configuration section, we will configure SSL as part of

security hardening for the entire secure portal runtime environment.
f. When the Logging Information window appears, we checked Enable

Tivoli Common Directory for logging, entered log directory
c:\ibm\Tivoli\common, and then clicked Next.
g. When the Configuration Review window appears, take note of the Policy
Server certificate path (for example,
c:\ibm\Tivoli\TAM\keytab\pdcacert_download.b64). When done, click
Finish.
3. From the Access Manager Configuration utility, select the Access Manager
WebSEAL package and click Configure.
a. When the Access Manager WebSEAL Configuration window appears,
click Configure.
b. When the Instance Identification window appears, enter the following and
then click Next:
• WebSEAL instance name: default
The value can not exceed 20 characters.
Note: Chapter 23, “pdconfig options,” in Web Security Installation

Guide, IBM Tivoli Access Manager V5.1, SC32-1361, documents
how to use the fully qualified host name. We found this was not
possible given the 20-character input restriction.
• Do not check Use a logical network interface (not used in our

example).

c. When the WebSEAL Server Information page appears, enter the following
and then click Next.
• Hostname: wswin1
Note: When the instance is created, the server name will be

generated as <instance_name>-webseald-<hostname> (for
example, default-webseald-wswin1).
• Listening port: 7234

d. When the Administrator Identification page appears, enter the following
• Administration ID: sec_master
• Administration password: <password>
e. When the SSL communications with LDAP Server window appears, we
uncheck Enable SSL communication with the LDAP server and clicked
Next (no SSL at this time).
f. When the HTTP/HTTPS/Document Root Properties window appears, we
accepted the following defaults and clicked Finish:
HTTP Access:
• Check Allow HTTP Access
• Port: 80
HTTPS Access:
• Check Allow HTTPS Access
• Port: 443
• Document root directory: c:/ibm/Tivoli/PDWeb/www-default/docs
Where default is the instance name.
g. You should see the default instance created. When done, click Close.
4. Configure Access Manager Java Runtime Environment.
a. Select the Access Manage Java Runtime Environment from the Access
Manager Configuration window.
b. Click Configure.
c. When the Configuration Type window appears, select Standalone (only
used by local iKeyman utility) and click Next.
d. Enter the JRE path (for example, c:\ibm\Java131\jre), and then click Next.
e. When the Logging Information window appears, we checked Enable
Tivoli Common Directory for logging, entered log directory
c:\ibm\Tivoli\common, and then clicked Finish.
f. After configuration, click OK.
g. When done, close the configuration utility by clicking Close.
Configure GSKit iKeyman utility

After the GSKit is installed, the iKeyman utility must be configured.
1. Ensure that the following prerequisites are installed and configured, which
should be the case if you have followed the documented procedure:
– Ensure that the Java Runtime is installed
(see “Install Java Runtime Environment (JRE)” on page 219).
– Ensure that GSKit is installed
(see “Install GSKit” on page 219).
– Ensure that Access Manager Java Runtime Environment is installed
(see “Install the Tivoli Access Manager WebSEAL” on page 220).
2. Navigate to the c:\ibm\Java131\jre\lib\security directory on the Reverse Proxy
node.
3. Back up the java.security file to java.security.org.
4. Modify the java.security file as follows to add the IBM JCE and IBM CMS
security providers:
security.provider.3=com.ibm.crypto.provider.IBMJCE
security.provider.4=com.ibm.spi.IBMCMSProvider
5. Save and close the java.security file.
6. Verify that the iKeyman utility starts properly from a command window by
entering the following commands:
cd \ibm\gsk7\bin
set JAVA_HOME=c:\ibm\Java131\jre
gsk7ikm
7. Close the IBM Key Management utility.
6.3.7 Tivoli Access Manager V5.1 Base Fixpack 2 installation

In our example, we installed the Tivoli Access Manager Runtime Environment on
the Reverse Proxy node. As part of our configuration we need to upgrade the
Tivoli Access Manager V5.1 Base to Fixpack 2 (5.1.0.2).
Ensure that the Tivoli Access Manager WebSEAL Windows service is stopped
prior to installing the fixpack.
For details on installing Tivoli Access Manager V5.1 Base Fixpack 2, refer to
6.2.12, “Tivoli Access Manager V5.1 Base Fixpack 2 installation” on page 216.

6.3.8 Tivoli Access Manager V5.1 WebSEAL Fixpack 2 installation
To install Tivoli Access Manager V5.1 WebSEAL Fixpack 2, do the following:
Note: For more detailed information on installing the Tivoli Access Manager
V5.1 WebSEAL Fixpack 2, refer to the readme, which can be found at:
http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2bT
ivoli+%2bAccess+%2bManager&uid=swg24006926&loc=en_US&cs=utf-8&cc=us&lang=all
1. Ensure that you are logged into the Reverse Proxy node as an administrator.
2. Back up the Tivoli Access Manager V5.1 WebSEAL databases on the
Reverse Proxy node be before installing Fixpack 2 as follows:
a. Create a database backup directory (for example, c:\ibm\websealdb.bak).
b. Open a command window and enter the following command:
pdbackup -action backup -list c:\ibm\Tivoli\tam\etc\pdbackup.lst -path
c:\ibm\websealdb.bak
3. Ensure that you have installed IBM GSKit V7.0.1.16, which is a prerequisite to
Fixpack 2.
Refer to “Install GSKit V7.0.1.16” on page 191 for details.
4. Ensure that the Tivoli Access Manager WebSEAL-<instance> Windows
service is stopped before installing the fixpack.
5. Download Tivoli Access Manager V5.1 WebSEAL Fixpack 2 from the
following URL to a temporary directory (for example, c:\temp\tam51ws.fp2) on
the Reverse Proxy node:
ll
example, c:\temp\tam51ws.fp2) and run 5.1-AWS-FP02-WIN.exe to start the
Access Manager V5.1 WebSEAL Fixpack 2 Setup (5.1.0.2).
9. When the installation completes, click Finish.
Note: If a configuration window appears for the PDJRTE, you can click
Cancel since we have already configured the Access Manager Java
Runtime Environment.
10.To verify that the Fixpack installation was successful, open a command
window and enter the following command:
pdversion
This should return a list of components installed at the 5.1.0.2 level (Tivoli
Access Manager Base and WebSEAL Fixpack 2).
11.Start the Access Manager Auto-Start Service Windows service.
This completes the base installation and configuration of the Reverse Proxy
node.
6.4 Implement the Portal Server node

This section describes the procedure we used to install and configure the Portal
Server node for the ITSO working example runtime environment on Windows.
Note: When installing and configuring the Portal Server node, we referenced
the following:
򐂰 IBM WebSphere Portal Extend for Multiplatforms V5.0.2 InfoCenter at:
http://www.ibm.com/websphere/portal/library
򐂰 IBM WebSphere Portal for Multiplatforms V5 Handbook, SG24-6098,
redbook
The high-level tasks to install the Portal Server node are as follows:
1. Windows 2000 Server installation
2. WebSphere Portal Server V5.0 installation
3. WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2) installation
4. WebSphere Application Server V5.0.2 Fixes installation
5. WebSphere Portal V5 Fixpack 2 (V5.0.2) installation
6. WebSphere Application Server Enterprise V5.0.2 Cumulative Fix (V5.0.2.3)
installation
7. WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) installation
8. Java Runtime Environment (JRE) V1.3.1 installation
9. Tivoli Access Manager Java Runtime Environment installation
10.DB2 Universal Database installation

Refer to 6.2.1, “Windows 2000 Server installation” on page 183, for details.
6.4.2 WebSphere Portal Server V5.0 installation

This section describes how to install and configure WebSphere Portal Server
V5.0. on the Portal Server node. We will install the following components with
this installation:
򐂰 WebSphere Application Server Enterprise V5.0.1 (Base and PME) including
required fixes
򐂰 IBM HTTP Server V1.3.26
򐂰 WebSphere Portal Server V5.0
򐂰 WebSphere Portal Content Publishing V5.0
Install WebSphere Portal

To install WebSphere Portal V5.0, do the following:
1. Insert the IBM WebSphere Portal V5.0.2 Setup CD.
The installer will automatically start the installation process by offering a
command prompt. If auto start is disabled, run install.bat from the root of the
CD to start the installation.
Tip: You may have to minimize the command prompt window if it stays on
top and obscures the language prompt.
2. When the Install Shield Language window appears, select the desired
3. When the Welcome window appears, you are provided with an option to
launch the InfoCenter (optional). Click Next to continue the installation.
4. When the License Agreement page appears, review the terms and, if in
agreement, select I accepts the terms in the license agreement and then
click Next.
The installer will check for the required operating system and prerequisites.
5. The next window provides the installation options to choose from Full (all
components) or Custom (useful when components such as WebSphere
Application Server are already installed).
In our example, we selected Full and click Next to continue.
6. The wizard displays a window for the WebSphere Application Server
installation directory. We used the following path and then clicked Next:
– Installation directory: C:\ibm\WebSphere\AppServer
7. The next window displays the IBM HTTP Server installation directory. We
used the following path and then clicked Next:
– Installation directory: C:\ibm\IBMHTTPServer
8. The next window prompts for us the System Logon user ID and password that
will be used to start the WebSphere Application Server and IBM HTTP Server
programs, if these are selected to be run as a service. We used the following
settings and clicked Next:
– Check Run WebSphere Application Server as a service.
– Check Run IBM HTTP Server as a service.
– User ID: admin
In our example, we create the admin user as part of our Windows
configuration in 6.4.1, “Windows 2000 Server installation” on page 228.
Note: If the User ID had not been created or you did not give administrator
rights to the current user, you will see an error message like Figure 6-7.
You should then proceed to create the user exactly as specified in, “Create
admin user and assign user rights” on page 183.

Figure 6-7 WebSphere Portal Server invalid user ID or password message
9. The next window prompts for the node name and host name to be used for
the WebSphere Application Server install. We used the following values and
clicked Next:
– Node name: wpwin1
– WebSphere Application Server hostname: wpwin1.itso.ral.ibm.com
10.We are now prompted for the WebSphere Portal installation directory. We
used the following path and clicked Next:
– Installation directory: C:\ibm\WebSphere\PortalServer
11.The next window prompts for the Portal administrative user and password.
We used the following values, confirmed the password, and clicked Next:
– Administrative user: wpsadmin
The <password> for wpsadmin is user defined during the installation.
– Confirm Password: <password>
12.The next window will display the different components that are going to be
installed. Click Next.
13.The Installer program will then prepare the installation. After a while, you will
be prompted to insert CD #1-1 WebSphere Application Server Enterprise for
Windows. It will first start locating a Java Virtual Machine, then begin the
install of WebSphere Application Server (Base and PME).
After this installation is completed, you will be prompted to insert CD #1-6
WebSphere Application Server Fixpack and eFixes for Windows and Linux.
Note: For the ITSO example, we avoided the necessity of replacing CDs
by putting the CD images on the network drive. By verifying that you use
the following directory names for each CD image (and place the images in
the same directory on the network), you will not be prompted to insert any
CDs:
򐂰 setup
򐂰 cd1-1
򐂰 cd1-6
򐂰 cd2
The wizard will then perform the following tasks, displaying a progress meter
for each task:
– Preparing the WebSphere Application Server Fix Pack files
– Installing WebSphere Application Server Fix Pack 1
– Installing WebSphere Application Server Enterprise Fix Pack 1
– Installing WebSphere Application Server Fixes
14.When these tasks are complete, the installer will start the WebSphere
Application Server (server1 application server). After the server starts, you
will be prompted to insert CD #2 WebSphere Portal Server - WebSphere
Portal Content Publisher. It will start installing WebSphere Portal.
15.When this completes, the InfoCenter will install and then WebSphere Portal
Server will start (WebSphere_Portal application server). The install is then
validated and the portlets will begin to be installed. Once this has finished, the
Installer will go on to install the content publishing features. Once the whole
procedure is completed, you should be presented with a window stating that
the installation was successful.
Leave the checkbox selected for Launch First Steps and click Finish.
The installation program will then complete and close. Note that as its final task,
it will load the WebSphere Portal First Steps application.
WebSphere Portal Server verification

If the installation completed properly, the WebSphere Portal First Steps
application should be running.

Note: Start the WebSphere Portal application server and First Steps.
If you have restarted the system where WebSphere Portal is installed after the
installation and WebSphere Portal and the First Steps are not running, do the
following:
1. Start the WebSphere Portal application by clicking Start → Programs →
IBM WebSphere → Portal Server v5.0 → Start the Server.
Alternatively, start the WebSphere Portal application server from the
command line as follows:
c:\ibm\WebSphere\AppServer\bin\startServer Webphere_Portal
2. Start First Steps application by selecting Start → Programs → IBM
WebSphere → Portal Server v5.0 → First Steps.
To verify WebSphere Portal, do the following:

1. Click Launch WebSphere Portal to test that the portal pages appear
properly. This should launch a Web browser window with the following URL
(wpwin1.itso.ral.ibm.com is the host name of this node):
http://wpwin1.itso.ral.ibm.com:9081/wps/portal
Tip: When launching the portal from the first step GUI, be sure that the
URL contains the fully qualified DNS name in case the URL has only the
hostname. This could happen if the System properties → Network
Identification → Full computer name does not contain the domain name
extension. If this is the case then add the computer to the domain or add
the domain name.
2. Log in to the portal by clicking the Log in link located in the upper right corner.
This will take you to a new page prompting for login information.
– User ID: wpsadmin
This user ID was created during the WebSphere Portal installation.
– Password: <your_password>
The password was user defined during the WebSphere Portal installation.
3. You should be presented with the personalized portal pages for the logged in
user. If the install is successful and you have Internet access, you should see
a portal a page like Figure 6-8 displayed.
If your computer does not have direct access to the Internet, you will see a
page like Figure 6-9 on page 234. This error is purely cosmetic and happens
because some of the given portlets obtain content to display by connecting to
servers available on the Internet.
Figure 6-8 WebSphere Portal welcome page with Internet access

Figure 6-9 WebSphere Portal welcome page with no Internet access
4. Click Log out.
6.4.3 WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2)

installation
The IBM WebSphere Portal Extend for Multiplatforms V5.0.2 includes IBM
WebSphere Application Server Enterprise V5.0.2. In summary, the IBM
WebSphere Application Server Enterprise V5.0.2 includes the IBM WebSphere
Application Server (Base), WebSphere Application Server Network Deployment,
WebSphere MQ, and Programming Module Enhancements (PME).
As a prerequisite to IBM WebSphere Portal Extend for Multiplatforms V5.0.2, we

will install IBM WebSphere Application Server Enterprise V5 Fixpack 2 to service
the WebSphere Application Server Base and PME components. We will install
each of these components found in Fixpack 2 separately.
The WebSphere Application Server Enterprise V5 Fixpack 2 requires write

access to the file system during installation. For this reason we need to copy the
fixpack to the local file system of the target node. In addition, Fixpack 2 includes
a newer version of the WebSphere Update Installer (install Wizard for fixpacks
and fixes). We will use the WebSphere Update Installer included with Fixpack 2
to install the WebSphere fixes.
The WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2) installation

includes the installation of the following:
򐂰 Stop servers and back up configuration.
򐂰 Install WebSphere Application Server V2 Fixpack 2.
򐂰 Install WebSphere Application Server PME V5 Fixpack 2.
Stop servers and back up configuration

Prior to starting the cumulative fix installation, ensure that the server Windows
services are stopped, and back up the WebSphere Application Server
configuration as follows:
1. Ensure that the following servers are stopped before you install Fixpack 2:
– WebSphere Application Server Enterprise (all application servers
including server1, WebSphere_Portal)
– IBM HTTP Server
– IBM HTTP Administration Server
Note: Refer to 12.2.3, “WebSphere Application Server - Command-line

tools” on page 533, for instructions on how to stop and check the status of
an application server.
2. Back up the WebSphere Application Server configuration by entering the

following command:
c:\ibm\WebSphere\AppServer\bin\backupConfig

Install WebSphere Application Server V2 Fixpack 2
To install WebSphere Application Server V5 Fixpack 2 (V5.0.2), do the following
on the Portal Server node:
1. Copy the WebSphere Application Server Base Fixpack 2 files and sub
directories found in the <CD_Root>\wasfp2\win directory of the WebSphere
Application Server Fixpack and eFixes for Windows and Linux CD to a
temporary directory (for example, c:\temp\was5.fp2).
2. Set up the environment by running the setupCmdLine.bat as follows:
c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat
3. To start the WebSphere Update Installer (updateWizard.bat) supplied with
WebSphere Application Server Base Fixpack 2, we entered the following:
c:\temp\was5.fp2\updateWizard.bat
6. The WebSphere Update Installer will detect your current WebSphere
Application Server version (IBM WebSphere Application Server V5.0.1 +
Enterprise V5.0.1) and installation directory (c:\ibm\WebSphere\AppServer).
Click Next.
7. Select Install fix packs and then click Next.
8. Enter the directory where you have copied the fixpack. For example, we
entered c:\temp\was5.fp2\fixpacks in the Fix pack directory text field, and
then clicked Next.
9. Select the was50_fp2_win fixpack (default) and then click Next.
10.You will be prompted for the directories for the IBM HTTP Server and the
WebSphere Application Server Embedded Messaging. In our example, we
accepted the following path and then clicked Next.
– IBM HTTP Server: c:\ibm\IBMHttpServer
– Embedded Messaging: <not_installed>
12.When the WebSphere Application Server V5 Base Fixpack 2 installation is
Install WebSphere Application Server PME V5 Fixpack 2
To install WebSphere Application Server Programming Module Extension (PME)
V5 PME Fixpack 2 (V5.0.2), do the following:
1. Copy the WebSphere Application Server PME Fixpack 2 files and sub
directories found in the <CD_Root>\pmefp2\win directory of the WebSphere
temporary directory (for example, c:\temp\was5pme.fp2).
WebSphere Application Server PME Fixpack 2 we entered the following:
c:\temp\was5pme.fp2\updateWizard.bat
Application Server version. Click Next.
Notice that the base version is now V5.0.2 since the base Fixpack was has
been installed (IBM WebSphere Application Server V5.0.2 + Enterprise
V5.0.1) in the installation directory (c:\ibm\WebSphere\AppServer).
entered the following in the Fix pack directory field and then clicked Next:
c:\temp\was5pme.fp2\fixpacks
9. Select the was50_pme_fp2_win fixpack (default) and then click Next.
11.When the WebSphere Application Server V5 PME Fixpack 2 installation is
6.4.4 WebSphere Application Server V5.0.2 Fixes installation

This section describes how to install WebSphere Application Server Fixes on top
of the WebSphere Application Server Enterprise V5 Fixpack 2. These fixes are
required by WebSphere Portal V5.0.2.

The WebSphere Portal Server Fixpack 2, which we install in the next section,
requires the following fixes to be installed on WebSphere Application Server
before proceeding with the Portal fixpack installation:
򐂰 PQ76567_5.0.2.jar
򐂰 PQ78166eFix_fixes_install_db_resource.jar
򐂰 PQ81248_fix.jar
򐂰 WAS_CM_08-12-2003_5.0.2-5.0.1_cumulative_Fix.jar
The following additional fixes are required for proper operation of WebSphere
Portal Server V5.0.2:
򐂰 PQ75469.jar
򐂰 PQ77008.jar
򐂰 PQ77142.jar
򐂰 PQ78370_Fix.jar
򐂰 PQ78882_Fix.jar
򐂰 PQ79083_5.0.2_Fix.jar
򐂰 WAS_Adapter_10-30-2003_5.0.2_cumulative_Fix.jar
򐂰 WAS_Sessions_08-12-2003_5.0.2_cumulative_Fix.jar
򐂰 WAS_Security_07-07-2003_5.0.2-5.0.1-5.0.0_JSSE_cumulative_Fix.jar
򐂰 WAS_Plugin_09-03-2003_5.0.X_cumulative_Fix_Win.jar
To install the WebSphere Application Server V5.0 Fixes required by WebSphere

Portal, do the following:
1. Ensure that the following servers are stopped before you install Fixpack 2:
– IBM HTTP Server
2. Copy the WebSphere Application Server V5.0.2 Fixes files and sub
directories found in the <CD_Root>\fixes\win directory of the WebSphere
temporary directory (for example, c:\temp\was502.efixes).
WebSphere Application Server PME Fixpack 2 we entered the following:
c:\temp\was502.efixes\updateWizard.bat
Notice that the base version is now V5.0.2 since the base Fixpack was has
been installed (IBM WebSphere Application Server V5.0.2 + Enterprise
V5.0.2) in the installation directory (c:\ibm\WebSphere\AppServer).
Note: If the base version is not detected, enter the path to the WebSphere
Application Server installation directory.
8. Select Install fixes and then click Next.

entered c:\temp\was502.efixes\efixes in the Fixes directory text field, and
then clicked Next.
10.When the fixes list appears, check all fixes (defined in list above) and then
click Next.
Note: Information describing each PQ fix is available during the Fixes

installation by selecting the fix and reviewing the Fix description text box.
11.Review the fixes selected to install and then click Next to begin the fix
12.When the WebSphere Application Server V5.0.2 Fixes installation is
Verify the WebSphere Application Server V5.0.2

Prior to continuing to the WebSphere Portal V5 Fixpack 2 installation, we
recommend that you verify that the WebSphere Application Server V5.0.2 is
working properly.
For details on how to verify the WebSphere Application Server refer to “Verify
WebSphere Application Server V5.0.2” on page 200.

6.4.5 WebSphere Portal V5 Fixpack 2 (V5.0.2) installation
To install the WebSphere Portal V5 Fixpack 2 (V5.0.2), do the following:
1. Ensure that you have installed the required WebSphere Application Server
Fixpacks and Fixes.
– WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2)
– WebSphere Application Server V5.0.2 Fixes required by WebSphere
Portal V5.0.2
To check the server status, enter the following command:
C:\ibm\websphere\appserver\bin\serverStatus -all
If you receive a message that none of the servers can be reached, then they
are all stopped. If one or more servers display as running, you can use the
command stopServer <servername> in order to stop the server.
2. Create the <wp_home>\update directory to copy the fixpack (for example,
c:\ibm\WebSphere\PortalServer\update).
3. Copy the WebSphere Portal V5 Fixpack 2 files and sub directories found in
the root of the WebSphere Portal V5 Fixpack CD, to the <wp_home>\update
directory (for example, c:\ibm\WebSphere\PortalServer\update), which we
created in the previous step.
4. Open a command window and enter the following command to set up the
Java environment for the WebSphere Portal update installer:
C:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat
5. Navigate to the WebSphere Portal update directory:
cd \ibm\WebSphere\PortalServer\update
6. To start the WebSphere Portal update installer, enter the following command:
updatePortal -fixpack -installDir “c:\ibm\WebSphere\PortalServer”
-fixpackDir “c:\ibm\WebSphere\PortalServer\update” -install -fixpackID
WP_PTF_502
Note: If you have configured WebSphere Application Server V5 security

prior to installing the WebSphere Portal V5 Fixpack 2, you will need to
ensure the WasUserid and WasPassword fields are populated correctly in
the <wp_home>\config\wpconfig.properties file before running the
WebSphere Portal V5 Fixpack 2 update installer.
When the Fixpack is complete, you should see the message Fix pack
installation completed successfully.
7. Update the WebSphere Portal configuration.
Note: Configuration failure due to WebSphere SOAP timeout.
We found that on slower systems, the WebSphere Portal configuration for

the post Fixpack 2 operation received a configuration failure on task 36 of
50, due to a WebSphere Application Server SOAP connector timeout. The
failure will show up as follows in the <portal_home>\log\ConfigTrace.log:
action-remove-ear-wmm:
..
[wsadmin] WASX7017E: Exception received while running file
"C:\ibm\WebSphere\PortalServer/config/work/was/removeWmmEar.jacl";
exception information: com.ibm.bsf.BSFException: error while eval'ing
Jacl expression: com.ibm.ws.scripting.ScriptingException:
com.ibm.websphere.management.exception.ConfigServiceException
To work around this issue, we did the following:

1. Increased the WebSphere Application Server SOAP connector timeout
in <was_home>\properties\soap.client.props. We changed the value of
the com.ibm.SOAP.requestTimeout=6000 (default 180).
2. Next, we backed the configuration by running the WebSphere Portal
uninstall. See the configuration failure/recovery procedure in the
following note box for details on how to run the uninstall.
3. We reran the WebSphere Portal configuration task.
After the WebSphere Portal V5 Fixpack installation is complete, you will need
to update the WebSphere Portal configuration.
a. Restart the IBM HTTP Server.
b. Open a command window and enter the following command to update the
WebSphere Portal configuration:
c:\ibm\WebSphere\PortalServer\config\WPSConfig.bat WP-PTF-502
-DPortalAdminPwd=<password>
Where <password> is the WebSphere Portal administrator password.

Note: Configuration failure/recovery: If the Update WebSphere Portal
configuration task fails, do the following:
1. Correct the cause of the failure.
2. Uninstall the WebSphere Portal V5 Fixpack 2 (uninstall might be
better named as unconfigure; this just unconfigures the failed
configuration) as follows:
WPSconfig.bat UNINSTALL-WP-PTF-5002
3. Rerun the WebSphere Portal configuration task.
For details refer to the WebSphere Portal V5 Fixpack 2 readme

(install_win_unix.html) found at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/readme/install_win
_unix.html
IBM WebSphere Portal Content Publisher V5

This section is not required for the ITSO working example.
IBM WebSphere Portal Content Publisher V5 was installed as part of the

WebSphere Portal V5 installation. In our example, we are not using Content
Publisher, thus we did not install WebSphere Portal Content Publisher V5
Fixpack 2. If you are using IBM WebSphere Portal Content Publisher V5, we
recommend that you install Fixpack 2.
Document Manager search index

This section is not required for the ITSO working example.
If you have installed and are using WebSphere Portal Content Publisher V5
installed the Content Publisher Fixpack 2, you will also need to update the
Document Manager search index.
When the fixpack is installed, the existing search index for Document Manager is
deleted. Before you can use the search function with Document Manager after
installing the fixpack, WebSphere Portal must update the search index through
the usual automated process, where the search index is updated according to a
specified interval. You can either wait until the next scheduled update occurs, or
you can change the interval to the shortest possible time to cause the update to
occur sooner.
Refer to the Managing documents → Document Manager → Search topic in
the WebSphere Portal Information Center for details on setting the update
interval:
Verify the WebSphere Portal Server

Now that you have installed and configured WebSphere Portal V5 Fixpack 2
(V5.0.2), we recommend that you verify that the WebSphere Portal Server is
working properly. For details refer to “WebSphere Portal Server verification” on
page 231.
6.4.6 WebSphere Application Server Enterprise V5.0.2 Cumulative

Fix (V5.0.2.3) installation
IBM WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1), which we install in
the following section, requires the following WebSphere Application Server
V5.0.2 cumulative fixes:
򐂰 Stop servers and back up configuration.
򐂰 Install WebSphere Application Server Cumulative Fix 2.
򐂰 Install WebSphere Application Server PME Cumulative Fix 2.
򐂰 Install WebSphere Application Server Cumulative Fix 3.
򐂰 Install WebSphere Application Server V5.0.2.3 efixes.
Note: The WebSphere Application Server prerequisites for WebSphere Portal

V5.0.2 Cumulative Fix 1 can be confusing, so we thought an explanation may
help.
We chose to patch WebSphere Application Server to the latest levels that

were officially supported by WebSphere Portal V5.0.2.1:
򐂰 WebSphere Application Server V5.0.2 Base Cumulative Fix 3 (V5.0.2.3)
򐂰 WebSphere Application Server V5.0.2 PME Cumulative Fix 2 (V5.0.2.2)
We found that we had to install WebSphere Application Server V5.0.2 Base

Cumulative Fix 2 before installing the PME Cumulative Fix 2. Then we were
able to successfully install WebSphere Application Server V5.0.2 Cumulative
Fix 3 (V5.0.2.3). In addition, WebSphere Portal V5.0.2.1 requires several
WebSphere Application Server V5.0.2.3 efixes. For these reasons, we have
installed the fixes in the order listed. Lastly, we found that WebSphere Portal
stopped working properly after installing the WebSphere Application Server
Fixpacks and Fixes, and began working after we installed the WebSphere
Portal Cumulative Fix 1 (V5.0.2.1).

Stop servers and back up configuration
Prior to starting the cumulative fix installation, ensure that the server Windows
services are stopped, and back up the WebSphere Application Server
configuration as follows:
1. Ensure that the following servers are stopped before you install the Fixpack:
– IBM HTTP Server
2. Back up the WebSphere Application Server configuration by entering the
following command:
c:\ibm\WebSphere\AppServer\bin\backupConfig
Install WebSphere Application Server Cumulative Fix 2

To download and install the WebSphere Application Server V5.0.2 (Base)
Cumulative Fix 2 (V5.0.2.2), do the following:
Note: More information on the WebSphere Application Server V5.0.2 (Base)

Cumulative Fix 2 (V5.0.2.2) like a list of defects fixed, the readme, and the
download for each platform can be found at:
http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg240
05952
1. Download the WebSphere Application Server V5.0.2 Cumulative Fix 2

(V5.0.2.2) for Windows (was502_cf2_win.zip) to a temporary directory
(c:\temp) on the Portal Server node from the following URL:
952
2. Unpack the cumulative fix download (was502_cf2_win.zip) to a temporary
directory (for example, c:\temp\was502.cf2).
WebSphere Application Server Cumulative Fix 2, we entered the following in
a command window:
c:\temp\was502.cf2\updateWizard.bat
The version should be IBM WebSphere Application Server V5.0.2 +
Enterprise V5.0.2, and installation directory c:\ibm\WebSphere\AppServer.

entered c:\temp\was502.cf2\fixpacks in the fix pack directory text field, and
then clicked Next.
9. When the Fix pack to install window appears, was502_cf2_win should be
selected. Click Next.
10.On the install summary page, review the old fixes to be uninstalled (newer
versions in cumulative fix), and then click Next to begin the fix pack
11.When the WebSphere Application Server V5.0.2 Cumulative Fix 2 installation
is complete, click Finish.
Install WebSphere Application Server PME Cumulative Fix 2

To download and install the WebSphere Application Server PME V5.0.2
Note: The WebSphere Application Server PME V5.0.2 Cumulative Fix 2

(V5.0.2.2) requires that the WebSphere Application Server (base) V5.0.2
Cumulative Fix 2 (V5.0.2.2) is installed as a prerequisite.
More information on the WebSphere Application Server PME V5.0.2

Cumulative Fix 2 (V5.0.2.2), a list of defects fixed, the readme, and the
http://www-1.ibm.com/support/docview.wss?rs=823&context=SS4QY3&uid=swg240
05954
1. Download the WebSphere Application Server PME V5.0.2 Cumulative Fix 2

(V5.0.2.2) for Windows (was502_pme_cf2_win.zip) to a temporary directory
http://www-1.ibm.com/support/docview.wss?rs=823&context=SS4QY3&uid=swg24005
954

2. Unpack the cumulative fix download (was502_pme_cf2_win.zip) to a
temporary directory (for example, c:\temp\was502pme.cf2).
WebSphere Application Server PME Cumulative Fix 2, we entered the
following in a command window:
c:\temp\was502pme.cf2\updateWizard.bat
The version should be IBM WebSphere Application Server V5.0.2.2 +
Enterprise V5.0.2, and the installation directory
c:\ibm\WebSphere\AppServer.

entered c:\temp\was502pme.cf2\CumulativeFixes in the Fix pack directory
text field, and then clicked Next.
9. When the fixpack to install window appears, was502_pme_cf2_win should
be selected. Click Next.
10.Review fixpack installation information and then click Next to begin the fix
pack installation of files.
11.When the WebSphere Application Server V5.0.2 Fixes installation is
Install WebSphere Application Server Cumulative Fix 3

To download and install the WebSphere Application Server V5.0.2 (Base)
Note: More information on the WebSphere Application Server V5.0.2 (Base)

Cumulative Fix 3 (V5.0.2.3), a list of defects fixed, a readme, and the
06289
1. Download the WebSphere Application Server V5.0.2 Cumulative Fix 3
(V5.0.2.3) for Windows (was502_cf3_win.zip) to a temporary directory
289
2. Unpack the cumulative fix download (was502_cf3_win.zip) to a temporary
directory (for example, c:\temp\was502.cf3).
WebSphere Application Server Cumulative Fix 3, we entered the following in
a command window:
c:\temp\was502.cf3\updateWizard.bat
Enterprise V5.0.2.2, and the installation directory

entered c:\temp\was502.cf3\fixpacks in the fix pack directory text field, and
then clicked Next.
9. When the Fix pack to install window appears, was502_cf3_win should be
selected. Click Next.
10.On the install summary page, review fix pack installation information and then
click Next to begin the fix pack installation of files.
11.When the WebSphere Application Server V5.0.2 Cumulative Fix 3 installation
is complete, click Finish.
Install WebSphere Application Server V5.0.2.3 efixes

WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) requires additional
WebSphere Application Server efixes to be installed. The readme file for

WebSphere Portal V5.0.2 Cumulative Fix 1 outlines the efixes required for the
following supported versions of WebSphere Application Server V5.0.2.x:
򐂰 WebSphere Application Server V5.0.2.0
Normally, you would need to download the efixes individually from the
WebSphere Application Server Support Web site. However, there is a file located
on the WebSphere Portal Support Web site that includes all of these efixes and
targets specifically WebSphere Application Server 5.0.2.3 for Windows.
Therefore, we chose to download this file from the following location:
http://www6.software.ibm.com/dl/websphere33/wps-h?S_PKG=dlwps50fp&S_TACT=&S
_CMP=
Note: The WebSphere Portal Support Web site requires you to log in as a
registered user (or register first). Once you navigate to the download page you
will see a listing of many fixes. We downloaded the following file: WAS 5.0.2.3
Fixes (WAS5023CumulativeWindows.zip).
It is important to understand that this package is only intended for use on

Windows with WebSphere Application Server V5.0.2.3. For other versions and
platforms, you will need to contact IBM Support or download the individual
efixes from the WebSphere Application Server Support Web site:
http://www-306.ibm.com/software/webservers/appserv/was/support/
The readme file for WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) can
be found at:
http://publib.boulder.ibm.com/pvc/wp/5021/ent/en/readme/install.html
To download and install the WebSphere Application Server V5.0.2.3 efixes, do

the following:
1. Download the WebSphere Application Server V5.0.2.3 Fixes to a temporary
directory (for example, c:\temp):
– Download the fixes listed in Table 6-7 on page 249 individually from the
WebSphere Application Server V5 Support site at:
http://www-306.ibm.com/software/webservers/support.html
or
– Download the WAS5023CumulativeWindows.zip (contains all required
WebSphere Application Server V5.0.2.3 fixes) available from the Portal
Server 5.0 Fix pack 2 download page at:
http://www-1.ibm.com/support/docview.wss?uid=swg24006309
Note: When you access the above URL, you will first need to click the
Portal Server 5.0 Fix pack 2 link. Next you will need to log in (or
register). You will then see a WAS 5.0.2.3 fixes link to download the
fixes (WAS5023CumulativeWindows.zip).
2. Unpack the efixes download (WAS5023CumulativeWindows.zip) to a

temporary directory (for example, c:\temp\was5023.fixes).
the efixes download, we entered the following in a command window:
c:\temp\was5023.fixes\updateWizard.bat
Enterprise V5.0.2.2, and the installation directory

8. Enter the directory where you have copied the fixes. For example, we entered
c:\temp\was5023.fixes\efixes in the Fix directory text field, and then clicked
Next.
9. When the window appears with a list of fixes, only select the eight fixes listed
in Table 6-7 and then click Next.
Table 6-7 WebSphere Application Server V5.0.2.3 Fixes

Fix description
WAS_Dynacache_01-30-2004_5.0.2_cumulative
PQ78370
PQ81248
PQ81416

WAS_Security_12-12-2003_5.0.2.3-5.0.2.2-5.0.2.1-5.0.2-5.0.1-5.0.0_JSSE_cumulativ
e_Fix
WAS_CM_08-12-2003_5.0.2-5.0.1_cumulative_Fix
WAS_Adapter_10-30-2003_5.0.2_cumulative_Fix
WebSphere Plug-in Cumulative Fix for 5.0.0, 5.0.1, and 5.0.2
Note: If one of the three following fixes is selected, you will receive an error
stating that the fix(es) are not supported on your installed products:
򐂰 PQ75469
򐂰 PQ77008
򐂰 PQ78166
Also, we did not select PQ76567 or PQ79083 since the readme states that
they are included in WAS_Dynacache_01-30-2004_5.0.2_cumulative.
Finally, there are seven remaining efixes that we did not select for two
reasons:
򐂰 They are not required per the WebSphere Portal Server V5.0.2
Cumulative Fix 1 readme file.
򐂰 We tested the selection of all efixes and eventually had problems
running the WPSconfig.bat WP-PTF-5021 configuration task after
installing WebSphere Portal Server V5.0.2 Cumulative Fix 1.
10.On the install summary page, review the fixes to be installed or refreshed and
then click Next to begin the fix pack installation of files.
11.When the WebSphere Application Server V5.0.2.3 Fixes installation is
Verify the WebSphere Application Server V5.0.2

Prior to continuing to the WebSphere Portal V5 Cumulative Fix 1 installation, we
recommend that you verify that the WebSphere Application Server V5.0.2.3 is
working properly.
For details on how to verify the WebSphere Application Server refer to “Verify
WebSphere Application Server V5.0.2” on page 200.
Note: The WebSphere Portal Server will not work with the level of WebSphere
Application Server at this stage. WebSphere Portal will work after applying the
WebSphere Portal Cumulative Fix 1 (V5.0.2.1) in the next section.
6.4.7 WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) installation
This section describes how to download and install a new WebSphere Portal
V5.0.2 Update Installer and the WebSphere Portal V5.0.2 Cumulative Fix 1
(V5.0.2.1).
Note: More information regarding the contents of the WebSphere Portal

V5.0.2 Cumulative Fix 1 can be found at:
http://www-1.ibm.com/support/docview.wss?rs=688&context=SSHRKX&q1=cumulat
ive+fix&uid=swg24006865&loc=en_US&cs=utf-8&lang=en+en
Prepare WebSphere Portal for installation

There are a few prerequisite steps that need to be addressed prior to installing
WebSphere Portal V5.0.2 Cumulative Fix 1. To address the prerequisites, do the
following:
1. Verify that you installed the recommended efixes as discussed in “Install
WebSphere Application Server V5.0.2.3 efixes” on page 247.
2. Ensure that the application servers are stopped:
a. Open a command prompt and change to c:\ibm\websphere\appserver\bin.
b. Issue the following commands:
stopServer server1
stopServer WebSphere_Portal
Proceed with steps 3 and 4 only if you have already configured WebSphere
Portal to IBM HTTP Server. For the ITSO example, we skipped these two
steps since we will not configure the external Web server until “Configure
WebSphere Portal for IBM HTTP Server” on page 264.
3. Stop the IBM HTTP Server.
4. Edit the httpd.conf (C:\ibm\IBMHttpServer\conf), as shown in Example 6-1.
Example 6-1 ITSO Example httpd.conf

##Uncommment the following line
Listen 80
##Comment out the following four lines

#Port 80
#AfpaEnable
#AfpaCache on
#AfpaLogFile “C:\ibm\IBMHttpServer/logs/afpalog” V-EDLF

Note: In our ITSO working example, we have not yet created the
WebSphere Portal databases for DB2; thus the following steps are not
required.
However, for an environment where the WebSphere Portal databases

have already been created in DB2, you can reduce deadlocks with the
WebSphere Portal databases by doing the following:
򐂰 DB2 Version 8.1 FP4 or higher users only:
Use the DB2 command window to enter the following commands on the
DB2 server with DB2 instance owner privileges:
db2set DB2_EVALUNCOMMITTED=YES
db2set DB2_INLIST_TO_NLJN=YES
db2 update db cfg for <portal_db using locklist 1024>
򐂰 All database users:
Connect to the WebSphere Portal database and enter the following
commands on the database server:
CREATE INDEX <portal_db_admin_user>.IX2110D ON
<portal_db_admin_user>.PROT_RES (PARENT_OID, OID)
CREATE INDEX <portal_db_admin_user>.IX2140B ON
<portal_db_admin_user>.LNK_USER_ROLE (ROLE_INST_OID)
Install WebSphere Portal V5.0.2 Cumulative Fix 1

To download and install WebSphere Portal V5.0.2 Cumulative Fix 1, do the
following:
1. Download the following to the <wp_root>\update directory (for example,
c:\ibm\websphere\portalserver\update) on the Portal Server node:
http://www-1.ibm.com/support/docview.wss?rs=688&context=SSHRKX&q1=cumulativ
e+fix&uid=swg24006865&loc=en_US&cs=utf-8&lang=en+en
– WebSphere Portal Update Installer (PortalUpdateInstaller.zip)

This is required to install the WebSphere Portal V5.0.2 Cumulative Fix 1.
– WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) for Windows
(WP_PTF_5021.jar)
Note: From the URL listed, you will have to log in as a registered user (or
register first). Once you navigate to the download page you will see a
listing of many fixes. We downloaded the following:
򐂰 WebSphere Portal Update Installer (PortalUpdateInstaller.zip)
򐂰 Portal 5.0.2 Cumulative Fix 1: (WP_PTF_5021.jar)
2. Unzip the contents of PortalUpdateInstaller.zip to the <wp_root>\update
directory (overwriting any current files if necessary).
3. Change the timeout for the SOAP client (if you have not done so previously):
a. Open the soap.client.props file in <was_home>\properties.
b. Modify the request timeout as follows (default is 180 seconds):
com.ibm.SOAP.requestTimeout=6000
c. Save and close the file.
4. Open a command window and enter the following command to set up the
Java environment for the WebSphere Portal update installer:
C:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat
5. Navigate to the WebSphere Portal update directory:
cd \ibm\WebSphere\PortalServer\update
6. To start the WebSphere Portal update installer, enter the following command:
updatePortal -fixpack -installDir “c:\ibm\WebSphere\PortalServer”
-fixpackDir “c:\ibm\WebSphere\PortalServer\update” -install -fixpackID
WP_PTF_5021
Note: If you have configured WebSphere Application Server V5 security

prior to installing that the WebSphere Portal V5.0.2 Cumulative Fix 1, you
will need to ensure the WasUserid and WasPassword fields are populated
correctly in the <wp_home>\config\wpconfig.properties file before running
the WebSphere Portal V5.0.2 Cumulative Fix 1 update installer.
When the Fixpack is complete, you should see the message Fix pack
installation completed successfully.
If you receive an error, you can review the log information in the
c:\ibm\WebSphere\PortalServer\log directory.
7. Restart the IBM HTTP Server.
8. Open a command window and enter the following command to update the
WebSphere Portal configuration:
Where <password> is the WebSphere Portal administrator password.

Note: Configuration failure/recovery:
If the Update WebSphere Portal configuration task fails, do the following:
1. Correct the cause of the failure.
2. Uninstall the WebSphere Portal V5 Cumulative Fix 1 (uninstall might be
better named as unconfigure; this just unconfigures the failed
configuration) as follows:
WPSconfig.bat UNINSTALL-WP-PTF-5021
3. Rerun the WebSphere Portal configuration task.
For details refer to the WebSphere Portal V5 Cumulative fix readme

(install_win_unix.html) found at:
4. Restart WebSphere Application Server:

cd /ibm/websphere/appserver/bin
stopServer server1
startServer server1
5. Restart WebSphere Portal Server:
startServer WebSphere_Portal
Verify the WebSphere Portal Server

Now that you have installed and configured WebSphere Portal V5 Cumulative
Fix 1 (V5.0.2.1), we recommend that you verify that the WebSphere Portal
Server is working properly.
For details refer to “WebSphere Portal Server verification” on page 231.

The Java Runtime Environment included with IBM WebSphere Application
Server V5.0.2.3 (Base) is incompatible with the SvrSslCfg command included
with the Tivoli Access Manager Java Runtime Environment (PDJRTE). For this
reason, we installed the Java Runtime Environment V1.3.1.
For details refer to 6.2.4, “Java Runtime Environment (JRE) V1.3.1 installation”
on page 192.
6.4.9 Tivoli Access Manager Java Runtime Environment installation
This section describes how to install and configure the following:
򐂰 Install Tivoli Access Manager Java Runtime Environment.
򐂰 Install Tivoli Access Manager V5.1 Base Fixpack 2.
򐂰 Configure PDJRTE for WebSphere Application Server JRE.
򐂰 Configure PDJRTE for standalone JRE V1.3.1.
Install Tivoli Access Manager Java Runtime Environment

To install and configure the Tivoli Access Manager Java Runtime Environment
(PDJRTE) using the native installation utility, do the following on the Portal
Server node:
1. Ensure that the following Windows services are started on the Policy Server
node:
2. Insert the Tivoli Access Manager Base for Windows NT, Windows XP,
Windows 2000 and Windows 2003 CD.
and run Setup.exe to start the installation.
6. When the License Agreement window appears, if in agreement click Yes to
continue.
package and then clicked Next:
– Check Access Manager Java Runtime Environment (PDJRTE).
– Uncheck all other packages.
8. Choose the destination folder (for example, c:\ibm\Tivoli\tam) and click Next.
9. Review your settings and click Next.
10.When the installation is complete you should see a dialog with the message
Installation completed successfully. Click OK to exit.

Install Tivoli Access Manager V5.1 Base Fixpack 2
Fixpack 2 will update the Tivoli Access Manager Java Runtime Environment.
Install the fix pack by performing the following steps:
1. Download Tivoli Access Manager V5.1 Base Fixpack 2 from the following
URL to a temporary directory (for example, c:\temp\tam51.fp2) on the Portal
Server node:
ll
Note: If you have already downloaded this fixpack for your TAM installation
on the Policy Server node, you can use it for this node as well.
example, c:\temp\tam51.fp2), and run 5.1-TAM-FP02-WIN.exe to start the
Access Manager V5.1 Fixpack Setup (5.1.0.2).
5. When the installation is complete, click Finish.
Configure PDJRTE for WebSphere Application Server JRE

To configure the Tivoli Access Manager Java Runtime Environment (PDJRTE)
for the WebSphere Application Server JRE, do the following on the Portal Server
node:
Note: This configuration is needed so that the WebSphere Application Server

can use the Tivoli Access Manager APIs.
1. Open a command window and navigate to the c:\ibm\Tivoli\tam\sbin directory.

2. Enter the following command:
pdjrtecfg -action config -config_type full -host tamwin1.itso.ral.ibm.com
-port 7135 -java_home c:\ibm\WebSphere\AppServer\java\jre
Configuration of Access Manager Java Runtime Environment completed
successfully.
Configure PDJRTE for standalone JRE V1.3.1
for the standalone JRE V1.3.1, do the following Portal Server node:
Note: The Java Runtime Environment included with IBM WebSphere

Application Server V5.0.2.3 (Base) is incompatible with the SvrSslCfg
command (used in 7.6.1, “Configure the SSL between WebSphere and TAM”
on page 322).
For this reason, we installed the Tivoli Access Manager Java Runtime
Environment V1.3.1 and configured the Tivoli Access Manager Java Runtime
Environment (PDJRTE) to use the standalone JRE V1.3.1.
1. Open a command window and navigate to the c:\ibm\Tivoli\TAM\sbin

directory.
pdjrtecfg -action config -config_type full -host tamwin1.itso.ral.ibm.com
-port 7135 -java_home c:\ibm\Java131\jre
successfully.
6.4.10 DB2 Universal Database installation

By default, the WebSphere Portal V5.0.2 uses the Cloudscape database. As part
of the ITSO runtime environment, we will configure WebSphere Portal to use
DB2 UDB instead of Cloudscape (see 7.1, “Configure WebSphere Portal for
DB2” on page 261).
For details on installing a DB2 Server refer to 6.2.2, “DB2 Universal Database
installation” on page 184.

7
Chapter 7. Configure the runtime

environment
As an extension of Chapter 6, “Install the runtime environment” on page 175, this
chapter describes the configuration tasks to integrate and secure Tivoli Access
Manager and WebSphere Portal components on the three nodes (Reverse Proxy
node, Portal Server node, Policy Server node) for the ITSO runtime environment.
This chapter is organized into the following configuration sections:

򐂰 Configure WebSphere Portal for DB2.
򐂰 Configure WebSphere Portal for IBM HTTP Server.
򐂰 Configure WebSphere Portal for LDAP.
򐂰 Enable mutual SSL between WebSEAL and WebSphere Portal.
򐂰 Configure portal authentication with TAM using TAI.
򐂰 Configure Portal for authorization with TAM.
򐂰 Integrate the Credential Vault.
򐂰 Additional configuration.

Note: The WebSphere Portal and Tivoli Access Manager products can be
configured in part using the WebSphere Portal Tivoli Access Manager
Configuration Wizard, or by performing the tasks manually. Using the
Configuration Wizard is useful in some scenarios.
For the ITSO scenario, we found that the Configuration Wizard did not perform
many of the configuration tasks we needed for our environment; thus we
configured the environment manually. By performing the configuration
manually, we are able to describe what the configuration tasks accomplish,
demonstrate by example configuration options and procedures, and provide
verification steps before proceeding.
Information on the IBM WebSphere Portal Tivoli Access Manager

Configuration Wizard Version 1.0 can be found at:
http://www-106.ibm.com/developerworks/websphere/zones/portal/catalog/doc/
1wp10004g/index.html
7.1 Configure WebSphere Portal for DB2
This section describes how to configure and verify WebSphere Portal V5.0.2.1 to
use DB2 UDB V8.1 in place of the default Cloudscape database.
To configure WebSphere Portal to use DB2 UDB V8.1, do the following:

1. Ensure that you have installed DB2 UDB V8.1 Server on the Portal Server
node.
This task should have been completed as part of the runtime installation. For
details refer to 6.4.10, “DB2 Universal Database installation” on page 257.
2. Open a command window and navigate to the <wp_home>\config directory.
3. Back up the WebSphere Portal configuration properties found in the
wpconfig.properties file by entering the following command:
wpsconfig backup-main-cfg-file
After the wpsconfig command is run, you should see a backup of the
wpconfig.properties file with a time stamp in the <wp_home>\config directory.
Note: The backup configuration procedure should be run prior to further

configuration tasks such as configuring security, externalizing the Web
server, or transferring the database (as is the case for our example).
The wpconfig.properties file is a configuration input file used by wpsconfig

to load configuration settings for WebSphere Portal (stored in XML files).
4. Export the WebSphere Portal configuration data found in the Cloudscape

database by entering the following command:
wpsconfig database-transfer-export
When complete you should get the message BUILD SUCCESSFUL.
5. Modify the wpconfig.properties file to configure WebSphere Portal to use DB2
UDB. Refer to Table 7-1 on page 262 for the configuration settings used in the
ITSO example. For a detailed description of each of the keywords refer to the
WebSphere Portal InfoCenter found at (search on Configuring WebSphere
Portal for DB2):
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html
Chapter 7. Configure the runtime environment 261

Table 7-1 WebSphere Portal configuration settings in wpconfig.properties for DB2
Section of Keyword ITSO value
wpconfig.properties file
Database properties DbSafeMode false
DbType db2
WpsDbName wps50
DbDriver COM.ibm.db2.jdbc.app.DB2Driver
DbDriverDs COM.ibm.db2.jdbc.DB2XADataSource
DbUrl jdbc:db2:wps50
DbUser db2admin
DbPassword <your_dbuser_password>
DbLibrary c:/ibm/sqllib/java/db2java.zip
Note: Directory is java ,not java12
WpsDsName wps50DS
WpsXDbName wps5TCP
WpsDbNode wpsNode
WebSphere Portal WpcpDbNode wcmNode

content publishing
Database properties WpcpXDbName wpcp5TCP
FeedbackXDbName fdbk5TCP
WpcpDbName wpcp50
Note: Seperate database
WpcpDbUser db2admin
WpcpDbPassword <your_dbuser_password>
WpcpDbUrl jdbc:db2:wpcp50
WpcpDbEjbPassword <ejb_password> (user defined)
FeedbackDbName fdbk50
FeedbackDbUser db2admin
FeedbackDbPassword <your_dbuser_password>
FeedbackDbUrl jdbc:db2:fdbk50
Section of Keyword ITSO value
Member Manager WmmDsName wmmDS

properties
WmmDbName wps50
WmmDbUser db2admin
WmmDbPassword <your_dbuser_password>
WmmDbUrl jdbc:db2:wps50
Note: As an alternative to storing the passwords in the wpconfig.properties

file, the values can be left blank in the file and specified with a -D
parameter when running the WPSconfig.bat.
6. Save the updated wpconfig.properties file.

7. Create databases.
If you are using a local DB2 database (true for the ITSO example), you can
automatically create your databases by typing the following command:
WPSconfig.bat create-local-database-db2
Note: If you are using a remote DB2 database, ensure that your databases
have been created manually. Refer to the WebSphere Portal InfoCenter
(search on Setting up DB2).
8. Validate configuration properties.

From the <wp_home>/config directory, enter the following commands to
validate the configuration properties:
WPSconfig.bat validate-database-connection-wps -DDbPassword=<password>
WPSconfig.bat validate-database-connection-wmm -DWmmDbPassword=<password>
WPSconfig.bat validate-database-connection-wpcp -DWpcpDbPassword=<password>
-DFeedbackDbPassword=<password>
WPSconfig.bat validate-database-driver
Note: The -D parameter on the validate-database-connection commands

is only necessary if you do not have the database passwords in the
wpconfig.properties. In the ITSO example, we left off this parameter.
9. Import the database settings.

If the validation runs correctly, enter the following commands to run the
configuration task to import the database settings:
WPSconfig.bat database-transfer-import
10.After importing the database tables, perform a reorg check to improve
performance.
a. Open a DB2 command window.
b. Run the following commands from the DB2 command window for each
WebSphere Portal database (for example, wps50, wpcp50, fdbk50):
db2 connect to <database_name>
db2 reorgchk update statistics on table all
db2 terminate
db2rbind <database_name> -l db2rbind.out -u <db2_admin> -p <password>
11.Start the WebSphere Portal server as follows:
12.Verify WebSphere Portal for DB2 configuration.
To verify the WebSphere Portal for DB2 UDB configuration, refer to
“WebSphere Portal Server verification” on page 231.
7.2 Configure WebSphere Portal for IBM HTTP Server

We now reconfigure WebSphere Portal Server to use an external Web server
instead of the internal HTTP service of the WebSphere Application Server. For
our example, we used IBM HTTP Server as our external Web server.
Note: This section does not apply to runtime topologies such as the
development WebSphere Test Environment or a runtime environment
architected not to include an external Web server.
To configure an external IBM HTTP Server for WebSphere Portal in place of the
WebSphere Application Server internal HTTP service, do the following:
1. Verify that the IBM HTTP Server is started.
2. Navigate to the <wp_home>\config directory.
4. Change the wpconfig.properties values as seen in Table 7-2 on page 265. For
a detailed description of each of the keywords refer to the WebSphere Portal
InfoCenter found at (search on Configuring your Web server) go to:
Table 7-2 ITSO example wpconfig.properties values for external Web server
Section in wpconfig.properties file Keyword ITSO example value
WebSphere Application Server WpsHostName wpwin1.itso.ral.ibm.com
WpsHostPort 80

6. Enter the following command to configure WebSphere Portal Server for the
external Web server:
wpsconfig httpserver-config
8. Restart the WebSphere Portal Server:
a. Open a command prompt change to the WebSphere Application Server
bin directory:
b. Confirm that the WebSphere Portal Server is stopped:
c. Wait for confirmation that the server instance is stopped or cannot be
reached. Then start the server:
9. Verify that WebSphere Portal works properly with the external Web server.
You should be able to browse your WebSphere Portal Server using the
external Web server hostname:
http://wpwin1.itso.ral.ibm.com/wps/portal
Note: Prior to adding the external Web server, you needed to include the
port number 9081 for the internal HTTP transport the WebSphere Portal
Server was using in the URL. For example,
Now that we have configured the external Web server, we do not need to
specify the port (default port 80) in the URL:

7.3 Configure WebSphere Portal for LDAP
This section describes how to configure WebSphere Portal with the Tivoli
Directory Server (LDAP). We will first connect WebSphere Portal to the
previously installed Tivoli Directory Server on the Policy Server node. In addition,
we will create users and groups for the ITSO environment.
The section is organized into the following tasks:

򐂰 Create a suffix.
򐂰 Create LDIF file containing users and groups.
򐂰 Import the LDIF file (wp-itso.ldif) to create users and groups.
򐂰 Enable LDAP security for WebSphere Portal.
򐂰 Verify the LDAP configuration.
Note: For more detailed information, refer to the WebSphere Portal V5.0.2
InfoCenter at:
Search on the following within the InfoCenter:

򐂰 Setting up IBM Directory Server
򐂰 Configuring WebSphere Portal for IBM Directory Server
7.3.1 Create a suffix

To create a suffix from the Tivoli Directory Server - Configuration Tool, do the
following on the Policy Server node, where the Tivoli Directory Server is installed:
1. Stop the Tivoli Directory Server V5.2 Windows service.
2. Start the Tivoli Directory Server - Configuration Tool by clicking Start →
Programs → IBM Tivoli Directory Server V5.2 → Directory
Configuration.
3. Select Manage suffixes under Choose a task.
4. On the suffix page, we entered the following for the ITSO example and then
clicked Add:
Suffix DN: dc=itso,dc=ibm,dc=com
5. Click OK.
7.3.2 Create LDIF file containing users and groups
Users and groups can be created for the Tivoli Directory Server from the Web
Administration Tool or by importing an LDIF file containing users and groups. The
main structure of the wp-itso.ldif file is displayed in Figure 7-1 on page 267.
dc=itso,dc=ibm,dc=com
cn=users cn=groups
uid=wpsadmin uid=wpsbind cn=wpsadmins
Figure 7-1 LDAP structure to be used in the ITSO example
For the ITSO working example, we created the wp-itso.ldif based on the
PortalUsers.ldif file found on the WebSphere Portal Setup CD. We have included
the wp-itso.ldif file in the ITSO sample code c:\6325code\config\ldap directory
(see Example 7-1).
We changed the DN. We recommend that you change the userpassword

attribute for users wpsadmin and wpsbind to a unique password.
Example 7-1 ITSO example WebSphere Portal LDIF file (wp-itso.ldif)

version: 1
# ITSO example: wp-itso.ldif file
dn: dc=itso,dc=ibm,dc=com
objectclass: domain
objectclass: top
# Add lines according to this scheme that correspond to your suffix
dc: itso,dc=ibm,dc=com
dc: itso,dc=ibm
dc: itso
dn: cn=users,dc=itso,dc=ibm,dc=com
objectclass: container
objectclass: top
cn: users

dn: cn=groups,dc=itso,dc=ibm,dc=com
objectclass: top
objectclass: container
cn: groups
dn: uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: wpsadmin
userpassword: wpsadmin
sn: admin
givenName: wps
cn: wps admin
dn: uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
objectclass: top
objectclass: person
uid: wpsbind
userpassword: wpsbind
sn: bind
givenName: wps
cn: wps bind
dn: cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com
objectclass: groupOfUniqueNames
objectclass: top
uniquemember: uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com
cn: wpsadmins
7.3.3 Import the LDIF file (wp-itso.ldif) to create users and groups
To import the ITSO-provided wp-itso.ldif file to create users and groups to the
Tivoli Directory Server, do the following on the Policy Server node (where Tivoli
Directory Server is installed in our example):
1. Stop the IBM Tivoli Directory Server V5.2 Windows service.
2. Copy the ITSO-provided c:\6325code\config\ldap\wp-itso.ldif file to a
temporary directory where Tivoli Directory Server is installed (for example,
c:\temp).
3. Start the Tivoli Directory Server Configuration Tool by clicking Start →
Configuration.
4. Select Import LDIF data.
5. When the Import LDIF Data page appears, we entered the following and then
clicked Import (bottom of page):
– Path and LDIF file name: c:\temp\wp-itso.ldif
– Select Standard import.
After the import has finished successfully, a message will be displayed
reporting how many entries have been imported into the directory server.
6. When the import is complete, click Close. Close the Configuration Tool.
7. Restart the IBM Tivoli Directory Server V5.2 Windows service.
8. Verify that the LDAP entries where created properly by performing an LDAP
search. For example, we entered the following from a command window on
the Policy Server node:
ldapsearch -h tamwin1 -b dc=itso,dc=ibm,dc=com -D
uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com -w its0ral0 -s sub uid=wpsadmin
7.3.4 Enable LDAP security for WebSphere Portal

This section describes how to enable LDAP security for WebSphere Portal.
Configure WebSphere Portal for read-only LDAP access

For the ITSO example, we have chosen to prevent WebSphere Portal from
writing to the LDAP directory. We will only allow Tivoli Access Manager to write
to the LDAP directory to ensure consistency and increase security. However, the
default configuration for WebSphere Portal is not set up for read-only LDAP
access. Therefore, we must configure WebSphere Portal for read-only LDAP
access.
Note: If you are running WebSphere Portal 5.0 or 5.0.2, you will need to install
PQ83389 before proceeding. More information on this fix for WebSphere
Member Manager can be found at:
http://www-1.ibm.com/support/docview.wss?rs=688&context=SSHRKX&q1=PQ83389
&uid=swg24006269&loc=en_US&cs=utf-8&lang=en+en
However, since WebSphere Portal 5.0.2 Cumulative Fix 1 contains PQ83389,

we may proceed for the ITSO example.

To configure WebSphere Portal for read-only LDAP access, do the following:
1. Navigate to the c:/ibm/WebSphere/PortalServer/config/templates/wmm
directory on the Portal Server node.
Note: Development environment: Change to the following directory on the

Development node:
c:/ibm/wsad/runtimes/portal_v50/config/templates/wmm
2. Back up the following files:

– wmm_LDAP.xml.<LDAPType>.<number>.wmm
(for example, wmm_LDAP.xml.IBM_DIRECTORY_SERVER.1.wmm)
– wmmLDAPAttributes_<LDAPType>.xml
(for example, wmmLDAPAttributes_IBM_DIRECTORY_SERVER.xml)
Note: Explanation of naming constructs for wmm xml files:

򐂰 <LDAPType> is the type of LDAP server that is being used, such as
IBM_DIRECTORY_SERVER or DOMINO502.
򐂰 <number> specifies whether a lookaside database is implemented. Use
1 if a lookaside database is not defined or 3 if the lookaside database is
defined.
3. Modify the attributes in the

wmm_LDAP.xml.IBM_DIRECTORY_SERVER.1.wmm file. Search for the
<ldapRepository tag section of the file, and modify the values as seen in
Example 7-2.
Example 7-2 ITSO example wmm_LDAP.xml.IBM_DIRECTORY_SERVER.1.wmm (snippet)

<ldapRepository name="wmmLDAP"

wmmGenerateExtId="false"
ignoreReadOnlyUpdate="true"
supportGetPersonByAccountName="true"
profileRepositoryForGroups="LDAP1"
supportTransactions="false"
adminId="@LDAPAdminUIdXml@"
adminPassword="@EncryptedLDAPAdminPwd@"
ldapHost="@LDAPHostName@"
ldapPort="@LDAPPort@"
ldapTimeOut="6000"
ldapAuthentication="SIMPLE"
ldapType="0"
groupCacheRefreshInterval="-1">
</ldapRepository>
4. Save the file.

5. Modify the attributes in the
wmmLDAPAttributes_IBM_DIRECTORY_SERVER.xml file. Search for
wmmAttributeName=”extId” and modify the pluginAttributeName attribute as
shown in Example 7-3.
6. Set the readOnly attribute to true in every attributeMap tag as shown in
Example 7-3. If an attributeMap tag does not contain a readOnly attribute, you
will need to add it.
Example 7-3 ITSO wmmLDAPAttributes_IBM_DIRECTORY_SERVER.xml (snippet)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE repositoryAttributes SYSTEM "wmmAttributesMap.dtd">
<repositoryAttributes repositoryName="wmmLDAP">

<attributeMap wmmAttributeName="extId"

pluginAttributeName="ibm-entryUuid"
dataType="String"
multiValued="false"
readOnly="true"/>

<attributeMap wmmAttributeName="groupMember"
pluginAttributeName="@LDAPGroupMember@"
applicableMemberTypes="Group"
dataType="String"
valueLength="1024"
multiValued="true"
readOnly="true" 
defaultValue="uid=dummy" />

</repositoryAttributes>
7. Save the file.
Configure WebSphere Portal for security with LDAP

On the Portal Server node, there are pre-configured templates that can be
customized to configure WebSphere Portal for LDAP.
1. Open a command prompt and navigate to the <wp_home>\config directory.

Note: Development environment: Within the development environment
(WebSphere Studio Application Developer and WebSphere Portal toolkit)
this is the c:\ibm\wsad51\runtimes\portal_v50\config directory.
The file named wpconfig.properties contains the properties to be changed

when changing the authentication mechanism. Make a backup copy of this
file and edit the original file in portal_v50\config.

3. Change the wpconfig.properties values as seen in Table 7-4 on page 273. For
a detailed description of the wpconfig.properties for LDAP security
configuration with WebSphere Portal refer to the InfoCenter at (search on
Configuring WebSphere Portal for IBM Directory Server):
Example 7-4 ITSO example wpconfig.properties values for LDAP security
Section in Keyword ITSO example value
WebSphere Application WasUserid uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com

Server Properties
WasPassword <password>
Portal Configuration PortalAdminId uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com

Properties
PortalAdminIdShort wpsadmin
PortalAdminPwd <password>
PortalAdminGroupId cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com
PortalAdminGroupId wpsadmins
Short
WebSphere Portal LTPAPassword <password>

Security LTPA and SSO
Configuration LTPATimeout 120
SSODomainName itso.ral.ibm.com
LDAP Properties Lookaside false

Configuration
LDAPHostName tamwin1.itso.ral.ibm.com
LDAPPort 389
LDAPAdminUId uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
LDAPAdminPwd <password>
LDAPServerType IBM_DIRECTORY_SERVER
LDAPBindID uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
LDAPBindPassword <password>

Advanced LDAP LDAPSuffix dc=itso,dc=ibm,dc=com

Configuration
LdapUserPrefix uid
LDAPUserSuffix cn=users
LdapGroupPrefix cn
LDAPGroupSuffix cn=groups
LDAPUserObjectCla inetOrgPerson
ss
LDAPGroupObjectCl groupOfUniqueNames
ass
LDAPGroupMember uniqueMember
LDAPUserFilter (&(uid=%v)(objectclass=inetOrgPerson))
LDAPGroupFilter (&(cn=%v)(objectclass=groupOfUniqueNames))
LDAPsslEnabled false
Note: If you are not using an external HTTP server, you will want to set the
WpsHostName property in the wpconfig.properties file. For example:
WpsHostName=wpwin1.itso.ral.ibm.com
5. Change to the <was_home>\bin directory and enter the following commands:

startServer server1
6. Change to the <wp_home>\config directory and enter the following
command:
WPSconfig.bat validate-ldap
If an error occurs, review the values in the wpconfig.properties (typographical
errors are quite often the cause of an error on this step) and the settings in the
LDAP server. Also, ensure that the LDAP server is actually running.
7. If the validation was successful enable security by issuing the following
command:
WPSconfig.bat enable-security-ldap
If the task completes successfully, you will see the message BUILD
SUCCESSFUL.
Note: You may receive the following error when running the configuration
task to enable security:
action-create-deployment-credentials:
[xmlaccess] XMLA0006I: Connecting to URL
http://localhost:9081/wps/config
[xmlaccess] XMLA0002I: Reading input file
C:\ibm\WebSphere\PortalServer\config\work\createDeploymentCredentials.
xml
[xmlaccess] XMLA0011I: Request was accepted.
[xmlaccess] <?xml version="1.0" encoding="UTF-8" ?>
[xmlaccess] <failure>
[xmlaccess]
com.ibm.wps.command.xml.XmlCommandServlet$AuthorizationException:
XMLC0005E: Authorization for user wpsadmin failed.
[xmlaccess] </failure>
. . . .
BUILD FAILED
file:../config/actions/wps_cfg.xml:289: XMLA0015E: Server response
indicates an error.
If you have received this error, it usually means that the following two items
are true:
򐂰 Your LDAPAdminUId does not have write permissions to the LDAP
server.
򐂰 Your Portal server is not configured for read-only access.
Therefore, you must either give your LDAPAdminUId (as defined in the
wpconfig.properties) write permissions via the LDAP server administration
interface, or you can configure your WebSphere Portal server for read-only
access as we have done in the ITSO example in “Configure WebSphere
Portal for read-only LDAP access” on page 269.
8. Change to the <wp_home>\config directory and enter the following

commands:
stopServer server1 -user wpsbind -password <password>
Where wpsbind is the WebSphere Administrator user ID and <password> is
the password for the user ID.
startServer server1

7.3.5 Verify the LDAP configuration
To verify the WebSphere Portal and LDAP configuration, do the following:
1. Verify that WebSphere security is working properly by starting the
WebSphere Application Server Administration Console and log in as user ID
wpsbind. WebSphere security in this case provides the authentication. If
security was not working, you would not be able to log in with the wpsbind
user ID.
http://wpwin1.itso.ral.ibm.com:9090/admin
2. Verify that WebSphere Portal works properly with the LDAP configuration and
WebSphere security.
a. If everything works properly, you should be able to browse your
WebSphere Portal Server using the fully qualified hostname, which is now
configured to use LDAP:
Important: Using localhost or just the hostname for accessing the

portal might cause problems after configuring LDAP security. Always
use the fully qualified hostname for browsing.
b. From the WebSphere Portal Welcome page, click Log in at the top right
corner (for example, we used the wpsadmin user ID and password).
Note: For information on disabling LDAP security for WebSphere Portal, refer
to “Disabing global security for WebSphere Application Server” on page 583.
7.4 Enable mutual SSL between WebSEAL and

WebSphere Portal
The ITSO example architecture uses an external IBM HTTP Server for
WebSphere Portal on the Portal Server node. This section describes how to
configure mutual SSL between the WebSEAL on the Reverse Proxy node and
the IBM HTTP Server on the Portal Server node.
In our example, we have two fundamental requirements. First, we want to

provide access for some pages to unauthenticated users. Second, we do not
want to create two seperate junctions for authenicated and unauthenticated
users. For these reasons and limitations when creating a WebSEAL junction, we
needed to enable mutual SSL for the type of junction needed.
1. IBM HTTP Server SSL configuration.
2. Configure WebSphere Portal for SSL.
3. Export IBM HTTP Server CA certificate.
4. Import IBM HTTP Server certificate into WebSEAL keystore.
5. Export WebSEAL certificate.
6. Import WebSEAL certificate into IBM HTTP Server keystore.
7. Enable mutual SSL for IBM HTTP Server.
7.4.1 IBM HTTP Server SSL configuration

This section describes how to configure SSL for the IBM HTTP Server, and is
organized into the following tasks:
򐂰 Enable the httpd.conf for SSL.
򐂰 Copy WebSphere plug-in entries to the httpd.conf.
򐂰 Create the IBM HTTP Server keystore.
򐂰 Verify IBM HTTP Server.
Enable the httpd.conf for SSL

To modify the httpd.conf to enable SSL support, do the following:
1. Stop the IBM HTTP Server V1.3.26 Windows service.
2. Back up the original httpd.conf. For example:
cd \<ihs_home>\conf
copy httpd.conf httpd.conf.org
3. Copy the httpd.conf.sample (located in current directory) containing the
commented SSL directives to httpd.conf (overwrite the existing file). For
example:
copy httpd.conf.sample httpd.conf
4. Open the <ihs_home>\conf\httpd.conf file with a text editor.
5. Search for the following lines, uncomment the # symbol, and modify the
settings as described:
– Verify the ServerName value, which should include your fully qualified
hostname (for example, wpwin1.itso.ral.ibm.com):
ServerName <fully_qualified_hostname>
– Uncomment the IBM SSL module for the given SSL encryption level (56 or
128 bit). For example:
LoadModule ibm_ssl_module/IBMModuleSSL128.dll

Note: 56 or 128 is the appropriate encryption level for your locale, for
example, 128 for 128-bit encryption in the US and Canada.
– Uncomment the following line to listen on port 443 for HTTPS:

Listen 443
– Uncomment and update the VirtualHost with your hostname as follows:
<VirtualHost hostname.domain.com:443>
Note: Substitute your fully qualified host name in this line (for example,
<VirtualHost wpwin1.itso.ral.ibm.com:443>).
– Uncomment:
SSLEnable
– Uncomment:
</VirtualHost>
– Uncomment and update the following:
Keyfile "c:\ibm\IBMHttpServer/ssl/keyfile.kdb"
Note: The keyfile path has been modified to include ssl instead of keys.
For example:
Keyfile "c:\ibm\IBMHttpServer/ssl/keyfile.kdb"
– Uncomment:
SSLV2Timeout 100
SSLV3Timeout 1000
6. Save the changes to the httpd.conf file.
Copy WebSphere plug-in entries to the httpd.conf

During the installation of the IBM HTTP Server and WebSphere plug-in, the
httpd.conf was updated with the plug-in entries. Now that we have copied the
httpd.conf.sample in the previous section to enable the SSL directives, we now
also need to add the WebSphere plug-in entries to the httpd.conf.
1. Change to the directory the IBM HTTP Server <ihs_home>\conf directory.
2. Modify the httpd.conf, and add the following for the WebSphere plug-in at the
end of the file:
LoadModule ibm_app_server_http_module
"c:\ibm\WebSphere\AppServer/bin/mod_ibm_app_server_http.dll"
WebSpherePluginConfig
"c:\ibm\WebSphere\AppServer/config/cells/plugin-cfg.xml"
Tip: The above text is two separate lines. Within the httpd.conf, the lines
are not wrapped.
If you backed up the httpd.conf.org, you can cut and paste the plug-in
entries to the SSL-enabled httpd.conf.
3. Save and close the httpd.conf file.
Create the IBM HTTP Server keystore

To create the IBM HTTP Server keystore database used to store certificates, do
the following:
1. From Windows, click Start → Programs → IBM HTTP Server 1.3.26 →
Start Key Management Utility.
2. From the menu bar, click Key Database File → New.
3. In the New window, enter the following and then click OK:
– Key Database Type: CMS key database file
– File name: keyfile.kdb
– Location: <ihs_home>\ssl (for example, c:\ibm\IBMHttpServer\ssl)
Note: This path must match the keyfile path in the httpd.conf.
4. In the Password Prompt window, enter the following and then click OK:
– Password: <your_password> (to protect the keystore file)
– Check Set expiration time? and enter the number of days before the
password will expire. If no expiration is required, do not check this.
Note: Although not required in a development environment, it is

recommended that all keystores used in production environments set
an expiration period.
– Check Stash the password to a file.
Note: The IBM HTTP Server accesses the password-protected keystore.
5. When the information window appears with the following message, click OK:
The password has been encrypted and saved in file:

c:\ibm\IBMHttpServer\ssl\keyfile.sth
Create a certificate for the IBM HTTP Server

For development and testing purposes, we will create a new self-signed
certificate. The following steps outline the creation of a new self-signed
certificate:
1. From the Key Management Utility menu bar, select Create → New
Self-Signed Certificate.
If you closed the Key Management Utility, you will first need to open the
keystore first.
2. Fill in the information on the form and click OK. For example, we entered the
following:
– Key Label: WP HTTP Server SSL Key
– Common Name: <fully_qualified_hostname>
– Organization: IBM
Note: The organization name is used when specifying the -D parameter in

the wp-junction.pd command file to create the junction. The value is case
sensative.
3. When done, close the Key Management Utility.
Verify IBM HTTP Server

After the IBM HTTP Server SSL configuration, we recommend that you complete
the following verification tests:
򐂰 Start IBM HTTP Server.
򐂰 Verify the IBM HTTP Server.
Start IBM HTTP Server

The IBM HTTP Server service can be started by one of the following methods:
򐂰 IBM HTTP Server 1.3.26 Windows service
or
򐂰 From the command line or batch file containing the following:
net start “IBM HTTP Server 1.3.26”
Verify the IBM HTTP Server
To verify that the IBM HTTP Server is working properly, enter the following URLs
in a Web browser after the IBM HTTP Server has been started:
򐂰 Verify HTTP:
http://<hostname>
򐂰 Verify HTTPS:
https://<hostname>
7.4.2 Configure WebSphere Portal for SSL

This section describes how to enable SSL for WebSphere Portal on the Portal
Server node. In this example we will configure the WebSphere Application
Server, where WebSphere Portal is installed, to be SSL enabled and update the
WebSphere Portal configuration for SSL.
Enable SSL for the WebSphere Application Server

Configure the WebSphere Application Server plug-in for the Web server to
forward WebSphere Portal traffic that is received over SSL to WebSphere
Application Server (which will then forward the traffic to WebSphere Portal).
Update the virtual host list for WebSphere Application Server to include the
correct host name and port number, and regenerate the plug-in configuration.
Note: For more information regarding WebSphere Application Server security,

refer to the IBM WebSphere V5.0 Security, WebSphere Handbook Series,
SG24-6573, redbook.
To enable SSL for the WebSphere Application Server where WebSphere Portal
is installed, do the following:
1. Ensure that the WebSphere Application Server server1 is started on the
Portal Server node.
2. Start the WebSphere Application Server Administrative Console:
a. Enter the URL:
https://wpwin1.itso.ral.ibm.com:9043/admin
b. Enter WebSphere administrator credentials (for example, wpsbind).
3. Select Environment → Virtual Hosts.
4. Click default_host.
5. Click Host Aliases.
6. To add a Host Alias for port 443, click New.

7. When the New Host Alias page appears, enter the following and then click
OK:
– Host Name: *
– Port: 443
8. Click Save.
9. When the Save to Master Configuration page appears, click Save.
10.Select Environment → Update Web Server Plugin.
11.When prompted to update the plug-in configuration file, click OK.
12.Log out of the WebSphere Application Server Administrative Console.
Note: In our example, the IBM HTTP Server and plugin-cfg.xml are installed
on the same node as the WebSphere Application Server. The plugin-cfg.xml is
reloaded with the updated settings based on the RefreshInterval set in the
plugin-cfg.xml. By default, it is set to refresh after 60 seconds. If you want this
to take effect immediately, restart the IBM HTTP Server.
Enable SSL in the WebSphere Portal configuration

In our example, since we are using Tivoli Access Manager WebSEAL for
authentication, we will disable WebSphere Portal login pages in 7.5.11,
“Configure Portal login/logout for use with WebSEAL” on page 313.
To enable SSL in the WebSphere Portal configuration, do the following:

1. Navigate to the following directory:
c:\ibm\WebSphere\AppServer\installedApps\wpwin1\wps.ear\wps.war\WEB-INF
2. Back up web.xml to web.xml.org.
3. Modify the web.xml as seen in Example 7-5. Search on SecurityConstraint_1
to find the appropriate section to modify. Inside the SecurityConstraint_1
definition change the <transport-guarantee> setting from NONE to
CONFIDENTIAL.
Note: The CONFIDENTIAL transport_guarantee will only allow https

access to the /myportal/* URLs.
Example 7-5 ITSO modified web.xml for WebSphere Portal

<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name></web-resource-name>
<url-pattern>/myportal/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<description></description>
<role-name>All Role</role-name>
</auth-constraint>
<user-data-constraint id="UserDataConstraint_4">
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
4. Save and close the web.xml file.

5. Restart the WebSphere_Portal application server.
Verify WebSphere Portal SSL configuration

Once the configuration is complete, we recommend that you verify that the
WebSphere Portal Server is SSL enabled by entering the following URL in a
Web browser:
https://wpwin1.itso.ral.ibm.com/wps/myportal
Log in with the wpsadmin user ID and password. Verify that the Welcome page is
displayed.
7.4.3 Export IBM HTTP Server CA certificate

In our example, we used a self-signed certificate for the IBM HTTP Server. This
section explains how to export the Certificate Authority (CA) certificate that will
be imported into the WebSEAL keystore for the purpose of setting up SSL
junctions. Use the following procedure for exporting the certificate:
1. Start the IBM Key Management Utility on the Portal Server node by clicking
Start → Programs → IBM HTTP Server 1.3.26 → Start Key Management
Utility.
2. From the menu bar select Key Database File → Open.
3. Select the c:\ibm\IBMHttpServer\ssl\keyfile.kdb and click Open.
Note: The key database file, also known as a keystore or keyring, is

defined in the <ihs_home>\conf\httpd.conf file. Search for Keyfile (for
example, Keyfile "c:\ibm\IBMHttpServer/ssl/keyfile.kdb").

4. When prompted enter the password for the keystore.
5. Under Personal Certificates, select the certificate you created in “Create a
certificate for the IBM HTTP Server” on page 280 (for example, WP HTTP
Server SSL Key), as shown in Figure 7-2 on page 284.
Figure 7-2 IHS keyfile
6. Click Extract Certificate.

7. When the Extract Certificate to a File window appears, we entered the
following and then clicked OK:
– Data Type: Select Base64-encoded ASCII data (default).
– Certificate file name: wp_httpd_cert.arm
– Location: c:\ibm\IBMHttpServer\ssl\
8. You should see the following message on the status bar:
The requested action has successfully completed.
9. Close the Key Management Utility.
7.4.4 Import IBM HTTP Server certificate into WebSEAL keystore

In our example, the JRE, GSKit and WebSEAL are installed on the Reverse
Proxy node. By default, the JRE (java.security) does not include the IBM JCE
and IBM CMS security providers. As part of our configuration of the GSKit
iKeyman utility, we added the IBM JCE and IBM CMS security providers (see
“Configure GSKit iKeyman utility” on page 225).
This section describes how to import the IBM HTTP Server certificate into the
WebSEAL keystore on the Reverse Proxy node.
1. Ensure that you have added the IBM CMS security provider to the
java.security file (see “Configure GSKit iKeyman utility” on page 225).
2. Determine the WebSEAL keystore file name and location.
a. Navigate to the c:\ibm\Tivoli\PDWeb\etc directory on the Reverse Proxy
node.
b. Open the webseald-default.conf file in a text editor.
c. Search webseal-cert-keyfile and record the value (for example,
c:/ibm/Tivoli/PDWeb/www-default/certs/pdsrv.kdb).
3. Copy the IBM HTTP Server certificate (for example, wp_httpd_cert.arm) from
the Portal Server node (c:\ibm\IBMHttpServer\ssl\) to the
c:/ibm/Tivoli/PDWeb/www-default/certs directory on the Reverse Proxy node.
4. Start the iKeyman utility on the Reverse Proxy node by entering the following
commands from a Windows command window:
cd \ibm\gsk7\bin
gsk7ikm
6. When the Open window appears, do the following and then click OK:
– Key database type: Select CMS.
– Filename: pdsrv.kdb
– Location: c:/ibm/Tivoli/PDWeb/www-default/certs
7. When prompted, enter the password for the keystore. By default the
password is pdsrv.
The password can be changed by selecting Key Database File → Change
Password.
8. From the Key database content drop-down list, select Signer Certificates.
9. Click Add.
10.When the Add CA’s Certificate from a file window appears, we entered the
– Data type: Select Base64-encoded ASCII data.
– Certificate file name: wp_httpd_cert.arm

11.When prompted for the label, we entered WP HTTP Server SSL Key and then
clicked OK. For consistency, we entered the same name as used when we
created the key.
You should see the newly imported certificate listed (for example, WP HTTP
Server SSL Key) among the Signer Certificates.
7.4.5 Export WebSEAL certificate

This section describes how to create a self-signed certificate for the WebSEAL
and how to export the certificate. Although WebSEAL does provide a test
certificate, we chose not to use this certificate for our example. This test
certificate is included with the distribution of Tivoli Access Manager V5.1
available to all customers and is thus not secure. For this reason, we will create a
new self-signed certificate.
Create WebSEAL self-signed certificate

To create a self-signed certificate for WebSEAL, do the following:
1. If you have closed the Key Management utility after the previous step, you will
need to start the Key Management utility and open the key database file
(pdsrv.kdb).
2. Select Personal Certificates from the Key database content drop-down list.
3. From the menu bar, select Create → New Self Signed Certificate.
4. When the Create New Self Signed Certificate window appears, we entered
the following and then clicked OK:
– Key Label: WebSEAL default key
In this case, default is the name of the WebSEAL instance.
– Common Name: wswin1.itso.ral.ibm.com
– Organization: IBM
5. When prompted, Do you want to set the key as the default key in the
database, click No. In our example, the key is defined explicitly in the
webseald-default.conf.
Export WebSEAL certificate

To export the WebSEAL certificate, do the following:
1. If you have closed the Key Management utility after the previous step, you will
need to start the Key Management utility and open the key database file
(pdsrv.kdb).
2. Under Personal Certificates, select the certificate you created in “Create
WebSEAL self-signed certificate” on page 286 (for example, WebSEAL
default key).
3. Click Extract Certificate.
4. When the Extract Certificate to a File window appears, we entered the
– Data Type: Select Base64-encoded ASCII data (default).
– Certificate file name: webseal_default_cert.arm
5. Close the iKeyman utility.
Modify webseald-default.conf to use new certificate

In our example, we chose to create a new self signed certificate. In order for the
WebSEAL to use this new certificate, we need to modify the
webseald-default.conf to define the new key label.
1. Navigate to the c:/ibm/Tivoli/PDWeb/etc directory.
2. Open the webseald-default.conf file with a text editor.
3. Search for webseal-cert-keyfile-label. Modify the value as follows:
webseal-cert-keyfile-label = WebSEAL default key
4. Save and close the file.
5. Restart the WebSEAL instance (Access Manager WebSEAL-default
Windows service).
7.4.6 Import WebSEAL certificate into IBM HTTP Server keystore

To import the WebSEAL certificate into the IBM HTTP Server keystore, do the
following:
1. Copy the WebSEAL certificate (for example, webseal_default_cert.arm) from
the Reverse Proxy node to the c:/ibm/IBMHttpServer/ssl directory on the
Portal Server node.
2. Start the IBM Key Management Utility on the Portal Server node by clicking
Start → Programs → IBM HTTP Server 1.3.26 → Start Key Management
Utility.
4. Select the c:\ibm\IBMHttpServer\ssl\keyfile.kdb and click Open.
5. When prompted enter the password for the keystore.
6. From the Key database content drop-down list, select Signer Certificates.
7. Click Add.
8. When the Add CA’s Certificate from a file window appears, we entered the

– Data type: Select Base64-encoded ASCII data.
– Certificate file name: webseal_default_cert.arm
– Location: c:\ibm\IBMHttpServer\ssl
9. When prompted for the label, we entered WebSEAL default key and then
clicked OK. For consistency, we entered the same name as used when we
created the key.
You should see the newly imported certificate listed (for example, WebSEAL
default key) among the Signer Certificates.
10.Close the IBM Key Management Utility.
7.4.7 Enable mutual SSL for IBM HTTP Server

To enable mutual SSL for IBM HTTP Server on the Portal Server node, do the
following:
1. Stop the IBM HTTP Server V1.3.26 Windows service.
2. Open the c:\ibm\IBMHTTPServer\conf\httpd.conf file with a text editor.
3. Search for the keyword SSLClientAuth inside the <VirtualHost entry.
4. Add the following entry after the commented SSLClientAuth entries:
SSLClientAuth required
5. Save the changes to the httpd.conf file.
Note: Once the SSLClientAuth required keyword and value are set, we will
no longer be able to directly connect to the IBM HTTP Server via HTTPS.
HTTPS connections to the IBM HTTP Server will only be permitted from
WebSEAL.
7. Verify that you are not able to access the IBM HTTP Server directly via
HTTPs by entering the following URL in a Web browser:
https://wpwin1.itso.ral.ibm.com
Figure 7-3 Client Authentication message
8. You should see a message like Figure 7-3. Click Cancel. If you are then
prompted with a Security Alert, click No.
Note: When we create a WebSEAL junction in 7.5.3, “Create a WebSEAL

junction” on page 297, we will enable mutual SSL for the WebSEAL junction.
7.5 Configure portal authentication with TAM using TAI

In the ITSO example, our runtime is currently configured for users to directly log
in to the WebSphere Portal on the Portal Server node. After completing this
section, the authentication for WebSphere Portal will be performed by a
combination of the WebSEAL on the Reverse Proxy node, and the Tivoli Access
Manager Policy Server on the Policy Server node.

1. Apply Tivoli Access Manager ACLs to new LDAP suffixes.
2. Define additional MIME types for WebSphere Application Server.
3. Create a WebSEAL junction.
4. Enable forms authentication on WebSEAL.
5. Configure WebSEAL to modify URLs to back-end systems.
6. Configure additional WebSEAL parameters.
7. Import WebSphere Portal users and groups into TAM.
8. Define access controls for WebSphere Portal URIs.

9. Configure the junction mapping table.
10.Configure SSO for WebSEAL and WebSphere via TAI.
11.Configure Portal login/logout for use with WebSEAL.
7.5.1 Apply Tivoli Access Manager ACLs to new LDAP suffixes

When Tivoli Access Manager V5.1 is configured, it attempts to apply appropriate
access control in the form of Access Control Lists (ACLs) to every LDAP suffix
that exists at the time in the LDAP server. In our example, we created the LDAP
suffix dc=itso,dc=ibm,dc=com in 7.3.1, “Create a suffix” on page 266, after we
configured Tivoli Access Manager. For this reason, we must manually apply
Tivoli Access Manager ACLs to the suffix.
Note: For more information on applying Tivoli Access Manager ACLs to a new
LDAP suffix, refer to Appendix D, “Managing user registries, section Applying
IBM Tivoli Access Manager ACLs to new LDAP suffixes,” in the Base
Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360, product
guide.
Note: Apply TAM ACLs to new LDAP suffix via ldif file import.
This note offers an alternative solution for applying Tivoli Access Manager
ACLs to a new LDAP suffix using an ldif file import in the Tivoli Directory
Server. The ITSO sample code includes c:\6325code\config\ldap\tam-acls.ldif.
If you choose to import ACLs via the ldif, you can skip the rest of this section.
To apply Tivoli Access Manager ACLs to a new LDAP suffix, do the following:
1. Copy the c:\6325code\config\ldap\tam-acls.ldif file to the c:\temp directory.
2. Modify the tam-acls.ldif file for your suffix.
3. From command line, execute the following command.
ldapmodify -h tamwin1.itso.ral.ibm.com -D cn=root -w <password> -i
c:\temp\tam-acls.ldif
To apply Tivoli Access Manager ACLs to a new LDAP suffix, do the following on
the Policy Server node:
1. Ensure that the following IBM Tivoli Directory Server 5.2 Windows service is
running.
2. Start server1 via the command prompt:
cd /ibm/websphere/appserver/bin
startServer server1
3. Start the Tivoli Directory Server Web Administration Tool in a Web browser
at:
http://tamwin1.itso.ral.ibm.com:9080/IDSWebApp/IDSjsp/Login.jsp
Where tamwin1.itso.ral.ibm.com is the host name of the application server
where the IBM Directory Server Web Administration Tool has been installed.
4. From the Web Administration Tool, do the following and then click Login:
– Select the newly created server (for example, tamwin1.itso.ral.ibm.com)
from the drop-down list on the Login page.
5. From the Web Administration Tool, select Directory management →
Manage entries.
6. When the Manage entries page appears, select the suffix from the list (for
example, dc=itso,dc=ibm,dc=com) by clicking it in the Select column, and
then click Edit ACL.
7. To add the cn=SecurityGroup,secAuthority=Default ACL to the ITSO suffix
dc=itso,dc=ibm,dc=com, do the following:
a. When the Edit ACL page appears, click Non-filtered ACLs.
b. When the Edit ACL → Non-filtered ACLs page appears, do the following
and then click Add:
• Check Propagate ACLs.
• DN (distinguished name): cn=SecurityGroup,secAuthority=Default
• Type: Select group.
c. When the Add access rights page appears, do the following and then click
OK at the bottom of the page (see Figure 7-4 on page 292):
• Add child: Select grant.
• Delete entry: Select grant.
• Select grant for all security classes (normal, sensitive, critical, system,
restricted) and actions (read, write, search, compare).
Note: You cannot grant write permission for the system security class
(menu option is disabled).

Figure 7-4 Add ACL for DN cn=SecurityGroup,secAuthority=Default
8. To add the cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default ACL

to the ITSO suffix dc=itso,dc=ibm,dc=com, do the following:
and then click Add:
• DN: cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default
• Type: select group.
• Add child: Leave blank.
• Delete entry: Leave blank.
• Set the normal and system Security classes to grant for the read,
search and compare actions. Leave the Add child, Delete entry, and all
other Security classes blank (see Figure 7-5).
Figure 7-5 Add ACL for cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default
9. To add the cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default

ACL to the ITSO suffix dc=itso,dc=ibm,dc=com, do the following:
b. When the Edit ACL Non-filtered ACLs page appears, do the following and
then click Add:
• DN: cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default

• Set the normal and system Security classes to grant for the read,
search and compare actions. Leave the Add child, Delete entry, and all
other Security classes blank (see Figure 7-6).
Figure 7-6 Add ACL for cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default
10.To add the cn=anybody ACL to the ITSO suffix dc=itso,dc=ibm,dc=com, do

the following:
and then click Add:
• DN: cn=anybody
OK at the bottom of of page (see Figure 7-7):
• Set the normal, system and restricted Security classes to grant for the
read, search and compare actions. Leave the Add child, Delete entry,
and all other Security classes blank (see Figure 7-7).
Figure 7-7 Add ACL for cn=anybody
11.When you have completed adding the ACLs click OK.

12.When the Manage entries page appears, click Close.
The LDAP server does not need to be restarted for the changes to take effect.
13.If you are finished with the IBM Directory Server Web Administration Tool,
click Logout.

7.5.2 Define additional MIME types for WebSphere Application Server
By default the WebSphere Application Server V5 is not configured with MIME
types for Java Archive files and Microsoft ActiveX Control files. These MIME
types are commonly used by back-end Web applications such as Lotus
components included in IBM WebSphere Portal Extend for Multiplatforms V5.0.2.
When using Tivoli Access Manager WebSEAL, the MIME type must be defined
in response headers in order for the response to be passed through the
WebSEAL.
Table 7-3 lists the MIME type definitions we will add in this section. If your portlet
application uses other MIME types not found by default within WebSphere
Application Server, follow the same procedure to add the MIME type definitions.
Table 7-3 Additional MIME types for WebSphere Portal

Description MIME type Extensions
Java Archive application/java-archive jar
ActiveX Control application/x-cabinets-Win32-x86 cab
To add MIME type definitions to the WebSphere Application Server where

WebSphere Portal is installed, do the following:
1. Ensure the server1 application server is started on the Portal Server node.
2. Open the WebSphere Application Server Administrative Console:
a. Enter URL: https://wpwin1.itso.ral.ibm.com:9043/admin
b. Enter the WebSphere administrator user ID and password (for example,
wpsbind).
3. Select Environment → Virtual Hosts.
4. On the Virtual Hosts page, click default_host.
5. Add new MIME type.
a. Click MIME Types under Additional Properties.
b. Click New.
c. On the New MIME Type page, enter the following for the Java archive, as
seen in Table 7-3, and then click OK:
• MIME type: application/java-archive
• Extensions: jar
6. Repeat the previous step to add a new type for ActiveX controls with the
values listed in Table 7-3.
7. Click Save.
8. On the Save to Master Configuration page, click Save.
9. Click Logout.
7.5.3 Create a WebSEAL junction

To create the WebSEAL junctions for our configuration, we will use the Tivoli
Access Manager pdadmin command line interface. You can use the pdadmin
command line interface in one of the following three modes:
򐂰 Single command mode
򐂰 Interactive command mode
򐂰 Multiple command mode
For the ITSO example, we chose to create an input file. In our example, we will
use multiple command mode with a command file containing the commands to
create the junction. Figure 7-8 depicts the ITSO sample /portal WebSEAL
junction for WebSphere Portal.
/portal junction point

Port 80 Port 443
Web Browser HTTP WebSEAL instance HTTPS HTTP Server for
Client (default-webseald-wswin1) WebSphere Portal
Figure 7-8 ITSO junction for WebSphere Portal
Create the wp-junction.pd command file

For our example, we created a command file named wp-junction.pd found in the
c:\6325code\config\tam directory.
To create the wp-junction.pd file containing the commands to create a junction

for WebSphere Portal, do the following:
1. Ensure the Access Manager Policy Server Windows service is started.
2. Start the pdadmin command line interface on the Reverse Proxy node, by
selecting Start → Programs → IBM Tivoli Access Manager →
Administration Command Prompt.
3. Log in by entering login in the pdadmin prompt. When prompted, enter the
user ID sec_master and <password>.
4. To get a list of servers, enter the following command:
server list

The command will output a list that contains the following:
default-webseald-wswin1
Take note of the WebSEAL server name.
5. We created the wp-junction.pd file with the commands as seen in
Example 7-6. The wp-juncion.pd will be used to define an SSL junction for
WebSphere Portal in the WebSEAL instance we configured previously. This
will enable mutual SSL for the WebSEAL junction created.
Note: For details on the parameters refer to Appendix B, “WebSEAL

junction reference,” in the WebSEAL Administration Guide, IBM Tivoli
Access Manager V5.1, SC32-1359, product guide.
The syntax of this command is as follows:

server task <webseal_servername> create -t <junction_type> -h
<backend_server_hostname> -p <backend_server_port> -j -w -c all -K
“<key_label>” -D “<CN>” <junction_point>
Where the parameters are as follows:
– <webseal_servername> is the server name returned from server list
command in the previous step (for example, default-webseald-wswin1).
– <junction_type> is either tcp for non-ssl or ssl.
– <backend_server_hostname>, in our example this is Portal Server node.
– <backend_server_port> ,in our example this is Portal Server node port
443.
– -j enables junction cookies for handling server relative URLs.
– -w is used to support the Win32 file system. This option will only allow full
paths to resources (not the short name). Also, it will make the resource
validation case insensitive.
– -c all: There are two key options (-c all or -c iv-user) for WebSphere Portal
integration. When only performing authentication, -c -iv-user is sufficient.
When using performing authentication and authorization, then -c all must
be used.
– -K <key_label> is the WebSEAL key label on the Reverse Proxy node.
– -D <CN> in our example is CN=wpwin1.itso.ral.ibm.com,O=IBM,C=US.
Example 7-6 ITSO wp-junction sample command file

server task default-webseald-wswin1 create -t ssl -h wpwin1.itso.ral.ibm.com -p 443 -j -w -c
all -K "WebSEAL default key" -D "CN=wpwin1.itso.ral.ibm.com,O=IBM,C=US" /portal
Note: For scenarios using the internal HTTP service built-in to WebSphere
Application Server (development WebSphere Test Environment or no external
Web Server), update the port to 9444 for SSL instead of port 443 in the
wp-junction.pd (see Example 7-6).
Create the WebSEAL junction from wp-junction.pd

To create the WebSEAL junction from wp-junction.pd, do the following:
1. Copy the wp-junction.pd command file to the c:\temp directory on the
Reverse Proxy node.
2. Open a Windows command window (not pdadmin).
3. From the Windows command line, change to the directory of the
wp-junction.pd and enter the following command:
pdadmin -a sec_master wp-junction.pd
4. When prompted for the password, enter the sec_master password.
Note: When creating the junction, WebSEAL will attempt to connect to the
back-end system (for example, WebSphere Portal). If the system is not
available, you will see the following message:
DPWWA1222E A third-party server is not responding. Possible causes:
the server is down, there is a hung application on the server, or
network problems. This is not a problem with the WebSEAL server.
DPWIV1054E Could not connect
The junction will still be created.
5. Verify that the junction was created properly.

a. Start pdadmin and log in as sec_master.
b. Enter the following command to verify the junction:
server task default-webseald-wswin1 list
You should see a list of junctions including the new junction created, for
example:
/portal
c. You can further review the junction definition by entering the following
command. This will list all settings for the /portal junction.
server task default-webseald-wswin1 show /portal

7.5.4 Enable forms authentication on WebSEAL
By default, the WebSEAL uses HTTP basic authentication for its authentication
challenge to the user. With basic authentication, the logout does not happen until
the user closes the Web browser. In addition, there are other security issues with
basic authentication that make forms authentication preferable.
To enable forms authentication, you will need to update the

webseald-<webseal_instancename>.conf on the Reverse Proxy node as follows:
1. Navigate to the c:\ibm\Tivoli\PDWeb\etc directory.
2. Back up the webseald-default.conf (for example, webseald-default.conf.org).
3. We modified the webseald-default.conf, as seen in Figure 7-7, for the ITSO
example.
Example 7-7 ITSO example forms authentication settings in webseaId-default.conf

[ba]
#--------------------------
# BASIC AUTHENTICATION
#--------------------------
#Enable authentication using basic authentication mechanism
#One of <http, https, both, none>
ba-auth = none
[forms]
#--------------------------
#Forms
#--------------------------
#Enable authentication using forms
#One of <http, https, both, none>
forms-auth = https
4. Save the webseald-default.conf file.

5. Restart the Access Manager WebSEAL-default Windows service to enable
these configuration changes.
6. To verify that the forms authentication is enabled, we will access the
WebSEAL with Web browser:
https://<webseal_hostname>
You should now get the WebSEAL login form page in the browser instead of
the WebSEAL basic authentication pop-up.
7. Log on to the WebSEAL with the sec_master user ID and password.
You should see the WebSEAL splash screen.
Now that forms are enabled, users will be able to log out without needing to close
the Web browser.
7.5.5 Configure WebSEAL to modify URLs to back-end systems

Web pages returned to the client from back-end applications are likely to contain
URL links to resources located on those application servers (for example,
WebSphere Application Server or WebSphere Portal). It is important that these
links are constructed to direct any requests back to the correct locations of these
resources.
This section describes how to configure WebSEAL to modify URLs to back-end

systems for the following:
򐂰 Enable WebSEAL URL filtering.
򐂰 Enable WebSEAL processing of URLs in the request.
Enable WebSEAL URL filtering

The Tivoli Access Manager WebSEAL URL filtering performs two functions:
򐂰 It adds the junction name to the path of the absolute and server-relative URLs
that refer to resources located on the back-end servers.
򐂰 The absolute URL host/port is mapped to the respective junction on
WebSEAL.
When adding WebSEAL in front of a back-end application such as WebSphere

Application Server or WebSphere Portal, the absolute URLs of the back-end
application need to be mapped to WebSEAL.
Note: For more detailed information of WebSEAL URL filtering, refer to

Chapter 10, “WebSEAL junctions, section Filtering URLs in responses,” in the
WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1359, product guide.
If the back-end application (WebSphere Portal) generates an absolute URL as

seen in Table 7-4, it will need to be mapped on WebSEAL since only the Reverse
Proxy node is accessible to Web browser clients. In the filtered WebSEAL URL,
the junction /portal was created in 7.5.3, “Create a WebSEAL junction” on
page 297.
Table 7-4 WebSEAL URL filter example

WebSphere Portal URL Filtered WebSEAL URL
http://wpwin1.itso.ral.ibm.com/wps/portal http://wswin1.itso.ral.ibm.com/portal/wps/portal

To enable WebSEAL URL filtering, do the following:
2. Back up the webseald-default.conf (for example, webseald-default.conf.org).
3. We modified the webseald-default.conf, as seen in Figure 7-8, for the ITSO
example.
script-filter=yes enables WebSEAL URL filtering.
Example 7-8 ITSO example URL filtering settings in webseaId-default.conf

[script-filtering]
script-filter=yes

5. You will need to restart the Access Manager WebSEAL-default Windows
service for the changes to take effect. We will make other changes to the
webseald-default.conf file, so you may defer the restart at this time.
Enable WebSEAL processing of URLs in the request

When URLs are dynamically generated by client-side applications such as
applets or embedded scripts in the HTML such as JavaScript or ActiveX, the
URLs will need to be mapped. In this case WebSEAL does not have the ability to
apply its standard filtering rules to the dynamically generated URLs.
The WebSEAL provides two methods of addressing dynamically generated

URLs from client-side applications:
򐂰 Junction cookies are specified with a -j option when creating the junction.
򐂰 Junction mapping: The junction mapping uses a static junction mapping table
to map specific back-end resources to junction names.
Note: For more detailed information on WebSEAL URL filtering, refer to

Chapter 10, “WebSEAL junctions, section Processing URLs in requests,” in
the WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1359, product guide.
For the ITSO example, we chose to use the junction cookies option for the base
configuration. When creating the junction in 7.5.3, “Create a WebSEAL junction”
on page 297, we used the -j option for junction cookies of processing URLs in the
request.
7.5.6 Configure additional WebSEAL parameters
This section describes additional parameters we modified in the
webseaId-default.conf file for the ITSO working example.
Note: For information on configuring WebSEAL parameters, refer to Appendix

A, “WebSEAL configuration file reference,” in the WebSEAL Administration
Guide, IBM Tivoli Access Manager V5.1, SC32-1359, product guide.
To configure additional WebSEAL parameters such as timeout, do the following:

2. We modified the webseald-default.conf as seen in Figure 7-8 on page 302 to
configure additional parameters. The webseaId-default.conf includes
comments that explain each parameter. The ITSO example contains
additional parameters in webseald-default.conf.
Example 7-9 Code

[server]
dynurl-allow-large-posts=yes
[junction]
http-timeout=300
https-timeout=300
[session]
ssl-id-sessions=no

4. You will need to restart the Access Manager WebSEAL-default Windows
service for the changes to take effect.
7.5.7 Import WebSphere Portal users and groups into TAM

Although the users and groups used by WebSphere Portal have already been
created in the Tivoli Directory Server directory, the users have not been imported
into the Tivoli Access Manager. The import of users into Tivoli Access Manager
includes adding attributes to existing users in the LDAP directory.
Create the wp-tam-user-import.pd command file

In our example, we will create a command file called wp-tam-user-import.pd
found in the c:\6325code\config\tam ITSO sample code directory. This command
file will be used to import the WebSphere Portal users into Tivoli Access

Manager using pdadmin. The ITSO-provided wp-tam-user-import.pd file is
displayed in Example 7-10 on page 304.
Example 7-10 ITSO example wp-tam-user-import.pd file

user import -gsouser wpsadmin uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com
user modify wpsadmin account-valid yes
user modify wpsadmin password-valid yes
group import wpsadmins cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com
Import WebSphere Portal users into TAM via command file

To import the WebSphere Portal users and groups into Tivoli Access Manager
using a pdadmin command file, do the following:
1. Open a command window.
2. Copy the wp-tam-user-import.pd to a temporary directory on the Reverse
Proxy node (for example, c:\temp).
3. From the temporary directory, enter the following command to import the
WebSphere Portal users and groups into Tivoli Access Manager:
pdadmin -a sec_master wp-tam-user-import.pd
When prompted, enter the sec_master password.
4. To verify that the users and groups where imported properly, enter the
following commands from a Windows command window:
pdadmin -a sec_master -p <password> user list * 100
pdadmin -a sec_master -p <password> group list * 100
Where <password> is the sec_master password, * is all users, and 100 is the
maximum user to return.
7.5.8 Define access controls for WebSphere Portal URIs

This section describes how to define four access categories for WebSphere
Portal, as defined in Table 7-5.
Table 7-5 Access categories for WebSphere Portal

Access category Description
WP_all_access Access for all users (authenticated and

unathenticated)
WP_authenticated_access Access for authenticated users only
WP_admin_access Access for administrator users only
WP_no_access No access
Create TAM objects for WebSphere Portal URIs
To create Tivoli Access Manager objects for WebSphere Portal URIs, do the
following on the Reverse Proxy node:
Note: For more information on creating Tivoli Access Manager objects, refer
to Chapter 12, “Application integration,”in the WebSEAL Administration Guide,
IBM Tivoli Access Manager V5.1, SC32-1359, product guide.
1. Create a file named dynurl.conf in the c:\ibm\Tivoli\PDWeb\www-default\lib

directory, as seen in Example 7-11.
Where default is the name of the WebSEAL instance. We have included a
dynurl.conf in the c:\6325code\config\tam ITSO sample code directory.
Example 7-11 ITSO example dynurl.conf

/portal/wps/portal /portal/wps/portal*
/portal/wps/myportal /portal/wps/myportal*
/portal/wps/config /portal/wps/config*
/portal/wps/doc /portal/wps/doc*
/portal/wps /wps/*
Note: We have added entries for both before the mapping and after the
mapping versions of URLs that will be handled by the JMT. This is
necessary, as WebSEAL will perform two ACL checks, one on the URL
before the JMT transformation and one after. Both must pass for access to
be granted.
Given that the real access control check is the second one, we have added
dummy entries for the before versions and mapped them to an object that
is readable by both unauthenticated and authenticated users (/portal/wps),
so the first ACL check will now always pass.
2. To activate the definitions, do one of the following:

– Issue the following command:
pdadmin -a sec_master -p <password> server task default-webseald-wswin1
dynurl update
or
– Restart the Access Manager WebSEAL-default Windows service.

Define access control policy for WebSphere Portal
This section describes how to define the access control policy for WebSphere
Portal and includes the following operations:
򐂰 Create Tivoli Access Manager ACL templates corresponding to the access
categories defined for WebSphere Portal.
򐂰 Update the ACLs for the imported users and groups.
򐂰 Attach ACLs to protected objects for WebSphere Portal.
To define the access control policy, do the following

1. Create a command file called wp-tam-acl.pd, as seen in Example 7-12. The
file is included in the c:\6325code\config\tam ITSO sample code directory.
Note: The ITSO provided wp-tam-acl.pd command file includes three

sections.
򐂰 The first two sections in Example 7-12 do not need to be modified
unless you need to create new access categories.
򐂰 The last section in Example 7-12 includes settings that will change
based on your environment. For example, you will need to update the
following: The /WebSEAL/host-instance_name represents the
beginning of the Web space for a particular WebSEAL server instance
(for example, /WebSEAL/wswin1-default). To retrieve your setting enter
the following command on the Reverse Proxy node:
pdadmin -a sec_master -p <password> object list /WebSEAL
Record the value returned and update the command file accordingly.
Example 7-12 ITSO example wp-tam-acl.pd

acl create WP_all_access
acl create WP_authenticated_access
acl create WP_admin_access
acl create WP_no_access
acl modify WP_admin_access set user sec_master TcmdbsvaBrxl

acl modify WP_admin_access set group iv-admin Tcmdbsvarxl
acl modify WP_admin_access set group webseal-servers Tgmdbsrxl
acl modify WP_admin_access set group wpsadmins Tr
acl modify WP_admin_access set any-other T
acl modify WP_admin_access set unauthenticated T
acl modify WP_no_access set user sec_master TcmdbsvaBrxl
acl modify WP_no_access set group iv-admin Tcmdbsvarxl
acl modify WP_no_access set group webseal-servers Tgmdbsrxl
acl modify WP_no_access set group wpsadmins T
acl modify WP_no_access set any-other T
acl modify WP_no_access set unauthenticated T
acl modify WP_authenticated_access set user sec_master TcmdbsvaBrxl
acl modify WP_authenticated_access set group iv-admin Tcmdbsvarxl
acl modify WP_authenticated_access set group webseal-servers Tgmdbsrxl
acl modify WP_authenticated_access set group wpsadmins Tr
acl modify WP_authenticated_access set any-other Tr
acl modify WP_authenticated_access set unauthenticated T
acl modify WP_all_access set user sec_master TcmdbsvaBrxl
acl modify WP_all_access set group iv-admin Tcmdbsvarxl
acl modify WP_all_access set group webseal-servers Tgmdbsrxl
acl modify WP_all_access set group wpsadmins Tr
acl modify WP_all_access set any-other Tr
acl modify WP_all_access set unauthenticated Tr
acl attach /WebSEAL/wswin1-default/portal/wps/config WP_admin_access

acl attach /WebSEAL/wswin1-default/portal/wps/myportal WP_authenticated_access
acl attach /WebSEAL/wswin1-default/portal/wps/portal WP_all_access
acl attach /WebSEAL/wswin1-default/portal/wps/doc WP_all_access
acl attach /WebSEAL/wswin1-default/portal/wps WP_all_access
2. To create the Tivoli Access Manager ACLs, modify the access and attach to
objects using the wp-tam-acl.pd file by entering the following from a Windows
command window:
pdadmin -a sec_master -p <password> wp-tam-acl.pd
7.5.9 Configure the junction mapping table

Several portlets, including the Resource Permissions portlet, and the productivity
components editors use relative JavaScript within the portlet or component.
These portlets and components will not function correctly when accessed
through a WebSEAL junction. For the JavaScript to be interpreted and navigation
followed correctly, WebSeal must be configured to insert the junction point into
the JavaScript. One way to accomplish this is through the use of the JMT table
function in WebSEAL.
To enable the JMT function, define an ASCII text file called jmt.conf as follows on
the Reverse Proxy node:
1. Create the jmt.conf file in the c:/ibm/Tivoli/PDWeb/www-default/lib directory.
The location of this file is specified in the [junction] stanza of the
webseald-default.conf configuration file jmt-map = lib/jmt.conf.
2. The format for data entry in the table consists of the junction name, a space,
and the resource location pattern. You can also use wildcard characters to
express the resource location pattern.
The ITSO-provided jmt.conf is displayed in Example 7-13.

Example 7-13 ITSO example jmt.conf
/portal /wps/*

4. Reload the JMT in WebSEAL to do one of the following:
– Restart the WebSEAL Windows service.
or
– Reload the JMT using the following command:
i. Open a command window.
ii. Enter the following to log in to pdadmin:
pdadmin -a sec_master -p <password>
iii. Enter the following from the pdadmin command line to reload the JMT:
server task default-webseald-wswin1 jmt load
You should see the message JMT table successfully loaded.
5. To verify that the JMT (jmt.conf) is working properly, enter the following URL
in a Web browser to access WebSphere Portal via the WebSEAL (Reverse
Proxy node hostname):
http://wswin1.itso.ral.ibm.com/wps/portal
You should see the default WebSphere Portal page for unauthenticated users.
7.5.10 Configure SSO for WebSEAL and WebSphere via TAI

When using a Reverse Proxy such as WebSEAL to authenticate users in the
DMZ, it is desirable that WebSphere Application Server, as well as other
back-end applications and services, trust the authentication that has been
performed and the identity that is being presented by the Reverse Proxy. If this
trust can be established, users then need only authenticate once to the Reverse
Proxy in order to have access to all authorized services located beyond that
proxy. This is commonly known as Reverse Proxy Single Sign-on (RPSS).
Note: For a detailed explaination refer to 4.1.3, “Single sign-on guidelines” on

page 96.
There are two ways to establish a trust relationship between WebSphere
Application Server and WebSEAL:
򐂰 Trust Association Interceptor (TAI)
For the ITSO working example runtime environment, we chose to use TAI for
the implementation procedure found in this section.
or
򐂰 Light Weight Third Party Authentication (LTPA) Token
For details on implementing using an LTPA Token for the single sign-on
configuration, refer to Appendix B, “Configure single sign-on using LTPA” on
page 597.
There are three possible methods of verifying that the request to the WebSphere
Application Server came from WebSEAL:
򐂰 TCP junction without SSL, with basic authentication credentials supplied
򐂰 SSL junction with basic authentication
򐂰 Mutual SSL junction without basic authentication credentials
Note: We used this method for the ITSO example.
Enable TAI on the Portal Server node

To enable TAI in WebSphere Application Server on the Portal Server node using
the WebSphere Application Server Administrative Console, do the following:
Note: As an alternative to enabling TAI using the WebSphere Application

Server Administrative Console as described in this section, you can use a
WebSphere Application Server admin script.
We have included a WebSphere Application Server admin script file named

config.was.tai.jacl in the c:\6325code\config\wps directory. This script can be
modified/run to enable TAI within WebSphere Application Server.
To run the command once you have modified it for your environment, enter the
following:
c:\ibm\WebSphere\AppServer\bin\wsadmin" -f "c:\temp\config.was.tai .jacl"
-user wpsbind -password password
Where password is your password for the wpsbind user ID.
1. Ensure that the WebSphere Application Server server1 is started.

a. Enter the URL:
3. Select Security → Authentication Mechanisms → LTPA.
Note: Although LTPA is the menu option, we are configuring TAI.
4. Click Trust Association under Additional Properties.

5. On the Trust Association page, check the Trust Association Enabled check
box. Click Apply.
6. Click Interceptors under Additional Properties.
7. Click com.ibm.ws.security.web.WebSealTrustAssociationInterceptor.
8. Click Custom Properties under Additional Properties.
9. Click New and enter the General Properties name and value pairs specified in
Table 7-6. For more information on the possible values that these properties
might have, please refer to the WebSphere Portal InfoCenter.
Table 7-6 Custom properties for WebSEAL Trust Association Interceptor

Name Value
com.ibm.websphere.security.trustassociation.types webseal
com.ibm.websphere.security.webseal.id iv-user
com.ibm.websphere.security.webseal.hostnames wswin1.itso.ral.ibm.com, wswin1

Note: This is the Reverse Proxy
node in our example. The host
name is case sensitive.
com.ibm.websphere.security.webseal.ports 80,443
com.ibm.websphere.security.webseal.ignoreProxy false
com.ibm.websphere.security.webseal.mutualSSL true
Note: SSL between the
WebSEAL and the IBM HTTP
Server on the Portal Server node.
Figure 7-9 Trust association properites
After you have created all these properties, the Custom Properties should
look as shown in Figure 7-9.
Tip: Check and double-check the names and values of all the Custom
properties before saving the configuration changes.
10.Click Save. When the Save to Master Configuration page appears, click
Save.
11.Click Logout.
12.Restart the WebSphere_Portal application server.

Verify the TAI configuration
Now that we have enabled TAI within WebSphere Application Server on the
Portal Server node, we recommend that you verify that TAI is working properly.
1. To verify that access to unauthenticated portal pages is working properly,
enter the following in a Web browser:
http://wswin1.itso.ral.ibm.com/portal/wps/portal
In this case, there should be no authentication.
2. To verify that authenticated access is working properly, entering the following
URL in a Web browser:
https://wswin1.itso.ral.ibm.com/portal/wps/myportal
WebSEAL should challenge you to authenticate. Once you log in as
wpsadmin, you should be directed to the user’s secure and personalized
myportal page, as seen in Figure 7-10.
Figure 7-10 Secure myportal page
Note: The Logout link will not work at this stage. In the next section we
configure the WebSphere Portal login/logout for use with WebSEAL.
If you are directed to the portal login screen at wps/portal/.scr/Login or the

public page, there is a problem with the Trust Association Interceptor
configuration.
7.5.11 Configure Portal login/logout for use with WebSEAL

In our example, we have configured WebSEAL to authenticate users for
WebSphere Portal. With our current configuration, it is no longer possible to log
in or log out of WebSphere Portal directly. In this section, we describe how to
configure WebSphere Portal login/logout functionality for use with WebSEAL.
Modifying web.xml
To modify the WebSphere Portal login, such that login requests are directed to
the personalized portal URL, do the following:
1. Navigate to the following directory on the Portal Server node:

c:/ibm/WebSphere/AppServer/installedApps/wpwin1/wps.ear/wps.war/WEB-INF/
2. Back up the existing web.xml to web.xml.org.
3. Modify the web.xml contents as seen in Example 7-14.
Example 7-14 ITSO modified web.xml snippet

<login-config id="LoginConfig_1">
<auth-method>FORM</auth-method>
<realm-name>WPS</realm-name>
<form-login-config id="FormLoginConfig_1">
<form-login-page>/myportal</form-login-page>
<form-error-page>/error.html</form-error-page>
</form-login-config>
</login-config>
Create wpslogout.html
When a WebSphere Portal user log outs of WebSEAL, we would like to display
the public (unauthenticated) portal page at:
http://wswin1.itso.ibm.com/portal/wps/portal
To achieve this behavior, we must create the wpslogout.html to redirect

WebSEAL logout to the WebSphere Portal public page as follows:

Note: The ITSO sample code c:\6325code\config\tam directory includes a
sample wpslogout.html file.
1. Navigate to the following directory on the Reverse Proxy node:

c:\ibm\Tivoli\PDWeb\www-default\lib\html\C
2. Create the wpslogout.html file as seen in Example 7-15. You will need to
modify the href value to include the WebSEAL hostname (for example,
http://wswin1.itso.ral.ibm.com/portal/wps/portal).
Example 7-15 ITSO example wpslogout.html

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<script language=javascript type="text/javascript">

</script>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Refresh"
content="2;URL=http://wswin1.itso.ral.ibm.com/portal/wps/portal">
<title>PKMS Administration: User Log Out</title>

</head>
<body bgcolor="#FFFFFF" text="#000000" onLoad=delete_all_cookies("/",exception_list)>
<font size="+2"><b>User %USERNAME% has logged out.</b></font>
<BR><BR>
<BR><BR>
Redirecting to public portal page ... select <a
href="http://wswin1.itso.ral.ibm.com/portal/wps/portal">here</a> if your browser does not
automatically redirect after 2 seconds.
</body>
</html>
Modify logout.html
When users from other applications (non WebSphere Portal) accessed through
WebSEAL perform logout, the logout.html page will be displayed.
1. Navigate to the following directory on the Reverse Proxy node:
C:\ibm\Tivoli\PDWeb\www-default\lib\html\C
2. Back up the existing logout.html to logout.html.org.

3. Replace the existing logout.html file contents as seen in Example 7-15 on
page 314.
Note: The ITSO sample code c:\6325code\config\tam directory includes a

sample logout.html file.
Example 7-16 ITSO example logout.html





<script language=javascript type="text/javascript">


</script>
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=UTF-8">
<title>PKMS Administration: User Log Out</title>
</head>
<body bgcolor="#FFFFFF" text="#000000" onLoad=delete_all_cookies("/",exception_list)>
<font size="+2"><b>User %USERNAME% has logged out.</b></font>
</body>
</html>
Modify ConfigService.properties
To modify the WebSphere Portal logout command to point to the WebSEAL
logout command, do the following:
c:\ibm\WebSphere\PortalServer\shared\app\config\services
2. Back up the ConfigService.properties file to ConfigService.properties.org.
3. Modify the ConfigService.properties with the contents seen in Example 7-17.
You will need to update the redirect.logout and redirect.logout.ssl to true, and
redirect.logout.url for your environment.
Note: Example 7-17 only includes the values we changed, not the entire
contents of the ConfigService.properties file.

Example 7-17 ITSO example ConfigService.properties snippet
# Logout redirect parameters
#
# Default: false, false, <none>
redirect.logout = true
redirect.logout.ssl = true
redirect.logout.url = https://wswin1.itso.ral.ibm.com/pkmslogout?filename=wpslogout.html
Modify ToolBarInclude.jsp files

This section modifies the ToolBarInclude.jsp to address the following items:
򐂰 The ability of end users to self-register by removing the link to the
self-registration screen from the public portal page
򐂰 The ability of end users to edit their profiles by removing the link to the edit
profiles screen from the private portal page
򐂰 The ability of end users to request their passwords by removing the forgot
password link from the public portal page
򐂰 The address of the Log in link by altering the link to point to the Reverse
Proxy node
The procedure requires that each ToolBarInclude.jsp is updated in each theme in

which the file exists.
Note: There is one occurrence of the ToolBarInclude.jsp in the root of the

../wps.war/themes/html directory. This ToolBarInclude.jsp is used as the
default if a theme does not have its own ToolBarInclude.jsp.
In addition, you will need to update the ToolBarInclude.jsp (if found) in the
../wps.ear/wps.war/themes/html/<theme_name> directory for each theme.
Modify the ToolBarInclude.jsp for each occurrence of the file, as follows:

Root directory:
c:/ibm/WebSphere/AppServer/installedApps/wpwin1/wps.ear/wps.war/themes/html
Or Theme directory:
/<theme>
Where <theme> is the theme directory of interest. We have listed the themes
we updated the ToolBarInclude.jsp:
– Admin
– AdminLeftNavigation
– Corporate
– Engineering
– Finance
– Science
– YourCoFinancial
– YourCoFinancial2
2. Back up the ToolBarInclude.jsp.
3. Open the file in a text editor. Comment out the forgot password, selfcare, and
enroll buttons as shown Example 7-18.
Example 7-18 ITSO example ToolBarInclude.jsp snippet to be used as the default theme
<%-- forgot password button --%>
<%--
<wps:if loggedIn="no" notScreen="ForgotPassword">
<td class="wpsToolBar" valign="middle" align="<%=bidiAlignRight%>" nowrap>
<a class="wpsToolBarLink" href='<wps:url screen="ForgotPassword"
home="public"/>'><wps:text key="link.password" bundle="nls.engine"/></a>
</td>
</wps:if>
--%>
<%-- selfcare button --%>
<%--
<wps:if loggedIn="yes" notScreen="SelfcareUserForm,SelfcareUserConf" portletSolo="no">
<a class="wpsToolBarLink" href='<wps:url command="PrepareSelfcare"
reqid="no"/>'><wps:text key="link.selfcare" bundle="nls.engine"/></a>
</td>
</wps:if>
--%>
<%-- enroll button --%>
<%--
<wps:if loggedIn="no">
<%
String dt = com.ibm.wps.puma.UserManager.instance().getDirectoryType();
if (dt==null)
{
dt = "";

}
if (!dt.equals("SSPM"))
{
%>
<a class="wpsToolBarLink" href='<wps:url command="PrepareEnrollment"
home="public" reqid="no"/>'><wps:text key="link.enrollment" bundle="nls.engine"/></a>
</td>
<%
}
%>
</wps:if>
--%>
<%-- Edit the login button section as follows: --%>

<%-- login button --%>
<wps:if loggedIn="no" notScreen="Login">
<a class="wpsToolBarLink" href='<wps:url home=”protected” screen=”Home”
ssl=”true”>'><wps:text key="link.login" bundle="nls.engine"/></a>
</td>
</wps:if>
4. Edit the login button section as seen in Example 7-18 on page 319 for each
theme used.
6. Open and save the version of Default.jsp found in the root of the html
directory and corresponding theme directory (if they exist).
/Default.jsp
This is necessary to make the application server recompile the JSP pages in
order to have the changes take effect (touch operation).
Modify WpsHostName property in wpconfig.properties

After junction configuration the property WpsHostName in wpconfg.properties
should be set to the WebSEAL hostname. This will allow proper URL filtering and
protocol switching by the WebSEAL.
1. Navigate to the <wp_home>\config directory.
2. Modify the wpconfig.properties file as follows:
From (Portal Server node hostname):
To (Reverse Proxy node hostname):
WpsHostName=wswin1.itso.ral.ibm.com
4. Execute the wpsconfig.bat command to load the configuration changes:
a. Open a command window and navigate to the following directory:
c:\IBM\WebSphere\PortalServer\config
b. Execute the wpsconfig command:
wpsconfig httpserver-config
Verify create/login of new user

To further test the TAI, we will create a new user (any random user) as follows:
1. Enter the following commands from the pdadmin console on the Reverse
Proxy node after you have logged in as sec_master:
Note: The syntax of the user create command for Tivoli Access Manager
is:
user create -gsouser <user_name> <user_dn> <common name> <surname>
<password>
user create -gsouser jane uid=jane,cn=users,dc=itso,dc=ibm,dc=com “Jane”

“Doe” “passw0rd”
user modify jane account-valid yes
Tip: The user password chosen has to conform to the Tivoli Access
Manager password policy. It requires a minimum length of eight characters
formed by at least four alphabetical characters and one non-alphabetical
character with no more than two repeated characters. The password policy
can be changed on a user base or global base. For more information refer
to the Base Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1360 product guide.
2. Log in to the portal site using this newly created user:


7.6 Configure Portal for authorization with TAM
This section describes how to implement authorization using Tivoli Access
Manager for WebSphere Portal. We include an example for externalizing the
WebSphere Portal YourCo Financial portlet page resources for authorization via
Tivoli Access Manager. In addition, the procedures in this section are a
prerequisite for deploying the ITSO Bank secure portal application detailed in
Chapter 10, “Deploy the secure portal application” on page 433.
The section is organized as follows:

1. Configure the SSL between WebSphere and TAM.
2. Implement JAAS authentication.
3. Modify WebSphere Portal configuration files.
4. Verify entries in TAM for Portal external authorization.
5. Example for externalizing a resource.
Note: A list of fixes in WebSphere Portal related to external authorization can

be found in “Problems fixed in the portal for external access control” on
page 594.
7.6.1 Configure the SSL between WebSphere and TAM

The SrvSslCfg command is used to configure the SSL connection between the
WebSphere Application Server and Tivoli Access Manager. This command
creates a keyfile and a properties file, which will be used later for WebSphere
Portal configuration.
The SrvSslCfg command also creates the user who is specified as <was_id> and
inserts this user in the following Tivoli Access Manager LDAP groups:
cn=remote-acl-users
cn=SecurityGroup,secauthority=Default
To configure the SSL connection between WebSphere Application Server used

by WebSphere Portal and the Tivoli Access Manager, do the following:
Note: We found that the Java Runtime Environment included with IBM
WebSphere Application Server V5.0.2.3 (Base) is incompatible with the
SvrSslCfg command. For this reason, we installed the Tivoli Access Manager
Java Runtime Environment V1.3.1 and configured the Tivoli Access Manager
Runtime to use the standalone IBM JRE V1.3.1.
1. Open a command window on the Portal Server node.
2. In our example, we created a command file named wpwin1_svrsslcfg.bat (see
Example 7-19) in the c:\6325code\config\wps directory of the ITSO sample
code containing the SvrSslCfg command and parameters for the ITSO
environment. In Example 7-19 <password> needs to be updated with the
correct sec_master password.
Example 7-19 ITSO sample wpwin1_svrsslcfg.bat

c:\ibm\Java131\jre\bin\java com.tivoli.pd.jcfg.SvrSslCfg -action config
-admin_id sec_master -admin_pwd <password> -appsvr_id amwas -port 7201 -mode
remote -policysvr tamwin1.itso.ral.ibm.com:7135:1 -authzsvr
tamwin1.itso.ral.ibm.com:7136:1 -cfg_file
"c:\ibm\WebSphere\AppServer\java\jre\PdPerm.properties" -key_file
"c:\ibm\WebSphere\AppServer\java\jre\lib\security\pdperm.ks" -cfg_action
replace
– <admin_id> is the Tivoli administrator user ID. The default value is

sec_master.
– <password> is the password for the Tivoli administrator user ID.
– <was_id> is the unique WebSphere Application Server identifier to be
inserted into Tivoli Access Manager.
Note: The value is user defined. In our example, we entered amwas for
the <was_id>.
– <port_number> is the TCP/IP port that WebSphere Application Server

listens to for policy server notifications. This value must be filled in even
though WebSphere Application Server does not currently use this port.
– <pdmgrd_host> is the pdmgrd host (pdmgrd is a Tivoli Access Manager
process).
– <pdacld_host> is the pdacld host (pdacld is a Tivoli Access Manager
process).
– <pdacld_host> is the pdmgrd port. The default port number is 7135.
– <pdacld_port> is the pdacld port. The default port number is 7136.
– <rank> is the rank of the host. If only one host is specified, this value is 1.
– <config_file_path> is the path to the properties file that you will create and
insert into ExternalAccess ControlService.properties, for example,
c:\ibm\WebSphere\AppServer\java\jre\PdPerm.properties.

– <keystore_path> is the path to the keystore, for example,
c:\ibm\WebSphere\AppServer\java\jre\lib\security\pdperm.ks.
– replace is used to replace the existing configFile URL and keystoreFile
URL.
Note: Alternatively, you could enter the following SvrSslCfg command to

configure an SSL connection between the WebSphere Application Server
on the Portal Server node and Tivoli Access Manager on the Policy Server
node:
c:/ibm/Java131/jre/bin/java com.tivoli.pd.jcfg.SvrSslCfg -action
config -admin_id <admin_id> -admin_pwd <password> -appsvr_id <was_id>
-port <port_number> -mode remote -policysvr
<pdmgrd_host>:<pdmgrd_port>:<rank> -authzsvr
<pdacld_host>:<pdacld_port>:<rank> -cfg_file "<config_file_path>"
-key_file "<keystore_path>" -cfg_action replace
When the SvrSslcfg command completes, you should see the message:
The configuration completed successfully.
3. To verify that the SvrSslCfg command worked properly, do the following:
a. Open a command window on the Policy Server node.
b. Enter the following command to log in to pdadmin:
c. Enter the following command to list the servers defined in Tivoli Access
Manager:
server list
You should see the newly created server amwas-wpwin1, where amwas is
the appsvr_id and wpwin1 is the host name of the Portal Server node
(WebSphere Application Server is installed).
7.6.2 Implement JAAS authentication

In this step we configure WebSphere Portal Server to extract and cache the
Tivoli Access Manager JAAS credential from the HTTP header data sent by the
WebSEAL. This step is required if you intend to call the JAAS API from within a
portlet or if you intend to configure WebSphere Portal for external authorization
using Tivoli Access Manager.
Modify WebSphere Portal Server config files

Modify the WebSphere Portal Server configuration files to enable JAAS as
follows:
1. Modify ConfigService.properties.
a. Navigate to the following directory on the Portal Server node:
b. Modify the ConfigService.properties file as follows:
execute.portal.jaas.login=true
2. Modify callbackheaderslist.properties.
c:\ibm\WebSphere\PortalServer\shared\app\config
b. Modify the callbackheaderslist.properties file as follows by uncommenting
the following entries:
header.1=iv-user
header.2=iv-creds
3. Modify ExternalAccessControlService.properties.
b. Modify the ExternalAccessControlService.properties file as follows:
externalaccesscontrol.pdurl=file:///c:/ibm/WebSphere/AppServer/java/jre/
PdPerm.properties
Configure JAAS in WebSphere Application Server

The following steps add a Tivoli Access Manager specific subclass of
java.security.Principal to the WebSphere Application Server JAAS subject, which
is used for the access control integration with Tivoli Access Manager.
JAAS can be configured within WebSphere Application Server on the Portal

Server node by using the WebSphere Administrative Console or by using a
WebSphere JACL command script.

Note: As an alternative to the procedure we have documented in this section
using the Administrative Console, we have included a JACL command script
with the ITSO example code to configure JAAS within the WebSphere
Application Server for WebSphere Portal:
c:\6325code\config\wps\config.was.jaas.jacl
Ensure server1 on the Portal Server node is running and then enter the
following to execute the JACL command script:
wsadmin -f "c:\6325code\config\wps\config.was.jaas.jacl" -user wpsbind

-password <password>
To configure JAAS within the WebSphere Application Server on the Portal

Server node using the WebSphere Administrative Console, do the following:
Note: This section describes how to create four new JAAS Login Modules that
add Tivoli Access Manager specific subclasses of java.security.Principal to
the WebSphere Portal JAAS subject.
1. Ensure that WebSphere Application Server server1 is started.

2. Start the WebSphere Administrative Console and log in.
a. Enter the URL:
3. Add the com.ibm.wps.sso.WebSealLoginModule to the Portal_Login
Application Login Configuration.
a. From the WebSphere Application Server Administrative Console, select
Security → JAAS Configuration → Application Logins.
b. From the Application Login Configuration page, click Portal_Login.
c. From the Portal Login page, click JAAS Login Modules in the Additional
Properties section.
d. From the JAAS Login Modules page, click New.
e. From the New JAAS Login Modules page, enter the following and then
click OK:
• Module Classname:
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
• Authentication Strategy: Select REQUIRED.
f. From the JAAS Login Modules page, click the following under Module
Classname:
g. Click Custom Properties in the Additional Properties section.
h. Click New.
i. From the New Custom Properties page, enter the following and then click
OK:
• Name: delegate
• Value: com.ibm.wps.sso.WebSealLoginModule
4. Add the com.tivoli.mts.PDLoginModule to the Portal_Login Application Login
Configuration.
b. From the Application Login Configuration page, click Portal_Login.
c. From the Portal Login page, click JAAS Login Modules in the Additional
Properties section.
click OK:
Classname (ensure that you click the second listed module)
h. Click New.
OK:
• Name: delegate
• Value: com.tivoli.mts.PDLoginModule
If you were to now navigate to the Application Login Configuration →
Portal_Login → JAAS Login Modules page, you should see something
similar to Figure 7-11.

Figure 7-11 JAAS Login Modules for Portal_Login
Note: Even though the JAAS Login Modules have the same module
classname, they still are unique given their Name:Value pair in Custom
Properties.
5. Add the com.ibm.wps.sso.WebSealLoginModule to the

Portal_SubjectRebuild Application Login Configurations.
b. From the Application Login Configuration page, click
Portal_SubjectRebuild.
c. From the Portal_SubjectRebuild page, click JAAS Login Modules in the
Additional Properties section.
click OK:
Classname:
h. Click New.
OK:
• Name: delegate
• Value: com.ibm.wps.sso.WebSealLoginModule
6. Add the com.tivoli.mts.PDLoginModule to the Portal_SubjectRebuild
Application Login Configuration.
b. From the Application Login Configuration page, click
Portal_SubjectRebuild.
c. From the Portal_SubjectRebuild page, click JAAS Login Modules in the
Additional Properties section.
click OK:
Classname (ensure that you click the second listed module).
h. Click New.

OK:
• Name: delegate
• Value: com.tivoli.mts.PDLoginModule
If you were to now navigate to the Application Login Configuration →
Portal_SubjectRebuild → JAAS Login Modules page, you should see
something similar to Figure 7-12.
Figure 7-12 JAAS Login Modules for Portal_SubjectRebuild
Note: Even though the JAAS Login Modules have the same module
classname, they still are unique given their Name:Value pair in Custom
Properties.
7. Click Save.
9. Click Logout.
Normally, we would now restart the WebSphere_Portal application server.
However, we will defer this task until after we modify the WebSphere Portal
configuration files.
7.6.3 Modify WebSphere Portal configuration files

This section includes the following modifications to WebSphere Portal
configuration files to enable external authorization using Tivoli Access Manager:
򐂰 Modify the ExternalAccessControlService.properties.
򐂰 Modify AccessControlConfigService.properties.
򐂰 Modify services.properties.
򐂰 Modify AccessControlDataManagementService.properties.
򐂰 Reorder role names (optional).
Modify the ExternalAccessControlService.properties

Modify the ExternalAccessControlService.properties file as follows:
1. Navigate to the <wp_home>/shared/app/config/services directory and open
the ExternalAccessControlService.properties file.
2. Example 7-20 includes the uncommented directives and ITSO example
values in the ExternalAccessControlService.properties file. You may need to
update this file accordingly with values for your environment.
Example 7-20 ITSO example ExternalAccessControlService.properties

# ------------------------------------------------- #
# Properties of the External Access Control Service #
# ------------------------------------------------- #
## This flag indicates whether the configuration in this file

## has been configured to connect to the External Security Manager
externalaccesscontrol.ready=true
## Rolenames representations are qualified with a context built

## by the following parameters. For example, the Administrator@External_Access_Control/xxx/xxx
## is represented in the following ways:
##
## TAM: Protected object space entry
## /WPSv5/Administrator@External_Access_Control/xxx/xxx/WPS/WebSphere_Portal/cell
##
## SiteMinder:
## resource/subrealms under Domain: WebSphere Portal v5
## /cell/WebSphere_Portal/WPS/Administrator@External_Access_Control/xxx/xxx

externalaccesscontrol.server=WebSphere_Portal
externalaccesscontrol.application=WPS
externalaccesscontrol.cell=cell
## ---------------------------------------
## Access Manager configuration
## ----------------------------------------
## After completing the PDJRTE and SrvSslCfg configuration,

## the following directives are needed to
## allow WP to use Access Manager as an External Security Manager
## Provide the root of your Protected Object Space for Portal Server entries
externalaccesscontrol.pdroot=/WPSv5
## Provide and administrative user and password with adequate rights in

## Tivoli to create, delete, modify the objects in the Protected Object Space.
## You can use the WAS PropFilePasswordEncoder utility to mask the password.
## Using PropFilePasswordEncoder will remove any comments and uncommented properties,
## so create a backup copy of this file for future reference.
## Example: <WAS_ROOT>/bin/PropFilePasswordEncoder
## <WPS_ROOT>/shared/app/config/services/ExternalAccessControlService.properties
## externalaccesscontrol.pdpw
## *NOTE* this command is on 3 lines in this file, but should be typed on 1 line
## in a command window.
externalaccesscontrol.pduser=sec_master
externalaccesscontrol.pdpw=<password>
## Specify the location of the Access Manager propeties file for PDJRTE
## This URL must be in the format file:///<path to properties file. http://
## urls are not supported.
externalaccesscontrol.pdurl=file:///c:/IBM/WebSphere/AppServer/java/jre/PdPerm.properties
## (optional) Specify whether to create ACLs in Access Manager for roles stored externally
## If this value is set to false, the Access Manager administrator will be responsible
## for all ACL linkages between TAM and WP
## values:
## true - if an TAM ACL will be created for EVERY resource
## false - if no ACLs will be created for WP objects
externalaccesscontrol.createAcl=true
## (optional) Specify the action group and the customized actions to map to Portal
## role membership. If these items do not exist, they will be created at startup
## default values:
## externalaccesscontrol.pdactiongroup=[WPS]
## externalaccesscontrol.pdAction=m
externalaccesscontrol.pdactiongroup=[WPS]
externalaccesscontrol.pdaction=m

4. Use the WebSphere Application Server encoding mechanism to mask the
password that will appear in the ExternalAccessControlService.properties file,
by performing the following steps:
a. Use the WebSphere Application Server encoding mechanism to mask the
passwords in the live version of the
ExternalAccessControlService.properties file.
The following command masks the sensitive fields and removes all
comments from the file. The original version of the file with the password
in the clear and all comments intact is preserved with a bak extension.
<was_home>\bin\PropFilePasswordEncoder.bat <filename> <property_name>
For example:
c:\ibm\WebSphere\AppServer\bin\PropFilePasswordEncoder.bat
c:\ibm\WebSphere\PortalServer\shared\app\config\services\ExternalAccessC
ontrolService.properties externalaccesscontrol.pdpw
The command will generate the <filename>.bak (for example,
ExternalAccessControlService.properties.bak).
b. The next time you need to change the password, do the following:
i. Copy the backup version of the file over the live version.
ii. Edit this new live file as needed and enter the new password in clear
text.
iii. Save the file.
iv. Run the WebSphere Application Server mechanism on the file.
c. For security reasons, either remove the password from the backup file
with the clear text password (for example,
ExternalAccessControlService.properties.bak), or delete the file.
Modify AccessControlConfigService.properties
To modify the AccessControlConfigService.properties file, do the following:
1. Navigate to the <wp_home>/shared/app/config/services directory.
2. Make a backup copy of the AccessControlConfigService.properties.
3. Modify the following value in the AccessControlConfigService.properties file:
accessControlConfig.enableExternalization=true

Modify services.properties
To modify the services.properties file, do the following:
1. Navigate to the <wp_home>/shared/app/config directory.
2. Make a backup copy of the services.properties.
3. Modify the services.properties file as seen in Example 7-21. Only the last
entry in Example 7-21 needs to be modified. Take note of the value marked in
bold.
Note: Some of the values in Example 7-21 are wrapped to the following
line.
Example 7-21 ITSO example services.properties snippet

com.ibm.wps.ac.impl.AccessControlDataManagementService=com.ibm.wps.ac.impl.AccessControlDataMan
agementServiceImpl
com.ibm.wps.services.ac.PermissionFactoryService=com.ibm.wps.ac.impl.PermissionFactoryImpl
com.ibm.wps.services.ac.ACPrincipalFactoryService=com.ibm.wps.ac.impl.ACPrincipalFactoryImpl
com.ibm.wps.services.ac.internal.AccessControlConfigService=com.ibm.wps.ac.impl.AccessControlCo
nfigImpl
com.ibm.wps.services.ac.AccessControlService=com.ibm.wps.ac.impl.AccessControlImpl
com.ibm.wps.services.ac.ExternalAccessControlService=com.ibm.wps.ac.esm.TAMExternalAccessContro
lImpl
Modify AccessControlDataManagementService.properties
To modify the AccessControlDataManagementService.properties file, do the
following:
2. Make a backup copy of the
AccessControlDataManagementService.properties file.
3. Modify the following values in the
AccessControlDataManagementService.properties file:
accessControlDataManagement.enableNestedGroups=false
accessControlDataManagement.cacheTimeout=30
4. Add the following entries at the bottom of the file if they do not exist:
accessControlDataManagement.externalizeAllRoles=false
accessControlDataManagement.createAdminMappingXMLAccess=true
Note: Explanation of parameters:
򐂰 cacheTimeout: Portal Access Control maintains caches for better
performance of requests. When a role mapping is changed in the
external system, Portal Access Control does not know about these
changes unless the affected user(s) logs out and in again. This property
automatically invalidates the Portal Access Control caches after the
given time (in seconds).
򐂰 externalizeAllRoles: This property is only applicable for externalization
of resources through the user interface. If the property is set to false
and a resource is externalized, the following happens:
a. The resource and all descendants of this resource that are not
private and not externalized so far are externalized.
b. The roles (and the role mappings) that exist on all resources that
were identified in the previous step are written into the external
security manager object space.
c. For the root resource that was chosen to be externalized, a role
mapping for the Administrator role for the executing user is created
in the external security manager object space.
If this property is set to true, then in addition to the three steps above,
roles are created in the external security manager object space for all
action sets for the root resource that have not already been created in
steps b and c.
򐂰 createAdminMappingXMLAccess: This property is only applicable for
externalization of resources through XMLAccess. If the property is set
to false and a resource is externalized, the following happens:
a. The resource will be externalized.
b. The roles that exist (and the role mappings) on the resource are
written into the external security manager object space.
If the property is set to true, then in addition to the two steps above a
role mapping for the Administrator role is created for the executing user
in the external security manager object space.
򐂰 enableNestedGroups: Tivoli Access Manager V5.1.0.2 does not
support nested groups. WebSphere Portal V5.0.2 does support nested
groups, but due to the Tivoli Access Manager limitation we must set this
to false (do not use nested groups).

6. Restart the WebSphere_Portal application server (you can defer this step if
you are planning to implement the reorderRoleNames property).
When WebSphere Portal starts, TAMExternalAccessControlServices creates the

necessary topology in Tivoli Access Manager to begin externalizing roles, and
also creates the Administrator@EXTERNAL ACCESS CONTROL/1 role.
Depending on your configuration setting for externalaccesscontrol.pd_createAcl,
it also adds the <wpsadmin> user to the ACL that is attached to this role.
Reorder role names (optional)

By default, externalized roles appear in the external security manager as Role
Type@Resource Type/Name/Object ID; for example,
Administrator@PORTLET_APPLICATION/Welcome/1_1_1G. You can change
this format to Resource Type/Name/Object ID@Role type. This format change
groups the roles by resource name instead of by role type, for example,
PORTLET_APPLICATION/Welcome/1_0_1G@Administrator. This format
change is visible only when the roles are externalized. This change does not
affect the way roles are displayed in WebSphere Portal. The
Administrator@VIRTUAL/wps.EXTERNAL ACCESS CONTROL/1 role is never
affected by this format change. This role always appears with the role type
"Administrator" on the left.
To reorder the role names when listed, do the following on the Portal Server
node:
2. Make a backup copy of the
AccessControlDataManagementService.properties file.
3. Modify the AccessControlDataManagementService.properties file as follows:
accessControlDataManagement.reorderRoleNames=true
If the property does not exist, add it.
7.6.4 Verify entries in TAM for Portal external authorization

When the WebSphere Portal starts, TAMExternalAccessControlServices creates
the necessary topology in Tivoli Access Manager to begin externalizing roles,
and also creates the core WPS_Administrator-Virtual_wps-EXTERNAL ACCESS
CONTROL_1 role. It also creates an Access Control List (ACL) and adds the
<wpsadmin> user to the ACL. It attaches this ACL to the core role.
To confirm this, execute the following commands in a pdadmin session on the
Reverse Proxy node:
1. Open a command window and log in to pdadmin:
2. Verify the /WPSv5 objectspace has been created by entering the following
command:
objectspace list
You should see the/WPSv5 objectspace in the list.
3. Verify the WPS action group has been created by entering the following
command:
action group list
You should see the WPS action group in the list.
4. To verify that the portal administrator has the Administrator role, view the ACL
for the namespace entry representing the
Administrator@VIRTUAL/EXTERNAL ACCESS CONTROL_1 role by
entering the following command on the pdadmin command line:
acl show WPSv5_Administrator-VIRTUAL_wps-EXTERNAL_ACCESS_CONTROL_1
You should see the following new entry:
User wpsadmin [WPS]m
7.6.5 Example for externalizing a resource

This section includes an example for externalizing a resource. We will use the
WebSphere Portal YourCo Financial pages in the example.
This section includes the following:

򐂰 Externalizing a resource overview.
򐂰 YourCo Financial externalizing a resource example overview.
򐂰 Back up systems prior to externalizing a resource.
򐂰 Externalize the YourCo Financial pages resource.
򐂰 Verify the Tivoli Access Manager object space and ACLs.
򐂰 Verify the YourCo Financial page access.
Externalizing a resource overview

WebSphere Portal V5.0.2.1 can externalize roles, and uses ACLs to control role
membership. From the perspective of the external security manager, these
externalized roles contain only one permission: Membership in the role.
WebSphere Portal always determines the permissions that the portal associates
with each role.

The specifics as to which resources to externalize and the access control to be
applied to them is environment-specific and needs to be analyzed in detail for
each one.
We have set the property externalaccesscontrol.createAcl=true in “Modify the

ExternalAccessControlService.properties” on page 331. This implies that for
each resource role type that is externalized for a particular resource, there is a
dedicated Tivoli Access Manager Access Control List created that is attached to
the resource role type. If you choose to set the
externalaccesscontrol.createAcl=false, you will need to manually create or attach
an existing ACL to the object representing the resource and role type. This
method can be used to implement a more efficient ACL scheme, but requires
more manual maintence.
We will use the YourCo Financial page to illustrate, by example, the behavior of
an externalized resource when externalaccesscontrol.createAcl=true. The
YourCo Financial page will have the Administrator and Privilaged User roles
assigned. Each resource and role combination will have a seperate object and
ACL created in Tivoli Access Manager. In the example of the YourCo Financial
page, the following objects and ACLs will be created as a result of externalizing
the page resource:
򐂰 Objects:
– /WPSv5/CONTENT_NODE_yourCo.Financial_6_0_69@Administrator
– /WPSv5/CONTENT_NODE_yourCo.Financial_6_0_69@Privileged User
򐂰 ACLs:
– WPSv5_CONTENT_NODE_yourCo-Financial_6_0_69-Administrator
– WPSv5_CONTENT_NODE_yourCo-Financial_6_0_69-Privileged-User
Important: When you externalize the roles for a resource, any access control
inheritance from internally controlled parent resources is severed (that is, the
external resource no longer inherits role assignments from the internalized
parent resource). Since, for most resources, the Administrator Role Type is
inherited, it would be lost when a resource is externalized. Access controls
that are explicitly defined will be preserved when externalized.
When externalizing a resource using WebSphere Portal V5.0.2.1, an explicit

assignment of Administrator role will be performed automatically.
YourCo Financial externalizing a resource example overview

This section is included to verify that the configuration for externalizing a
resource is working properly. We will include an example for externalizing
resources for the ITSO Bank application in the Chapter 10, “Deploy the secure
portal application” on page 433.
Table 7-7 defines the YourCo Financial resource permission assignments
defined within WebSphere Portal. As part of the example for externalizing the
YourCo Financial pages resource, we will need to explicitly define the permission
assignments for the pages due to the inheritence being severed.
Table 7-7 YourCo Financial pages resource permission assignments

Privileged
YourCo Financial pages Administrator User User
YourCo wpsadmins
Financial
Home wpsadmins All authenticated anonymous
portal users portal user
My Account wpsadmins All authenticated

portal users
Accounts wpsadmins All authenticated

portal users
Payments wpsadmins All authenticated

portal users
Profile wpsadmins All authenticated

portal users
Contact Us wpsadmins All authenticated

portal users
Company Info wpsadmins All authenticated anonymous

Sales wpsadmins All authenticated anonymous

Customer wpsadmins All authenticated anonymous

Support portal users portal user
Back up systems prior to externalizing a resource

We recommend that you perform system backups prior to externalizing your
resources. Within the ITSO example runtime environment, we performed a
backup of the Portal Server node and the Policy Server node.

Externalize the YourCo Financial pages resource
This section describes how to extrenalize the YourCo Financial pages resource
using the WebSphere Portal Resource Permission portlet.
1. Start the WebSphere Portal Administration Console by entering the following
URL:
https://<webseal_hostname>/portal/wps/myportal
2. Log on as the wpsadmin user.
3. Access the Resource Permission portlet by clicking Administration →
Access → Resource Permissions. You should see a list of resource types
like in Figure 7-13.
Figure 7-13 Resource Permissions portlet - Resource types listed
4. Click Pages under the Resource Type column.

5. Click Content Root in the Page Title column.
6. Click My Portal.
7. To verify the access granted to the YourCo Financial page (and pages under
it by inheritance), click the key icon in the Assign Access column next to
YourCo Financial, as seen in Figure 7-14 on page 341.
Figure 7-14 YourCo Financial Resource Permissions
8. Figure 7-15 on page 342 shows all the possible roles that can be defined for
the YourCo Financial pages resource, and is used to determine which users
or groups belong to a role.
Since role assignments are not inherited for the resource when externalized,
you will need to check all the current role assignments. The inherited role
assignments will need to be defined explicitly.
In our example, we have the following roles:
– Administrator
– Security Administrator
– Delegator
– Manager
– Editor
– Privileged User
– User
The following procedure demonstrates how to examine a role assignement
for the User role. This should be performed for each role listed.
a. Click the pencil icon in the Edit Role column for the User role.
b. In the case of User role, there are no role assignments. Click Done.

Figure 7-15 YourCo Financial Resource Permissions
9. Privileged User role assignment (see Table 7-7 on page 339 for a role
assignment summary).
The Privileged User role assignments for the all authenticated portal users
group were explicitly assigned by default, and thus do not need to be modified
for each of the following pages: Home, My Account, Company Info, Sales,
Customer Support.
10.User role assignment (see Table 7-7 on page 339 for a role assignment
summary).
The User role assignment for the anonymous portal user was explicitly
assigned by default, and thus does not need to be modified for each of the
following pages: Home, Company Info, Sales, Customer Support.
11.Once you are done reviewing the permissions, navigate up the page tree to
Root → Content Root → MyPortal.
12.Click the right-facing arrow in the Externalize/Internalize column.
13.You will be prompted Are you sure you want to place the resource under
External Access Control? Click OK for the process to begin.
When complete, you should see the following message:
APRV4012I: Resource successfully externalized.
14.Click Done. The arrow in the Externalize/Internalize column is not updated
until you click Done and reopen this resource (see Figure 7-16).
Figure 7-16 Externalize resource - Done
Verify the Tivoli Access Manager object space and ACLs

Verify that the objects have been created properly in the Tivoli Access Manager
object space and ACLs have been created. The verification can be performed
using the Tivoli Access Manager pdadmin command line tool or the Web Portal
Manager Web-based interface.
1. Ensure that the server1 application server is started on the Policy Server
node.
2. Start the Web Portal Manager by entering the following URL in a Web
browser:
http://tamwin1.itso.ral.ibm.com/pdadmin
3. Log on as user ID sec_master (since we only have one domain, it is not
necessary to enter the Default domain).

4. To verify that the objects were created in the Tivoli Access Manager object
space, do the following:
a. Select Object Space → Browse Object Space.
b. When the Browse Object Space page appears, expand the / (root) →
WPSv5 by clicking the + symbol, as seen in Figure 7-17.
Figure 7-17 Contents of /WPSv5 object space in Tivoli Access Manager
Note: If you are running WebSphere Portal 5.0.2.1, you may see an
additional role:
Administrator@CONTENT_NODE_yourCo.Financial_6_0_69
Furthermore, the names of your objects may be structured differently if you

chose to reorder role names as per “Reorder role names (optional)” on
page 336.
5. To verify that the ACLs where created properly within Tivoli Access Manager,
do the following:
a. From the Web Portal Manager, click ACL → List ACL.
b. You should see something like Figure 7-18. For verification purposes, click
WPSv5_CONTENT_NODE_yourCo-CompanyInfoPage_6_0_6C-User.
Figure 7-18 List of ACLs in Tivoli Access Manager
c. You should see something like Figure 7-19 on page 346, which should
display the unauthenticated and any other entry type.

Figure 7-19 ACL properties example
Note: The server_application_cell tree structure has been created to form a

so-called unified object. This means that an ACL can only be attached to the
lowest cell-level object of the tree structure. That is, you cannot attach an ACL
to the intermediate levels. If you attempt to do so, you will receive an error
message.
Verify the YourCo Financial page access

Now that the YourCo Financial pages have been externalized and roles have
been assigned, we need to verify the access to the YourCo Financial pages.
1. Verify unauthenticated access.
a. Enter the following URL to access the unauthenticated portal page:
http://wswin1.itso.ral.ibm.com/portal/wps/portal
b. Click YourCo Financial.
You should see the navigation tabs for the Home, Company Info, Sales
and Customer Support pages.
Note: The My Account navigation tab should not be displayed for an

unauthenticated user.
2. Verify authenticated access.

a. Enter the following URL to access the unauthenticated portal page:
b. Log in as jane (the test user we created in “Verify create/login of new user”
on page 321).
c. Click YourCo Financial.
You should see the navigation tabs for the Home, My Account, Company
Info, Sales and Customer Support pages.
You should also see a pencil icon on the portlet skins, which allows the
privileged user to edit portlet settings.
7.7 Integrate the Credential Vault

This section is only required if the portal application makes use of the Credential
Vault service and you want to configure Tivoli Access Manager to store the user
credentials. The ITSO Bank application example does require that the Credential
Vault configuration for WebSphere Portal and Tivoli Access Manager be
completed.
7.7.1 Credential Vault overview

WebSphere Portal includes Credential Service and Credential Vault features to
allow portlet applications to pass user credentials to a back-end application. For
example, the ITSO Bank portlets will retrieve user credentials from the Credential
Vault and pass the credentials to the ITSO Bank back-end application.
The Credential Service contains objects that handle Basic Authentication, LTPA
Token authentication, and simple form-based user ID/password login challenges.
Credentials can take their input identity from the portlet configuration or from the
Credential Vault service. Portlet developers can use the credential vault service

to retrieve credentials from the credential vault. Credential Vault Service objects
can also be used to pass Tivoli Access Manager single sign-on tokens to the
back-end application in the appropriate headers. In the ITSO Bank application
example, the ITSO Bank portlets will retreive the credentials from the credential
vault and use them in remote EJB calls to the ITSO Bank back-end application.
The Credential Vault is a portal service that helps portlets and portal users
manage multiple identities. The Credential Vault stores credentials that allow
portlets to log in to applications outside the portal realm on behalf of the user.
WebSphere Portal provides one simple database vault implementation for
mappings to secrets for other enterprise applications. By default, the Credential
Vault contains an administrator-managed vault segment and a user-managed
vault segment. Administrator-managed vaults allow users to update mappings;
however, users cannot add new applications to this vault.
By default, the WebSphere Portal Credential Vault uses an encryption plug-in

that encodes the passwords in Base 64. When using Tivoli Access Manager with
WebSphere Portal, the credential storage for the Credential Vault can be moved
to the Tivoli Access Manager GSO (Global Sign-on) lockbox. When using Tivoli
Access Manager, the passwords are no longer stored in WebSphere Portal.
7.7.2 Configure the Credential Vault for Tivoli Access Manager

In the ITSO example, we will use the Tivoli Access Manager in the Credential
Vault service. WebSphere Portall includes a vault adapter for Tivoli Access
Manager. Users who are storing credentials in the AccessManagerVault must be
defined in Tivoli Access Manager as global sign-on (GSO) users.
To configure the WebSphere Portal Credential Vault for use with Tivoli Access
Manager, do the following on the Portal Server node:
1. Ensure that you have completed the steps in 7.6.1, “Configure the SSL
between WebSphere and TAM” on page 322.
2. Navigate to the <wp_home>\shared\app\config\services directory.
3. Make a backup copy of the VaultServices.properties file.
4. Add the definitions to the types value in the VaultServices.properties file, as
seen in Example 7-22.
Example 7-22 ITSO sample definitions to add to VaultServices.properties

#Added second type
types=default, accessmanager
#Manually added these lines

accessmanager.vaultadapter=com.ibm.wps.sso.vaultservice.AccessManager41VaultAdapter
accessmanager.config=services/AccessManagerVault.properties
accessmanager.manageresources=true
accessmanager.readonly=false
Note: Our value for accessmanager.vaultadapter differs from the

instructions in the WebSphere Portal V5.0.2 InfoCenter. If you use the
value specified in the InfoCenter, you will generate the following exception
on startup of the WebSphere Portal:
2004.04.29 13:14:54.818 E com.ibm.wps.engine.Servlet init
java.lang.UnsatisfiedLinkError: Can't find library pdlib
(pdlib.dll) in java.library.path
Furthermore, it should be pointed out that by using the

AccessManager41VaultAdapter, we will need to provide a value for pdurl,
as shown in Example 7-23.
5. Create the <accessmanager.config_value> file in the

<wp_home>\shared\app\config\services directory.
Where <accessmanager.config_value> is the value for
accessmanager.config property in Example 7-22 on page 348.
For example:
c:\ibm\WebSphere\PortalServer\shared\app\config\services\AccessManagerVault
.properties
6. Add the lines listed in Example 7-23 to the <accessmanager.config_value>
file (for example, AccessManagerVault.properties).
– Where <sec_master> is an administrator who is defined in Tivoli Access
Manager (for example, sec_master).
– Do not enter a value for the password at this time.
Example 7-23 ITSO sample AccessManagerVault.properties

pduser=sec_master
pdpw=<password>
pdurl=file:/c:/IBM/WebSphere/AppServer/java/jre/PdPerm.properties
7. Use the WebSphere Application Server encoding mechanism to mask the

password that will appear in the AccessManagerVault.properties file by
performing the following steps:
a. Use the WebSphere Application Server encoding mechanism to mask the
passwords in the live version of the AccessManagerVault.properties file.
The following command masks the sensitive fields and removes all
comments from the file. The original version of the file with the password
in the clear and all comments intact is preserved with a bak extension.

<was_home>\bin\PropFilePasswordEncoder.bat <filename> <property_name>
For example (all in one line):
c:\ibm\WebSphere\AppServer\bin\PropFilePasswordEncoder.bat
c:\ibm\WebSphere\PortalServer\shared\app\config\services\AccessManagerVa
ult.properties pdpw
The command will generate the <filename>.bak (for example,
AccessManagerVault.properties.bak).
b. The next time you need to change the password, do the following:
i. Copy the backup version of the file over the live version.
ii. Edit this new live file as needed and enter the new password in clear
text.
iii. Save the file.
iv. Run the WebSphere Application Server mechanism on the file.
For security reasons, either remove the password from the file with the
clear text password (for example, AccessManagerVault.properties.bak) or
delete the file.
8. Ensure that you have configured the SSL connection between WebSphere
Application Server and Tivoli Access Manager, so that the
AccessManagerVault can access the GSO lockbox from within WebSphere
Portal.
For details refer to “Configure the SSL between WebSphere and TAM” on
page 322.
7.7.3 Verify the Credential Vault

In order to verify that the Credential Vault is working properly, we will create a
test case where a test portlet will connect to a Web server resouce that requires
authentication. The portlet will use credentials stored in the TAM database to
authenticate the portlet successfully to the Web server resource.
Create a Credential Vault segment and slot

We will create a test credential vault segment and slot in the TAM database via
the WebSphere Portal Administration interface.
1. Access the WebSphere Portal Administration interface by entering the
following URL in your browser:
2. Log in with the credentials for the WebSphere Portal admin user.
3. Click Administration.
4. Click Access → Credential Vault.
5. Create the Vault Segment.
a. Click Add a vault segment.
b. Enter the following values and click OK:
• Vaults: Select accessmanager(0).
• Vault segment name: WPS-TAM segment
6. Create the Vault Slot.
a. Click Add a vault slot.
b. Enter the following values and click OK:
• Vault: Select accessmanager.
• Name: WPS-TAM Vault Slot
• Vault Segment: Select WPS-TAM segment.
• Vault resource associated with vault slot: Click new radio button and
enter: WPS-TAM GSO Resource
7. Click Log out.
8. Verify that the GSO resource is created in the TAM database:
c. Enter the following command to list servers defined in Tivoli Access
Manager:
rsrc list
You should see the newly created resource WP-TAM GSO Resource.
Create test portlet to verify Credential Vault

We will now use a portlet (for example, the Web Clipping portlet) to verify that the
credential vault is working correctly. We will connect to a test page on IBM HTTP
Server (Portal Node), which requires authentication.
Create test authentication realm and test user on Web server

First, we will need to set up an authentication realm and test user on IBM HTTP
Server.
1. Open the c:\ibm\IBMHTTPServer\conf\httpd.conf in a text editor on the Portal
Server node.
2. Append the information in Example 7-24 on page 352 to the end of the file.

Example 7-24 ITSO Example authentication realm definition in httpd.conf
<Directory "C:\ibm\IBMHttpServer/htdocs/en_US/test">
AuthName "ITSO_Test_Realm"
AuthType Basic
AuthUserFile "C:\ibm\IBMHttpServer/conf/itso.passwd"
require valid-user
AllowOverride None
order allow,deny
allow from all
</Directory>

4. Create the test directory C:\ibm\IBMHTTPServer\htdocs\en_US\test.
5. Create the vault_test.html file (as seen in Example 7-25) and place it in the
directory C:\ibm\IBMHTTPServer\htdocs\en_US\test.
Example 7-25 ITSO Example html in vault_test.html

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>WebSphere Portal Credential Vault test</title>
</head>
<body>
<h1>
Congratulations, your Credential Vault integration was successful!
</h1>
</body>
</html>
6. Create a test user for the ITSO_Test_Realm.

a. Open a command prompt and navigate to C:\ibm\IBMHTTPServer.
b. Execute the following command:
htpasswd -c conf\itso.passwd vault_test
c. When prompte,d enter the new password (for example, passw0rd).
d. Confirm the password.
7. Restart IBM HTTP Server.
8. Verify the newly created authentication realm and test user:
a. Start your browser and enter the following URL:
http://wpwin1.itso.ral.ibm.com/test/vault_test.html
b. When prompted for credentials, notice the realm, ITSO_Test_Realm, and
enter the following:
• Name: vault_test
• Password: passw0rd
You should see the message:
Note: At this point, the credential vault integration has not actually been
proven succesful. We have just confirmed that we can authenticate to our
test realm on the Web server with our test user.
Define a Web Clipping portlet

We will now create a new Web clipping portlet and configure it for our test user
and authentication realm.
1. Access the WebSphere Portal Administration interface by entering the
following URL in your browser:
2. Log in with the credentials for the WebSphere Portal admin user.
4. Click Portlets → Web Clipping.
5. Click New Portlet.
6. Enter the following values:
– Name and default locale title: ITSO Credential Vault Test Portlet
– URL to clip: http://wpwin1.itso.ral.ibm.com/test/vault_test.html
7. Click Advanced Options → Modify authentication options.
8. Select/enter the following authentication options and click Set Credentials:
– Authentication required
– HTTP Basic Authentication
• Realm: ITSO_Test_Realm
9. Select/enter the following credential vault options and click OK:
– Use a vault slot that is not shared.
• WPS-TAM Vault Slot
• User ID: vault_test
• Password: passw0rd
10.Click OK.
11.Click OK.
12.Click Next.

You should see the message displayed in Figure 7-20.
Figure 7-20 Web clipping editor preview page
13.Click Finish.
Create a test page

Now we will create a test page that will contain an instance of our test portlet.
1. Click Portal User Interface → Manage Pages.
2. Click the My Portal page under the Content Root.
3. Click the Welcome page.
4. Click New Page.
5. Enter a title (for example, ITSO Test Page) and click OK.
6. You should see that the page was created successfully. Click OK.
Edit the test page

We will edit the test page to include our test portlet.
1. Click the pencil icon to the far right of ITSO Test Page.
2. Click the Add Portlets button on the left side of the page.
3. Locate your portlet by entering in part of your portlet title in the Search for field
(for example, Search for ITSO) and click Search.
4. Select the test portlet and click OK.
5. Click Done.
Display the test page

We will navigate to our test page to ensure it displays correctly:
1. Click the My Portal link in the upper right corner of the current page.
2. Click the Welcome page (not the Welcome page under Content Publishing).
3. Click ITSO Test Page.
You should see the container for your test portlet display the message:
Verify Tivoli Access Manager control of credentials

We will now confirm that the credentials used by the portlet are actually being
controlled by Tivoli Access Manager. This can be done by modifying the
credentials in Tivoli Access Manager and refreshing our test page.
1. We created a command file called vault-test-acl.pd, as seen in Example 7-26.
The file is included in the ITSO sample code c:\6325code\config\tam
directory.
Example 7-26 ITSO example vault-test-acl.pd

rsrccred modify "WPS-TAM GSO Resource" rsrctype web set -rsrcuser vault_test
-rsrcpwd <dummy_password> user wpsadmin
2. Copy the vault-test-acl.pd command file to the c:\temp directory on the Policy
Server node.
3. Open the file and change the <dummy_password> value to a new password.
vault-test-acl.pd and enter the following command:
pdadmin -a sec_master vault-test-acl.pd
Note: Running the command will change the password in TAM for the
vault_test user from passw0rd to a dummy password.
8. Return to your Web browser, hold down the Shift key, and click the Refresh
button on the browser.

The page should display a message similar to:
Authorization Required
This server could not verify that you are authorized to access the document
requested. Either you supplied the wrong credentials (e.g., bad password),
or your browser doesn't understand how to supply the credentials required.
The portlet can no longer be displayed since the authentication fails against
the Web server due to our password change in Tivoli Access Manager.
9. Open the C:\temp\vault-test-acl.pd on the Policy Server node and modify the
user password from <dummy_password> back to our original password
passw0rd.
10.Save the file.
11.Rerun the pdadmin command and enter the sec_master password to execute
the modified vault-test-acl.pd.
12.Return to your Web browser, hold down the Shift key, and click the Refresh
button on the browser.
13.The page should display the message:
14.Click Log out and close the browser.
7.8 Additional configuration

This section includes addition configuration tasks that may be optional for your
business requirements.
7.8.1 Configure WebSEAL and WebSphere Portal sesssion timeouts

Both WebSEAL and WebSphere Portal establish sessions with the client
browser when initially accessed. These sessions are independent of each other,
but both must be valid in order for the system to work as expected. For a detailed
description of the architecture and considerations for session timeouts refer to
4.2.8, “WebSEAL and WebSphere Portal session considerations” on page 114.
This section includes the following tasks to configure WebSphere Portal and
WebSEAL session timeouts:
򐂰 Modify the WebSphere Portal session timeout.
򐂰 Configure WebSphere Portal to resume timed out sessions.
򐂰 Modify the WebSEAL session timeout.
Modify the WebSphere Portal session timeout
Modify the WebSphere Portal session timeout values on the Portal Server node
from the WebSphere Application Server Administrative Console, as follows:
1. Ensure the server1 application server is started. If not, start the server as
follows:
startServer server1
http://<was_hostname>:9090/admin
3. Log on to the WebSphere Administration Console (for example, wpsbind).
4. Click Servers → Application Servers.
5. Click WebSphere_Portal.
6. Click Web Container.
7. Click Session Management.
8. From the Session Management Configuration page, modify the following
setting and then click OK:
Session timeout:
– Select Set timeout.
– Minutes: 25 (default 30)
Note: Session timeout value (minutes) should be set based on the

business requirements for security and performance. For example, you
may consider reducing this value for high volume Web sites.
9. Click Save.
11.Log out and close the WebSphere Administrative Console.
12.The WebSphere_Portal application server needs to be restarted for this
change to take effect. If you plan on performing the steps in “Configure
WebSphere Portal to resume timed out sessions” on page 357, the restart
can be defered until after that task is complete.
Configure WebSphere Portal to resume timed out sessions

To confiure the WebSphere Portal to resume timed out sessions, do the following
on the Portal Server node:

1. Open a command window and navigate to
c:\ibm\WebSphere\PortalServer\shared\app\config\services.
2. Modify the ConfigService.properties file as follows:
a. Search the ConfigService.properties file for the persistent.session.level.
Note: We chose to accept the default persistent.session.level = 0,

which means that the window state will not be preserved when the
session is persisted.
b. Add the following entry above the persistent.session.level property:

timeout.resume.session = true
Note: By default, WebSphere Portal will invalidate sessions when they

time out.
The timeout.resume.session = true WebSphere Portal will persist the

sessions when they time out instead of invalidating them.
For more detail refer to 4.2.8, “WebSEAL and WebSphere Portal

session considerations” on page 114.
c. Save and close the ConfigService.properties file.

3. The WebSphere_Portal application server needs to be restarted for this
change to take effect.
Modify the WebSEAL session timeout

Modify the WebSEAL session timeout values on the Reverse Proxy node, as
follows:
2. Modify the webseald-default.conf file.
a. Search for inactive-timeout.
b. We recommend that you change the inactive-timeout value from the
default of 600 seconds to match the WebSphere Portal session timeout.
For example, we set the WebSphere Portal session timeout to 25 minutes;
thus the inactive-timeout for WebSEAL is set to 1500 seconds.
inactive-timeout = 1500
Note: The inactive-timeout value should not exceed the WebSEAL
timeout value (located above the inactive-timeout value in the .conf file).
By default, timeout = 3600 seconds. Simply increase the timeout value
to be equal to or greater than the inactive-timeout value.
For more details refer to 4.2.8, “WebSEAL and WebSphere Portal

session considerations” on page 114; and the WebSEAL Administration
3. Save and close the webseald-default.conf file.

4. The WebSEAL needs to be restarted for this change to take effect.
7.8.2 Configure WebSEAL to handle favicon.ico

Some Web browsers have unexpected behavior with the default WebSEAL
configuration attempting to load the favicon.ico.
To configure WebSEAL to handle favicon.ico to work with all Web browsers, do

the following on the Reverse Proxy node:
1. Open a command window and log in to pdadmin.
2. Enter the following acl attach command:
acl attach /WebSEAL/wswin1-default/favicon.ico WP_all_access
Where wswin1-default is the WebSEAL instance and WP_all_access is ACL
that allows access for all users (defined in Example 7-12 on page 306).

8
Chapter 8. Implement the development

environment
This chapter describes how to install and configure a secure portal development
environment on the Windows platform for the ITSO working example. The
development environment defined in this chapter consists of four nodes,
including the Repository node (optional), Development node, the Policy Server
node, and Reverse Proxy node (optional) used for testing.
When implementing the test nodes in the environment, we will note the unique
settings and reference the procedures found in Chapter 6, “Install the runtime
environment” on page 175; and Chapter 7, “Configure the runtime environment”
on page 259.

򐂰 Planning
򐂰 Implement the Repository node (optional)
򐂰 Implement the Policy Server node
򐂰 Implement the Reverse Proxy node (optional)
򐂰 Implement the Development node
򐂰 Configure WebSphere Portal for LDAP
򐂰 Additional configuration (optional)

8.1 Planning
This section describes the scenario for the ITSO working example development
environment, and provides information regarding the hardware and software
levels we used to implement the environment.
8.1.1 Architecture overview

Figure 8-1 depicts the all-in-one secure portal development environment used for
the ITSO working example. For more information on this development
environment topology, refer to 3.3, “Development environment topology
selection” on page 81.
Reverse Proxy Node Development Node

Web
Tivoli WebSphere Portal for
Browser
WebSEAL Test Environment
Client
wsdev1.itso.ral.ibm.com
Portal Toolkit
Other WebSphere Studio

Other Application Developer
Clients
Clients
wpdev1.itso.ral.ibm.com
Policy Server Node

Tivoli Tivoli
Access Directory
Manager Server
WebSphere DB2 Repository Node

Application UDB
Server CVSNT
Server
tamdev1.itso.ral.ibm.com cvsnt1.itso.ral.ibm.com
Figure 8-1 The architecture overview diagram of the development environment
We would like to highlight a few key points regarding the ITSO development
enviornment.
򐂰 Although Figure 8-1 displays four physical nodes, we used VMWare for the
Policy Server node and Reverse Proxy node test nodes.
򐂰 The Development node includes WebSphere Studio Application Developer,
Portal Toolkit, and Test Environment, and is the primary node for
development.
򐂰 The Reverse Proxy node is optional, and only needed if you plan on testing
authentication using the WebSEAL within the development environment.
򐂰 The Repository node is optional, and in our example hosts the CMS system
for source control management.
8.1.2 Hardware used within the ITSO development environment

We used the following hardware within the ITSO working example secure portal
development environment for windows:
򐂰 Repository node
– VMWare image
• 1 CPU, Intel Xeon 2,4 GHz
• 6 GB harddisk
• 1 IBM Ethernet Adapter
• Hostname: cvsnt1.itso.ral.ibm.com
– VMWare image
• 1 CPU, Intel Pentium® 4 1,8 GHz
• 5 GB harddisk
• 1 AMD PCNET Ethernet Adapter
• Hostname: tamdev1.itso.ral.ibm.com
Note: The Reverse Proxy node is optional unless you plan on testing
authentication in your development environment testing needs.
– VMWare image
• 1 CPU, Intel Pentium 4 1,8 GHz
• 5 GB harddisk
• 1 AMD PCNET Ethernet Adapter
• Hostname: wsdev1.itso.ral.ibm.com
򐂰 Development node
– IBM Thinkpad T30 (2366-DG3)
• 1 CPU, Mobile Intel Pentium 4-M 1,8 GHz
• 1024 GB main memory
• 27 GB harddisk
• 1 IBM Ethernet Adapter
• Hostname: wpdev1.itso.ral.ibm.com
Chapter 8. Implement the development environment 363

Note: The configurations described above are not necessarily the minimum
requirements for the setup; only the values for memory were chosen to be as
small as possible.
8.1.3 Software used within the ITSO development environment

We used the following software levels within the ITSO working example secure
portal development environment on Windows.
Table 8-1 Repository node

Software Version
Microsoft Windows 2000 Server Server + Service Pack 4
CVSNT 2.0.4
Table 8-2 Policy Server node

Software Version

IBM GSKit 7.0.1.16
IBM WebSphere Application Server 5.0.2
IBM Tivoli Directory Server 5.2

* Directory Server

* Access Manager Runtime Note: 5.1 + Base Fixpack 2
* Access Manager Java Runtime Environment
(PDJRTE)
Table 8-3 Reverse Proxy node

Software Version
Software Version
IBM GSKit 7.0.1.16

* Access Manager Runtime Note: 5.1 + WebSEAL Fixpack 2 +
* Access Manager Java Runtime Environment Base Fixpack 2
(PDJRTE)
Table 8-4 Development node

Software Version
Microsoft Windows 2000 2000 + Service Pack 4
IBM WebSphere Studio Application 5.1.1

Developer
IBM WebSphere Test Environment 5.0.2.3

included with WebSphere Studio Note: Fixpack 2 + Cumulative Fix 3 +
Application Developer Fixes
IBM WebSphere Portal Toolkit 5.0.2.1
IBM WebSphere Portal Server for test 5.0.2.1

environment

* Access Manager Java Runtime Note: 5.1 + Base Fixpack 2
Environment (PDJRTE)
8.1.4 VMWare
Within the development environment, we implemented the Reverse Proxy node
and Policy Server node in VMware images. This allowed for greater flexability,
including the capability to run the Development node (WebSphere Studio
Application Developer and portal toolkit), Reverse Proxy node, and Policy Server
node on the same physical system with 2 GB of RAM.

8.2 Implement the Repository node (optional)
Within the ITSO development environment, we installed and configured CVSNT
on the Repository node. The details of this configuration can be found in
Appendix C, “CVS configuration” on page 603. This section is optional if you do
not plan on using CVS (for example, using another SCM tool such as
ClearCase®, or you do not plan to use source control).
8.3 Implement the Policy Server node

The Policy Server node in this case will be used for for testing as part of the
development environment. The implementation of this node is the same as
documented in 6.2, “Implement the Policy Server node” on page 182. Within the
development environment, we installed the Policy Server node in a VMWare
image.
We have listed the unique settings for the Policy Server node for the
development environment:
򐂰 Policy Server node hostname in the development environment:
tamdev1.itso.ral.ibm.com
򐂰 Policy Server node WebSphere Application Server node name tamdev1
(used by the Web Administration Tool and Web Portal Manager).
8.4 Implement the Reverse Proxy node (optional)

The Reverse Proxy node in this case is optional to the basic ITSO development
enviornment. The Reverse Proxy node is needed if you plan on configuring the
development test environment for such topics as authentication using the
WebSEAL or configuring authorization with Tivoli Access Manager.
Note: In the development environment we have, in general, weaker
requirements concerning security than in the runtime environment, since all
development activities are usually done in the same network zone with
internal resources, and maybe even internal subnets that are sealed anyway
from the outside. However, if we want to develop applications that modify the
security settings of our runtime environment, we need to test them in the
development environment to supply a thorough development process.
For the reasons mentioned above, we will set up the WebSEAL and Tivoli
Access Manager configuration only with regards to development, not
necessarily security. We have so far set up the different components as in the
runtime environment. Now we have to configure the security settings.
For details on implementing the Reverse Proxy node, refer to 6.3, “Implement the
Reverse Proxy node” on page 218. Within the development environment, we
installed the Reverse Proxy node in a VMWare image.
We have listed the unique settings for the Reverse Proxy node for the
development environment:
򐂰 Reverse Proxy node hostname in the development environment:
wsdev1.itso.ral.ibm.com
򐂰 Tivoli Access Manager - WebSEAL configuration
The Access Manager Policy Server is installed on another machine:
– Host name: tamdev1.itso.ral.ibm.com
– Listening port: 7135
When the LDAP Server information appears, we entered the following:
– LDAP host name: tamdev1.itso.ral.ibm.com
– LDAP port number: 389
In the configuration for the Access Manager WebSEAL enter the following for
the hostname:
– WebSEAL instance name: default
– WebSEAL Server Information hostname: wsdev1
All settings (except the hostnames above) are the same as in the runtime
environment.

8.5 Implement the Development node
This section describes how to install and configure the components of the
Development node, namely the IDE and the test environment.
The Development node is used as the workbench to create and test the portlet
and J2EE applications. The primary components of the Development node are
the WebSphere Studio Application Developer, WebSphere Portal toolkit ,and
portal server test environment. The Development node in our environment will
integrate with the Policy Server node running Tivoli Access Manager Policy and
Authorization Servers, and the Tivoli Directory Server and the Reverse Proxy
node running the Tivoli Access Manager WebSEAL. Optionally, the Development
node can be configured to use the Repository node where CVS is installed.
This section includes the following task to implement the Development node:
1. Windows 2000 installation.
2. WebSphere Studio Application Developer V5.1.1 installation.
3. WebSphere Studio Application Developer V5.1.1 Interim Fix 002 installation.
4. WebSphere Studio Application Developer - WebSphere Test Environment
fixpack installation.
5. WebSphere Portal Toolkit and test environment installation.
6. Verify the Portal Toolkit and Test Environment installation.
7. Java Runtime Environment (JRE) V1.3.1 installation.
8. Tivoli Access Manager Java Runtime Environment installation.
9. Configure the SSL between the WTE and TAM.
10.Verify the TAM configuration within WebSphere Studio.
11.CVS client configuration for WebSphere Studio.
Note: The procedure documented in this section assumes that you have a
clean Windows environment. If you had installed a previous version of
WebSphere Portal toolkit and it was not properly removed, the installation may
fail.
For more detailed information regarding the WebSphere Portal Toolkit

V5.0.2.1 and troubleshooting installation issues, refer to the Installation Guide,
WebSphere Portal Toolkit V5.0.2.1 product guide, found at:
http://www.ibm.com/websphere/portal/toolkit
8.5.1 Windows 2000 installation
This section highlights the key issues addressed when installing Microsoft
Windows 2000 Professional or Microsoft Windows 2000 Sever.
Note: The installation guide for the WebSphere Portall toolkit V5.0.2 states as
a requirement the operation system Microsoft Windows 2000 Professional
with Service Pack 2 or later. In our scenario we used Windows 2000
Professional with Service Pack 4.
Windows 2000 Service Pack 4

In our example, we installed Windows 2000 Service Pack 4.
Windows 2000 service levels

We installed the latest Windows 2000 service level critical updates on top of
Service Pack 4.
8.5.2 WebSphere Studio Application Developer V5.1.1 installation

IBM WebSphere Studio Application Developer V5.1.1 is a prerequisite to IBM
WebSphere Portal Toolkit V5.0.2.1. This section includes the following tasks to
install WebSphere Studio Application Developer and the supporting fixpack.
To install IBM WebSphere Studio Application Developer V5.1.1 for Windows on

the Development node, do the following:
1. Insert IBM WebSphere Studio Application Developer V5.1.1 CD1.
2. Start the installer by running launchpad.exe from the root of the CD.
3. Click Install IBM WebSphere Studio Application Developer from the main
installation page. Note that it takes a few minutes for the Install Shield to
prepare the JVM.
4. When the Welcome to the InstallShield Wizard for IBM WebSphere Studio
Application Developer V5.1 window appears, click Next.
5. When the Software License Agreement window appears, review the terms
and if in agreement select I accept the terms in the license agreement, and
then click Next.
6. When the Location to Install window appears, we entered c:\ibm\wsad and
then clicked Next.

Tip: Do not use the default installation path proposed by the WebSphere
Studio Application Developer installer (C:\Program Files\IBM\WebSphere
Studio\Application Developer\v5.1). The path for the WebSphere Portal
Toolkit must not contain periods (.) or dollar symbols ($).
7. When the Select Features window appears, we checked the following

features (as seen in Figure 8-2), and then clicked Next:
– Check Integrated Development Environment (required).
This option is check automatically (it is greyed out and cannot be
deselected).
– Check Integrated Test Environments.
• Uncheck WebSphere Application Server V5.1.
• Check WebSphere Application Server V5.0.2.
Figure 8-2 WebSphere Studio Application Developer V5.1.1 features selection
8. When the Installation Summary window appears, review the information and
then click Next to begin copying files.
Note: The installation of WebSphere Studio Application Developer V5.1.1

with the features we selected requires approximately 1220 MB of disk
space.
9. When the installation is complete you should see a message stating The
InstallShield Wizard has successfully installed IBM WebSphere Studio
Application Developer V5.1.1. Click Finish.
10.When the WebSphere Studio Installatation Launchpad main window appears,
click Exit.
11.Verify that WebSphere Studio Application Developer V5.1.1 installed
correctly.
a. Start WebSphere Studio Application Developer by clicking Start →
Programs → IBM WebSphere Studio → Application Developer 5.1.1.
b. When you start WebSphere Studio the first time, you will be prompted for
the workspace directory. Do the following and then click OK.
• Change the default location for the workspace to a shorter directory
name (for example, c:\ibm\workspace).
• Uncheck “Use this workspace as the default and do not show this
dialog box again”.
Note: It desireable to select different workspaces (directories) at

startup. For this reason, we recommend that you do not check “Use this
workspace as the default and do not show this dialog box again”
checkbox.
c. Close WebSphere Studio Application Developer.
8.5.3 WebSphere Studio Application Developer V5.1.1 Interim Fix 002

installation
This section describes how to download and install the IBM WebSphere Studio
Application Developer V5.1.1 Interix Fix 002.
1. Download the IBM WebSphere Studio Application Developer V5.1.1 Interim
Fix 002 from:
ftp://www3.software.ibm.com/software/websphere/studiotools/zips/511/wsappde
v511_interim_fix002.zip
Note: If you have problems downloading the file, search for Interim Fix
002 for WebSphere Studio Application Developer v5.1.1 on the
WebSphere Portal support page at:
http://www.ibm.com/software/genservers/portal/support/

2. Unpack the interim fix zip file to a local temporary directory (for example,
c:\temp). After unpacking the zip file you will have a directory structure like the
following:
c:\temp\wsad511\interim_fix002\update
3. Start WebSphere Studio Application Developer by clicking Start →
4. Open the Update Manager by clicking Help → Software Updates → Update
Manager.
5. In the Feature Updates view, expand the My Computer section to open the
directory where you extracted the zip file. For example, select and expand
<temp> → wsad511 → interim_fix002 → update → WebSphere Studio
Application Developer 5.1.1 Interim Fixes, as seen in Figure 8-3.
Where <temp> is the root directory where you unpack the Interim Fix 002 zip
file.
Figure 8-3 Features Update selection for Interim Fix 002
6. Double-click Interim Fix 002 for WebSphere Studio Application Developer

5.1.1.
7. When the Preview window for the Interim Fix 002 for WebSphere Studio
Application Developer 5.1.1 appears, check Install by adding to the
selected updates. The fix will now appear in the Selected Updates window,
as seen in Figure 8-4.
Figure 8-4 Install by adding selected updates for Interim Fix 002
8. Select Interim Fix 002 for WebSphere Studio Application Developer

5.1.1.2.0.0 from the Select Updates window (upper right-hand window).
Right-click and select Process from the context menu.
9. When the Update Tasks window appears, we accepted the default options
and clicked Next.
10.When the Feature Licence window appears, review the terms and if in
agreement select I accept the terms in the license agreement, and then
click Next.
11.When the Optional Features window appears, we accepted the default
features and clicked Next.
12.When the Installation Location window appears, we accepted the default (for
example, c:/ibm/wsad/wstools/eclipse) and clicked Finish.
13.When the Feature Verification window appears, we clicked Install.

14.When the installation is complete you should see a window with the message
You will need to restart the workbench for the changes to take
effect. Would you like to restart now? Click No and close the
workbench.
8.5.4 WebSphere Studio Application Developer - WebSphere Test

Environment fixpack installation
This section describes how to install fixpacks and efixes for the WebSphere Test
Environment of WebSphere Studio Application Developer.

򐂰 Prepare environment for WebSphere Cumulative Fixpack 3.
򐂰 Install WebSphere Application Server Cumulative Fixpack 3.
򐂰 Install WebSphere Application Server V5.0.2.3 efixes.
Prepare environment for WebSphere Cumulative Fixpack 3

Before installing WebSphere Application Server V5.0.2 Cumulative Fix 3, you
need to correct the uninstallation information for fixes installed initially on
WebSphere Test Environment. Otherwise, WebSphere Application Server
V5.0.2 Cumulative Fix 3 will not be able to uninstall these fixes. The WebSphere
Portal Toolkit V5.0.2.1 provides the batch command to correct the uninstallation
information.
To run the batch file to correct the uninstallation information, do the following:
1. Download the WebSphere Portal Toolkit V5.0.2.1 (PortalToolkit5021MP.exe)
from the following URL to a temporary directory (for example, c:\temp):
2. Ensure that WebSphere Studio Application Developer is not running.
3. Start the WebSphere Portal Toolkit self-extracting installer by running
PortalToolkit5021MP.exe from the temporary download directory (c:\temp).
4. When prompted, enter the directory to which you want to extract the
WebSphere Portal Toolkit (for example, c:\temp\PortalToolkit5021), and then
click Next.
5. When Portal Toolkit V5.0.2.1 Installer starts automatically, click Cancel to the
installation. In this case, we simply wanted to extract the Portal Toolkit files to
get access the the fixWTE_forCF.bat script file.
6. Open the command window and navigate the to directory you unpacked the
toolkit (for example, c:\temp\PortalToolkit5021).
7. Run the following script file to fix the WebSphere Studio Application
Developer WebSphere Test Environment:
fixWTE_forCF.bat <wsad_home>\runtimes\base_v5
Where <wsad_home> is the directory where WebSphere Studio Application
Developer is installed.
Install WebSphere Application Server Cumulative Fixpack 3

To install the WebSphere Application Server V5.0.2 Cumulative Fixpack 3, do
the following:
1. Download the WebSphere Application Server V5.0.2 Cumulative Fixpack 3
ftp://ftp.software.ibm.com/software/websphere/appserv/support/fixpacks/was5
0/fixpack2/cumulative/cf3/Windows/was502_cf3_win.zip
2. Unpack the contents of was502_cf3_win.zip to a local temporary directory (for
example, c:\temp\was502.cf3).
3. Ensure that WebSphere Studio Application Developer is not running.
4. Open a command window and navigate to the directory where you have
extacted the cumulative fix 3 (for example, c:\temp\was502.cf3).
5. Set the JAVA_HOME environment as follows:
set JAVA_HOME=<wsad_home>\runtimes\base_v5\java
Where <wsad_home> is the WebSphere Studio Application Developer
installation directory.
6. To start the WebSphere Update Installer, run updateWizard.bat from the
command window.
appropriate language for the wizard (for example, English), and then click
OK.
8. The Update Installation Wizard will launch. Click Next.
10.The WebSphere Update Installer will attempt to detect the current
WebSphere Application Server version. In our example, it did not detect the
WebSphere Application Server location. We manually entered the target
installation directory c:\ibm\wsad\runtimes\base_v5 and then clicked Next.
11.Select Install fix packs and then click Next.
12.Enter the directory where you have copied the fixpack. For example, we
entered c:\temp\was502.cf3\fixpacks in the Fix pack directory text field, and
then clicked Next.

13.Select the was502_cf2_win fixpack (default) and then click Next.
15.When the WebSphere Application Server V5.0.2 Cumulative Fixpack 3
installation is complete, click Finish.
Install WebSphere Application Server V5.0.2.3 efixes

WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) requires additional
WebSphere Application Server efixes to be installed for the WebSphere Portal.
Note: The WebSphere Portal Support Web site requires you to log in as a
registered user (or register first). Once you navigate to the download page you
will see a listing of many fixes. We downloaded the following file: WAS 5.0.2.3
Fixes (WAS5023CumulativeWindows.zip).
It is important to understand that this package is only intended for use on

Windows with WebSphere Application Server V5.0.2.3. For other versions and
platforms, you will need to contact IBM Support or download the individual
efixes from the WebSphere Application Server Support Web site:
http://www.ibm.com/software/webservers/appserv/was/support/
The readme file for WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) can
be found at:
To download and install the WebSphere Application Server V5.0.2.3 efixes, do

the following:
1. Download the WebSphere Application Server V5.0.2.3 Fixes to a temporary
directory (for example, c:\temp):
– Download WAS5023CumulativeWindows.zip (contains all required
WebSphere Application Server V5.0.2.3 fixes) available from the Portal
Server 5.0 Fix pack 2 download page at:
http://www-1.ibm.com/support/docview.wss?uid=swg24006309
Note: Normally, you would need to download the efixes individually
from the WebSphere Application Server Support Web site. However,
there is a file located on the WebSphere Portal Support Web site that
includes all of these efixes and targets, specifically WebSphere
Application Server 5.0.2.3 for Windows.
When you access the above URL, you will first need to click the Portal
Server 5.0 Fix pack 2 link. Next you will need to log in (or register). You
will then see a WAS 5.0.2.3 fixes link to download the fixes
(WAS5023CumulativeWindows.zip).
– Alternatively, download the fixes listed in Table 8-5 individually from the
WebSphere Application Server V5 Support site at:
http://www-306.ibm.com/software/webservers/support.html
2. Unpack the efixes download (WAS5023CumulativeWindows.zip) to a
temporary directory (for example, c:\temp\was5023.fixes).
3. Open a command window and navigate to the directory you have extacted
the fixes (for example, c:\temp\was5023.fixes).
4. Set the JAVA_HOME environment as follows:
set JAVA_HOME=<wsad_home>\runtimes\base_v5\java
Where <wsad_home> is the WebSphere Studio Application Developer
installation directory.
5. To start the WebSphere Update Installer, run updateWizard.bat from the
command window.
8. The WebSphere Update Installer will attempt to detect the current
WebSphere Application Server version. In our example, it did not detect the
WebSphere Application Server location. We manually entered the target
installation directory c:\ibm\wsad\runtimes\base_v5 and then clicked Next.
10.Enter the directory where you have copied the fixes. For example, we entered
c:\temp\was5023.fixes\efixes in the Fix directory text field, and then clicked
Next.
11.When the window appears with a list of fixes, only select the six fixes listed in
Table 8-5, and then click Next.

Note: Do not install other fixes beyond what is listed in Table 8-5. The
installation may fail otherwise.
Table 8-5 WebSphere Application Server V5.0.2.3 Fixes

Fix description
PQ81248
PQ81416
WAS_Adapter_10-30-2003_5.0.2_cumulative_Fix
WAS_CM_08-12-2003_5.0.2-5.0.1_cumulative_Fix
WAS_Dynacache_01-30-2004_5.0.2_cumulative
WAS_Security_12-13-2003_5.0.2.3-5.0.2.2-5.0.2.1-5.0.2-5.0.1-5.0.0_JSSE_cumulativ
e_Fix
12.On the install summary page, review the fixes to be installed or refreshed and
then click Next to begin the installing the fixes.
13.When the WebSphere Application Server V5.0.2.3 Fixes installation is
8.5.5 WebSphere Portal Toolkit and test environment installation

To install the IBM WebSphere Portal V5.0.2.1 Toolkit and Test Environment, do
the following:
Note: For more detailed information on the Portal Toolkit V5.0.2.1 and Test
Environment installation, refer to the Installation Guide, WebSphere Portal
Toolkit V5.0.2.1.
1. Ensure that the WebSphere Studio Application Developer is not running.

2. Ensure the WebSphere Application Server WebSphere Test Environment has
been prepared. Refer to “Prepare environment for WebSphere Cumulative
Fixpack 3” on page 374.
3. Ensure that the prerequiste fixpacks have been installed:
– “WebSphere Studio Application Developer V5.1.1 Interim Fix 002
installation” on page 371
– “Install WebSphere Application Server Cumulative Fixpack 3” on page 375
– “Install WebSphere Application Server V5.0.2.3 efixes” on page 376
4. Download the WebSphere Portal Toolkit V5.0.2.1 (PortalToolkit5021MP.exe)
5. Start the WebSphere Portal Toolkit self-extracting installer by running
PortalToolkit5021MP.exe from the temporary download directory (c:\temp).
6. When prompted, enter the directory to which you want to extract the
WebSphere Portal Toolkit (for example, c:\temp\PortalToolkit5021), and then
click Next.
appropriate language for the wizard (for example, English), and then click
OK.
9. When the Software License Agreement window appears, review the terms
and, if in agreement, select I accept the terms in the license agreement,
and then click Next.
10.When the Select Components to Install window appears, check the following
– Check Portal Toolkit V5.0.2.1.
– Check WebSphere Portal V5.0 for Test Environment.
11.When the Portal Toolkit Summary window appears, review the installation
options and then click Next to start installing files.
12.When the Path Information to the WebSphere Portal installer window
appears, insert the WebSphere Portal Server CD #2. Browse to the
<cd_root>\wps directory containing the wpsinstall.jar file (for example,
WebSphere Portal V5.0 installer f:\wps\wpinstall.jar, where f: is the CD Rom
drive). Click Next.
13.When the WebSphere Portal V5.0 for Test Environment Summary page
appears, review the settings and click Next.
14.When the installation is complete, click Finish.
15.Start WebSphere Studio Application Developer by clicking Start →
16.The first time you start WebSphere Studio Application Developer after the
fixpack and toolkit installation, you will be prompted to apply changes that
have been made to the configuration. Accept those changes by clicking
Finish.
17.You will be prompted to restart of the workbench.

Note: In the ITSO development enviornment, we did not configure local
debug. We choose to debug via print statements.
Tip: Troubleshooting a failed Portal Toolkit and Test Environment installation:
We found that if the Portal Toolkit and Test Environment installation failed, we
had to do the following for it to correctly install afterwards:
򐂰 Uninstall the Portal Toolkit from the Windows Add remove programs.
򐂰 Delete the <wsad_home>\runtimes\portal_v50 and
<wsad_home>\PortalToolkit directories.
򐂰 Rename the vpd.properties file found in the \winnt directory.
򐂰 Search the Windows registry for WebSphere Portal and delete the entries
found.
򐂰 Restart the system.
򐂰 Close all other applications to reduce memory usage and retry the
installation.
For more information on Portal Toolkit V5.0.2.1 installation failures, refer to the
Troubleshooting section in the Installation Guide, WebSphere Portal Toolkit
V5.0.2.1 product guide.
8.5.6 Verify the Portal Toolkit and Test Environment installation

To verify that the installation of the Portal Toolkit and Test Environment
installation was successful, create and run the basic portlet in the test
environment:
1. Start WebSphere Studio Application Developer by clicking Start →
Note: In our example, we defined our default workspace to be

c:\ibm\workspace in 8.5.2, “WebSphere Studio Application Developer
V5.1.1 installation” on page 369. You can create an arbitrary number of
workspaces so that you can put the workspace for your projects on the file
system where you also put the other project documentation.
2. Create a Portlet Application project from the WebSphere Studio Application

Developer workbench by doing the following:
a. Click File → New → Other.
b. Select Portlet Development → Portlet Application Project and then
click Next.
c. When the Define a Portlet Project window appears, enter the following and
then click Finish:
• Project name: ITSOPortletTest
• Select Create basic project.
d. When prompted with the message This kind of project is associated
with the Portlet Perspective. Do you want to swith to this
perspective, click Yes.
3. Run the newly created portlet in the Test environment.
a. Select ITSOPortletTest.
b. Right-click Run on Server.
c. When the Server Selection window appears, enter the following and then
click Finish:
• Select Create a new server.
• Server Type: Select WebSphere Portal v5.0 Test Environment.
You should see server messages in the console view as the server starts.
After the server starts, a Web browser will open showing a page with the
portlet.

For details refer to 6.2.4, “Java Runtime Environment (JRE) V1.3.1 installation”
on page 192.
8.5.8 Tivoli Access Manager Java Runtime Environment installation

This section describes how to install the Tivoli Access Manager V5.1 Java
Runtime Environment and Fixpack 2. The Access Manager libraries are used by
portlets to access and manipulate objects in Tivoli Access Manager.
Install Tivoli Access Manager V5.1 PDJRTE

Refer to “Install Tivoli Access Manager Java Runtime Environment” on page 255
for details.
Install Tivoli Access Manager V5.1 Base Fixpack 2

Refer to 6.2.12, “Tivoli Access Manager V5.1 Base Fixpack 2 installation” on
page 216, for details.

Configure PDJRTE for WebSphere Studio WTE
for the WebSphere Studio Application Developer WebSphere Test Environment
JRE, do the following on the Development node:
Note: This configuration is needed so that the WebSphere Studio Application

Developer WebSphere Test Environment can use the Tivoli Access Manager
APIs.
1. Open a command window and navigate to the c:\ibm\Tivoli\tam\sbin directory.

2. Enter the following command (see Table 8-6 for parameter options):
pdjrtecfg -action config -config_type full -host tamdev1.itso.ral.ibm.com
-port 7135 -java_home c:\ibm\wsad\runtimes\base_v5\java\jre
successfully.
Table 8-6 Options for the pdjrtecfg tool

Parameter Description Value
-action Configure JRE config
-host Policy Server node host name in tamdev1.itso.ral.ibm.com

the development environment
-port Policy Server port 7135
-java_home JRE directory c:\ibm\wsad\runtimes\base_v5\java\jre
3. Afer the command has completed, verify that the PolicyDirector directory has
been created in the c:\ibm\wsad\runtimes\base_v5\java\jre directory. Also,
verify that the PdPerm.properties file has been created in the same directory.
Configure PDJRTE for standalone JRE V1.3.1

for the standalone JRE V1.3.1, do the following Portal Server node:
Note: The Java Runtime Environment included with IBM WebSphere Studio
Application Developer WebSphere Test Environment (V5.0.2.3) is
incompatible with the SvrSslCfg command (used in 7.6.1, “Configure the SSL
between WebSphere and TAM” on page 322). For this reason, we installed the
Tivoli Access Manager Java Runtime Environment V1.3.1 and configured the
Tivoli Access Manager Java Runtime Environment (PDJRTE) to use the
standalone JRE V1.3.1.
1. Open a command window and navigate to the c:\ibm\Tivoli\TAM\sbin

directory.
pdjrtecfg -action config -config_type full -host tamdev1.itso.ral.ibm.com
-port 7135 -java_home c:\ibm\Java131\jre
successfully.
8.5.9 Configure the SSL between the WTE and TAM

The SrvSslCfg command is used to configure the SSL connection between the
WebSphere Test Environment (WebSphere Application Server) and Tivoli
Access Manager. This command creates a keyfile and a properties file.
The SrvSslCfg command also creates the user who is specified as <was_id>,
and inserts this user in the following Tivoli Access Manager LDAP groups:
cn=remote-acl-users
cn=SecurityGroup,secauthority=Default
To configure the SSL connection between WebSphere Application Server used

by WebSphere Portal and the Tivoli Access Manager, do the following:
Note: We found that the Java Runtime Environment included with IBM
WebSphere Application Server V5.0.2.3 (WebSphere Test Environment) is
incompatible with the SvrSslCfg command. For this reason, we installed the
Tivoli Access Manager Java Runtime Environment V1.3.1 and configured the
Tivoli Access Manager Runtime to use the standalone IBM JRE V1.3.1.

1. Open a command window on the Development node, and change to the
following directory:
c:\ibm\Java131\jre\bin
2. Enter the following SvrSslCfg command to configure an SSL connection
between the WebSphere Application Server on the Portal Server node and
Tivoli Access Manager on the Policy Server node:
java com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id sec_master
-admin_pwd password -appsvr_id wps -port 7201 -mode remote -policysvr
tamdev1.itso.ral.ibm.com:7135:1 -authzsvr tamdev1.itso.ral.ibm.com:7136:1
-cfg_file “c:\ibm\wsad\runtimes\base_v5\java\jre\PdPerm.properties”
-key_file “c:\ibm\wsad\runtimes\base_v5\java\jre\lib\security\pdperm.ks”
-cfg_action replace
Note: The ITSO sample code includes the wpdev1_svrsslcfg.bat file found
in the c:\6325code\config\wps directory, which can be modified with the
appropriate values for your environment and then run.
For more detailed information on the SvrSslCfg command refer to 7.6.1,

“Configure the SSL between WebSphere and TAM” on page 322.
When the SvrSslcfg command completes, you should see the message:
The configuration completed successfully.
3. To verify that the SvrSslCfg command worked properly, do the following:
c. Enter the following command to list servers defined in Tivoli Access
Manager:
server list
You should see the newly created server wps-wpdev1, where wps is the
appsvr_id and wpdev1 is the host name of the Development node.
8.5.10 Verify the TAM configuration within WebSphere Studio

This section describes how to create a portlet that uses the Tivoli Access
Manager API with the purpose of verifying the Tivoli Access Manager
configuration within the WebSphere Test Environment. We will use the test
portlet created in 8.5.6, “Verify the Portal Toolkit and Test Environment
installation” on page 380, as a starting point. Next we will insert code that uses
the Tivoli Access Manager API to read some attributes from the server and print
the results to the console.
To create a test portlet to verify the Tivoli Access Manager API in the WebSphere
Test Environment, do the following:
1. Start WebSphere Studio Application Developer on the Development node.
2. First you have to make the libraries available to the project:
a. In the workbench, select your project and select Project → Properties →
Java Build Path.
b. Click the Libraries tab.
c. Click Add Variable.
d. Select WAS_50_PLUGINDIR from the list and click extend.
e. Navigate to the directory java/jre/lib/ext and select the file PD.jar. Click
OK.
f. Click OK and exit the property configuration.
3. Navigate to the ITSOPortletTest → Java Resources → itsoportlettest.
Where ITSOPortletTest is the test portlet project created in 8.5.6, “Verify the
Portal Toolkit and Test Environment installation” on page 380.
4. Open the ITSOPortletTest.java and search for the doView() method.
5. Insert the sample code listed in Example 8-1 into the doView () method.
Example 8-1 ITSO code to verify Tivoli Access Manager APIs in WTE
// TAM test configuration - begin
System.out.println("TAM test configuration - begin" );
PDMessages messages = new PDMessages();
try {
PDAdmin.initialize("MyPortlet", messages);
Locale locale = new Locale("ENGLISH", "US");
String admin = "sec_master";
String pw = "its0ral0";
// the file we specified in the connection setup with SvrSslCfg
java.net.URL configUrl = new
java.net.URL("file:///C:/ibm/wsad/runtimes/base_v5/java/jre/PdPerm.properties");
PDContext context = new PDContext(locale, admin, pw.toCharArray(), configUrl);

ArrayList arrayList = PDUser.listUsers(context, PDUser.PDUSER_ALLPATTERN,
PDUser.PDUSER_MAXRETURN, false, messages);
java.util.Iterator iterator = arrayList.iterator();
// for each object found, try to print it.

while (iterator.hasNext()) {
Object o = iterator.next();
System.out.println("Object found");
System.out.println(o.toString());

}
} catch (PDException e) {
throw new PortletException(e);
}
System.out.println("TAM test configuration - end" );

// TAM test configuration - end
6. After inserting the code we need to import the classes referenced by the
sample code. Select the class, and right-click Source → Organize Imports.
7. Save and close ITSOPortletTest.java.
8. Run the portlet on the server in the test environment and access it through a
browser.
In the console output of WebSphere Studio Application Developer you should
now see some objects from Access Manager, including sec_master and the
development server itself.
Note: The parameter for the connection file location in the code sample above
should be moved inside a configuration file or deployment description of the
Web/portal application, since that location will be specific to the installation.
Now the environment should be ready to develop applications with Tivoli Access
Manager.
8.5.11 CVS client configuration for WebSphere Studio

This section is only required if you are using CVS. For details on configuring the
CVS client with WebSphere Studio Application Developer refer to, “CVS Client
configuration for WebSphere Studio Application Developer” on page 610.
8.6 Configure WebSphere Portal for LDAP

When developing a secure portal application, such as the ITSO Bank, it is highly
desireable to have a development test environment that has the same behavior
as the production runtime environment. This section describes how to configure
WebSphere Portal with the Tivoli Directory Server (LDAP). We will first connect
WebSphere Portal to the previous installed Tivoli Directory Server on the Policy
Server node. Next, we will create users and groups for the ITSO environment.

򐂰 Create a suffix.
򐂰 Import the LDIF file (wp-itso.ldif) to create users and groups.
򐂰 Enable LDAP security for WebSphere Portal.
򐂰 Stop/start servers in WebSphere Test Environment.
򐂰 Verify the LDAP configuration.
򐂰 Disable LDAP security in WebSphere Portal.
Note: For more detailed information, refer to the WebSphere Portal V5.0.2
InfoCenter at:
Search of the following within the InfoCenter:

򐂰 Setting up IBM Directory Server
򐂰 Configuring WebSphere Portal for IBM Directory Server
8.6.1 Create a suffix

To create a suffix from the Tivoli Directory Server - Configuration Tool, do the
following on the Policy Server node, where the Tivoli Directory Server is installed:
1. Stop the Tivoli Directory Server V5.2 Windows service.
2. Start the Tivoli Directory Server - Configuration Tool by clicking Start →
Configuration.
3. Select Manage suffixes under Choose a task.
4. On the suffix page, we entered the following for the ITSO example and then
clicked Add:
Suffix DN: dc=itso,dc=ibm,dc=com
5. Click OK.
8.6.2 Import the LDIF file (wp-itso.ldif) to create users and groups
To import the ITSO-provided wp-itso.ldif file to create users and groups to the
Tivoli Directory Server, do the following on the Policy Server node (where Tivoli
Directory Server is installed in our example):
1. Stop the IBM Tivoli Directory Server V5.2 Windows service.
2. Copy the ITSO-provided c:\6325code\config\ldap\wp-itso.ldif file to a
temporary directory where Tivoli Directory Server is installed (for example,
c:\temp).
3. Start the Tivoli Directory Server Configuration Tool by clicking Start →
Configuration.

4. Select Import LDIF Data.
5. When the Import LDIF Data page appears, we entered the following and then
clicked Import (bottom of page):
– Path and LDIF file name: c:\temp\wp-itso.ldif
– Select Standard import.
After the import has finished successfully, a message will be displayed
reporting how many entries have been imported into the directory server.
6. When the import is complete, click Close. Close the Configuration Tool.
7. Restart the IBM Tivoli Directory Server V5.2 Windows service.
8.6.3 Enable LDAP security for WebSphere Portal

This section describes how to enable LDAP security for WebSphere Portal. In
the runtime environment we chose to prevent WebSphere Portal from writing to
the LDAP directory. We will only allow Tivoli Access Manager to write to the
LDAP directory to ensure consistency and increase security. However, the
default configuration for WebSphere Portal is not set up for read-only LDAP
servers.
In the development environment, we chose to allow WebSphere Portal to have

write access to LDAP, such that developers could potentially develop much of
the secure portal application without the Tivoli Access Manager components.
On the Development node (location of Portal Tookit and Test Environment),

there are pre-configured templates that can be customized to configure
WebSphere Portal for LDAP.
1. Open a command window and navigate to the following directory on the
Development node:
c:\ibm\wsad\runtimes\portal_v50\config
2. Back up the WebSphere Portal configuration properties file
wpconfig.properties to wpconfig.properties.org.
3. Modify the wpconfig.properties file to the values seen in Table 8-2 on
page 389.
For a detailed description of the wpconfig.properties for LDAP security
configuration with WebSphere Portal refer to the InfoCenter at (search for
Configuring WebSphere Portal for IBM Directory Server):
Example 8-2 ITSO example wpconfig.properties values for LDAP security
WebSphere Application WasUserid uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com

Server Properties
WasPassword wpsbind
Note: User ID password set in the wp-itso.ldif.
WpsHostName wpdev1.itso.ral.ibm.com
Note: Hostname of the Development node where

the Portal Tookit and Test Environment are
installed.
Portal Config Properties PortalAdminId uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com
PortalAdminPwd wpsadmin
Note: User ID password set in the wp-itso.ldif.
PortalAdminGroupId cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com
PortalAdminGroupId wpsadmins
Short
WebSphere Portal LTPAPassword wpsbind

Security LTPA and SSO
configuration Note: User ID password set in the wp-itso.ldif.
LTPATimeout 120
SSODomainName itso.ral.ibm.com

LDAP Properties Lookaside false

Configuration
LDAPHostName tamdev1.itso.ral.ibm.com
LDAPPort 389
LDAPAdminUId cn=root
Note: In the runtime environment we set this value

to uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
and made other configuration changes to only allow
portal read-only access to LDAP. In the
development environment, we allow write access to
LDAP directory.
LDAPAdminPwd <password>
Note: The password was set as part of the Tivoli

Directory Server installation in “Set the
administrator DN and password” on page 195.
LDAPServerType IBM_DIRECTORY_SERVER
LDAPBindID uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
LDAPBindPassword wpsbind
Advanced LDAP LDAPSuffix dc=itso,dc=ibm,dc=com

Configuration
LdapUserPrefix uid
LDAPUserSuffix cn=users
LdapGroupPrefix cn
LDAPGroupSuffix cn=groups
LDAPUserObjectCla inetOrgPerson
ss
LDAPGroupObjectCl groupOfUniqueNames
ass
LDAPGroupMember uniqueMember
LDAPUserFilter (&(uid=%v)(objectclass=inetOrgPerson))
Note: We had to manually add this property on the

Development node (portal tookit and test
environment). In the runtime environment, this
property was included.
LDAPGroupFilter (&(cn=%v)(objectclass=groupOfUniqueNames))
Note: We had to manually add this property on the

Development node (portal tookit and test
environment). In the runtime environment, this
property was included.
LDAPsslEnabled false
4. Save and close the modified wpconfig.properties file.

5. From a command window navigate to the following directory:
6. Ensure that the Tivoli Directory Server is started, and enter the following
command to validate the LDAP configuration.
WPSconfig.bat validate-ldap
You should see the message BUILD SUCCESSFUL.
If an error occurs, review the LDAP settings and server. Resolve the problem
before contining to the next step.

7. If the validation was successful, enable security by issuing the following
command:
WPSconfig.bat enable-security-ldap
8. Restart the WebSphere_Portal application server in the WebSphere Test
Environment on the Development node. For details refer to “Start servers in
WebSphere Test Environment” on page 392.
9. If the security enablement was successful you should be able to access the
portal server now at the following URL:
http://wpdev1.itso.ral.ibm.com:9081/wps/portal
Note: Ensure that you have entered the fully qualified hostname (not
localhost).
8.6.4 Stop/start servers in WebSphere Test Environment

The Portal Tookit provides the WPSconfig.bat, which can be used with
parameters to start and stop the WebSphere_Portal and server1 application
servers found in the WebSphere Test Environment of WebSphere Studio
Application Developer.
Stop servers in WebSphere Test Environment

To stop the WebSphere_Portal and server1 application servers, do the following:
1. From a command window, navigate to the following directory:
2. Enter the following commands:
WPSconfig.bat stop-portal-server
WPSconfig.bat stop-admin-server
Start servers in WebSphere Test Environment

To start the WebSphere_Portal and server1 application servers, do the following:
1. From a command window, navigate to the following directory:
2. Enter the following commands:
WPSconfig.bat start-portal-server
WPSconfig.bat start-admin-server
Tip: There are some things you should be aware of when working with the
security enabled within the WebSphere Studio Application Developer
WebSphere Test Environment:
򐂰 Using localhost or just the hostname for accessing the portal might cause
problems after configuring LDAP security. Always use the full qualified
hostname for browsing.
For example:
http://wpdev1.itso.ral.ibm.com:9081/wps/portal
򐂰 There is a difference between the various scripts for starting and stopping
the standalone portal from outside the Application Developer. The
startServer.bat scripts found in the base_v5\bin directory need to get the
credentials passed as parameter, whereas the wpsconfig.bat
start-portal-server command reads the credentials from files that the
setup configured. It is in general more convenient to use the latter. The
same applies to the stop commands.
򐂰 WebSphere Studio Application Developer has a problem with switching an
existing test server to security. So instead of using the existing server that
has been worked with before enabling LDAP security, you should delete
that server in Application Developer and create a new one. Application
Developer will apply the needed security settings during creation.
8.6.5 Verify the LDAP configuration

To verify the WebSphere Portal and LDAP configuration, do the following:
1. Verify that the WebSphere_Portal application server is working properly with
the LDAP configuration and WebSphere security.
a. Ensure that the WebSphere_Portal application server is started. If not,
refer to “Start servers in WebSphere Test Environment” on page 392 to
start the server.
b. Access the WebSphere Portal Server by entering the following URL in a
Web browser:
Important: Using localhost or just the hostname for accessing the

portal might cause problems after configuring LDAP security. Always
use the fully qualified hostname for browsing.
c. From the WebSphere Portal Welcome page, click Log in at the top right
corner. Log in as user ID wpsadmin and password.

2. Verify that the server1 application server and WebSphere Administrative
Console are working properly in the WebSphere Test Environment:
a. Ensure that the server1 application server is started. If not, refer to “Start
servers in WebSphere Test Environment” on page 392 to start the server.
b. Access the WebSphere Administrative Console by entering the following
URL in a Web browser:
http://wpdev1.itso.ral.ibm.com:9090/admin
Where wpdev1 is the hostname of the Development node where the
Portal Toolkit and Test environment are installed.
8.6.6 Disable LDAP security in WebSphere Portal

There are cases when it is desirable to disable security temporarily, such as
when something is not working in the environment and you are troubleshooting.
For this reason, we have added a procedure to easily reverse the steps done
above, to in effect disable LDAP security configuration for WebSphere Portal:
1. Copy the backup of wpconfig.properties you made above back to the
..\portal_v50\config directory.
2. Edit this file and change the following parameters:
WasUserid=wpsbind
WasPassword=wpsbind
This is necessary, since the new username and password were set when
enabling security and are needed for the server adminstration.
3. In the portal_v50 directory issue the following command:
WPSconfig.bat disable-security
You should now be able to use the test environment without the LDAP Server.
8.7 Additional configuration (optional)

Implementing authentication and authorization using the Reverse Proxy node
(WebSEAL) as described in Chapter 7, “Configure the runtime environment” on
page 259, is optional for most cases in the development environment. If you
should choose to set up a WebSEAL in the development environment, the
biggest difference between the development and runtime environment is that the
development environment does not have an external Web Server.
9
Chapter 9. Develop the secure portal

application
This chapter describes the structure of the ITSO Bank application and how to
work with it in the development environment. We have included an architecture
description that includes common requirements for secure portal applications.
From a hands-on perspective, we will first import the ITSO-provided sample

source code for the ITSO Bank application into the development environment.
Next we will guide the reader through a few examples on how to implement key
security-related features of the secure portal application for both Tivoli Access
Manager and WebSphere Portal.

򐂰 Architecture and design of the ITSO example.
򐂰 Prepare the workbench for the ITSO Bank example.
򐂰 Using the Tivoli Access Manager APIs.
򐂰 Using the WebSphere Portal Credential Vault.

9.1 Architecture and design of the ITSO example
This section outlines the ITSO Bank secure portal application architecture,
deployment units, and method level security.
9.1.1 Architecture
The architecture of the ITSO Bank sample application consists of a presentation
layer that uses an EJB-based layer, which accesses a database layer. Figure 9-1
depicts an overview of the ITSO Bank application architecture.
Presentation Layer
JSPs Portlets
Model
View
Controller
Data Beans
Manager
Session
Facade
EJB Layer
Trans- Entity
Accounts Users
History Beans
Accounts
Database Layer
ISTOID DATEJOINED ACCOUNTNUMBER

Transhistory
HISTORY HIST TIMEUsers
ITSOID
ISTOID PREFIX FIRSTNAME ...
Figure 9-1 ITSO Bank application architecture overview
Presentation layer
The presentation layer is the part of the application that is visible to the user. The
presentation layer consists of portlets, JSPs, and data beans, as well as
additional helper classes if needed.
The ITSO Bank portlets for the presentation layer are as follows:
򐂰 ITSOUser
The ITSOUser portlet manages users. This portlet will access the LDAP
directory for general user actions and the bank database for more specific
information.
򐂰 ITSOAccountBalance
The ITSOAccountBalance portlet is used to read and display the account
details.
򐂰 ITSOTransfer
The ITSOTransfer portlet is used to transfer funds between accounts.
򐂰 ITSOTransHistory
The ITSOTransHistory portlet is used to show the transaction history.
Each of the four portlets has an associated JSP that defines the basic layout of
the portlet. In addition to JSPs, the portlets have a data bean that encapsulates
the data that is passed between portlet and back-end. Each of the portlets has an
associated view bean that is used to encapsulate the data passed to the JSP.
These view beans are not displayed in the architecture overview diagram seen in
Figure 9-1 on page 396. This is a classical implementation of the
Model-View-Controller pattern, where the data bean is the model, the JSP the
view, and the portlet the controller.
EJB layer
The EJB layer performs the communication and transaction from the portlet to
the database and consists of two sub layers:
򐂰 Entity beans relating directly to database tables.
򐂰 A session bean that acts as an implementation of the session façade pattern
to prevent the direct use of the entity bean interfaces. This bean implements
method level security as described in 9.1.3, “Method level security” on
page 400.
Whenever information is requested by the presentation layer, the request is

always routed through the session bean, which in turn invokes the appropriate
calls for the entity beans and retrieves the result.
The EJB layer contains implementation classes specific to the DB2 database
deployment of the runtime environment. However, throughout this chapter, we
will generate deployment code for the Cloudscape database within the
development environment. We chose to use Cloudscape in the development
environment to lighten the memory requirements of the Development node
system during application development, and thus have a more responsive
Chapter 9. Develop the secure portal application 397

development system. The choice of using Cloudscape over DB2 in the
development environment does not impact the application source code for the
ITSO Bank sample application.
Note: The EJB Layer is indeed independent from the database vendor. The
code can be generated for several vendors and included in the project. The
only specific code to a certain implementation is the database binding in the
WebSphere binding files.
Database layer
The database layer consists of the following tables that contain the relevant
information needed for the ITSO Bank sample application:
򐂰 Users
򐂰 Accounts
򐂰 Transhistory
An invocation of the manager session bean will result in the invocation of one or
more entity beans, and therefore read from or write to one or more database
tables. The table information is included in the Table.ddl file that is included in the
EJB project. As part of the application deployment in the runtime environment,
the Table.ddl will be applied manually to the ITSO Bank database. In the
development environment, this task will be performed with wizards available in
WebSphere Studio Application Developer.
Helper classes
The helper classes contained in the portlet archive supports the creation of new
users in the LDAP directory and in Tivoli Access Manager. The helper classes for
LDAP and Access Manager are triggered only from the user portlet and the user
data bean. Note that only the user portlet that uses the Access Manager helper
(TAMHelper) writes to the LDAP directory.
The operations on Access Manager always follow the operations on the LDAP
directory, since the user has to be created in LDAP first, and then the Access
Manager operation can be executed to add additional attributes to the LDAP
directory and register the users in Tivoli Access Manager.
If you want to remove the Access Manager part from the application (for
example, if the environment is not completely set up yet or if you do not desire
those security features), simply uncomment the TAMHelper calls (as shown in
Example 9-1 on page 399) that are used in the ITSOUser.java class. The
application will work exactly the same way, but there will be no users added to the
Tivoli Access Manager users that are allowed to access the general
infrastructure through WebSEAL.
Example 9-1 Disabling the Access Manager import
...
LDAPHelper.addUser(itsoUserBean, log);
// write operation on TAM removed.
//TAMHelper.importUser(itsoUserBean);
...
9.1.2 Deployment units

The ITSO Bank sample project consists of several deployment units, which are in
logical groupings of code and configuration files that can be deployed in a
standardized way to the development and runtime environments. The number,
scope and definition of deployment units may be subject to discussion; however,
we will take those entities as deployment units that appear as different folders in
our development environment. The folder structure for the ITSO Bank
deployment units is displayed in Figure 9-2.
ITSOBankEAR.ear META-INF/application.xml
ITSOBankEJB.jar
ITSOBankWAR.war WEB-INFf/web.xml
WEB-INF/portlet.xml
WEB-INF/classes
WEB-INF/lib/ITSOBankEJB.jar
com_ibm_itso_bank_portlets/jsp/html
Figure 9-2 ITSO Bank: Internal structure of the deployment units
Note: All deployment units also contain the source code. Since the source
code is not needed for the deployment on the runtime, it will not be mentioned
explicitly.

ITSO Bank back-end enterprise archive (*.ear)
The ITSO Bank example includes one enterprise archive (*.ear) package named
ITSOBankEAR.ear. This file contains the EJB project ITSOBankEJB.jar, as well
as the application deployment descriptor application.xml, located in the
META-INF directory. The EJB subcomponets will be described below.
ITSO Bank front-end portlets (*.war)

The Web module ITSOBankWAR.war contains the *.class files for the portlets
and JSPs that form the portlet front-end. Additionally, the Web and portlet
deployment descriptor (web.xml and portlet.xml) are packaged in the *.war file.
The *.war archive also contains the EJB module as a client. This relationship is
represented by an entry in the WebSphere Studio Application Developer
deployment descriptor, which maps the files but does not map to the Web
deployment descriptor web.xml.
ITSO Bank back-end EJB module

The EJB module ITSOBankEJB.jar contains three entity beans that map to the
different database tables and a session bean that acts as an object described
through the session façade pattern. This file is used inside the enterprise archive
as the EJB module and separately inside the portal application as an EJB client.
The client EJB could be stripped down, since only the front-end interfaces are
needed for the client, in this case only the classes of the Manager session bean.
9.1.3 Method level security

The Manager EJB in the back-end application is configured to use method level
security that is mapped to two roles, ITSOManagers and ITSOCustomers. These
roles are defined in the EJB deployment descriptor ejb-jar.xml by the
security-role element, as seen in Example 9-2.
Example 9-2 Defining the ejb security roles

<assembly-descriptor>
<security-role>
<description>Customer</description>
<role-name>Customer</role-name>
</security-role>
<security-role>
<description>Manager</description>
<role-name>Manager</role-name>
</security-role>
...
</assembly-descriptor>
The ITSOManagers role is allowed to execute all remote methods on the
Manager EJB, whereas the ITSOCustomers role is limited to remote methods
listed in Table 9-1.
Table 9-1 Access permissions of the ITSOCustomers role on the manager EJB
Method Triggered by portlet
getAccounts ITSOAccountBalance
getAccountsData ITSOAccountBalance
transfer ITSOTransfer
createTransHistoryData ITSOTransfer
The restrictions to methods are achieved by defining the method-permissions

element in the deployment descriptor, as seen in Example 9-3. WebSphere
passes the information about the current user implicitly to the back-end server.
Example 9-3 Defining method level security
<method-permission>
<role-name>Customer</role-name>
<method>
<ejb-name>Manager</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getAccounts</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
...
</method-permission>
9.2 Prepare the workbench for the ITSO Bank example

This section describes how to set up the WebSphere Studio Application
Developer workbench with the ITSO Bank sample application code in
preparation for development, testing, and debugging.
The preparation of the workbench includes the following tasks:

򐂰 ITSO Bank sample code download and unpack.
򐂰 Import the sample project into the workbench.
򐂰 Team development.
򐂰 Prepare the database.

򐂰 Prepare the back-end EJB server.
򐂰 Prepare the front-end portal server.
Note: The import of the source code can be done either from the EAR file or
from some previously set up version control system, thus the steps in “Import
the sample projects from CVS” on page 407 are optional if you are not using a
version control system.
9.2.1 ITSO Bank sample code download and unpack

This section describes the process for downloading the ITSO sample code
6325code.zip and unpacking the zip file.
1. Download the ITSO sample code 6325code.zip file at:
ftp://www.redbooks.ibm.com/redbooks/SG246325
Note: For a description of the ITSO sample code and where to download it,
refer to Appendix F, “Additional material” on page 683.
2. Unpack the 6325code.zip file. For example, we unpacked the zip to the
c:\6326code directory.
9.2.2 Import the sample project into the workbench

This section describes how to import the sample code into WebSphere Studio
Application Developer, set up the application database, and set some variables
that are unique for the given development environment.
Import the back-end EAR into the workbench

To import the back-end ITSOBankEAR.ear into the workbench, do the following:
1. Start WebSphere Studio Application Developer on the Development node.
2. Select File → Import.
3. From the Select window, select EAR file and click Next.
4. When the Enterprise Application Import window appears, do the following:
– EAR file: Click Browse and select the ITSOBankEAR.ear file from ITSO
sample code c:\6325code\deploy directory.
– Project: ITSOBankEAR
– Click Finish.
Note: WebSphere Studio treats every Web project as part of an enterprise
project, so a plain import of a *.war file in the workbench where only one EAR
project exists will automatically add the Web project in the *.war file to the
EAR project. This is not desired for the ITSOBankEAR project.
If the import adds the ITSOBankWAR module to the EAR deployment

descriptor of the ITSOBankEAR project, remove it manually. If the EAR project
DefaultEAR exists in the workbench, the *.war project will be added to this
EAR project.
Import the front-end WAR into the workbench

To import the front-end ITSOBankWAR.war into the workbench, do the following:
1. Select File → Import.
2. From the Select window, select WAR file and click Next.
3. When the WAR File Import window appears, do the following:
– WAR file: Click Browse and select the ITSOBankWAR.war file from ITSO
sample code c:\6325code\deploy directory.
– Project: Click New to create a new project, enter ITSOBankWAR as the
project name, and then click Finish.
4. You should see the Repair Server Configuration window, which will add the
WAR to the DefaultEAR. Click OK.
5. Click Finish.
6. Click the Project Navigator view. The errors in the project occur due to some
missing variables, which will be configured in the next section.
Define the library variables

The ITSO Bank application requires some variables to be defined for the
workbench. These variables and their values are listed in Table 9-2 on page 404.
To set up the variables, perform the following steps to set the variable values for
each of the variables listed in Table 9-2 on page 404:
1. Select Window → Preferences.
2. From the Preferences window, select Java → Classpath Variables.
3. From the Classpath Variable window, do the following:
– If the variables listed in Table 9-2 on page 404 are present, select the
variable and click Edit to change the value accordingly for your
environment.

– If the variables listed in Table 9-2 on page 404 are not present, click New.
Enter the variable name and value.
4. Click OK and repeat the steps for each variable in Table 9-2.
5. Close the Preferences window by clicking OK.
6. If prompted by WebSphere Studio Application Developer to perform a full
rebuild, click Yes and check the workbench afterwards for errors.
Note: The values for the variables mentioned in Table 9-2 are specific to the
installation path for the Development node.
Table 9-2 Variables needed for the ITSO bank example

Variable name Value (examples)
WPS_LIB c:/ibm/wsad/runtimes/portal_v50/shared/app
WPS_TRANS_LIB c:/ibm/wsad/runtimes/portal_v50/IBMTrans/lib
XML_API_LIB c:/ibm/wsad/wstools/eclipse/plugins/com.ibm.etools.xalanrt_2.3.11
WPS_V5_PLUGINDIR c:/ibm/wsad/wstools/eclipse/plugins/com.ibm.wps_v5_5.0.2
WCM_PLUGINDIR c:/ibm/wsad/wstools/eclipse/plugins/com.ibm.wcm.resource.wizards_5.0.0.20
040219_2218
Define the project dependencies

After defining the library variables, we need to define which library variables will
be used by the ITSOBankWAR project.
To define the which variables are used by the ITSOBankWAR project, do the
following:
1. Select the ITSOBankWAR project.
2. Select Project → Properties from the menu bar.
3. From the Properties for ITSOBank window, select Java Build Path.
4. Click the Projects tab.
5. From the Java Build Path window for Projects, check the ITSOBankEJB
project.
6. Click the Libraries tab.
7. Add the variable extension.
a. Click Add Variable.
b. Select WAS_50_PLUGINDIR/java/lib/ext/PD.jar and click Extend.
c. Select wps.jar from the list and click OK.
8. Repeat step 7 for all variables listed in Table 9-3 on page 405.
When all variables have been defined, the ITSOBankWAR project should not
contain any errors and the workbench should look like Figure 9-3 on page 406.
This includes the projects just imported, as well as the portal application project
and default EAR project created when validating the WebSphere Studio
Application Developer installation.
Table 9-3 Variable extensions needed for the ITSOBankWAR project

Project Variable Variable extensions
ITSOBankWAR SERVERJDK_50_PLUGINDIR SERVERJDK_50_PLUGINDIR/jre/lib/rt.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/java/lib/ext/PD.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/dynacache.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/j2ee.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/ras.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/runtime.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/servletevent.jar
WPS_LIB WPS_LIB/jlog-2.2.1.jar
WPS_V5_PLUGINDIR WPS_V5_PLUGINDIR/portlet-api.jar
WPS_V5_PLUGINDIR WPS_V5_PLUGINDIR/wps.jar
WPS_V5_PLUGINDIR WPS_V5_PLUGINDIR/wpsportlets.jar
Note: When importing the projects from an existing CVS repository, these
variable extensions probably do not need to be performed, since the
.classpath file is checked into CVS (as opposed to the EAR archive).

Figure 9-3 Application Developer workbench after the application import
9.2.3 Team development

This section describes how to share an existing project with other developers by
using a source control management software such as CVS.
Sharing the project with other developers

The projects can be easily shared through the usage of a version control system
such as CVS. The version control system is often used by many developers and
many projects concurrently, so it is useful to choose a common prefix to all
workspace projects in the sample application. For example, we will use itsobank
as a prefix.
To share the projects with other developers using CVS, do the following:
1. Open the context menu (right mouse button) on a project and choose
Team → Share Project.
2. Choose the existing repository location and click Next.
3. Choose to use a specific module name and enter the above-mentioned
common prefix in front of the project name (see Figure 9-4).
4. Click Next and Finish to share the project.
After those steps, the changes have to be committed to the repository.
Figure 9-4 A common prefix for all workspace projects
Import the sample projects from CVS

Once the project is shared it is very easy for other project members to check out
the sources into their workbenches. Do get the sources into the workbench. After
it was checked in as described above, perform the following steps:
1. Open the CVS perspective in the workbench.
2. Expand the server and the HEAD section. You will now see the ITSOBank
folder.
3. Expand this folder and select all containing subfolders by holding down the
Shift key.

4. Open the context menu (right mouse button) and select Check out as
Project. This will move the different subprojects into your workbench.
You can now switch to the J2EE perspective of WebSphere Studio Application
Developer, set the variables as described in “Define the library variables” on
page 403, and continue working on the project.
9.2.4 Prepare the database

The ITSO Bank application needs a database to store all relevant banking
information. In the runtime environment we create a DB2, whereas in the
development environment we will use the preconfigured Cloudscape database.
All the following steps will be performed in the J2EE perspective and the J2EE
hierarchy view of WebSphere Studio Application Developer.
Attention: WebSphere Studio Application Developer and the Cloudscape

administration tool will each block the database, so do not use both tools at
the same time on the same database.
Create the database

Before we can connect to the database, we have to create the database
manually as follows:
1. Open a command prompt and navigate to the directory containing the
Cloudscape admin tool cview. For example, we navigated to the following
directory:
c:\ibm\wsad\runtimes\base_v5\cloudscape50\bin
2. Open the Cloudview administration interface by running cview.bat.
3. Create a new database by selecting File → New → Database.
4. When the New Database window appears, click the Database tab (default),
and enter the full path and name of the database and then click OK. For
example:
– Name: c:\ibm\wsad\itsobank
Where itsobank is the name of the database and c:\ibm\wsad\itsobank is the
path.
5. Click File → Exit to close the Cview tool.
Tip: Should you need to delete the Cloudscape database, simply delete the
directory on the file system where the database was created.
Create the EJB mapping for the database
As described in 9.1.1, “Architecture” on page 396, we will use an EJB layer to
connect to the newly created database.
To create the EJB mapping for the newly created itsobank database, do the
following:
1. From WebSphere Studio Application Developer, select J2EE perspective →
J2EE Hierarchy View.
2. Expand the EJB Modules.
3. Select the ITSOBankEJB module.
4. Right-click and select Generate → EJB to RBD Mapping.
5. When the EJB to RDB Mapping window appears, do the following:
a. Select Create a new backend folder and click Next.
b. Select Top Down and click Next.
c. When the Select Top Down Mapping Options window appears, do the
following and then click Finish:
• Target Database: Select Cloudscape, V5.0.
Note: Ensure you select Cloudscape, V5.0. By default Cloudscape

V5.1 is highlighted.
• Database name: itsobank

• Schema name: APP
• Accept defaults for other options.
This will create the EJB to RDB mapping and an entry in the Databases
section in the J2EE perspective.
Create the database connection and tables

To create to the database connection and tables, do the following:
1. From WebSphere Studio Application Developer, select the J2EE
perspective → J2EE Hierarchy View.
2. Select Databases → ITSOBankEJB: itsobank (Cloudscape, V5.0).
3. Right-click and select Export to server.
4. When the Data Export window appears, we accepted the default settings and
clicked Next.
5. When the Data Export Options window appears, we accepted the default
settings and clicked Next.

6. When the Database Connection window appears, we entered the following
(see Figure 9-5 on page 410), and then clicked Finish:
– Connection name: ITSOBank
– Database: itsobank
– Database Vendor Type: Select Cloudscape, V5.0.
Note: Ensure you select Cloudscape, V5.0. By default Cloudscape

V5.1 is highlighted.
– JDBC Driver: Select Cloudscape Embedded JDBC Driver.

– Database location: c:\ibm\wsad\itsobank
– Class location: c:\ibm\wsad\runtimes\base_v50\lib\db2j.jar
Figure 9-5 Database Connection for itsobank database using Cloudscape
Note: We found that the wizard would sometimes fail with an error
message stating that the database server could not be started. Running
the wizard again resolved this problem.
7. WebSphere Studio Application Developer will now validate the connection

and create the tables according to the schema definition. It will fail to create
the schema APP because it already exists (this is not a problem), as seen in
Figure 9-6. Click Commit changes.
Figure 9-6 Confirm export results window
8. Configure the back-end ID to Cloudscape, as follows:

a. Select the J2EE perspective → Project Navigator view.
b. Select the ITSOBankEJB project.
c. Double-click EJB Deployment Descriptor to open the descriptor.
d. Select the Overview tab and scroll to the very bottom.
e. Select CLOUDSCAPE_V50_1 for the back-end ID.
f. Select File → Save.
g. Close the EJB Deployment Descriptor.

9.2.5 Prepare the back-end EJB server
To build a test environment similar to the production environment, two separate
servers will be used in the development environment (server for portal front-end
and a server for the EJB back-end).
Note: It is possible to set up the portal front-end and EJB back-end on the
same server. In this case do not use an URL, as introduced in the
programming example below, when obtaining an initial context for JNDI
lookup. Just use the JNDI name.
Create the back-end server

In Chapter 8, “Implement the development environment” on page 361, we
configured the portal server test environment. In this section we will create a
separate back-end server in the WebSphere Test Environment to deploy and run
the EJB back-end for the ITSO Bank application.
To create server1 as the back-end server within the WebSphere Test

Environment, do the following:
1. Open the Server perspective in WebSphere Studio Application Developer by
selecting Window → Open Perspective → Other → Server.
2. Select File → New → Server and Server Configuration.
3. When the Create a new server and server configuration window appears, do
the following and then click Finish:
– Server name: server1
– Folder: Select Servers (default).
– Server type: Expand WebSphere version 5.0 and select Test
Environment.
4. Select Finish and the new server will be created.
Create the authentication alias

To create the authentication alias, do the following:
1. From WebSphere Studio Application Developer, select the Server
perspective.
2. From the Server Configuration window, expand Servers and double-click
server1 to open the server configuration.
3. Click the Security tab.
4. Click Add under JAAS Authentication Entries.
5. When the Edit JAAS Authentication Entries page appears, enter the following
and then click OK:
– Alias: localhost/ITSOBankAlias
– User ID: wpsadmin
– Password: wpsadmin
– Description: ITSO Bank Alias
6. Click File → Save.
Define the data source for the ITSO Bank application

To define the data source for the ITSO Bank application, do the following:
perspective.
2. From the Server Configuration window, expand Servers and double-click
server1 to open the server configuration.
3. Click the Data source tab of the server configuration.
4. If there is an existing entry for a DB2 JDBC provider, remove this entry.
5. Click Add to add a JDBC provider for Cloudscape.
6. When the Create a JDBC Provider window appears, do the following and then
click Next:
– Database type: Select Cloudscape.
– JDBC provider type: Select Cloudscape JDBC Provider.
7. When the Create a JDBC Provider - Select type of JDBC provider window
appears, do the following and then click Finish:
– Name: ITSO JDBC Provider
– Accept default for other options.
Now the JDBC Provider will be listed in the server configuration.
8. Select the ITSO JDBC Provider from the JDBC provider list.
9. Click Add for the Data source defined in the JDBC provider selected above
heading.
10.When the Create a Data Source - Select the type of data source window
appears, do the following and then click Next:
– Select the type of JDBC provider: Select Cloudscape JDBC Provider.
– Select the data source type: Select Version 5.0 data source.
11.When the Modify Data Source window appears, we entered the following (as
seen in Figure 9-7 on page 414), and then clicked Finish:
– Name: ITSODataSource
– JNDI name: jdbc/ITSO

– Description: ITSO Data Source
– Component-managed authentication alias: localhost/ITSOBankAlias
Figure 9-7 Create a data source
12.Under the heading Resource properties defined in the data source selected
above, scroll up and select databaseName. Click Edit.
13.When the Edit a resource property window appears, enter the path to the
database in the value field (for example, c:\ibm\wsad\itsobank) and then click
OK.
When done, the data source definition for the back-end EJB should look like
Figure 9-8 ITSO Data Source definition for the back-end EJB
14.Select File → Save and then close the server configuration file.
Configure security role mapping

To configure security role mapping to test the ITSO Bank, we will need to modify
the deployment descriptor for the enterprise application as follows:
perspective → J2EE Hierarchy View.
2. Select the ITSOBankEAR project, and double-click the EAR Deployment
Descriptor.
3. Click the Security tab.
4. Define the ITSOCustomer role mapping.

a. Select the ITSOCustomer role.
b. Check All authenticated users under WebSphere Bindings.
5. Define the ITSOManager role mapping.
a. Select the ITSOManager role.
b. Check Users/Groups under WebSphere Bindings.
c. Click Add. Enter wpsadmin in the User name field and click Finish.
6. Select File → Save and close the file.
Deploy and test the EJBs

The EJBs can be tested with the WebSphere Universal Test client to make sure
that the database connection is working properly.
To deploy and test the EJBs, do the following:

perspective.
2. Expand Servers and double-click server1 to open the server configuration.
3. Click the Configuration tab.
4. Check Enable universal test client.
6. Expand Servers and select server1.
7. Right-click and select Add and remove projects.
8. Select the ITSOBankEAR project, click Add, and then click Finish.
9. Expand Servers and select server1.
10.Right-click and select Publish.
11.You should see the message Publishing was successful. Click OK.
12.Expand Servers and select server1.
13.Right-click and select Start.
We chose this way of deploying the project since we do not want any other
projects to be published on the server. Now the EJB test client can be
launched.
Note: If a database connection is active, close it.

򐂰 Select the Data perspective.
򐂰 Under DB Servers view, select the active connection, and right-click
Disconnect.
14.Select the ITSOBankEJB project, right-click, and select Run on Server.
15.When the Server Selection window appears, select Use and existing server
and then server1. Click Next.
16.If this is the first deployment of the EJBs, select Deploy EJB beans and click
Finish.
17.An external or internal browser should open, depending on your workbench
settings, that will display the test client. Click JNDI Properties.
18.When the JNDI Properties page appears, enter wpsadmin for the user and
password. Click Set.
This will result in an authenticated call matching the security settings defined
in the EAR deployment descriptor above. If you are using any other user from
LDAP, only the EJB methods assigned to the customer role can be executed
unless you change the role assignment in the EAR Deployment Descriptor.
19.Return to the test client page by clicking the browser back button. Browse the
JNDI objects by clicking JNDI Explorer.
20.Call the methods of the different beans.
a. For example, select ITSO.
b. You should see a listing of EJBs.
c. Select the Manager (com.ibm.itso.bank.ejb ..).
d. Click Manager → ManagerHome → Manager create ().
e. Click Invoke.
f. The object should be retrieved. Click Work with Object.
g. Click the newly created Manager 1 instance.
h. You should see a listing of the methods under Manager 1 instance. Select
the UserData createUserData(UserData) method.
i. Click Invoke.
The string representation of the user data object should be displayed.
Note: If you do not get an error, the application appears to be working.
21.You can repeat the testing with other objects.

Tip: Check the status of server1. We found that we had to restart it frequently
to resynchronize for configuration changes.
If the test environment gives an error message that the current database is
already in use, change to the Data perspective of Application Developer and
delete or disconnect the DB server entries.
9.2.6 Prepare the front-end portal server

This section describes how to prepare the front-end portal server in the
development environment by completing the following steps:
򐂰 Set up the application properties.
򐂰 Add an attribute to LDAP.
򐂰 Enable base portlets.
򐂰 Run the ITSO Bank application in the test environment.
Set up the application properties

To update some property files for the front-end application specific to the
environment, do the following:
perspective → Project Navigator view.
2. Expand the ITSOBankWAR → Java Resources.
3. Modify the file itsobank.properties.
a. Enter the IP address of the local machine as address of the iiop protocol:
com.ibm.itso.bank.appserver.host=iiop://9.42.171.106
b. Adjust the jndi name to include the server1 in the path:
com.ibm.itso.bank.appserver.managerjndi=
cell/nodes/localhost/servers/server1/ITSO/Manager
c. Save and close the property file.
Attention: The jndi names in the itsobank.properties must contain the

pattern .../nodes/localhost/servers/... and not
.../nodes/myserver.mydomain/servers/... in the test environment, since
they relate to the file system.
4. Modify the file ldaphelper.properties.
a. Change the parameters in a parameter=value syntax according to
Table 9-4 on page 419, dependent on the specific settings you chose for
LDAP setup.
b. Save and close the file.
Table 9-4 Properties for the LDAP configuration

Parameter Value
java.naming.provider.url ldap://tamdev1.itso.ral.ibm.com:389
java.naming.security.principal cn=root
java.naming.security.credentials <password>
parent_dn cn=users,dc=itso,dc=ibm,dc=com
parent_dn_admin cn=users,dc=itso,dc=ibm,dc=com
Add an attribute to LDAP

The sample application will use the custom attribute ITSOid as a primary key in
many database tables; therefore this attribute has to be added to the LDAP
schema. This can be done as described in the runtime environment in 10.2.4,
“Add ITSOid attribute to the LDAP schema” on page 437.
In addition to creating the attribute, we have to edit the mapping between Portal
Server and LDAP to make them exchange the attribute:
1. Stop the test environment portal server in case it is running.
2. Edit the wmmLDAPServerAttributes.xml file, which is in the
<portalHome>\wmm directory, for example:
C:\ibm\wsad\runtimes\portal_v50\wmm\wmmLDAPServerAttributes.xml
3. Insert the section listed in Example 9-4 towards the end of the
wmmLDAPServerAttributes.xml file (before </repositoryAttributes>, which
ends the file). The ITSOid is a correlation ID between the ITSO Bank portlet
application and the user data in the LDAP repository.
Example 9-4 ITSO modified wmmLDAPServerAttributes.xml

<attributeMap wmmAttributeName="ITSOid"
pluginAttributeName="ITSOid"
applicableMemberTypes="Person"
dataType="String"
valueLength="254"
multiValued="true" />
4. Save and close the wmmLDAPServerAttributes.xml file.

Create the groups and users for the ITSO Bank application
This step is optional if you plan on using the wpsadmin user ID for testing.
To optionally create groups and users for the ITSO Bank application refer to
10.2.5, “Create the groups and users for the ITSO Bank application” on
page 438.
Enable base portlets

In the following sections it might be necessary to use the administration portlets.
perspective.
2. Expand Servers and double-click WebSphere Portal v5.0 Test
Environment to open the server configuration.
3. Click the Portal tab.
4. Check the Enable base portlets for portal administration and
customization checkbox.
9.2.7 Run the ITSO Bank application in the test environment

We are now ready to test the ITSO Bank application in the test environment of
To run and test the ITSO Bank application in the test environment, do the
following:
perspective.
2. Expand Servers and select WebSphere Portal v5.0 Test Environment.
3. Right-click and select Add and remove projects.
4. When the Add and remove projects window appears, ensure that the
DefaultEAR is added to the configured projects (if not, add it). Expand
DefaultEAR to ensure ITSOBankWAR is present. Click Finish.
5. Expand Server and select WebSphere Portal v5.0 Test Environment.
6. Right-click Publish.
7. You should see the message Publishing was successful. Click OK.
8. Right-click Start.
Review the contents of the console and monitor the server startup. You
should see the message WebSphere Portal open for e-business.
We chose this way of deploying the project since we do not want any other
projects to be published on the server. Now the Portal can be tested.
9. Select the ITSOBankWAR project.
10.Right-click and select Run on Server.
11.Select Use an existing server and select WebSphere Portal v5.0 Test
Environment. Click Finish.
12.Now a browser window should open with the login page.
Note: Ensure that the fully qualified hostname is entered in the URL. For
example:
http://wpdev1.itso.ral.ibm.com:9081/wps/myportal
13.Log in with the wpsadmin user ID. After login the debug page should present
the portlets. For the development you can now create your own pages and
place the portlets wherever they should appear later in a production
environment.
Refer to the deployment chapter for a recommended page and rights
assignment for users and portlets. Unless the application gets completely
removed from the test environments, changes to the code should be reflected
in the portlets.
Note: For details on testing the functionality of the ITSO Bank application,
refer to 12.5, “Verifying the ITSO Bank application and runtime” on page 557.
9.3 Using the Tivoli Access Manager APIs

Tivoli Access Manager provides APIs to access and manipulate the Tivoli
Access Manager Policy Server. This section includes an example based on the
ITSO Bank sample application to demonstration how to use Tivoli Access
Manager APIs.
The portlet used in this example is the ITSOUser portlet, which is used to register
new users and create a bank account for these users. After the users are
created, they have access to the portal in general, their account details, and the
portlets for account balance and transfer.
The data specific to the user is split into two parts, of which the core attributes
(for example, surname, firstname, userid, etc.) will be stored in LDAP, and the
information more specific to the ITSO Bank back-end application will be stored in
the itsobank database.

9.3.1 The portlet application without Tivoli Access Manager
To facilitate our explanation of using the Tivoli Access Manager APIs, we will first
explain how the user would access the ITSO Bank if it was not using Tivoli
Access Manager and connected directly to WebSphere Portal. In this case,
WebSphere Portal would perform the authentication for the user against the
LDAP directory server, as depicted in Figure 9-9.
WebSphere Portal Server
ITSOUser LDAP
Portlet Helper
Specific Core
User User Authentication
Data Data
Directory
Server
Figure 9-9 Portlet setup without Access Manager security
In this case the ITSOUser portlet uses the LDAPHelper class to store information
in the LDAP server and make that information available for the portal from now
on. Example 9-5 includes a code snippet for creating a user in LDAP with the
LDAPHelper class.
Example 9-5 Example of creating a user in LDAP with the LDAPHelper class
Properties env = getContextProperties(log);
String dn = "uid=" + userData.getUserId() + "," + parent_dn;
try {
DirContext ctx = new InitialDirContext(env);
Attributes attSet = getAttrSet(userData, objectClass);
ctx.createSubcontext(dn, attSet);
ctx.close();
} catch (NameAlreadyBoundException e) {
log.error("NameAlreadyBoundException while adding user: " +
e.getMessage());
} catch (NamingException e) {
log.error(logPrefix + " NamingException while adding user: " +
e.getMessage());
}
These calls in the current application are made through the classes in the
javax.naming.* and javax.naming.directory.* packages.
9.3.2 The portlet application using Tivoli Access Manager

When using Tivoli Access Manager for authentication, the user registry is found
in the Tivoli Directory Server LDAP directory. From the perspective of the portal
application, the application behaves the same with or without Tivoli Access
Manager, with the exception that when a user is created it is registered in Tivoli
Access Manager in addition to the LDAP user registry.

WebSphere Portal Server Authentication Tivoli
WebSEAL
TAM
Helper
ITSOUser
Portlet
Authentication
LDAP
Import User
Helper
Specific Core
User User
Data Data
Import User Tivoli

Directory Access
Server Manager
Figure 9-10 Portlet setup with Access Manager security
After the user is imported, Tivoli WebSEAL can successfully authenticate an

incoming call to the portal against Tivoli Access Manager and authenticate the
user at the portal. A code sample for the import is shown in Example 9-6 on
page 424.
Example 9-6 Importing a user from the Directory Server into Access Manager
try {
URL configURL = new URL(configURLStr);
// get context for TAM API

PDContext ctx = new PDContext(Locale.getDefault(),
"sec_master","<password>".toCharArray(), configURL);
// setup the LDAP registry name uid=name,cn=customers,dc=ibm,dc=com

String rgyName = "uid=" + userData.getUserId() + "," +
(String)env.get(PROPERTY_NAME_PARENT_DN);
PDRgyUserName pdRgyUserName = new PDRgyUserName(rgyName,
userData.getFirstName(), userData.getLastName());
boolean ssoUser = false;
PDMessages messages = new PDMessages();
// get the user info from LDAP into TAM's DB

// the parameter which is 'null' here is the groupname
PDUser.importUser(ctx, userData.getUserId(), pdRgyUserName, null, ssoUser,
messages);
// now the user can bypass webSEAL with a TAM authentication
} catch (MalformedURLException e) {
log.error(logPrefix + " MalformedURLException while importing user: " +
e.getMessage());
} catch (PDException e) {
log.error(logPrefix + " PDException while importing user: " +
e.getMessage());
}
Once the context for Tivoli Access Manager is created, all API calls can be
performed on the various Access Manager objects. These include working with
users (PDUser), policies (PDPolicy), ACLs (PDAcl), etc.
For more information on the Tivoli Access Manager APIs, refer to the
Authorization Java Classes Developer Reference, IBM Tivoli Access Manager
V5.1, SC32-1350, product guide.
9.4 Using the WebSphere Portal Credential Vault

In the runtime installation and configuration chapters we described how
WebSEAL can be used in conjunction with Tivoli Access Manager to create a
Single-Sign-On environment and allow the user to use various Web applications
by just signing in once at the Reverse Proxy (WebSEAL). This affects all
systems, that have their own Web interface that the user signs on to and that is
displayed to the users, be it through using their own browser window, as part of a
portal, or as part (snippet) of other Web pages, that are included as frame
(iFrame).
When engaging in application integration it is, however, often necessary to

access back-end systems with credentials and reuse and work with data from the
back-end instead of displaying this data to the user. In this case the
authentication cannot be handled through WebSEAL, since the Reverse Proxy is
not involved, but rather the credential vault internal to WebSphere Portal can be
used for accessing those back-end applications and authenticating against these
back-end resources. The different types of authentication are displayed in
Figure 9-11. The same applies for authorization.

Trust Association
Backend
Applications
Portlet
WebSphere
Authentication
Portal
Portlet
Authentication
Authentication Backend
Proxy Applications
(For example,
WebSEAL)
Other
Other
Web
Other
Web
Applications
Web
Applications
Applications
Figure 9-11 Front-end and back-end authentication
The usage of the credential vault is well documented in the Portal InfoCenter as
well as in a number of articles in the WebSphere Technical Journal of IBM
developerWorks. Therefore the following example will be brief.
In this section we introduce a simple application the makes use of the credential
vault in a way that an administrator initially specifies a common username and
password, as well as an URL for a protected resource. This resource is displayed
for every user that can see the portlet. The protected resource will be the Web
page from “Create test portlet to verify Credential Vault” on page 351, which is
secured with basic authentication.
Introducing the credential vault API

As described in 2.3.6, “WebSphere Portal Credential Vault” on page 44, the
WebSphere Portal credential vault is a storage area for different types of
credentials like usernames, passwords, certificates, etc. The credential vault is
partitioned in so-called segments and slots, where a segment can contain
several slots.
Vault segments can be either administrator-managed or user-managed. There is

a default administrator-managed segment that is used automatically if no other
segment is specified. To make the example as simple as possible, this segment
will be used in the example.
Since we want all users to access the same information with the same
combination of username and password, we need to take a system slot to share
the information among users.
Portlets can store data to and retrieve data from the credential vault via the
credential vault service. To access the service as well as the vault segments and
slot, the com.ibm.wps.portletservice.credentialvault package is used. This
contains three interfaces:
򐂰 CredentialSlotConfig
򐂰 CredentialVaultService
򐂰 VaultSegmentConfig
Out of these, the CredentialVaultService will mostly be used, since the others are
only needed when working directly with segments and slots, for example,
creation and deletion. Besides the package above, there is the package
com.ibm.wps.portletservice.credentialvault.credentials that contains different
credential objects that are used to handle the credentials. A part of the class
hierarchy is displayed in Figure 9-12 on page 428.

package: com.ibm.wps.portletservice.credentialvault.credentials
Credential
Passive Active
Credential Credential
Simple User JAAS

Passive ... ... Password ... Subject
Credential Credential Credential
Http HttpForm
BasicAuth ... BasedAuth
Credential Credential
Figure 9-12 Class hierarchy of the WebSphere Portal credentials
The credentials are split into active and passive credentials. Passive credentials
are objects that act as a containers for credentials, whereas active credentials
hide the credentials from the user and provide convenience methods instead.
Since basic authentication is used for the resource to access, we can use the
HttpBasicAuthCredential. Once this object is initialized, it can authenticate
connections for us without revealing the credentials.
The requirements lead to the settings displayed inTable 9-5.
Table 9-5 Credential vault details for the sample application

Parameter Value
Segment Default admin segment
Slot System slot (shared)
Parameter Value
Slotname ITSOTestSlot
Credential HttpBasicAuthCredential
An application walk-through
The application consists of the following classes/files:
򐂰 ITSOCredentialVaultPortlet.java: The main portlet class
򐂰 ITSOCredentialVaultConfigBean.java: A simple bean to wrap the settings that
are passed from and to the config mode
򐂰 ITSOCredentialVaultPortletError.jsp: An error page that is displayed in case
that exceptions occur
򐂰 ITSOCredentialVaultPortletConfig.jsp: The page used for the configuration
The portlet application used here consists of two modes, the general view mode
and a configure mode to set the settings, which are reflected by the doView() and
doConfigure() methods in the portlet class. The doConfigure() mode includes the
ITSOCredentialVaultPortletConfig.jsp page and displays the settings for the
portlet. These settings can be changed by an administrator in the configure
mode. If the parameters are changed, the actionPerformed() method of the
portlet will store the new settings.
Example 9-7 Storing the credentials

public void storeCredentials(String userID, String password, PortletRequest
request) throws PortletException {
try {
vaultService.setCredentialSecretUserPassword(SLOTNAME, userID,
password.toCharArray(), request);
} catch (PortletServiceException e) {
}
}
When the Save button on the config page is pressed, the request is passed to
the actionPerformed() method. This method will do a few checks on parameters
and then call the storeCredentials() method (displayed in Example 9-7) that will
call the CredentialVaultService to store the credentials.
After storing the credentials, the other important thing would be to use the
credentials to authenticate against the protected HTML page. As described

above, through the usage of the class HttpBasicAuthCredential, the direct usage
of the credentials can be avoided. This is displayed in Example 9-8.
Example 9-8 Authenticating the connection with the HttpBasicAuthCredential

public URLConnection getAuthenticatedURLConnection(PortletRequest request)
throws PortletException {
PortletSettings settings = request.getPortletSettings();

String urlString = settings.getAttribute(TARGET_URL);
try {
Map map = new HashMap();
String type = "HttpBasicAuth";
HttpBasicAuthCredential credential = (HttpBasicAuthCredential)
vaultService.getCredential(SLOTNAME, type, map, request);
return credential.getAuthenticatedConnection(urlString);
} catch (MalformedURLException e) {
} catch (IOException e) {
}
}
All other actions needed to perform on the WebSphere Portal credential vault
service are variations on the API, and therefore will not be discussed in detail.
Importing the sample code into the workbench

For importing the sample project in the workbench of WebSphere Studio
Application Developer, perform the following steps:
1. Open a clean workbench in the portlet perspective.
2. Choose File → Import → WAR File and click Next. Select the
ITSOCredentialVault.war file.
3. For the project name, click the New button to create a new project, enter
ITSOCredentialVault as the project name, and select Finish. This will get
you back to the import window. Enter ITSOBankWAR as the project name.
4. Click Finish.
You will have to set up the library variables for WPS_V5_PLUGINDIR, as

described in “Define the library variables” on page 403. The other variables do
not have to be specified if working only with the credential vault project.
Finally, add the variable extensions to the project as described in section “Define
the project dependencies” on page 404. In addition to the variable extensions
listed, add also the variable WAS_50_PLUGINDIR/lib/utils.jar.
Now the project can be run and tested in the test environment. For details
concerning the setup, see the next section.
Note: As described above, the URL to the protected page is a portlet setting.
Unless you specify this setting in the portlet deployment descriptor portlet.xml,
every execution of the Run on server option of the workbench will redeploy the
application, and therefore set this parameter to null. This will not be the case
with the credentials, since they are stored in the credential vault independently
from the application.
Deploying the application in the runtime environment

To deploy the credential vault application in the runtime environment, do the
following:
1. Access the WebSphere Portal Home page by entering the following URL in a
Web browser:
2. Log in as user ID wpsadmin.
4. Click Portlets → Install.
5. From the Install Portlets page, enter the following and then click Next:
– Specify the location of the file: c:\temp\ITSOCrendentialVault.war
6. Click Install.
7. When installation completes, you should see a message that the portlets
were successfully installed.
Then you should create a portal page and place the portlet on that page. How
this can be done is described in 10.3.5, “Create portal pages” on page 451, and
10.3.6, “Add portlets to pages” on page 453.
Now that the portlet is installed, the settings have to be configured once by
clicking the configure icon in the portlet header. The settings are displayed in
“Parameters for the credential vault portlets” on page 432.

Table 9-6 Parameters for the credential vault portlets
Parameter Value
User ID vault_test
Password passw0rd
Target URL http://wpwin1.itso.ral.ibm.com/test/vault_test.html
After the settings have been specified, a click the Save button should display the
protected page in the view mode.
10
Chapter 10. Deploy the secure portal

application
This chapter describes how to deploy the ITSO Bank secure portal application in
the production evironment. The ITSO Bank application is made up of a back-end
application and a front-end portal application. The back-end application consists
of Enterprise JavaBeans complying with EJB 2.0 and J2EE 1.3 specifications. It
also packages a DDL file to create tables in the required application database.
The portal application consists of portlets ready for deployment on WebSphere
Portal Server 5.0.2.1.

򐂰 ITSO Bank application overview.
򐂰 Deploy the ITSO Bank back-end application.
򐂰 Deploy the ITSO Bank portal application.

10.1 ITSO Bank application overview
ITSO Bank application is based on a secure eBanking portal scenario that
provides personalized information and services to the customer, coupled with an
administration interface for the bank officials.
This application provides the following personalized services to the user that
belongs to the role of customer:
򐂰 View balance in the savings and checking accounts.
򐂰 Transfer funds between savings and checking accounts.
This application provides the following administrative services to the user that
belongs to the role of manager:
򐂰 Enter customer information.
򐂰 Modify customer information.
򐂰 View balance in the savings and checking accounts of any customer.
򐂰 View transaction history of customer accounts.
10.2 Deploy the ITSO Bank back-end application

This section describes how to deploy the back-end application. It includes
activities such as creating and setting up the ITSO Bank database, as well as
configuring WebSphere Application Server so that it can host the ITSO Bank
application.
The ITSO Bank back-end is a J2EE application that uses a DB2 database (or
Cloudscape database in the development environment). The ITSO Bank
back-end and database can be installed on a remote WebSphere Application
Server. In our example, we will deploy both the back-end J2EE application and
front-end portlets on the Portal Server node. For the purposes of showing proper
configuration, we will create a separate application server (for example,
ITSOBankServer) to deploy the back-end application.
The deployment of the back-end application includes the following tasks:

򐂰 Create an application server.
򐂰 Create the ITSO Bank application database.
򐂰 Add ITSOid attribute to the LDAP schema.
򐂰 Create the groups and users for the ITSO Bank application.
򐂰 Create the ITSOBankDataSource data source.
򐂰 Deploy the back-end application EAR.
10.2.1 Create an application server
This section describes how to create the ITSOBankServer application server
used to deploy and run the ITSO Bank back-end enterprise application.
Create a new application server

To create a new application server (for example, ITSOBankServer), do the
following:
1. Ensure that the server1 application server is started (server1 is the server
where the WebSphere Application Server Adminstrative Console Enterprise
application is installed). If not, start server1 from a command window as
follows:
2. Start the WebSphere Administrative Console by entering the following URL in
a Web browser:
3. Log on as the user ID wpsbind.
4. Select Servers → Application Servers.
5. Click New.
6. When the Create New Application Server page appears, do the following and
then click Next:
– Select node: Select wpwin1/wpwin1.
– Server name: ITSOBankServer
– Accept default settings for the remaining options.
7. When the Confirm new application server page appears, review the settings
and click Finish.
8. Click Save.
Determine application server bootstrap port

When a new application server is created, a bootstrap port will be generated that
is unique based on existing applications servers. When the itsobank.properties
file is modified in a later procedure, a boot strap port value will be needed for the
application server in order to deploy the ITSO Bank application for JNDI lookup.
To determine the ITSOBankServer application server boot strap port, do the

following:
1. From the WebSphere Application Server Administrative Console, select
Servers → Application Servers.
Chapter 10. Deploy the secure portal application 435

2. Click ITSOBankServer.
3. Scroll down the page, and click End Points.
4. Click BOOTSTRAP_ADDRESS.
5. On the BOOTSTRAP_ADDRESS page, record the value of the port (for
example, 2810). Click Cancel.
6. Click Log out.
Note: In our example, we used the port value that was generated by
WebSphere Application Server for the newly created ITSOBankServer
application server. Alternatively, you could change the port value to a new
value.

6325code.zip, unpacking the zip file, and extracting files from the EAR.
3. Create the directory c:\temp\ITSOBankApp.
4. Copy the ITSOBankEAR.ear file from the ITSO sample code
c:\6325code\deploy directory to the c:\temp\ITSOBankApp directory.
5. Extract the ITSOBankEJB.jar from ITSOBankEAR.ear.
a. Open a command window and change to the temporary directory (for
example, c:\temp\ITSOBankApp).
b. Enter the following to extract the EJB jar file:
c:\ibm\WebSphere\AppServer\java\bin\jar -xvf ITSOBankEAR.ear
ITSOBankEJB.jar
6. Extract the Table.ddl from the ITSOBankEJB.jar.
a. Open a command window and change to the c:\temp\ITSOBankApp
directroy.
b. Enter the following to extract the files:
c:\ibm\WebSphere\AppServer\java\bin\jar -xvf ITSOBankEJB.jar
META-INF/Table.ddl
10.2.3 Create the ITSO Bank application database

Although the following steps can be done through the DB2 Control Center and
the DB2 Command Center, we chose to use the DB2 Command Line Processor.
1. Ensure that you are logged into the Portal Server node as the admin user with
proper privilages. In our example, we created and logged in as the admin
user (see “Create admin user and assign user rights” on page 183).
2. Start the DB2 Command window by selecting Start → Programs → IBM
DB2 → Command Line Tools → Command Window.
3. Create the database ITSOBank by entering the following DB2 command:
db2 create db ITSOBank
4. Connect to the database.
db2 connect to ITSOBank user <db2admin> using <db2admin_password>
5. Create the tables required for the application.
db2 -tvf C:\temp\ITSOBankApp\META-INF\Table.ddl
10.2.4 Add ITSOid attribute to the LDAP schema

This section describes how to add the ITSOid attribute to the LDAP schema. The
ITSOid is a correlation ID between the ITSO Bank portlet application and the
user entries in the LDAP repository.
To add the ITSOid attribute to the LDAP schema, do the following:

node (location of Tivoli Directory Server Web Administration Tool).
2. Access the Tivoli Web Administration tool from a Web browser:
http://tamwin1.itso.ral.ibm.com:9080/IDSWebApp/IDSjsp/Login.jsp
3. From the Login to the Web Administration Tool page, enter the following and
click Login:
– LDAP Hostname: Select tamwin1.itso.ral.ibm.com.
4. Click Schema Management → Add an attribute.

5. From the Add an attribute page, enter the following and then click OK at the
bottom of the page:
– Attribute name: ITSOid
– Description: Correlation ID between the ITSO Bank portlet
application and the user entries in the LDAP repository
– OID: ITSOid-OID
6. Click Schema Management → Manage object classes.
7. From the Manage object classes page, do the following:
a. Scroll down to the bottom of the page and select Page 15 of 18
nsLiProfile from the drop-down list. Click Go.
b. Select the organizationalPerson object class and then click Edit (found
by scrolling to the right-hand side of the page).
c. From the Edit object class: organizationalPerson page, click Attributes.
d. From the Attributes page, select ITSOid from the Available attributes
drop-down list. Click Add to optional.
e. Scroll down the Attributes page and click OK.
8. Click Logout of the Web Administration Tool.
9. Restart the IBM Tivoli Directory Server V5.2 Windows service on the Policy
Server node.
Note: At the time of writing this redbook, we found that we were not able to
successfully restart the Tivoli Directory Server remotely using the Web
Administration Tool. For this reason, we restarted the Tivoli Directory Server
via Windows services.
10.2.5 Create the groups and users for the ITSO Bank application
This section describes how to create groups and users needed for the ITSO
Bank application. We will create a ITSOManagers and ITSOCustomers group. In
addition, we will create a manager user ID in the managers group. The manager
user ID is required. However, the customer user IDs can be created from the
ITSO Bank application.
To create the ITSOManagers and ITSOCustomers groups and manager1 user

ID for the ITSO Bank application, do the following:
1. Create an ldif file like Example 10-1 on page 439 on the Policy Server node
(location of Tivoli Directory Server client). For example, we created the
itsobank.ldif file that will be imported to create the groups and users for the
ITSO Bank. The itsobank.ldif file can be found in the ITSO sample code
c:\6325code\deploy directory.
Example 10-1 ITSO Bank application - itsobank.ldif

version: 1
# ITSO example: itsobank.ldif file
dn: uid=manager1,cn=users,dc=itso,dc=ibm,dc=com
objectclass: person
objectclass: top
uid: manager1
userpassword: passw0rd
sn: Manager
givenName: ITSOBank
cn: ITSOBank Manager
dn: cn=ITSOManagers,cn=groups,dc=itso,dc=ibm,dc=com
objectclass: top
uniquemember: uid=manager1,cn=users,dc=itso,dc=ibm,dc=com
cn: ITSOManagers
# This is a dummy user entry for ITSOCustomers group.

dn: uid=ITSOBankDummyUser,cn=users,dc=itso,dc=ibm,dc=com
objectclass: person
objectclass: top
uid: ITSOBankDummyUser
sn: Dummy
givenName: ITSOBank
cn: ITSOBank Dummy User
dn: cn=ITSOCustomers,cn=groups,dc=itso,dc=ibm,dc=com
objectclass: top
uniquemember: uid=ITSOBankDummyUser,cn=users,dc=itso,dc=ibm,dc=com
cn: ITSOCustomers
Note: It is required to set a uniquemember attribute for the

ITSOCustomers group at the time of its creation, so we have created the
the ITSOBankDummyUser ID. Although this user belongs to the
ITSOCustomers group, it will not be used at any point for the ITSOBank
application.

2. Open a command window and enter the following to import the groups and
user into the Tivoli Directory Server:
ldapadd -D cn=root -w passw0rd -h tamwin1 -c -i itsobank.ldif
3. Import the ITSOManagers and ITSOCustomers groups and manager1 user
ID into Tivoli Access Manager from a command window:
a. Copy the ITSO sample code c:\6325code\deploy\itsobank.pd to the
c:\temp directory on the Policy Server node. Example 10-2 lists the
contents of the itsobank.pd command file.
Example 10-2 ITSO Bank application itsobank.pd

group import ITSOManagers cn=ITSOManagers,cn=groups,dc=itso,dc=ibm,dc=com
group import ITSOCustomers cn=ITSOCustomers,cn=groups,dc=itso,dc=ibm,dc=com
user import manager1 uid=manager1,cn=users,dc=itso,dc=ibm,dc=com

user modify manager1 account-valid yes
b. Open a command window and enter the following command to execute

the import into Tivoli Access Manager:
pdadmin -a sec_master -p passw0rd itsobank.pd
4. Verify that you can log on to the WebSphere Portal via WebSEAL.
a. Enter the following URL in a Web browser:
b. Log on as the manager1 user ID.
10.2.6 Create the ITSOBankDataSource data source

To create the ITSOBankDataSource (used by the back-end application to access
the ITSOBank database), do the following:
1. Ensure that the ITSOBankServer application server is started.
If it is not started, enter the following in a command window:
c:\ibm\WebSphere\AppServer\bin\startServer ITSOBankServer
2. Ensure that the server1 application server is started.
server1 is the server where the WebSphere Application Server Adminstrative
Console Enterprise application is installed). If not, start server1 from a
command window as follows:
3. Start the WebSphere Administrative Console by entering the following URL in
a Web browser:
4. Log on as the user ID wpsbind.
5. Create an authentication alias used by the datasource.
The ITSO Bank application uses an authentication alias to connect with the
database through the datasource configured for a DB2-based JDBC Provider.
This authentication alias can be configured in the WebSphere Administrative
Console by completing the following steps:
a. Click Security → JAAS Configuration → J2C Authentication Data.
b. From the J2C Authentication Data page, click New to create a new alias.
c. When the New alias page appears, enter the following, as seen in
Figure 10-1, and then click OK:
• Alias: ITSOBankAlias
• User ID: admin
This is the DB2 instance owner used to create a database.
• Password: <db2_password>
• Description: ITSO Bank Alias
Figure 10-1 Create ITSO Bank alias

6. Create a JDBC provider.
a. Click Resources → JDBC Providers.
b. On the JDBC Providers page, enter the following and click Apply:
• Node: wpwin1
• Server: ITSOBankServer
c. From the JDBC provider page, click New.
d. Select DB2 Legacy CLI-based Type 2 JDBC Driver from the JDBC
Providers drop-down list, and then click OK.
Note: The default DB2 JDBC Provider is deprecated. For this reason
we chose to use the DB2 Legacy CLI-based Type 2 JDBC Driver.
e. From the DB2 Legacy CLI-base Type 2 JDBC Drive page, enter the
following and then click OK:
• Name: DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO Bank
Application
• Description: DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO
Bank Application
7. Create the datasource.
a. From the JDBC Providers page, click the newly created JDBC provider
DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO Bank
Application.
b. Click Data Sources in the Additional Properties found by scrolling down
the page.
c. From the Data Sources page, click New.
d. From the New Data Sources page, enter the following and then click OK:
• Name: ITSOBankDataSource
• JNDI Name: jdbc/ITSO
• Container managed persistence: Check Use this Data Source in
container managed persistence (CMP).
• Description: DB2 JDBC DataSource for ITSOBank
• Component-managed Authentication Alias: Select
wpwin1/ITSOBankAlias.
• We accepted the defaut values for the remaining options.
e. Click ITSOBankDataSource.
f. Click Custom Properties under the Additional Properties heading.
g. Click databaseName and set the value to ITSOBANK. Click OK.
h. Click Environment → Manage WebSphere Variables.
Ensure that the variable DB2_JDBC_DRIVER_PATH is set to the location
of db2java.zip fle (for example, DB2_JDBC_DRIVER_PATH
c:\ibm\sqllib\java).
i. Click Save.
j. When the Save to Master Configuration page appears, click Save.
8. Test the connection to the database:
a. Select Resources → JBDC Providers.
b. Click DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO Bank
Application.
c. Click Data Sources under Additional Properties.
d. Check ITSOBankDataSource, and then click Test Connection.
You should see a message like the following if successful:
Test connection for the datasource ITSOBankDataSource on server server1
at node wpwin1 was successful.
10.2.7 Deploy the back-end application EAR

This section describes the steps to deploy the EAR.
To deploy the ITSOBankEAR.ear, do the following:

1. Click Applications → Install New Application.
2. From the Prepare for the application installation page, do the following and
then click Next:
– Select Local path.
– Local path: C:\temp\ITSOBankApp\ITSOBankEAR.ear
3. Click Next.
4. We accepted the default settings for Steps 1–6. Scroll down the page and
click Step 7: Map modules to application servers.
5. From the Step 7: Map modules to application servers page, do the following
and then click Apply.
– Module: Check ITSOBankEJB.
– Clusters and Servers: Select
WebSphere:cell=wpwin1,node=wpwin1,server=ITSOBankServer.
6. Click Next to advance to Step 8.

7. Map the ITSOManager role to the
cn=ITSOManagers,cn=groups,dc=itso,dc=ibm,dc=com group.
a. From the Step 8: Map security roles to users/groups, do the following:
• Role: Check ITSOManager.
• Click Lookup Groups.
b. When the Lookup users/groups page appears, do the following:
• Search string: ITSOManagers
• Click Search.
c. From the Available list, select
cn=ITSOManagers,cn=groups,dc=itso,dc=ibm,dc=com, and then click
>> to add it to the Selected list. Click OK.
8. Map the ITSOCustomer role to the
cn=ITSOCustomers,cn=groups,dc=itso,dc=ibm,dc=com group.
a. From the Step 8: Map security roles to users/groups, do the following:
• Role: Check ITSOCustomer.
• Click Lookup Groups.
b. When the Lookup users/groups page appears, do the following:
• Search string: ITSOCustomers
• Click Search.
c. From the Available list, select
cn=ITSOCustomers,cn=groups,dc=itso,dc=ibm,dc=com, and then
click >> to add it to the Selected list. Click OK.
When done, you should see a page like Figure 10-2 on page 445.
Figure 10-2 Results of role mapping
9. Click Step 11 Summary page, and then click Finish.

10.Click Save.
12.Start the ITSOBankServer application server from a command window as
follows (restart if already started):
c:\ibm\WebSphere\AppServer\bin\startServer ITSOBankServer
This completes the ITSO Bank back-end application deployment.

10.3 Deploy the ITSO Bank portal application
This section includes the following tasks to deploy the ITSO Bank portal
application:
򐂰 Modify properties files and repackage WAR.
򐂰 Modify the wmmLDAPServerAttributes.xml file.
򐂰 Install portlets.
򐂰 Create portal pages.
򐂰 Add portlets to pages.
򐂰 Modify resource permissions.
򐂰 Verify ITSO Bank application.
򐂰 Externalize the ITSO Bank resources.

6325code.zip, unpacking the zip file, and extracting files from the EAR.
3. Copy ITSOBankWAR.war to the c:\temp\ITSOBankApp directory.
4. Extract the contents of ITSOBankWAR.war to
C:\temp\ITSOBankApp\ITSOBankWAR.
a. Open a command window and create the
c:\temp\ITSOBankApp\ITSOBankWAR directory.
b. Change to the c:\temp\ITSOBankApp\ITSOBankWAR directory.
c. Enter the following command to extract the ITSOBankWAR.war:
c:\ibm\WebSphere\AppServer\java\bin\jar -xvf ..\ITSOBankWAR.war
10.3.2 Modify properties files and repackage WAR

To deploy the ITSO Bank WAR (ITSOBankWAR.war), do the following:
1. Navigate to the c:\temp\ITSOBankApp\ITSOBankWAR\WEB-INF\classes
where you have unpacked the ITSOBankWAR.war.
2. Modify the itsobank.properties file.
a. Modify the the following values in the itsobank.properties file for that of the
target system, as seen in Example 10-3 on page 447 (values to change in
bold):
• host: Change the hostname to match with the hostname of the node
where the application will be deployed. In our example, this is the
Portal Server node.
• port: Change the port to the bootstrap value of the application server
that you wish to deploy the application to. To determine this value, refer
to “Determine application server bootstrap port” on page 435 (for
example, 2810).
• managerjndi: You will need to update the node name (for example,
wpwin1) and application server (for example, ITSOBankServer), as
seen in Example 10-3.
Example 10-3 ITSO Bank application itsobank.properties file

# ITSO Bank Properties
com.ibm.itso.bank.appserver.host=iiop://wpwin1.itso.ral.ibm.com
com.ibm.itso.bank.appserver.port=2810
com.ibm.itso.bank.appserver.managerjndi=cell/nodes/wpwin1/servers/ITSOBankServer/ITSO/Manager
Note: ITSOBankServer is the application server on which this

enterprise application will be deployed. The ITSOBankServer was
created in 10.2.1, “Create an application server” on page 435. If you
choose to change the name of the application server, it should be
reflected in the itsobank.properties file.
b. Save and close the itsobank.properties file.

3. Modify the ldaphelper.properties file.
a. Modify the the following values in the ldaphelper.properties file for that of
the target system, as seen in Example 10-4 (values to change highlighted
in bold):
• java.naming.provider.url: Hostname and port of the Tivoli Directory
Server (in our example, this is installed on the Policy Server node).
• java.naming.security.principal: LDAP administrator ID with write
privilege for the parent_dn and parent_dn_admin.
• java.naming.security.credentials: Password for the principal
• parent_dn: Base DN of the LDAP tree for the customer user IDs.

• parent_dn_admin
Example 10-4 ITSO Bank application ldaphelper.properties file

# The following must be set when name arguments are DN based.
# Use one of the following LDAP servers...

# IBM Directory Server 5.2
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
# Authentication mechanism. One of none, simple, EXTERNAL or CRAM-MD5.

java.naming.security.authentication=simple
# URL settings. If a Secure Socket Layer (SSL) connection is desired

# then change URL "ldap:" to "ldaps:".
java.naming.provider.url=ldap://tamwin1.itso.ral.ibm.com:389
java.naming.security.principal=cn=root
java.naming.security.credentials=passw0rd
# Parent dn for all user IDs with CUSTOMER role

parent_dn=cn=users,dc=itso,dc=ibm,dc=com
# DN for the ITSOCustomers group

group_dn=cn=ITSOCustomers,cn=groups,dc=itso,dc=ibm,dc=com
# Parent dn for all user IDs with MANAGER role

parent_dn_admin=cn=users,dc=itso,dc=ibm,dc=com
# Object class required for add user

object_class=top person organizationalPerson ePerson inetOrgPerson
b. Save and close the ldaphelper.properties file.

4. Modify the tamhelper.properties file.
a. Modify the the values in the tamhelper.properties file for that of the target
system, as seen in Example 10-5 (values to change in bold).
Note: The PdPerm.properties file is generated as part of the Tivoli

Access Manager Java Runtime Environment configuration (pdjrtecfg)
completed in “Configure PDJRTE for WebSphere Application Server
JRE” on page 256.
Example 10-5 ITSO Bank application tamhelper.properties file

application=ITSOBank
url=file:///c:/ibm/WebSphere/AppServer/java/jre/PdPerm.properties
principal=sec_master
credential=passw0rd
# Parent dn for all user ID's with CUSTOMER role

parent_dn=cn=users,dc=itso,dc=ibm,dc=com
b. Save and close the tamhelper.properties file.

5. Repackage the ITSOBankWAR.war.
a. Copy the orginal ITSOBankWAR.war found in the c:\temp\ITSOBankApp
directory to ITSOBankWAR.war.org.
b. Navigate to the c:\temp\ITSOBankApp\ITSOBankWAR directory.
c. Repackage ITSOBankWAR.war to include the modified properties files by
entering the following command:
c:\ibm\WebSphere\AppServer\java\bin\jar -uvf ..\ITSOBankWAR.war
WEB-INF\classes\itsobank.properties
WEB-INF\classes\ldaphelper.properties
WEB-INF\classes\tamhelper.properties
10.3.3 Modify the wmmLDAPServerAttributes.xml file

The WebSphere Portal Member Manager maps attribute names that are
exposed on Java objects representing users and groups to the LDAP repository
attribute names. Member Manager attributes are mapped to LDAP attributes
through the wmmLDAPServerAttributes.xml file.
Note: For more detailed information on the WebSphere Portal Member

Manager, refer to the WebSphere Portal InforCenter at the following URL and
search for wmmLDAPServerAttributes.xml:
To modify the wmmLDAPServerAttributes.xml for the ITSO Bank application

example, do the following:
1. Navigate to the <wp_home>\wmm directory on the Portal Server node.
2. Back up the wmmLDAPServerAttributes.xml file to
wmmLDAPServerAttributes.xml.org.
3. Open the wmmLDAPServerAttributes.xml file.
4. Insert the section listed in Example 10-6 towards the end of the
wmmLDAPServerAttributes.xml file (before </repositoryAttributes>, which
ends the file). The ITSOid is a correlation ID between the ITSO Bank portlet
application and the user data in the LDAP repository.

The contents of Example 10-6 can be found in
c:\6325code\config\wps\wmmLDAPServerAttributes_itso.xml.
Note: In the ITSO Bank application example, we added the ITSOid

attribute to the LDAP schema in 10.2.4, “Add ITSOid attribute to the LDAP
schema” on page 437.
This file will be overwritten for certain wpsconfig tasks like disable-security,
enable-security-ldap. In that case, this entry will have to be added again.
Example 10-6 ITSO modified wmmLDAPServerAttributes.xml

<attributeMap wmmAttributeName="ITSOid"
pluginAttributeName="ITSOid"
applicableMemberTypes="Person"
dataType="String"
valueLength="254"
multiValued="true" />
</repositoryAttributes>
5. Save and close the wmmLDAPServerAttributes.xml file.

10.3.4 Install portlets

This section describes how to install the ITSO Bank portlets on the Portal Server
node.
Web browser:
– Specify the location of the file: c:\temp\ITSOBankApp\ITSOBankWAR.war
6. You should see a page like Figure 10-3 on page 451 listing the portlets to be
installed. Click Install.
Figure 10-3 ITSO Bank portlets to be installed
When installation completes, you should see a message that the portlets
were successfully installed.
10.3.5 Create portal pages

This section describes how to create portal pages. For the ITSO Bank example,
we created a hierachy where the ITSO Bank page acts as a page group that
contains three pages (Add User, Modify User, and Access Account).
To create portal pages, do the following:

1. From the Administration page click Portal User Interface → Manage Pages.
2. Create ITSO Bank page.
a. From the Manage Pages page, click My Portal.
b. Click New page.
c. From the New page: My Portal page, do the following and then click OK:
• Title: ITSO Bank
• Theme: Select Inherit Parent Theme (default).

d. You should see the message ITSO Bank has been created successfully.
Click OK.
3. We would like the ITSOBank page to be displayed after the Welcome page.
By default, when added, it is last in the list of pages. Click the up arrow for
ITSO Bank several time to move it up the list (before the Welcome page).
When done, you should see a page like Figure 10-4.
Figure 10-4 Move ITSOBank page
4. Create an Add User page.

a. Click the ITSO Bank page.
b. Click New page.
c. From the New page: ITSO Bank page, do the following and then click OK:
• Title: Add User
d. You should see the message Add User has been created successfully.
Click OK.
5. Create a Modify User page.
a. Click New page.
b. From the New page: ITSO Bank page, do the following and then click OK:
• Title: Modify User
c. You should seethe message Modify User has been created
successfully. Click OK.
6. Create Access Account page.
a. Click New page.
b. From the New page: ITSO Bank page, do the following and then click OK:
• Title: Access Account
c. You should see a message Access Account has been created
successfully. Click OK.
10.3.6 Add portlets to pages

This section describes how to add the ITSO Bank portlets to the pages created in
10.3.5, “Create portal pages” on page 451.
Add portlet to the Add User page

The Add User page should contain the ITSO Add User portlet. This
administration portlet allows the manager to enter the details of a new customer.
It provides an integrated interface to create a checking and savings account. The
ITSO Bank back-end application will generate unique account numbers and
ITSOid. The customers’ data will be saved in the database and the user will be
created in the LDAP with an optional attribute ITSOid set with the unique value.
The portlet can be added to the Add User page, as follows:

1. From the Administration page, click Portal User Interface → Manage
Pages.
2. Navigate to Content Root → My Portal → ITSOBank.
3. Click Add User page.
4. Click the pencil icon (Edit Page Layout) as seen in Figure 10-5 on page 454.

Figure 10-5 Add portlet edit page layout (pencil icon)
5. From the Edit Layout page, click the one column icon, as seen in Figure 10-6
on page 455.
6. When the message If you have derived or personalized pages based off
this page, then all those changes will be lost. Do you wish to
continue? appears, click OK.
Figure 10-6 Edit page layout - Single column page
7. Click Add portlets.

8. From the Edit Layout page, do the following and then click Search:
– Search on: Select Title contains.
– Search for: ITSO
9. When the search results are displayed, you should see a list of ITSO portlets.
Check the ITSO Add User portlet and then click OK.
10.Click Done.
Add portlets to the Modify User page

The Modify User page should contain three portlets including ITSO Modify User,
ITSO Transaction History, and ITSO Account Balance Admin. These
administration portlets provide extended administrative functionality to the user
with the manager role.
The portlet ITSO Modify User provides an integrated interface similar to the
portlet ITSO Add User, which is used to modify the personal details of the chosen
customer and the accounts held by the customer. This portlet also incorporates a
Click-To-Action icon that enables portlet messaging between the three
administration portlets placed on this page. Currently WebSphere Portal Server’s

property broker can deliver the information through the Click-To-Action
technology to the target portlets only when placed on the same page. For this
reason, it is required to place the three administration portlets on the same page.
The portlet ITSO Transaction History allows the manager to view the details of
transactions executed on an account or customer.
The portlet ITSO Account Balance Admin allows the manager to view the details
of the accounts held by the selected customer.
The portlets can be added to the Modify User page, as follows:

2. Click Modify User.
3. Click the pencil icon (Edit Page Layout).
4. For the Modify User page, we will use the default two column page layout.
Click Add portlets in the left-column container.
Check the following and then click OK:
– Check ITSO Account Balance Admin.
– Check ITSO Modify User.
– Check ITSO Transaction History.
7. Rearrange the portlet layout on the Modify User page.
a. After adding the portlets to the page you will see a page like Figure 10-7
on page 457. Click the right-hand arrow icon ( >) to move the ITSO
Account Balance Admin portlet to the right-column container (see
Figure 10-7 on page 457).
Figure 10-7 Edit page layout for Modify User page after adding portlets
b. Click the right-hand arrow icon (>) to move the ITSO Transaction History
portlet to the right-column container.
c. From the right-column container, click the up arrow (^) for the ITSO
Transaction History portlet.
When complete, the portlets should be arranged on the page as seen in

Figure 10-8 Modify User portlet page layout
8. Click Done.
Add portlets to Access Accounts page

The page Access Accounts (Customer) should contain two portlets, namely,
ITSO Transfer Funds and ITSO Account Balance. These portlets provide
personalized service to the logged in customer. The portlet ITSO Transfer Funds
provide a service to transfer funds between the checking and savings accounts.
The portlet ITSO Account Balance provides a service to view the balance in the
checking and savings account.
The portlets can be added to the Access Account page, as follows:

2. Click Access Account.
3. Click the pencil icon (Edit Page Layout).
4. From the Edit Layout page, click the one column icon.
5. When the message If you have derived or personalized pages based off
this page, then all those changes will be lost. Do you wish to
continue? appears, click OK.
6. Click Add portlets.
Check the following and then click OK:
– Check ITSO Account Balance.
– Check ITSO Transfer Funds.
9. Rearrange the portlet layout on the Access Account page by clicking the
down arrow icon to move the ITSO Account Balance portlet below the ITSO
Transfer Funds portlet.
10.Click Done.
10.3.7 Modify resource permissions

This section describes how to set resource permissions for the ITSO Bank pages
and portlets based on the roles of users.
Modify page permissions

The Add User and Modify User pages will contain the ITSOBank application’s
administration portlets. Only the user ID with the manager role should be granted
explicit access to these pages. In our example, we create the user ID manager
with the role manager in 10.2.5, “Create the groups and users for the ITSO Bank
application” on page 438. The default behavior of WebSphere Portal Server
V5.0.2 is to grant access to the All authenticated portal users group for the newly
created pages.
To change the page permission such that user IDs with the customer role do not
have access permissions to the Add User and Modify User pages, do the
following:
1. From the Administration page, click Access → Resource Permissions.
2. From the Resource Types page, click Pages.
3. Click Content Root.
4. Click My Portal.
5. Assign access to the ITSO Bank page.
a. Click the key icon under Assign access for ITSO Bank page.
b. Uncheck the Allow Inheritance checkboxes for the Privileged User role
and User role.

c. Click OK.
6. Click ITSO Bank page.
7. Assign access to the Add User page.
a. Click the key icon under Assign access for Add User page title as seen
Figure 10-9.
Figure 10-9 Assign access for Add User page
and User role, as seen in Figure 10-10 on page 461.
Figure 10-10 Uncheck privileged user
c. Click the pencil icon in the Edit Role column for the Privileged User.
d. From the Assign Access for: Pages → Add User page, click Add.
e. When the Search for Users and User Groups page appears, do the
following:
i. Select User Groups from the Search for Users or User Groups
drop-down list.
ii. Select cn from the Search on drop-down list.
iii. Enter ITSOManagers in the Search for text box.
iv. Click Search.
f. After clicking search, the page will be updated. Check the checkbox in the
Select column for the ITSOManagers group.
g. Click OK.
h. Click Done.
i. Click OK.

8. Assign access to the Modify User page.
a. Click the key icon under Assign access for Modify User page.
and User role.
d. From the Assign Access for: Pages → Modify User page, click Add.
following:
drop-down list.
iv. Click Search.
f. After clicking Search, the page will be updated. Check the checkbox in the
g. Click OK.
h. Click Done.
i. Click OK.
9. Assign access to the Access Account page.
a. Click the key icon under Assign access for Access Account page.
and User role.
d. From the Assign Access for: Pages → Access Account page, click Add.
following:
drop-down list.
iii. Enter ITSOCustomers in the Search for text box.
iv. Click Search.
Select column for the ITSOCustomers group.
g. Click OK.
h. Click Done.
i. Click OK.
j. Click Done.
Modify portlet permissions

The default behavior of WebSphere Portal V5.0.2 is to disable access to portal
users for the newly installed portlets. This section will describe how to assign
permissions for the ITSOManagers and ITSOCustomers groups for the listed
portlets:
򐂰 ITSOManagers group
ITSO Bank portlets used by the ITSOManagers group:
– ITSO Account Balance Admin
– ITSO Add User
– ITSO Modify User
– ITSO Transaction History
򐂰 ITSOCustomers group
ITSO Bank portlets used by the ITSOCustomers group:
– ITSO Account Balance
– ITSO Transfer Funds
To modify the portlet permissions, do the following:

1. From the Administration page, click Access → Resource Permissions.
2. Click Portlets.
3. From the Portlets Search page, do the following:
– Click Search.
From the results of the search, you should have a list of ITSO portlets, as seen in

Figure 10-11 ITSO Bank portlets
Modify portlet permissions for the ITSOManagers group

To modify the portlet permissions for the ITSOManagers group, do the following
for each of the listed portlets:
򐂰 ITSO Account Balance Admin
򐂰 ITSO Modify User
򐂰 ITSO Transaction History
򐂰 ITSO Add User
1. Modify the ITSO Account Balance Admin portlet permissions for the
ITSOManagers group as follows:
a. Click the key icon under Assign access for ITSO Account Balance Admin
portlet.
b. Uncheck the Allow Inheritance checkbox for the User role.
d. From the Assign: Portlets → ITSO Account Balance Admin page, click
Add.
following:
drop-down list.
iv. Click Search.
g. Click OK.
h. Click Done.
i. Click OK.
2. Repeat the process to modify portlet permissions (step 1) for each of the
remaining portlets for the ITSOManagers group.
– ITSO Modify User
– ITSO Transaction History
Note: The ITSO Modify User portlet, ITSO Transaction History portlet, and
ITSO Account Balance portlet are developed to incorporate
Click-To-Action technology supported by WebSphere Portal’s Property
Broker. They are programmatically enhanced to support the creation and
deletion of wire between the Click-To-Action enabled portlets. This
administration of wire requires the role of Privileged User. So the
ITSOManagers group is granted the role of Privileged User only for these
three portlets.
3. Modify the ITSO Add User portlet permissions for the ITSOManagers group
as follows:
a. Click the key icon under Assign access for ITSO Add User portlet.
c. Click the pencil icon in the Edit Role column for the User.
d. From the Assign: Portlets → ITSO Add User page, click Add.

following:
drop-down list.
iv. Click Search.
f. After clicking search, the page will be updated. Check the checkbox in the
g. Click OK.
h. Click Done.
i. Click OK.
Modify portlet permissions for the ITSOCustomers group

To modify the portlet permissions for the ITSOCustomers group, do the following
for each of the listed portlets:
򐂰 ITSO Account Balance
򐂰 ITSO Transfer Funds
1. Modify the ITSO Account Balance portlet permissions for the ITSOCustomers
group as follows:
a. Click the key icon under Assign access for ITSO Account Balance portlet.
c. Click the pencil icon in the Edit Role column for the User.
d. From the Assign: Portlets → ITSO Account Balance page, click Add.
following:
drop-down list.
iii. Enter ITSOCustomers in the Search for text box.
iv. Click Search.
Select column for the ITSOCustomers group.
g. Click OK.
h. Click Done.
i. Click OK.
2. Repeat the process to modify portlet permissions (step 1) for the ITSO
Transfer Funds portlet for the ITSOCustomers group.
3. Log out of WebSphere Portal.
10.3.8 Verify ITSO Bank application

This section is intended to perform a basic test that the ITSO Bank application is
working properly after deployment and setting permissions within WebSphere
Portal.
Note: Chapter 12, “Manage a secure portal solution” on page 503, includes
use case validation for the ITSO Bank.
Web browser:
2. Log in as user ID manager1.
The manager1 user ID was created in 10.2.5, “Create the groups and users
for the ITSO Bank application” on page 438.
3. Click the ITSOBank tab.
4. Click Add User.
Note: If the Add User portlet fails with the error message The portlet was not
available. Please contact your portal administrator, you probably have
missed the step to restart the ITSOBankServer. Restart the ITSOBankServer
for changes to take effect.
10.3.9 Externalize the ITSO Bank resources

This section describes how to externalize resources for the ITSO Bank portlet
pages.
This section includes the following steps:

򐂰 ITSO Bank externalize a resource overview.
򐂰 Back up systems prior to externalizing a resource.
򐂰 Externalize the ITSO Bank pages resource.
򐂰 Verify the Tivoli Access Manager object space and ACLs.
򐂰 Verify the ITSO Bank application.

ITSO Bank externalize a resource overview
Table 10-1 defines the ITSO Bank page resource permission assignments
defined within WebSphere Portal. Table 10-2 defines the ITSO Bank portlet
resource permission assignments defined within WebSphere Portal.
When externalizing the ITSO Bank page resources, we will need to explicitly
define the permission assignments for the pages due to the inheritence being
severed.
Table 10-1 ITSO Bank page resource permission assignments

Resource types Roles
ITSO Bank pages Privileged User Administrator
ITSO Bank None wpsadmins
Add User ITSOManagers wpsadmins
Modify User ITSOManagers wpsadmins
Access Account ITSOCustomers wpsadmins
Table 10-2 ITSO Bank portlet resource permission assignments

Resource types Roles
ITSO portlets User Administrator
ITSO Account Balance Admin ITSOManagers wpsadmins
ITSO Add User ITSOManagers wpsadmins
ITSO Modify User ITSOManagers wpsadmins
ITSO Transaction History ITSOManagers wpsadmins
ITSO Account Balance ITSOCustomers wpsadmins
ITSO Transfer Funds ITSOCustomers wpsadmins
Back up systems prior to externalizing a resource

We recommend that you perform system backups prior to externalizing your
resources. Within the ITSO example runtime environment, we performed a
backup of the Portal Server node and the Policy Server node.
Externalize the ITSO Bank pages resource
This section describes how to extrenalize the ITSO Bank pages resource using
the WebSphere Portal Resource Permission portlet.
URL:
Access → Resource Permissions.
4. Externalize the resource permissions for the ITSO Bank page.
a. Click Pages under Resource Type column.
b. Click Content Root in the Page Title column.
c. Click My Portal.
d. Click the right arrow (>) in the Externalize/Internalize column for the ITSO
Bank page.
e. You will be prompted Are you sure you want to place the resource
under External Access Control? Click OK.
You should see the message Resource Successfully externalized.
f. Click Done.
5. Externalize the resource permissions for portlets.
a. Click Portlets.
b. From the Portlet search page do the following:
• Search on: Select Title contains.
• Search for: ITSO
• Click Search.
c. Repeat the following steps for each of the listed portlets:
• ITSO Account Balance
• ITSO Account Balance Admin
• ITSO Add User
• ITSO Modify User
• ITSO Transaction History
• ITSO Transfer Funds
i. Click the right arrow (>) in the Externalize/Internalize column for the
respective portlet.
ii. You will be prompted Are you sure you want to place the resource
under External Access Control? Click OK.

d. After externalizing all the ITSO portlets, click Done.
Verify the Tivoli Access Manager object space and ACLs

Verify that the objects have been created properly in the Tivoli Access Manager
object space and ACLs have been created. The verification can be performed
using the Tivoli Access Manager pdadmin command line tool or the Web Portal
Manager Web-based interface. For details refer to “Verify the Tivoli Access
Manager object space and ACLs” on page 343.
Verify the ITSO Bank application

Now that the ITSO Bank pages have been externalized and roles have been
assigned, we need to verify the access to the ITSO Bank pages. For details refer
to 12.5, “Verifying the ITSO Bank application and runtime” on page 557.
11
Chapter 11. Security hardening

In 2.1, “Security domain and risk management” on page 14, we outlined many
security categories found in the security domain. The focus of this chapter is on
security hardening for the application middleware.

򐂰 Configure CSIv2 SSL settings.
򐂰 Enable SSL for LDAP.
򐂰 Replace the default SSL certificates for the SOAP connector.
򐂰 Additional security hardening guidelines.

11.1 Configure CSIv2 SSL settings
This section describes how to configure WebSphere Application Server CSIv2
settings, which will affect both enabling SSL for LDAP and replacing SSL
certificates for SOAP connectors.
By default the CSIv2 transports (inbound/outbound) are configured to use the

Dummy SSL certificates that are stored in the DummyServerKeyFile.jks and
DummyServerTrustFile.jks keystores. Since these certificates are distributed
with every WebSphere Application Server installation media, they do not provide
any real security. We will describe how to create your own key and trust files.
WebSphere Application Server V5 supports two security authentication

protocols:
򐂰 Common Secure Interoperability Version 2 (CSIv2)
򐂰 Security Authentication Service (SAS)
SAS is a legacy protocol used in WebSphere Application Server Version 3.x, and
Version 4.x. CSIv2 is an Object Management Group (OMG) industry standard
protocol that offers more vendor interoperability, as well as additional features.
The use of SAS protocol is only recommended for interoperability with
WebSphere Application Server V3.x and V4.x servers. In our environment we will
use the CSIv2 protocol.
WebSphere Application Server supports the following options for CSIv2 inbound
transport settings:
򐂰 TCP/IP: Only non-encrypted connections are used; SSL is not enabled.
򐂰 SSL-Supported: Both TCP/IP and SSL connections are accepted.
򐂰 SSL-Required: Only SSL connections are accepted.
For SSL connections both server authentication and client/server authentication

(mutual SSL) are supported. The SSL connection type is defined by the
endpoint, as shown in Table 11-1.
Table 11-1 CSIv2 endpoint types

SSL connection type Endpoint name
Server authenticated CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS
Mutually authenticated CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS
By default, the ports for CSIv2 connections are dynamically generated. If

connections need to be established across firewalls, fixed ports may be assigned
to the endpoint definitions. A zero port number indicates dynamic assignment.
In our example we will configure the CSIv2 endpoint with server authentication
and SSL-Required setting. We will configure it to use static port 7345.
11.1.1 Create SSL keys for CSIv2

To create SSL keys for CSIv2, do the following on the Portal Server node:
1. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the
ikeyman.bat command.
2. Create a CSIv2ServerKeyFile.jks and a self-signed certificate for CSIv2:
a. Click Key Database File → New.
b. Enter the following and click OK:
• Key database type: Select JKS.
• File Name: CSIv2ServerKeyFile.jks
• Location: C:\IBM\WebSphere\AppServer\etc
c. Enter and confirm the key file password. Click OK.
d. Select Personal Certificates from the pull-down menu underneath Key
database content.
e. Click New Self-Signed.
f. Modify the following fields and click OK:
• Key Label: wpwin1 CSIv2 Server Key
• Common Name: tamwin1.itso.ral.ibm.com
• Organization: IBM
g. Click Extract Certificate.
h. Modify the following fields and click OK:
• Data Type: Select Base64-encoded ASCII data.
• Certificate file name: csicert.arm
3. Create a CSIv2ServerTrustFile.jks:
• File Name: CSIv2ServerTrustFile.jks
Chapter 11. Security hardening 473

4. Import the CSIv2 Server Certificate:
a. Select Signer Certificates from the pull-down menu underneath Key
database content.
b. Click Add.
c. Modify the following fields and click OK:
• Certificate file name: csicert.arm
d. When prompted to enter a label for the certificate, enter: wpwin1 CSIv2
Server Certificate. Click OK.
e. Close the IBM Key Management window.
5. Close the IBM Key Management tool.
11.1.2 Configure the SSL repertoire for CSIv2

To configure the WebSphere SSL repertoire for CSIv2, do the following on the
Portal Server node:
2. Start WebSphere Application Server Administrative Console:
http://tamwin1.itso.ral.ibm.com:9090/admin
3. Log in as wpsbind user.
4. Configure the SSL repertoire:
a. Click Security → SSL.
b. In the SSL Configuration Repertoires screen click New.
c. Enter the following values and click OK.
• Alias: CSIv2SSLSettings
• Key File Name:
C:\ibm\WebSphere\AppServer\etc\CSIv2ServerKeyFile.jks
• Key File Password: <password>
• Key File Format: Select JKS
• Trust File Name:
C:\ibm\WebSphere\AppServer\etc\CSIv2ServerTrustFile.jks
• Trust File Password: <password>
• Trust File Format: Select JKS.
• Client Authentication: Uncheck.
• Security Level: Select HIGH.
• Cipher Suites: Do not modify.
• Cryptographic Token: Uncheck.
• Provider: Select IBMJSSE.
• Protocol: Select SSLv3.
d. Click Security → Authentication Protocol → CSIv2 Inbound
Transport.
e. Enter the following settings and click OK.
• Transport: Select SSL-Required.
• SSLSettings: Select wpwin1/CSIv2SSLSettings.
f. Click Security → Authentication Protocol → CSIv2 OutBound
Transport.
g. Enter the following settings and click OK.
• Transport: Select SSL-Required.
• SSLSettings: Select wpwin1/CSIv2SSLSettings.
5. Click Save.
6. When the Save to Master Configuration screen appears, click Save.
7. Log out from the Administrative Console.
8. Restart application server server1.
Note: At this time only server1 is needed. The changes will not take effect
on the other application servers (ITSOBankServer, WebSphere_Portal)
until restarted.
11.2 Enable SSL for LDAP

This section describes how to configure the Tivoli Directory Server for SSL as
well as how to configure SSL for connections between the LDAP directory and
middleware components. The advantage to enabling SSL connections to LDAP
is that data transferred is encrypted and no longer in clear text. The
disadvantage of enabling SSL connections to LDAP is slower performance.
In Chapter 7, “Configure the runtime environment” on page 259, we choose to

configure the system without SSL. We did so to ensure everything was working
properly and to isolate the tasks for enabling SSL for LDAP in one location to
provide a better understanding of the environment.
The IBM Tivoli Directory Server has the ability to protect LDAP access by
encrypting data with either Secure Sockets Layer (SSL) security or Transaction
Layer Security (TLS) or both. Both server authentication and client authentication
(mutual SSL) are supported when using SSL or TLS. We will use SSL with server
authentication. For more information about configuring TLS or mutual SSL,

please refer to Administration Guide, IBM Tivoli Directory Server V5.2,
SC32-1339.

1. Enable LDAP server for SSL connections.
2. Enable SSL for Tivoli Access Manager LDAP connections.
3. Enable SSL for WebSEAL LDAP connections.
4. Enable SSL for WebSphere LDAP connection.
5. Enable SSL for WebSphere Portal LDAP connections.
11.2.1 Enable LDAP server for SSL connections

To enable the Tivoli Directory Server for SSL connections, do the following the
Policy Server node:
1. Ensure IBM GSKit V7.0.1.16 is installed and configured as described in 6.2.3,
“IBM GSKit upgrade installation” on page 188.
2. Open a command line window and navigate to the c:\ibm\gsk7\bin directory.
3. Start the ikeyman utility by entering the following commands:
set JAVA_HOME=C:\ibm\WebSphere\AppServer\java
gsk7ikm
4. Create a self-signed certificate for the LDAP server:
• Key database type: Select CMS.
• File Name: ldapkey.kdb
• Location: c:\ibm\ldap\lib
c. In our case, we found an existing ldapkey.kdb. We chose to replace the
existing file when prompted by clicking Yes.
d. Enter and confirm the key file password. Select the Stash the password
to a file checkbox. Click OK.
e. Select Personal Certificates from the pull-down menu underneath Key
database content.
f. Click New Self-Signed.
g. Modify the following fields and click OK:
• Key Label: LDAP Server Key
• Common Name: tamwin1.itso.ral.ibm.com
h. Click Extract Certificate.
i. Modify the following fields and click OK:
• Certificate file name: ldapcert.arm
• Location: c:\ibm\ldap\lib
j. Close the IBM Key Management window.
5. Ensure the Tivoli Directory Server is started.
6. Modify the ldap-enable-ssl.ldif file found in the ITSO sample code
c:\6325code\hardening\ldap directory to point to the LDAP server keystore
that was created in previous steps. The contents of the ldap-enable-ssl.ldif
are listed in Example 11-1.
Example 11-1 ITSO ldap-enable-ssl.ldif file

#
# This file configures SSL communications for LDAP
# Update the ibm-slapdSslKeyDatabase location for your environment.
# Usage:
# ldapmodify -D cn=root -w <password> -h <ldap_server_host> -i ldap-enable-ssl.ldif
#
# Restart the server and admin daemon for changes to take effect.
#
dn: cn=SSL,cn=Configuration
changetype: modify
replace: ibm-slapdSslAuth
ibm-slapdSslAuth: serverAuth
-
replace: ibm-slapdSecurity
ibm-slapdSecurity: SSL
-
replace: ibm-slapdSslKeyDatabase
ibm-slapdSslKeyDatabase: c:\ibm\ldap\lib\ldapkey.kdb
7. Configure Tivoli Directory Server SSL access by executing the following

command:
ldapmodify -h tamwin1 -D cn=root -w passw0rd -i ldap-enable-ssl.ldif
8. Restart the following Windows services for the Tivoli Directory Server:
– IBM Tivoli Directory Server Admin Daemon V5.2
9. Verify successful startup of the Tivoli Directory Server by examining the
ibmslapd.log file in c:\ibm\ldap\var directory. It should contain the following
lines near the end of the file:
SSL port initialized to 636.
IBM Tivoli Directory (SSL), Version 5.2Server started.

Note: If the SSL settings were not configured properly, the Tivoli Directory
Server will only start in configuration mode, and the Admin Daemon will not
start at all.
After performing these steps, the Tivoli Directory Server will accept both
non-SSL LDAP connections on port 389 and SSL LDAP connections on port
636. The Tivoli Directory Server Admin Daemon will accept non-SSL
connections on port 3538 and SSL connections on port 3539.
Tip: To use the ldapsearch command after enabling SSL, specify the -Z
option. For example:
ldapsearch -Z -b dc=itso,dc=ibm,dc=com -s one objectclass=*
11.2.2 Enable SSL for Tivoli Access Manager LDAP connections

This section describes how to reconfigure Tivoli Access Manager components to
connect to the Tivoli Directory Server using SSL.
1. Copy the c:\ibm\ldap\lib\ldapcert.arm file to the c:\ibm\Tivoli\TAM\keytab
directory on the Policy Server node.
set JAVA_HOME=c:\ibm\WebSphere\AppServer\java
gsk7ikm
4. Import the self-signed certificate for LDAP server:
b. Enter the following values in the pop-up window:
• File Name: ldapcert.kdb
• Location: C:\IBM\Tivoli\TAM\keytab
c. Enter and confirm the key file password. Select the Stash the password
d. Select Signer Certificates from the pull-down menu underneath Key
database content.
e. Click Add.
• Location: c:\ibm\Tivoli\TAM\keytab
g. When prompted to enter a label for the certificate, enter LDAP Server
Certificate. Click OK.
h. Close the IBM Key Management window.
5. Modify the c:\ibm\Tivoli\TAM\etc\ldap.conf file and update the entries shown
in Example 11-2. Note that we checked stash password to keyfile; thus the
LdapSSLKeyFilePwd value is not needed.
Example 11-2 Enable SSL for LDAP connections in ldap.conf file

LdapSSL = ssl
LdapSSLKeyFile = c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb
LdapSSLKeyFileDn = “LDAP Server Certificate”
LdapSSLKeyFilePwd =
6. Modify the c:\ibm\Tivoli\TAM\etc\ivmgrd.conf file and update the entries

shown in Example 11-3.
Example 11-3 Enable SSL for LDAP connections in ivmgrd.conf file

ssl-enabled = yes
ssl-keyfile = c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb
ssl-keyfile-dn = “LDAP Server Certificate”
ssl-keyfile-pwd =
7. Modify the c:\ibm\Tivoli\TAM\etc\ivacld.conf file and update the entries shown

in Example 11-4.
Example 11-4 Enable SSL for LDAP connections in ivacld.conf file

ssl-enabled = yes
ssl-keyfile-pwd =
8. Restart the following Windows services:

– Access Manager Authorization Server
9. Verify that Tivoli Access Manager is connected to LDAP using SSL. From the
command line window enter the following command:
ldapsearch -Z -K c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb -b
cn=connections,cn=monitor -s base -h tamwin1 -D cn=root -w passw0rd
objectclass=*

You should see output similar to Example 11-5. Note that there should be an
SSL indicator for the connection:
CN=IVMGRD/MASTER,CN=SECURITYDAEMONS,SECAUTHORITY=DEFAULT
Example 11-5 Verify TAM connections to LDAP server

cn=connections,cn=monitor
connection=14 : 9.42.171.95 : 2004-05-31 22:04:01 GMT : 0 : 41 :
CN=IVMGRD/MASTER,CN=SECURITYDAEMONS,SECAUTHORITY=DEFAULT : : SSL
connection=21 : 9.42.171.95 : 2004-05-31 22:12:00 GMT : 1 : 1 : CN=ROOT : : SSL
11.2.3 Enable SSL for WebSEAL LDAP connections

This section describes how to configure Tivoli Access Manager WebSEAL to
connect to the Tivoli Directory Server using SSL.
1. Ensure IBM GSKit V7.0.1.16 is installed and configured as described in 6.2.3,
“IBM GSKit upgrade installation” on page 188.
2. Copy the c:\ibm\ldap\lib\ldapcert.arm file on the Policy Server node to the
c:\ibm\Tivoli\TAM\keytab directory on the Reverse Proxy node.
gsk7ikm
5. Import the self-signed certificate for the LDAP server:
• File Name: ldapcert.kdb
c. Enter and confirm the key file password. Select the Stash the password
database content.
e. Click Add.
g. When prompted to enter a label for the certificate, enter LDAP Server
Certificate. Click OK.
6. Modify the c:\ibm\Tivoli\TAM\etc\ldap.conf file and update the entries shown
in Example 11-6.
Example 11-6 Enable SSL for LDAP connections in ldap.conf file

LdapSSL = ssl
LdapSSLKeyFile = c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb
LdapSSLKeyFileDn = “LDAP Server Certificate”
LdapSSLKeyFilePwd =
7. Modify the c:\ibm\Tivoli\PDWeb\etc\webseald-default.conf file and update the

entries shown in Example 11-7.
Example 11-7 Enable SSL for LDAP connections in webseald-default.conf file

ssl-enabled = yes
ssl-keyfile-pwd =
8. Restart the Access Manager WebSEAL-default Windows service.

9. Verify that WebSEAL is connected to LDAP using SSL. From the command
line window enter the following command:
ldapsearch -Z -K c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb -b
cn=connections,cn=monitor -s base -h tamwin1 -D cn=root -w passw0rd
objectclass=*
You should see output containing the SSL flag for the following connection:
CN=DEFAULT-WEBSEALD/WSWIN1,CN=SECURITYDAEMONS,SECAUTHORITY=DEFAULT
11.2.4 Enable SSL for WebSphere LDAP connection

This section describes how to create a key file, import the LDAP server
certificate, and configure an SSL repertoire that will be used for LDAP
connections by WebSphere Application Server Security.
1. Copy the c:\ibm\ldap\lib\ldapcert.arm file from the Policy Server node to the
c:\ibm\WebSphere\AppServer\etc directory on the Portal Server node.

3. Import the LDAP server certificate:
• File Name: LdapClientTrustFile.jks
database content.
e. Click Add.
g. When prompted to enter a label for the certificate, enter tamwin1 LDAP
6. Log in as wpsbind user.
7. Click Security → SSL.
8. In the SSL Configuration Repertoires page click New.
9. Enter the following values and click OK.
Note: Since we do not use mutual SSL connections for LDAP, we can
specify LdapClientTrustFile.jks for both Key File Name and Trust File
Name settings. For mutually authenticated connections, a self-signed
certificate would need to be generated for WebSphere Application Server.
Key File Name should then point to the key file containing the private key
for the generated certificate.
– Alias: LDAPSSLSettings
– Key File Name:
C:\ibm\WebSphere\AppServer\etc\LdapClientTrustFile.jks
– Key File Password: <password>
– Key File Format: Select JKS.
– Trust File Name:
C:\ibm\WebSphere\AppServer\etc\LdapClientTrustFile.jks
– Trust File Password: <password>
– Trust File Format: Select JKS.
– Client Authentication: Uncheck.
– Security Level: Select HIGH.
– Cipher Suites: Do not modify.
– Cryptographic Token: Uncheck.
– Provider: Select IBMJSSE.
– Protocol: Select SSLv3.
– Fix Advanced LDAP Settings.
Note: Fix Advanced LDAP Settings.
The following steps are required because WebSphere Portal configuration

scripts incorrectly set the LDAP server type to IBM_Directory_Server while
defining the custom search filters that are displayed on the Advanced
LDAP Settings page. Clicking Apply resets the LDAP server type to
Custom, which is the correct setting when custom search filters are used. If
these steps are skipped, the search filters will be reset to default values for
IBM_Directory_Server. When you click OK you will not be able to access
any applications after restarting WebSphere Application Server.
a. Click Security → User Registries → LDAP.

b. Click Advanced LDAP Settings.
c. Click Apply.
10.Click Security → User Registries → LDAP.
11.Modify the following settings and click OK.
Note: Do not modify any other values.
– Port: 636
– Check SSL Enabled.
– SSL Configuration: Select wpwin1/LDAPSSLSettings.
12.You should now be on the Global Security page. Click Apply to validate the
LDAP connection.
Important: Verify that after clicking Apply you do not receive any LDAP
validation errors. If there are any errors, correct the problems before saving
the configuration, otherwise WebSphere Application Server will not be able
to start.

13.Click Save.
14.When the Save to Master Configuration screen appears, click Save.
15.Log out from the Administrative Console.
16.Restart server1 for the changes to take effect.
Note: At this time only server1 is needed. The changes will not take effect
on the other application servers (ITSOBankServer, WebSphere_Portal)
until restarted.
11.2.5 Enable SSL for WebSphere Portal LDAP connections

This section includes the following tasks to configure WebSphere Portal to
connect to the Tivoli Directory Server using SSL:
򐂰 Import LDAP certificate to WebSphere Portal keystore.
򐂰 Import LDAP server certificate into the CSIv2 trust file.
򐂰 Configure WMM for LDAP SSL connections.
Import LDAP certificate to WebSphere Portal keystore

WebSphere Portal has no configuration setting to use a specific Java keystore
file for secure LDAP connections. Therefore the certificates needed by
WebSphere Portal have to be imported into the JVM default keystore. The JVM
default keystore file is called cacerts and it is located in the
<WAS_HOME>/java/jre/lib/security directory. By default, the password for this
file is changeit.
To import the LDAP server certificate into the WebSphere Portal keystore, do the
following:
1. Copy the c:\ibm\ldap\lib\ldapcert.arm file from the Policy Server node to the
c:\ibm\WebSphere\AppServer\java\jre\lib\security directory on the Portal
Server node.
a. Click Key Database File → Open.
• File Name: cacerts
• Location: C:\IBM\WebSphere\AppServer\java\jre\lib\security
c. When prompted for the password, enter changeit. Click OK.
database content.
e. Click Add.
Import LDAP server certificate into the CSIv2 trust file

To import the LDAP server certificate into the CSIv2 trust file, do the following on
the Portal Server node:
• Location: C:\IBM\WebSphere\AppServer\etc\
database content.
e. Click Add.

Configure WMM for LDAP SSL connections
To configure WebSphere Member Management (WMM) for LDAP SSL
connections, do the following:
Important: The normal way to modify WebSphere Portal configuration is by

editing the wpconfig.properties file and then running a wpsconfig task to load
the configuration. At the time of writing, attempting to reconfigure WebSphere
Portal for LDAP SSL connections using this approach resulted in a
non-functional portal engine and exceptions in WMM and
ExternalAccessControl subsystems.
As an alternative, we updated the wmm.xml file directly. Beware that

wpsconfig tasks that involve LDAP configuration will overwrite this file, and
you may need to edit it again after running wpsconfig.
1. Edit the c:\ibm\WebSphere\PortalServer\shared\app\wmm\wmm.xml file and

modify the settings in the <ldapRepository> stanza, as shown in
Example 11-8.
– Change the ldapPort value to 636
– Insert a java.naming.security.protocol="ssl" entry.
Example 11-8 Modify <wp_home>/shared/app/wmm/wmm.xml file for secure LDAP

<ldapRepository name="wmmLDAP"
UUID="LDAP1"
adapterClassName="com.ibm.ws.wmm.ldap.ibmdir.IBMDirectoryAdapterImpl"
supportDynamicAttributes="false"
configurationFile="C:/ibm/WEBSPH~1/PORTAL~1/wmm/wmmLDAPServerAttributes.xml"
wmmGenerateExtId="true"
supportGetPersonByAccountName="true"
profileRepositoryForGroups="LDAP1"
supportTransactions="false"
adminId="uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com"
adminPassword="5mApqlzuuPW7iNQpYWkEKQ=="
ldapHost="tamwin1.itso.ral.ibm.com"
ldapPort="636"
ldapTimeOut="6000"
ldapAuthentication="SIMPLE"
ldapType="0"
java.naming.security.protocol="ssl"
groupCacheRefreshInterval="-1">

3. Verify WebSphere Portal by logging in as user wpsadmin:
11.2.6 Enable SSL for Web Admin Tool LDAP connection
To enable the Tivoli Directory Server Web Administration Tool to manage the
directory server over the SSL connection, do the following on the Policy Server
node.
Configure SSL certificate for LDAP

This section describes how to create a key file and import the LDAP server
certificate.
1. Copy the c:\ibm\ldap\lib\ldapcert.arm file to the
c:\ibm\WebSphere\AppServer\etc directory.
• File Name: LdapClientTrustFile.jks
database content.
e. Click Add.
Configure Web Admin Tool for LDAP SSL connections

To configure the Tivoli Directory Server Web Administration Tool for LDAP SSL
connections, do the following on the Policy Server node:
node.

2. Start the Tivoli Directory Server Web Administration Tool in a Web browser:
https://tamwin1.itso.ral.ibm.com:9443/IDSWebApp/IDSjsp/Login.jsp
3. Log in to the Console Admin with the username webadmin.
4. Configure the SSL key file for connection to the directory server.
a. Click Console Administration → Manage console properties.
b. Click SSL key database.
• Trust database path and file name:
c:\IBM\WebSphere\AppServer\etc\LdapClientTrustFile.jks
• Trust password: <password>
• Trust database file type: Select jks.
5. Configure the SSL connection to the directory server.
a. Click Console Administration → Manage console servers.
b. Select the tamwin1.itso.ral.ibm.com server. Click Edit.
• Port: 636
• Administration port: 3539
• Check SSL Enabled.
d. Click Close.
6. Click Logout.
7. Start the Web Administration Tool login page and log in to LDAP hostname
tamwin1.itso.ral.ibm.com with username cn=root.
8. If the login completes successfully, the SSL connection to the directory server
is working. Click Logout.
11.2.7 Configure Tivoli Directory Server client utilities for SSL

The configuration steps in this section are optional. Performing them will allow
you to use the Tivoli Directory Server client utilities, such as ldapsearch, without
explicitly specifying the SSL keyfile on the command line. The following
procedure is not needed on the Policy Server node, since we have created the
ldapkey.kdb on this node.
To configure the Tivoli Directory Server client utilities for SSL on the Reverse
Proxy node, do the following:
1. Navigate to the c:\ibm\ldap\lib directory on the Reverse Proxy node.
2. Copy the c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb file to
c:\ibm\ldap\lib\ldapkey.kdb. (Note: Change the file name to ldapkey.kdb.)
3. Copy the c:\ibm\Tivoli\TAM\keytab\ldapcert.sth file to
c:\ibm\ldap\lib\ldapkey.sth. (Note: Change to the file name to ldapkey.sth.)
4. Verify the ldapsearch command using SSL. Open a command prompt and
enter the following command on a single line:
ldapsearch -h tamwin1 -D cn=root -w passw0rd -s base -b
cn=connections,cn=monitor -Z objectclass=*
You should see a list of active connections on the LDAP server similar to
Example 11-9. Verify that the connection for the CN=ROOT user has the SSL
attribute set. This is the connection from the ldapsearch utility.
Example 11-9 LDAP server connection list

cn=connections,cn=monitor
connection=14 : 9.42.171.95 : 2004-05-31 22:04:01 GMT : 0 : 144 :
CN=IVMGRD/MASTER,CN=SECURITYDAEMONS,SECAUTHORITY=DEFAULT : : SSL
connection=23 : 9.42.171.93 : 2004-06-01 15:27:56 GMT : 0 : 32 :
UID=WPSBIND,CN=USERS,DC=ITSO,DC=IBM,DC=COM : :
connection=46 : 9.42.171.95 : 2004-06-01 18:34:09 GMT : 0 : 5 :
UID=WPSBIND,CN=USERS,DC=ITSO,DC=IBM,DC=COM : : SSL
connection=48 : 9.42.171.92 : 2004-06-01 18:50:43 GMT : 0 : 10 :
CN=DEFAULT-WEBSEALD/WSWIN1,CN=SECURITYDAEMONS,SECAUTHORITY=DEFAULT : : SSL
connection=51 : 9.42.171.92 : 2004-06-01 18:56:47 GMT : 0 : 10 :
CN=DEFAULT-WEBSEALD/WSWIN1,CN=SECURITYDAEMONS,SECAUTHORITY=DEFAULT : : SSL
connection=54 : 9.42.171.92 : 2004-06-01 19:05:07 GMT : 1 : 1 : CN=ROOT : : SSL
11.2.8 Disable non-SSL access to Tivoli Directory Server
Note: Do not complete this section if using the ITSO Bank application.
We were not able to configure the ITSO Bank sample portlets for access to the
LDAP server via SSL. For this reason, the ITSO Bank sample application will
not work if you complete this section on disabling non-SSL access to the Tivoli
Directory Server.
This procedure describes how to disable non-SSL access to the Tivoli Directory
Server.
1. Disable non-SSL connections to the Tivoli Directory Server by executing the
following command on the Policy Server node:
ldapmodify -h tamwin1 -D cn=root -w passw0rd -i ldap-disable-nonssl.ldif

The ldap-disable-nonssl.ldif file can be found in the ITSO sample code
c:\6325code\hardening\ldap directory.
Example 11-10 ITSO ldap-disable-nonssl.ldif file

# This file disables non-SSL connections for Tivoli Directory Server.
# Usage:
# ldapmodify -D cn=root -w <password> -h <ldap_server_host> -i ldap-disable-nonssl.ldif
#
# Restart the directory server and admin daemon for changes to take effect.
#
dn: cn=SSL,cn=Configuration
changetype: modify
replace: ibm-slapdSecurity
ibm-slapdSecurity: SSLOnly
2. Restart the following Windows services for the Tivoli Directory Server:
– IBM Tivoli Directory Server Admin Daemon V5.2
3. After performing these steps, the Tivoli Directory Server will only accept SSL
LDAP connections on port 636. The Admin Daemon will only accept SSL
connections on port 3539.
Enter the following command in a Windows command window on the Policy
Server node:
netstat -an | more
Look for open tcp listening ports on 389 and 3538. These ports should not be
listed, as they are the non-ssl ports for LDAP that have been turned off in this
section.
11.3 Replace the default SSL certificates for the SOAP

connector
By default, the SOAP connector is configured to use dummy SSL certificates,
which are stored in the DummyServerKeyFile.jks and DummyServerTrustFile.jks
keystores. Since these certificates are distributed with every WebSphere
Application Server installation media, they do not provide any real security.
This section describes how to create your own key and trust files:
򐂰 Configure SSL certificate and repertoire for SOAP connector.
򐂰 Configure WebSphere administration utilities.
򐂰 Configure WebSphere Portal SOAP connection credentials.
11.3.1 Configure SSL certificate and repertoire for SOAP connector
This section describes how to configure the SSL certificate and repertoire for the
SOAP connector on the Portal Server node.
Create SSL keys for SOAP connector

To create the SSL keys for the SOAP connector, do the following:
2. Create a SOAPServerKeyFile.jks file and a self-signed server certificate for
SOAP connections:
b. Enter the following and then click OK:
• File Name: SOAPServerKeyFile.jks
database content.
• Key Label: wpwin1 SOAP Server Key
• Common Name: wpwin1.itso.ral.ibm.com
• Certificate file name: soapservercert.arm
3. Create a SOAPClientKeyFile.jks and a self-signed client certificate for SOAP
connections:
• File Name: SOAPClientKeyFile.jks

database content.
• Key Label: wpwin1 SOAP Client Key
• Common Name: wpwin1.itso.ral.ibm.com
• Certificate file name: soapclientcert.arm
4. Create a SOAPClientTrustFile.jks and import the server certificate:
• File Name: SOAPClientTrustFile.jks
database content.
e. Click Add.
g. When prompted to enter a label for the certificate, enter wpwin1 SOAP
Server Certificate. Click OK:
5. Create SOAPServerTrustFile.jks and import the client certificate:
• File Name: SOAPServerTrustFile.jks
database content.
e. Click Add.
• Certificate file name: soapclientcert.arm
Client Certificate. Click OK.
6. Close the IBM Key Management tool.
Create and configure SSL repertoire for SOAP connectors

This section describes how to create an SSL repertoire for SOAP connections
and how to configure the SOAP Connectors for this SSL repertoire.
1. Ensure that the server1 application server is started. Open the WebSphere
Application Server Administrative Console in a Web browser:
2. Log in as the wpsbind user.
3. Click Security → SSL.
4. In the SSL Configuration Repertoires screen click New.
5. Enter the following values and click OK.
– Alias: SOAPSSLSettings
– Key File Name:
C:\ibm\WebSphere\AppServer\etc\SOAPServerKeyFile.jks
– Key File Password: <password>
– Key File Format: Select JKS.
– Trust File Name:
C:\ibm\WebSphere\AppServer\etc\SOAPServerTrustFile.jks
– Trust File Password: <password>
– Trust File Format: Select JKS.
– Client Authentication: uncheck.
– Security Level: Select HIGH.
– Cipher Suites: Do not modify.
– Cryptographic Token: Uncheck.
– Provider: Select IBMJSSE.
– Protocol: Select SSLv3.
6. Configure the SOAP Connector for the server1 application server.
a. Click Servers → Application Servers.

b. Click server1.
c. Click Administration Services.
d. Click JMX Connectors.
e. Click SOAP Connector.
f. Click Custom Properties.
g. Click sslConfig.
h. Enter the following and click OK:
• Name: sslConfig (default)
• Value: wpwin1/SOAPSSLSettings
Where wpwin1/SOAPSSLSettings is the name of the SSL repertoire
created in “Create and configure SSL repertoire for SOAP connectors”
on page 493.
7. Repeat the previous step for the WebSphere_Portal and ITSOBankServer
application servers.
8. Click Save.
9. When the Save to Master Configuration screen appears, click Save.
10.Log out from the Administrative Console.
11.Restart all currently running application servers.
Note: At this stage you will not be able to manage any application servers
using WebSphere utilities such as serverStatus or stopServer because
they have not been configured yet for the new SOAP SSL settings.
11.3.2 Configure WebSphere administration utilities

To configure the WebSphere administration utilities, do the following:
1. Navigate to the c:\ibm\WebSphere\AppServer\properties directory and create
a backup copy of the soap.client.props file.
2. Edit the soap.client.props file and modify the properties listed in
Example 11-11.
Example 11-11 soap.client.props file fragment for Policy Server node

#------------------------------------------------------------------------------
# SOAP Client Security Enablement
#
# - security enabled status ( false[default], true )
#------------------------------------------------------------------------------
com.ibm.SOAP.securityEnabled=true
#------------------------------------------------------------------------------
# SSL Configuration
#
# - keyStore and trustStore (fully qualified path to file)
# - keyStorePassword and trustStorePassword (string specifying password - encoded or not)
#------------------------------------------------------------------------------
com.ibm.ssl.keyStore=C\:/ibm/WebSphere/AppServer/etc/SOAPClientKeyFile.jks
com.ibm.ssl.keyStorePassword=passw0rd
com.ibm.ssl.trustStore=C\:/ibm/WebSphere/AppServer/etc/SOAPClientTrustFile.jks
com.ibm.ssl.trustStorePassword=passw0rd
3. Encode the passwords that are entered in open text (optional).

a. Open a command line window and navigate to the
c:\ibm\WebSphere\AppServer\bin directory.
b. Enter the following command on a single line to encode the
com.ibm.ssl.keyStorePassword property:
PropFilePasswordEncoder ../properties/soap.client.props
com.ibm.ssl.keyStorePassword
c. Enter the folowing command on a single line to encode the
com.ibm.ssl.trustStorePassword property:
PropFilePasswordEncoder ../properties/soap.client.props
com.ibm.ssl.trustStorePassword
4. Verify the SOAP connectivity. Ensure that the server1 application server is
started and execute the following command:
serverStatus server1 -user wpsbind -password passw0rd
You should see the message The Application Server “server1” is
STARTED. If the connection to server1 fails, either the SOAP SSL connection is
configured improperly or server1 is not running.
11.3.3 Configure WebSphere Portal SOAP connection credentials

This section describes how to configure SSL trust files used by WebSphere
Portal for SOAP connections used during portlet deployment.
Note: The steps in this section are mandatory if you have modified the
WebSphere Application Server SOAP certificate settings as described in
“Configure SSL certificate and repertoire for SOAP connector” on page 491.

Import SOAP server certificate into CSIv2 trust file
To import the SOAP server certificate into the CSIv2 trust file, do the following:
c. Enter and confirm the key file password that you set when creating the
keystore. Click OK.
database content.
e. Click Add.
3. Close the IBM Key Management window.
Import SOAP server certificate into cacerts keystore

This section is necessary to be able to deploy portlets using the xmlaccess utility.
The xmlaccess utility has no configuration setting to use a specific Java Key
Store file for secure SOAP connections. Therefore the certificates needed by
xmlaccess have to be imported into the JVM default keystore. The JVM default
keystore file is called cacerts and it is located in the
<WAS_HOME>/java/jre/lib/security directory. By default, the password for this
file is changeit.
1. Copy the c:\ibm\WebSphere\AppServer\etc\soapservercert.arm file created in
“Create SSL keys for SOAP connector” on page 491 to the
c:\ibm\WebSphere\AppServer\java\jre\lib\security directory on the Portal
Server node.
• Key database type: Select JKS
• File Name: cacerts
• Location: c:\ibm\WebSphere\AppServer\java\jre\lib\security
c. Enter and confirm the key file password. The default password is
changeit. Click OK.
database content.
e. Click Add.
• Location: C:\IBM\WebSphere\AppServer\java\jre\lib\security
4. Close the IBM Key Management window.
Configure and load wpconfig.properties file

The steps in this section will update the deployment.truststore and
deployment.keystore credential slots in the WebSphere Portal Credential Vault.
Important: The wpsconfig secure-portal-ldap task will overwrite the

<wp_home>\shared\app\wmm\wmm.xml and
<wp_home>\wmm\wmmLDAPServerAttributes.xml files. If you have manually
modified these files earlier, which we did for the ITSO example, your changes
will be lost and you will have to modify them again.
In our example, we have modified the wmmLDAPServerAttributes.xml file in

10.3.3, “Modify the wmmLDAPServerAttributes.xml file” on page 449. The
wmm.xml file is modified manually in 11.2.5, “Enable SSL for WebSphere
Portal LDAP connections” on page 484.
1. Back up the
c:\ibm\WebSphere\PortalServer\wmm\wmmLDAPServerAttributes.xml.
2. Back up the c:\ibm\WebSphere\PortalServer\shared\app\wmm\wmm.xml.
3. Edit the c:\IBM\WebSphere\PortalServer\config\wpconfig.properties file and
modify the settings shown in Example 11-12.

Note: The trust and key file locations are relative to the <WAS_HOME>
directory.
The WpsHostName must be reset to the Portal Server node prior to

running wpsconfig and then changed back to the hostname of the Reverse
Proxy node after running wpconfig.
Example 11-12 Modify wpsconfig.properties for SOAP trust and key files
##################################################################
#
# Credentials for WAS administration secure SOAP connection
#
# Used for Portlet deployment with WAS security enabled
#
##################################################################
# WpsHostName=wswin1.itso.ral.com
# TrustStore: The location of the trust store

TrustStore=/etc/SOAPClientTrustFile.jks
# TrustStorePwd: The password to access the trust store.

TrustStorePwd=passw0rd
# KeyStore: The location of the key store

KeyStore=/etc/SOAPClientKeyFile.jks
# KeyStorePwd: The password to access the key store.

KeyStorePwd=passw0rd
4. Change to the c:\ibm\WebSphere\PortalServer\config directory.

5. Load the modified settings by executing the following command:
wpsconfig secure-portal-ldap
6. Fix the
c:\ibm\WebSphere\PortalServer\wmm\wmmLDAPServerAttributes.xml file as
described in the note in the beginning of “Configure and load
wpconfig.properties file” on page 497.
Restore the original wmmLDAPServerAttributes.xml from backup.
7. Fix the c:\ibm\WebSphere\PortalServer\shared\app\wmm\wmm.xml as
described in the note in the beginning of “Configure and load
wpconfig.properties file” on page 497.
Restore the original wmm.xml from backup.
8. Change the WpsHostName back to the hostname of the Reverse Proxy node
after running wpconfig in the wpconfig.properties file.
WpsHostName=wswin1.itso.ral.com
Verify SOAP configuration - Install portlet via GUI

To verify that the SOAP configuration is working properly, we recommend
deploying a portlet using the portal administration GUI.
For example, we installed the c:\6325code\deploy\ITSOCredentialVault.war

portlet provided with the ITSO sample code as follows:
1. Access the WebSphere Portal home page by entering the following URL in a
Web browser:
– Specify the location of the file:
c:\6325code\deploy\ITSOCredentialVault.war
6. Click Install.
You should see the message Portlets were successfully installed.
Verify XMLAccess utility - Install portlet via xmlaccess

This section describes how to verify the xmlaccess utility in the hardened
environment by installing a portlet. For example, we have provided an xml script
to install the WelcomePortlet.war portlet via the xmlaccess utility.
To verify that the xmlaccess utility is working properly, do the following:

1. Unininstall the WelcomePortlet.war portlet.
a. Access the WebSphere Portal home page by entering the following URL
in a Web browser:
b. Log in as user ID wpsadmin.
c. Click Administration.
d. Click Portlets → Manage Applications.
e. Select the WelcomePortlet.war.

f. Click Uninstall.
2. Create a welcomeportletdeploy.xml file like Example 11-13 that will be used
by the xmlaccess utility to install the worldclock.war.
The ITSO sample WelcomePortletDeploy.xml file can be found in the
c:\6325code\deploy directory.
Example 11-13 ITSO sample WelcomePortletDeploy.xml

<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
type="update"
create-oids="true">

<portal action="locate">


<web-app action="update" active="true" uid="com.ibm.wps.portlets.welcome">
<url>file:///$server_root$/installableApps/WelcomePortlet.war</url>

<portlet-app action="update" active="true" uid="com.ibm.wps.portlets.welcome.1">

<portlet action="update" active="true" objectid="thePortlet"
name="Welcome Portlet">
</portlet>
</portlet-app>
</web-app>

<content-node action="locate" objectid="parentPage" uniquename="wps.My Portal"/>

<content-node action="update" uniquename="wps.SamplePage" ordinal="last"
content-parentref="parentPage" active="true" allportletsallowed="false"
create-type="explicit" type="page">
<supported-markup markup="html" update="set"/>
<localedata locale="en"><title>Sample Page</title></localedata>
<component action="create" ordinal="100" type="container" orientation="H">

<component action="create" ordinal="100" type="control">

<portletinstance action="update" portletref="thePortlet"/>
</component>
</component>
</content-node>
</portal>
</request>
3. Open a command window and navigate to the

c:\ibm\WebSphere\PortalServer\bin directory.
4. Run the xmlaccess utility, as follows, on the Portal Server node:
xmlaccess -in c:\6325code\deploy\WelcomePortletDeploy.xml -user wpsadmin
-pwd password -url http://wpwin1.itso.ral.ibm.com/wps/config
You should see output like the following:
status element=”all” result=”ok”
5. Verify the portlet is listed under Manage Applications from the portal
administration tool.
Congratulations, you have completed the secure portal solutions gauntlet.
11.4 Additional security hardening guidelines

Due to time limitations we did not perform further security hardening for the
example environment. Listed below are some additional tasks that you may wish
to perform to further secure the environment:
򐂰 Run WebSphere Application Server processes as a non-administrative user.
򐂰 Secure RMI Connectors.
򐂰 Disable unused endpoints for application servers.
򐂰 Enable SSL between IBM HTTP Server and WebSphere Application Server.
򐂰 Define additional WebSphere Application Server administrative roles.
򐂰 Disable unused WebSphere HTTP transports.
11.4.1 Secure a WebSphere Network Deployment environment

In the real-world environment WebSphere Portal will frequently be deployed on
WebSphere Application Server Network Deployment edition. In the WebSphere
Application Server Network Deployment environment there are several
differences that need to be taken into account when planning security hardening.
Deployment Manager server

In a Network Deployment environment there will be at least one Deployment
Manager server. This server is used for centralized administration of all
application servers on all nodes that have been federated into cells. This server
contains the master repository for WebSphere Application Server configuration

files for all nodes, so particular care must be taken to secure it. It also runs the
WebSphere Application Server Administrative Console Web application, which is
used for centralized management of all nodes.
Deployment Manager servers must be hardened similarly to application servers

running on the Portal Server node.
Node agents
When the WebSphere Application Server node is federated into a cell, a node
agent application is deployed and started on the node. The nodeagent
application server must be hardened similarly to other application servers
running on WebSphere Portal node.
server1 application servers

When the WebSphere Application Server node is federated into a cell, the
Administrative Console Web application is removed from the server1 application
server. As a result, server1 usually no longer contains any applications that are
used in a production environment. In this case, server1 should not be started at
all.
11.4.2 Disable the IBM HTTP Server Administration service

We recommend disabling the IBM HTTP Administration Server on production
machines and configuring IBM HTTP Server by manually editing the httpd.conf
file. Disable the IBM HTTP Administration Windows service.
11.4.3 Disable the IBM HTTP Server on the Policy Server node
The IBM HTTP Server on this node is used only for administrator access to the
WebSphere Application Server Administrative Console, Tivoli Directory Server
Web Administration Tool, and Tivoli Access Manager Web Portal Manager. We
recommend disabling the IBM HTTP Server and IBM HTTP Administration
services completely and accessing the Web applications directly on WebSphere
Application Server HTTP Transport ports, for example:
򐂰 WebSphere Application Server Administrative Console
򐂰 Tivoli Directory Server Web Administration
https://tamwin1.itso.ral.ibm.com:9443/IDSWebApp/IDSjsp/Login.jsp
򐂰 Tivoli Access Manager Web Portal Manager
https://tamwin1.itso.ral.ibm.com:9443/pdadmin
12
Chapter 12. Manage a secure portal

solution
The object of this chapter describes the key administration tools and tasks for a
secure portal solution with the goal of providing the critical information to get
someone started. It is not intended as a standalone source for secure portal
administration. In addition, this chapter includes verification procedures for the
ITSO working example secure portal application.

򐂰 Tivoli administration tools and common tasks.
򐂰 WebSphere administration tools and common tasks.
򐂰 Start and stop servers for ITSO example nodes.
򐂰 Back up and restore of key configuration files and databases.
򐂰 Verifying the ITSO Bank application and runtime.

12.1 Tivoli administration tools and common tasks
This section documents the tools and tasks related to the administration of the
Tivoli products used in the secure portal solution. Tivoli Directory Server and the
Tivoli Access Manager administration tools and key tasks are explored.
Note: For more detailed information on Tivoli Access Manager V5.1 and Tivoli
Directory Server V5.2 refer to the following:
SC32-1359
򐂰 Command Reference, IBM Tivoli Access Manager V5.1, SC32-1354
12.1.1 Tivoli Directory Server processes

This section documents how to start and stop the Tivoli Directory Server
processes.
Tivoli Directory Server executable (ibmslapd)

The Tivoli Directory Server executable ibmslapd can be started after you install
the server and configure the database using the methods documented in this
section.
Important: Do not forget Tivoli Directory Server depends on DB2. Ensure that
DB2 processes are running.
Start
Tivoli Directory Server can be started from either the Windows Services panel,
the command line, or the Tivoli Directory Server Web Administration Tool:
򐂰 To start the directory server from Windows services, select IBM Tivoli
Directory Server V5.2, right-click, and select Start.
򐂰 To start the directory sever from a command prompt, type in ibmslapd or use
the following command (requires the administration daemon ibmdiradm to be
running):
ibmdirctl [-h <hostname >][-D <adminDN >][-w <password >][-p <portnumber
>]start
Where the portnumber specifies the TCP port where the administration
daemon is listening (typically 3538). The above command can also be used to
stop, restart or view the status of the directory server.
򐂰 For information on starting ibmslapd from the Tivoli Directory Server Web
Administration Tool see 12.1.3, “Tivoli Directory Server - Web Administration
Tool” on page 507.
Stop
Tivoli Directory Server can be stopped from either the Windows Services panel,
the command line, or the Tivoli Directory Server Web Administration Tool:
򐂰 To stop the directory server from the Windows services panel, select IBM
Tivoli Directory Server V5.2, right-click, and select Stop.
򐂰 To stop the directory server from a command prompt use the following
command (requires the administration daemon ibmdiradm to be running):
>]stop
deamon is listening (typically 3538).
򐂰 For information on stopping ibmslapd from the Tivoli Directory Server Web
View status
Tivoli Directory Server’s status can be viewed from either the Windows Services
panel, the command line, or the Tivoli Directory Server Web Administration Tool:
򐂰 To view the status of the directory server from the Windows services panel,
select IBM Tivoli Directory Server V5.2 and view the status column.
򐂰 To view the status of the directory server from a command prompt use the
following command (requires the administration daemon ibmdiradm to be
running):
>]status
deamon is listening (typically 3538).
򐂰 For information on viewing the status of ibmslapd from the Web
Chapter 12. Manage a secure portal solution 505

Tivoli Directory Server administration daemon (ibmdiradm)
The directory administration daemon (ibmdiradm) allows for remote
management of the Tivoli Directory Server. It must be running on the machine
where Tivoli Directory Server is installed in order to accept requests to start,
stop, restart, and monitor the status of the Tivoli Directory Server. The directory
administration daemon by default listens on port 3538 for non-SSL connections
and port 3539 for SSL connections.
Start
The directory administration daemon can be started from either the Windows
services panel or the command line:
򐂰 To start the administration daemon from the Windows Services panel select
IBM Tivoli Directory Admin Daemon V5.2, right-click, and select Start.
򐂰 To start the admin daemon from the command prompt type in ibmdiradm.
Stop
The directory administration daemon can be stopped from either the Windows
services panel or the command line:
򐂰 To stop the admin daemon from the Windows Services panel select IBM
Tivoli Directory Admin Daemon V5.2, right-click, and select Stop.
򐂰 To stop the admin daemon from the command prompt type:
ibmdirictl -D <adminDN> -w <adminPW> admstop
12.1.2 Tivoli Directory Server - Configuration Tool (ldapxcfg)

The ldapxcfg GUI Configuration Tool and its command line equivalent ldapcfg
are used to configure the directory server. The tool is simple to use and has an
intuitive interface. The Configuration Tool can perform the following tasks:
򐂰 Define the administrator distinguished name and password.
򐂰 Configure, reconfigure, and unconfigure the database.
򐂰 Add and remove suffixes.
򐂰 Add and remove schema files.
򐂰 Import and export LDIF data.
򐂰 Enable and disable the changelog.
򐂰 Back up, restore, and optimize the database.
Accessing the Configuration Tool

The Configuration Tool can be accessed by typing ldapxcfg at a command
prompt or through the start menu by clicking Start → Programs → IBM Tivoli
Directory Server 5.2 → Directory Configuration.
Define the administrator distinguished name and password
Please refer to “Set the administrator DN and password” on page 195 for details
on how to perform this task.
Configure the database

Please refer to “Create and configure the directory database” on page 195 for
details on how to configure a database for the IBM Directory Server.
Add suffixes
Please refer to 7.3.1, “Create a suffix” on page 266 for detailed instructions for
this task.
Import LDIF data

Please refer to 7.3.3, “Import the LDIF file (wp-itso.ldif) to create users and
groups” on page 268, for details on how to execute this task and 12.1.8, “User
management” on page 513, for full details of how to manage users in the ITSO
Bank system.
12.1.3 Tivoli Directory Server - Web Administration Tool

The Tivoli Directory Server Web Administration Tool is a GUI that runs on an
application server such as WebSphere Application Server and is used to
administer the directory server remotely. The tool allows the administrator to
perform an extensive range of administration tasks on any Tivoli Directory Server
that has been added to the console. Administrative tasks include the following:
򐂰 Start, stop, restart and view the status of the directory server.
򐂰 Manage server connections and properties.
򐂰 Create administrative groups.
򐂰 Set server properties.
򐂰 Add, edit, delete and search directory entries.
For more detailed information refer to the Administration Guide, IBM Tivoli
Directory Server V5.2, SC32-1339, product guide.
Access the Web Administration Tool

To access the Tivoli Directory Server Web Administration Tool, do the following:
1. To start the Web Administration Tool you must first start the application server
on which it is installed. In our case this is the WebSphere Application Server
on the Policy Server node. To start the server enter the following in a
command window:
C:\ibm\WebSphere\appserver\bin\startServer.bat server1

2. You must also have the directory administration daemon running to be able to
start, stop, or restart a directory server remotely. See “Tivoli Directory Server
administration daemon (ibmdiradm)” on page 506 for how to start the
directory administration daemon.
3. To log on to the console, access the following address with a Web browser:
http://<policy_node>:9080/IDSWebApp/IDSjsp/Login.jsp
4. Select the console or the Tivoli Directory Server that you wish to log on to and
enter your login credentials (for example, cn=root and <password>).
Add a new server to the console

Please refer to “Define the directory server node to the Web Administration Tool”
on page 204 for detailed instructions on adding a new server to the console.
Change the administrator distinguished name and password

Please refer to “Define the directory server node to the Web Administration Tool”
on page 204 for detailed steps on changing the administrator’s distinguished
name and password.
Starting and stopping the server and checking server status

The Tivoli Directory Server can be started and stopped remotely using the Web
Administration Tool. The status of the server can also be easily viewed.
View the server status

To view the status of a directory server with the Web Administration Tool, do the
following:
1. Ensure that the administration daemon is running.
2. Log into the console.
3. View the icon in the upper left-hand corner of the server status area. This icon
will indicate whether the server is currently stopped, started, or in
configuration mode.
Start the server

To start the server if the status indicates it is not running, click Server
Administration in the Web Administration navigation area, click
Start/Stop/Restart Server in the expanded list, and click start.
Stop the server

To stop the server if the status indicates it is running, click Server
Administration in the Web Administration navigation area, click
Start/Stop/Restart Server in the expanded list, and click Stop.
Managing directory entries
This section details how to add and delete directory entries using the Web
Administration tool. We document the example of viewing, adding and deleting
user entries. It must be noted that this is not the most efficient method of adding
entries to the directory. Importing LDIF files is a more efficient process. For
details on how to import an LDIF file please see “Import LDIF data” on page 507.
Note: Adding a user entry in LDAP will not make that user a valid user of the
ITSO Bank secure system. For full details on user management please see
12.1.8, “User management” on page 513.
View entries
In the ITSO example the users and groups directory entries are not listed under
the Users and groups navigation section of the Web Administration Tool. This
would require additional configuration, including the creation of a realm and a
user template. Our users and groups are simply listed as directory entries under
the Directory management navigation section.
To view the list of ITSO Bank application users, do the following:

1. Expand the Directory management menu item in the navigation pane.
2. Click the Manage entries menu item.
3. Select the dc=itso,dc=ibm,dc=com entry and click Expand.
4. Select cn=users and click Expand.
5. At this point all the users are listed. To view the details of an individual user
click Edit attributes. Click Other attributes to see further attributes, or
Membership to see which groups that user belongs to.
Add entries
To add a user entry to the directory do the following:
Note: Adding a user to the directory will not give that user access to the ITSO
Bank application. For full details on user management please see 12.1.8,
“User management” on page 513.

2. Click the Add an entry menu item.
3. Select inetOrgPerson as the object class and click Next.
4. Click Next on the Auxiliary object classes page.

5. Complete the following fields:
– Relative DN: uid=<username>
– Parent DN: cn=users,dc=itso,dc=ibm,dc=com
– CN: <user’s common name>
– SN: <user’s surname>
6. Click other attributes and fill in the following fields:
– uid
– given name
– userpassword
7. Click Finish.
Delete entries
Note: To delete a user cleanly from the ITSO Bank secure system, the user
should be deleted from Tivoli Access Manager rather than from Tivoli
Directory Server. For full details please see 12.1.8, “User management” on
page 513.
To delete a user entry from the directory do the following:

2. Click the Manage entries menu item.
3. Select the dc=itso,dc=ibm,dc=com entry and click Expand.
4. Select cn=users and click Expand.
5. Select the user to delete and click Delete.
12.1.4 Tivoli Directory Server - Command line utilities

Tivoli Directory Server provides a number of command line utilities for both client
and server administration operations. Client tools include utilities like ldapsearch,
ldapadd, ldapdelete, and ldapchangepassword, and thus many of the tasks
performed with the Web Administration Tool can also be performed using the
command line utilities. These command line utilities are simpler and more
efficient to use than the GUI Web Administration Tool, and are therefore
recommended over the GUI. Server utilities include the bulkload utility, dbback
and dbrestore, ldaptrace and runstats.
These utilities can all be found in the <tam_home>/bin directory, and usage
details can be found by running <utilityname> -? at the command prompt or in
the Command line utilities chapter of the Administration Guide, IBM Tivoli
Directory Server V5.2, SC32-1339, product guide.
For a usage example of a client utility please see 7.5.1, “Apply Tivoli Access
Manager ACLs to new LDAP suffixes” on page 290. For a usage example of a
server utility see 12.4, “Back up and restore of key configuration files and
databases” on page 549.
12.1.5 Tivoli Access Manager - Servers

This section documents how to start, stop and view the status of the Tivoli
Access Manager servers. The servers should be stopped and started in the
correct order; that is, stop the servers in the following order:
1. Authorization Server (pdacld)
2. Proxy Server (pdmgrproxyd)
3. Policy Server (pdmgrd)
Start the servers in the following order:

1. Policy Server
2. Proxy server
3. Authorization Server
Note: The AutoStart Service automatically starts each of the Tivoli Access
Manager servers if the Startup configuration is set to automatic.
12.1.6 Tivoli Access Manager - pdadmin

The pdadmin tool is the command line utility used to perform administration tasks
for Tivoli Access Manager. It has the advantage over the Web Portal Manager
tool that commands can be used in scripts or batch files to automate processing
and files can be used to bulk-load data.
This section documents some key tasks that can be performed with pdadmin.
For full details of how to perform administration tasks with pdadmin please see
chapter one of Command Reference, IBM Tivoli Access Manager V5.1,
SC32-1354.
Access pdadmin
The pdadmin tool is installed as part of the Tivoli Access Manager runtime
package and can therefore be used on any machine with the runtime installed.
Simply type pdadmin -a sec_master -p <password> at a command prompt.
User tasks
This section details the Tivoli Access Manager user show commands that may
be helpful when troubleshooting your system.

For full details on how to manage users in the ITSO Bank system including the
pdadmin commands used to import users, delete users, activate user accounts,
list users and manage user passwords, please refer to 12.1.8, “User
management” on page 513.
View the details of a user

To view the details of a user, type the following command at a pdadmin prompt:
user show user_name
For example:
user show bsmith
Output is similar to the following:

Login ID:bsmith
LDAP DN:cn=bsmith,uid=bsmith,cn=users,dc=itso,dc=ibm,dc=com
LDAP CN:Belinda Smith
LDAP SN:Smith
Description:a test user
Is SecUser:yes
Is GSO user:yes
Account valid:yes
Password valid:yes
Show group membership

To show the list of groups to which a user belongs, enter the following command
at a pdadmin prompt:
user show-groups <user_name>
For example:
user show-groups bsmith
ACL Management
For details on ACL management using pdadmin see “Grant membership to a
role” on page 524 and “Revoke role membership” on page 528.
Policy Management
For details on policy management see “Password Management” on page 517.
Junction management
For details of how to create a WebSEAL junction using pdadmin see 7.5.3,
“Create a WebSEAL junction” on page 297.
Protected Object Policy (POP) management
For details on POP management using pdadmin see “Attach a POP to a
resource-role combination” on page 529.
12.1.7 Tivoli Access Manager - Web Portal Manager

Web Portal Manager is a GUI used to manage a subset of the Tivoli Access
Manager administration tasks including domains, users, groups, roles,
permissions, access control lists, protected object policies, authorization rules,
protected object spaces and protected objects. Web Portal Manager provides a
simple and intuitive interface for performing these tasks. For details on how to
perform individual tasks please refer to the Base Administration Guide, IBM
Tivoli Access Manager V5.1, SC32-1360.
Access the Web Portal Manager

To access the Web Portal Manager, do the following:
1. Prior to starting Web Portal Manager, ensure that the server1 application
server is started.
2. Enter the following URL in your Web browser:
https://<hostname>/pdadmin
Where hostname is the machine where the Web Portal Manager is installed
on a WebSphere application server. In our case this is the Policy Server
node.
3. Enter a Tivoli Access Manager administration user name and password (for
example, sec_master).
4. After the Tivoli Access Manager logo appears, select and perform tasks as
needed.
5. Click Sign Off on the bottom status bar to shut down Web Portal Manager.
12.1.8 User management

When we configured WebSphere Portal for authentication with Tivoli Access
Manager in 7.5, “Configure portal authentication with TAM using TAI” on
page 289, we imported the WebSphere Portal users and groups into the LDAP
directory and into Tivoli Access Manager. This import process resulted in those
users being updated with extra attributes that identified them as valid users in the
Tivoli Access Manager infrastructure.
As a result, to be a valid user in the ITSO Bank secure system, a user must have
both the specific attributes that identify them as an ITSO Bank application user
and those that identify them as a Tivoli Access Manager user. These attributes

are all stored in the user’s profile in the Tivoli Directory Server database. ITSO
Bank users cannot, therefore, be added or deleted using just one management
tool. This section describes the process for how to add and delete users in the
ITSO Bank system, and documents the facility available for users to change their
passwords.
Create users
This section documents the process for creating an ITSO Bank application user.
The process involves creating the user in the directory, followed by importing the
user into Tivoli Access Manager.
Users in the ITSO Bank application can be created in three ways:

1. Bulk user creation via an LDIF file imported to the directory with either the
Tivoli Directory Server Configuration Tool or the command line utility
bulkload. Users are then imported into Tivoli Access Manager using a
pdadmin command file.
2. Individual user creation using any combination of the following tools:
Create a user in LDAP using any one of these tools:
– LDIF files imported using Tivoli Directory Server Configuration Tool or
command line utility ldif2db
– Tivoli Directory Server Web Administration Tool
– ldapadd command line utility
Import the user into Tivoli Access Manager using either of the following tools:
– pdadmin
– Tivoli Access Manager Web Portal Manager
3. Creating and importing the user programmatically using APIs
The most efficient ways to create ITSO Bank users are the first and the third
methods. We will demonstrate the first method in this section as full details on
how to create a users programmatically are available in 9.3.2, “The portlet
application using Tivoli Access Manager” on page 423.
To create a user using the second method please refer to the following sections:
򐂰 “Create users in LDAP using LDIF files” on page 515
򐂰 “Managing directory entries” on page 509
򐂰 “Tivoli Directory Server - Command line utilities” on page 510
򐂰 “Tivoli Access Manager - pdadmin” on page 511
򐂰 “Tivoli Access Manager - Web Portal Manager” on page 513
򐂰 “Grant membership to a role” on page 524
For another example of user creation please see 10.2.5, “Create the groups and
users for the ITSO Bank application” on page 438.
Create users in LDAP using LDIF files

An LDIF file containing the details of the users to be added must first be created,
and then this file must be imported into LDAP.
To create an LDIF file to add a user or users to the LDAP directory create a text
file with the extension ldif (for example, user_add.ldif) with user data like that in
Example 12-1.
Example 12-1 user_add.ldif

Version: 1
#ITSO example: user_add.ldif
# Data for user: newuser1

dn: uid=newuser1,cn=users,dc=itso,dc=ibm,dc=com
objectclass=top
objectclass=person
objectclass=organizationalPerson
objectclass=inetOrgPerson
uid=newuser1
userpassword=passw0rd
sn=user1
cn=new user1
#Data for user: newuser2

dn: uid=newuser2,cn=users,dc=itso,dc=ibm,dc=com
objectclass=top
objectclass=person
uid=newuser2
userpassword=passw0rd
sn=user2
cn=new user2
Import the newly created LDIF file into LDAP using Tivoli Directory Server
Configuration Tool. For details on how to do this please see 7.3.3, “Import the
LDIF file (wp-itso.ldif) to create users and groups” on page 268.

Note: This LDIF import can also be performed using the Tivoli Directory
Server command line utility ldif2db or, if there are many users to be added,
the bulkload Tivoli Directory Server command line utility can be used for
greater efficiency. For details on Tivoli Directory Server command line utilities,
please see 12.1.4, “Tivoli Directory Server - Command line utilities” on
page 510.
Import users into Tivoli Access Manager

The newly created users must be imported into Tivoli Access Manager. To do
this first create a pdadmin command file, as in Example 12-2.
Example 12-2 import_users.pd

user import -gsouser newuser1 uid=newuser1,cn=users,dc=itso,dc=ibm,dc=com
user modify newuser1 account-valid yes
user modify newuser2 account-valid yes
These commands can also be run at a pdadmin command prompt instead of as a

command file. Simply open a pdamin command prompt (for details, see “Access
pdadmin” on page 511) and type individual commands.
Users can also be added to groups while being imported into Tivoli Access
Manager. To do this simply add the name of the group that you wish the user to
be a part of at the end of the user import command. For example, to import the
user newuser2 into a previously create group called testgroup2, type the
following at a pdadmin command prompt or insert into a pdadmin command file:

testgroup2
Note: The text has been wrapped in the example to fit on the page.
Verify users have been imported

To verify that these users have been created perform a user list pdadmin
command at a command prompt:
pdadmin -a sec_master -p <password> user list * 20
For another example of creating users using this method, please see the
following sections:
򐂰 7.3.2, “Create LDIF file containing users and groups” on page 267
򐂰 7.3.3, “Import the LDIF file (wp-itso.ldif) to create users and groups” on
page 268
򐂰 7.5.7, “Import WebSphere Portal users and groups into TAM” on page 303
Delete users
The method for deleting users from the ITSO Bank secure system is somewhat
simpler than that of creating a user. Users can be deleted from the system by
using either pdadmin or Web Portal Manager. The following command can be
used at a pdadmin command prompt to delete a user:
user delete [-registry] username
For example, to delete the user newuser1 from both Tivoli Access Manager and
the Tivoli Directory Server database enter the following command:
user delete -registry newuser1
However, if the ITSO Bank wished to keep all of the unused user account data in
the directory while ensuring these users would no longer be able to access the
system, the registry flag would not be used in the delete command.
Using the Tivoli Access Manager user delete command also ensures that any
resource credentials associated with the user are also removed.
Password Management
This section documents how to manage user passwords in the ITSO Bank
system. Specifically, it explains the following:
򐂰 How to set the user password policy
򐂰 The method for users to initiate a password change
򐂰 How to force users to change their password on first access to their account
򐂰 How to reset a user’s password.
These password management procedures are all Tivoli Access Manager based
because after a user is created in a secure portal system, their access details
must all be managed through Tivoli Access Manager in order to maintain the
integrity of the system security.
Set password policy

The user password and account, rules, and conditions are set using the policy
set command in pdadmin. Using this command you can:
򐂰 Set the account expiry date of a specific user.
򐂰 Disable the time-interval for a user’s account expiration.
򐂰 Set the maximum number of password failures allowed.
򐂰 Set the maximum password age allowed.

򐂰 Set the number of repeated characters allowed in a password.
򐂰 Set the minimum number of alphabetic characters.
򐂰 Set the minimum password length.
򐂰 Set the minimum number of non-alphabetic characters.
򐂰 Set whether spaces are allowed in passwords.
The default maximum password age is 91 days. To change this to 60 days, 12

hours and 30 minutes for all users enter the following command at a pdadmin
prompt:
policy set max-password-age 060-12:30:00
For details on how to use the policy command to execute the other password
policy changes listed above, please see chapter one of the Command
Reference, IBM Tivoli Access Manager V5.1, SC32-1354.
User-initiated password change

Users can initiate a password change at any time by accessing the Tivoli Access
Manager password change form pkmspasswd. This form can be accessed by a
user who is logged in to Tivoli Access Manager by requesting the following URL:
https://<webseal_host>/pkmspasswd
Note: For the ITSO example, we removed the “I forgot my password” link from
the WebSphere Portal interface since it used the portal’s native password
change facility. Furthermore, you would most likely want the link on the login
form for WebSEAL in an integrated environment.
The user will be presented with a password change form where she must enter
her old password followed by her new password twice for confirmation purposes.
A password change success or failure form will then be presented, depending on
the result, and the user will be required to use the new password on her next
login to the system. For details on how to customize this page please see
“Customize the WebSEAL HTML pages” on page 519.
Note: If basic authentication is being used as the authentication method, after

a password change the user is logged out of the current session. If the user
makes additional requests he is presented with a basic authentication prompt,
which her must complete with her new password before access can be
granted. This scenario is only for basic authentication.
Force password change on first access

A user can be forced to change his password on first access to his account by
modifying his account to show that his password is invalid. If the
invalid-password flag is set to yes, the user is unable to access the system until
he has changed his password. To make this change, type the following
command at a pdadmin command prompt or add it to the pdadmin command file
used when importing the users into Tivoli Access Manager.
user modify username password-valid no
Password reset
Tivoli Access Manager administrators can reset the password of a user using
either pdadmin or Web Portal Manager. The administrator does not need to know
the user’s old password. At a pdadmin command prompt (see “Access pdadmin”
on page 511) type the following command:
user modify <username to modify> password <new pasword>
For example:
user modify newuser1 password passw0rd2
For details of how to execute this command using Web Portal Manager see
Chapter 11, “User and group management,” of Base Administration Guide, IBM
Tivoli Access Manager V5.1, SC32-1360.
User self-management
We do not provide an example in the ITSO environment of user management of
account information such as phone number, address, etc., but it should be
pointed out that account management is possible in an environment where
WebSphere is configured for read-only access to the LDAP server. An additional
database called a lookaside database could be set up via WebSphere Member
Manager as a repository for editable profile information. The setup would require
ensuring that editable attributes were stored in the lookaside database instead of
LDAP.
Note: For further information on user repositories including lookaside

databases, please refer to the WebSphere Portal InfoCenter V5.0.2 at:
12.1.9 Customize the WebSEAL HTML pages

The Tivoli Access Manager account management HTML pages and error
message pages are all customizable. You can modify any of these pages to
contain messages, graphics specific to your organization, and to perform actions
specific to your site. This section documents where to find these pages and
macros that are available for use when customizing these pages.

Error pages
There are 29 existing default WebSEAL error message pages, which are
returned to the client when WebSEAL is unable to process a access request
from a browser. These error message pages explain why the request has failed.
These error message pages can all be customized, and further error message
pages can be created based on WebSEAL error message codes. For a full listing
of all the available error message pages and how to create additional pages
please see the WebSEAL server administration chapter in the WebSEAL
guide.
The location of the error pages is defined by an entry in the WebSEAL

configuration file. Under the acnt-mgt stanza search for the error-dir parameter.
The default value is <ws_home>/<WebSEAL_instance/lib/html/<lang-dir>, where

lang-dir is the language directory. Hence, the actual language used is based on
localization.
The default United States English directory is

<ws_home>/<WebSEAL_instance>/lib/errors/C, whereas the Japanese locale
files are located in <ws_home>/<WebSEAL_instance>/lib/errors/JP.
One of the default pages that users may come across is the 38cf0427.html page,
which documents the 403 Forbidden error. The default HTML page is shown in
Example 12-3.
Example 12-3 38cf0427.html


<html>
<head>
<meta http-equiv="Content-Type" content= "text/html; charset=UTF-8">

<title>Forbidden</title>
</head>
<body bgcolor="#FFFFFF">


<h1><font color="#FF0000">Forbidden</font></h1>
<p> The resource you have requested is secured
by Access Manager WebSEAL.
<BR><BR><BR>


<H4>Explanation</H4>
<P>There are two possible reasons why this message appeared:
<OL>
<LI>You are not logged in to this secure domain.
<LI>You are logged in to this secure domain, but do not have the correct
permissions to access the resource.
</OL>
<BR>


<H4>Solutions</H4>
<P><B>You have an account for this secure domain but need to log in:</B> You
must first access this resource via HTTPS (SSL) and login to the secure
domain. <A HREF="%HTTPS_BASE%%URL%">Re-access the page using HTTPS</A>.
<P><B>You do not have an account with this secure domain:</B> Please contact
your Account Administrator to obtain login and password information.
<P><B>You are logged in but still denied access to the page:</B> If you
continue to get this message, you probably do not have the correct
permissions to access the resource. Please contact your Security
Administrator for assistance.
<br>
<br>
<br>
<a href="%BACK_URL%">[%BACK_NAME% BUTTON]</a></p>
</body>
</html>
When modifying the default error message pages you must observe the following
guidelines:
򐂰 Do not modify the name of the file, as WebSEAL displays the error pages
based on the hexadecimal error number.

򐂰 Use correct HTML tagging.
򐂰 Use the supplied macros where appropriate (see “Macro support” on
page 524).
Account management pages

There are 31 customizable HTML account management pages, including pages
for help; login pages for forms, basic authentication, certificate, and token login;
password management pages; and many more. For a full listing of these pages
please refer to the WebSEAL server configuration chapter in the WebSEAL
guide.
The location of these pages is defined by an entry in the WebSEAL configuration

file. Under the acnt-mgt stanza search for the mgt-pages-root parameter. The
default value is <ws_home>/<WebSEAL_instance>lib/html/<lang-dir>, where
lang-dir is the language directory. Hence, the actual language used is based on
localization. The default United States English directory is
<ws_home>/<WebSEAL_instance>/lib/html/C, whereas the Japanese locale
files are located in <ws_home>/<WebSEAL_instance>/lib/html/JP.
One of the default pages that we have seen while configuring our ITSO system is
the forms-login page. The HTML for this default page can be seen in
Example 12-4.
Example 12-4 login.html

<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<TITLE>Access Manager for e-business Login</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<B>Access Manager for e-business Login</B>

<BR>
%ERROR%
<BR><BR>





<SCRIPT LANGUAGE=JavaScript>
var warningString = "<B>WARNING:</B> To maintain your login session, make sure
that your browser is configured to accept Cookies.";
document.cookie = 'acceptsCookies=yes';
if(document.cookie == ''){
document.write(warningString);
}
else{
document.cookie = 'acceptsCookies=yes; expires=Fri, 13-Apr-1970 00:00:00 GMT';
}
</SCRIPT>
<NOSCRIPT>
<B>WARNING:</B> To maintain your login session, make sure that<BR>
your browser is configured to accept Cookies.
</NOSCRIPT>

<BR>
<FORM METHOD=POST ACTION="/pkmslogin.form">
<FONT SIZE="+2">
<TABLE BORDER="0" WIDTH="400">
<TR>
<TD ALIGN="LEFT"><UL><LI>Username</LI></UL></TD>
<TD><INPUT NAME="username" SIZE="15"></TD>
</TR>
<TR>
<TD ALIGN="LEFT"><UL><LI>Password</LI></UL></TD>
<TD><INPUT TYPE="PASSWORD" NAME="password" SIZE="15"></TD>
</TR>
</TABLE>
</FONT>
<INPUT TYPE="HIDDEN" NAME="login-form-type" VALUE="pwd"></TD>

<BR><INPUT TYPE="SUBMIT" VALUE="Login">
</FORM>
</BODY>
</HTML>
Macro support
When modifying the default error message pages and the default account
management pages, a large number of macros are available for use. When
placed in the default HTML files, these macro strings will be substituted with the
appropriate information if relevant to that page and if macro support is enabled in
the WebSEAL configuration file. By default, macro support is enabled. To disable
support set the utf8-template-macros-enabled property to no in the content
stanza of the WebSEAL configuration file. Macros available include those to
display the authentication level, the back-url, error messages, protocol and
username. For a full listing of the macros available and their descriptions please
see the WebSEAL server configuration chapter in the WebSEAL Administration
12.1.10 Externalized role management

When the ITSO Bank application resources were externalized in 10.3.9,
“Externalize the ITSO Bank resources” on page 467, every resource and role
combination externalized from WebSphere Portal resulted in the creation of an
object and an attached ACL in Tivoli Access Manager. The group and user
entries in each ACL determined which users and groups had membership in
those roles for the associated WebSphere Portal resource. In order to manage
which users have access to which roles for the WebSphere Portal resources in
the ITSO Bank application, we therefore have to manage the objects and ACLs
in Tivoli Access Manager.
This section documents how to manage membership of the roles of the

resources in the ITSO Bank application after they have been externalized from
WebSphere Portal. Specifically, it documents the process for adding
membership to a role of a WebSphere Portal resource in Tivoli Access Manager,
revoking access when it is no longer needed, and attaching a protected object
policy (POP) to a resource-role combination.
Grant membership to a role

This section outlines how to grant membership to a role for a WebSphere Portal
resource in the ITSO Bank system after the resource has been externalized. The
procedure for defining role membership before the resource is externalized is
demonstrated in 10.3.9, “Externalize the ITSO Bank resources” on page 467,
when we externalized the resources of the ITSO example. The basic procedure
is outlined and an example is given.
The basic procedure for granting membership to a role of a resource is as

follows:
1. Locate the Tivoli Access Manager object that represents the resource-role
combination.
2. Find the ACL that is attached to the object.
3. View the ACL user and group entries.
4. Modify the ACL to add the user or group for which access is to be granted.
5. Test the application to demonstrate that user or group has membership of
that role for that resource.
We will use the example of granting the ITSOCustomer group membership to the
User role of the ITSO Transaction History portlet. Please note that this access is
not part of the business requirements of the ITSO Bank, nor is it a portlet that
would be appropriate for the customers to have access. It just serves as an
example that you can use to apply to any situation where you might need to grant
membership to a role after the role is externalized. We followed the above
process and executed the following commands to do so:
1. To locate the Tivoli Access Manager object that represents the combination
of the ITSO Transaction History resource and the User role, we executed the
following command at a pdadmin prompt (see “Access pdadmin” on
page 511):
object list /WPSv5
This command returned the following list of Tivoli Access Manager objects
representing all the resource-role combinations from the ITSO example (see
Figure 12-1).

Figure 12-1 pdadmin object list command
You will notice that the names of these objects follow a common pattern,
namely, WPSv5_<resource type>_<resource name>_<alphanumeric
code>@<role>. From this pattern we can determine that the object that best
matches the ITSO Transaction History resource and User role combination is:
/WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User
This object, however, is an intermediate object, that is, it is not the lowest,
cell-level object of this branch of the cell tree object structure. To find the
lowest level we executed the following commands, using the output of the
previous command as input to the next command. (This is the equivalent of
expanding a non-leaf object using the Web Portal Administration tool.)
– object list “/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User”
Command output:
/WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User/WPS
History_3_0_CK@User/WPS”
Command output:
/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS/WebSphere_Portal
History_3_0_CK@User/WPS/WebSphere_Portal”
Command output:
“/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS/WebSphere_Portal/cell”
This command did not produce any output, signifying that it is a lowest
level object.
2. To find the ACL that is attached to that object we executed the following
pdadmin command:
object show “/WPSv5/PORTLET_DEFINITION_ITSO Transaction
This command produced the following output:
Description: WP role: PORTLET_DEFINITION/ITSO Transaction
History/3_0_CK@User
Type: 0 (Unknown)
Is Policy Attachable: Yes
Attached ACL:
WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
Attached POP:
Attached AuthzRule:
Effective ACL:
Effective POP:
Effective AuthzRule:
We can see from this output that the associated ACL is:
3. To view the current ACL users and groups entries we executed the following
pdadmin command:
acl show WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
The output of this command was as follows:
ACL Name: WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
Description: ACL for WP rolePORTLET_DEFINITION/ITSO Transaction
History/3_0_CK@User

Entries:
User sec_master TcmdbsvaBRl
Group ITSOManagers [WPS]m
This shows that we have granted the ITSOManager group modify
permissions on the object, or in WebSphere Portal terms, membership to the
User role for that resource.
4. To grant the ITSOCustomers group membership to the User role of this
resource we must modify the ACL to include access for that group. To do this
we executed the following command:
acl modify WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
set group ITSOCustomers [WPS]m
5. To test of the role membership was added to the group ITSOCustomers, we
executed the following steps:
a. We created a valid testuser called testuser.
For details on how to create a user in the ITSO Bank application please
refer to “User management” on page 513.
b. We added the testuser to the ITSOCustomers group:
group modify ITSOCustomers add testuser
c. We logged into the Portal as the testuser.
d. We created a new page called History:
i. Click New page in the upper right-hand corner.
ii. Enter the title and click OK.
iii. Click OK to confirm that the new page has been created.
e. We edited that page to add the Transaction History Portlet.
i. Click Add portlets in the edit layout for the new page.
ii. Search for a title containing ITSO.
iii. Select the ITSO Transaction History portlet and click OK.
iv. Click Done.
6. This has proved that the ITSOCustomer group now has the User role for the
ITSO Transaction History portlet. To clean up the system we deleted the test
user with the following pdadmin command:
user delete -registry testuser
Revoke role membership

We have now seen how to grant users membership to a role for a WebSphere
Portal resource, but what happens when this access is no longer needed? This
section outlines the steps to revoke membership of a user group from a role of a
WebSphere Portal resource for the secure portal solution. We investigate the
situation where the User role is no longer needed by the ITSOCustomer group
for the ITSO Transaction History portlet.
The basic procedure for removing access from a role of a resource is as follows:
1. Locate the Tivoli Access Manager object that represents the resource-role
combination.
2. Find the ACL that is attached to the object.
3. View the ACL user and group entries.
4. Modify the ACL to remove the user or group for which access is to be
revoked.
5. Test the application to demonstrate that user or group no longer has
membership of that role for that resource.
To remove all access to the Privileged User role of the Account Balance Admin
page we followed the above process and executed the following commands to
do so:
1. To locate the Tivoli Access Manager object that represents the combination
of the Account Balance Admin resource and the Privileged User role, we
executed the commands in step one of “Grant membership to a role” on
page 524 for procedure.
2. To find the ACL that is attached to the object, we executed the commands in
step two of “Grant membership to a role” on page 524.
3. To view the ACL users and groups entries we executed the commands in
step three of “Grant membership to a role” on page 524. This confirmed that
we have granted the ITSOCustomer group membership to the User role for
the this resource.
4. To revoke the role membership we modified the ACL and removed the
ITSOCustomer group. To do this we executed the following command:
acl modify WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
remove group ITSOCustomers
5. To test that role membership had been revoked, we tried to execute the
commands listed in step five of “Grant membership to a role” on page 524.
We found that the user did not have the option of adding the ITSO Transaction
History portlet to her new page, thus proving membership had been revoked.
Attach a POP to a resource-role combination

In the ITSO Bank example we did not implement any protected object policies
(POPs). POPs are another security policy management tool that allow the
administrator to place conditions additional to ACLs on the requests. While ACLs

provide information on whether a user or group should be allowed to perform
some operation on an object, a POP provides further information about the
requested object that applies to all users and groups.
A POP might, for example, define what time of day the resource is allowed to be
accessed or which IP address endpoints are allowed to access the object. POPs
also allow for more complex authentication procedures to be implemented on
specific objects, for example, step-up authentication where a user may be forced
to authenticate again to step up to a higher level of authentication before being
allowed access to a specific object. This section shows how to create and attach
a basic POP to a WebSphere Portal resource in the ITSO system.
We will use the example where the User role to the Modify User portlet should
only be allowed between the hours of 9:00 p.m. and 5:00 p.m. only on weekdays.
To enforce this access we must create a time of day POP and attach it to the
object in Tivoli Access Manager that represents the User role of the ITSO Modify
User resource. To do this we did the following:
1. Created a POP using the pdadmin command:
pop create tod_0900-1700_weekdays
2. Modified the POP to only allow access between the specified times on the
specified days:
pop modify tod_0900-01700_weekdays set tod-access weekday:0900-1700:local
3. Located the object to which we were to attach the POP (see step one of
“Grant membership to a role” on page 524 for full details). From this we
determined that the object we want to restrict access to is:
/WPSv5/PORTLET_DEFINITION_ITSO Modify
User_3_0_CH@User/WPS/WebSphere_Portal/cell
4. Attached the POP to the object:
pop attach “/WPSv5/PORTLET_DEFINITION_ITSO
ModifyUser_3_0_CH@User/WPS/WebSphere_Portal/cell” tod_0900-1700_weekdays
5. To test the scenario we did the following:
a. Created a valid testuser called testuser. For details on how to create a
user in the ITSO Bank application please refer to 12.1.8, “User
management” on page 513.
b. Added the testuser to the ITSOManagers group:
group modify ITSOManagers add testuser
c. Logged into the Portal as the testuser outside the hours of 9 a.m.–5 p.m.
weekdays.
d. Navigated to the Modify User page and found that the ITSO Modify User
portlet was not displayed.
e. Logged into the Portal as the testuser during the hours of 9 a.m.–5 p.m.
weekdays.
f. Navigated to the Modify User page and found that the ITSO Modify User
portlet was displayed and available for use.
This demonstrated that the access to the resource was limited by the
conditions we set in the POP. To clean up the environment we deleted the
testuser using the following command:
user delete -registry testuser
12.1.11 Favicon configuration

Favicons can cause some Web browsers to produce unexpected results when
used with the default WebSEAL configuration. If you wish to include a Favicon in
your application there are two steps that you must perform in order to prevent
this behavior. These steps are as follows:
1. Place the favicon in the document root of the WebSEAL junction.
2. Create an ACL to allow unauthenticated access to this object. For instructions
refer to 7.8.2, “Configure WebSEAL to handle favicon.ico” on page 359.
These two steps will allow unauthenticated access to the Favicon, and thus
prevent the browser from receiving a forbidden message and producing
unexpected results when trying to access the icon.
12.2 WebSphere administration tools and common

tasks
This section outlines how to launch the administrative tools for the WebSphere
Application Server and WebSphere Portal. In addition, we describe how to
perform common administrative tasks in an environment such as the ITSO
working example secure portal solution. We are not attempting to provide a
comprehensive list of functionality for each tool, since this is addressed in
various other publications, including redbooks. We will use the secure options
(SSL, name and password authentication, etc.) with the administrative tools
where appropriate.
12.2.1 WebSphere Application Server - Administrative console

The WebSphere Administrative Console is a graphical Web-based tool that
allows you to manage an entire WebSphere cell.

Accessing the administrative console
To access the console, do the following:
1. Ensure that the application server (for example, server1) is started. See
“Checking the status of an application server” on page 534 for details.
2. Enter the following URL:
https://<was_host>:9043/admin
This URL should take you to the login page for the WebSphere Application
Server Administrative Console.
3. Enter your login credentials for your WebSphere Application Server admin ID
and click OK.
You are now in the administrative console and can manage your application
servers.
Note: For detailed information regarding the WebSphere administrative

console, please refer to Chapter 8, “WebSphere administration basics,” in the
IBM WebSphere Application Server V5.1 System Management and
Configuration WebSphere Handbook Series, SG24-6195-01.
12.2.2 WebSphere Application Server - Scripting program

The WebSphere administrative scripting program (wsadmin) is a non-graphical
command environment that allows you to manage and configure WebSphere
Application Server by using the JACL scripting language.
Launching the scripting process

To start an interactive wsadmin environment, do the following:
1. Open a command prompt and change to <was_home>\bin.
2. Enter the command:
wsadmin.bat -user <username> -password <password>
You should see something similar to:
WASX7209I: Connected to process “server1” on node wpwin1 using SOAP
connector; the type of process is UnManagedProcess
WASX029I: For help, enter: “$Help help”
wasadmin>
From this prompt, you can enter any JACL command.
Explanation of command-line syntax:
– <username> is the username for authentication when WebSphere security
is enabled (for example, wpsbind).
– <password> is the username for authentication when WebSphere security
is enabled.
3. To leave the interactive session, type quit or exit.
Note: Script and property files can also be used with wsadmin. For detailed
information regarding the WebSphere administrative scripting program,
please refer to the following resources:
򐂰 Chapter 16, “Command-line administration and scripting,” in IBM
WebSphere Application Server V5.1 System Management and
Configuration WebSphere Handbook Series, SG24-6195-01
򐂰 Appendix D, “Using wsadmin scripting for security configuration,” in IBM
WebSphere V5.0 Security WebSphere Handbook Series, SG24-6573-00
12.2.3 WebSphere Application Server - Command-line tools

Command-line tools allow you to stop, start, and monitor WebSphere server
processes. However, the tools can only be used for local servers. For remote
servers, use wsadmin or the administrative console.
Starting and stopping the application server

To start an application server, do the following:
2. Enter one of the following commands:
– To start the server, enter:
startServer.bat <server>
– To stop the server, enter:
stopServer.bat <server> -user <username> -password <password>
• <server> is the application server name (for example, server1 and
WebSphere_Portal).
• <username> is the username for authentication when WebSphere
security is enabled (for example, wpsbind).
• <password> is the username for authentication when WebSphere
security is enabled.

Note: When global security is enabled in WebSphere Application Server, it
is important to verify that the LDAP server is running prior to
starting/stopping the application server.
It is possible to start/stop the application servers via the Windows Start

menu:
򐂰 Start → Programs → IBM WebSphere → Application Server v5.0
→ Stop/Start the Server
򐂰 Start → Programs → IBM WebSphere → Portal Server v5.0 →
Stop/Start the Server
You may be prompted for your admin username and password when using
these shortcuts if you have security enabled.
Checking the status of an application server

To obtain the status of one or all of the application servers configured on a node,
do the following:
serverStatus.bat <server>|-all -user <username> -password <password>
– <server> is the application server name (for example, server1 and
WebSphere_Portal). You can choose a single server or use the -all option
to return the status of all application servers on the node.
is enabled.
Note: For detailed information regarding the WebSphere application server

command line tools including optional command line parameters, please refer
to Appendix A, “Command-line tools,” in IBM WebSphere Application Server
V5.1 System Management and Configuration WebSphere Handbook Series,
SG24-6195-01.
Further information on WebSphere Application Server administration can be

found in the WebSphere Application Server V5 InfoCenter at:
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp
12.2.4 WebSphere Portal - Web administration
The Web administration interface for WebSphere Portal is the primary tool for
managing WebSphere Portal. It is the gateway to the administration portlets that
allow you perform tasks such as installing portlet applications, configuring Portal
settings, and managing access control for resources.
Accessing the administration interface

To access the WebSphere Portal Web administration interface, do the following:
1. Ensure that the WebSphere_Portal application server is started. See
“Checking the status of an application server” on page 534 for details.
https://<webseal_host>/portal/wps/myportal
This URL should prompt you with the login page for WebSEAL assuming you
have configured WebSphere Portal in a secure portal runtime with Tivoli
Access Manager and WebSEAL.
3. Enter your login credentials for your WebSphere Portal admin ID and click
Login. You should be redirected to WebSphere Portal.
4. Click the Administration link in the top right corner of the page.
Note: If you log in with a user ID that does not have administrative rights,
the Administration link will not be present.
You are now on the Administration page. On the left side of the page, you will
see the five different links (clicking each link will present nested links):
򐂰 Portal User Interface: Manage page hierarchy and look and feel of portal.
򐂰 Portlets: Install and configure portlet applications (and individual portlets).
򐂰 Access: Work with resource permissions and view users and groups.
򐂰 Portal Settings: Manage overall portal settings.
򐂰 Portal Analysis: Gather statistics and tracing on the portal.
Note: For detailed information on WebSphere Portal administration, please

refer to the following resources:
򐂰 Chapter 10, “WebSphere Portal Administration,” in the IBM WebSphere
Portal for Multiplatforms V5 Handbook, SG24-6098, redbook
򐂰 WebSphere Portal InfoCenter V5.0.2 at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wps/admwpadm.h
tml

Managing the Credential Vault
For a description of the credential vault and its organization, please refer to
“WebSphere Portal Credential Vault” on page 44.
Accessing the credential vault

To access the credential vault, do the following:
https://<webseal_host>/portal/wps/myportal
2. Enter your login credentials for your WebSphere Portal admin ID and click
Login.
3. Click the Administration link in the top right corner of the page.
4. Click Access → Credential Vault.
You can now manage your vault segments and slots from the current location.
Creation of vault segment and segment slot

For the ITSO example, we provide a procedure for creating a vault slot and
segment that results in a new GSO resource in the Tivoli Access Manager GSO
lockbox. For further details on this procedure, please refer to “Create a
Credential Vault segment and slot” on page 350.
Note: Further details on the Credential Vault and how it can be used can be
found in the following resources:
򐂰 WebSphere Portal V5.0.2 InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wpf/sec_vault.
html
򐂰 A Secure Portal Extended With Single Sign-On, REDP3743, redpaper
Externalizing resources for authorization

WebSphere Portal provides two options for managing access control to portal
resources. The first option involves externalizing resources to an external
security manager such as Tivoli Access Manager. We have provided an example
of the procedure to externalize a resource to Tivoli Access Manager in our ITSO
example configuration. Please refer to 7.6.5, “Example for externalizing a
resource” on page 337.
The decision to externalize a resource depends upon the security needs of the
resource itself, as well as the overall environment of an organization. Security
administrators may have certain portlets/pages that contain sensitive data and
are considered part of the organization’s enterprise security domain.
Furthermore, an organization can have other enterprise security resources
outside of WebSphere Portal, and may wish to administer them from a central
location.
Internalizing resources for authorization

The second option for managing resources in WebSphere Portal is
internalization. By default, all WebSphere Portal resources are internalized.
Therefore, the only time you would need to actively internalize a resource would
be if you had externalized it previously to an external security manager, such as
Tivoli Access Manager.
The common scenario in a secure enterprise environment is to have a mixture of

internalized and externalized resources. Some pages/portlets do not fall under
the realm of enterprise security and can therefore be managed by WebSphere
Portal’s native access control. Authorization data for an internalized resource
would be stored in the portal database and managed via administration portlets.
We will now provide an example of how to internalize a portal resource that is

currently managed by Tivoli Access Manager. For our example, let us use the
YourCo Financial page that we externalized in 7.6.5, “Example for externalizing a
resource” on page 337.
Internalize the resource

As an example, we will demonstrate how to internalize the YourCo Financial
page, as follows:
URL:
4. Click Pages under the Resource Type column.
5. Click Content Root in the Page Title column.
6. Click My Portal.
The externalized resource should appear similar to the YourCoFinancial page
in Figure 12-2.

Figure 12-2 Example of externalized resource
7. Click the left-facing arrow in the Externalize/Internalize column for your

resource (for example, YourCo Financial).
8. You will be prompted, Are you sure you want to place this resource
under Portal Access Control? Click OK for the process to begin.
9. You should now see a message at the top of the page stating that the
resource is now under Portal Access Control. Click Done.
Verify the resource in WebSphere Portal and Tivoli Access Manager

To verify the resource in WebSphere Portal and Tivoli Access Manager, do the
following:
1. Verify that the resource is now internalized in WebSphere Portal by
navigating back to the page.
a. Access the Resource Permission portlet by clicking Administration →
b. Click Pages under the Resource Type column.
c. Click Content Root in the Page Title column.
d. Click My Portal.
The internalized resource (for example, YourCo Financial page) should
now have a right-facing arrow in the Externalize/Internalize column.
e. Click Log out.
2. Verify that the TAM objects for the resource have been deleted from the TAM
objectspace:
a. Ensure that the server1 application server is started on the Policy Server
node.
b. Start the Web Portal Manager by entering the following URL in a Web
browser:
http://<tam_host>/pdadmin
c. Log on as user ID sec_master (since we only have one domain, it is not
necessary to enter the Default domain).
d. To verify the objects where created in the Tivoli Access Manager object
space, do the following:
i. Select Object Space → Browse Object Space.
ii. When the Browse Object Space page appears, expand the / (root) →
WPSv5 by clicking the + symbol, as seen in Figure 12-3 on page 539.
Figure 12-3 Contents of /WPSv5 object space in Tivoli Access Manager
You should now see that the TAM objects for the resource (for
example, the YourCo pages) no longer exist in the object space.
iii. Click Sign Off in the bottom right corner of the page.
Administering authorization for an internalized resource

Portal Access Control (PAC) is the built-in access control for WebSphere Portal.
PAC defines the operations that a user is allowed to execute within the portal
object space. WebSphere Portal uses the role concept, which defines a role as a

container of permissions. Therefore, assigning a role to a user effectively grants
them all of the permissions contained in the role. Roles are denoted as
RoleType@Resource. WebSphere Portal contains seven role types, as defined
in Table 12-1.
Table 12-1 Seven role types within WebSphere Portal

Role type Description
User Allows viewing of portal content (for example, viewing a

specific page).
Privileged User Allows viewing portal content, personalizing portlets and

pages, and creating new private pages.
Editor Allows creating new shared resources and configuring

existing resources that are used by multiple users.
Manager Allows creating new shared resources as well as configuring

and deleting existing resources that are used by multiple
users.
Delegator Allows assigning specific users or user groups to those roles

that the delegator holds himself.
Security Administrator Allows creating and deleting role assignments for roles tied
to specific resources.
Administrator Allows for unrestricted access to resources. This includes

creation, configuration, and deletion of shared resources. In
addition, it allows deciding who will have access to the
resources by creating/deleting corresponding role
assignments.
Access control for internalized resources can be administered in three ways in

WebSphere Portal:
򐂰 Resource Permissions: Administration portlet that allows a centralized view of
the resources
򐂰 User and Groups: Administration portlet that provides a view of the access
control configuration from a user/group perspective
򐂰 XMLAccess: Portal scripting interface that supports the complete set of
access control configuration facilities
We now provide an example of how to administer an internalized resource with

the Resource Permissions portlet.
Assign roles to test user for managing a portlet application
To experience Portal Access Control at work, you can do the following
procedure. The following steps assume that you have a test user created in your
LDAP directory (for example, we created authtestuser) and the Reminder portlet
is installed on the WebSphere Portal server. Our goal will be to allow a test user
to manage a portlet application (Reminder) with the Manage Applications portlet.
In order to reach this goal, we will need to assign the following roles to our test
user via the Resource Permissions portlet:
򐂰 User@Reminder Web module: Permits test user to see the information that is
contained in a the Web module and to use the Manage Applications portlet to
navigate to the portlet applications that are contained in this Web module
򐂰 Manager@Reminder portlet application: Permits test user to manage the
portlet application
򐂰 User@Manage Portlet Applications portlet
򐂰 User@Manage Applications page
Note: Rather than explicitly assigning the user to the role for each
resource, you could simply add the user to a group that already has the
needed role(s) via LDAP. However, for our example, we will show the
explicit assignments of roles in order to display the process of using the
Resource Permissions portlet to assign access.
1. Assign the User role to the Reminder Web module:

a. Start the WebSphere Portal Administration Console by entering the
following URL:
b. Log on as the wpsadmin user.
c. Access the Resource Permissions portlet by clicking Administration →
d. Click Web Modules.
e. Enter reminder in the Search for text field and click Search.
f. You should see the Web module reminder.war. Click the key icon next to
the Web module to assign access.
g. Click the pencil icon for the User role located on the right side of the page.
h. Click Add.
i. Select the following values and click Search:
• Search for Users or User Groups: Users
• Search on: uid

• Search for: <username> (for example, authtestuser)
j. Check the Select box for the test user and click OK.
k. Click Done → OK → Done to get back to the Resource Types page.
2. Assign the Manager role to the Reminder portlet application:
a. Click Portlet Applications.
b. Enter reminder in the Search for text field and click Search.
c. You should see the portlet application ReminderPortlet. Click the key icon
next to the portlet application to assign access.
d. Click the pencil icon for the Manager role located on the right side of the
page.
e. Click Add.
f. Select the following values and click Search:
• Search on: uid
g. Check the Select box for the test user and click OK.
h. Click Done → OK → Done to get back to the Resource Types page.
3. Assign the User role to the Manage Portlet Applications portlet:
a. Click Portlets.
b. Enter Manage Portlet Applications in the Search for text field and click
Search.
c. You should see the portlet Manage Portlet Applications. Click the key
icon next to the portlet to assign access.
d. Click the pencil icon for the User role located on the right side of the page.
e. Click Add.
• Search on: uid
h. Click Done → OK →Done to get back to the Resource Types page.
4. Assign the User role to the Manage Applications page:
a. Click Pages.
b. Enter Manage Applications in the Search for text field and click Search.
c. You should see the Manage Applications page. Click the key icon next to
the page to assign access.
d. Click the pencil icon for the Manager role located on the right side of the
page.
e. Click Add.
• Search on: uid
h. Click Done → OK → Done to get back to the Resource Types page.
i. Click Log out.
5. Verify that the test user can access the portlet application:
a. Access WebSphere Portal by entering the following URL:
b. Log on as the test user (for example, authtestuser).
c. Click the Administration link in the top right corner of the page
Note: By giving the test user the role User@Manage Applications page,
he is actually able to see the Administration link when he logs in.
However, he will not have access to the other administration portlets
unless he is assigned access to each portlet.
d. You should now see the Manage Portlet Applications portlets displayed on
the Manage Applications page. Click the Reminder Portlet portlet
application. You should see a page similar to Figure 12-4.

Figure 12-4 Example of Manage Applications page as seen by test user
From this interface, your test user can now manage the Reminder portlet
application.
Note: For an example of how we modified permissions for an internalized

resources in the ITSO example, please refer to 10.3.7, “Modify resource
permissions” on page 459. In the ITSO example, we show an example of
both page and portlet permissions modification.
For further information on access control in WebSphere Portal, please

refer to the WebSphere Portal InfoCenter V5.0.2 at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wps/admsecu
r.html
12.2.5 WebSphere Portal - XMLAccess

XMLAccess is a small command-line client that connects to the portal server via
an HTTP connection. Therefore, it allows an administrator to connect to the
WebSphere Portal server remotely.
XMLAccess can be used for the following purposes:
򐂰 Export an entire portal configuration or parts of the configuration to an xml file.
You can then import this file into another portal in order to recreate the
desired configuration.
򐂰 Install additional resources to the current portal.
򐂰 Perform common administrative tasks in a scripted manner.
Note: XMLAccess should not be used for backing up and restoring

production systems since XMLAccess is not designed to deal efficiently
with large volumes of data.
Also, it should be pointed out that a complete backup of the portal

configuration is not enough to recreate the portal on another machine. You
must also copy the WAR files for the portlets, and perhaps additional
resources such as themes that are not included as part of the standard
portal installation.
Using XMLAccess in a secure environment

XMLAccess does not currently support an HTTPS connection. Therefore, an
administrator must choose one of the following options to secure communication
with XMLAccess:
򐂰 Run XMLAccess from a secure location within your firewall where you can be
certain the transaction cannot be compromised. If port 80 cannot be enabled,
then port 9081 is another option (http transport for the application server).
򐂰 Set up an SSH connection to create an encrypted network tunnel for use with
XMLAccess.
In order to use the XMLAccess configuration interface, you must have the
manager role on the virtual resource XMLACCESS, as well as the administrator
role on the virtual resource PORTAL.
Running the XMLAccess client

The XMLAccess client can be run from any directory on local or remote
machines that meets the following requirements:
򐂰 Java runtime is installed.
򐂰 XMLAccess.bat and tools.jar reside in the working directory.
Note: You may have to adapt the PATH settings in the .bat file to point to
your Java runtime. The XMLAccess.bat and tools.jar are initially placed in
the <wp_home\bin directory during the WebSphere Portal installation.

To run XMLAccess, do the following:
1. Ensure the WebSphere_Portal application server is running.
2. Open a command prompt and change to the directory containing
XMLAccess.bat.
3. Run the following command
xmlaccess -in <xml_file> -user <username>-pwd <password> -url
<portal_config_url> -out <result_xml_file>
– <xml_file>: The name of the input file containing the XML request
(configuration export or update) that should be processed.
– <username>: The short username describing the authority under which
the request should be processed. Full distinguished names (DN) are not
supported.
– <password>: Password for user.
– <portal_config_url>: The URL to access the portal configuration servlet
(for example, http://wpwin1.itso.ral.ibm.com/wps/config).
– <result_xml_file>: The name of the output file containing the resulting
XML.
Note: The <xml_file> must be created and reside in the working directory
(or you can specify a path to the file in your command line) prior to running
XMLAccess.
Exporting the WebSphere Portal configuration

We will provide the standard example of exporting the entire WebSphere Portal
configuration (excluding users). To export the configuration do the following:
1. Copy the xmlaccess.bat and tools.jar (located in <wp_home>/bin) to a secure
workstation in your environment.
2. Edit the xmlaccess.bat to reflect the correct path for the java environment on
your workstation.
3. Create your input file. For example, we did the following:
a. Create a new file (with a text editor) called export.xml in the directory that
contains xmlaccess.bat on your workstation.
b. Populate export.xml with the xml shown in Example 12-5.
Example 12-5 Contents of sample export.xml

<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
type="export"
export-users="false">

<portal action="export"/>
</request>
4. Open a command prompt and change to the directory on your workstation

that contains xmlaccess.bat
5. Run the following command:
xmlaccess.bat -in export.xml -user wpsadmin -pwd <password> -url
http://<wp_hostname>/wps/config -out export_result.xml
The command should export your portal configuration to the export_result.xml
file. If you open the xml file, you should see the following at the end of the file:
<status element="all" result="ok"/>
Note: For detailed information on using XMLAccess including example

XML files, please refer to the WebSphere Portal V5.0.2 InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wps/admxmla
i.html
12.2.6 Externalize virtual resources

If you go to the Resource Permissions portlet and select the resource type
Portlets, a list of all the deployed portlets will appear; you can then externalize
each portlet individually. However, this can become cumbersome. If later on you
deploy a new portlet, you will have to manually externalize it. There is a much
simpler way of doing this, and that is to use the Virtual Resource resource type
under Resource Types. If you externalize the virtual resource Portlet Applications
(which is the parent resource for all portlets and portlet applications), all the
portlets will also be externalized. Each new portlet or portlet application added
thereafter will be automatically externalized.
For details on how to externalize a virtual resource, refer to the WebSphere

Portal InfoCenter at:

12.3 Start and stop servers for ITSO example nodes
This section documents the procedures for starting up and shutting down the
ITSO Bank secure system. When a secure system is deployed it is important to
start up and shut down the components in the correct order to ensure the
security of the system. Also, when global security is enabled in WebSphere
Application Server, it is important to verify that the LDAP server is running prior to
starting the application server. In the ITSO system, we would start the servers in
this order:
1. Policy Server node:
– DB2 (Windows services)
– IBM Tivoli Directory Admin Daemon V5.2 (Windows service)
– IBM Tivoli Directory Server V5.2 (Windows service)
– Access Manager Auto-Start Service (Windows service)
• Access Manager Policy Server (Windows services)
• Access Manager Authorization Server (Windows service)
2. Portal Server node
– IBM HTTP Server (Windows services)
– Applications servers:
• WebSphere_Portal
• server1 (optional for administration purposes)
3) Reverse Proxy node

This node could be started either second or third.
– Access Manager Auto-Start Service (Windows service)
• Access Manager WebSEAL-default (Windows services)
Note: For details on how to start up and shut down the application servers
please refer to “Starting and stopping the application server” on page 533.
When shutting down the system, the following order should be followed:
1. Reverse Proxy node
This node could be stopped either first or second.
– Tivoli Access Manager Proxy Server (Windows services)
2. Portal Server node
– Applications servers (server1 and/or WebSphere_Portal)
– IBM HTTP Server (Windows services)
3. Policy Server node
– Tivoli Access Manager Authorization Server (Windows services)
– Tivoli Access Manager Policy (Windows services)
– IBM Directory Server and admin daemon (Windows services)
12.4 Back up and restore of key configuration files and

databases
This section documents the basic procedure used to back up and restore the
configuration data and databases on the three nodes in the ITSO Bank secure
system. In addition, we have included the key information for a system
administrator to know what files and database to back up as part of the backup
strategy (for example, tape backup).
12.4.1 Backup
This section documents the basic procedure for backing up configuration data
and databases on the three nodes.
Policy Server node

Backing up the Policy Server node consists of backing up the directory server’s
DB2 database and the configuration files, and backing up the Tivoli Access
Manager Policy Server’s configuration files.
Tivoli Directory Server’s DB2 database

To back up the Tivoli Directory Server’s DB2 database use the dbback command
line tool provided with Tivoli Directory Server. This tool can only be used when
the directory server is stopped.
The syntax of the command is as follows:

dbback -d <backupdir> -w <filename>
Where the parameters are:

򐂰 backupdir: The directory to back up the database.
򐂰 filename: The full path name of the file to which the output is redirected.
To back up the Tivoli Directory Server on the ITSO Bank system we executed the
following command:
c:\ibm\LDAP\bin\dbback -d c:\temp -w tdsbackup

This command creates a file called tdsbackup.dat and a number of other .dat
files like schemafile0.bak in the directory specified and copies the ibmslapd.conf
file to this directory.

The Tivoli Access Manager pdbackup tool should be used when backing up
Tivoli Access Manager configuration files. The fomat of the command is as
follows:
pdbackup –action backup –list <path_to_list_file> [–path <archive path>]
[–file <archive>]

򐂰 list: The path to the file used to determine the list of files that should be
backed up. The default list file can be found at <Policy Director install
directory>\etc \pdbackup.lst.
򐂰 path: The path that the backup file will be written to. If not specified, the path
is <amrte directory>\pdbackup\.
򐂰 file: The file name of the backup archive. If not specified, the file name is
list_filename _<date> .<time> .dar, where <date> and <time> are the date
and time of the backup.
To back up the Policy Server on the ITSO system execute the following
command:
pdbackup -action backup -list “c:\ibm\tivoli\Policy
Server\etc\pdbackup.lst”
The output of the command is recorded in a log file, the location of which is
specified on command completion. A return code of zero indicates a successful
backup.
The backup command produces the following archive:

c:\ibm\tivoli\Policy Director\pdbackup\pdbbackup.list_<date>.time.dar
Proxy Server node

Backing up the Proxy Server node consists of backing up just the WebSEAL
configuration files.
The Tivoli Access Manager pdbackup tool should be used when backing up
Tivoli Access Manager configuration files. Use the following command to back up
the WebSEAL files on the ITSO system:
pdbackup -action backup -list “c:\ibm\tivoli\PDWeb\etc\amwebbackup.lst”
backup.
The backup command produces the following archive:

c:\ibm\tivoli\PDWeb\pdbackup\amwebbackup.list_<date>.time.dar
WebSphere Portal node

WebSphere Portal does not have an official backup procedure currently
documented for Version 5.x. However, the WebSphere Portal V5.0.2 InfoCenter
does recommend low-level and file system backups for a production system. We
will offer procedures for backing up the databases and configuration files for the
Portal node.
Backing up WebSphere Portal databases

The individual Portal databases that have been configured in your environment
need to be backed up. For example, we would back up the following databases
for the ITSO example:
򐂰 FDBK50
򐂰 ITSOBANK
򐂰 WPCP50
򐂰 WPS50
We will provide the general procedure for backing up DB2 databases via a
command line as well as via the Control Center:
To back up a DB2 database from the command line, do the following:

1. Stop the applications that are connected to the DB2 database.
2. Disconnect all applications connected to the database:
db2 force applications all
db2 terminate
3. Create a database backup directory (for example, c:\ibm\dbbackup).
4. Open a DB2 command window.
5. Back up the database by entering the command:
db2 backup db <dbname> to <path>
For example:
db2 backup db wc1 to c:\ibm\dbbackup

The following describes how to perform the backup using the DB2 Control
Center:
1. Select Start → Programs → IBM DB2 → General Administration Tools →
Control Center.
2. Expand the following path of nodes in the left-hand side panel: System →
<node name> → Instances → DB2 → Databases.
3. A list of databases will show under the Databases node. Highlight the
WebSphere Commerce Studio database name.
4. Select Selected → Backup.
5. The Backup Wizard opens. Click Next.
6. Ensure that File System is selected as Media Type. Click Add.
7. The Path Browser is displayed. Select the directory under which you wish to
store the database backup and click OK.
8. Click Next.
9. Ensure that the backup options are set as follows (see Figure 12-5):
– Full Backup.
– Offline - Users cannot access the database during the backup.
– Quiesce must be deselected.
Figure 12-5 Backup options
10.Click Finish.
11.The Backup Wizard will close and the Progress window will open.
12.After a few minutes a window with the completion status of the backup will
open.
Backing up WebSphere Portal configuration

Please refer to “Exporting the WebSphere Portal configuration” on page 546 for
the steps to export the full WebSphere Portal configuration.
Backing up additional WebSphere Portal resources

You will want to perform a file system backup of the WAR files for your portlets as
well as additional file resources that were not included with the standard
WebSphere Portal installation such as themes.
Backing up WebSphere Application Server configuration

To back up the WebSphere node configuration to a ZIP archive, do the following:
backupConfig.bat <backup_file> -user <username> -password <password>
– <backup_file> is the name of the zip file that will contain the node
configuration (for example, WebSphereConfig_yyyy-mm-dd>.zip).
is enabled (For example, wpsbind).
is enabled.
This command will stop all running processes, but it will not restart them once the
backup is complete. You will need to manually restart the desired processes.
The command archives the contents of the <was_home>\config directory (and

subdirectories) to the named zip file in the current working directory.
12.4.2 Restore
This section documents the basic procedure for restoring the backed-up
configuration data on three nodes.
Policy Server node

This section documents how to restore the backed-up data on the Policy Server
node. This consists of restoring the DB2 data, Tivoli Directory Server data, and
the Tivoli Access Manager data.

Tivoli Directory Server’s DB2 database
To restore the Tivoli Directory Server’s DB2 database use the dbrestore
command line tool provided with Tivoli Directory Server. This tool can only be
used when the directory server is stopped. The syntax of the command is as
follows:
dbback -d <backupdir> -n -w <filename>

򐂰 backupdir: The directory to back up the database.
򐂰 filename: The full path name of the file to which the output is redirected.
򐂰 n: Specifies not to restore the ibmslapd.conf file. Use this option when you
want to resynchronize replica data without overwriting the ibmslapd.conf file
of the server.
To restore the Tivoli Directory Server on the ITSO Bank system we executed the
following command:
c:\ibm\LDAP\bin\dbrestore -d c:\temp -w tdsbackup

The Tivoli Access Manager pdbackup tool is used when restoring backed-up
Tivoli Access Manager configuration files and data. The fomat of the command is
as follows:
pdbackup –action restore –file <path_to_archive>
Where the parameter file is the path to the archive created when backing up the
system. See “Policy Server node” on page 549 for details on the archive file
names.
To restore the Policy Server configuration on the ITSO system, execute the
following command:
pdbackup -action restore -file “c:\ibm\tivoli\Policy
Director\pdbackup\pdbbackup.list_<date>.time.dar”
restore.
Proxy Server node

Restoring the Proxy Server node uses the pdbackup tool with the restore option,
as documented in “Policy Server node” on page 549.
To restore the Proxy Server configuration on the ITSO system, execute the
following command:
pdbackup -action restore -file
“c:\ibm\tivoli\PDWeb\pdbackup\amwebbackup.list_<date>.time.dar”
restore.
WebSphere Portal node

Restoring the Portal Server node would involve restoring the WebSphere Portal
databases and configuration, WAR files and custom themes, and the
WebSphere Application Server configuration.
Restore WebSphere Portal databases

Use the following procedure to restore your WebSphere Portal databases. As
needed, to restore a DB2 database, do the following:
1. Stop the applications that are connected to the DB2 database.
2. If a database exists on the DB2 server that is no longer needed, drop the
database as follows from a DB2 command window:
db2 drop db <db_name>
3. Copy the backup of the database to the DB2 server.
4. Prior to performing the DB2 restore, we recommend creating the new
database with the desired codeset and territory. For example:
db2 create db <db_name> using codeset UTF-8 territory US
Note: If the codeset and territory are not specified, you cannot be sure that
the DB2 create database command will create the database with the
desired locale information.
Information on the desired codeset and territory can be found in the DB2
command reference.
5. To restore the database, enter the following from a DB2 command window:
db2 restore db <wc_dbname> from <path>
For example:
db2 restore db wc1db from c:\ibm\dbbackup

Restore WebSphere Portal configuration
To restore WebSphere Portal configuration:
1. Open a command prompt and change to the directory on your workstation
that contains xmlaccess.bat.
2. Run the following command:
xmlaccess.bat -in export_result.xml -user wpsadmin -pwd <password> -url
http://<wp_hostname>/wps/config -out import_result.xml
The command should import your backed-up portal configuration into the
portal. You can open the import_result.xml file to confirm that the import was
successful. You should see the following at the end of the file:
<status element="all" result="ok"/>
Note: The file export_result.xml is the exported configuration file. If it does

not reside in the same directory as xmlaccess.bat, you will need to give a
path to the file.
If you only need to restore parts of the configuration, you can strip out parts
of the export_result.xml file prior to the import. For more details, please
refer to WebSphere Portal V5.0.2 InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wps/admxmla
i.html
Restore additional WebSphere Portal resources

Restore WAR files for portlets and additional file resources, such as custom
themes, to their appropriate directories on the file system.
Restore the WebSphere Application Server configuration

To restore the WebSphere node configuration, do the following:
restoreConfig.bat <backup_file> -user <username> -password <password>
– <backup_file> is the name of the file that will contain the previously
backed-up node configuration (for example,
WebSphereConfig_yyyy-mm-dd>.zip).
is enabled.
12.5 Verifying the ITSO Bank application and runtime
This section steps through the use cases to verify that the ITSO Bank system
has met the specified requirements. Selected uses cases have been chosen to
demonstrate key functionality that has been implemented. Please note that not
every use case will be documented.
The following use cases will be demonstrated:

򐂰 Banking application login.
򐂰 Add user.
򐂰 Modify user information.
򐂰 View account balance.
򐂰 Transfer funds.
12.5.1 Banking application login

This section steps through use case UCF1: Banking application login. It provides
screen shots to demonstrate the scenario outlined in Table 5-7 on page 158.
1. The actor fills out the login form.
a. The user hits the ITSO Bank site with the browser.
b. The Tivoli Access Manager login form is presented.
c. The actor fills in the user name and password.
d. The actor submits the login form.

Figure 12-6 Actor submits login form
2. The system receives the login request and makes the authentication and
authorization decision.
3. The system creates the user credential.
4. The actor is logged in.
Figure 12-7 Actor is logged in
12.5.2 Add user

This section steps through use case UCF3: Add user. It provides screen shots to
demonstrate the scenario use case outlined in Table 5-9 on page 159.
1. The actor accesses the Add User page.

Figure 12-8 Access add user page
2. The actor fills out the new user’s information in the form. The compulsory
fields are Userid, Password and Date of birth.
Figure 12-9 Actor fills out information in form
3. The actor clicks Add User to submit the form.

4. The system asks the actor to confirm user creation.

Figure 12-10 Actor submits form
5. THe actor clicks OK to confirm creation.

The form could be rejected due to missing critical fields. The actor would be
diverted back to step two to fill in missing data.
Figure 12-11 Form rejected due to missing information
6. New user information is added in the database and enterprise directory

server using APIs, and confirmation of account creation is provided.
Figure 12-12 User data added
12.5.3 Modify user information

This section steps through use case UCF4: Modify user information. It provides
screen shots to demonstrated the scenario outlined in Table 5-10 on page 160.
1. The actor browses the Modify User page.
Figure 12-13 Actor accesses Modify User page
2. The actor types in the user ID of the customer in question and clicks Query
User.

3. The system finds user information in the database.
4. The system displays user information.
5. The actor makes necessary changes.
Figure 12-14 Modify user
6. The actor clicks Modify user to the submit form.

7. The system asks the actor to confirm modification.
Figure 12-15 Confirm user modification
8. The actor clicks OK to confirm modification.

9. The system updates the user record in the database and displays
confirmation of the modification.

Figure 12-16 System updates user information and displays confirmation
12.5.4 View account balance

This section steps through use case UCF7: View account balance, with the
customer as the actor. It provides screen shots to demonstrate the scenario
outlined in Table 5-13 on page 162.
1. The customer actor accesses the Account Balance portlet.
If user is a customer, this is located on the access account page
2. The account balance is queried in the database.
If the actor is a customer, no user ID is required.
3. The account balance is displayed.
Figure 12-17 Account balance is displayed
12.5.5 Transfer funds

This section steps through use case UCF8: Transfer funds. It provides screen
shots to demonstrate the scenario outlined in Table 5-14 on page 163.
1. The actor browses to the Transfer funds portlet on the Access Accounts
page.
2. The user fills in the funds transfer form:
a. The actor selects the account to transfer the funds from.
b. The actor selects the account to transfer the funds to.
c. The actor fills in the amount to transfer.

Figure 12-18 Form is completed
3. The actor clicks Execute to submit the form.

4. The system queries the balance of the account to ensure sufficient funds.
Transfer may be rejected if insufficient funds exist. The error message will be
displayed and the actor will be redirected back to step two.
Figure 12-19 System rejects transfer due to insufficient funds
5. The system performs the transfer and updates the information in the
database. The confirmation is displayed.
Figure 12-20 System updates information and displays confirmation

Part 3
Part 3 Appendixes

A
Appendix A. Troubleshooting a secure

portal solution
This appendix includes methods and tools that can be used to troubleshoot
problems that arise in a secure portal environment. Some of these procedures
and tools were used in addressing issues that came up while implementing the
ITSO working example, while others have been used by IBM Software Support in
troubleshooting customer issues.

򐂰 Common issues encountered in a secure portal
򐂰 Runtime log files for server components
򐂰 Gathering runtime tracing for security issues
򐂰 Problems fixed in the portal for external access control

Common issues encountered in a secure portal
There tend to be common problems that arise during setup and runtime in a
secure portal. We will list a few common problems and their solutions. In addtion,
we will include helpful tips to assist you in troubleshooting a secure portal.
Common problems and solutions

The following sections discuss common issues that can arise in a secure portal
environment and recommends solutions to address these problems.
Login problems
After entering your credentials into the login form and pressing Submit, you are
reprompted with the login form. You have verified that you are using the correct
user ID and password. We will address four causes of this issue.
Usage of hostname in URL

If the hostname in your login URL does not include the domain name that you
have set for the SSO domain name in WebSphere Application Server, you will
experience a login problem. For example, if you used itso.ral.ibm.com as your
SSO domain name, then your login URL would need to look like the following:
Incorrect value used in SSODomainName field

If you have entered an incorrect value for the SSODomainName field in the
wpconfig.properties file prior to running the configuration task to enable
WebSphere Portal security with LDAP, you will experience a login problem. For
example, you will encounter a problem if you include a leading period for the
SSODomainName value. The value should appear as follows:
SSODomainName=itso.ral.ibm.com (not .itso.ral.ibm.com)
Note: Unfortunately, the example in the wpconfig.properties that ships with

WebSphere Portal 5.0 shows .ibm.com as an example entry for the
SSODomainName. This is misleadin, and the WebSphere Portal will correct it
in a future release of WebSphere Portal V5.x to show ibm.com.
Problem with browser formatting of POST request

A login problem can occur in Microsoft’s Internet Explorer after applying the
Microsoft Security Update 832894 (MS04-004) or hotfix 821814. The
update/hotfix can prevent your username and password from being included on
a POST request when submitting the login form via SSL. In order to address the
problem, please apply Critical Update 831167 from Microsoft’s support site.
Details and a downloadable fix are available on Microsoft’s support site:
http://support.microsoft.com/default.aspx?kbid=831167
Problem with browser handling of two-letter domains

A login problem can occur if your top-level domain contains only two letters. For
example:
https://www.xx.yy/portal/wps/myportal
This issue can occur in Microsoft’s Internet Explorer 6 due to a problem with the
SetCookie function. To resolve the issue, you can obtain the latest service pack
and follow the instructions on Microsoft’s support site:
http://support.microsoft.com/?kbid=310676
Session timeouts
It is quite common in an integrated environment involving WebSphere Portal and
Tivoli Access Manager WebSEAL for unexpected results to occur due to session
timeouts. These unexpected results can include:
򐂰 Error messages requesting the user to establish a new session
򐂰 Prompting the user for credentials when clicking the Log out button
򐂰 Not prompting the user for credentials when clicking the Log in button
These results occur because both the portal and proxy servers establish a
session with the user independently of each other. For details on the specific
sessions, refer to 4.2.8, “WebSEAL and WebSphere Portal session
considerations” on page 114. It is possible to configure the portal and proxy
servers to handle the session timeouts in a way that avoids these unexpected
results. For an example of this configuration, please refer to the modifications we
made to the ITSO example in 7.8.1, “Configure WebSEAL and WebSphere
Portal sesssion timeouts” on page 356.
Failure creating deployment credentials

During the enable-security-ldap configuration task for WebSphere Portal, one of
the final actions to be run is action-create-deployment-credentials. If this action
fails (confguration task ends in BUILD FAILED), it leaves the portal in a state in
which you are able to authenticate successfully against the LDAP server, but the
administrative user is unable to deploy portlets because the three deployment
credential vault slots have not been created. The action usually fails for one of
two reasons:
򐂰 You have an incorrect value (usually a typo) for one of the properties in the
wpconfig.properties file located in <wp_home>/config.
Appendix A. Troubleshooting a secure portal solution 575

In order to address this issue, you can use one of the following two options:
– If you are able to recognize the incorrect setting in wpconfig.properties,
you can make a change to the file and rerun the enable-security-ldap task.
If the task completes successfully, you have solved the problem. .
– If you cannot locate the source of the problem, you can manually create
the vault slots through the credential vault slot portlet in the portal
administrative user interface by using the following steps:
i. Open the file
<wp_home>/config/work/createDeploymentCredentials.xml for
reference.
i. Log in to WebSphere Portal as the administrative user and navigate to
Administration → Access → Credential Vault.
ii. Click Add a vault slot.
iii. Create a shared vault slot in the Default vault.
iv. For the Name field, refer to the file name parameter (that is,
deployment.user) located in createDeploymentCredentials.xml.
v. Under “Vault resource associated with vault slot” select New and enter
the same name used in the previous step.
vi. In the Shared userid field, enter the value of the external-id parameter
in the xml file
vii. In the Shared password field, enter the password that is set for the
password-secret tag in the xml file.
viii. Click the OK button to create the vault slot.
Repeat steps ii through viii two more times to create a vault slot for
deployment.keystore and deployment.truststore using the same parameters
in the xml file for the same fields in the portlet.
򐂰 Another possible cause of the problem is that the user that you have set for
the LDAPAdminUId property in the wpconfig.properties file does not have
write permissions to the LDAP directory and you have not set up WebSphere
Portal for read-only access to the LDAP server. To resolve this issue, you
need to either give the user ID write access to the LDAP directory, or you can
configure WebSphere Portal for read-only access to the LDAP server. For the
procedure for performing the latter option, refer to “Configure WebSphere
Portal for read-only LDAP access” on page 269.
Note: The console output of the WebSphere Portal configuration task is

written to <wp_home>/log/ConfigTrace.log.
Recovering from lost administrator privileges to the portal
There are various ways for a WebSphere Portal administrator to get into trouble
by removing administration access to the WebSphere Portal. We will discuss two
issues and explain how to rectify them.
Portal administrator is lost

Two possible causes as to why WebSphere Portal can no longer be
administered are as follows:
򐂰 If the portal administrator and all members of the portal administrators group
are deleted through the portal user interface, the XML configuration interface,
or in the LDAP server, you will no longer be able to administer WebSphere
Portal.
򐂰 If the role mapping of the user or group for the Administrator role on the virtual
resource PORTAL is removed, you will no longer be able to administer
WebSphere Portal.
A user becomes an administrator within the portal through a role mapping for the
Administrator role on the virtual resource PORTAL or via direct membership in a
group that has such a role mapping. If the following property is set to true, users
will also inherit access rights from groups of which they are not direct members
via nested membership:
accessControlDataManagement.enableNestedGroups
This property is located in the following file:

<wp_home>/shared/app/config/services/AccessControlDataManagementService.pro
perties
Note: If the portal administrator group (for example, wpsadmins) was not
deleted or the role mappings of that group were not deleted, the best solution
is to add members to this group directly in the LDAP. The new members
become portal administrators after their next login to the portal.
In general, a user or group can be made a portal administrator by the following

database update:
1. Back up the portal database. For the backup procedure, refer to “Backing up
WebSphere Portal databases” on page 551.
2. Run the database command:
SELECT * FROM USER_DESC

3. Check if the result contains an entry with the distinguished name of the
intended portal administrator or the portal administrator user group in the
NAME column. For example, for users this can be one of the following:
– uid=wpsadmin,dc=users,dc=itso,dc=ibm,dc=com with security enabled
– uid=wpsadmins,o=default organization with security disabled
For groups this can be one of the following:
– cn=wpsadmins,dc=groups,dc=itso,dc=ibm,dc=com with security enabled
– cn=wpsadmins,o=default organization with security disabled
Note the correct values of the OID and TYPE column for the intended
administrator or administrator group.
4. Run the following database command:
INSERT INTO LNK_USER_ROLE (USER_DESC_TYPE, USER_DESC_OID, ROLE_INST_OID)
VALUES (<Type value from the USER_DESC table>, <OID value from the
USER_DESC table>, 1)
5. Restart your WebSphere_Portal application server.
Note: Only one portal administrator user ID should have the OID 10, and
one portal administrator group should have the OID 11 in the USER_DESC
table to guarantee the correct function of Portal.
Missing access rights for the administrator group

If the PortalAdminID and PortalAdminGroupID have not been updated within the
wpconfig.properties file prior to enabling/disabling security, wpsadmin and the
members of the wpsadmins group will not have administrative privileges. This
can be fixed in the following way:
1. Check administrative user.
a. Connect to the WebSphere Portal database using a database client:
CONNECT TO WPS50 USER [dbuser] USING [dbpassword]
SELECT * FROM USER_DESC WHERE OID = 10
If the result is empty or the distinguished name contained in the Name
field of the result does not match the distinguished name of your intended
admin user, proceed with the following steps.
Note: You might want to back up the tables USER_DESC and

LNK_USER_ROLE in case any thing goes wrong.
b. If the result of the previous query was not empty, run the following:
DELETE FROM USER_DESC WHERE OID=10
c. Check if the result contains an entry that contains the intended admin
user's distinguished name (one of the following):
• uid=wpsadmin,dc=users,dc=itso,dc=ibm,dc=com with security enabled
• uid=wpsadmin,o=default organization with security disabled.
If you actually tried to log into the portal with this user, the entry will be
there.
d. If the entry is there, run the following:
DELETE FROM USER_DESC WHERE OID=[oid of the entry found in step 3]
INSERT INTO USER_DESC (OID, NAME, TYPE, CREATED, MODIFIED) VALUES (10,
'[dn of the user found in step c]', 9, 1022882400000, 1022882400000)
VALUES (9, 10, 1)
e. Restart WebSphere_Portal application server.
2. Check administrative user group.
a. Connect to the WebSphere Portal database using a database client:
CONNECT TO WPS50 USER [dbuser] USING [dbpassword]
SELECT * FROM USER_DESC WHERE OID = 11
If the result is empty or the distinguished name contained in the name field
of the result does not match the distinguished name of your intended
admin user group, proceed with the following.
b. If the result of the previous query was not empty, run the folloiwng:
DELETE FROM USER_DESC WHERE OID=11
c. Check if the result contains an entry that contains the intended admin user
group’s distinguished name (one of the following):
• uid=wpsadmins,dc=users,dc=ibm,dc=com with security enabled
• uid=wpsadmins,o=default organization with security disabled
d. If the entry is there, run the following:
DELETE FROM USER_DESC WHERE OID=[oid of the entry found in step 3]
INSERT INTO USER_DESC (OID, NAME, TYPE, CREATED, MODIFIED) VALUES (11,
'[dn of the user found in step c]', 9, 1022882400000, 1022882400000)
VALUES (8, 11, 1)
e. Restart WebSphere Portal server.
Problem running WebSphere Portal as a service

When WebSphere Portal is configured to Run as a Service on a Microsoft
Windows server, it can be configured to run as a Local System Account or with a
specific user account. This can cause a problem in some situations after security

is enabled on the WebSphere Application Server, which requires authorization to
terminate the java process.
If WebSphere Portal is configured for a "Local System Account," there is no

specific user and password associated with it. After enabling WebSphere
Application Server security, one of the security features is to protect the integrity
of running application servers and thus requires an authorized user and
password to be issued along with the stopServer.bat command. Only stopping,
not starting, an application server is considered a protected action.
In order to address the problem, you can do either of the following steps to
modify the <was_root>/properties/soap.client.props file:
򐂰 In the SOAP Client Security Enablement section of the file, enter the
authorized user after com.ibm.SOAP.loginUserid= and enter the password
after com.ibm.SOAP.loginPassword= .
򐂰 Stop the server with the stopServer command including credentials. Refer to
“Starting and stopping the application server” on page 533.
Note: The first option would be less secure since you are placing a password
in a file on the file system.
If you do not complete either of these steps, the Java process for the
WebSpere Portal Application Server JVM will remain active, and the following
error might be logged in <was_home>\logs\<app_server>\stopServer.log:
ADMU0111E: Program exiting with error:
javax.management.JMRuntimeException:
ADMN0022E: Access denied for the stop operation on Server MBean due to
insufficient or empty credentials.
Database transfer to DB2 fails on import

While attempting to transfer data from Cloudscape to DB2 as outlined in 7.1,
“Configure WebSphere Portal for DB2” on page 261, you experience the
following error on the import task:
action-wpcp-populate-db2:
[java] Connected to jdbc:db2:wpcp50
[java] Reading file
D:\WebSphere\PortalServer\config\DBTransfer\wps\wpcpdb2insert.sql
[java] Could not read
D:\WebSphere\PortalServer\config\DBTransfer\wps\wpcpdb2insert.sql
[java] java.io.FileNotFoundException:
D:\WebSphere\PortalServer\config\DBTransfer\wps\wpcpdb2insert.sql (The system
cannot find the file specified)
Target finished: action-wpcp-populate-db2
Target finished: database-transfer-import
BUILD FAILED
file:../config/actions/dbt_cfg.xml:925: Java returned: 3
You can find more information as to why this error occurred by examining the
earlier sections of the import task output:
[java] Formatting Exported Item (215) CTAREQUESTATTRS
[java] Formatting Exported Item (216) CMACTIVITY
[java] Formatting Exported Item (217) WPCPMETADATA
[java] java.io.FileNotFoundException:
/opt/WebSphere/PortalServer/config/DBTransfer/wps/[WCM.SCHEMA].LOCKS.exp
(No such file or directory)
[java] at java.io.FileInputStream.open(Native Method)
[java] at java.io.FileInputStream.<init>(FileInputStream.java:91)
[java] at java.io.FileInputStream.<init>(FileInputStream.java:54)
[java] at
com.ibm.wps.config.db.transfer.DumpDatabaseSchema.process(DumpDatabaseSc
hema.java:945)
[java] at
com.ibm.wps.config.db.transfer.DumpDatabaseSchema.main(DumpDatabaseSchem
a.java:1147)
The problem can occur due to the optional creation of the LOCKS table provided
by wpcp during the database transfer. In order to address this problem, you can
attempt one of two options:
򐂰 Modify the database tables template.
– Edit the file <wp_home>/config/templates/db/wpstableslist.txt and delete
the line that includes [WCM.SCHEMA].LOCKS.
– Rerun the configuration task:
<wp_home>/config/WPSconfig database-transfer-import
򐂰 Verify that the PTF configuration task was run successfully after installing the
latest fixpack for WebSphere Portal. If it did not complete successfully, you
may run into this error.
IllegalBlockSizeException seen in SystemErr.log

When analyzing the SystemErr.log, you notice the following exception:
[3/29/04 17:24:39:948 CEST] 5d2b1880 SystemErr R %3DES-F-DCRYPT;
Exception caught while decrypting
[3/29/04 17:24:39:973 CEST] 5d2b1880 SystemErr R ;
javax.crypto.IllegalBlockSizeException: Input length (with padding) not
multiple of 8 bytes
The above exception occurs when the adminPassword field in

<wp_home>/shared/app/wmm/wmm.xml is set to clear text. For example:

adminPassword="ibm"
Instead of:
adminPassword="5mApqlzuuPW7iNQpYWkEKQ=="
WebSphere Member Manager (WMM) accepts both clear text passwords and
encrypted passwords, but for clear text passwords, you will see the exception in
the log.
Note: For further information on encrypting clear text passwords, refer to

“Using command-line utilties to encrypt or remove passwords” on page 586.
Secure portal tips

The following sections discuss helpful hints on troubleshooting a secure portal.
Disabling security for WebSphere Portal

In certain situations (such as troubleshooting your configuration), it is desirable to
disable security in WebSphere Portal. To disable security, do the following:
1. Open a command prompt and navigate to the <wp_home>\config directory.
3. Modify the wpconfig.properties file to configure WebSphere Portal to disable
security. Refer to for the configuration settings used in the ITSO example.
Note: For a detailed description of each of the keywords refer to the

WebSphere Portal InfoCenter found at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wpf/sec_was_di
s.html
Table A-1 Example wpconfig.properties for disabling security
Portal configuration PortalAdminId uid=wpsadmin,o=default

properties organization
PortalAdminPwd <password>
PortalAdminGroupId cn=wpsadmins,o=default
orgainization

5. From the <wp_home>\config directory enter the following command:
WPSconfig.bat disable-security
6. Change to the <was_home>\bin directory and restart the application servers:
cd \ibm\websphere\appserver\bin
startServer server1 (wait for server to complete startup)
The task will disable global security on WebSphere Application Server and
modify WebSphere Portal to use basic portal-based authentication with the
WMM database.
Disabing global security for WebSphere Application Server

Global security can be disabled in WebSphere Application Server simply by
unchecking the Enabled checkbox in the administration console via Security →
Global Security. However, if global security is not working properly, it can cause
the server to not start or even to start without the ability for the administrator to
log on. If this situation occurs, the following procedure can be used to temporarily
disable security:
1. Open the security.xml file for editing. It is located in
<was_home>\config\cells\<cell_name>\.
2. Search for the tag that begins with <security:Security.
3. You should see the following attribute-value pair:
enabled="true"
Modify the value to false.
4. Save the file.
5. Restart the application server.

Global security is now disabled. Therefore, you should be able to access the
administrative console and make any necessary changes. You should only
disable security long enough to address the problem. Be sure you reset the
Enabled value to true in the security.xml and restart the application server when
you have resolved the issue.
Note: If the admin console is not accessible, but you are able to start/stop the
application server, you can use wsadmin to disable security as follows:
1. Run the following command and press Enter:
<was_root>/bin/wsadmin -conntype NONE
2. Type the following and press Enter after each command:
securityoff
exit
Stopping/restarting WebSphere Application Server is required for this to

become active.
Using LDAP client utilities to troubleshoot connections

When WebSphere Portal or WebSphere Application Server encounter problems
ocmmunicating with the LDAP server, it can be helpful when troubleshooting to
use LDAP client utilties.
Command-line tools such as LDAPsearch

Ldapsearch is a simple command-line tool that can search an LDAP server
based on your specified search criteria. The tool gets installed (among others)
with IBM Tivoli Directory Server (as well as other brands of LDAP servers).
Furthermore, the ldapsearch client also gets installed with the IBM Lotus Notes
client.
You can run the tool to verify your LDAP settings. For example, we can run the
following:
ldapsearch -h tamwin1.itso.ral.ibm.com -p 389 -b "dc=itso,dc=ibm,dc=com" -D
"uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com" -w "<password>"
“(&(uid=wpsbind)(objectclass=inetOrgPerson))"
Explanation of options:
򐂰 h: Host name for LDAP server
򐂰 p: Port number for LDAP server
򐂰 b: Base dn for search
򐂰 D: Bind dn
򐂰 w: Bind password
(&(uid=wpsbind)(objectclass=inetOrgPerson)) is the search filter that includes
the entry to be searched.
The results of the request should look similar to Example A-1.
Example: A-1 ITSO example ldapsearch

uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
objectclass=top
objectclass=person
uid=wpsbind
sn=bind
givenName=wps
cn=wps bind
1 matches
Note: The parameter -Z can be used with the ldapsearch command to use a
secure ldap connection via SSL. The command ldapsearch -? can be used to
list all of the options for the tool.
Graphical tools
Two graphical tools that can be used to query an LDAP server include:
򐂰 Microsoft’s LDP: Details on the usage of this tool can be found at:
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.
com:80/support/kb/articles/q224/5/43.asp&NoWebContent=1&NoWebContent=1
򐂰 Java LDAP Browser: Details on the usage of this tool can be found at:
http://www.iit.edu/~gawojar/ldap/
Tips on installing and configuring fixpacks for the portal

When installing fixpacks on WebSphere Portal, problems can occur on the
installation as well as on the post-installation configuration task. The following
sections are three preventative measures to ensure that your installation and
configuration complete successfully.
Using the latest version of the update installer

When installing a fixpack for WebSphere Portal, verify that you have the latest
version of the WebSphere Portal V5 Update Installer. For example, your
installation of the WebSphere Portal v5.0.2 Cumulative Fix1 can fail if you are
using the version of the update installer that was available when WebSphere

Portal v5.0 Fixpack 2 was first released. You can find the latest version of the
WebSphere Portal V5 Update Installer at:
http://www-1.ibm.com/support/docview.wss?rs=688&context=SSHRKX&q1=update+in
staller&uid=swg24005565&loc=en_US&cs=utf-8&lang=en+en
Setting the admin password for the portal

Before running the PTF configuration task after installing a fixpack, you need to
do one of two things:
򐂰 Verify that you have entered the WebSphere Portal administrator password in
the PortalAdminPwd field located in <wp_home>\config\wpconfig.properties.
򐂰 Include the WebSphere Portal administrator password in the command line
when running the configuration task. For example:
WPSconfig.bat WP-PTF-5021 -DPortalAdminPwd=<portal_admin_password>
Setting an appropriate SOAP client timeout

It is possible to experience SOAP timeouts on slower systems when running the
PTF configuration task on WebSphere Portal. To avoid such timeouts, increase
the WebSphere Application Server SOAP connector timeout in the
<was_home>\properties\soap.client.props. For example, change the value to:
com.ibm.SOAP.requestTimeout=6000
Using command-line utilties to encrypt or remove passwords

It is very important in a secure portal to eliminate clear text passwords in
properties files. The following sections discuss options to address this issue.
Encrypt clear text passwords

There are two options when encrypting clear text passwords in a file:
򐂰 Encrypt the password string via a command line and copy the result into the
target file for the appropriate property. For example:
a. Open a command prompt and change to the
<wp_root>/config/work/wmm/bin directory.
b. Encrypt the password string by entering the appropriate command:
wmm_encrypt.bat <password>
The script returns a value for the ASCII encrypted string.
c. Open the target file with a text editor and copy the value from the ASCII
encrypted string and place it in the appropriate field.
d. Save the file.
򐂰 Encrypt an existing password string by directing an encoder towards the
target file and field. For example:
a. Open a command prompt and change to the <was_home>/bin directory.
b. Encrypt the existing password in the target file by entering the appropriate
command:
PropFilePasswordEncoder.bat <filename> <property_name>
• <filename>: Path to target file

• <property_name>: Property name in the target file
Note: Running PropFilePasswordEncoder.bat will remove all comments in

the target file. Also, it will create a backup of the target file with a .bak
extension. For an example of how we used it in the ITSO example, refer to
“Modify the ExternalAccessControlService.properties” on page 331.
Remove passwords in the portal configuration directory

You can remove all clear text passwords in the WebSphere Portal configuration
directory by following these two procedures:
1. Run the following command to remove all passwords from the
wpconfig.properties.
a. Open a command prompt and change to the <wp_home>/config directory.
b. Run the following command:
WPSconfig.bat delete-passwords
Note: All passwords should be removed from the wpconfig.properties file.

However, remember to re-enter the appropriate passwords before running
any future configuration task for WebSphere Portal.
2. The WebSphere Portal installation and configuration processes write

security-sensitive information including clear text passwords into multiple files
in the <wp_home>/config/work directory. When you no longer need this
information, you can remove the directory:
a. Open a command prompt and change to the <wp_home>/config directory.
b. Run the following command:
WPSconfig.bat cleanup-work-dir

Runtime log files for server components
The log files listed below include the common log files that are used for each
server component. It is not intended to be a comprehensive list, but it does
contain the log files that are most helpful when troubleshooting issues and/or
seeking information about runtime output in a secure portal.
Logs - WebSphere Application Server

The following logs are the run-time logs most often referred to when
troubleshooting security problems.
JVM standard logs

The JVM logs are created by redirecting the System.out and System.err streams.
In addition to the server, applications and other code can write to the streams.
The default location for the logs is <was_home>/<application_server>/logs.
򐂰 Name: SystemOut.log
򐂰 Description: Records the health of the running application server (for
example, server1)
򐂰 Name: SystemErr.log
򐂰 Description: Records exception stack trace information that can be used to
troubleshoot a problem with the application server
Web server plug-in log

The default location of the Web server plug-in log is <plugin_home>/logs.
򐂰 Name: http_plugin.log
򐂰 Description: Records error and information messages regarding requests
routed from the Web server to Websphere Application Server. The amount of
data is controlled by the Web server plug-in configuration file.
IBM HTTP Server logs

The default location for the Web server logs is <ihs_home>/logs.
򐂰 Name: access.log
򐂰 Description: Records all Web server activity including request information.
򐂰 Name: error.log
򐂰 Description: Records errors that occur in IBM HTTP Server.
Note: Detailed information on logging for WebSphere Application Server and
IBM HTTP Server can be found in the following locations:
򐂰 Chapter 15, “Troubleshooting,” in IBM WebSphere Application Server V5.1
System Management and Configuration WebSphere Handbook Series,
SG24-6195-01
򐂰 Log Files - Apache HTTP Server:
http://httpd.apache.org/docs/logs.html
Logs - WebSphere Portal

The following logs are the run-time logs that are referred to most often when
troubleshooting security problems.
Portal run-time log

The WebSphere Portal log is the primary source of infomation when
troubleshooting run-time issues. The default location of the portal run-time log is
<wp_home>\log.
򐂰 Name: wps_<date_time>.log
򐂰 Description: Contains message and trace data for WebSphere Portal
JVM standard logs

For JVM standard logs:
򐂰 Name: SystemOut.log
򐂰 Description: Monitors the health of the WebSphere_Portal application server
򐂰 Name: SystemErr.log
򐂰 Description: Contains exception strack trace information for the
WebSphere_Portal application server
Note: Further information on using logs in WebSphere Portal can be found

in the WebSphere Portal V5.0.2 InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wpf/inst_lo
gs.html#runtime_logs
Logs - Tivoli Access Manager

The contents of the Tivoli Access Manager server log files are useful sources of
information for determining configuration problems and monitoring the servers.
The log files capture any error messages and warning messages that are
generated by the Tivoli Access Manager servers. The directory location for

serviceability message log files differs depending on whether Tivoli Common
Directory is configured. In the ITSO Bank system we configured Tivoli Access
Manager to use a common directory for logging. This section documents where
to locate the Tivoli Access Manager server logs on the ITSO system and where
to find information on configuring event logging for auditing.
Note: Further details on Tivoli Access Manager logging and routing and XML
output for logging and auditing logs can be found in chapters 17 and 18 of the
Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360.
WebSEAL Server log

The WebSEAL server log is the primary source of information for data regarding
starting and stopping the WebSEAL server. The default location of the WebSEAL
server log when Tivoli Common Directory is used is <tivoli_common_
directory>/HPW/logs/.
򐂰 Name: <msg_pdmgrdproxyd_utf8>.log
򐂰 Description: Logs WebSEAL servicability messages. Levels of messages
logged can be specified in the pdmgrproxyd_routing file found in <WebSEAL
install directory>/etc.
Policy Server Log

The Policy Server log is the primary source of information for data regarding
starting and stopping the Policy Server. The default location of the Policy Server
log when Tivoli Common Directory is used is
<tivoli_common_directory>/HDP/logs/.
򐂰 Name: msg_pdmgrd_utf8.log
򐂰 Description: Logs Policy Server servicability messages. Levels of messages
logged can be specified in the pdmgrd_routing file found in <Policy Director
install directory>/etc.
Authorization Server Log

The Authorization Server log is the primary source of information for data
regarding starting and stopping the Authorization Server. The default location of
the Authorization Server log when Tivoli Common Directory is used is
<tivoli_common_directory>/HDP/logs/.
򐂰 Name: msg_pdacld_utf8.log
򐂰 Description: Logs Authorization Server servicability messages. Levels of
messages logged can be specified in the pdacld_routing file found in <Policy
Director install directory>/etc.
Tivoli Access Manager event logging
For auditing and other serviceability purposes, other than messages produced
when starting a Tivoli Access Manager server, all messages generated by Tivoli
Access Manager are created in a structured hierarchy of events. Logging of
these events can be configured in the aznapi-configuration stanza of the
configuration file of each server. For further details refer to chapter 19 of the
Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360.
Gathering runtime tracing for security issues

Due to the complexity involved in setting up and maintaining a secure portal
environment configured with Tivoli Access Manager, tracing can be very helpful
when problems occur, and cannot be easily explained.
Tracing authentication issues

When problems occur during the login process (or possibly even the URL
redirection process), tracing can be enabled in one of two places, depending on
whether Tivoli Access Manager or WebSphere Portal is handling the
authentication.
Enabling trace when TAM handles authentication

When Tivoli Access Manager is performing the authentication for WebSphere
Portal, the Trust Association Interceptor (TAI) information will be included in the
trace data. You will be able to see how the TAI handles a request.
To enable the tracing, do the following:

1. Open the WebSphere Administrative Console and submit and login.
https://<was_hostname>:9043/admin/logon.jsp
2. Click Troubleshooting → Logs and Trace.
3. Click WebSphere_Portal → Diagnostic Trace.
4. Verify that the Enable Trace checkbox is checked and change the Trace
Specification to:
com.ibm.ws.security.web.*=all=enabled:
5. Confirm that the location of the Trace Output Filename is:
${SERVER_LOG_ROOT}/trace.log
6. Click OK and save the changes to the master configuration.

Once the server is restarted with the new settings, you will find a trace.log file in
the <wp_home>\log directory.
Enabling trace when WebSphere Portal handles authentication

When WebSphere Portal handles its own authentication, the trace collection will
differ, since the Trust Association Interceptor will not be in use for the portal
server. We will need to enable tracing for portal authentication as well as for
WebSphere Member Manager (WMM).
Enabling authentication trace via portal administration

To enable tracing, do the following:
1. Open the log.properties file in the <wp_home>\shared\app\config directory.
2. Modify the traceString as follows (all on one line):
traceString=com.ibm.wps.engine.commands.*=all=enabled:com.ibm.wps.services.
puma.*=all=enabled:com.ibm.wps.puma.*=all=enabled:com.ibm.wps.engine.servle
t=all=enabled:com.ibm.wps.sso.*=all=enabled
Note: When the trace string is added via the WebSphere Portal Web
administration, the tracing will only be active until the application server is
restarted. Since we will also be enabling WMM tracing for this example and
it requires an application server restart, we have enabled the trace in the
properties file so that the trace will still be present after the server restart.
3. Save the file.

The trace will be written to the wps_<date_time>.log in the <wp_home>\log

directory.
Enabling member management trace via WebSphere administration

To enable WebSphere Member Manager tracing, refer to “Enabling trace when
TAM handles authentication” on page 591, but replace the trace string with the
following:
com.ibm.websphere.wmm.*=all=enabled:com.ibm.ws.wmm.*=all=enabled:WSMM=all=e
nabled
Note: This trace requires a restart of the WebSphere_Portal application

server.
Once the server is restarted with the new settings, you will find a trace.log file in
the <wp_home>\log directory.
Tracing authorization issues
When a user runs into problems accessing a resource, the source of the issue
may be the permissions that the user has on the resource. To troubleshoot this
possibility, tracing can be enabled.
Enabling trace when TAM handles authorization

To enable tracing, do the following:
1. Enter the following URL and log in.
2. Click the Admininstration link in the top right corner of the page.
3. Click Portal Analysis → Enable Tracing.
4. Add the following trace string to the Append these trace settings text field
com.ibm.wps.ac.esm.*=all=enabled:com.ibm.wps.ac.authtable.*=all=enabled
5. Click the Add button (the plus sign to the right of the text field) and the trace
string should be added to the Current Trace settings text field.
6. Click Log Off.
Note: Since we enabled the portal tracing via the portal administration
interface, the tracing is active automatically. However, once the server is
restarted, the tracing is disabled. If you wish the tracing to last beyond the
current server session, refer to “Enabling authentication trace via portal
administration” on page 592 for the procedure.

directory.
Enabling trace when WebSphere Portal handles authorization

To enable tracing, refer to “Enabling trace when TAM handles authorization” on
page 593 for the procedure. However, you will need to replace the trace string
with the following:
com.ibm.wps.ac.*=all=enabled

directory.

Tracing Credential Vault issues
Credential Vault tracing can be helpful when troubleshooting SSO issues
involving back-end applications. The following trace can be implemented whether
using a WebSphere Portal or a Tivoli Access Manager vault adapter.
Enabling trace for credential vault

To enable tracing, refer to “Enabling trace when TAM handles authorization” on
page 593 for the procedure. However, you will need to replace the trace string
with the following:
traceString=com.ibm.wps.sso.*=all=enabled

directory.
Note: When you are finished collecting traces, remember to remove the trace
string and restart the application server. Traces can negatively affect
performance and result in very large log files.
Problems fixed in the portal for external access control

Several issues regarding external access control have been addressed since
WebSphere Portal V5.0. We will address the items fixed in V5.0.2, V5.0.2.1, and
an additional usability fix that came out after V5.0.2.1 was released.
WebSphere Portal V5 Fixpack 2 (V5.0.2)

The items fixed in Fixpack 2 for WebSphere Portal V5.0 are as follows.
PQ77683
Descriptions of this item follow:
򐂰 Resources that do not have a Unique_Name specified do not have a title in
the role names in the external security manager. The title of the default locale
will now be used if no Unique_Name is defined for the resource.
򐂰 When a resource is externalized without an existing role, it will neither show
up in the resource permissions portlet, nor will a role for this resource be
visible in the external security manager. Now the administrator role is
automatically created during externalization. The administrator role will
therefore be visible in the external security manager.
򐂰 The role name in the external system was built in the order
RoleType@ResourceType_ResourceName_ObjectID. Due to this, the
resources were difficult to find in the external security manager. Now the
property accessControlDataManagement.reorderRoleNames in the file
<wp_home>/shared/
app/config/services/AccessControlDataManagement.properties controls how
the role names are built. If the flag is set to true, the role name is built in the
order ResourceType_ResourceName_ObjectID@RoleType.
PQ79613
Descriptions of this item follow:
򐂰 If an XMLAccess request sets a resource to an externalized state and
specifies role mappings for this resource, an exception occurs.
򐂰 If an XML request specifies a parent resource as externalized, all child
resources are also externalized, even if the XML request does not specify
this.
Resulting problem: Due to the previous two problems in PQ79613, migration

from previous versions fails if you try to include the external access control
settings in the migration.
PQ79684
Description: It is not possible to externalize resources of the Resource type Page
and URLMapping.
PQ79819
Description: After installing PQ77683, WebSphere Portal cannot be accessed
anymore.
PQ79938
Description: If an XML request first creates role mappings for a resource and
then externalizes that resource and you run the XML request once more, an
exception occurs.
PQ80428
Description: The role mappings that user groups have for a resource that is
externalized are not transferred to the external security manager if the user
groups do not have the common name property defined in the LDAP.
WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1)

The items fixed in Cumulative Fix 1 for WebSphere Portal V5.0.2 are as follows.

PQ81912
Description: Owner permissions on externalized resources are not muted. This
means that users can get permissions via role mappings in the external system
and through the ownership defined in WebSphere Portal.
PQ83717
Description: When externalizing a resource, only the roles/role mappings that
existed before the externalization took place are externalized. This means that if
the administrator in the external security manager wants to assign a principal to a
resource for a role that was not externalized, he has to use WebSphere Portal
again to create the roles. This is very inconvenient for the external security
manager’s administrator, especially because he is usually not the WebSphere
Portal administrator.
Individual fixes for WebSphere Portal V5.0.2.1

Although we were not able to fully explore this fix, the description is relevent to
the redbook. Refer to the following URL for details:
http://www.ibm.com/support/docview.wss?rs=474&uid=swg24007317
PQ86200
Title: PQ86200 TAM protected object space entries are all one protected object.
򐂰 Description: The externalization model for WebSphere Portal 5 includes the
creation of three levels of child objects under the role object to indicate
context. This fix allows the context information to be omitted if desired.
򐂰 Description: This option allows for multiple WebSphere Portal servers to
share the same Tivoli Access Manager (TAM) object space by permitting an
additional TAM container to be inserted between the WebSphere Portal root
object and the role objects.
The parameter in the ExternalAccessControlService.properties is as follows:
externalaccesscontrol.instance=<TAM_object_container>
Omitting this parameter just means that it will not be used.
򐂰 Description: This option increases the use of TAM inheritance for WebSphere
Portal roles by allowing WebSphere Portal to be configured to search for the
rolename component of the TAM object name in the results of the TAM
entitlements query when determining access rights for a user.
The parameter in the ExternalAccessControlService.properties is as follows:
externalaccesscontrol.allowSubStringSearch=false
B
Appendix B. Configure single sign-on

using LTPA
This appendix describes how to implement WebSphere Portal for single sign-on
authentication with Tivoli Access Manager using LTPA.
Note: For more information on single sign-on refer to 4.1.3, “Single sign-on
guidelines” on page 96.

Prerequisite steps
Prior to configuring single sign-on using LTPA, you should perform the following
configuration steps:
򐂰 Chapter 6, “Install the runtime environment” on page 175 (required)
򐂰 Chapter 7.1, “Configure WebSphere Portal for DB2” on page 261 (optional)
򐂰 Chapter 7.2, “Configure WebSphere Portal for IBM HTTP Server” on
page 264 (optional)
򐂰 Chapter 7.3, “Configure WebSphere Portal for LDAP” on page 266 (required)
Note: Mutual SSL in this example is not required when using LTPA.
LTPA configuration
This section outlines the configuration tasks needed to set up LTPA for single
sign-on. The majority of the steps are common to the procedure used to
configure TAI.
We have provided details where the procedures are unique to LTPA

configuration:
1. Apply Tivoli Access Manager ACLs to new LDAP suffix.
2. Define additional MIME types for WebSphere Application Server.
3. Export LTPA encryption keys from the WebSphere Application Server (Note:
Unique to LTPA configuration).
4. Create a WebSEAL junction (Note: Unique to LTPA configuration).
5. Enable forms authentication on WebSEAL.
6. Configure WebSEAL to modify URLs to back-end systems.
7. Configure additional WebSEAL parameters.
8. Import WebSphere Portal users and groups into TAM.
9. Define access controls for WebSphere Portal URIs.
10.Configure the junction mapping table.
11.Configure Portal login/logout for WebSEAL.
Apply Tivoli Access Manager ACLs to new LDAP suffix

For details refer to 7.5.1, “Apply Tivoli Access Manager ACLs to new LDAP
suffixes” on page 290.
Define additional MIME types for WebSphere Application Server
For details refer to 7.5.2, “Define additional MIME types for WebSphere
Application Server” on page 296.
Export LTPA encryption keys from the WebSphere Application Server

This section describes how to export the LTPA encryption key from WebSphere
Application Server on the Portal Server node and then copy the key to the
Reverse Proxy node.
Export the LTPA encryption key from WebSphere

To export the LTPA encryption keys from the WebSphere Application Server
where WebSphere Portal is installed, do the following:
1. Ensure that the server1 application server is started on the Portal Server
node.
2. Open the WebSphere Application Server Administrative Console:
a. Enter the URL:
b. Enter the WebSphere administrator user ID and password (for example,
wpsbind).
3. Select Security → Authentication Mechanisms → LTPA.
4. From the LTPA configuration settings page, enter the following and then click
Export Keys:
– Other values supplied by default
– Key File Name: c:\temp\wps_ltpa.key
5. Click Save.
6. Click Save on the Save to Master page.
Copy the LTPA encryption key to the WebSEAL

Copy the LTPA encryption key file wps_ltpa.key exported in the previous section
to the c:\ibm\Tivoli\PDWeb\www-default\certs directory on the Reverse Proxy
node (WebSEAL).
Create a WebSEAL junction

For our example, we created a command file named wp-junction-ltpa.pd found in
the c:\6325code\config\tam directory. Next we used the command file to create
the WebSEAL junction.
Appendix B. Configure single sign-on using LTPA 599

Create the wp-junction-ltpa.pd command file
To create the wp-junction-ltpa.pd file containing the commands to create a
junction for WebSphere Portal, do the following:
1. Ensure that the Access Manager Policy Server Windows service is started.
2. Start the pdadmin command line interface on the Reverse Proxy node by
selecting Start → Programs → IBM Tivoli Access Manager →
Administration Command Prompt..
3. Log in by entering login at the pdadmin prompt. When prompted, enter the
user ID sec_master and <password>.
4. To get a list of servers, enter the following command:
server list
The command will output a list that contains the following:
default-webseald-wswin1
Take note of the WebSEAL server name.
5. We created the wp-junction-ltpa.pd file with the commands seen in
Example B-1. The wp-juncion-ltpa.pd will be used to define an SSL junction
for WebSphere Portal in the WebSEAL instance we configured previously.
Example: B-1 ITSO wp-junction-ltpa.pd sample command file

server task default-webseald-wswin1 create -t tcp -h wpwin1.itso.ral.ibm.com -p 80 -j -w -A -F
"c:\ibm\Tivoli\PDWeb\www-default\certs\wps_ltpa.key" -Z <ltpa_password> /portal
Note: For scenarios using the internal HTTP service built in to WebSphere
Application Server (development WebSphere Test Environment or no external
Web Server), update the port to 9081 for HTTP instead of port 80 in the
wp-junction-ltpa.pd (see Example B-1).
Create the WebSEAL junction from wp-junction-ltpa.pd

To create the WebSEAL junction from wp-junction-ltpa.pd, do the following:
1. Copy the wp-junction-ltpa.pd command file to the c:\temp directory on the
Reverse Proxy node.
wp-junction-ltpa.pd and enter the following command:
pdadmin -a sec_master wp-junction-ltpa.pd
Note: When creating the junction, WebSEAL will attempt to connect to the
back-end system (for example, WebSphere Portal). If the system is not
available, you will see the following message:
DPWWA1222E A third-party server is not responding. Possible causes:
the server is down, there is a hung application on the server, or
network problems. This is not a problem with the WebSEAL server.
DPWIV1054E Could not connect
The junction will still be created.
5. Verify that the junction was created properly.

a. Start pdadmin and log in as sec_master.
b. Enter the following command to verify the junction:
server task default-webseald-wswin1 list
You should see a list of junctions, including the new junction created, for
example:
/portal
c. You can further review the junction definition by entering the following
command. This will list all settings for the /portal junction.
server task default-webseald-wswin1 show /portal
Enable forms authentication on WebSEAL

For details refer to 7.5.4, “Enable forms authentication on WebSEAL” on
page 300.
Configure WebSEAL to modify URLs to back-end systems

For details refer to 7.5.5, “Configure WebSEAL to modify URLs to back-end
systems” on page 301.
Configure additional WebSEAL parameters

For details refer to 7.5.6, “Configure additional WebSEAL parameters” on
page 303.
Import WebSphere Portal users and groups into TAM

For details refer to 7.5.7, “Import WebSphere Portal users and groups into TAM”
on page 303.
Appendix B. Configure single sign-on using LTPA 601

Define access controls for WebSphere Portal URIs
For details refer to 7.5.8, “Define access controls for WebSphere Portal URIs” on
page 304.
Configure the junction mapping table

For details refer to 7.5.9, “Configure the junction mapping table” on page 307.
Configure Portal login/logout for WebSEAL

For details refer to 7.5.11, “Configure Portal login/logout for use with WebSEAL”
on page 313.
C
Appendix C. CVS configuration

This appendix describes how to implement the Repository node used within the
ITSO team development environment.
This section is organized as follows:

򐂰 CVS overview
򐂰 CVSNT Server implementation
򐂰 CVS Client configuration for WebSphere Studio Application Developer
The development environment we will use for portal development is WebSphere

Studio Application Developer. WebSphere Studio Application Developer is a
file-based integrated development environment (IDE). In most cases, developers
do not work alone, but rather as part of a team. The open architecture of
WebSphere Studio Application Developer V5.1.0 allows software configuration
management (SCM) systems to be integrated through the use of a plug-in.
WebSphere Studio Application Developer includes SCM plug-ins for Concurrent
Version System (CVS) and Rational® ClearCase LT.
Both SCM plug-ins are installed with the default WebSphere Studio Application
Developer installation, the SCM Server products are not installed. The built-in
CVS client support includes CVS Team Provider Core 2.0.0, CVS SSH Core
2.0.0, and CVS Team Provider UI 2.0.1 plug-ins.
Note: In a real environment, we recommend that you implement CVS on a

UNIX/Linux system instead of Windows for security and functionality reasons.

CVS overview
Concurrent Version System (CVS) is a simple open-source software
configuration management (SCM) system. CVS offers version control for parallel
development, but does not offer many of the advanced features included with a
product, such as Rational ClearCase.
We selected CVS for the ITSO example for several reasons. First, we wanted to
use a SCM tool that people could easily download for free. Second, we wanted to
keep the software configuration management within this redbook at a basic level
so that it would not detract too much from the core WebSphere Portal
development. Finally, CVS is relatively easy to use and many people are already
familiar with how to install, configure, and use it.
Some of the main features of CVS are as follows:

򐂰 Multiple client/server protocols over TCP/IP that let developers access the
latest code from a wide variety of clients from virtually any location with an
Internet connection.
Note: WebSphere Studio Application Developer supports two

communication protocols: pserver (password server) and ssh. The default
is pserver. The other protocol has to be manually configured by selecting
Window → Preferences → Team → CVS → Ext Connection Method.
򐂰 It stores all the versions of a file in a single file using forward-delta versioning,
keeping only the most current version and differences from earlier versions.
򐂰 It insulates the different developers from each other. Every developer works
in his own directory, and CVS merges the work in the repository when each
developer is done. Conflicts should be resolved in the process.
Important: CVS and WebSphere Studio Application Developer have a

different understanding of what a conflict is.
򐂰 For CVS, a conflict arises when two changes to the same base file are
close enough to be noticed by the merge command.
򐂰 For WebSphere Studio Application Developer, a conflict is when the
base revision of a modified file is different from the revision stored in the
repository.
򐂰 Its unreserved checkout approach to version control helps avoid artificial

conflicts common when using an exclusive checkout model.
򐂰 It keeps your shared projects’ data in repositories. Each repository has a root
directory on the file system.
򐂰 CVS maintains a history of the source code revisions. Each change is
stamped with the time it was made and the user name of the person who
made it. It is recommended and good practice that developers also provide a
description of the change. Given that information, CVS can help you find who
made the change and when it was made and why.
For more information on CVS, refer to the following URLs:

򐂰 Concurrent Versions System home page:
http://www.cvshome.org
򐂰 Concurrent Versions System for NT (CVSNT) home page:
http://www.cvsnt.org
CVSNT Server implementation

Since our development environment is a pure Windows environment, we will use
CVS for NT (CVSNT) for the development environment.
The CVSNT Server implementation is organized as follows:

򐂰 CVS Server installation.
򐂰 CVS Server repository configuration.
򐂰 Create CVS users.
Important: CVSNT is not officially supported by the Eclipse platform, which

WebSphere Studio Application Developer is based on. Eclipse does officially
support CVS on AIX and Linux.
Depending on the version, different bugs may occur. In our case, we used
CVSNT 2.0.4 without any problems.
An important note about CVSNT support can be found at:

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home
/docs/online/cvs_features2.0/cvs-faq.html
CVSNT was ideal for our environment because we had a pure Windows
environment, and it is easy to use. We did not experience any significant
problems using the CVSNT version.
Appendix C. CVS configuration 605

CVS Server installation
To install CVS on the Windows platform, do the following:
1. Before installing CVSNT, we recommend reading the installation tips:
http://www.cvsnt.org/wiki/InstallationTips
2. Download the CVSNT V2.0.4 Server (cvsnt-2.0.4.exe) from the following URL
to a temporary directory (for example, c:\temp) on the Build and SCM node:
http://www.cvsnt.org
3. Execute the CVSNT installer by double-clicking the self-extracting
cvsnt-2.0.4.exe file from the temporary directory.
4. Unless noted, we accepted the default options:
– We selected Typical installation.
– We installed\ to the c:\cvsnt directory.
– Under Protocols, we also selected Named Pipe (:ntserver) Protocol.
5. When the installation is complete, restart your system even if the installer
does not prompt you to do so. This step will guarantee that the environment
variables are set up properly.
CVS Server repository configuration

After you have installed the CVS Server and restarted your system (Build and
SCM node), do the following to create and configure the CVS Server repository:
1. Stop the CVS services in order to create the repository by clicking Start →
Programs → CVSNT → Service Control Panel.
2. When the CVSNT control panel window appears, stop the services CVS
service and CVS Lock service by clicking Stop (see Figure C-1 on page 607).
Figure C-1 CVSNT service configuration (Service Status page)
3. Click the Repositories tab.

The use of repository prefixes with CVSNT and Eclipse can cause problems,
so we do not use a repository prefix.
4. You have to manually create the common root directory. For example, we
created the c:\rep directory.
5. Click the Browse button. Select the path you want to be the repository prefix.
For example, we selected the c:\rep directory.
6. Click Add to create the new itso repository (the c:/rep prefix should be
displayed). We choose to call the repository /itso, as seen in Figure C-2, and
then clicked OK.
Figure C-2 ITSO repository path

7. When prompted with the message c:/rep/itso does not exist, Create
it?, click Yes to create it.
When done, the Repository page should look like Figure C-3.
Figure C-3 CVSNT service configuration (Repository page)
Figure C-4 CVS service configuration (Advanced page)
8. Select the Advanced tab. Do the following and then click Apply (see
Figure C-4 on page 608):
– Check Server side support for ntserver protocol.
– Check Impersonation enabled.
– Check Use local users for pserver authentication instead of domain
users.
CVSNT uses either the domain or the local server directory for user
authentication under the pserver protocol. You have to choose the correct
value for your environment. This setting only applies if your machine is
connected to a Windows domain.
9. Select the Services Status tab. Click Start for the CVS service and CVS
Lock service. The status should change to Running.
Create CVS users

When setting up CVS users, you have two options: Creating separate Windows
users for each CVS user (good for high security and auditing needs), or sharing
one Windows user for all CVS users (good for ease of configuration and less
stringent security needs).
Note: As mentioned when configuring the CVS repository, you can choose
between local accounts or domain accounts (we used local accounts). Within
the development environment example we are not focused on security for
CVS. In a production environment, we recommend that you refer to the CVS
documentation to secure your environment for your needs.
For the ITSO development environment, we create one Windows user for each
CVS user as follows:
1. To add the Windows user for each developer using CVS, do the following:
a. Add the desired CVS user to Windows on the Build and SCM node by
clicking Start → Settings → Control Panel → Administrative Tools →
Computer Management.
b. Select Local Users and Groups → Users.
c. From the menu bar, click Action → New User.
d. We created a user called boog.
e. Add boog to the group Power Users.
f. We repeat the same for the user manekar.

2. To add CVS users to the CVS repository, do the following:
a. Open a Windows command prompt.
b. Set the cvsroot as follows:
set cvsroot=:ntserver:CVSJMG1.itso.ral.ibm.com:/itso
Where CVSJMG1.itso.ral.ibm.com is the host name of the Repository
node, and itso is the repository created for the ITSO (no prefix).
Note: The host name must be specified. For example, specifying

localhost will not work.
c. Enter the following CVS commands to add users:

cvs passwd -a -r boog boog
Where the first occurrence refers to the Windows user created, and the
second refers to the CVS user added to the CVS passwd file found in the
c:\rep\itso\CVSROOT. You will be prompted for the desired password of
the user being created. We do not recommend that you modify the passwd
file directly. Repeat this step for each developer needing CVS access; in
our case we repeat that for manekar.
3. Next, provide the development users their CVS account information, host
name, and connection type to the CVS server so that they can establish a
connection from WebSphere Studio Application Developer in a later
configuration step on the Development node. For example:
– Account info: Developer CVS user created (for example, boog)
– Host name: CVS Server host name (for example,
CVSJMG1.itso.ral.ibm.com)
– Connection type: pserver
CVS Client configuration for WebSphere Studio

Application Developer
This section describes CVS client configurations to be made for use with
Set CVS DTD file extension to ASCII
We discovered when adding DTD files to the CVS repository that by default the
file would be added as a binary file. This is not the desired or expected behavior.
To address this issue, we did the following:
1. From within WebSphere Commerce Studio Workspace, select Window →
Preferences.
2. Select and expand Team → File Content.
3. Click Add, and enter dtd in the file extension text box, then click OK.
When done, you should see dtd file extension listed as ASCII content type.
Label decorations for CVS

When working with CVS within WebSphere Studio Application Developer, we
recommend adding some visual clues to the environment:
1. Select Window → Preferences in WebSphere Studio Application
Developer.
2. Expand the Workbench node and click Label Decorations.
Workbench is listed first, even though all other options are listed
alphabetically.
3. Ensure that the CVS check box is checked. Click OK.
This will make sure that the icons of any resource that is under source control will
get a small cylinder icon, the release number appended to the resource name,
the file type (ASCII/Binary), and a greater-than sign (>) in front of the resource
name if the file is locally modified and therefore not in synchronization with the
repository. If the resource is not under source control, it will have a small
question-mark added to its icon, signifying that the file is unknown to CVS.
Setting up the repository location

For setting up the repository location in WebSphere Studio with the parameters
that were provided by the CVS administrator, do the following:
1. In WebSphere Studio click Windows → Open Perspective → Other →
CVS Repository Exploring.
2. In the view CVS Repositories use the right mouse button for opening the
context menu, and choose New → Repository Location.
3. Add the parameters for the repository location and select to validate the
connection on finish (see Figure C-5).

Figure C-5 Adding a new repository location in WebSphere Studio
If everything worked correctly, you now should be able to see a repository

location with HEAD, Branches and Versions (see Figure C-6 on page 612).
Figure C-6 The CVS perspective of a successful connected CVS repository
D
Appendix D. Automate deployment tasks

This appendix describes how to automate portal application build, packaging,
and deployment tasks with a focus on the portal specifics of the ITSO Bank
sample application. In Chapter 10, “Deploy the secure portal application” on
page 433, we demonstrated how to deploy the ITSO Bank application using a
manual procedure. This appendix provides automated scripts to replace many of
these manual tasks.
Note: This appendix is intended as a reference for developers to automate

build, package, and deployment tasks. The Ant scripts are provided as is, and
have detault implementation for building the following component types: EJBs,
Web Archives containing Portlet Applications, Utility Libraries (JAR files),
Enterprise Archives (EAR files) and Portal pages. Only Portal components
incorporate deployment functionality: Portlet Applications and Pages.
This appendix is organized into the following sections:

򐂰 Overview
򐂰 Terminology
򐂰 Tooling
򐂰 Deployment walkthrough
򐂰 Concepts and background discussion

Overview
Automation is a tactic for solving a number of problems that are often caused by
tedious manual tasks. Complex manual tasks are one of the least desirable
things a project wishes for, as it is associated with a number of undesirable
factors such as:
򐂰 Wasting time which could be allocated for other things
򐂰 Introducing or increasing the number of human errors
򐂰 Increasing development and maintenance cost
In order to manage a development project, it is desirable to have as much

information as possible up front about the sources of complexity. This is so that
plans, structures, and processes can be created in order to better cope with
complex issues.
Deployment is the process of getting deployment units onto runtime

environments. Given this, the more we know about our runtimes, the better we
can plan and structure the project deliverables for the targeted environments.
The better we tailor our deployment units for the targeted environments, the
smoother and less complex the deployment phase will be.
There are generally two choices when it comes to deploying a unit. Either you
deal with the complexity of configuring it when building the unit, or you defer until
later during deployment to deal with it. This is a sliding scale and constraints are
usually what ultimately decide where on the scale a unit ends up.
It is desirable to do as much as possible during the build phase before shipping

or deploying a unit since complex issues related to the deployment units are best
dealt with by the people who developed the units.
The following three requirements exist in most any project and will be the driving
force when we approach automation pertaining to deployment of our ITSO Bank
sample application:
򐂰 Traceability
Knowing what components you have deployed and being able to trace them
back to source in a repository.
The simplification of administrative chores such as configuration, packaging,
and deployment processes, aimed at reducing the probability that
errors/defects appear due to high complexity. As the portal application grows
and the number of deployment nodes increase, so does the complexity and
administrative difficulty.
򐂰 Reproducibility
Being able to reproduce a given version of the application with a given
configuration for different deployment nodes. For example, nodes in
development, test, or production environments.
In order to streamline the build, package, and deployment scenarios, we look to

automation of tasks as the means of fulfilling the above requirements. To be
successful in our undertaking we require:
򐂰 Identification and classification of components and elements required to
create our application, coupled with their respective dependencies from a
runtime perspective
򐂰 Details of any required structuring (package layout) of the units imposed by
the runtimes
򐂰 The procedures for deploying each type of unit
򐂰 Details about the targeted environments our solution will be deployed to
We will limit the scope of our discussion of the component types in this appendix
to what is relevant from a packaging and deployment standpoint. Focus will be
on our ITSO Bank sample application developed in this book, but some
comments will be made for how to manage situations that are likely to occur in
various projects, but were not specifically addressed while creating our example
application.
In order to shorten the startup phase of WebSphere Portal customization and

development projects, we will be using a WebSphere Portal development starter
kit (See “ITSO WebSphere Portal development starter kit” on page 627), which
we are also making available for download along with this book. Using the starter
kit will give us a sound initial structuring and partitioning of the elements together
with tooling for common chores related to WebSphere Portal development and
deployment. See “ITSO WebSphere Portal development starter kit” on page 627
for a discussion of the starter kit.
Terminology
Table D-1 on page 616 provides a definition of key terms used throughout the
appendix to provide a context and meaning. The domain of build and deployment
bridges the development and runtime domains. We have attempted to use terms
for concepts which are distinct and not to be confused with concepts with the
same name in other domains.
Appendix D. Automate deployment tasks 615

Table D-1 Description of domain specific terms.
Term Meaning
Solution The result of all custom development effort aimed at solving one or
more business requirements.
Component An identifiable part of the solution that can be packaged and

deployed on its own.
A component depends on zero or more other components in order
to build and run.
Example: A portlet application or an EJB.
Portal application One or more portal components that run on a WebSphere Portal
node. Essentially a subset of the solution.
Portal component A logical structuring of related elements covering a WebSphere

Portal concept. A specialized component.
Example: Skin, theme, or portlet application.
Element The smallest unit of work in the solution.

Essentially a file on a file system.
Archive A file system container containing one or more files and/or

directories.
Example: A J2EE Web Archive, a ZIP, or a TAR file.
Build The process in which one or more solution elements are

transformed and aggregated into units suitable for a targeted
runtime.
Packaging The process of assembling built elements into containers intended

for deployment.
Example: The assembling of portlet application elements into a

Web archive or the assembling of portal components into a
solution archive.
Deployment The process of installing packages onto a runtime environment

and/or reconfiguration of said environment.
Tooling
The majority of the ITSO automation scripts have been developed using Apache
Ant. The reason we choose Ant is because it is a very flexible tool, easily
extensible, and is used by WebSphere Portal and WebSphere Application Server
as a base for their respective configurations. In addition, it is also freely availably,
and there are many developers familiar with Ant, as it has become the tool of
choice for deployment.
As Ant is a Java-based tool, it will run on a lot of different platforms; in fact, any
platform for which a Java Development Kit is provided. Since we will be working
with WebSphere Application Server and Portal technology, we will have
additional constraints, since we are dependent on certain libraries provided by
these two products. Thus, a build or deployment node requires these products to
be installed.
The components required in this appendix are:

򐂰 WebSphere Portal runtime
Either a standalone WebSphere Portal runtime or provided by WebSphere
Portal Test Environment in WebSphere Studio Application Developer.
򐂰 The ITSO WebSphere Portal development starter kit (see “ITSO WebSphere
Portal development starter kit” on page 627)
Note: Apache Ant is bundled with WebSphere Application Server as well as

WebSphere Studio Application Developer (which is bundled with a
WebSphere Application Server runtime) and has its own Web site hosted by
the Apache Foundation at:
http://ant.apache.org
We will be using the Ant version provided by WebSphere Application Server

runtime since it is pre-configured to use many of the libraries we will be
depending on.
Deployment walkthrough
This section walks you through the steps involved in starting a WebSphere Portal
project and includes adding, building, and deploying components. Some of the
steps are similar, or just an alternative way of doing the same thing, as has
previously been described in Chapter 10, “Deploy the secure portal application”
on page 433. As with all automation, we will begin by relying on manual
processes, and thus will reference the manual steps during the phase where we
create the components. The real benefit of this excercise comes when doing
repeated deployments.
The target runtime environment we will target is the one we installed in

Chapter 6, “Install the runtime environment” on page 175; and Chapter 7,
“Configure the runtime environment” on page 259, and what we will be deploying
is the front-end/Portal Application of the ITSO Bank solution. Since the Portal

Application depends on the back-end part of the solution, we suggest that you go
through the steps mentioned in 10.2, “Deploy the ITSO Bank back-end
application” on page 434, in order to be able to validate the deployment at the
end of this walkthrough.
The deployment part of this walkthrough is a subset of what is described in

Chapter 10, “Deploy the secure portal application” on page 433. More
specifically, we will be performing the equivalent steps described in 10.3, “Deploy
the ITSO Bank portal application” on page 446, with the exception of 10.3.3,
“Modify the wmmLDAPServerAttributes.xml file” on page 449, since we are
targeting iterative processes, not single occurrance modifications. Iterative
processes are what will provide most value per time invested in automation. As
we go, we will refer to the manual steps that we aim to replace.
This section assumes that WebSphere Studio Application Developer has been
set up on the current working environment. If not, refer to Chapter 8, “Implement
the development environment” on page 361, for details for setting up the
development environment.
Solution structuring
The ITSO Bank portal application will consist of one Portlet Application and four
custom pages. This implies that the component types we will be concerned with
are the following:
򐂰 Portlet Applications
Grouping of related Portlets
򐂰 Pages
Composition of content areas and navigation
򐂰 Environment Configurations
Specific configurations for the target environment
One of the goals with our setup is to make it self contained. That is, we should be
able to build, package, and deploy using only the assets contained in the project
directory structure. Having all dependent libraries within in the project also helps
avoid incompatibilities between library versions, which might otherwise occur if
developers are using their own selection of external libraries.
Note: Actually, we have dependencies on libraries outside the project, the
libraries provided by WebSphere Portal and WebSphere Application Server.
We bend the rules for self-containment here in order to abide the licensing
agreement for the products. However, if the license for a dependent entity
allows you to include it in the project and use it as part of your build and
deployment scenarios, then we would recommend that you do so.
Preparation
WebSphere Portal Test Environment contains a basic but functional runtime
environment configuration, and you will start by backing up the current
configuration by serializing it to an XML document. This will enable us to revert to
the current configuration should something go wrong at any point while modifying
the WebSphere Portal configuration.
After having serialized the WebSphere Portal configuration, we will initialize the
solution working area, which will configure the starter kit for the environment we
are currently working in.
Backing up the WebSphere Portal configuration

Before you start modifying your WebSphere Portal runtime, it is suggested that
you make a copy of the current configuration, so that you can revert to that state
if so desired. We suggest that you make the backup in two ways. The first is a
node backup of WebSphere Portal as described in 10.2, “Deploy the ITSO Bank
back-end application” on page 434, for the purpose of disaster recovery. The
second is for having a reference of the configuration in XML form, which you can
refer to at a later stage when working with subsets of the configuration. The
serialization is performed by exporting the WebSphere Portal configuration to an
XML document using the xmlaccess command. The command is located in the
<wp_home>\bin directory.
Example: D-1 Serialize the WebSphere Portal configuration

C:\ibm\WebSphere\PortalServer\bin\xmlaccess -url
http://wpwin1.itso.ral.ibm.com/wps/config -user wpsadmin -pwd passw0rd -in
<wp_home>\doc\xml-samples\Export.xml -out c:\temp\full_export.xml
Setting up the solution working area

First we will be creating our solution working directory and obtaining the ITSO
WebSphere Portal development starter kit, followed by submitting it under
version control, and finally initializing our working area.

1. Start by creating a directory on the disk that will be the root directory of the
solution. We will be using c:\6325sol.
2. Download the ITSO sample code containing the ITSO WebSphere Portal
development starter kit from:
3. Unpack the 6325code.zip (for example to, c:\6325code).
4. Open a console window and change to the solution root directory.
5. Extract the contents of the starter kit:
<was_home>\java\bin\jar -xvf c:\6325code\starterkit
6. Optional: If you have CVS installed, import the solution working area to CVS
in order for other team members to be able to use it. From a console window,
change to c:\6325sol and issue:
cvs -d:pserver:user@cvsjmg1.itso.ral.ibm.com:c:/rep/itso import -m “initial
import” 6325sol ibm init
Initializing the working area

This will configure the working area to the current environment. If executed from
an environment containing WebSphere Studio Application Developer, the
process will be automatic. If initializing from an environment containing only
stand-alone WebSphere Application Server and WebSphere Portal, you will be
prompted for the directories the two products are installed in.
1. Change to c:\6325sol and issue:
<was_home>\bin\ws_ant -f setup-buildenv.xml
2. If prompted for the location of WebSphere Portal and WebSphere Application
Server, enter the corresponding directory locations for the current
environment.
There is now a file named init-env.bat in current directory. This file contains
environment variables used by the starter kit in order to find needed libraries and
for proper directory navigation. Copy this file to your desktop and use it instead of
starting an ordinary console window from now on when working with the build
files.
Note: If you try to execute a build file without having the needed environment
variables set, Ant will fail immediately, stating that the needed environment
variables are not available. For this reason, always use the init-env script
when you want to work with build files relying on the starter kit.
Populating the solution
Now we have an initialized solution working area without any components, so it
is time to fill it with the components we will be using.
Adding WebSphere Studio Application Developer projects

Navigate to the c:\6325sol\wsad\projects directory and add your WebSphere
Studio Application Developer projects to this directory by either exporting from
WebSphere Studio Application Developer or by exporting them directly from a
CVS location. We will be exporting from WebSphere Studio Application
Developer.
1. Start WebSphere Studio Application Developer.
2. Open the J2EE Perspective and switch to the Project Navigator view.
3. Select all projects to export, which in our case include ITSOBankEAR,
ITSOBankEJB, ITSOBankPortalEAR, ITSOBankUtils and ITSOBankWAR.
4. Right click one of the selected projects to bring up the context menu, click
Export, and select File System as the export method. Click Next.
5. In the To Directory field enter c:\6325sol\wsad\projects and click Finish.
6. Close WebSphere Studio Application Developer.
In a real project, we would now do the following:

1. Copy a proper build.xml template from c:\6325sol\wsad\templates to each of
the WebSphere Studio Application Developer component directories.
2. Add each WebSphere Studio Application Developer component to version
control, so that component developers can start adapting the build.xml files
for the specific components.
Note: With the starter kit we have created directories for the WebSphere
Studio Application Developer projects we use in this redbook and populated
them with pre-edited build.xml files in order to make this walkthrough feasible.
In a real project you would start by removing all directories under
wsad\projects, followed by copying a template build.xml file from
wsad\templates to the corresponding component’s directory. Developers will
likely want to edit the component build files in order suit their particular
components. These templates work as a starting point for them.
Building and deploying the Portlet Application

The reasons we decide to deploy the portlets at this stage are two fold. Firstly,
having portlets deployed to the runtime is a prerequisite for using the page
administration portlet to assist us in creating and composing the Pages

component. Since WebSphere Portal pages reference portlets, we will be unable
to customize our pages, adding portlets to them and arranging the layout of the
pages unless we can reference the portlets. In order to reference them, they
have to be deployed to the target node. Secondly, having the portlets deployed
to a WebSphere Portal node allows us to edit the resource permissions of the
portlet application and the portlet instances using the resource permission portlet
in the Web administration interface. The manual steps covered here are those
defined in Chapter 10, “Deploy the secure portal application” on page 433. The
editing of the application property files is implicit during the build of the Portlet
Application component, and is performed by the component’s configure target.
The manual deployment section has been replaced by the execution of a single
command.
1. Open an initialized console window by double clicking the file init-env.bat
located on the desktop.
2. Change to the ITSOBankWAR component directory:
cd c:\6325sol\wsad\projects\ITSOBankWAR
3. Create a deployment unit of the ITSOBankWAR component for the local
environment. (Omitting the targetenv parameter will default the target
environment to the local environment.)
ant dist
4. Start the local WebSphere Portal runtime environment:
<wp_home>\config\wpsconfig start-portal-server
5. Deploy the ITSOBankWAR component to the local environment:
ant deploy
Creating pages
We will be using WebSphere Portal’s page administration portlet in the Web
interface, since we are creating an initial page hierarchy. Begin by following
10.3.5, “Create portal pages” on page 451, through 10.3.6, “Add portlets to
pages” on page 453 to create the pages and assign the portlets to them. Then
give the top page in the new page hierarchy (the page titled itsobank), a custom
unique name so that we can reference it later via xmlaccess. This is done as
follows:
1. In the Web administration interface menu on the left side of the screen, click
Portal settings → Custom Unique Names.
2. In the resource type list, click Pages.
3. In the search field titled Search For, input ITSOBank and click Search.
4. Click the pencil icon (Edit unique name or Page) to the right on the screen.
5. In the field titled Custom name, enter itso.page.itsobank and click OK.
Modifying resource permissions
Follow the instructions in 10.3.7, “Modify resource permissions” on page 459,
through 10.3.8, “Verify ITSO Bank application” on page 467.
Extracting access control elements for Portlet Application

Now we have a working application that we can base our component
configurations on. We could have created the pages, and performed the access
control activities by creating xml documents by hand, but it would have been an
error-prone process, and is something we discourage. The steps just covered
are what we would define as extensive modification, mentioned earlier as to
when using the administration portlets was prefered.
Now we will serialize the configuration of the pages together with their assigned
permissions. The result will be two XML documents, one containing the page
composition and the other the access control information.
2. Change to directory of the pages component:
cd c:\6325sol\ui\pages directory
3. Run the following command (all on one line), which will export the pages and
associated access control directives to two XML files:
wpdsk-util -Dtargetenv=wpwin1 -Dexport.pageroot=itso.page.itsobank
export-pages
4. Rename the file exported_pages.xml to pages.xml.
5. Rename the file exported_access-control.xml to access-control.xml.
Next we will serialize the access control for the Portlet Application component.
The result will be an XML document containing the access control configuration.
1. Change to the ITSOBankWAR component directory:
cd c:\6325sol\wsad\projects\ITSOBankWAR
2. Once again we will let the wpdsk-util command assist us:
wpdsk-util -Dtargetenv=wpwin1 export-pages
3. Rename the file exported_access-control.xml to access-control.xml.
Note: The command wpdsk-util is a utility file, which provides some

assistance with working with serialized configuration. See “wpdsk-util
command reference” on page 642 for more details about this command.

Verification
Let us start the verification by building the components, uninstalling them from
the target environment, and finally re-deploying them.
2. Change to the solution root directory c:\6325sol and issue:
ant -Dtarget=clean all
3. Build the components configured for our target environment:
ant -Dtargetenv=wpwin1 -Dtarget=dist wars pages
4. Undeploy the components:
ant -Dtargetenv=wpwin1 -Dtarget=undeploy wars pages
5. Do a verification that the components are gone by either doing a full
xmlaccess export of the entire portal configuration, or logging into the Web
administration interface and using the administration portlets to verify that the
components are no longer deployed. We will use xmlaccess:
<wp_home>\bin\xmlaccess -url http://wpwin1.itso.ral.ibm.com/wps/config
-user wpsadmin -pwd passw0rd -in <wp_home>\doc\xml-samples\Export.xml -out
c:\temp\full_export_verification.xml
6. Verify that the pages are no longer present. This can be done by searching
for the unique name itso.page.itsobank we assigned to our top page. If that
page is not present, then neither are any of the children, since WebSphere
Portal 5 does not allow leaf pages.
type c:\temp\full_export_verification.xml | c:\winnt\system32\find
“itso.page.itsobank“
7. Verify that our portlets are gone as well by searching for the unique ID of the
Portlet Application, as defined in portlet.xml:
type c:\temp\full_export_verification.xml | c:\winnt\system32\find
“com.ibm.itso.bank.portlets.ITSOUser.e02c08feb2“
8. Now let us deploy the components again:
ant -Dtargetenv=wpwin1 -Dtarget=deploy wars pages
9. Repeat the verification, steps 5–7. This time the Windows find command
should return results when we query, both for the page and the Portlet
Application.
You now have the pages component and the WebSphere Studio Application
Developer components comprising the WebSphere Portal part of the application
set up for automatic build and deployment. You can deploy any of the
components to any environment remotely by mounting an SMB share (Windows
file share) to the current environment and creating a build.properties file for the
environment. If you do not have the ability to mount a share from the target host,
then you can create a solution archive, transfer it to the target host, unpack the
archive, and deploy the components, as described in “Deploying from the target
host” on page 641.
Concepts and background discussion

This section covers some of the theory useful for proper solution management.
We will also explain support features used in the first half of the appendix in more
detail.
Component types
Here we touch on some of the key portal concepts and how they relate to
deployment units.
There are a number of different WebSphere Portal concepts that can be

componentized in order to ease team development and more rapidly and
accurately deploy the application to the WebSphere Portal runtime environment.
This section briefly discusses the most relevant concepts for components that
will be deployed.
For a full discussion of the different concepts available for creation or

customization of WebSphere Portal assets, please refer to the WebSphere Portal
5.02 InfoCenter and read the chapters Designing your portal and Developing
portlets found at:
Portal services
A Portlet service is an implementation of the PortletService interface, making it
possible for portlets to share the implementation. The portlet service is from a
deployment perspective, essentially a utility library. This library has certain
specific deployment requirements. It must be deployed from the WebSphere
Portal into the <wp_home>/shared/app directory. Additionally, it must be added
to the application server’s WPSLib shared library, and also receive a registration
entry in
<wp_home>/shared/app/config/services/PortletServiceRegistryService.propertie
s. For further details, refer to the WebSphere Portal 5.02 InfoCenter.
Portlets and Portlet Applications

A portlet is an application that displays page content. Portlet applications are
collections of related portlets and resources that are packaged together. Portlets

packaged together as Portlet Applications share the same context containing
specific resources such as images, properties files, and classes used by the
portlets.
The container for a Portlet Application is a J2EE Web Archive, also referred to as
a war file, due to its extension.
Table D-2 shows a typical structure and elements of a Portlet Application Web
Archive.
Table D-2 Contents of a Web Archive containing a Portlet Application

Element Description
WEB-INF/classes Optional. Directory containing the compiled Java code for all
portlets within the Portlet Application
WEB-INF/lib Optional. Directory containing utility libraries private to the

Portlet Application
WEB-INF/portlet.xml Required. The WebSphere Portal deployment descriptor
WEB-INF/web.xml Required. Web application server deployment descriptor
jsp Optional. Directory containing Java Server Page files
Note: In order to support different markups and locales, you can optionally
create further directories within the jsp folder, such as jsp/<markup>/<locale>.
So for example, if we need to support html and the German locale, we would
create two additional sub directories like jsp/html/de, and put our content in
the third-level directory.
User interface
The user interface components consist primarily of four different types: Themes,
skins, screens, and pages. The first three can be made to render their visual
representation differently, depending on the specifics of the client accessing
WebSphere Portal.
Screens
This is the area of the portal that typically displays portlets, but can also display
other content in its place, for example, a login form or error message. Screens
are selected from navigation icons in the theme.
On a WebSphere Portal node, screens are deployed to the following directory:

<was_home>/installedApps/<nodename>/wps.ear/wps.war/screens/
Themes
Themes determine the look and layout of the portal, including colors, fonts, and
images outside of the portlet content area. Themes often provide the initial
navigation to portal pages.
Themes are divided into separate directories, one for each theme. At least one
Java Server Page file named Default.jsp must exist for each theme. This file can
be seen as the entry point for the rendering of a page.
On a WebSphere Portal node, themes are deployed to the following directory:

<was_home>/installedApps/<nodename>/wps.ear/wps.war/themes/
Skins
Skins represent the border rendering around components, such as the
navigation provided by the theme, containers, or portlets. Skins also provide
navigation themselves, to levels deeper than the navigation that is provided by
the themes. Skins are installed independently from themes. However, the
administrator can set a default skin for a theme.
Skins are partitioned into their own directories, which hold all elements specific to
a certain skin. Inside its directory, at least one file is required, a Java Server
Page file named Control.jsp. This file is responsible for rendering the skin area.
Skins have a relationship to themes, in that a theme is what is triggering the
rendering of a skin and that a theme can be configured with a default skin.
On a WebSphere Portal node, skins are deployed to the following directory:

<was_home>/installedApps/<nodename>/wps.ear/wps.war/skins/
Pages
This is a form of configuration of WebSphere Portal governing the navigational
structure of the portal, also acting as containers for portlet instances, dictating
the layout of the portlets. A page have no file system resource representation,
and thus does not require anything to be deployed to the target node’s file
system.
ITSO WebSphere Portal development starter kit

The reason that we create a WebSphere Portal starter kit is to accelerate the
startup phase of portal projects, as well as aid in maintaining solutions as they
grow. We found the available information lacking in how to maintain portal
projects efficiently. Also, in our experience there is not always time to spend
thinking and planning the automation of build, package, and deployment tasks in
projects.

Typically, team members start producing artifacts without much thought as to
what will happen when they get to the deployment phase. Having a good starting
point will reduce the cost of both developing and maintaining the solution, since
time spent deploying applications is reduced, less errors introduced due to
human intervention and reduced startup time when creating new applications or
components is achieved.
The ITSO WebSphere Portal starter kit provides the following:

򐂰 A base structure into which developed components can be placed.
򐂰 Tooling handling commonly occurring tasks pertaining to building and
deploying components.
򐂰 Templates to assist in the creation of new components.
The requirements for each component are that it should be able to build,
package, and optionally configure for a target environment. In some cases,
depending what type of component it is, it should also be able to deploy itself
and, if so, also undeploy as well. Additionally we place the same requirements
for the solution, so that it should be possible to perform a build and deployment
on a solution-level or component-type level. These requirements make the
solution easy to administer for different kinds of job roles. For example, a portlet
developer might simply want to create the pages in his private WebSphere Portal
Test Environment, and can thus issue the Pages component to deploy itself to
that environment. Another example is when the team wants to deploy the entire
solution to another environment. They can then issue the entire solution to
deploy itself to a specified node/target environment.
We have tried to weigh unobrusiveness for developers against ease of solution

management when creating the starter kit. A goal was that it should be usable
without requiring any changes to WebSphere Studio Application Developer,
since the latter is likely to be the primary tool for portlet and J2EE development.
The starter kit scripts are primarily based on Apache Ant. Each element of the kit
is either an XML or XSL document, or a plain text property file. The goal of
sticking to these three types of documents was to make it accessible for as many
people as possible to understand and modify the kit in order to satisfy particular
needs. Also, using existing libraries instead of writing custom ones ensures that
the starter kit will be usable even when new versions of WebSphere Application
Server, WebSphere Portal, or WebSphere Studio Application Developer come
out.
Note: Some modifications might still be required if the middleware is
upgraded. However, in our view the cost of modification will likely be lower
compared to the cost had we solved the problems by providing custom
libraries instead of sticking to the previously mentioned document types
coupled with functions provided by the middleware.
Project structure
The structure of the project is designed to group similar items logically. The main
groups are configurations, support tools, user interface, and WebSphere Studio
Application Developer projects. This separation is done since different people
are likely to be working with different aspects of the solution. A portlet developer
is likely to work with components inside WebSphere Studio Application
Developer’s workbench, and thus needs the component structure to be
compatible with that tool. A graphics designer, on the other hand, might use
other tools, giving another set of requirements regarding the file structure; thus
the separation of user interface and WebSphere Studio Application Developer
components. Configuration is managed on a solution global level, making
administration easier, and ensuring that all components are properly configured
for the targeted environments.
The main structure of the starter kit is shown in Table D-3.
Table D-3 Project structure

Directory name Description
conf Solution global configuration.
conf/env Environment-specific configurations.
tools Artifacts that are not considered part of the solution.
tools/bin Executables used by the automation tooling.
tools/itso-wpdsk Artifacts essential to the operation of the ITSO WebSphere Portal

development starter kit.
tools/lib Optional libraries that are needed in order to build the solution.
Used by the starter kit, but is a proposed place to store libraries
needed during build, but already available on the targeted
WebSphere Portal runtime environments.
For example: If a library is already installed into the application

extension library on the runtime server, but unavailable on the build
node, then such a library would be a likely candidate for storing in
this directory.

Directory name Description
ui The location of the user interface and layout related components.
ui/pages WebSphere Portal pages.
ui/screens WebSphere Portal screens.
ui/skins WebSphere Portal skins.
ui/templates Templates that can be copied when creating a new user interface
component.
ui/themes WebSphere Portal themes.
wsad Components developed in WebSphere Studio Application

Developer.
wsad/projects WebSphere Studio Application Developer projects.
wsad/templates Templates that can be copied when creating a new WebSphere

Studio Application Developer component.
Note: Regarding the WebSphere Studio Application Developer components,

our definition of component is roughly equivalent to WebSphere Studio
Application Developer’s use of the term project. Here we see a collision of
domain terms, as the word project has a different meaning in our domain than
it does in WebSphere Studio Application Developer.
Solution configuration
Configuration is managed on a solution level, which allows us to easily configure
the solution for deployment to new environments. It also reduces the amount of
work needed when aspects relating to the runtime environments change.
Having central configuration might in some cases incur a certain overhead when
creating new components. When developing a component, thought must be
given as to what external aspects required by the component are likely to
change. After the external aspects have been identified, the configuration step
for the component should incorporate override capability for the component
elements identified. The way we suggest for allowing override capability is to
make sure that the component is configured using plain text files, such as XML
files or property files.
The solution configuration files are stored in subdirectories of conf/env. Each

subdirectory represents a given environment, and in turn contains the actual
configuration file, which is a plain text property file in the form of a key value pair
(key=value). To avoid having to update and keep several configuration files in
sync, a form of inheritance is used. Any configuration property not defined in a
specific environment configuration file will be inherited from a base configuration.
Whenever a component’s public build target is triggered, the active configuration

is resolved as follows. If the build document was initiated with a specific target
environment specified, the property file for that environment will be read, and its
properties made active in the current execution. Otherwise the property file for
the default environment is read and its properties are made available. Next, the
base property file will be read, and any property defined in this file and not in the
former will be made available for later reference.
The starter kit currently supports two methods for configuring a component:
򐂰 Property substitution
Modifies property values in plain text property files having the format
key=value.
򐂰 Filtering
Searches for tokens in a text document such as an XML file, and replaces
predefined tokens with values specified in the solution configuration files. A
drawback of this method is that the document cannot be used until it has been
filtered, which might make this method unsuitable in certain cases.
Component structures
There is one common element, that must exist in each component directory for
the starter kit framework to function properly: A build.xml file. This is an XML
document containing various instructions that will be processed and performed
by Ant when executed from a directory containing such a file. If access control is
to be applied to the component, a file named access-control.xml should be
placed in the component’s root directory. Aside from this, the contents of the
component directories can be laid out in any way desired.
Component build file

Here we describe the elements of a component build file and how the file relates
to other assets in the starter kit framework.
All components share a common file called build.xml. This file is responsible for
performing all tasks related to building, configuring, and deploying the
component. The file is made up of a number of targets. A target is an Ant term,
and is a grouping of a set of activities / tasks that are to be performed when the
target is triggered. Targets can be dependent on other targets, which makes
them suitable for performing small specialized operations, and because of the
dependency scheme, act as entry points for operations on a larger scale as well.

For further information regarding Ant, its concepts, types, and operations, upon
which this starter kit is based, refer to the Apache Ant documentation and read at
least the sections Introduction and Using Ant.
http://ant.apache.org/manual/index.html
Note: At the time of writing, the latest version of Ant is Version 1.6.1 and the
online documentation is written for that version. WebSphere Application
Server 5.0.2 is using Ant Version 1.5.2, which means that some of the latest
features in the online version of the Ant documentation will not be available in
the version we are using. Aside from new features, Ant is backwards
compatible, so Ant-specific detail in the starter kit files should still be properly
explained in the online version of the Ant documentation.
Required targets
The starter kit requires a number of targets to be defined in any component’s
build file. The required targets are listed in Table D-4 (target being the literal
name of the target).
Table D-4 Component build targets

Target Description
clean Deletes all generated files and directories created during the building of
the component
build Builds the component
configure Allows for component-specific configuration
test Allows the component to run unittests
dist Creates a deployment unit/distributable from the built artefacts
deploy Deploys/installs the component to a target environment
undeploy Undeploys/removes the component from a target environment
init Initializes the component and allows the component to override default
properties
Component build in detail

Ant’s target dependency is the key feature making extension and modification
easy to accomplish. Dependency is what is chaining several targets together,
and we make extensive use of this feature in the starter kit. In Example D-2 a
template for a portlet application component build file is shown.
Example: D-2 Portlet Application build file
<?xml version="1.0"?>
<!DOCTYPE project [
<!ENTITY standard-init SYSTEM
"file:../../../tools/itso-wpdsk/ant/standard-init.xml">
<!ENTITY standard-portletapp SYSTEM
"file:../../../tools/itso-wpdsk/ant/standard-portletapp.xml">
]>
<project name="ComponentName" basedir="." default="default">


&standard-init;
&standard-portletapp;

<target name="init" depends="standard-init" />


<target name="configure" />
<target name="clean" depends="standard-clean"

description="Deletes all generated files and directories" />
<target name="build" depends="standard-build-portletapp"
description="Builds the component" />
<target name="test" depends="standard-test"
description="Runs unit tests" />
<target name="dist" depends="standard-dist-portletapp"
description="Generates distributable files" />
<target name="deploy" depends="standard-deploy"
description="Deploys the component to the target environment" />
<target name="undeploy" depends="standard-undeploy"
description="Removes the component from the target environment" />
</project>
Although Example D-2 on page 633 does not look like much more than a number
of declarations, it is a good example for illustrating important concepts of the
starter kit. We will go through the build file from top to bottom and explain
important concepts as we go.
Ant build files are XML documents composed of a root element named project. In
our example, project has three attributes: name, basedir and default. The
attribute name is meant to contain the name of the component. We use this

name as an input for default naming of distributables, resulting in the name
<project_name>.<extension>. In this specific case our portlet application
component distributable would be named ComponentName.war. The attribute
basedir defines the root directory during the execution, and since we have
provided a dot as the value, it means the directory the build file is located in.
Since we place the build files in the component root directories, this implicitly
means basedir will point to the component’s root directory. The last attribute
default states which target to trigger if no explicit target is provided when the
build file is invoked.
After the project declaration we reference two XML entities, which are defined at
the top of the file. These entities contain XML fragments of utility targets provided
by the starter kit. Any target having a name prefixed by standard belongs to the
starter kit framework, containing common targets which are provided for use by
component build files. These targets contain default behavior for operations
common to modules of given types, which can substantially reduce the amount
of work required when creating a new component. The first document included in
the build file, referenced as standard-init, contains targets that define the solution
global properties, as well as provide functionality that all components are likely to
make use of. The next file, referenced via the standard-portletapp entity, includes
component type specific targets useful for Portlet Application components. See
Figure D-1 on page 635 for how the standard documents relate to the various
component types.
Standard Standard
common Components specialized
EAR ear
EJB ejb
init
Library library
Portlet portlet
Figure D-1 Relationship between the component types and the standard targets
As previously mentioned, the default target for this build file is standard-default.
This target is defined in the standard-init.xml file, which can be deduced by the
standard prefix. Since we delegate the choice of what target to run by default to
the target defined in standard-init.xml, we have essentially moved this specific
configuration out of the specific component build file to a common file. This is an
example of a design choice made in order to ease maintenance, since only one
file needs changing if a decision is made to change the default target for the
solution. The point we try to highlight is that when making new component build
files, try to identify patterns of configuration and move them to a common
location for easier management.
The rest of the targets simply delegate operations to that standard

implementation by depending on such targets. When exploring the starter kit,
you will notice that there is a standard-X.xml file for each type of component
needing specialized processing, where X is a specific component type such as
portletapp or ejb.
Finally, the two non-public targets (public targets have a description attribute in
their target element) will receive some mentioning. The init target is where you
will override default properties for standard targets. The second, named
configure, will be called from standard-build targets, allowing component

developers to perform component-specific configuration, while still delegating the
build operation to the standard implementation.
Handling of component dependencies

Dependencies between components are handled explicitly by declaring what
other components a component depends on in the component’s init target. This
is done by overriding the property override.dependent.projects with the value of
one or more component names separated by the comma character. For
example, our ITSOBankWAR project depends on the ITSOBankEJB project in
order to compile. Example D-3 shows how this is declared.
Note: Many standard targets incorporate overridable properties. Each such

property is identified by the override prefix. Since all overridable properties are
too extensive to list here, please refer to the specific standard document
containing the tasks your targets depend on for the available overridable
properties.
Example: D-3 Project dependency declaration

<target name="init" depends="standard-init">
<property name="override.dependent.projects" value="ITSOBankEJB" />
</target>
Component build file invocation

The syntax for invoking a component build file is:
ant [-Dtargetenv=<tenv>] <target>
Where the argument within the square brackets is optional and will use a default
value if omitted. The value tenv is the alias for the environment the component
will be configured for and target is a public target defined in the component’s
build file. Example D-4 shows how to invoke a single target followed by multiple
ones.
Example: D-4 Component build file invocation

ant clean
ant -Dtargetenv=wpwin1 dist deploy
The first command removes any files and directories generated by a previous
call to the build or dist targets. The second command creates a deployment unit
of the component, configured for the target environment wpwin1 and deploys it to
said environment.
Solution build file
The root directory of the solution contains a build file that can be used to execute
any public target on all components of a certain type. The targets in this file refer
to groups of components by type. There is one public target for each component
type plus an additional target named all. The latter will execute a specified
component target on all components in the solution. Since each component has
its own build file, the solution build file will simply delegate the specified
component target to each component in turn. Target delegation helps keep
complexity down in the solution build file. The available public targets are shown
in Table D-5.
Table D-5 Public targets of the solution build file

Target Description
all Calls targets on ejbs, wars, ears, pages, and the solution-specific dist target
in the stated order.
ears Calls targets on Enterprise Application components.
ejbs Calls targets on Enterprise JavaBean components.
libs Calls targets on utility library components.
pages Calls targets on the pages component.
wars Calls targets on Portlet Application components.
clean Solution-specific target, will clean the solution archive created by the solution
dist target.
dist Solution specific target, creates a solution archive containing all component
deployment units/distributables available at the time of execution. Note that
this target simply packages the deployment units, it does not build them. The
reason for this is to allow the creation of a solution archive containing a set of
components for several different target environments. In that case you would
create distributables for all environments targeted and then package them
into one archive by invoking this target.
Solution build invocation

Invocation of the solution build file is in the following form:
ant [-Dtargetenv=<tenv>] [-Dtarget=<ctarget>] <starget>
Where tenv is a valid target environment as defined by having a subdirectory in

the conf/env/ directory, ctarget is the component target to execute, and starget is
the solution target. The parameters within square brackets are optional and if
omitted will revert to default values. Example D-5 on page 638 shows two
invocations of the solution build file.

Example: D-5 Solution build file invocation
ant -Dtargetenv=wpwin1 -Dtarget=dist all
ant -Dtargetenv=wpwin1 -Dtarget=deploy wars pages
The first command creates deployment units for all components configured for
the target environment wpwin1 and packages all deployment units into a solution
archive. The second command deploys only the Portlet application and Pages
components to wpwin1 (alias for WebSphere Portal node).
Note: The name wpwin1 does not actually reflect the hostname of a node, but
is an arbitrary alias as defined by having a subdirectory in conf/env. The actual
hostname of the environment containing the target node is defined within the
build.properties file contained in the alias’s directory. The reason for this is to
decouple hostnames from environments, since hostnames might change.
Another reason is that using an alias might provide more meaning for various
people about an environment than a hostname. For example, in previous
projects we used aliases like sys-test, int-test, acc-test, and prod to symbolize
the different environment types. Further, this also shields us if a node, for
example, is clustered using a deployment manager, while other environments
are not. From the development standpoint, they are all just environments with
the specifics uninteresting and shielded away.
Deployment build file

As a result of a component build, a deployment build file is created, which
supports deployment and undeployment of the specific component type. This
build file is unmodified during the build process except for filtering of a single
attribute. The filtered attribute is what will make the build file perform the proper
operations required to deploy or undeploy a component with regards to what type
of component it is responsible for. The source of the deployment file can be
found in the <build_home>\tools\itso-wpdsk\ant directory, where build_home is
the solution root directory, and the file is named
component_deployment_buildfile.xml. If you have specific requirements for
deployment not met by the default implementation, then this is the file to modify.
Building and packaging

We will show how to build and configure both components and solutions for a
specific environment in this section.
The pre-requirements for this section are:

򐂰 The solution working area has been initialized.
򐂰 An environment configuration file has been created for the target environment
and its properties set to reflect the aspects of the said environment.
To build any component, double click the init-env.bat file on the desktop,
change the directory to an arbitrary component’s directory, and invoke the dist
target of the build file:
1. Change to the directory of the component.
2. Start by cleaning any leftovers from a previous build:
ant clean
3. Invoke the distributable target of the component’s build file and specify the
alias for the target environment:
ant -Dtargetenv=<tenv> dist
The resulting distributable will end up in a newly created directory called dist in
the component’s directory. All intermediate files created during the build phase
are located in a directory called build.
Invoking targets on a solution is similar to that of a component. To build the entire

solution, double click the init-env.bat file on the desktop, change the directory to
the root directory of the solution working area, and invoke the dist target of the
build file. For example:
1. Change to the solution root directory.
2. Start by cleaning any leftovers from a previous build:
ant -Dtarget=clean all
3. Invoke the distributable target of the various component build files and specify
the alias for the target environment:
ant -Dtargetenv=<tenv> -Dtarget=dist all
The distributable for the solution is the solution archive, which is contained in a
newly created directory called dist. The solution archive comprises the contents
of all components’ dist directories. This archive can be moved to other
WebSphere Portal nodes for deployment.
Tip: To see what public targets are defined in a build file, change to the
directory containing the build file you are interested in and issue the
command:
ant -projecthelp
This command also lists further details about the build file, such as optional
arguments when invoking it, provided that information has been included in
the build file’s project description element.

Deployment
During the deployment phase, our entire knowledge of the target environment is
comprised of the information contained in the targeted environment’s property
file, or what we provide on the command line when invoking the deployment or
undeployment targets. It is therefore essential that the information contained in
the build.properties files are accurate. There is, however, one type of information
we have selected not to include in the environment property files, principals and
credentials for accounts, since this kind of information is sensitive and nothing
we would like to have in a version control system. We therefore only declare the
location where a file containing principals and credentials can be found. We
have, however, added a sample credentials file to the directory conf/env/base/ in
order to give an example of such a file.
In order to deploy any component to WebSphere Portal you need to make

available valid credentials for xmlaccess by ensuring that one of the following is
true:
1. The property credentials.file in the file conf\env\base\build.properties points to
a credentials file containing valid xmlaccess credentials for the target
environment.
2. You have created a subdirectory of c:\6325sol\conf\env containing a
build.properties file for your target environmet. The build.properties file has to
declare the credentails.file property to point to a valid credentials file (refer to
conf\env\base\credentials.properties for an example file).
Deployment and undeployment are both performed by issuing a single

command. In the case where remote deployment is not possible, such as if the
WebSphere Portal environment is located in a restricted zone, the solution
archive must be transferred to the target environment before invoking either the
deploy or undeploy targets. Since a solution archive has the potential of
containing all components and elements making up the solution, only parts of the
archive are likely to be deployed to a given host, unless all nodes the deployment
units are to deployed to are located on the same host.
Deploying from build host

To deploy a component from the same host the component was built on, do as
follows:
1. Open an initialized console window by double clicking the init-env.bat file on
the desktop.
2. Change to the component’s dist directory.
3. Instruct the deployment unit to deploy to a specified target environment:
ant -Dtargetenv=<tenv> deploy
Removing/undeploying the component from the target runtime environment is
performed using the same steps as above, but instead of specifying the deploy
target in step 3, specify undeploy.
To deploy on a solution level from the same host the solution was built on, do as
follows:
1. Open an initialized console window by double clicking the init-env.bat file on
the desktop.
3. Instruct the solution to deploy one or more sets of component types to a
specified target environment:
ant -Dtargetenv=<tenv> -Dtarget=deploy <ctype> [<ctypes..>]
Where tenv is the target environment alias, ctype is the type of components to
deploy, and the ctypes within square brackets are optional additional component
types to deploy.
Undeployment of the deployed component types is performed using the same

three steps, except substituting deploy for undeploy in the third step.
Deploying from the target host

Deployment of a component from a host other than the one the components
were built on is performed as follows:
1. Copy the solution archive to a directory on the host from which deployment
will occur.
2. Extract the solution archive to a directory.
3. Open a console window.
4. Change to the dist directory of the component you wish to deploy.
5. Deploy the component:
<was_home>\bin\ws_ant -Dtargetenv=<tenv> deploy
Removing/undeploying the component from the target runtime environment is

performed using the same steps as above, but instead of specifying the deploy
target in step 3, specify undeploy.
To deploy parts of a solution from a host other than the one the components
were built on is performed as follows:
1. Copy the solution archive to a directory on the host from which deployment
will occurr.
2. Extract the solution archive to a directory.

3. Open a console window.
5. Instruct the solution to deploy one or more sets of component types to a
specified target environment:
<was_home>\bin\ws_ant -Dtargetenv=<tenv> -Dtarget=deploy <ctype>
[<ctypes..>]
Where tenv is the target environment alias, ctype is the type of components to
deploy, and the ctypes within square brackets are optional additional component
types to deploy.
Undeployment of the deployed component types is performed using the same

three steps with the target deploy substituted for undeploy in the third step.
Note: During deployment or undeployment there are no requirements to have

a proper solution working area set up or environment variables initialized,
since all required configuration details are bundled with the deployment units.
The source of this configuration data originally comes from the
<build_home>/conf/env/ directories of the solution working area, where the
deployment units and solution archive was created.
wpdsk-util command reference

The wpdsk-util command is a utility that is meant to simplify complex and/or
error-prone activities, such as working with pages. The syntax for invoking the
command is:
wpdsk-util [OPTIONS] SUB_COMMAND
The available sub-commands are export-pages and export-portlet-access.

export-pages extracts all pages from a given page root from the WebSphere
Portal configuration together with their assigned access controls. The output
consists of two XML documents. The first document contains page definitions of
the specified page root and all descending pages in the page hierarchy.
Additionally, in the document are references to portlets available in the exported
pages. References to pages outside the exported page tree are also made
available. The pages, referenced pages, and referenced portlets are grouped
into sections in the document, to make it easier to work with different aspects of
custom pages. The second document being created contains the access control
configuration for the pages. The two files are intended to be renamed to
pages.xml and access-control.xml, respectively, and will be used when
packaging and deploying the pages component.
The export-portlet-access subcommand extracts access control configuration for
a portlet application and stores that information in an XML document. This
document is intended to be renamed access-control.xml and stored in the portlet
application component’s root directory. The access control will be applied during
the deployment of the component if available when the deploy target is invoked.
The available options for the command are shown in Table D-6. If the
sub-command is omitted, a usage description will be shown.
Table D-6 wpdsk-util command syntax options

Sub-command Option Description
export-pages -Dexport.pageroot The unique name of the root page in the

WebSphere Portal page hierarchy from
which export will begin.
Default value: wps.My Portal
-Dtargetenv The targeted environment alias.
Default value: the current environment
export-portlet-access -Dtargetenv The targeted environment alias.
Default value: the current environment

E
Appendix E. Node descriptions for

architecture models
This appendix is a supplement to Chapter 3, “Architecture and topology
selection” on page 51. The appendex includes detailed descriptions for the
conceptual model, specified model, and phycial model nodes, for both the secure
portal runtime environment and development environment.
The appendix is organized into the following sections:

򐂰 Conceptual model node description for the runtime environment
򐂰 Specified model node description for the runtime environment
򐂰 Conceptual model node descriptions for development
򐂰 Specified model node description for development and test environment

Conceptual model node description for the runtime
environment
The following tables describe the conceptual nodes in detail.
򐂰 Load Balancer node (see Table E-1)
򐂰 Reverse Proxy node (see Table E-2 on page 647)
򐂰 Caching Proxy node (see Table E-3 on page 648)
򐂰 Portal Server node (see Table E-4 on page 649)
򐂰 Directory node (see Table E-5 on page 649)
򐂰 Data Server node (see Table E-6 on page 650)
򐂰 Web Server node (see Table E-7 on page 651)
򐂰 App Server node (see Table E-8 on page 652)
򐂰 Policy Server node (see Table E-9 on page 653)
򐂰 Collaboration node (see Table E-10 on page 654)
򐂰 Instant Messaging node (see Table E-11 on page 654)
򐂰 Portal Development node (see Table E-12 on page 655)
Table E-1 Conceptual Load Balancer node

Subject Conceptual node: Load Balancer
Description A process that supports the distribution of e-business

requests to a cluster of servers.
General The load-balancing component provides a scalable solution

for distributing and routing HTTP, servlet, and Enterprise
JavaBean™ (EJB) requests. As the load on one server or a
cluster of servers with similar content increases, the Load
Balancer can redirect this incoming traffic to under-used
servers to help maintain optimal response times for each
site visitor. Incoming user requests are routed to back-end
servers depending on their availability, performance, and on
the relevance of the application or components they host.
Users and presentation The administration client is handled through a Java-based

GUI or command line interface.
Performance and The non-functional requirements and volumetric must be

capacity handled by this node. The disk capacity and caching
configuration ensure reaching the transaction rate for the
average/peak transaction rate according to the number of
customers.
Availability 24x7.
Cost and benefit N/A.
Security SSL software support. In case of performance problems,

hardware encryption components can be added.
Subject Conceptual node: Load Balancer
Risk It is mission critical since it serves all customer requests

accessing the site. For high availability a hot-standby Load
Balancer is recommended.
Node management Follows the management standards for remote

management, recovery time, problem management,
software distribution, and configuration management.
Table E-2 Conceptual Reverse Proxy node

Subject Conceptual node: Reverse Proxy
Description A process that supports the use and management of Web

pages and other Internet-related material.
General This node is a high-performance, multi-threaded Reverse

Proxy, front-end for back-end Web services that applies a
security policy to a protected object space (which is defined
in the authorization database). The Reverse Proxy can
provide single sign-on solutions and incorporate back-end
Web application server resources into its security policy.
Being implemented on an HTTP server foundation, it listens
to the typical HTTP and HTTPS ports.
Users and presentation The administration client is browser based to configure the
settings.
In addition, command line tools are available.
Performance and The nonfunctional requirements and volumetric must be

customers.
Availability 24x7.


accessing the site. Ability to cluster for load
balancing/failover.
Node management Follows the node management standards for remote

Appendix E. Node descriptions for architecture models 647

Table E-3 Conceptual Caching Proxy node
Subject Conceptual node: Caching Proxy

General The caching proxy capability improves response time by off

loading back-end servers and peering links. The caching
proxy caches static content and can also cache—and
invalidate—dynamically generated content from the
applications server, such as JSP™ and servlet results to
create a virtual extension of the application server cache
into network-based caches. The caching proxy also
provides the following plug-in support:
򐂰 A Tivoli Access Manager plug-in
򐂰 A plug-in that allows users to exploit an LDAP-based
repository for storing user authentication and
authorization information
򐂰 An authentication/authorization plug-in that allows
independent software vendors (ISVs) to exploit
third-party authentication/authorization mechanisms
such as RADIUS or SecurID tokens
Users and presentation Support command line tools.

customers.
Availability 24x7.
Cost and Benefit N/A.

The node access is defined by the security policies. There
is a well-defined relationship between Web Server nodes
and App Server nodes.

accessing the site. Ability to cluster for performance/failover.
Node Management Follows the node management standards for remote

Table E-4 Conceptual Portal Server node
Subject Conceptual node: Portal Server
Description A process that supports the use and management of

multi-channel e-business information such as Web pages
and other Internet-related material.
General The responsibilities of the Portal Server node include

receiving and serving HTTP/HTTPS requests from the
browser client. It encompasses integration services that
give you access to enterprise data, applications, and Web
services.
Users and presentation This node serves customers and administrators. The
presentation services are only browser based.
Performance and The nonfunctional requirements and volumetric must be

customers.
Availability 24x7.

There is a well-defined relationship between Portal Server
nodes, Directory nodes, and back-end applications.

accessing the site.

Table E-5 Conceptual Directory node

Subject Conceptual node: Directory
Description The Directory node is a centralized, enterprise-wide

directory structure optimized for the rapid retrieval of search
results. It normally provides a separate multi-tier user
administration function for updating the directory.

General Lightweight Directory Access Protocol (LDAP) refers to the

protocol that is used to communicate from a calling program
and a Directory node. Information is kept on the
LDAP-based directory node about such topics as people
and/or services. For example, the directory could be used to
store information needed to identify registered shoppers
(referred to as authentication). It could also be used to store
information about what functions those shoppers are
allowed to perform after being identified (referred to as
authorization).
Directory nodes are classified as a master or a replica.
directory settings. LDAP entries are managed using
command line tools or a browser.

customers.
Availability 24x7.
Security SSL is strictly enforced, and maintenance access to the

directory server runtime is granted based on the security
policy definitions.
Risk Mission critical.

Table E-6 Conceptual Data Server node

Subject Conceptual node: Data Server
Description The Data Server node's function is to provide persistent

data storage and retrieval in support of the user-to-business
transactional interaction. The data stored is relevant to the
specific business interaction, for example, bank balance,
insurance information, current purchase by the user, etc.
General It is important to note that the mode of database access is

perhaps the most important factor determining the
performance of this Web application, in all but the simplest
cases. One approach is to collapse the database accesses
into a single call or very few calls. This can be achieved via
coding and invoking Java stored procedure calls on the
database.
Users and presentation Administration facilities are Java-based GUIs, or using the
command line facilities.

average/peak transaction rate.
Availability 24x7.
Security Access to the data server runtime is granted based on the

security policy definitions.
Risk Mission critical.

Table E-7 Conceptual Web Server node

Subject Conceptual node: Web Server

General The responsibilities of the Web server node include

browser client.

customers.
Availability 24x7.

Subject Conceptual node: Web Server
Cost and Benefit N/A.


accessing the site. Ability for clustering for
performance/failover.

Table E-8 Conceptual Application Server node

Subject Conceptual node: Application Server
Description This node provides the infrastructure for application logic

and may be part of a Portal Server node. It is capable of
running both presentation and business logic, but generally
does not serve HTTP requests. When used with a Web
server redirector, the Application Server node will run both
presentation and business logic. In other situations, it may
be used for business logic only.
General The responsibilities of the Application Server include

receiving requests from the clients, selecting and executing
the appropriate business logic based on these requests,
coordinating with external services (for example, the LDAP
directory) to retrieve data and execute external applications,
and finally formulating the response and dispatching it back
to the client. To meet these requirements, the application
servers provide a range of dynamic page construction,
business logic processing, data access, external application
integration, session management, load balancing, and
fail-over services.
Users and presentation The administration client provides a Java-based GUI to

administer the Application Server node.

customers.
Availability 24x7.
Subject Conceptual node: Application Server
Security SSL is strictly enforced and maintenance access to the App

Server runtime is granted based on the security policy
definitions.
User access is authenticated against the Directory node.
Risk It is mission critical and serves presentation and business

logic of customer requests. Ability for clustering to support
performance/failover.

Table E-9 Conceptual Policy Server node

Subject Conceptual node: Policy Server
Description Provides end-to-end security for e-business, including Web

single sign-on, distributed Web-based administration, and
policy-based security.
General The Policy Server node integrates with e-business

applications out-of-the-box to deliver a secure, unified, and
personalized e-business experience. By providing
authentication and authorization APIs and integration with
application platforms such as J2EE™, it helps you secure
access to business-critical applications and data spread
across the extended enterprise.
Delivers unified authentication and authorization for
e-business initiatives as you secure a single enterprise or a
federated environment. Supports single sign-on that
encompasses Web, Microsoft, telnet and mainframe
application environments.
Users and presentation Browser-based administration services. In addition,

command line tools are available.

capacity handled by this node.
Availability 24x7.
Security SSL is strictly enforced in compliance with the security

policy.
Risk Mission critical since all security-related services are

handled.


Table E-10 Conceptual Collaboration node

Subject Conceptual node: Collaboration
Description In e-business collaboration scenarios, the collaboration

node provides a convenient place for supply chain members
to collaborate on process improvements, troubleshooting,
etc.
General On the demand side, it supports contract negotiations.

Whatever the task at hand, it increases efficiency, makes it
much easier for teams to collaborate across organizational
boundaries, and enables the capture and reuse of best
practices in dealing with suppliers, partners, and customers
alike.
Users and presentation Browser-based administration services. Customers can

access collaboration services using a browser.

Availability 24x7.

policy.
Risk Mission critical since business resellers are using the

collaboration feature for negotiations.

Table E-11 Conceptual Instant Messaging node

Subject Conceptual node: Instant Messaging
Description The Instant Messaging node provides real-time

collaboration product for business, offering a customizable,
standards-based platform for instant awareness, real-time
communication (chat), and online meetings with application
sharing and white-boarding capabilities.
Subject Conceptual node: Instant Messaging
General Awareness is the focal point of the instant messaging node.

First, it enables members of the online community to know
who else is using the e-business collaboration
environment—coworkers, partners, or customers. It then
helps partners communicate in a variety of ways, from
one-on-one instant messages to ad hoc virtual meetings. It
also enables users to share live documents, applications,
and a white board; for example, a seller can share a
spreadsheet with a buyer, and the only application the
buyer needs on her computer is a Java-aware Web
browser.
Users and presentation Browser-based administration services. Customers can

access instant messaging services using a browser.

Availability Business hours from 08:00 a.m. - 5.00 p.m.
Cost and benefit The network must handle the additional traffic and data
volume for instant messaging streaming.
Security SSL is strictly enforced. The node extends the internal

instant messaging capabilities, requiring further port and
firewall settings.
Risk Critical for collaboration.

Table E-12 Conceptual Portal Development node

Subject Conceptual node: Portal Development
Description The Portal Development node provides the infrastructure

and services to develop, test, and debug portal applications.
General The responsibilities of the Portal Development node include

maintaining source code for portal assets (HTML, JSP,
code, portlets, data assets), testing and debugging
applications, repository management, etc.
Users and presentation It serves portal developers and provides an integrated

workbench for Java code and front-end design.

Subject Conceptual node: Portal Development
Performance and Performance requirements demand a powerful developer

capacity workstation with at least 1 GB of memory. Disk capacity can
handle the necessary software components and data
volume.
Availability Business hours from 08:00 a.m. - 7:00 p.m.
Security None.
Risk N/A.

Specified model node description for the runtime

environment
The naming conventions for the specified nodes are listed below:
򐂰 S indicates it is a node of the specified operational model.
internal development zone within the Intranet, or the management zone.
򐂰 An abbreviation for the service, for example, TAM stands for Tivoli Access
Manager.
The node interaction matrix is shown in Table E-13 on page 656. It describes the
relationship of specified nodes with their characteristics, for example, which type
communication protocol is used.
Table E-13 Node interaction matrix

User SELB HTTP (80), HTTPS (443)
SELB SERP1,SERP2 HTTP (80), HTTPS (443)
SERP1,SERP2 SECP1,SECP2 HTTP (80), HTTPS (443)
SERP1,SERP2 SPLDAPR LDAPS(636)
SERP1,SERP2 SMTAM TAM_SSL(7135)
SECP1,SECP2 SPPORTAL HTTP (80), HTTPS (443)
SPPORTAL SPHTTPD HTTP(80), HTTPS(443)
SPHTTPD SPBANK HTTP(80), HTTPS(443)
SPPORTAL SPDOMINO HTTP(80), HTTPS(443)
SPPORTAL SPSAMETIME HTTP(80), HTTPS(443)
SPPORTAL,SPDOMIN SPLDAPR LDAPS(636)

O,SPSAMETIME
SPLDAPR,SPPORTAL, SPDB Database client/server

SPBANK connection ports
SMLDAP SPLDAPR LDAPS(636)
SMLDAP,SMWAS2,SM SMDB Database client/server

WAS1 connection ports
SMTAM SMLDAP LDAPS(636)
SIDEVELOP SPPORTAL FTP(21)
Table E-14 Specified SELB node

Subject Specified node: SELB (Load Balancer)
Description This node serves e-business requests of the site to

distribute the load across a cluster of servers.
Presentation function The administration services are Java based.
Processing function Dispatches HTTP requests to the cluster of servers.
Data Logs requests on the local file system and in memory.

24x7.
Infrastructure Ethernet access with at least 100 Mbps LAN.
Presentation services None.
Processing services 128-bit SSL encryption.
Data services None.

Subject Specified node: SELB (Load Balancer)
Hardware Productive server profile. For scalability reasons the

hardware must support up to two processors.
Operating system Multi-tasking multi-processor operating system.
Connections Based on TCP/IP serving HTTP and HTTPS requests.

Access to file system using native operating services.
Management Tivoli systems management software 4.x or later.
Table E-15 Specified SERP1 and SERP2 node

Subject Specified node: SERP1, SERP2 (Reverse Proxy)
Description This node serves security aspects to enforce defined

policies.
Presentation function The administration services are command-line based.
Processing function Analyzes the HTTP/HTTPS request in order to enforce

authentication and authorization tasks defined by the
security policies.
Data Logs requests on the local file system. Serves up to 1000

concurrent users per hour.
24x7.
Data services Handles <= 2000 connections.
Hardware Productive server profile. For scalability reasons, the

hardware must support up to two processors.
Operating system Supports <= 512 threads. Multi-tasking multi-processor

operating system.

Table E-16 Specified SECP1 and SECP2 node
Subject Specified node: SECP1 and SECP2 (Caching Proxy)
Description This node caches the HTML responses to increase the

overall performance.
Processing function Analyzes the HTTP/HTTPS request in order to return

cached data. It reduces the amount of back-end processing
if data is properly cached.
Data Logs requests on the local file system. Serves up to 1000

concurrent users per hour.
24x7.
Data services N/A.
Hardware Productive server profile.

Table E-17 Specified SPPORTAL node

Subject Specified node: SPPORTAL (Portal Server)
Description This node serves portal requests and renders the client
page. It supports multi-channel access serving HTML and
WAP WML clients.
24x7.
Presentation function Browser-based configuration and administration.

Application server services are managed through a Web
Client.
Processing function Processes HTTP request from an HTML or WAP WML

capable client browser. Multi-threading services to share the
load of serving customer requests.
Based on J2EE open standards including Web services.

Subject Specified node: SPPORTAL (Portal Server)
Data Logs application server relevant data on the local file

system.
Uses database repository to maintain application server
configuration.
Presentation services Supports JavaServer Pages, WML and HTML.
Processing services Rendering engine to generate markup language for HTML

and WML. J2EE-compliant runtime environment leveraging
Java services.
WebSphere Portal Enable/Extend.
Data services JDBC driver to access database-relevant information.

Handles data as defined by the nonfunctional requirements.

Access to file system using Java services.
JDBC driver from database vendor.
Table E-18 Specified SPHTTPD node

Subject Specified node: SPHTTPD (Web Server)
Description This node serves banking requests only.
Presentation function The administration services are browser-based leveraging

HTML and java applets.
Processing function Runs 100 or more HTTP services to serve HTTP requests.
Delivers HTTP response streams.
Data Logs HTTP requests on the local file system. Serves up to

3000 concurrent users per hour.
24x7.
Processing services IBM HTTP Web server required to handle HTTP requests.
128-bit SSL encryption.
Subject Specified node: SPHTTPD (Web Server)

hardware must support up to four processors.

operating system.

Table E-19 Specified SPBANK node

Subject Specified node: SPBANK (App Server)
Description This node serves banking requests and renders the client
page.
24x7.
Processing function Processes HTTP request from a HTML capable client

browser. Multi-threading services to share the load of
serving customer requests.

system.
configuration.
Store information and data assets are kept in the commerce
database.
Presentation services Supports JavaServer Pages and HTML.
Processing services Generates markup language for HTML and XML. J2EE
runtime environment leveraging Java services.



Subject Specified node: SPBANK (App Server)
Table E-20 Specified SPLDAPR node

Subject Specified node: SPLDAPR (Directory)
Description This node serves the enterprise replica-directory.

24x7.

Directory entities are managed through LDAP
synchronisation.
Processing function Processes LDAP and LDAP requests. Multi-threading

services to share the load of serving directory requests.
Based on J2EE and open standards.
Data Logs directory-relevant data on the local file system.

Uses database repository to maintain directory
configuration.
Processing services Serves LDAP and LDAPS V3.0 requests.

Connections Based on TCP/IP serving LDAP, and LDAPS requests.

Database native clients.
Table E-21 Specified SPDB node

Subject Specified node: SPDB (Data Server)
Description This node is the data store for the enterprise applications
including the portal, bank application and directories. The
directory entities are optimized for read access.
24x7.
Presentation function None.
Subject Specified node: SPDB (Data Server)
Processing function Is able to serve 10000 directory database requests per hour.
Database provides performance optimizations to handle the
load.
Data Use of native relational database technology.

Optimized hard disk access.
Processing services Relational database supporting SQL.
Data services JDBC support. Database is able to handle 80 concurrent

connections and provides stored procedures.
Connections Based on TCP/IP.

Native database driver from database vendor including
JDBC support.
Table E-22 Specified SPDOMINO node

Subject Specified node: SPDOMINO (Collaboration)
Description This node serves collaboration requests.

24x7.
Presentation function Lotus Domino base services.
Processing function Lotus Domino base services.
Data Lotus Domino base data.
Presentation services See Lotus Domino.
Processing services Lotus Domino base services.
Data services Requires Lotus Domino Notes.

Subject Specified node: SPDOMINO (Collaboration)

Lotus Domino Notes specific extensions.
Table E-23 Specified SPSAMETIME node

Subject Specified node: SPSAMETIME (Instant Messaging)
Description This node serves instant messaging requests.

08:00 - 18:00
Presentation function Lotus Sametime® base services.
Processing function Lotus Sametime base services.
Data Lotus Sametime base data.
Presentation services See Lotus Sametime.
Processing services Lotus Sametime base services.
Data services Requires Lotus Domino Notes.
Operating system Multitasking multi-processor operating system.

Lotus Domino Notes specific extensions.
Table E-24 Specified SMTAM node

Subject Specified node: SMTAM (Policy Server)
Description This node serves the security service requests from the
Reverse Proxy nodes and the app server nodes.
24x7.
Processing function Processes Security API-request from capable clients.

Multi-threading services to share the load of serving
customer requests.
Support of open standards including J2EE.
Subject Specified node: SMTAM (Policy Server)
Data Logs server-relevant data on the local file system.

Store information and data assets are kept in the directory
database.
Processing services Runtime environment supports Java and native operating

systems as well as native programming languages.
Data services LDAP driver to access directory-relevant information.


Table E-25 Specified SMHTTP1 node

Subject Specified node: SMHTTP1 (Web Server)
Description This node serves the policy server administration requests

only.

HTML.
Processing function Delivers HTTP response streams.
Data Logs HTTP requests on the local file system.


Table E-26 Specified SMWAS1 node

Subject Specified node: SMWAS1 (Application Server)
Description This node serves the policy server administration client

request only.
24x7.


system.
configuration.
database.


Table E-27 Specified SMHTTP2 node
Description This node serves the directory administration requests only.

HTML.
Processing function Delivers HTTP response streams.
Data Logs HTTP requests on the local file system.

Table E-28 Specified SMWAS2 node

Description This node serves the directory server administration client

request only.
24x7.


system.
configuration.
database.



Table E-29 Specified SMLDAP node

Subject Specified node: SMLDAP (Directory)
Description This node serves the enterprise directory.

24x7.

Directory entities are managed through LDAP
synchronisation for the replica nodes.

Based on J2EE and open standards.
Data Logs directory relevant data on the local file system.

configuration.
Infrastructure Ethernet access with at least 100 Mbps LAN
Data services JDBC driver to access database relevant information.

Subject Specified node: SMLDAP (Directory)

Table E-30 Specified SMDB node

Subject Specified node: SMDB (Data Server)
Description This node is the master data store for the enterprise
directory.
24x7.
Processing function Is able to serve 10000 directory database requests per hour.
Database provides performance optimizations to handle the
load.


Directory synchronisation with replicas.

Operating system Multitasking multi-processor operating system.

JDBC support
Table E-31 Specified SIDEVELOP node

Subject Specified node: SIDEVELOP (Portal Development)
Description This node serves the requirements to develop portal

applications.
08:00 - 18:00

Subject Specified node: SIDEVELOP (Portal Development)
Presentation function See WebSphere Studio Application Developer.
Processing function See WebSphere Studio Application Developer.

See WebSphere Portal Enable/Extend.

Presentation services See WebSphere Studio Application Developer.
Processing services WebSphere Studio Application Developer.

WebSphere Portal Enable/Extend
DB2.
Data services JDBC support.

See WebSphere Studio Application Developer.
Hardware Developer workstation profile.

JDBC support.
Conceptual model node descriptions for development

The following tables describe the conceptual nodes in detail.
򐂰 Repository node (see Table E-32)
򐂰 Development node (see Table E-38 on page 676)
Table E-32 Conceptual Repository node

Subject Conceptual node: Repository
Description A process that offers version control for development

assets.
Subject Conceptual node: Repository
General 򐂰 Enables parallel development.

򐂰 Provides workspace management including dynamic
view support.
򐂰 Uses Unified Change Management—the configurable,
activity-based process for managing change.
򐂰 Scales from medium to large team with extensive
platform support including Windows, Linux and UNIX.
򐂰 Provides advanced build management and auditing,
including build management for mainframe
applications.
򐂰 Provides options for geographically distributed teams.
򐂰 Integrates with leading Integrated Development
Environments
Users and presentation The administration is command-line based.

developers.
Availability 7:00 a.m. - 10:00 p.m.
Security SSL support for remote access accross geographically

distributed teams.
Risk It is mission critical from a developers perspective since it

serves all developer requests accessing the assets.
Node management Follows the management standards for remote

Table E-33 Conceptual Reverse Proxy node



General This node is a high-performance, multi-threaded Reverse

Proxy, front-ending back-end Web services that applies a
security policy to a protected object space (which is defined
in the authorization database). The Reverse Proxy can
provide single sign-on solutions and incorporate back-end
Web application server resources into its security policy.
Being implemented on an HTTP server foundation, it listens
to the typical HTTP and HTTPS ports.
It can be configured such that a set of junctions are defined
for each developer to enable a testbed
settings.
In addition, command line tools are available.

customers.
Security SSL software support for testing purposes.
Risk It is critical since it serves all developer requests accessing

the to be tested secure portal solution.

Table E-34 Conceptual Portal Server node

Description A process that supports the use and management of

multi-channel e-business information such as Web pages
and other Internet-related material.
General The responsibilities of the Portal Server node include

browser client. It encompasses integration services that
give you access to enterprise data, applications, and Web
services.

customers.
Security SSL software support.

There is a well-defined relationship between Portal Server
nodes, Directory nodes, and back-end applications.
Risk It is critical since it serves all developer requests accessing

the site.

Table E-35 Conceptual Directory node

Description The Directory node is a centralized, developer-wide

directory structure optimized for the rapid retrieval of search
results. It normally provides a separate multi-tier user
administration function for updating the directory.
General Lightweight Directory Access Protocol (LDAP) refers to the

protocol that is used to communicate from a calling program
and a Directory node. Information is kept on the
LDAP-based directory node about such topics as people
and/or services. For example, the directory could be used to
store information needed to identify registered customers
(referred to as authentication). It could also be used to store
information about what functions those customers are
allowed to perform after being identified (referred to as
authorization).
directory settings. LDAP entries are managed using
command line tools or a browser.


customers.
Security SSL is enforced and maintenance access to the directory

server runtime is granted based on the security policy
definitions.
Risk Critical.

Table E-36 Conceptual Data Server node

Description The Data Server node's function is to provide persistent

data storage and retrieval in support of the user-to-business
transactional interaction. The data stored is relevant to the
specific business interaction, for example, bank balance,
insurance information, current purchase by the user, etc.
General It is important to note that the mode of database access is

perhaps the most important factor determining the
performance of this Web application in all but the simplest
cases.
Users and presentation Administration facilities are Java-based GUIs or using the
command-line facilities.

average/peak transaction rate.
Security Access to the data server runtime is granted based on the

security policy definitions.
Risk Critical.

Table E-37 Conceptual Policy Server node

Description Provides end-to-end security for e-business, including Web

single sign-on, distributed Web-based administration, and
policy-based security.
General The Policy Server node integrates with e-business

applications out-of-the-box to deliver a secure, unified and
personalized e-business experience. By providing
authentication and authorization APIs and integration with
application platforms such as J2EE™, it helps you secure
access to business-critical applications and data spread
across the extended enterprise. Delivers unified
authentication and authorization for e-business initiatives as
you secure a single enterprise or a federated environment.
Supports single sign-on that encompasses Web, Microsoft,
telnet and mainframe application environments.
Users and presentation Browser-based administration services. In addition,

command line tools are available.


policy.
Risk Mission critical since all security-related services are

handled.


Table E-38 Conceptual Development node
Subject Conceptual node: Development
Description The Development node provides the infrastructure and

services to develop, test, and debug WebSphere Portal
applications.
General The responsibilities of the Development node include

maintaining source code for Portal assets (HTML, JSP,
code, portlets, data assets), testing and debugging
applications, repository management, etc.
Users and presentation It serves portal developers and provides an integrated

workbench for Java code and front-end design.
Performance and Performance requirements demand a powerful developer

capacity workstation with at least 1 GB of memory. Disk capacity can
handle the necessary software components and data
volume.
Security None.
Risk N/A.

Specified model node description for development and

test environment
The following tables describe the specified nodes in detail.
򐂰 Repository node (see Table E-39 on page 677)
򐂰 Development node (see Table E-45 on page 681)
Table E-39 Specified SDREP
Subject Specified node: SDREP (Repository)
Description This node serves source code management and change

management processes across development, testing, and
integration purposes. The change management process
especially is in an integral part.
Presentation function The administration services are command line based. As an

option a garphical user interface is available.
Processing function Processes check-in/check-out requests of assets. In

addition, it supports change management processes for a
full life-cycle development.
Data Logs requests on the local file system.
Processing services 128-bit SSL encryption for multi-site access via the Internet.
Data services Handles <= 20 connections in a developer environment.

hardware should support up to two processors.

operating system.

Table E-40 Specified SDRP

Subject Specified node: SDRP (Reverse Proxy)
Description This node serves security aspects to enforce defined

policies.
Processing function Analyzes the HTTP/HTTPS request in order to enforce

authentication and authorization tasks defined by the
security policies. Each developer is assigned a unique
junction name for testing purposes. In a test environment
one junction exists for ntegration tests.
Data Logs requests on the local file system.

Subject Specified node: SDRP (Reverse Proxy)

hardware should support up to two processors.

operating system.

Table E-41 Specified SDPORTAL node

Subject Specified node: SDPORTAL (Portal Server)
Description This node serves portal requests and renders the client
page. It supports multi-channel access serving HTML and
WAP WML clients. In a developer environment each
developer has a local instance, while in a test environment
they share a single instance.

Application server services are managed through a Web
Client.
Processing function Processes HTTP requests from an HTML or WAP WML

capable client browser. Multi-threading services to share the
load of serving customer requests.

system.
configuration.
Presentation services Supports JavaServer Pages, WML and HTML.
Subject Specified node: SDPORTAL (Portal Server)
Processing services Rendering engine to generate markup language for HTML

and WML. J2EE-compliant runtime environment leveraging
Java services.
WebSphere Portal Enable/Extend.

Handles data as defined by the non-functional
requirements.

Table E-42 Specified SDLDAP node

Subject Specified node: SDLDAP (Directory)
Description This node serves the development and test enterprise

directory, which contains a representative subset of the
enterprise directory.
Presentation function Browser-based configuration and administration. In

addition, all modifications are script based using
command-line tools.

Data Logs directory-relevant data on the local file system.

configuration.
Data services Database driver to access database-relevant information.

requirements.

Subject Specified node: SDLDAP (Directory)

Table E-43 Specified SDDB node

Subject Specified node: SDDB (Data Server)
Description This node is the data store for the enterprise applications
including the portal, bank application and directories.
Processing function Is able to serve the amount of directory database requests

per hour. Database provides performance optimizations to
handle the load.


requirements.

JDBC support.
Table E-44 Specified SDTAM node

Subject Specified node: SDTAM (Policy Server)
Description This node serves the security requests from the Reverse
Proxy nodes and the Portal Server nodes.
Presentation function Browser-based configuration and administration. Command

line tools are used to modify configuration data.
Subject Specified node: SDTAM (Policy Server)
Processing function Processes Security API-request from capable clients.

Multi-threading services to share the load of serving
customer requests.
Support of open standards including J2EE.
Data Logs server relevant data on the local file system.

Store information and data assets are kept in the directory
database.
Processing services Runtime environment supports Java and native operating

systems as well as native programming languages.
Data services LDAP driver to access directory-relevant information.

requirements.
Table E-45 Specified SDWB

Subject Specified node: SDWB (Development)
Description This node represents the developer’s workbench to

develop, deploy, and unit-test a secure portal application. It
provides an embedded test-environment.
Presentation function Java-based GUI supporting J2EE application development.

plug-ins to access the repository services to
check-out/check-in development assets.
Processing function Integrated test environment with debug and browsing

capabilities.
Data N/A.
Presentation services J2EE runtime.
Processing services N/A.

Subject Specified node: SDWB (Development)
Data services N/A.
Hardware Developer workstation profile. For performance reasons,

the hardware should provide >= 1 GB or memory.
Operating System Multi-tasking multi-processor operating system.
Connections Access to file system using native operating services.
Management N/A.
F
Appendix F. Additional material

This redbook refers to additional material that can be downloaded from the
Internet as described below.
Locating the Web material

The Web material associated with this redbook is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser to:
Alternatively, you can go to the IBM Redbooks Web site at:

ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the redbook form number, SG246325.
Using the Web material

The additional Web material that accompanies this redbook includes the
following files:
File name Description
6325code.zip Secure Portal Solution sample code

System requirements for downloading the Web material
The following system configuration is recommended:
Hard disk space: 5 MB minimum
Operating System: Windows/UNIX
Processor: 1 GHz PIII or higher
Memory: 1 GB per node (two nodes needed)
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the
Web material zip file into this folder. For example, unzip 6325code to the
Description of sample code

The ITSO sample code and configuration files developed for the ITSO working
example secure portal can be found in the 6325code.zip file. Table F-1 provides
a description of the assets included in the 6325code.zip.
Table F-1 Redbook sample code contents

File name or directory Description
c:\6325code Root directory of redbook sample configuration files and sample code.
c:\6325code\config Secure portal solution configuration files used during the installation
and configuration chapters to se tup the runtime environment.
c:\6325code\deploy ITSO Bank secure portal application source and deployment code. This
includes the front-end WAR (portlets) and back-end EAR (EJBs).
c:\6325code\hardening This directory includes scripts and configuration files used in

Chapter 11, “Security hardening” on page 471.
c:\6325code\starterkit This directory includes build and deployment scripts used in

Appendix D, “Automate deployment tasks” on page 613.
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 688. Note that some of the documents referenced here may be available
in softcopy only.
򐂰 IBM WebSphere Portal for Multiplatforms V5 Handbook, SG24-6098
򐂰 IBM WebSphere Portal V5, A Guide for Portlet Application Development,
SG24-6076
򐂰 A Secure Portal Extended With Single Sign-On, REDP3743
V4.1, SG24-6077
򐂰 IBM WebSphere Application Server V5.0 Systems Management and
Configuration: WebSphere Handbook Series, SG24-6195
򐂰 IBM WebSphere V5.0 Security, WebSphere Handbook Series, SG24-6573
򐂰 WebSphere V5.0 Applications: Ensuring High Performance and Scalability,
SG24-6198
򐂰 WebSphere Studio Application Developer Version 5 Programming Guide,
SG24-6957
SG24-6014
򐂰 A Portal Composite Pattern Using WebSphere Portal V5, SG24-6087
򐂰 Lotus Security Handbook, SG24-7017
򐂰 A Secure Way to Protect Your Network: IBM SecureWay Firewall for AIX
V4.1, SG24-5855
򐂰 AIX V4.3 Elements of Security, SG24-5962
򐂰 IBM Host Integration in a Secure Network, SG24-5988
򐂰 Understanding LDAP - Design and Implementation, SG24-4986-01
򐂰 Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885

򐂰 IBM Tivoli Access Manager for e-business, REDP3677
SG24-6996
Other publications
These publications are also relevant as further information sources:
򐂰 WebSphere Portal V5.0.2.1 with Tivoli Access Manager V5.1.0.2 Integration
Guide, Volume 1: Installation and Configuration white paper by Ray Neucom,
found at:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD101710
򐂰 Stuart McClure, et al., Hacking Exposed: Network Security Secrets &
Solutions, Osborne/McGraw Hill, 2001, ISBN 0072193816
򐂰 Administration Java Classes Developer Reference, IBM Tivoli Access
Manager V5.1, SC32-1356
򐂰 Authorization Java Classes Developer Reference, IBM Tivoli Access
򐂰 Command Reference, IBM Tivoli Access Manager V5.1, SC32-1354
򐂰 Plug-in for IBM WebSphere Edge Server Integration Guide, IBM Tivoli Access
򐂰 Error Message Reference, IBM Tivoli Access Manager V5.1, SC32-1353
򐂰 Performance Tuning Guide, IBM Tivoli Access Manager V5.1, SC32-1351
򐂰 Problem Determination Guide, IBM Tivoli Access Manager V5.1, SC32-1352
򐂰 IBM Global Security Kit, Secure Sockets Layer Introduction and iKeyman
User’s Guide V7a, SC32-1363
򐂰 IBM WebSphere Application Server Integration Guide, IBM Tivoli Access
SC32-1359
򐂰 Web Security Developer Reference, IBM Tivoli Access Manager V5.1,
SC32-1358
SC32-1361
򐂰 Plug-in for Web Servers Integration Guide, IBM Tivoli Access Manager V5.1,
SC32-1365
SC32-1338
򐂰 Performance Tuning Guide, IBM Tivoli Directory Server V5.2, SC32-1342
Online resources
These Web sites and URLs are also relevant as further information sources:
򐂰 IBM WebSphere Portal for Multiplatforms InfoCenter:
򐂰 IBM WebSphere Portal Extend for Multiplatforms home page
http://www.ibm.com/software/genservers/portal/
򐂰 IBM WebSphere Portal Extend for Multiplatforms technical library home page
http://www.ibm.com/software/genservers/portal/library/
򐂰 IBM Tivoli Access Manager for e-business home page
http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/
򐂰 IBM Tivoli Access Manager for e-business technical information home page
http://publib.boulder.ibm.com/tividd/td/IBMAccessManagerfore-business5.1.ht
ml
򐂰 System Administration, Networking and Security Institute (SANS)
http://www.sans.org/
򐂰 The Center for Internet Security (CIS)
http://www.cisecurity.org/
򐂰 Microsoft Security home page
http://www.microsoft.com/security/default.asp
򐂰 SANS Institute, Information Reading Room for Windows 2000
http://rr.sans.org/win2000/win2000_list.php
򐂰 IBM AIX home page
http://www.ibm.com/servers/aix/
򐂰 IBM AIX Service Bulletins and Security Advisories
http://techsupport.services.ibm.com/server/nav?fetch=sbasa
Related publications 687

򐂰 SANS Institute, Information Reading Room for general UNIX
http://rr.sans.org/unix/unix_list.php
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
Help from IBM

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

ibm.com/services
Index
automation overview 614
Numerics availability 151
6325code.zip 684
A B
Back-end application cookies 110
Access Control List 42, 336
Basic authentication 40
access.log 588
BMP
AccessControlConfigService.properties 333
See Programming Module Enhancement
AccessControlDataManagementService.proper-
bootstrap port 435
ties 334
business challenges 145
account management pages 522
business requirements 146
ACL
See Access Control List
ActiveX Control 296 C
actors defined 155 CA
add portlets to page 453 See certificate authority
Additional security hardening guidelines 501 Certificate Authority 27
Administrator rights 229 Certificates 29–30
Apache Ant 616 Client-Web application single sign-on 96
application architecture 396 Common Secure Interoperability V2 472
application deployment Component connections
automate tasks 613 entry runtime environment 133
application development 395 Concepts
Architecture authentication 4
secure portal solution 5 authorization 4
architecture Credential Vault 4
node descriptions 645 global sign-on 4
Architecture overview 362 shared LDAP user registry 4
asymmetric key encryption 28 single sign-on 4
attributeMap.xml 31 Conceptual model 58
Authentication 4, 38 description 53
authentication 30 nodes 61
trace 591 conceptual model
Authentication data 39 node description
Authorization 4, 41 Application Server node 652
Tivoli Access Manager configuration 322 Caching Proxy node 648
WebSphere Portal vs TAM 95 Collaboration node 654
authorization Data Server node 650
trace 593 Directory node 649
authorization API Instant Messaging node 654
Tivoli Access Manager 18 Load Balancer node 646
Authorization goals 42 Policy Server node 653
Authorization process flow 43 Portal Development node 655
Authorization rules 42 Portal Server node 649

Repository node 670 Configure SSL certificate for LDAP 487
Reverse Proxy node 647 Configure the SSL repertoire for CSIv2 474
Web Server node 651 Configure Tivoli Directory Server client utilities for
node descriptions 645 SSL 488
Concurrent Version System 603 Configure Web Admin Tool for LDAP SSL connec-
config.was.tai.jacl 309 tions 487
ConfigService.properties 317 Configure WebSphere administration utilities 494
WebSphere Portal configuration for JAAS 325 Configure WebSphere Portal SOAP connection cre-
Configuration dentials 495
authorization Configure WMM for LDAP SSL connections 486
WebSphere Portal using TAM 322 cookie 103
Credential Vault 347 create a certificate 280
CSIv2 SSL settings 472 Create a suffix
CVS client for WSAD 386 for WebSphere Portal 266
CVS for NT 606 Tivoli Directory Server 387
IBM HTTP Server create a WebSEAL junction 297
enable SSL 277 create admin user and assign rights 183
JAAS 324 Create and configure SSL repertoire for SOAP con-
mutual SSL between WebSEAL and Web- nectors 493
Sphere Portal 276 create and ldif file
PDJRTE users and groups 267
for standalone JRE 382 create portal pages 451
WebSphere Studio WTE 382 Create SSL keys for CSIv2 473
PDJRTE for standalone JRE V1.3.1 382 Create SSL keys for SOAP connector 491
PDJRTE for WebSphere Studio WTE 382 Create users and groups
session timeouts 356 import the LDIF file (wp-itso.ldif) 387
WebSEAL 356 Credential objects 45
WebSphere Portal 356 Credential Service 4
SSO using LTPA 597 Credential Vault 4
Tivoli Access Manager 208 configuration 347
Web Portal Manager 215 Tivoli Access Manager 348
WebSEAL 222 trace 594
Tivoli Directory Server 195 Cryptography 27
for Tivoli Access Manager 206 CSIv2
WebSEAL create SSL keys 473
favicon 531 See Common Secure Interoperability V2
WebSphere Application Server SSL repertoire 474
JAAS 325 CSIv2 endpoint types
WebSphere Portal mutually authenticated 472
enable SSL 281 server authenticated 472
login/logout with WebSEAL 313 CSIv2 inbound transports
SOAP connection credentials 495 SSL-Required 472
WebSphere Portal for DB2 261 SSL-Supported 472
WebSphere Portal for LDAP 266, 386 TCP/IP 472
WebSphere Portal TAI 309 CSIv2 SSL
Configure and load wpconfig.properties file 497 configuration 472
Configure CSIv2 SSL settings 472 CVS client configuration 610
Configure SSL certificate and repertoire for SOAP CVS for NT 605
connector 491
D conceptual model 83
DB2 rebind 188 end-to-end development life-cycle 82
DB2 UDB V8.1 Fixpack 2 hardware used by ITSO 363
installation ITSO Bank
Windows 186 backend EJB server 412
DB2 Universal Database frontend portal server 418
First Steps 188 prepare database 408
installation 184 prepare for ITSO Bank 401
verification 188 software used by ITSO 364
define additional MIME types solution software 8
WebSphere Application Server 296 specified model 84
Defining and applying ACLs and POPs 42 topology selection 81
Demilitarized zone 60 Development node 368
deployed portlets 547 digital signature 29
deployment 433 Disable non-SSL access to Tivoli Directory Server
deployment automation 489
component types 625 disable non-SSL connections 489
concepts 625 disable security for WebSphere Portal 582
goals Disable the IBM HTTP Server Administration ser-
maintainability 614 vice 502
reproducibility 615 Disable the IBM HTTP Server on the Policy Server
traceability 614 node 502
terminology 615 Domain zone categories 54
tooling 616 controlled 55, 57
walkthrough 617 External Controlled 55
Deployment Manager 501 restricted 55, 57
Deployment Manager server 501 secured 55, 57
Design guidelines 93 uncontrolled 55
WebSphere Portal external web server 107 dummy SSL certificates 472
Design principals 94 DummyServerKeyFile.jks 472
access decision evaluation on-demand 94 DummyServerTrustFile.jks 472
access evaluated on-demand dynurl.conf 305
implication 95
motivation 95
E
capture access events EJB method level security 19
implication 95 electronic document 29
motivation 95 Enable LDAP server for SSL connections 476
capture authentication events and logs 95 Enable SSL for LDAP 475
centralized security 94 Enable SSL for Tivoli Access Manager LDAP con-
implication 94 nections 478
motivation 94 Enable SSL for Tivoli Directory Server Web Admin-
Development enviornment istration Tool for LDAP connections 487
topology selection Enable SSL for WebSEAL LDAP connections 480
all-in-one approach 85 Enable SSL for WebSphere Application Server
develop and deploy without debug 87 LDAP connections 481
develop using share security infrastructure Enable SSL for WebSphere Portal LDAP connec-
90 tions 484
develop, deploy and remote debug 88 encrypt passwords 586
Development environment
Index 691
Encryption 29 create a certificate 280
Enterprise runtime topology 73 create a keystore 279
Entry runtime topology 70 export CA certificate 283
Enumeration 16 import certificate 284
error page logs
customization 520 access.log 588
error.log 588 error.log 588
external authorization 336 http_plugin.log 588
ExternalAccessControlService.properties 331 SSL configuration 277
externalize resources 467 IBM Java Runtime Environment (JRE) 7
externalized role management 524 IBM Tivoli Access Manager for e-business 7
attach POP to resource-role 529 IBM Tivoli Directory Server 7–8
grant membership to a role 524 IBM WebSphere Application Server 7
revoke role membership 528 IBM WebSphere Application Server Enterprise 8
externalizing a resource 337 IBM WebSphere Portal Content Publisher 8
IBM WebSphere Portal Extend for Multiplatforms 8
IBM WebSphere Portal Toolkit and Test Environ-
F ment 9
favicon 531
IBM WebSphere Studio Application Developer 9
favicon.ico 359
IBM WebSphere Test Environment 9
Firewalls 22
ibmslapd 504
Footprinting 16
Identity management 105
Forms authentication 40
IllegalBlockSizeException 581
forms authentication 300
import an ldif file 268
fully qualified DNS name 232
Import LDAP certificate to WebSphere Portal key-
functional requirements 146
store 484
Import LDAP server certificate into the CSIv2 trust
G file 485
getCallerPrincipal method 19 Import SOAP server certificate into cacerts keystore
Global Sign-on 5, 96 496
GSKit 188 Import SOAP server certificate into CSIv2 trust file
GSO 496
See Global Sign-on import WebSphere Portal users into TAM 303
Important log files 588
initial context 144
H
http_plugin.log 588 Installation
httpd.conf 277 CVS for NT 606
DB2 Universal Database 184
Windows 185
I IBM GSKit 188
IBM DB2 UDB 7 IBM Java Runtime Environment 192
IBM GSKit 7 Tivoli Access Manager 207
determine version installed 189 PDJRTE 381
installation 188 Web Portal Manager 213
known issues 190 Tivoli Directory Client 219
uninstall 190 Tivoli Directory Server 193
IBM HTTP Server Web Administration Tool 196
configuration WebSEAL 220
certificate 280 WebSphere Application Server 197
WebSphere Portal 228 modify user info 563
Windows 2000 Server 183 portlets
Integration guidelines 93, 107 ITSOAccountBalance 397
access control of resources within portlets 113 ITSOTransfer 397
access control of WP resources 113 ITSOTransHistory 397
backend application cookies 110 ITSOUser 397
junction mapping table 112 run in WTE 420
TAI junction considerations 109 sample code download 402
WebSEAL junctions 108 verfiy add user 559
WebSEAL session considerations 114 verification 467
WebSEAL URL based access control 112 verify login 557
WebSphere Portal session considerations 114 verify transfer funds 567
Internal network 60 verify view account balance 566
intruder reconnaissance 15 ITSO Bank business scenario 144
isCallerInRole method 20 ITSO working exampel
IT architect 10 use case model
IT specialist 10 application login 158
ITSO Bank ITSO working example
application architecture and design 396 administration
backend 400 secure portal solution 503
database layer 398 application deployment 433
deploy backend application 434 architecture 166
add ITSO attribute to LDAP 437 decisions 169
create application server 435 development environment 174
create data source 440 key concepts 168
create database 437 overview 167
create users and groups 438 runtime environment 174
deploy EAR 443 business requirements 146
determine bootstrap port 435 business scenario 144
unpack backend code 436 business challenges 145
deploy frontend application 446 initial context 144
add portlets to pages 453 development environment
create portal pages 451 architecture 362
externalize resources 467 hardware used by ITSO 363
install portlets 450 planning 362
modify itsobank.properties 446 software used by ITSO 364
modify portlet permissions 463 functional requirements 146
modify resource permissions 459 ITSO Bank customer 146
wmmLDAPServerAttributes.xml 449 ITSO Bank manager 147
deployment units 399 portal administration 147
ITSOBankEAR.ear 400 security administration 147
ITSOBankWAR.war 400 ITSO Bank
EJB layer 397 application design 396
frontend 400 prepare development environment 401
helper classes 398 presentation layer 396
import into WSAD 402 using Credential Vault 425
method level security roles using TAM APIs 421
ITSOCustomers 400 LDAP distinguished name (DN) 267
ITSOManagers 400 non-functional requirements 147
Index 693
availability 151 JAAS
maintainability 152 See Java Authentication and Authorization Ser-
performance 148 vices
scalability 151 Java 2 SDK 20
security 152 Java Archive 296
system constraints 153 Java Authentication and Authorization Services 20
runtime environment Java Runtime Environment 192
planning 176 JMT
Policy Server node 182 See Junction Mapping Table
Portal Server node 227 jmt.conf 308
Reverse Proxy node 218 JRE
sample code See Java Runtime Environment
6325code.zip 684 junction 297
description 684 Junction Mapping Table
download 683 limitations 112
security hardening 471 Junction mapping table 112
start / stop servers 548
use case model 155
add user 159
K
Key concepts 4
administrative use cases 163
keystore 279
application logout 159
delete user 161
front-end use cases 158 L
modify user information 160 LDAP 31, 193, 266
transfer funds 163 enable SSL 475–476
view account balance 162 LDAP repository 4
view transaction history 161 ldap-enable-ssl.ldif 477
verification LDAPHelper class 422
add user 559 ldaphelper.properties 448
login 557 ldapmodify 290, 489
modify user info 563 LDAPsearch 584
transfer funds 567 Light Weight Third Party Authentication 309
view account balance 566 Lightweight Third Party Authentication 103
ITSOAccountBalance portlet 397 Logical security 17
itsobank.ldif 439 applications 18
itsobank.properties 447 middleware and application software 20
ITSOBankDataSource data source 440 network 22
ITSOBankEAR.ear 400, 443 operating systems 21
ITSOBankWAR.war 400, 446 IBM AIX 21
ITSOCustomers 400 Linux 22
ITSOid 419, 437 Microsoft Windows 21
ITSOManagers 400 WebSphere security 18
ITSOTransfer portlet 397 logout.html 315
ITSOTransHistory portlet 397 Logs
ITSOUser portlet 397 access.log 588
error.log 588
http_plugin.log 588
J msg_pdacId_utf8.log 590
J2EE developer 11
msg_pdmgrd_utf8.log 590
msg_pdmgrdproxyd_utf8.log 590 O
SystemErr.log 588 Operational model 52
SystemOut.log 588 contents
LTPA 597 description of each node 52
LTPA configuration 104 description of middleware services 52
description of walkthroughs 52
mapping matrix 52
M
macro support 524 one or more diagrams 52
maintainability 152 systems management strategy 52
Management zone 60 Outside zone 59
MASS
See Method for Architecturing Secure Solutions P
Matching topics to roles 11 pages 627
Method for Architecting a Security pdadmin 299, 304, 511
phases pdjrtecfg 382
analysis 26 permission 337, 342
developing security architectures 26 Physical model
integration for solution architecture 26 description 53
problem statement 26 Physical security 17
system model for security 26 PKI
Method for Architecting Secure Solutions 25 See Public Key Infrastructure
Microsoft Windows 2000 Server Plug-in approach 76
installation 183 Policy Server node 182, 366
MIME types 296 POPs
ActiveX Control (cab) 296 See Protected object policies
Java Archive (jar) 283, 296 Portal administrator 11
Modifying web.xml 313 Portal developer 11
msg_pdacld_utf8.log 590 Portal Server node 227
msg_pdmgrd_utf8.log 590 Portal-Backend SSO 96
msg_pdmgrdproxyd_utf8.log 590 PQ77683 594
mutual SSL 276 PQ79613 595
myportal 535 PQ79684 595
PQ79819 595
PQ79938 595
N
Network zone PQ80428 595
uncontrolled 56 PQ81912 596
Network zones 56 PQ83717 596
controlled 57 PQ86200 596
Node agents 502 presentation layer
nodes ITSO Bank application 396
Development node 368 private key cryptography 27
Policy Server 182 Production zone 60
Portal Server 227 Programming Module Enhancement (PME) 8
Repository node 366 Programming Module Extension 237
Reverse Proxy 218 Project manager 11
non-functional requirements 147 Protected object policies 42
Novell SuSe Linux 22 public key cryptography 28
Public Key Infrastructure 27
Index 695
R S
Realms of single sign-on 97 sample code
Redbooks Web site 688 description 684
Contact us xix download 683
Redhat Linux 22 SANS Institute 22
Replace the default SSL certificates for the SOAP SAS
connector 490 See Security Authentication Service
Repository node 366 scalability 151
requirements Scanning 16
ITSO working example 146 secret key cryptography 28
performance 148 secure portal
response time 149 application development 395
static volumetric 151 Secure portal solution
throughput 149 component connections 133
utilization 150 high level architecture 5
Resource Permissions portlet 547 high level authentication process 5
resource type Portlets 547 high level authorization 6
response time requirements 149 secure portal solution
Reverse proxy approach 74 administration 503
Reverse Proxy node 218 application deployment 433
risk management 14 application development 395
role membership 337 backup key files 549
roles 336, 338 development environment implementation 361
Roles and skills 10 log files 588
IT architect 10 overview 4
IT specialist 10 authentication 4
J2EE developer 11 authorization 4
portal administrator 11 credential vault 4
portal developer 11 shared LDAP user registry 4
project manager 11 single sign-on 4
security administrator 11 runtime environment configuration 259
security architect 10 runtime environment installation 175
Runtime environment security hardening 471
planning SSO using LTPA 597
hardware used by ITSO 178 SSO using TAI 289
installation paths and variables 181 troubleshooting 573
overview 176 Securing WebSphere Application Server in Network
prerequisites 177 Deployment environment 501
software used by ITSO 178 Security
using VMWare and Ghost 182 network 22
solution software 6 Security administrator 11
topology selection 69 Security and design guidelines
add external WP Web Server 107
extended enterprise runtime 79 authorization TAM vs WP 95
enterprise runtime 73 design principals 94
entry runtime 70 identity management 105
single sign-on 96
Security architect 10
Security Authentication Service 472
Security design objectives 54 WebSEAL session times out before Web-
Security domain 14 Sphere Portal session 121
intruder reconnaissance 15 WebSphere Portal logout after WebSEAL
logical security 17 session timeout 131
logical security categories WebSphere Portal session times out before
applications 18 WebSEAL session 124
middleware and application software 20 server1 application servers 502
network software 22 serverStatus.bat 534
operating systems 21 services.properties 334
physical security 17 Session considerations 114
physical security categories Session data 39
buiding access 17 session timeouts
physical network 17 WebSEAL 356
system access 17 WebSphere Portal 356
systems hardware 17 Single sign-on 4
security policy categories guidelines
risk analysis 23 Trust Association Interceptor 99
security management and audit 23 realms 97
security policies and procedures 23 selecting a solution 104
source vulnerability 15 single sign-on
security domain figure 14 configuration
Security fundamentals 13 LTPA 597
security hardening 471 TAI 289
additional guidelines 501 Single sign-on guidelines 96
define additional admin roles 501 LTPA token 103
disable IBM HTTP Server Administration skins 627
502 SOAP connector
disable unused end points 501 replace default SSL cert 490
disable unused WebSphere HTTP trans- Software versions 7
ports 501 Solution software 6
non-admin user 501 runtime environment 6
secure RMI connectors 501 Specified model 62
WAS Network Deployment 501 description 53
Security interaction patterns 65 specified model
application 67 node description 656
infrastructure 65 SPNEGO (Keberos) 40
Security policies 23 SSL
Security risk management 14, 23 enable IBM HTTP Server 277
Sequence diagrams enable SSL for LDAP 475
common access patterns 115 enable Tivoli Access Manager 478
access protected page with existing valid enable WebSEAL 480
session 119 enable WebSphere Application Server 281,
access protected portal page with invalid 481
credentials 120 enable WebSphere Portal 281, 484
access protected portal page, provide cre- Tivoli Directory Server
dentials 117 enable client utilities 488
access unprotected portal pages 116 enable Web Admin Tool 487
both WebSEAL and WebSphere Portal ses- SSO
sions time out 127 See Single sign-on
Index 697
SSODomainName 574 WebSphere Portal URIs 305
starter kit 627 enable SSL for LDAP 478
startServer.bat 533 features
static volumetric 151 authentication 35
Stop and start servers authorization 35
WebSphere Test Environment 392 centralized security management 35
stopServer.bat 533 programmatic authentication and authoriza-
Symantec Ghost 182 tion 35
symmetric key encryption 27 secure communication 35
system constraints 153 web single sign-on 35
SystemErr.log 588 Global Sign-on 5
SystemOut.log 588 installation 207
PDJRTE 213
update Windows registry 211
T logs
TAI
msg_pdacId_utf8.log 590
See Trust Association Interceptor
msg_pdmgrd_utf8.log 590
tam-acls.ldif 290
pdadmin 511
TAMExternalAccessControlServices 336
security model
TAMHelper 398
authentication 38
tamhelper.properties 448
client request session and authentication
Target redbook audience 10
data 38
team development 406
database used to maintain security policies
themes 627
36
throughput 149
features and components 35
Tivoli
master authorization database 37
administration tools 504
protected object 37
Tivoli Acccess Manager
protected object space 37
global sign-on 46
system resource 37
user registry database 36
apply ACLs to LDAP suffixes 290
web objects 37
authentication goals 38
WebSEAL 38
authentication process flow 40
authorization API 18
trace
authorization APIs 18
authentication 591
authorization vs WebSphere Portal 95
authorization 593
components
user create 321
Authorization Server 36
using APIs 421
pdadmin command line utility 36
Web Portal Manager 513
Policy Server 36
verification 216
WebSEAL
WebSEAL 36
configuration 222
configuration 208
create a junction 297
Authorization Server 210
installation 220
Policy Server 209
Tivoli Access Manager Global Sign-on 46
Runtime 208
Tivoli Directory Server
client utilities
Windows services startup 213
enable SSL for LDAP 488
create objects
command line utilities 510
configuration 195 secondary actors 156
configuration tool 506 summary of use cases 157
create a suffix 206 use case diagram 156
disable non-SSL access 489 user management 513
enable SSL 476 create users 514
installation 193 delete users 517
processes 504 password management 517
start / stop servers 505 user self care 519
Web Administration Tool 507 User registry 4
enable SSL for LDAP 487 utilization 150
Web Administration Tool installation 196
Tivoli Identity Manager 49
ToolBarInclude.jsp 318
V
Vault segment 44
Topology zones 53
Vault slot 44
trace 591
VaultServices.properties 348
Tracing Trust Association 324
Verfication
troubleshooting 573
WebSphere Portal SSL configuration 283
common issues 574
Verification
failure creating deployment credentials 575
Credential Vault 350
fixes
DB2 Universal Database 188
external access control 594
external authorization
login 574
TAM for WebSphere Portal 336
2-letter domains 575
IBM HTTP Server 280–281
browser formatting POST request 574
ITSO Bank 467
incorrect SSODomainName 574
LDAP configuration 393
usage of hostname in URL 574
Portal Toolkit 380
problem running portal as service 579
Portal Toolkit and Test Environment 380
recover portal admin privilage 577
SOAP configuration
session timeouts 575
install porlet via XMLAccess 499
tips 582
install portlet via GUI 499
disable WP security 582
TAI configuration 304, 312
install fixpacks for portal 585
create/login new user 321
using LDAP client utilities 584
trace 591
ACLs 343
authentication 591
configuration and APIs within Studio 384
WP database tranfers to DB2 fails 580
object space 343
Trust Association Interceptor 99, 309
methods 100
Tivoli Directory Server
settings 310
Web Administration Tool 205
summary how it works 100
WebSphere Application Server 200
Trust Association Interceptor configuration 313
WebSphere Portal 231
Verify SOAP configuration - install portlet via GUI
U 499
URL filtering 301 Verify xmlaccess utility- install portlet via xmlaccess
use case model 155 499
actors defined 155 Virtual Private Network 23
overview 155 Virtual Resource resource type 547
primary actors 155 VMWare 365
Index 699
VMWare Workstation 182 options 108
VPN cookie handling 108
See Virtual Private Network encryption 108
number of junctions 108
TAI 109
W WebSEAL to web application authentication flow
Web objects 37
98
Web Portal Manager 213, 513
WebSEAL user sessions 114
web.xml
WebSphere
WebSphere Portal 313
administration tools 531
WebSphere Portal SSL 282
WebSphere Application Server
webseaId-default.conf 300
Administrative Console 531
WebSEAL 220
authentication protocols
additional parameters 303
CSIv2 472
configuration 222
SAS 472
create a junction 297
bootstrap port 435
create junction
configuration
syntax parameters 298
backup 235
customize HTML pages 519
JAAS 325
account management pages 522
default_host 281
error pages 520
define additional MIME types 296
macro support 524
disable global security 583
enable forms authentication 300
dummy SSL certificates 472
enable SSL 281
favicon.ico configuration 359
junction cookies 302
establish trust relationship
junction mapping 302
LTPA 309
junction mapping table 307
TAI 309
logs
host aliases 281
msg_pdmgrdproxyd_utf8.log 590
installation 197
modify URLs to backend 301
logs
processing of URLs 302
SystemErr.log 588
URL based access control 112
SystemOut.log 588
URL filtering 301
Network Deployment 501
user sessions 114
Deployment Manager 501
WebSEAL authentication methods 39
node agents 502
Basic authentication 40
Programming Module Extension 237
CDSSO ID token 39
server status 534
client-side certificate 39
serverStatus.bat 534
failover cookie 39
SOAP connector
forms authentication 40
replace default SSL cert 490
HTTP headers 40
SSL repertoire for CSIv2 474
IP address 40
SPNEGO (Keberos) 40
startServer.bat 533
WebSEAL junction
stopServer.bat 533
-b supply option 109
verification 200
-b supply option using mutual SSL 110
wsadmin 532
custom TAI plugin 110
WebSphere Member Services 31
WebSEAL junctions 108
WebSphere Portal
access categories delegated administration 35
WP_admin_access 304 identifyi the user 32
WP_all_access 304 Java security 34
WP_authenticated_access 304 member services 31
WP_no_access 304 persistent connections 33
add portlets to pages 453 single sign-on 33
authorization vs TAM 95 third-party authentication servers 32
ConfigService.properties 317 self care 31
configuration skins 627
Credential Vault 347 SOAP timeout 241
login/logout with WebSEAL 313 standalone Web server 107
SOAP connection credentials 495 stop and start server 235
Content Publisher 242 themes 627
create portal pages 451 trace
Credential Service 4 authentication 592
Credential Vault 4, 44, 99 authorization 593
credential objects 45 credential vault 594
vault segment 45 URIs 305
verification 350 define access controls 304
DB2 configuration 261 user sessions 114
disable LDAP security 394 verification 231
disable security 582 Web administration 535
enable LDAP security 269 xmlaccess 544
enable LDAP security for WebSphere Portal WebSphere Portal Toolkit
388 installation 378
enable SSL for LDAP 484 WebSphere Portal user sessions 114
encrypt clear text passwords 586 WebSphere security 18
externalize a resource 536 EJB method level security 19
First Steps 231 JAAS 20
IBM HTTP Server configuration 264 WebSphere Studio Application Developer
install portlets 450 installation 369
installation 228 WebSphere Studio Application Developer V5.1.1
internalize a resource 537 installation 369
LDAP configuration 266 WebSphere Test Environment
logs start and stop 392
SystemErr.log 589 wmm_LDAP.xml.IBM_DIRECTORY_SERVER.1.w
SystemOut.log 589 mm 270
wps_date_time.log 589 wmmLDAPAttributes_IBM_DIRECTORY_SERVER
manage the Credential Vault 536 .xml 271
modify portlet permissions 463 wmmLDAPServerAttributes.xml 419, 449
modify resource permissions 459 WP_admin_access 304
read-only LDAP access 269 WP_all_access 304
remove encrypted passwords 587 WP_authenticated_access 304
screens 626 WP_no_access 304
security model wpconfig.properties
administration 31 DB2 settings 262
authentication 32 disable security 583
authorization 34 LDAP settings 273
Credential Vault 33 Web server settings 265
Index 701
WpsHostName 320
wp-itso.ldif 267
wp-junction.pd 297
wp-junction-ltpa.pd 600
wps_date_time.log 589
wpsconfig 261
wpslogout.html 313
wp-tam-acl.pd 306
wp-tam-user-import.pd 303–304
wpwin1_svrsslcfg.bat 323
wsadmin.bat 532
X
XMLAccess 544
verfication 499
Y
YourCo Financial 338
Develop and Deploy a Secure Portal Solution
Using WebSphere Portal V5 and Tivoli Access
Manager V5.1
Back cover ®
Develop and Deploy a

Secure Portal Solution
Using WebSphere Portal V5 and Tivoli
Access Manager V5.1
Solution architecture Portals provide a personalized single point of access to

and technologies for applications, content, and processes through a Web INTERNATIONAL
a secure portal interface. Secure portal solutions are needed to address TECHNICAL
common security challenges such as authentication, SUPPORT
authorization, and single sign-on. ORGANIZATION
Deploy a secure
portal runtime This IBM Redbook and sample code will provide IT
environment architects, developers, IT specialists, and administrators
with the critical knowledge to design, develop, deploy,
and manage a secure portal solution using IBM Tivoli BUILDING TECHNICAL
Develop and deploy Access Manager V5.1.0.2 and IBM WebSphere Portal INFORMATION BASED ON
secure portal V5.0.2.1. PRACTICAL EXPERIENCE
application
Part 1, “Introduction to secure portal solutions”,
introduces key concepts and provides an in-depth look at IBM Redbooks are developed by
the IBM International Technical
the secure portal solution architecture, topology
Support Organization. Experts
selection, design, and integration guidelines. from IBM, Customers and
Partners from around the world
Part 2, “ITSO working example secure portal solution”, create timely technical
describes how to implement an end-to-end secure portal information based on realistic
solution. This part includes a business scenario, scenarios. Specific
requirements, design, implementation of the runtime and recommendations are provided
development environments, application development to help you implement IT
and deployment, and administration of the secure portal solutions more effectively in
solution. your environment.
For more information:

ibm.com/redbooks
SG24-6325-00 ISBN 073849044X

Develop and Deploy A Websphere Portal Solution

Uploaded by

Document Information

Original Title

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

Develop and Deploy A Websphere Portal Solution

Uploaded by

Copyright:

Available Formats

Front cover

Develop and Deploy a

Solution architecture and technologies

Deploy a secure portal runtime

Develop and deploy

Develop and Deploy a Secure Portal Solution

First Edition (August 2004)

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

Part 1. Introduction to secure portal solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2. Security fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 3. Architecture and topology selection. . . . . . . . . . . . . . . . . . . . . 51

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

Chapter 4. Design and integration guidelines . . . . . . . . . . . . . . . . . . . . . . 93

Part 2. ITSO working example secure portal solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Chapter 5. Requirements and solution design. . . . . . . . . . . . . . . . . . . . . 143

Chapter 6. Install the runtime environment . . . . . . . . . . . . . . . . . . . . . . . 175

Chapter 7. Configure the runtime environment . . . . . . . . . . . . . . . . . . . . 259

Chapter 8. Implement the development environment . . . . . . . . . . . . . . . 361

Chapter 9. Develop the secure portal application . . . . . . . . . . . . . . . . . . 395

Chapter 10. Deploy the secure portal application . . . . . . . . . . . . . . . . . . 433

Chapter 11. Security hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

Chapter 12. Manage a secure portal solution. . . . . . . . . . . . . . . . . . . . . . 503

Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

Appendix A. Troubleshooting a secure portal solution. . . . . . . . . . . . . . 573

Appendix B. Configure single sign-on using LTPA . . . . . . . . . . . . . . . . . 597

Appendix C. CVS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603

Appendix D. Automate deployment tasks. . . . . . . . . . . . . . . . . . . . . . . . . 613

Appendix E. Node descriptions for architecture models . . . . . . . . . . . . 645

Appendix F. Additional material. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

© Copyright IBM Corp. 2004. All rights reserved. xiii

AIX® HACMP™ Redbooks™

The following terms are trademarks of other companies:

Portals provide a personalized single point of access to applications, content,

Part 1, “Introduction to secure portal solutions” on page 1, introduces key

The team that wrote this redbook

© Copyright IBM Corp. 2004. All rights reserved. xv

John Ganci is a Senior Software Engineer, WebSphere Specialist at the IBM

Hinrich Boog is an IT Specialist in the IBM e-business Innovation Center

Ashwin Manekar is a Software Engineer in IBM Software Group Solution Test,

Normunds Saumanis is an IT Architect in IBM Global Services, Latvia. He has

Kai Schwidder is an IT Architect in the IBM Software Group, Switzerland. He

Jonas Tingeborn is an IT Specialist in IBM Global Services, Sweden. He has

Tinny Ng, IBM Canada

Become a published author

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

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

1.1.1 Key concepts of a secure portal solution

Shared LDAP user registry

1.1.2 Secure portal solution high level architecture

Outside Zone Demilitarized Zone Production Zone

Portal Server Backend Server

Figure 1-1 Secure portal solution high level architecture

1.2 Solution software

1.2.1 Runtime environment solution software

As described in Chapter 3, “Architecture and topology selection” on page 51,

IBM DB2® UDB, Enterprise Server Edition 8.1 8.1.4.428

IBM GSKit 7.0.1.9 7.0.1.16

IBM Java Runtime Environment (JRE) 1.3.1 1.3.1

IBM WebSphere Application Server 5.0.2 5.0.2

IBM Tivoli Directory Server 5.2 5.2

IBM Tivoli Access Manager for e-business 5.1 5.1.0.2

IBM DB2 UDB, Enterprise Server Edition 8.1.1 8.1.4.428