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.1 Windows 2000 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . 219 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.1 Windows 2000 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . 228 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.8 Java Runtime Environment (JRE) V1.3.1 installation . . . . . . . . . . . 254 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.7 Java Runtime Environment (JRE) V1.3.1 installation . . . . . . . . . . . 381 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 10.3.7 10.3.8 10.3.9

Add portlets to pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Modify resource permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Verify ITSO Bank application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 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® Balance® ClearCase® Cloudscape™ developerWorks® Domino® DB2 Universal Database™ DB2®

HACMP™ IBM® ibm.com® Lotus Notes® Lotus® NetView® Notes® Rational®

Redbooks™ Redbooks (logo) Sametime® Tivoli® WebSphere® xSeries®

™

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: [email protected]

򐂰 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.

© Copyright IBM Corp. 2004. All rights reserved.

3

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

4

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Demilitarized Zone

Outside Zone

Production Zone

Request Response

Reverse Proxy TAM WebSEAL

Domain Name Server

Domain Firewall

Web Browser Client

I N T E R N E T

Protocol Firewall

Public Key Infrastructure

Portal Server

Backend Server

ITSO Bank Portlets

ITSO Bank EJBs

WebSphere Portal

WebSphere Application Server

WMM

ITSO Bank

Policy Server

Directory Server

TAM Policy Server

Tivoli Directory Server

TAM Authorization Server

LDAP User Registry

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,

6

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 product name

Tivoli Access Manager bundled software version

ITSO example fixpack 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 Note: Used to host Web administration tools.

5.0.2

5.0.2

IBM Tivoli Directory Server * Directory Server * Directory Client SDK * Web Administration Tool

5.2

5.2

IBM Tivoli Access Manager for e-business * Access Manager Runtime * Access Manager Java Runtime Environment (PDJRTE) * Access Manager Policy Server * Access Manager Authorization Server * Access Manager Web Portal Manager * Access Manager Web Security Environment *Access Manager WebSEAL

5.1

5.1.0.2 Note: 5.1 + TAM Base Fixpack 2 + WebSEAL Fixpack 2

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.

Chapter 1. Introduction

7

Table 1-2 Software included with WebSphere Portal V5.0.2 Extend and fixpack levels used by the ITSO WebSphere Portal Extend bundled software product name

WebSphere Portal bundled software version

ITSO example fixpack version

IBM DB2 UDB, Enterprise Server Edition

8.1.1

8.1.4.428 Note: 8.1 + Fixpack 4a

5.0.2 Note: 5.0 + Fixpack 2 + Fixes

5.0.2.3 Note: 5.0 + Fixpack 2 + Cumulative Base Fix 3 + Fixes

* Programming Module Enhancement (PME)

5.0.2 Note: 5.0 + Fixpack 2

5.0.2.2 Note: 5.0 + Fixpack 2 + Cumulative PME Fix 2

IBM Tivoli Directory Server * Directory Server * Directory Client SDK * Web Administration Tool

5.1

5.2

IBM WebSphere Portal Extend for Multiplatforms * WebSphere Portal * WebSphere Portal Content Publisher

5.0.2 Note: 5.0 + Fixpack 2 + Fixes

5.0.2.1 Note: 5.0 + Fixpack 2 + Cumulative Fix 1 + Fixes

IBM WebSphere Application Server Enterprise * WebSphere Application Server (Base)

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.

8

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Developer

5.1.1

IBM WebSphere Test Environment included with WebSphere Studio Application Developer

5.0.2.3 Note: Fixpack 2 + Cumulative Fix 3 + Fixes

IBM WebSphere Portal Toolkit and Test Environment

5.0.2.1

IBM Java Runtime Environment (JRE)

1.3.1

IBM Tivoli Access Manager for e-business * Access Manager Java Runtime Environment (PDJRTE)

5.1.0.2 Note: 5.1 + Base Fixpack 2

Chapter 1. Introduction

9

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.

10

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 page 51

IT architect Security architect

All user roles

Chapter 4, “Design and integration guidelines” on page 93

IT architect Security architect

All user roles

Part 2, “ITSO working example secure portal solution” on page 141

Chapter 1. Introduction

11

Chapter/appendix

Primary

Secondary

Chapter 5, “Requirements and solution design” on page 143

IT architect Security architect Project manager

All user roles

Chapter 6, “Install the runtime environment” on page 175

IT specialist

IT architect

Chapter 7, “Configure the runtime environment” on page 259

IT specialist Security administrator Portal administrator

IT architect Security architect

Chapter 8, “Implement the development environment” on page 361

Portal developer J2EE developer

IT architect IT specialist

Chapter 9, “Develop the secure portal application” on page 395

Portal developer J2EE developer

IT architect

Chapter 10, “Deploy the secure portal application” on page 433

IT specialist Portal administrator Security administrator

Portal developer J2EE developer IT architect

Chapter 11, “Security hardening” on page 471

IT specialist Security administrator

IT architect Security architect

Chapter 12, “Manage a secure portal solution” on page 503

Portal administrator Security administrator

IT specialist IT architect

Appendix A, “Troubleshooting a secure portal solution” on page 573

IT specialist Portal administrator Security administrator

Portal developer J2EE developer IT architect

Appendix B, “Configure single sign-on using LTPA” on page 597

IT specialist Security administrator

IT architect Security architect

Appendix C, “CVS configuration” on page 603

Portal developer J2EE developer

IT architect IT specialist

Appendix D, “Automate deployment tasks” on page 613

IT specialist Portal administrator Security administrator

Portal developer J2EE developer IT architect

Appendix E, “Node descriptions for architecture models” on page 645

IT architect Security architect

All user roles

Appendix F, “Additional material” on page 683 Note: Sample configuration files and ITSO Bank sample secure portal application

IT specialist Portal developer J2EE developer

IT architect

Part 3, “Appendixes” on page 571

12

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

© Copyright IBM Corp. 2004. All rights reserved.

13

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 Vulnerability and Intruder Reconnaissance

Applications 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

14

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

16

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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.

Chapter 2. Security fundamentals

17

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. 򐂰 Enterprise Security Architecture Using IBM Tivoli Security Solutions, 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.

18

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

WebSphere Application Resources

HTML Servlet/JSP EJBs WebServices

Naming 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.

Chapter 2. Security fundamentals

19

– 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

20

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 2. Security fundamentals

21

– 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.

22

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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.

Chapter 2. Security fundamentals

23

Prevent

Risk Analysis

Protect

Mitigate

Risk

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.

24

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 2. Security fundamentals

25

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. b. c. d.

Business process model Security design objectives Selection and enumeration of subsystems Documenting conceptual security architecture

5. Integration into the overall solution architecture a. b. c. d. e.

Solution models Documenting architectural decisions Use cases Refining the functional design 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

26

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 򐂰 򐂰 򐂰

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

Chapter 2. Security fundamentals

27

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

Plain Text

Encryption

Key 2

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.

28

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

2

1 Alice

B

B Plain Text

Public

Alice

3

Encrypted Text

Private

Private

Plain Text

A

A Plain Text

Bob

Encrypted Text

Public

Bob 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

Chapter 2. Security fundamentals

29

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.

30

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 2. Security fundamentals

31

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

32

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 2. Security fundamentals

33

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.

34

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 򐂰 Enterprise Security Architecture Using IBM Tivoli Security Solutions, 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

Chapter 2. Security fundamentals

35

– 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)

36

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 2. Security fundamentals

37

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

38

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 2. Security fundamentals

39

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.

40

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 2. Security fundamentals

41

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.

42

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Objects

Web Objects

User-Defined 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.

Chapter 2. Security fundamentals

43

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 Administrator-managed Segment (A2) Slot A2a

Other Vault Implementation

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

44

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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.

Chapter 2. Security fundamentals

45

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

46

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 attributes Object classes and attributes used by applications sharing LDAP

Primary user password (userPassword)

Application X user object Application Y user object Synchronization Access Manager user object (secUser) principalName Access Manager GSO user object (eGSOUser)

Object classes used by Access Manager

GSO resource for Application X User ID User Password GSO resource for Application Y User ID User Password

Figure 2-9 LDAP shared by Access Manager and other applications

Chapter 2. Security fundamentals

47

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

48

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 2. Security fundamentals

49

TAM Directory Person TAM UserID

TAM Policy Server

TAM GSO Credential

TAM Admin over SSL

TAM GSO Credential

TAM Admin over SSL

TAM GSO Credential

TAM Node TAMGSO Agent

DAML over SSL

ITIM Directory

DAML over SSL

TAM Agent

Person TAMAccount TAMGSOAccount

TAM Service

TAMGSO Services

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 򐂰 Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014

50

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 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.

© Copyright IBM Corp. 2004. All rights reserved.

51

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.

52

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

54

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Domain Firewall

Domain Firewall

Controlled

Domain Firewall

Uncontrolled

Protocol Firewall

Restricted

Controlled

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).

Chapter 3. Architecture and topology selection

55

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.

56

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 3. Architecture and topology selection

57

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

58

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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 Outside Zone

Demilitarized Zone

Production Zone

Internal Network

Wireless Gateway

Mobile Client

Legend:

Web Server Node

App Server Node

Collaboration Node

Instant Messaging Node

Database Domain

Directory Replica Domain

Data Server Node

Directory Node

Domain Firewall

Domain Firewall

Development Domain Domain Firewall

Caching Proxy

Reverse Proxy

Load Balancer Hot Standby

Domain Name Server

Protocol Firewall

Rich Client

Internet

Web Browser Client

Load Balancer

Public Key Infrastructure

Backend Domain

Caching Proxy

Reverse Proxy

Portal Server Node

Reverse Proxy

Portal Domain

Portal Development Node

Access Manager Domain Policy Server Node

App Server Node

Web Server Node

Directory Domain Directory Node

App Server Node

Web Server Node

Data Server Node

Management Zone 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.

Chapter 3. Architecture and topology selection

59

򐂰 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.

60

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Production Zone

Authentication (Also request routing and authorization)

Mobile Client

Legend:

• • • • • • •

• • • • •

Backend Domain

Content Transcoding Access Control List Content Aggregation Document Management Document Editors Credential Services UDDI Directory Services

Domain Firewall

Caching Proxy

Caching Proxy

Load Balancer Hot Standby

Wireless Gateway

Reverse Proxy

Protocol Firewall

Internet

Domain Name Server

Load Balancer

Advanced Caching (Also request routing and dynamic caching)

Web Browser Client Rich Client

Portal Server Node Reverse Proxy

Load Balancing (Request routing)

Public Key Infrastructure

Internal Network

• Static Page Serving • Servlet Redirector Portal Domain

Web Server Node

App Server Node

Collaboration Node

Instant Messaging Node

• • • •

Data Source Connectivity Business Logic Transaction Management Content Transcoding Reverse Proxy

Demilitarized Zone

Development Domain

Portal Asynchronous Synchronous Database Domain Directory Replica Development Interaction Interaction Domain Node (e-Mail) (e-Meeting, etc.) Data Directory Server Node Node • Authentication & Authorization Engine • Rule-Based Policies Domain Firewall • Role-Based Policies Domain Firewall

Outside Zone

Access Manager Domain Database supporting LDAP Policy App Web User Records Server Server Server Group Data Node Node Node Organizational Data Credential Repository Directory Domain Directory Node

App Server Node

Web Server Node

Data Server Node

Management Zone Data related flows Security 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

Chapter 3. Architecture and topology selection

61

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.

62

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Demilitarized Zone

Production Zone Portal Domain App Server Node

Caching Proxy SECP1

Web Browser Client

Reverse Proxy

SECP2

SELB

Reverse Proxy

Domain Firewall

Protocol Firewall

Internet

SERP1

Caching Proxy

Reverse Proxy

Backend Domain

SPPORTAL

Load Balancer

Internal Network

Web Server Node

App Server Node

SPHTTPD

SPBANK

Collaboration Node

Instant Messaging Node

SPDOMINO

SPSAMETIME

Directory Replica Domain

Database Domain

Directory Node

Data Server Node

SPLDAPR

SPDB

SIRP

Development Domain

Domain Firewall

Outside Zone

Portal Development Node SIDEVELOP

Domain Firewall

SERP2

Access Manager Domain Policy Server Node

App Server Node

Web Server Node

SMTAM

SMWAS1

SMHTTP1

Directory Domain Directory Node SMLDAP

App Server Node

Web Server Node

SMWAS2 SMHTTP2

Data Server Node SMDB

Management Zone Legend:

Data related flows Security 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.

Chapter 3. Architecture and topology selection

63

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

64

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 O,SPSAMETIME

SPLDAPR

LDAP(389), LDAPS(636)

SPLDAPR,SPPORTAL, SPBANK

SPDB

Database client/server connection ports (50000,50001)

SMLDAP

SPLDAPR

LDAP(389), LDAPS(636)

SMLDAP,SMWAS2,SM WAS1

SMDB

Database client/server connection ports (50000,50001)

SMHTTP1

SMWAS1

HTTP(9080), HTTPS(9443)

SMHTTP2

SMWAS2

HTTP(9080), HTTPS(9443)

SMTAM

SMLDAP

LDAP(389), LDAPS(636)

SIDEVELOP

SPPORTAL

FTP(21)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 User

2 Load Balancer

6

4 Reverse Proxy

Application 5

3

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.

Chapter 3. Architecture and topology selection

65

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 7

Reverse Proxy

Application

8 5 3

Policy Server

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.

66

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 3. Architecture and topology selection

67

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

Backend Class Files

Secure

NonSecure

Interface Pages (JSP, HTML,Portlets)

Secure

NonSecure

Transactional Objects (EJB)

Secure

NonSecure

Figure 3-7 Simple application security categories

68

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Backend Class Files

Secure Programmatic: Policy Server Permissions

Transactional Objects (EJB)

Interface pages (JSP, HTML,Portlets)

NonSecure

Secure Declarative: Reverse Proxy (i.e. WebSeal) Programmatic: Session Control

NonSecure

Secure Declarative: Realms Programmatic: In-house or Policy Server Permissions

NonSecure

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.).

Chapter 3. Architecture and topology selection

69

򐂰 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. 򐂰 E/P/M/I indicates it belongs to the external zone, the production zone, the 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. 򐂰 An optional number to distinguish similar nodes within a zone. 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.

70

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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.

Chapter 3. Architecture and topology selection

71

Outside Zone

Demilitarized Zone

Production Zone • • • • • •

• Tivoli Access Manager 5.1.0.2 (Runtime, PDJRTE, Web Security, WebSeal) • IBM GSKit 7.0.1.16 • IBM JRE 1.3.1 • Microsoft Windows 2000 Server + SP4

Reverse Proxy PERP SERP1

Portal/Backend Domain PPBANK SPPORTAL Domain Firewall

Protocol Firewall

Internet

Web Browser Client

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

SPHTTPD

SPBANK

SPDB

Domain Firewall

Access Manager/Directory Domain 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 Security 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.

72

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Table 3-2 Node interaction matrix From

To

Characteristics

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.

Chapter 3. Architecture and topology selection

73

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.

74

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Demilitarized Zone

Production Zone Portal Domain

Tivoli Access Manager 5.1.0.2 (WebSEAL) Web Browser Client

PPPORTAL

Backend Domain

SPPORTAL

Reverse Proxy

PPBANK

Lotus Domino/Notes

PERP1

SPHTTPD

SPBANK

PPNOTES

PPST

SERP1 Tivoli Directory Server 5.2

PELB SELB Reverse Proxy

Domain Firewall

Load Balancer Protocol Firewall

Internet

WebSphere Edge Components

Internal Network

WebSphere Application Server 5.0.2.3

WebSphere Portal Extend 5.0.2.1

Lotus Sametime

Development Domain

SPDOMINO SPSAMETIME DB2

Directory Replica Domain

Database Domain

PPLDAPR

PPDB

SPLDAPR

SPDB Domain Firewall

PIDEV Domain Firewall

Outside Zone

SIDEVELOP

Tivoli Access Manager 5.1.0.2 (Policy and Authorization)

PERP2 Access Manager Domain

SERP2

PMTAM SMTAM

SMWAS1

SMHTTP1

Tivoli Access Manager 5.1.0.2 (WebSEAL)

• Tivoli Directory Server 5.2 • DB2

Directory Domain PMLDAP SMLDAP

SMWAS2

SMHTTP2

SMDB

Management Zone Legend:

Data related flows Security related flows

Figure 3-10 Physical model of the enterprise model using reverse proxies

Restriction: The physical model covers performance-relevant characteristics and is not intended to provide high-availability aspects. Therefore only one Load Balancer node is specified. Table 3-3 Node interaction matrix From

To

Characteristics

User

PELB

HTTP(80), HTTPS(443)

PELB

PERP1,PERP2

HTTP(80), HTTPS(443)

PERP1,PERP2

PPLDAPR

LDAP(389), LDAPS(636)

Chapter 3. Architecture and topology selection

75

From

To

Characteristics

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 ANK

PPDB

DB(50000,50001)

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.

76

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Demilitarized Zone

Production Zone WebSphere

WebSphere Portal Extent 5.0.2.1

• WebSphere Caching Proxy • Tivoli Access Manager 5.1.0.2 Plugin Web Browser Client

Portal Domain PPPORTAL

SECP1

SELB

Caching/ Plugin Proxy

Tivoli Directory Server 5.2

Domain Firewall

Protocol Firewall

Internet

Load Balancer PELB

PPBANK

Lotus Domino/ Notes

PECP1 WebSphere Edge Components

Backend Domain

SPPORTAL

Caching/ Plugin Proxy

Internal Network

Application Server 5.0.2.3

SPHTTPD

SPBANK

PPNOTES

PPST

SPDOMINO

Directory Replica Domain

Lotus Sametime

Development Domain

SPSAMETIME

DB2

Database Domain

PPLDAPR

PPDB

SPLDAPR

SPDB

PIDEV Domain Firewall

Outside Zone

SIDEVELOP

Tivoli Access Manager 5.1.0.2 (Policy and Authorization.)

Domain Firewall

PECP2 Access Manager Domain

SECP2

PMTAM SMTAM • WebSphere Caching Proxy • Tivoli Access Manager 5.1.0.2 Plugin

SMWAS1

Directory Domain

SMHTTP1 • Tivoli Directory Server 5.2 • DB2

PMLDAP SMLDAP

SMWAS2

SMHTTP2

SMDB

Management Zone Legend:

Data related flows Security related flows

Figure 3-11 Physical model of the enterprise runtime based on security plug-ins

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.

Chapter 3. Architecture and topology selection

77

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. Restriction: The physical model covers performance-relevant characteristics and is not intended to provide high-availability aspects. Therefore only one Load Balancer node is specified. Table 3-4 Node interaction matrix

78

From

To

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)

PMTAM

PERP1,PERP2

TAM_SSL(7234)

PECP1,PECP2

PPORTAL

HTTP(9081), (optional 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 ANK

PPDB

DB(50000,50001)

PMTAM

PMLDAP

LDAP(389), LDAPS(636)

PMLDAP

PPLDAPR

LDAP(389), LDAPS(636)

PIDEV

PPPORTAL

FTP(21)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 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 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.

Chapter 3. Architecture and topology selection

79

Demilitarized Zone

Production Zone

WebSphere Portal Extend 5.0 Portal Domain

Caching Proxy

Tivoli Access Manager 5.1.0.2 (WebSEAL)

PPPORTAL

PECP2

Web Browser Client

Reverse Proxy

Lotus Domino/Notes

Load Balancer

PECP1

PELB

SECP1

SELB

Domain Firewall

Protocol Firewall

Internet

PPBANK

SPHTTPD

SPBANK

PPNOTES Tivoli Directory Server 5.2

Caching Proxy

Reverse Proxy

PPHTTP

SECP2

SERP1

WebSphere Edge Components

SPDOMINO

Directory Replica Domain

WebSphere Caching Proxy

Reverse Proxy

Backend Domain

SPPORTAL

PERP1

Internal Network

• WebSphere Application Server 5.0.2.3 • IBM HTTP Server 1.3.26

WebSphere Caching Proxy

PIRP SIRP Lotus Sametime

PPST SPSAMETIME

DB2

PPLDAPR

Database Domain PPDB SPDB

SPLDAPR

Domain Firewall

Outside Zone

Development Domain PIDEV SIDEVELOP

Domain Firewall

PERP2

Tivoli Access Manager 5.1.0.2 (Policy and Authorization) Access Manager Domain

SERP2

PMTAM SMTAM Tivoli Access Manager 5.1.0.2 (WebSEAL)

SMWAS1

SMHTTP1

• Tivoli Directory Server 5.2 • DB2 Directory Domain PMLDAP SMLDAP

Legend:

SMWAS2

SMHTTP2

SMDB

Management Zone Data related flows Security related flows

Figure 3-12 Physical model of the extended enterprise runtime

Restriction: The physical model covers performance-relevant characteristics and is not intended to provide high-availability aspects. Therefore only one Load Balancer node is specified. Table 3-5 Node interaction matrix

80

From

To

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)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

From

To

Characteristics

PMTAM

PERP1,PERP2

TAM_SSL(7234)

PERP1,PERP2

PECP1,PECP2

HTTP(80), HTTPS(443)

PECP1,PECP2

PPORTAL

HTTP(9081), (optional HTTPS(9444))

PPPORTAL

PPHTTP

HTTP(80), (optional HTTPS(443))

PPHTTP

PPBANK

HTTP(9083)

PPPORTAL

PPST

IIOP

PPPORTAL

PPNOTES

HTTP(80), HTTP(443) IIOP

PPORTAL,PPBANK

PPLDAPR

LDAP(389), LDAPS(636)

PPORTAL,PPLDAPR,PPB ANK

PPDB

DB(50000)

PMTAM

PMLDAP

LDAP(389), LDAPS(636)

PMLDAP

PPLDAPR

LDAP(389), 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).

Chapter 3. Architecture and topology selection

81

򐂰 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.

Pre-Production (Optional)

Test/Integration

Development

Production

Module A Module B

Handover

Handover

Handover Tuning

Performs

Analysis

Error

Module C Fix to be tested

Module C

Passed to the developer

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

82

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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 Node

Reverse Proxy Node

Repository Node

Portal Server Node

Directory Server Node

Data Server 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.

Chapter 3. Architecture and topology selection

83

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 Node SDWB Reverse Proxy Node SDRP

Repository Node SDREP

Portal Server Node SDPORTAL Directory Server Node SDLDAP

Data Server Node 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.

84

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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.

Chapter 3. Architecture and topology selection

85

Physical Machine using VMWare for Test Nodes SDWB PDWB Tivoli Access Manager 5.1.0.2 (WebSEAL)

SDRP

SDPORTAL SDREP

• WebSphere Studio Application Developer 5.1.1 • WebSphere Portal Toolkit and Test Environment 5.0.2.1 • CVS • Windows 2000 + SP4

PDRP

SDTAM PDTAM

SDLDAP SDDB

Legend :

• Tivoli Access Manager 5.1.0.2 (Policy and Authorization) • Tivoli Directory Server 5.2

Physical Virtual

Figure 3-16 All-in-one approach Table 3-6 Node interaction matrix

86

From

To

Characteristics

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)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 3. Architecture and topology selection

87

Test Domain

Development Domain PDWB • WebSphere Studio Application Developer 5.1.1 • WebSphere Portal Toolkit 5.0.2.1

PDRP SDWB

CVS

SDPORTAL

SDRP

W

PDREP

PDPORTAL

WebSphere Portal Extend 5.0.2.1

SDREP

PDTAM

Tivoli Access Manager 5.1.0.2 (WebSEAL)

SDTAM

SDLDAP

SDDB

• Tivoli Access Manager 5.1.0.2 (Policy and Authorization) • Tivoli Directory Server 5.2

Figure 3-17 Develop and deploy without debug Table 3-7 Node interaction matrix From

To

Characteristics

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

88

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

It is capable of providing a development environment as follows: 򐂰 An unique environment to develop portal assets 򐂰 Full testing capabilities including security aspects 򐂰 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-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 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. Test Domain

Development Domain PDWB

PDRP SDWB

• WebSphere Studio Application Developer 5.1.1 • WebSphere Portal Toolkit 5.0.2.1

PDREP

SDPORTAL

SDRP

Tivoli Access Manager 5.1.0.2 (WebSEAL)

SDREP

PDPORTAL WebSphere Portal Extend 5.0.2.3

PDTAM SDTAM SDLDAP

CVS

SDDB

• Tivoli Access Manager 5.1.0.2 (Policy and Authorization) • Tivoli Directory Server 5.2

Figure 3-18 Develop, deploy, and remote debugging

Chapter 3. Architecture and topology selection

89

Note: We assume that the Portal Server node is capable of supporting parallel remote debugging sessions. Table 3-8 Node interaction matrix From

To

Characteristics

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.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. It is capable of providing a development environment as follows: 򐂰 򐂰 򐂰 򐂰

An unique environment to develop portal assets Full testing capabilities including security aspects Team development by sharing a repository instance An unique security setup for each developer

The test environment is capable of: 򐂰 򐂰 򐂰 򐂰

90

Sharing a common security infrastructure Supporting a large team of development process Minimizing the required hardware investments Providing a secure portal integration environment

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 򐂰 The specified Reverse Proxy node is placed on a physical node. 򐂰 The specified Policy Server node and specified Directory node are placed on 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.

Tivoli Access Manager 5.1.0.2 (WebSEAL)

Development Domain

Test Domain

PDWB

PDRP

SDWB SDPORTAL • WebSphere Studio Application Developer 5.1.1 • WebSphere Portal Extend V5.0.1 • Portal Toolkit 5.0.2.1

SDRP

PDREP

PDPORTAL

PDTAM

SDREP SDTAM SDLDAP

WebSphere Portal Extend V5.0.2.1

SDDB

• Tivoli Access Manager 5.1.0.2 (Policy & Authorization Servers) • Tivoli Directory Server 5.2

CVS

Figure 3-19 Develop using a shared security infrastructure

Chapter 3. Architecture and topology selection

91

Table 3-9 Node interaction matrix

92

From

To

Characteristics

PDWB

PDREP

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

PDWB

PDRP

HTTP(80) HTTPS(443)

PDRP

PDTAM

LDAPS(636) TAM_SSL(7135)

PDRP

PDWB

HTTP(9081), HTTPS(9444)

PDWB

PDTAM

LDAPS(636)

PDRP

PDPORTAL

HTTP(9081), HTTPS(9444)

PDPORTAL

PDTAM

LDAPS(636)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰

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

© Copyright IBM Corp. 2004. All rights reserved.

93

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

94

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

96

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Cross-Domain SSO

Client-Web App SSO

Portal-Backend SSO

Web Application

Client

Client

Portlet Authentication Proxy

Other Domain Authentication Proxy

Back-end Application

WebSphere Portal Portlet

Back-end Application

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.

Chapter 4. Design and integration guidelines

97

User requests a URL from a web browser

WebSEAL session exists?

No

Is URL accessible to unauthenticated users?

Yes

Is URL accessible to this user?

No

Create a session by setting PD-SSESSION-ID cookie in HTTP response

Yes

No

Yes

Build HTTP request to the junctioned server

Issue the HTTP request and get the response from the junctioned server

Send HTTP 302 response redirecting the web browser to the WebSEAL login page

Create a new session by setting PD-SSESSION-ID cookie in HTTP response

User enters username and password and submits the form

Send HTTP 302 response redirecting the web browser to the original URL

Web browser automatically requests the URL. PD-S-SESSION-ID session cookie is sent to WebSEAL

Validate user credentials in LDAP user registry

Build HTTP response for the user No

Send the response to the user

User credentials valid?

Yes

Send an error 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

98

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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.

Chapter 4. Design and integration guidelines

99

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

100

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 4. Design and integration guidelines

101

Start building the request to the junctioned server

TAI validates in LDAP the WebSEAL user id specified in TAI username property with the extracted password

Create BA header using actual client id and dummy password

User/password combination valid?

No

Yes -c junction option specified?

No

Extract client username from iv_user header Yes

Insert iv_user, iv_groups, iv_creds headers as specified by -c option

iv_user extracted successfully?

No

Yes Send request to WebSphere Application Server

TAI extracts the password from BA header

Use the extracted value as authenticated user id for WebSphere authorization

WebSphere authorization assumes unauthenticated user

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

102

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 File

3

Internet John

WebSEAL

HTTP Request 4 John

WebSphere Application Server John 6

Application

2 Bind Directory

Username=? Password=?

5

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

Chapter 4. Design and integration guidelines

103

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 the current user id

LTPA token valid?

No

Yes Encrypt the LTPA token with the imported LTPA encryption key

Send request to WebSphere Application Server

Use the extracted value as authenticated user id for WebSphere authorization

Use the extracted value as authenticated user id for WebSphere authorization

WebSphere authorization assumes unauthenticated user

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.

104

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 4. Design and integration guidelines

105

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: 򐂰 Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996 򐂰 Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014

106

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 4. Design and integration guidelines

107

򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

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?

108

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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

Chapter 4. Design and integration guidelines

109

logged in user, and a dummy password defined in the webseald-.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.

110

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 access

/portal

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>!

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

Chapter 4. Design and integration guidelines

111

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.

112

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Request

Deny

Deny

No

ACL Satisfied?

Access determined by user/group permissions

Deny

No

Yes

POP Satisfied?

Object access characteristics (for example, audit, time-of-day or day-of-week) for all users and groups

Yes

Rule Decision?

Permit

Access determined dynamically, based on current conditions

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.

Chapter 4. Design and integration guidelines

113

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

114

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 4. Design and integration guidelines

115

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 access

/portal

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.

116

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Browser

WebSEAL

Portal

GET /wps/portal

GET /portal/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. 4. System displays the requested page contents.

Chapter 4. Design and integration guidelines

117

Browser

Portal

WebSEAL GET /portal/wps/myportal HTTP 200 OK (login.html)

Set PD-S-SESSION-ID cookie. Path: /

POST /pkmslogin.form HTTP 302 MOVED to /portal/wps/myportal GET /portal/wps/myportal HTTP 200 OK (customized page)

Set PD-S-SESSION-ID cookie. Path: / GET /wps/myportal HTTP 200 OK (customized page)

Set JSESSIONID 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. 2. WebSEAL performs URL authorization and determines that the requested 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: https://<webseal_fully_qualified_hostname>/portal/wps/myportal

And sends the PD-S-SESSION-ID cookie in the request. 7. WebSEAL forwards the request to the WebSphere Portal. 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.

118

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

4.3.3 UCT3: Access protected portal page with existing valid session This section includes a use case and sequence diagram for access to a 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

Browser GET /portal/wps/myportal

WebSEAL GET /wps/myportal

HTTP 200 OK (customized page) Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies

Portal

HTTP 200 OK (customized page)

Send JSESSIONID cookie

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: https://<webseal_fully_qualified_hostname>/portal/wps/myportal

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. 3. WebSEAL performs URL authorization and determines that the requested resource is accessible to the currently authenticated user. 4. WebSEAL forwards the request to the WebSphere Portal.

Chapter 4. Design and integration guidelines

119

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. 6. WebSEAL performs response URL and cookie filtering and sends the response to the user.

4.3.4 UCT4: Access protected portal page with invalid credentials This section includes a use case and sequence diagram for access to a 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.

Main Scenario

1. Actor accesses protected portal page with a Web browser. 2. System displays the login page. 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.

Browser

Portal

WebSEAL

GET /portal/wps/myportal HTTP 200 OK (login.html)

Set PD-S-SESSIONID cookie. Path: /

POST /pkmslogin.form HTTP 403 ACCESS DENIED

Figure 4-10 Sequence diagram - UCT4 Access protected portal page, invalid credentials

120

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

The steps are: 1. User tries to access 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 or sends a cookie identifying an expired WebSEAL session. 2. WebSEAL performs URL authorization and determines that the requested 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

򐂰 򐂰

򐂰 򐂰 Actors

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.

Customer.

Chapter 4. Design and integration guidelines

121

Use Case ID: UCT5

UCT5: WebSEAL session times out before WebSphere Portal session

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. 4. System displays the requested page contents. 5. After waiting 3 minutes the actor tries to access the same page. 6. System displays the login page. 7. Actor provides valid username and password and submits the page. 8. System displays the requested page contents.

122

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Browser

Portal

WebSEAL

GET /portal/wps/myportal Set PD-S-SESSION-ID cookie. Path: /

HTTP 200 OK (login.html)

POST /pkmslogin.form HTTP 302 MOVED to /portal/wps/myportal GET /portal/wps/myportal

GET /wps/myportal

HTTP 200 OK (customized page)

HTTP 200 OK (customized page)

Set JSESSIONID cookie. Path:/wps

Set AMWEB!%2Fportal!JSESSIONID cookie. Path:/ Wait more than 3 minutes for WebSEAL session timeout Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies GET /portal/wps/myportal HTTP 200 OK (login.html)

Set PD-S-SESSION-ID cookie. Path: /

POST /pkmslogin.form HTTP 302 MOVED to /portal/wps/myportal

Set PD-S-SESSION-ID cookie. Path: / Send JSESSIONID cookie

GET /portal/wps/myportal HTTP 200 OK (customized page)

JSESSIONID session is still valid

GET /wps/myportal HTTP 200 OK (customized page)

Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies

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.

Chapter 4. Design and integration guidelines

123

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: https://<webseal_fully_qualified_hostname>/portal/wps/myportal

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. 6. The user enters a valid username and password and submits the login form (POST /pkmslogin.form). 7. WebSEAL verifies the user credentials and sends the HTTP 302 Moved Temporarily response to the users 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. 8. The browser automatically makes a request to: 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 response to the user.

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.

124

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

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 that there are no established sessions. WebSEAL session timeout is set to 30 minutes. WebSphere Portal session timeout is set to 3 minutes.

Actors

Customer.

Main Scenario

1. Actor accesses protected portal page with an HTML browser. 2. System displays the login page. 3. Actor provides valid username and password and submits the page. 4. System displays the requested page contents. 5. After waiting 3 minutes the actor tries to access the same page. 6. System displays error message. 7. User clicks the Login button. 8. System displays protected home page without asking for username/password.

Chapter 4. Design and integration guidelines

125

Browser

Portal

WebSEAL

GET /portal/wps/myportal HTTP 200 OK (login.html)

Set PD-S-SESSION-ID cookie. Path: /

POST /pkmslogin.form HTTP 302 MOVED to /portal/wps/myportal GET /portal/wps/myportal HTTP 200 OK (customized page)

Set PD-S-SESSION-ID cookie. Path: / GET /wps/myportal HTTP 200 OK (customized page)

Set JSESSIONID cookie. Path:/wps

Set AMWEB!%2Fportal!JSESSIONID cookie. Path:/ Wait more than 3 minutes for WebSphere Portal session inactivity timeout Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies

PD-S-SESSION-ID session is still valid Send JSESSIONID cookie

GET /portal/wps/myportal

GET /wps/myportal

HTTP 302 MOVED to /wps/portal/!ut/p/.scr/ErrorSessionTimeout

HTTP 302 MOVED to /wps/portal/!ut/p/.scr/ErrorSessionTimeout

GET /wps/portal/!ut/p/.scr/ErrorSessionTimeout HTTP 200 OK (session timeout message)

JSESSIONID session has expired Set JSESSIONID cookie. Path:/wps

GET /wps/portal/!ut/p/.scr/ErrorSessionTimeout HTTP 200 OK (session timeout message)

Set AMWEB!%2Fportal!JSESSIONID cookie. Path:/ User clicks the Log in link Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies GET /wps/myportal/!ut/p/.scr/Home HTTP 200 OK (customized home page)

Send JSESSIONID cookie GET /wps/myportal/!ut/p/.scr/Home HTTP 200 OK (customized home page)

Set JSESSIONID cookie. Path:/wps

Set AMWEB!%2Fportal!JSESSIONID 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.

126

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: https://<webseal_fully_qualified_hostname>/portal/wps/myportal

The browser sends the PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies in the request. 4. WebSEAL determines that the user session identified by the 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. 9. WebSEAL performs response URL and cookie filtering and sends the response to the user.

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.

Chapter 4. Design and integration guidelines

127

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.

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 3 minutes.

Actors

Customer.

Main Scenario

1. Actor accesses protected portal page with an HTML browser. 2. System displays the login page. 3. Actor provides valid username and password and submits the page. 4. System displays the requested page contents. 5. After waiting 3 minutes the actor tries to access the same page. 6. System displays the login page. 7. Actor provides valid username and password and 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.

128

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Browser

Portal

WebSEAL

GET /portal/wps/myportal

Set PD-S-SESSION-ID cookie. Path: /

HTTP 200 OK (login.html) POST /pkmslogin.form

Set PD-S-SESSION-ID cookie. Path: /

HTTP 302 MOVED to /portal/wps/myportal GET /portal/wps/myportal

GET /wps/myportal

HTTP 200 OK (customized page)

Set JSESSIONID cookie. Path:/wps

HTTP 200 OK (customized page)

Set AMWEB!%2Fportal!JSESSIONID cookie. Path:/ Wait more than 3 minutes for both WebSEAL and WebSphere Portal session inactivity timeout Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies PD-S-SESSION-ID session has expired

GET /portal/wps/myportal

Set PD-S-SESSION-ID cookie. Path: /

HTTP 200 OK (login.html)

POST /pkmslogin.form

Set PD-S-SESSION-ID cookie. Path: /

HTTP 302 MOVED to /portal/wps/myportal

Send JSESSIONID cookie

Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies GET /portal/wps/myportal

GET /wps/myportal Set JSESSIONID cookie. Path:/wps

Set AMWEB!%2Fportal!JSESSIONID cookie. Path:/ HTTP 302 MOVED to /wps/portal/!ut/p/.scr/ErrorSessionTimeout

JSESSIONID session has expired

HTTP 302 MOVED to /wps/portal/!ut/p/.scr/ErrorSessionTimeout

Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies GET /wps/portal/!ut/p/.scr/ErrorSessionTimeout

GET /wps/portal/!ut/p/.scr/ErrorSessionTimeout

HTTP 200 OK (session timeout message)

HTTP 200 OK (session timeout message)

User clicks the Log in link Send PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies GET /wps/myportal/!ut/p/.scr/Home HTTP 200 OK (customized home page)

Send JSESSIONID cookie GET /wps/myportal/!ut/p/.scr/Home

Set JSESSIONID cookie. Path:/wps

HTTP 200 OK (customized home page)

Set AMWEB!%2Fportal!JSESSIONID cookie. Path:/

Figure 4-13 UCT7: Both WebSEAL and WebSphere Portal sessions time out

Chapter 4. Design and integration guidelines

129

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: https://<webseal_fully_qualified_hostname>/portal/wps/myportal

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. 6. The user enters a valid username and password and submits the login form (POST /pkmslogin.form). 7. WebSEAL verifies the user credentials and sends the 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. WebSEAL creates a new user session by setting the PD-S-SESSION-ID cookie in the response headers. 8. The browser automatically makes a request to: https://<webseal_full_hostname>/portal/wps/myportal

Sending the PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID cookies in the request. 9. WebSEAL determines that the user session identified by the 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. 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.

130

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 response to the user.

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.

Preconditions

򐂰 򐂰 򐂰

The actor has to be a registered user in the system. 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. 2. System displays the login page. 3. Actor provides valid username and password and submits the page. 4. System performs logout and displays the home page for unauthenticated portal users.

Chapter 4. Design and integration guidelines

131

Browser

Portal

WebSEAL

GET /portal/wps/myportal/!ut/p/.cmd/lo HTTP 200 OK (login.html)

PD-S-SESSION-ID session has expired

User enters the username and password POST /pkmslogin.form HTTP 302 MOVED to /portal/wps/myportal/!ut/p/.cmd/lo GET /portal/wps/myportal/!ut/p/.cmd/lo HTTP 302 MOVED to /pkmslogout?filename=wpslogout.html

Set PD-S-SESSION-ID cookie. Path: / GET /wps/myportal/!ut/p/.cmd/lo HTTP 302 MOVED to /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 HTTP 200 OK (default unprotected page)

GET /portal/wps/portal 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. 3. WebSEAL determines that the user session identified by the PD-S-SESSION-ID cookie has expired.

132

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

4. 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. 5. The user enters a valid username and password and submits the login form (POST /pkmslogin.form). 6. WebSEAL verifies the user credentials and sends the HTTP 302 Moved 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 new user session by setting the PD-S-SESSION-ID cookie in the response headers. 7. The browser automatically makes a request to: 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. 8. WebSEAL determines that the user session identified by the 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. 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

Chapter 4. Design and integration guidelines

133

and instructions for security hardening after a functional environment has been built.

134

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Client data

Reverse Proxy node

Security infrastructure

WebSphere Portal node

Administrative communications

33

Policy Server node

IHS Admin

WAS Admin

/portal 3 HTTPS :443 junction

:80

HTTPS

:443

IHS

:8880 :8881

WebSphere_Portal

WAS plugin 4 HTTP

22 DB2

Portal core

:9081

23 LDAP

2

24 IIOP

:7234

User, Portal Admin

WebSEAL

5

30

stopServer serverStatus

9

HTTP

:8880

Admin Console :9080

LDAP Admin, TAM Admin, WAS Admin

IDS Web App

TAM WPM

:389

12 LDAP Admin 13 LDAP

:389 :389

:389

:389

14 LDAP

28

LDAP

:389

21 DB2

:50000 :50001

LDAP DB

:389

LD AP

P LDA

Policy Server/SSL

TAM Administration/SSL

:7135

29

LDAP Admin :3538 Daemon

Access Manager Java Runtime Environment 15

27 LDAP

Policy Server/SSL

server1 HTTP

SOAP/HTTP

11

:9080

8

26 DB2

WebSphere Security

...

HTTP

10

:50000 :50001

Access Manager Java Runtime Environment Authorization aznAPI/SSL

WAS plugin

IHS

ITSO Bank DB

wsadmin startServer

LDAP

:80

IHS Admin

IHS Admin Server

PORTAL DB

:2810

ITSO Bank backend application

:8008

:50000 :50001

:8882

ITSOBankServer

AP LD

HTTP

ITSO Bank portlets 25 IIOP

6

Policy Server/SSL

7

SOAP/HTTPS

HTTP

server1

36

Admin Console

:80

:80

35

SOAP/HTTPS

HTTP :9443

:8008 IHS Admin Server

34

SOAP/HTTPS

HTTP

32

HTTP

31

1

wsadmin startServer stopServer serverStatus ...

xmlaccess

17

20

:7135 18

Policy Server

TAM Administration/SSL :7137

16

Authorization Server

:7136

Policy Server/SSL 19 :7135 :7135

Figure 4-15 Runtime environment component connection diagram

Chapter 4. Design and integration guidelines

135

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

136

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

– 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 – Usage: Tivoli Directory Server administration, Tivoli Access Manager administration, WebSphere Application Server administration 10.Connection from IBM HTTP Server to server1 application server HTTP transport on the Policy Server node. – Protocol: HTTP – Port: 9080 – Usage: Tivoli Directory Server administration, Tivoli Access Manager administration, WebSphere Application Server 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 – Usage: LDAP queries

Chapter 4. Design and integration guidelines

137

15.Secure connection from Tivoli Access Manager Web Portal Manager (TAMWPM) application to Tivoli Access Manager Policy Server. – Protocol: Tivoli Access Manager internal communications over SSL – Port: 7135 – Usage: Tivoli Access Manager internal communications 16.Secure connection from Tivoli Access Manager Policy Server to WebSEAL. – Protocol: Tivoli Access Manager internal communications over SSL – Port: 7234 – Usage: Tivoli Access Manager internal communications 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. – Protocol: Tivoli Access Manager internal communications over SSL – Port: 7137 – Usage: Tivoli Access Manager internal communications 19.Secure connection from Tivoli Access Manager Authorization Server to Tivoli Access Manager Policy Server. – Protocol: Tivoli Access Manager internal communications over SSL – Port: 7135 – Usage: Tivoli Access Manager internal communications 20.Connection from Tivoli Access Manager Authorization Server to LDAP registry (Tivoli Directory Server). – Protocol: LDAP – Port: 389 – Usage: LDAP queries 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). – Protocol: DB2 client – Port: 50000 – Usage: DB2 queries and updates

138

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

23.Connection from WebSphere Portal application to LDAP registry (Tivoli Directory Server). – Protocol: LDAP – Port: 389 – Usage: LDAP queries 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). – Protocol: DB2 client – Port: 50000,50001 – Usage: DB2 queries and updates 27.Connection from ITSO Bank application to LDAP registry (Tivoli Directory Server). – Protocol: LDAP – Port: 389 – Usage: LDAP queries 28.Secure connection from WebSphere Application Server to Tivoli Access Manager Policy Server. – Protocol: Tivoli Access Manager internal communications over SSL – Port: 7135 – Usage: Tivoli Access Manager internal communications 29.Secure connection from WebSphere Application Server to Tivoli Access Manager Authorization Server. – Protocol: Tivoli Access Manager internal communications over SSL – Port: 7136 – Usage: Authorization requests 30.Connection from WebSphere Application Server security services to LDAP registry (Tivoli Directory Server). – Protocol: LDAP

Chapter 4. Design and integration guidelines

139

– Port: 389 – Usage: LDAP queries 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 35.Secure connection from WebSphere Application Server administration utilities (for example wsadmin, startServer, stopServer, serverStatus) to WebSphere_Portal application server SOAP JMX connector on Portal Server node. – Protocol: SOAP over HTTPS – Port: 8881 – Usage: WebSphere_Portal application server administration 36.Secure connection from WebSphere Application Server administration utilities (for example wsadmin, startServer, stopServer, serverStatus) to ITSOBankServer application server SOAP JMX connector on Portal Server node. – Protocol: SOAP over HTTPS – Port: 8882 – Usage: ITSOBank application server administration

140

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Part 2

Part

2

ITSO working example secure portal solution

© Copyright IBM Corp. 2004. All rights reserved.

141

142

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰

Business scenario Business requirements Use case model Architecture

© Copyright IBM Corp. 2004. All rights reserved.

143

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.

144

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

DMZ

Outside Zone

Internal Network

Production Zone

Banking Application

Database Domain

Domain Firewall

Browser User

I N T E R N E T

Domain Firewall

Public Key Infrastructure

Protocol Firewall

Intranet

Internal User

Development 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.

146

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 5. Requirements and solution design

147

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 Maintainability 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.

148

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Transaction Complexity

High frequency (for example, > 100 time per day)

Medium frequency (for example, > 10 times per day but < 100 times per day)

Low frequency (for example, < 10 times per day)

Simple Transaction

1–2

2–3

3–4

Medium Transaction

3–5

4–7

5–10

Complex Transaction

6–10

8–15

11–20

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.

Chapter 5. Requirements and solution design

149

Table 5-2 Throughput requirements Use Cases

Information

Volume Information

Sizing Information

UCF1 UCF2 UCA4 UCA5

Log in and out of the security application: Authentication and authorization.

Small

70% of 20000 customers per day = 14000

UCF3

Add a new user to the application registry: Customer details.

Medium amount of data

100 registrations per day 20000 customer accounts active

UCF4

Modify user information: Customer details.

Medium amount of data

10% of customers = 2000 per day

UCF5

Delete user: Customer details.

Medium amount of data

0.05% customers = 10 per day

UCF6

View transaction history: Data about user transactions.

Large amount of data

All customer accounts once a week

UCF7

View account balance: Account numbers and balance information.

Small amount of data

70% of customers= 14000 per day

UCF8

Transfer funds: Account numbers, balance information, transfer amounts.

Small amount of data

70% of customers = 14000 per day

UCA1 UCA2

Add and delete portlet in WebSphere Portal: Information to publish.

Medium

Once a month

UCA5

Configure security settings: Security configuration data.

Small

Once a month

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.

150

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 5. Requirements and solution design

151

Table 5-3 Availability requirements Use Cases

Service hour

Fallback plan

Availability req high/ medium/ low*

Recovery requirement

Number of outages acceptable

UCF1 UCF2 UCF7 UCF8

Almost 24 hours

Customer uses telephone banking

High

1 hour recovery

2/year

UCF3 UCF4 UCF5

08:00 18:00

Bank staff record data in old system

High

1 hour recovery

4/year

UCF6

08:00 18:00

-

Medium

Next day recovery

4/year

UCA1 UCA2 UCA3 UCA4

20:00 24:00

-

M

Next day

2/month

UCA5

Almost 24 hours

-

VH

1/2 hour

2/year

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: 򐂰 򐂰 򐂰 򐂰 򐂰

152

Audit Access control (authorization) Flow control Identity and credentials (authentication) Solution integrity

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 5. Requirements and solution design

153

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

154

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Secondary Actors

Primary Actors

Customer

Bank Manager

Customer Service Representative

Portal Administrator

Security Administrator

Figure 5-2 ITSO Bank application actors

Primary actors The primary actors in our business scenario are as follows: 򐂰 Customer 򐂰 Customer service representative

Chapter 5. Requirements and solution design

155

򐂰 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

Customer

Transfer Funds

Login to Portal Domain

Banking Application Login

Logout of Portal Domain

Banking Application Logout

Add Portlet

View Account Balance

Edit Portlet

Portal Administrator

Delete Portal Configure Portal Settings Add User Modify User Information

Configure Security Settings

Security Administrator

View Contract History Delete User

Bank Manager

Figure 5-3 Use case diagram

156

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 case ID

Use case name

Goal in context

Actors

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 information in the enterprise directory.

Manager

UCF4

Modify user information

Update a user’s account details.

Manager

UCF5

Delete user

Delete a customer account including customer details.

Manager

UCF6

View transaction history

View the transaction history of a customer.

Manager

UCF7

View account balance

View the balance of a customer account.

Manager Customer

UCF8

Transfer funds

Transfer funds from one account to another.

Customer

Table 5-6 Administrative use cases Use case ID

Use case name

Goal in context

Actors

UCA1

Add portlet

Deploy WebSphere portlet on the productive server.

Portal administrator

UCA2

Delete portlet

Delete WebSphere portlet from the productive server.

Portal administrator

Chapter 5. Requirements and solution design

157

Use case ID

Use case name

Goal in context

Actors

UCA3

Login to Portal domain

Log in to the WebSphere Portal Server administration interface.

Portal administrator

UCA4

Logout of Portal domain

Log out of the WebSphere Portal Server administration interface.

Portal administrator

UCA5

Configure security settings

Configure the settings of the security product.

Security 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

158

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Use Case ID: Name

UCF1: Application login

Chapter/section that fulfills use case

12.5.1, “Banking application login” on page 557.

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.

Secondary actor

None.

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 fulfills use case

None.

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.

Secondary actor

None.

Chapter 5. Requirements and solution design

159

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 fulfills use case

12.5.2, “Add user” on page 559.

Table 5-10 UCF4: Modify user information

160

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.

Primary actor

Bank manager.

Secondary actor

None.

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 fulfills use case

12.5.3, “Modify user information” on page 563.

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.

Precondition

Actor is logged in.

Primary actor

Bank manager.

Secondary actor

None.

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.

Chapter/section that fulfills use case

None.

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.

Precondition

Actor is logged in.

Primary actor

Bank manager.

Chapter 5. Requirements and solution design

161

Use Case ID: Name

UCF6: View transaction history

Secondary actor

None.

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 fulfills use case

None.

Table 5-13 UCF7: View account balance

162

Use Case ID: Name

UCF7: View account balance

Description

This is a primary use case for viewing a user’s account balance.

Precondition

Actor is logged in.

Primary actor

Bank manager/customer.

Secondary actor

None.

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 fulfills use case

12.5.4, “View account balance” on page 566.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Precondition

Actor is logged in.

Primary actor

Customer.

Secondary actor

None.

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 fulfills use case

12.5.5, “Transfer funds” on page 567.

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.

Secondary actor

None.

Chapter 5. Requirements and solution design

163

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 fulfills use case

None.

Table 5-16 UCA2: Delete portlet

164

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.

Primary actor

Portal administrator.

Secondary actor

None.

Main Scenario

1. 2. 3. 4. 5. 6. 7. 8. 9.

Alternatives

None.

Actor clicks Administration. System displays portal user interface. Actor clicks Manage portlets. System displays all pages in content root. Actor navigates to page he wishes to delete portlet from. System displays page. Actor clicks Edit page layout (pencil icon). System displays edit layout page. Actor clicks Delete portlet (trash can icon) for portlet they wish to delete. 10. Actor clicks Done.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Use Case ID: Name

UCA2: Delete portlet

Chapter/section that fulfills use case

None.

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.

Secondary actor

None.

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.

Chapter/section that fulfills use case

None.

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.

Primary actor

Portal administrator.

Secondary actor

None.

Chapter 5. Requirements and solution design

165

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.

Chapter/section that fulfills use case

None.

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.

Secondary actor

None.

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.

Chapter/section that fulfills use case

None.

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.

166

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Database

Portal

Browser

Reverse Proxy

Management Zone

I N T E R N E T

Enterprise Directory

Policy Server

Directory Database

Master 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.

Chapter 5. Requirements and solution design

167

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

168

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 ID

AD01

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.

Chapter 5. Requirements and solution design

169

Architectural decision ID

AD01

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

170

Architectural Decision ID

AD02

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Architectural Decision ID

AD02

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 Architectural decision ID

AD03

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 Architectural decision ID

AD04

Architectural Decision

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

Chapter 5. Requirements and solution design

171

Architectural decision ID

AD04

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 Architectural decision ID

AD05

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

172

Architectural decision ID

AD06

Architectural Decision

The protocol to be used for communication between WebSEAL and the portal server.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Architectural decision ID

AD06

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 Architectural decision ID

AD07

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.

Chapter 5. Requirements and solution design

173

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.

174

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰

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

© Copyright IBM Corp. 2004. All rights reserved.

175

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: 򐂰 Reverse Proxy node 򐂰 Policy Server node 򐂰 Portal Server node Note: We do not include procedures for implementing the firewalls.

176

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Demilitarized Zone

Outside Zone

Production Zone

Tivoli Access Manager 5.1.0.2 (Runtime, PDJRTE, Web Security, WebSEAL) IBM GSKit 7.0.1.16 IBM JRE 1.3.1 Microsoft Windows 2000 Server + SP4

Reverse Proxy Node wswin1

Portal Server Node Domain Firewall

Protocol Firewall

Web Browser Client

I N T E R N E T

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

wpwin1 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 Security 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: 򐂰 Policy Server node – 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 򐂰 Portal Server node – IBM eServer xSeries 230 (8658-61Y) • 1 CPU, Intel PIII 1 GHz • 1152 MB main memory • 18 GB DASD • 1 IBM Ethernet adapter • Hostname: wpwin1.itso.ral.ibm.com 򐂰 Reverse Proxy node – IBM eServer xSeries 230 (8658-61Y) • 1 CPU, Intel PIII 1 GHz • 1152 MB main memory • 18 GB DASD • 1 IBM Ethernet adapter • 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

178

Software

Version

Microsoft Windows 2000 Server

2000 + Service Pack 4

IBM DB2 UDB, Enterprise Server Edition

8.1.4.428 Note: 8.1 + Fixpack 4a

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Software

Version

IBM GSKit

7.0.1.16

IBM Java Runtime Environment (JRE)

1.3.1

IBM WebSphere Application Server

5.0.2 Note: 5.0 + Fixpack 2

IBM Tivoli Directory Server * Directory Server * Directory Client SDK * Web Administration Tool

5.2

IBM Tivoli Access Manager for e-business * Access Manager Runtime * Access Manager Java Runtime Environment (PDJRTE) * Access Manager Policy Server * Access Manager Authorization Server * Access Manager Web Portal Manager

5.1.0.2 Note: 5.1 + Base Fixpack 2

Table 6-2 Reverse Proxy node Software

Version

Microsoft Windows 2000 Server

2000 + Service Pack 4

IBM GSKit

7.0.1.16

IBM Java Runtime Environment (JRE)

1.3.1

IBM Tivoli Access Manager for e-business * Access Manager Runtime * Access Manager Java Runtime Environment (PDJRTE) * Access Manager Web Security Environment *Access Manager WebSEAL

5.1.0.2 Note: 5.1 + WebSEAL Fixpack 2 + Base Fixpack 2

Table 6-3 Portal Server node Software

Version

Microsoft Windows 2000 Server

2000 + Service Pack 4

Chapter 6. Install the runtime environment

179

Software IBM WebSphere Application Server Enterprise * WebSphere Application Server (Base)

Version 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 * WebSphere Portal * WebSphere Portal Content Publisher

5.0.2.1 Note: 5.0 + Fixpack 2 + Cumulative Fix 1 + Fixes

IBM DB2 UDB, Enterprise Server Edition

8.1.4.428 Note: 8.1 + Fixpack 4a

IBM Java Runtime Environment (JRE)

1.3.1

IBM Tivoli Access Manager for e-business * Access Manager Java Runtime Environment (PDJRTE)

5.1.0.2 Note: 5.1 + Base Fixpack 2

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 WebSphere Portal Toolkit Portal InfoCenter

Version 5.0 for Multiplatforms Version 5.0 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 Windows and Linux

Fixpack 1 (V5.0.1)

180

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

CD

WebSphere Portal component

Version

1-17

WebSphere Application Server Fixpack and Fixes

Fixpack 2 (V5.0.2)

2

WebSphere Portal Server WebSphere Portal Content Publisher

Version 5.0 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



IBM HTTP Server V1.3.26.2

c:\ibm\IBMHttpServer



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



IBM Tivoli Access Manager V5.1.0.2

c:\ibm\Tivoli\tam



IBM Tivoli Directory Server V5.2

c:\ibm\ldap



IBM Java Runtime Environment (JRE) V1.3.1

c:\ibm\Java131

<jre_home>

IBM GSKit V7.0.1.16

c:\ibm\gsk7



Chapter 6. Install the runtime environment

181

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: 򐂰 Installation and Configuration Guide, IBM Tivoli Directory Server V5.2, SC32-1338 򐂰 Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339 򐂰 Base Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1362 򐂰 Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360 򐂰 A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager V4.1, SG24-6077, redbook 򐂰 Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-6014, redbook The high-level tasks to install the Policy Server node are as follows: 1. Windows 2000 Server installation

182

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 6. Install the runtime environment

183

– 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 ping nslookup nslookup

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.

184

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 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.

Chapter 6. Install the runtime environment

185

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.

186

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 6. Install the runtime environment

187

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 db2 db2 db2 db2

terminate CONNECT TO BIND \BND\@db2ubind.lst GRANT PUBLIC BIND \BND\@db2cli.lst GRANT PUBLIC terminate

– Where represents the name of a database to which the utilities should be bound. – Where 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

188

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Note: GSKit is included with the IBM HTTP Server V1.3.26 included on the WebSphere Application Server CD.

5.0.5.70

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.

Chapter 6. Install the runtime environment

189

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.

190

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Where 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.

Chapter 6. Install the runtime environment

191

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 \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. 4. When the Welcome window appears, click Next. 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))

192

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 \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.

Chapter 6. Install the runtime environment

193

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.

194

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 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.

Chapter 6. Install the runtime environment

195

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

196

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 \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.

Chapter 6. Install the runtime environment

197

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

198

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

9. When the Node name and Host name window appears, we entered the following and then clicked Next: – 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 Password: <password>

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 \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.

Chapter 6. Install the runtime environment

199

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. 8. When the Welcome window appears, click Next. 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.

200

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: cd \ibm\WebSphere\AppServer\bin 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

Chapter 6. Install the runtime environment

201

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 \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

5. When the Welcome window appears, click Next. 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. – – – –

202

Uncheck Client SDK 5.2. Check Web Administration Tool 5.2. Uncheck Server 5.2. Uncheck IBM WebSphere Application Server - Express 5.0.2.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

– 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

2. Start the WebSphere Application Server Administration Console by entering the following URL in a Web browser: http://: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.

Chapter 6. Install the runtime environment

203

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.

204

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Hostname: tamwin1.itso.ral.ibm.com 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 – Password: <password> 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).

Chapter 6. Install the runtime environment

205

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.

206

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 \windows\PolicyDirector\Disk Images\Disk1 folder and run Setup.exe to start the installer.

Chapter 6. Install the runtime environment

207

6. When the Choose Setup Language window appears, select the desired language (for example, English) and click OK. 7. When the Welcome window appears, click Next. 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 following and then clicked Next: – 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:

208

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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:

Chapter 6. Install the runtime environment

209

– ID: sec_master (greyed out) – Password: <password> – 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:

210

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 following and then clicked Next: – 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.

Chapter 6. Install the runtime environment

211

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.

212

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 6. Install the runtime environment

213

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. 5. Navigate to the \windows\PolicyDirector\Disk Images\Disk1 folder and run Setup.exe to start the installation. 6. When the Choose Setup Language window appears, select the language for the installation process (for example, English) and click OK. 7. When the Welcome window appears, click Next. 8. When the License Agreement window appears, if in agreement, click Yes to continue. 9. When the Select Packages window appears, we checked the following packages and then clicked Next: – 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.

214

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 following and then clicked Next: • • •

Hostname: tamwin1.itso.ral.ibm.com 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.

Chapter 6. Install the runtime environment

215

d. When the Policy Server Information window appears, we entered the following and clicked Next: • •

Hostname: tamwin1.itso.ral.ibm.com 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:///pdadmin

Where 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 – Password: <password> 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

216

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 – Access Manager Policy 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). 7. When the Welcome window appears, click Next. 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.

Chapter 6. Install the runtime environment

217

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: 򐂰 Web Security Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1361 򐂰 WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1359 򐂰 A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager V4.1, SG24-6077, redbook The high level tasks to install the Reverse Proxy node are as follows: 1. Windows 2000 Server installation.

218

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

2. 3. 4. 5. 6. 7. 8.

Install GSKit. Install Java Runtime Environment (JRE) Install Tivoli Directory Client. Tivoli Access Manager - WebSEAL installation. Tivoli Access Manager - WebSEAL configuration. Tivoli Access Manager V5.1 Base Fixpack 2 installation. Tivoli Access Manager V5.1 WebSEAL Fixpack 2 installation.

6.3.1 Windows 2000 Server 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 \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. 4. When the Welcome window appears, click Next. 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.

Chapter 6. Install the runtime environment

219

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.

220

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 3. Navigate to the \windows\PolicyDirector\Disk Images\Disk1 folder and run Setup.exe to start the installation program. 4. When the Choose Setup Language window appears, select the desired language (for example, English) and click OK. 5. When the Welcome window appears, click Next. 6. When the License Agreement window appears, review the terms and, if in agreement, click Yes. 7. When the Select Packages window appears, we checked the following packages and then clicked Next: – – – –

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 agreement, click Yes. c. When the Access Manager Java Runtime Environment Choose Destination Directory window appears, we did the following: i. Click Browse.

Chapter 6. Install the runtime environment

221

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 agreement, click Yes. 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:

222

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

• •

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 following and then clicked Next: • •

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).

Chapter 6. Install the runtime environment

223

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 -webseald- (for example, default-webseald-wswin1).

•

Listening port: 7234

d. When the Administrator Identification page appears, enter the following and then click Next: • •

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.

224

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 6. Install the runtime environment

225

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- 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: http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2b Tivoli+%2bAccess+%2bManager&uid=swg24006926&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\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). 7. When the Welcome window appears, click Next. 8. When the License Agreement window appears, review the terms and, if in agreement, click Yes. 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.

226

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 򐂰 A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager V4.1, SG24-6077, redbook The high-level tasks to install the Portal Server node are as follows: 1. 2. 3. 4. 5. 6.

Windows 2000 Server installation WebSphere Portal Server V5.0 installation WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2) installation WebSphere Application Server V5.0.2 Fixes installation WebSphere Portal V5 Fixpack 2 (V5.0.2) installation 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

Chapter 6. Install the runtime environment

227

6.4.1 Windows 2000 Server 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 language (for example, English) and click OK. 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:

228

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

– 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. – Password: <password> 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.

Chapter 6. Install the runtime environment

229

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 – Password: <password> 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.

230

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 6. Install the runtime environment

231

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: 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

232

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 6. Install the runtime environment

233

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

234

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 6. Install the runtime environment

235

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 \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

4. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 5. When the Welcome window appears, click Next. 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> 11.Review the fixpack settings and then click Next to begin the fixpack installation of files. 12.When the WebSphere Application Server V5 Base Fixpack 2 installation is complete, click Finish.

236

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 \pmefp2\win directory of the WebSphere Application Server Fixpack and eFixes for Windows and Linux CD to a temporary directory (for example, c:\temp\was5pme.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 PME Fixpack 2 we entered the following: c:\temp\was5pme.fp2\updateWizard.bat

4. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 5. When the Welcome window appears, click Next. 6. The WebSphere Update Installer will detect your current WebSphere 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). 7. Select Install fix packs and then click Next. 8. Enter the directory where you have copied the fixpack. For example, we 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. 10.Review the fixpack settings and then click Next to begin the fixpack installation of files. 11.When the WebSphere Application Server V5 PME Fixpack 2 installation is complete, click Finish.

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.

Chapter 6. Install the runtime environment

237

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 PQ78382_fix.jar PQ78882_Fix.jar PQ79083_5.0.2_Fix.jar PQ79193_fix.jar PQ81020_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: – WebSphere Application Server Enterprise (all application servers including server1, WebSphere_Portal) – IBM HTTP Server – IBM HTTP Administration Server 2. Copy the WebSphere Application Server V5.0.2 Fixes files and sub directories found in the \fixes\win directory of the WebSphere Application Server Fixpack and eFixes for Windows and Linux CD to a temporary directory (for example, c:\temp\was502.efixes). 3. Set up the environment by running the setupCmdLine.bat as follows: c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat

4. To start the WebSphere Update Installer (updateWizard.bat) supplied with WebSphere Application Server PME Fixpack 2 we entered the following: c:\temp\was502.efixes\updateWizard.bat

238

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

5. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 6. When the Welcome window appears, click Next. 7. The WebSphere Update Installer will detect your current WebSphere 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.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. 9. Enter the directory where you have copied the fixpack. For example, we 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 installation of files. 12.When the WebSphere Application Server V5.0.2 Fixes installation is complete, click Finish.

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.

Chapter 6. Install the runtime environment

239

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.

240

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 6. Install the runtime environment

241

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. c:\ibm\WebSphere\PortalServer\config\WPSConfig.bat WP-PTF-502 -DPortalAdminPwd=<password>

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.

242

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Refer to the Managing documents → Document Manager → Search topic in the WebSphere Portal Information Center for details on setting the update interval: http://www.ibm.com/websphere/portal/library

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).

Chapter 6. Install the runtime environment

243

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: – WebSphere Application Server Enterprise (all application servers including server1, WebSphere_Portal) – IBM HTTP Server – IBM HTTP Administration 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: http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg24005 952

2. Unpack the cumulative fix download (was502_cf2_win.zip) to a temporary directory (for example, c:\temp\was502.cf2). 3. To start the WebSphere Update Installer (updateWizard.bat) supplied with WebSphere Application Server Cumulative Fix 2, we entered the following in a command window: c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat c:\temp\was502.cf2\updateWizard.bat

4. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 5. When the Welcome window appears, click Next.

244

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

6. The WebSphere Update Installer will detect your current WebSphere Application Server version. Click Next. The version should be IBM WebSphere Application Server V5.0.2 + Enterprise V5.0.2, and installation directory c:\ibm\WebSphere\AppServer. Note: If the base version is not detected, enter the path to the WebSphere Application Server installation directory. 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\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 installation of files. 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 Cumulative Fix 2 (V5.0.2.2), do the following: 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 download for each platform can be found at: 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 (c:\temp) on the Portal Server node from the following URL: http://www-1.ibm.com/support/docview.wss?rs=823&context=SS4QY3&uid=swg24005 954

Chapter 6. Install the runtime environment

245

2. Unpack the cumulative fix download (was502_pme_cf2_win.zip) to a temporary directory (for example, c:\temp\was502pme.cf2). 3. To start the WebSphere Update Installer (updateWizard.bat) supplied with WebSphere Application Server PME Cumulative Fix 2, we entered the following in a command window: c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat c:\temp\was502pme.cf2\updateWizard.bat

4. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 5. When the Welcome window appears, click Next. 6. The WebSphere Update Installer will detect your current WebSphere Application Server version. Click Next. The version should be IBM WebSphere Application Server V5.0.2.2 + Enterprise V5.0.2, and 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. 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\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 complete, click Finish.

Install WebSphere Application Server Cumulative Fix 3 To download and install the WebSphere Application Server V5.0.2 (Base) Cumulative Fix 3 (V5.0.2.3), do the following: 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 download for each platform can be found at: http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg240 06289

246

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 (c:\temp) on the Portal Server node from the following URL: http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg24006 289

2. Unpack the cumulative fix download (was502_cf3_win.zip) to a temporary directory (for example, c:\temp\was502.cf3). 3. To start the WebSphere Update Installer (updateWizard.bat) supplied with WebSphere Application Server Cumulative Fix 3, we entered the following in a command window: c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat c:\temp\was502.cf3\updateWizard.bat

4. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 5. When the Welcome window appears, click Next. 6. The WebSphere Update Installer will detect your current WebSphere Application Server version. Click Next. The version should be IBM WebSphere Application Server V5.0.2.2 + Enterprise V5.0.2.2, and 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. 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\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

Chapter 6. Install the runtime environment

247

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 򐂰 WebSphere Application Server V5.0.2.2 򐂰 WebSphere Application Server V5.0.2.3 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

248

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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). 3. To start the WebSphere Update Installer (updateWizard.bat) supplied with the efixes download, we entered the following in a command window: c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat c:\temp\was5023.fixes\updateWizard.bat

4. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 5. When the Welcome window appears, click Next. 6. The WebSphere Update Installer will detect your current WebSphere Application Server version. Click Next. The version should be IBM WebSphere Application Server V5.0.2.3 + Enterprise V5.0.2.2, and 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. 7. Select Install fixes and then click Next. 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

Chapter 6. Install the runtime environment

249

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 complete, click Finish.

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.

250

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 6. Install the runtime environment

251

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)

252

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: c:\ibm\WebSphere\PortalServer\config\WPSConfig.bat WP-PTF-5021 -DPortalAdminPwd=<password>

Where <password> is the WebSphere Portal administrator password.

Chapter 6. Install the runtime environment

253

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. c:\ibm\WebSphere\PortalServer\config\WPSConfig.bat WP-PTF-5021 -DPortalAdminPwd=<password>

For details refer to the WebSphere Portal V5 Cumulative fix readme (install_win_unix.html) found at: http://publib.boulder.ibm.com/pvc/wp/5021/ent/en/readme/install.html

4. Restart WebSphere Application Server: cd /ibm/websphere/appserver/bin stopServer server1 startServer server1

5. Restart WebSphere Portal Server: stopServer WebSphere_Portal 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.

6.4.8 Java Runtime Environment (JRE) V1.3.1 installation 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.

254

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: – IBM Tivoli Directory Server V5.2 – Access Manager Policy Server 2. Insert the Tivoli Access Manager Base for Windows NT, Windows XP, Windows 2000 and Windows 2003 CD. 3. Navigate to the \windows\PolicyDirector\Disk Images\Disk1 folder and run Setup.exe to start the installation. 4. When the Choose Setup Language window appears, select the language for the installation process (for example, English) and click OK. 5. When the Welcome window appears, click Next. 6. When the License Agreement window appears, if in agreement click Yes to continue. 7. When the Select Packages window appears, we checked the following 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.

Chapter 6. Install the runtime environment

255

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: 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

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. 2. 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). 3. When the Welcome window appears, click Next. 4. When the License Agreement window appears, review the terms and, if in agreement, click Yes. 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

You should see the following message: Configuration of Access Manager Java Runtime Environment completed successfully.

256

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Configure PDJRTE for standalone JRE V1.3.1 To configure the Tivoli Access Manager Java Runtime Environment (PDJRTE) 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. 2. Enter the following command: pdjrtecfg -action config -config_type full -host tamwin1.itso.ral.ibm.com -port 7135 -java_home c:\ibm\Java131\jre

You should see the following message: Configuration of Access Manager Java Runtime Environment completed 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.

Chapter 6. Install the runtime environment

257

258

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

© Copyright IBM Corp. 2004. All rights reserved.

259

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

260

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 wpconfig.properties file

Keyword

ITSO value

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



DbLibrary

c:/ibm/sqllib/java/db2java.zip Note: Directory is java ,not java12

WpsDsName

wps50DS

WpsXDbName

wps5TCP

WpsDbNode

wpsNode

WpcpDbNode

wcmNode

WpcpXDbName

wpcp5TCP

FeedbackXDbName

fdbk5TCP

WpcpDbName

wpcp50 Note: Seperate database

WpcpDbUser

db2admin

WpcpDbPassword



WpcpDbUrl

jdbc:db2:wpcp50

WpcpDbEjbPassword

<ejb_password> (user defined)

FeedbackDbName

fdbk50

FeedbackDbUser

db2admin

FeedbackDbPassword



FeedbackDbUrl

jdbc:db2:fdbk50

WebSphere Portal content publishing Database properties

262

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Section of wpconfig.properties file

Keyword

ITSO value

Member Manager properties

WmmDsName

wmmDS

WmmDbName

wps50

WmmDbUser

db2admin

WmmDbPassword



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.

Chapter 7. Configure the runtime environment

263

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 db2 reorgchk update statistics on table all db2 terminate db2rbind -l db2rbind.out -u -p <password>

11.Start the WebSphere Portal server as follows: cd \ibm\WebSphere\AppServer\bin startServer WebSphere_Portal

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. 3. Back up the WebSphere Portal configuration properties found in the wpconfig.properties file by entering the following command: wpsconfig backup-main-cfg-file

264

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html 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

5. Save the updated wpconfig.properties file. 6. Enter the following command to configure WebSphere Portal Server for the external Web server: wpsconfig httpserver-config

7. Restart the IBM HTTP Server. 8. Restart the WebSphere Portal Server: a. Open a command prompt change to the WebSphere Application Server bin directory: cd \ibm\WebSphere\AppServer\bin

b. Confirm that the WebSphere Portal Server is stopped: stopServer WebSphere_Portal

c. Wait for confirmation that the server instance is stopped or cannot be reached. Then start the server: startServer WebSphere_Portal

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, http://wpwin1.itso.ral.ibm.com:9081/wps/portal

Now that we have configured the external Web server, we do not need to specify the port (default port 80) in the URL: http://wpwin1.itso.ral.ibm.com/wps/portal

Chapter 7. Configure the runtime environment

265

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: http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

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.

266

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

uid=wpsadmin

cn=groups

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

Chapter 7. Configure the runtime environment

267

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 objectclass: organizationalPerson objectclass: inetOrgPerson 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).

268

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

3. Start the Tivoli Directory Server Configuration Tool by clicking Start → Programs → IBM Tivoli Directory Server V5.2 → Directory 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.

Chapter 7. Configure the runtime environment

269

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...wmm (for example, wmm_LDAP.xml.IBM_DIRECTORY_SERVER.1.wmm) – wmmLDAPAttributes_.xml (for example, wmmLDAPAttributes_IBM_DIRECTORY_SERVER.xml) Note: Explanation of naming constructs for wmm xml files: 򐂰 is the type of LDAP server that is being used, such as IBM_DIRECTORY_SERVER or DOMINO502. 򐂰 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 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">

270

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1



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) pluginAttributeName="ibm-entryUuid" dataType="String" multiValued="false" readOnly="true"/> defaultValue="uid=dummy" />

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.

Chapter 7. Configure the runtime environment

271

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. 2. Back up the WebSphere Portal configuration properties found in the wpconfig.properties file by entering the following command: wpsconfig backup-main-cfg-file

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): http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

272

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Example 7-4 ITSO example wpconfig.properties values for LDAP security Section in wpconfig.properties file

Keyword

ITSO example value

WebSphere Application Server Properties

WasUserid

uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com

WasPassword

<password>

Portal Configuration Properties

PortalAdminId

uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com

PortalAdminIdShort

wpsadmin

PortalAdminPwd

<password>

PortalAdminGroupId

cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com

PortalAdminGroupId Short

wpsadmins

LTPAPassword

<password>

LTPATimeout

120

SSODomainName

itso.ral.ibm.com

Lookaside

false

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>

WebSphere Portal Security LTPA and SSO Configuration

LDAP Properties Configuration

Chapter 7. Configure the runtime environment

273

Section in wpconfig.properties file

Keyword

ITSO example value

Advanced LDAP Configuration

LDAPSuffix

dc=itso,dc=ibm,dc=com

LdapUserPrefix

uid

LDAPUserSuffix

cn=users

LdapGroupPrefix

cn

LDAPGroupSuffix

cn=groups

LDAPUserObjectCla ss

inetOrgPerson

LDAPGroupObjectCl ass

groupOfUniqueNames

LDAPGroupMember

uniqueMember

LDAPUserFilter

(&(uid=%v)(objectclass=inetOrgPerson))

LDAPGroupFilter

(&(cn=%v)(objectclass=groupOfUniqueNames))

LDAPsslEnabled

false

4. Save the updated wpconfig.properties file. 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 stopServer WebSphere_Portal

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

274

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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] [xmlaccess] [xmlaccess] com.ibm.wps.command.xml.XmlCommandServlet$AuthorizationException: XMLC0005E: Authorization for user wpsadmin failed. [xmlaccess] . . . . 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

Chapter 7. Configure the runtime environment

275

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: http://wpwin1.itso.ral.ibm.com/wps/portal

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.

276

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

The section is organized into the following tasks: 1. 2. 3. 4. 5. 6. 7.

IBM HTTP Server SSL configuration. Configure WebSphere Portal for SSL. Export IBM HTTP Server CA certificate. Import IBM HTTP Server certificate into WebSEAL keystore. Export WebSEAL certificate. Import WebSEAL certificate into IBM HTTP Server keystore. 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 \\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 \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

– Uncomment the IBM SSL module for the given SSL encryption level (56 or 128 bit). For example: LoadModule ibm_ssl_module/IBMModuleSSL128.dll

Chapter 7. Configure the runtime environment

277

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:

Note: Substitute your fully qualified host name in this line (for example, ). – Uncomment: SSLEnable

– Uncomment:

– 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 \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"

278

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: \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: (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:

Chapter 7. Configure the runtime environment

279

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: – 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”

280

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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://

򐂰 Verify HTTPS: https://

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.

Chapter 7. Configure the runtime environment

281

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 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> /myportal/*

282

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

DELETE GET POST PUT <description> All Role <user-data-constraint id="UserDataConstraint_4"> CONFIDENTIAL

4. Save and close the web.xml file. 5. Restart the WebSphere_Portal application server. 6. Restart the IBM HTTP 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 \conf\httpd.conf file. Search for Keyfile (for example, Keyfile "c:\ibm\IBMHttpServer/ssl/keyfile.kdb").

Chapter 7. Configure the runtime environment

283

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

284

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 set JAVA_HOME=c:\ibm\Java131\jre gsk7ikm

5. From the menu bar select Key Database File → Open. 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 following and then clicked OK: – Data type: Select Base64-encoded ASCII data. – Certificate file name: wp_httpd_cert.arm – Location: c:/ibm/Tivoli/PDWeb/www-default/certs

Chapter 7. Configure the runtime environment

285

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).

286

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

3. Click Extract Certificate. 4. 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: webseal_default_cert.arm – Location: c:/ibm/Tivoli/PDWeb/www-default/certs 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. 3. From the menu bar select Key Database File → Open. 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 following and then clicked OK:

Chapter 7. Configure the runtime environment

287

– 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
5. Save the changes to the httpd.conf file. 6. Restart the IBM HTTP Server. 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

288

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This section includes the following tasks: 1. 2. 3. 4. 5. 6. 7. 8.

Apply Tivoli Access Manager ACLs to new LDAP suffixes. Define additional MIME types for WebSphere Application Server. Create a WebSEAL junction. Enable forms authentication on WebSEAL. Configure WebSEAL to modify URLs to back-end systems. Configure additional WebSEAL parameters. Import WebSphere Portal users and groups into TAM. Define access controls for WebSphere Portal URIs.

Chapter 7. Configure the runtime environment

289

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

290

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. – Username: cn=root – Password: <password> 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).

Chapter 7. Configure the runtime environment

291

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: 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: cn=ivacld-servers,cn=SecurityGroups,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-5 on page 293): • •

292

Add child: Leave blank. Delete entry: Leave blank.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

•

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: 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: cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default Type: Select group.

Chapter 7. Configure the runtime environment

293

c. When the Add access rights page appears, do the following and then click OK at the bottom of the page (see Figure 7-6 on page 294): • • •

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-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: 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: • •

294

Check Propagate ACLs. DN: cn=anybody

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

•

Type: Select group.

c. When the Add access rights page appears, do the following and then click OK at the bottom of of page (see Figure 7-7): • • •

Add child: Leave blank. Delete entry: Leave blank. 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.

Chapter 7. Configure the runtime environment

295

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.

296

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Web Browser Client

HTTP

Port 80

WebSEAL instance (default-webseald-wswin1)

Port 443 HTTPS

HTTP Server for 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

Chapter 7. Configure the runtime environment

297

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 -p -j -w -c all -K “” -D “” <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. – , in our example this is Portal Server node. – ,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 is the WebSEAL key label on the Reverse Proxy node. – -D 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

298

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 7. Configure the runtime environment

299

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 ba-auth = none

[forms] #-------------------------#Forms #-------------------------#Enable authentication using forms #One of 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.

300

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 7. Configure the runtime environment

301

To enable WebSEAL URL filtering, do the following: 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-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

4. Save the webseald-default.conf file. 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.

302

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 1. Navigate to the c:\ibm\Tivoli\PDWeb\etc directory. 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

3. Save the webseald-default.conf file. 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

Chapter 7. Configure the runtime environment

303

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

304

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

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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/myportal /portal/wps/config /portal/wps/doc /portal/wps

/portal/wps/portal* /portal/wps/myportal* /portal/wps/config* /portal/wps/doc* /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.

Chapter 7. Configure the runtime environment

305

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

306

acl acl acl acl

create create create create

WP_all_access WP_authenticated_access WP_admin_access WP_no_access

acl acl acl acl acl acl acl acl acl acl acl

modify modify modify modify modify modify modify modify modify modify modify

WP_admin_access set user sec_master TcmdbsvaBrxl WP_admin_access set group iv-admin Tcmdbsvarxl WP_admin_access set group webseal-servers Tgmdbsrxl WP_admin_access set group wpsadmins Tr WP_admin_access set any-other T WP_admin_access set unauthenticated T WP_no_access set user sec_master TcmdbsvaBrxl WP_no_access set group iv-admin Tcmdbsvarxl WP_no_access set group webseal-servers Tgmdbsrxl WP_no_access set group wpsadmins T WP_no_access set any-other T

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

acl acl acl acl acl acl acl acl acl acl acl acl acl

modify modify modify modify modify modify modify modify modify modify modify modify modify

WP_no_access set unauthenticated T WP_authenticated_access set user sec_master TcmdbsvaBrxl WP_authenticated_access set group iv-admin Tcmdbsvarxl WP_authenticated_access set group webseal-servers Tgmdbsrxl WP_authenticated_access set group wpsadmins Tr WP_authenticated_access set any-other Tr WP_authenticated_access set unauthenticated T WP_all_access set user sec_master TcmdbsvaBrxl WP_all_access set group iv-admin Tcmdbsvarxl WP_all_access set group webseal-servers Tgmdbsrxl WP_all_access set group wpsadmins Tr WP_all_access set any-other Tr WP_all_access set unauthenticated Tr

acl acl acl acl acl

attach attach attach attach attach

/WebSEAL/wswin1-default/portal/wps/config WP_admin_access /WebSEAL/wswin1-default/portal/wps/myportal WP_authenticated_access /WebSEAL/wswin1-default/portal/wps/portal WP_all_access /WebSEAL/wswin1-default/portal/wps/doc WP_all_access /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.

Chapter 7. Configure the runtime environment

307

Example 7-13 ITSO example jmt.conf /portal /wps/*

3. Save and close the file. 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.

308

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 7. Configure the runtime environment

309

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 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.

310

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 7. Configure the runtime environment

311

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

312

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 FORM WPS /myportal /error.html

4. Save and close the file.

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:

Chapter 7. Configure the runtime environment

313

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 <script language=javascript type="text/javascript">
314

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

var cookie_string = "" + document . cookie; var cookie_array = cookie_string . split ("; "); // Delete each cookie ... // EXCEPT those whose naems appear in the semicolon delimited list // passed in as the second parameter to this function for (var i = 0; i < cookie_array . length; ++ i) { var single_cookie = cookie_array [i] . split ("="); var name = single_cookie [0]; if (name_in_list(name, exceptions) == false) delete_cookie (name, path); } } // --> <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"> User %USERNAME% has logged out.





Redirecting to public portal page ... select here if your browser does not automatically redirect after 2 seconds.

3. Save and close the file.

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.

Chapter 7. Configure the runtime environment

315

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">
316

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

// Get cookie list and split into an array of cookie entries var cookie_string = "" + document . cookie; var cookie_array = cookie_string . split ("; "); // Delete each cookie ... // EXCEPT those whose naems appear in the semicolon delimited list // passed in as the second parameter to this function for (var i = 0; i < cookie_array . length; ++ i) { var single_cookie = cookie_array [i] . split ("="); var name = single_cookie [0]; if (name_in_list(name, exceptions) == false) delete_cookie (name, path); } } // --> <meta http-equiv="Content-Type" content= "text/html; charset=UTF-8"> User %USERNAME% has logged out.

4. Save and close the file.

Modify ConfigService.properties To modify the WebSphere Portal logout command to point to the WebSEAL logout command, do the following: 1. Navigate to the following directory on the Portal Server node: 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.

Chapter 7. Configure the runtime environment

317

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

4. Save and close the file.

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/ directory for each theme. Modify the ToolBarInclude.jsp for each occurrence of the file, as follows: 1. Navigate to the following directory on the Portal Server node: Root directory: c:/ibm/WebSphere/AppServer/installedApps/wpwin1/wps.ear/wps.war/themes/html

Or Theme directory: c:/ibm/WebSphere/AppServer/installedApps/wpwin1/wps.ear/wps.war/themes/html /

318

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Where 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"> <wps:text key="link.password" bundle="nls.engine"/>

--%> <%-- selfcare button --%>

<%-<wps:if loggedIn="yes" notScreen="SelfcareUserForm,SelfcareUserConf" portletSolo="no"> <wps:text key="link.selfcare" bundle="nls.engine"/>

--%> <%-- enroll button --%>

<%-<wps:if loggedIn="no"> <% String dt = com.ibm.wps.puma.UserManager.instance().getDirectoryType(); if (dt==null) { dt = "";

Chapter 7. Configure the runtime environment

319

} if (!dt.equals("SSPM")) { %> <wps:text key="link.enrollment" bundle="nls.engine"/> <% } %>

--%> <%--

Edit the login button section as follows:

--%>

<%-- login button --%> <wps:if loggedIn="no" notScreen="Login"> <wps:text key="link.login" bundle="nls.engine"/>

4. Edit the login button section as seen in Example 7-18 on page 319 for each theme used. 5. Save and close the file. 6. Open and save the version of Default.jsp found in the root of the html directory and corresponding theme directory (if they exist). c:/ibm/WebSphere/AppServer/installedApps/wpwin1/wps.ear/wps.war/themes/html /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): WpsHostName=wpwin1.itso.ral.ibm.com

320

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

To (Reverse Proxy node hostname): WpsHostName=wswin1.itso.ral.ibm.com

3. Save and close the file. 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

5. Restart the WebSphere_Portal application server.

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> <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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

Chapter 7. Configure the runtime environment

321

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.

322

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.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

– 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. – is the pdmgrd host (pdmgrd is a Tivoli Access Manager process). – is the pdacld host (pdacld is a Tivoli Access Manager process). – is the pdmgrd port. The default port number is 7135. – is the pdacld port. The default port number is 7136. – is the rank of the host. If only one host is specified, this value is 1. – 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.

Chapter 7. Configure the runtime environment

323

– 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_pwd <password> -appsvr_id <was_id> -port <port_number> -mode remote -policysvr :: -authzsvr :: -cfg_file "" -key_file "" -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: pdadmin -a sec_master -p <password>

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:

324

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

1. Modify ConfigService.properties. a. Navigate to the following directory on the Portal Server node: c:\ibm\WebSphere\PortalServer\shared\app\config\services

b. Modify the ConfigService.properties file as follows: execute.portal.jaas.login=true

c. Save and close the file. 2. Modify callbackheaderslist.properties. a. Navigate to the following directory on the Portal Server node: 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

c. Save and close the file. 3. Modify ExternalAccessControlService.properties. a. Navigate to the following directory on the Portal Server node: c:\ibm\WebSphere\PortalServer\shared\app\config\services

b. Modify the ExternalAccessControlService.properties file as follows: externalaccesscontrol.pdurl=file:///c:/ibm/WebSphere/AppServer/java/jre/ PdPerm.properties

c. Save and close the file.

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.

Chapter 7. Configure the runtime environment

325

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: cd \ibm\WebSphere\AppServer\bin 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: https://wpwin1.itso.ral.ibm.com:9043/admin

b. Enter WebSphere administrator credentials (for example, wpsbind). 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

326

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

•

Authentication Strategy: Select REQUIRED.

f. From the JAAS Login Modules page, click the following under Module Classname: com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy

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. 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 (ensure that you click the second listed module) com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy

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.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.

Chapter 7. Configure the runtime environment

327

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. a. From the WebSphere Application Server Administrative Console, select Security → JAAS Configuration → Application Logins. 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.

328

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy

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

6. Add the com.tivoli.mts.PDLoginModule to the Portal_SubjectRebuild 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_SubjectRebuild. c. From the Portal_SubjectRebuild 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 (ensure that you click the second listed module). com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy

g. Click Custom Properties in the Additional Properties section. h. Click New.

Chapter 7. Configure the runtime environment

329

i. From the New Custom Properties page, enter the following and then click 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.

330

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

8. When the Save to Master Configuration page appears, 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

Chapter 7. Configure the runtime environment

331

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]

332

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

externalaccesscontrol.pdaction=m

3. Save and close the file. 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 <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 .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

4. Save and close the file.

Chapter 7. Configure the runtime environment

333

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

4. Save and close the file.

Modify AccessControlDataManagementService.properties To modify the AccessControlDataManagementService.properties file, do the following: 1. Navigate to the <wp_home>/shared/app/config/services directory. 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

334

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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). 5. Save and close the file.

Chapter 7. Configure the runtime environment

335

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: 1. Navigate to the <wp_home>/shared/app/config/services directory. 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. 4. Save and close the file. 5. Restart the WebSphere_Portal application server.

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.

336

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: pdadmin -a sec_master -p <password>

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.

Chapter 7. Configure the runtime environment

337

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.

338

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 YourCo Financial pages

Administrator

YourCo Financial

wpsadmins

Privileged User

User

anonymous portal user

Home

wpsadmins

All authenticated portal users

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 portal users

anonymous portal user

Sales

wpsadmins

All authenticated portal users

anonymous portal user

Customer Support

wpsadmins

All authenticated portal users

anonymous 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.

Chapter 7. Configure the runtime environment

339

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.

340

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 7. Configure the runtime environment

341

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.

342

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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).

Chapter 7. Configure the runtime environment

343

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.

344

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 7. Configure the runtime environment

345

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.

346

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

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

Chapter 7. Configure the runtime environment

347

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

348

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 file in the <wp_home>\shared\app\config\services directory. Where 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 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.

Chapter 7. Configure the runtime environment

349

<was_home>\bin\PropFilePasswordEncoder.bat <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 .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. 9. Restart the WebSphere_Portal application server.

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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

2. Log in with the credentials for the WebSphere Portal admin user.

350

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: a. Open a command window on the Policy Server node. b. Enter the following command to log in to pdadmin: pdadmin -a sec_master -p <password>

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.

Chapter 7. Configure the runtime environment

351

Example 7-24 ITSO Example authentication realm definition in httpd.conf AuthName "ITSO_Test_Realm" AuthType Basic AuthUserFile "C:\ibm\IBMHttpServer/conf/itso.passwd" require valid-user AllowOverride None order allow,deny allow from all

3. Save and close the file. 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 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Congratulations, your Credential Vault integration was successful!

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:

352

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

• •

Name: vault_test Password: passw0rd

You should see the message: Congratulations, your Credential Vault integration was successful! 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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

2. Log in with the credentials for the WebSphere Portal admin user. 3. Click Administration. 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.

Chapter 7. Configure the runtime environment

353

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.

354

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: Congratulations, your Credential Vault integration was successful!

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 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 value to a new password. 4. Save and close the file. 5. Open a Windows command window (not pdadmin). 6. From the Windows command line, change to the directory of the vault-test-acl.pd and enter the following command: pdadmin -a sec_master vault-test-acl.pd

7. When prompted for the password, enter the sec_master password. 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.

Chapter 7. Configure the runtime environment

355

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 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: Congratulations, your Credential Vault integration was successful!

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.

356

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: cd \ibm\WebSphere\AppServer\bin startServer server1

2. Start the WebSphere Application Server Administration Console by entering the following URL in a Web browser: 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. 10.When the Save to Master Configuration page appears, 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:

Chapter 7. Configure the runtime environment

357

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: 1. Navigate to the c:\ibm\Tivoli\PDWeb\etc directory. 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

358

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Guide, IBM Tivoli Access Manager V5.1, SC32-1359, product guide. 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. pdadmin -a sec_master -p <password>

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).

Chapter 7. Configure the runtime environment

359

360

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

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)

© Copyright IBM Corp. 2004. All rights reserved.

361

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.

Web Browser Client

Reverse Proxy Node

Development Node

Tivoli WebSEAL

WebSphere Portal for Test Environment

wsdev1.itso.ral.ibm.com

Portal Toolkit

WebSphere Studio Application Developer

Other Other Clients Clients

wpdev1.itso.ral.ibm.com

Policy Server Node

Tivoli Access Manager

Tivoli Directory Server

WebSphere Application Server

DB2 UDB Server

tamdev1.itso.ral.ibm.com

Repository Node CVSNT 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.

362

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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 512 MB main memory 6 GB harddisk 1 IBM Ethernet Adapter Hostname: cvsnt1.itso.ral.ibm.com

򐂰 Policy Server node – VMWare image • • • • •

1 CPU, Intel Pentium® 4 1,8 GHz 1024 MB main memory 5 GB harddisk 1 AMD PCNET Ethernet Adapter Hostname: tamdev1.itso.ral.ibm.com

򐂰 Reverse Proxy node 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 150 MB main memory 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

Microsoft Windows 2000 Server

2000 + Service Pack 4

IBM DB2 UDB, Enterprise Server Edition

8.1.4.428 Note: 8.1 + Fixpack 4a

IBM GSKit

7.0.1.16

IBM Java Runtime Environment (JRE)

1.3.1

IBM WebSphere Application Server

5.0.2

IBM Tivoli Directory Server * Directory Server * Directory Client SDK * Web Administration Tool

5.2

IBM Tivoli Access Manager for e-business * Access Manager Runtime * Access Manager Java Runtime Environment (PDJRTE) * Access Manager Policy Server * Access Manager Authorization Server * Access Manager Web Portal Manager

5.1.0.2 Note: 5.1 + Base Fixpack 2

Table 8-3 Reverse Proxy node

364

Software

Version

Microsoft Windows 2000 Server

2000 + Service Pack 4

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Software

Version

IBM GSKit

7.0.1.16

IBM Java Runtime Environment (JRE)

1.3.1

IBM Tivoli Access Manager for e-business * Access Manager Runtime * Access Manager Java Runtime Environment (PDJRTE) * Access Manager Web Security Environment *Access Manager WebSEAL

5.1.0.2 Note: 5.1 + WebSEAL Fixpack 2 + Base Fixpack 2

Table 8-4 Development node Software

Version

Microsoft Windows 2000

2000 + Service Pack 4

IBM WebSphere Studio Application Developer

5.1.1

IBM WebSphere Test Environment included with WebSphere Studio Application Developer

5.0.2.3 Note: Fixpack 2 + Cumulative Fix 3 + Fixes

IBM WebSphere Portal Toolkit

5.0.2.1

IBM WebSphere Portal Server for test environment

5.0.2.1

IBM Java Runtime Environment (JRE)

1.3.1

IBM Tivoli Access Manager for e-business * Access Manager Java Runtime Environment (PDJRTE)

5.1.0.2 Note: 5.1 + Base Fixpack 2

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.

Chapter 8. Implement the development environment

365

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.

366

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 8. Implement the development environment

367

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

368

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 8. Implement the development environment

369

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.

370

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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/

Chapter 8. Implement the development environment

371

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 → Programs → IBM WebSphere Studio → Application Developer 5.1.1. 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 → wsad511 → interim_fix002 → update → WebSphere Studio Application Developer 5.1.1 Interim Fixes, as seen in Figure 8-3. Where 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.

372

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.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.

Chapter 8. Implement the development environment

373

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. This section includes the following tasks: 򐂰 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): http://www.ibm.com/websphere/portal/toolkit

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).

374

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 from the following URL to a temporary directory (for example, c:\temp): 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. 7. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English), and then click OK. 8. The Update Installation Wizard will launch. Click Next. 9. When the Welcome window appears, 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.

Chapter 8. Implement the development environment

375

13.Select the was502_cf2_win fixpack (default) and then click Next. 14.Review the fixpack settings and then click Next to begin the fixpack installation of files. 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: 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 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

376

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 6. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English) and then click OK. 7. When the Welcome window appears, click Next. 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. 9. Select Install fixes and then click 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.

Chapter 8. Implement the development environment

377

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 complete, click Finish.

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

378

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

4. Download the WebSphere Portal Toolkit V5.0.2.1 (PortalToolkit5021MP.exe) from the following URL to a temporary directory (for example, c:\temp): http://www.ibm.com/websphere/portal/toolkit

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. 7. When the WebSphere Update Installer language window appears, select the appropriate language for the wizard (for example, English), and then click OK. 8. When the Welcome window appears, click Next. 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 and then click Next: – 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 \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 → Programs → IBM WebSphere Studio → Application Developer 5.1.1. 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.

Chapter 8. Implement the development environment

379

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 → Programs → IBM WebSphere Studio → Application Developer 5.1.1. 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.

380

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

8.5.7 Java Runtime Environment (JRE) V1.3.1 installation 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.

Chapter 8. Implement the development environment

381

Configure PDJRTE for WebSphere Studio WTE To configure the Tivoli Access Manager Java Runtime Environment (PDJRTE) 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

You should see the following message: Configuration of Access Manager Java Runtime Environment completed successfully. Table 8-6 Options for the pdjrtecfg tool Parameter

Description

Value

-action

Configure JRE

config

-host

Policy Server node host name in the development environment

tamdev1.itso.ral.ibm.com

-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 To configure the Tivoli Access Manager Java Runtime Environment (PDJRTE) for the standalone JRE V1.3.1, do the following Portal Server node:

382

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 2. Enter the following command: pdjrtecfg -action config -config_type full -host tamdev1.itso.ral.ibm.com -port 7135 -java_home c:\ibm\Java131\jre

You should see the following message: Configuration of Access Manager Java Runtime Environment completed 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.

Chapter 8. Implement the development environment

383

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: a. Open a command window on the Policy Server node. b. Enter the following command to log in to pdadmin: pdadmin -a sec_master -p <password>

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.

384

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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());

Chapter 8. Implement the development environment

385

} } 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. The section is organized into the following tasks: 򐂰 Create a suffix.

386

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 򐂰 򐂰 򐂰 򐂰

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: http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

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 → 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.

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 → Programs → IBM Tivoli Directory Server V5.2 → Directory Configuration.

Chapter 8. Implement the development environment

387

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): http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

388

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Example 8-2 ITSO example wpconfig.properties values for LDAP security Section in wpconfig.properties file

Keyword

ITSO example value

WebSphere Application Server Properties

WasUserid

uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com

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

PortalAdminIdShort

wpsadmin

PortalAdminPwd

wpsadmin Note: User ID password set in the wp-itso.ldif.

WebSphere Portal Security LTPA and SSO configuration

PortalAdminGroupId

cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com

PortalAdminGroupId Short

wpsadmins

LTPAPassword

wpsbind Note: User ID password set in the wp-itso.ldif.

LTPATimeout

120

SSODomainName

itso.ral.ibm.com

Chapter 8. Implement the development environment

389

Section in wpconfig.properties file

Keyword

ITSO example value

LDAP Properties Configuration

Lookaside

false

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.

390

LDAPServerType

IBM_DIRECTORY_SERVER

LDAPBindID

uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com

LDAPBindPassword

wpsbind

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Section in wpconfig.properties file

Keyword

ITSO example value

Advanced LDAP Configuration

LDAPSuffix

dc=itso,dc=ibm,dc=com

LdapUserPrefix

uid

LDAPUserSuffix

cn=users

LdapGroupPrefix

cn

LDAPGroupSuffix

cn=groups

LDAPUserObjectCla ss

inetOrgPerson

LDAPGroupObjectCl ass

groupOfUniqueNames

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: c:\ibm\wsad\runtimes\portal_v50\config

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.

Chapter 8. Implement the development environment

391

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: c:\ibm\wsad\runtimes\portal_v50\config

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: c:\ibm\wsad\runtimes\portal_v50\config

2. Enter the following commands: WPSconfig.bat start-portal-server WPSconfig.bat start-admin-server

392

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: http://wpwin1.itso.ral.ibm.com:9081/wps/portal

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.

Chapter 8. Implement the development environment

393

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.

394

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰

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.

© Copyright IBM Corp. 2004. All rights reserved.

395

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

Presentation Layer

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.

JSPs

Model View Controller Data Beans

Session Facade

Manager

EJB Layer Database Layer

Portlets

TransHistory

Accounts

Users

Entity Beans

Accounts 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.

396

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

398

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

399

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 <security-role> <description>Customer Customer <security-role> <description>Manager Manager ...

400

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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> Customer <method> <ejb-name>Manager <method-intf>Remote <method-name>getAccounts <method-params> <method-param>java.lang.String ...

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.

Chapter 9. Develop the secure portal application

401

򐂰 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.

402

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

403

– 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.

404

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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).

Chapter 9. Develop the secure portal application

405

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.

406

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

407

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.

408

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

409

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

410

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

411

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.

412

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 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 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

Chapter 9. Develop the secure portal application

413

– 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 on page 415.

414

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 1. From WebSphere Studio Application Developer, select the J2EE 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.

Chapter 9. Develop the secure portal application

415

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: 1. From WebSphere Studio Application Developer, select the Server perspective. 2. Expand Servers and double-click server1 to open the server configuration. 3. Click the Configuration tab. 4. Check Enable universal test client. 5. Select File → Save and close the file. 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.

416

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

417

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: 1. From WebSphere Studio Application Developer, select the J2EE 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.

418

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 , 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

4. Save and close the wmmLDAPServerAttributes.xml file.

Chapter 9. Develop the secure portal application

419

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. 1. From WebSphere Studio Application Developer, select the Server 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. 5. Select File → Save and close the file.

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 WebSphere Studio Application Developer. To run and test the ITSO Bank application in the test environment, do the following: 1. From WebSphere Studio Application Developer, select the Server 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.

420

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

421

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 Portlet

Specific User Data

LDAP Helper

Core User Data

Authentication

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;

422

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

423

WebSphere Portal Server

LDAP Helper

Core User Data Directory Server

Import User

Authentication

Specific User Data

Tivoli WebSEAL

TAM Helper

Import User

ITSOUser Portlet

Authentication

Tivoli Access 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,

424

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

425

Trust Association

WebSphere Portal

Portlet Portlet

Authentication

Authentication Proxy (For example, WebSEAL)

Authentication

Backend Applications

Backend Applications

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.

426

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 9. Develop the secure portal application

427

package: com.ibm.wps.portletservice.credentialvault.credentials Credential

Passive Credential

Simple Passive Credential

...

Active Credential

...

Http BasicAuth Credential

User Password Credential

...

...

HttpForm BasedAuth Credential

JAAS Subject 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

428

Parameter

Value

Segment

Default admin segment

Slot

System slot (shared)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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) { throw new PortletException(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

Chapter 9. Develop the secure portal application

429

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) { throw new PortletException(e); } catch (IOException e) { throw new PortletException(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.

430

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

2. Log in as user ID wpsadmin. 3. Click Administration. 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.

Chapter 9. Develop the secure portal application

431

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.

432

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 ITSO Bank application overview. 򐂰 Deploy the ITSO Bank back-end application. 򐂰 Deploy the ITSO Bank portal application.

© Copyright IBM Corp. 2004. All rights reserved.

433

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: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

434

Create an application server. ITSO Bank sample code download and unpack. 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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: c:\ibm\WebSphere\AppServer\bin\startServer server1

2. Start the WebSphere Administrative Console by entering the following URL in a Web browser: http://wpwin1.itso.ral.ibm.com:9090/admin

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. 9. When the Save to Master Configuration page appears, 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.

10.2.2 ITSO Bank sample code download and unpack This section describes the process for downloading the ITSO sample code 6325code.zip, unpacking the zip file, and extracting files from the EAR. 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. 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.

436

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 using

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: 1. Ensure that the server1 application server is started on the Policy Server 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. – Username: cn=root – Password: <password> 4. Click Schema Management → Add an attribute.

Chapter 10. Deploy the secure portal application

437

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

438

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: organizationalPerson objectclass: person objectclass: top objectclass: inetOrgPerson uid: manager1 userpassword: passw0rd sn: Manager givenName: ITSOBank cn: ITSOBank Manager dn: cn=ITSOManagers,cn=groups,dc=itso,dc=ibm,dc=com objectclass: groupOfUniqueNames 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: organizationalPerson objectclass: person objectclass: top objectclass: inetOrgPerson uid: ITSOBankDummyUser sn: Dummy givenName: ITSOBank cn: ITSOBank Dummy User dn: cn=ITSOCustomers,cn=groups,dc=itso,dc=ibm,dc=com objectclass: groupOfUniqueNames 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.

Chapter 10. Deploy the secure portal application

439

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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

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: c:\ibm\WebSphere\AppServer\bin\startServer server1

440

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

3. Start the WebSphere Administrative Console by entering the following URL in a Web browser: http://wpwin1.itso.ral.ibm.com:9090/admin

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: Description: ITSO Bank Alias

Figure 10-1 Create ITSO Bank alias

Chapter 10. Deploy the secure portal application

441

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.

442

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 10. Deploy the secure portal application

443

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.

444

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Figure 10-2 Results of role mapping

9. Click Step 11 Summary page, and then click Finish. 10.Click Save. 11.When the Save to Master Configuration page appears, 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.

Chapter 10. Deploy the secure portal application

445

10.3 Deploy the ITSO Bank portal application This section includes the following tasks to deploy the ITSO Bank portal application: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

ITSO Bank sample code download and unpack. 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.

10.3.1 ITSO Bank sample code download and unpack This section describes the process for downloading the ITSO sample code 6325code.zip, unpacking the zip file, and extracting files from the EAR. 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. 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.

446

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 10. Deploy the secure portal application

447

•

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

448

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

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 , which ends the file). The ITSOid is a correlation ID between the ITSO Bank portlet application and the user data in the LDAP repository.

Chapter 10. Deploy the secure portal application

449

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

5. Save and close the wmmLDAPServerAttributes.xml file. 6. Restart the WebSphere_Portal application server.

10.3.4 Install portlets This section describes how to install the ITSO Bank portlets on the Portal Server node. 1. Access the WebSphere Portal Home page by entering the following URL in a Web browser: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

2. Log in as user ID wpsadmin. 3. Click Administration. 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\ITSOBankApp\ITSOBankWAR.war 6. You should see a page like Figure 10-3 on page 451 listing the portlets to be installed. Click Install.

450

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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).

Chapter 10. Deploy the secure portal application

451

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.

452

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 10. Deploy the secure portal application

453

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.

454

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 10. Deploy the secure portal application

455

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: 1. Navigate to Content Root → My Portal → ITSOBank. 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. 5. From the Edit Layout page, do the following and then click Search: – Search on: Select Title contains. – Search for: ITSO 6. When the search results are displayed, you should see a list of ITSO portlets. 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).

456

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 on page 458.

Chapter 10. Deploy the secure portal application

457

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: 1. Navigate to Content Root → My Portal → ITSOBank. 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.

458

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

6. Click Add portlets. 7. From the Edit Layout page, do the following and then click Search: – Search on: Select Title contains. – Search for: ITSO 8. When the search results are displayed, you should see a list of ITSO 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.

Chapter 10. Deploy the secure portal application

459

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

b. Uncheck the Allow Inheritance checkboxes for the Privileged User role and User role, as seen in Figure 10-10 on page 461.

460

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 10. Deploy the secure portal application

461

8. Assign access to the Modify User page. a. Click the key icon under Assign access for Modify User page. b. Uncheck the Allow Inheritance checkboxes for the Privileged User role and User role. c. Click the pencil icon in the Edit Role column for the Privileged User. d. From the Assign Access for: Pages → Modify 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. 9. Assign access to the Access Account page. a. Click the key icon under Assign access for Access Account page. b. Uncheck the Allow Inheritance checkboxes for the Privileged User role and User role. c. Click the pencil icon in the Edit Role column for the Privileged User. d. From the Assign Access for: Pages → Access Account 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 ITSOCustomers 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 ITSOCustomers group. g. Click OK.

462

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: – Search on: Select Title contains. – Search for: ITSO – Click Search. From the results of the search, you should have a list of ITSO portlets, as seen in Figure 10-11 on page 464.

Chapter 10. Deploy the secure portal application

463

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. c. Click the pencil icon in the Edit Role column for the Privileged User.

464

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

d. From the Assign: Portlets → ITSO Account Balance Admin 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. 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. b. Uncheck the Allow Inheritance checkbox for the User role. c. Click the pencil icon in the Edit Role column for the User. d. From the Assign: Portlets → ITSO Add User page, click Add.

Chapter 10. Deploy the secure portal application

465

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.

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. b. Uncheck the Allow Inheritance checkbox for the User role. c. Click the pencil icon in the Edit Role column for the User. d. From the Assign: Portlets → ITSO Account Balance 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 ITSOCustomers 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 ITSOCustomers group. g. Click OK. h. Click Done.

466

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 1. Access the WebSphere Portal Home page by entering the following URL in a Web browser: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

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.

Chapter 10. Deploy the secure portal application

467

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.

468

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Externalize the ITSO Bank pages resource This section describes how to extrenalize the ITSO Bank pages resource using the WebSphere Portal Resource Permission portlet. 1. Start the WebSphere Portal Administration Console by entering the following URL: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

2. Log on as the wpsadmin user. 3. Access the Resource Permission portlet by clicking Administration → 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.

Chapter 10. Deploy the secure portal application

469

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.

470

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰

Configure CSIv2 SSL settings. Enable SSL for LDAP. Replace the default SSL certificates for the SOAP connector. Additional security hardening guidelines.

© Copyright IBM Corp. 2004. All rights reserved.

471

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.

472

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 Location: C:\IBM\WebSphere\AppServer\etc

3. Create a CSIv2ServerTrustFile.jks: a. Click Key Database File → New. b. Enter the following and click OK: • • •

Key database type: Select JKS. File Name: CSIv2ServerTrustFile.jks Location: C:\IBM\WebSphere\AppServer\etc

c. Enter and confirm the key file password. Click OK.

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: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: csicert.arm Location: C:\IBM\WebSphere\AppServer\etc

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: 1. Ensure that the server1 application server is started. 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. • • • • • • • • • • •

474

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

• •

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,

Chapter 11. Security hardening

475

please refer to Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339. This section includes the following tasks: 1. 2. 3. 4. 5.

Enable LDAP server for SSL connections. Enable SSL for Tivoli Access Manager LDAP connections. Enable SSL for WebSEAL LDAP connections. Enable SSL for WebSphere LDAP connection. 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: a. Click Key Database File → New. b. Enter the following and click OK: • • •

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 Organization: IBM

h. Click Extract Certificate.

476

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

i. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. 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 -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 V5.2 – 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.

Chapter 11. Security hardening

477

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. 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. Import the self-signed certificate for LDAP server: a. Click Key Database File → New. b. Enter the following values in the pop-up window: • • •

Key database type: Select CMS. File Name: ldapcert.kdb Location: C:\IBM\Tivoli\TAM\keytab

c. Enter and confirm the key file password. Select the Stash the password to a file checkbox. Click OK. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • •

478

Data Type: Select Base64-encoded ASCII data. Certificate file name: ldapcert.arm

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

•

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 = c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb ssl-keyfile-dn = “LDAP Server Certificate” ssl-keyfile-pwd =

8. Restart the following Windows services: – Access Manager Policy Server – 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=*

Chapter 11. Security hardening

479

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. 3. Open a command line window and navigate to the c:\ibm\gsk7\bin directory. 4. Start the ikeyman utility by entering the following commands: set JAVA_HOME=c:\ibm\Java131\jre gsk7ikm

5. Import the self-signed certificate for the LDAP server: a. Click Key Database File → New. b. Enter the following values in the pop-up window: • • •

Key database type: Select CMS. File Name: ldapcert.kdb Location: c:\ibm\Tivoli\TAM\keytab

c. Enter and confirm the key file password. Select the Stash the password to a file checkbox. Click OK. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

480

Data Type: Select Base64-encoded ASCII data. Certificate file name: ldapcert.arm Location: c:\ibm\Tivoli\TAM\keytab

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

g. When prompted to enter a label for the certificate, enter LDAP Server Certificate. Click OK. h. Close the IBM Key Management window. 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 = c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb ssl-keyfile-dn = “LDAP Server Certificate” 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. 2. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the ikeyman.bat command.

Chapter 11. Security hardening

481

3. Import the LDAP server certificate: a. Click Key Database File → New. b. Enter the following and click OK: • • •

Key database type: Select JKS. File Name: LdapClientTrustFile.jks Location: C:\IBM\WebSphere\AppServer\etc

c. Enter and confirm the key file password. Click OK. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: ldapcert.arm Location: C:\IBM\WebSphere\AppServer\etc

g. When prompted to enter a label for the certificate, enter tamwin1 LDAP Server Certificate. Click OK. h. Close the IBM Key Management window. 4. Ensure that the server1 application server is started. 5. Start the WebSphere Application Server Administrative Console: http://tamwin1.itso.ral.ibm.com:9090/admin

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.

482

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

– 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.

Chapter 11. Security hardening

483

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. 2. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the ikeyman.bat command. 3. Import the LDAP server certificate: a. Click Key Database File → Open. b. Enter the following values in the pop-up window: • • •

Key database type: Select JKS. File Name: cacerts Location: C:\IBM\WebSphere\AppServer\java\jre\lib\security

c. When prompted for the password, enter changeit. Click OK.

484

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: ldapcert.arm Location: C:\IBM\WebSphere\AppServer\etc

g. When prompted to enter a label for the certificate, enter tamwin1 LDAP Server Certificate. Click OK. h. Close the IBM Key Management window.

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: 1. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the ikeyman.bat command. 2. Import the LDAP server certificate: a. Click Key Database File → Open. b. Enter the following and click OK: • • •

Key database type: Select JKS. File Name: CSIv2ServerTrustFile.jks Location: C:\IBM\WebSphere\AppServer\etc\

c. Enter and confirm the key file password. Click OK. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: ldapcert.arm Location: C:\IBM\WebSphere\AppServer\etc

g. When prompted to enter a label for the certificate, enter tamwin1 LDAP Server Certificate. Click OK. h. Close the IBM Key Management window.

Chapter 11. Security hardening

485

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 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

2. Restart the WebSphere_Portal application server. 3. Verify WebSphere Portal by logging in as user wpsadmin: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

486

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 2. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the ikeyman.bat command. 3. Import the LDAP server certificate: a. Click Key Database File → New. b. Enter the following and click OK: • • •

Key database type: Select JKS. File Name: LdapClientTrustFile.jks Location: C:\IBM\WebSphere\AppServer\etc\

c. Enter and confirm the key file password. Click OK. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: ldapcert.arm Location: C:\IBM\WebSphere\AppServer\etc

g. When prompted to enter a label for the certificate, enter tamwin1 LDAP Server Certificate. Click OK. h. Close the IBM Key Management window.

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: 1. Ensure that the server1 application server is started on the Policy Server node.

Chapter 11. Security hardening

487

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. c. Enter the following values and click OK. • • •

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. c. Enter the following values and click OK. • • •

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.

488

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 11. Security hardening

489

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 -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 V5.2 – 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.

490

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 1. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the ikeyman.bat command. 2. Create a SOAPServerKeyFile.jks file and a self-signed server certificate for SOAP connections: a. Click Key Database File → New. b. Enter the following and then click OK: • • •

Key database type: Select JKS. File Name: SOAPServerKeyFile.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 SOAP Server Key Common Name: wpwin1.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: soapservercert.arm Location: C:\IBM\WebSphere\AppServer\etc

3. Create a SOAPClientKeyFile.jks and a self-signed client certificate for SOAP connections: a. Click Key Database File → New. b. Enter the following values in the pop-up window: • • •

Key database type: Select JKS. File Name: SOAPClientKeyFile.jks Location: C:\IBM\WebSphere\AppServer\etc

c. Enter and confirm the key file password. Click OK.

Chapter 11. Security hardening

491

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 SOAP Client Key Common Name: wpwin1.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: soapclientcert.arm Location: C:\IBM\WebSphere\AppServer\etc

4. Create a SOAPClientTrustFile.jks and import the server certificate: a. Click Key Database File → New. b. Enter the following values in the pop-up window: • • •

Key database type: Select JKS. File Name: SOAPClientTrustFile.jks Location: C:\IBM\WebSphere\AppServer\etc

c. Enter and confirm the key file password. Click OK. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: soapservercert.arm Location: C:\IBM\WebSphere\AppServer\etc

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: a. Click Key Database File → New. b. Enter the following values in the pop-up window: • • •

Key database type: Select JKS. File Name: SOAPServerTrustFile.jks Location: C:\IBM\WebSphere\AppServer\etc

c. Enter and confirm the key file password. Click OK.

492

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: soapclientcert.arm Location: C:\IBM\WebSphere\AppServer\etc

g. When prompted to enter a label for the certificate, enter wpwin1 SOAP 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: http://tamwin1.itso.ral.ibm.com:9090/admin

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.

Chapter 11. Security hardening

493

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

494

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

#-----------------------------------------------------------------------------# 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.

Chapter 11. Security hardening

495

Import SOAP server certificate into CSIv2 trust file To import the SOAP server certificate into the CSIv2 trust file, do the following: 1. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the ikeyman.bat command. 2. Import the LDAP server certificate: a. Click Key Database File → Open. b. Enter the following and click OK: • • •

Key database type: Select JKS. File Name: CSIv2ServerTrustFile.jks Location: C:\IBM\WebSphere\AppServer\etc\

c. Enter and confirm the key file password that you set when creating the keystore. Click OK. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: soapservercert.arm Location: C:\IBM\WebSphere\AppServer\etc

g. When prompted to enter a label for the certificate, enter wpwin1 SOAP Server Certificate. Click OK. 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. 2. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the ikeyman.bat command.

496

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

3. Import the LDAP server certificate: a. Click Key Database File → Open. b. Enter the following and click OK: • • •

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. d. Select Signer Certificates from the pull-down menu underneath Key database content. e. Click Add. f. Modify the following fields and click OK: • • •

Data Type: Select Base64-encoded ASCII data. Certificate file name: soapservercert.arm Location: C:\IBM\WebSphere\AppServer\java\jre\lib\security

g. When prompted to enter a label for the certificate, enter wpwin1 SOAP Server Certificate. Click OK. 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.

Chapter 11. Security hardening

497

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 WpsHostName=wpwin1.itso.ral.ibm.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.

498

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

9. Restart the WebSphere_Portal application server.

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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

2. Log in as user ID wpsadmin. 3. Click Administration. 4. Click Portlets → Install. 5. From the Install Portlets page, enter the following and then click Next: – 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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

b. Log in as user ID wpsadmin. c. Click Administration. d. Click Portlets → Manage Applications. e. Select the WelcomePortlet.war.

Chapter 11. Security hardening

499

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"> file:///$server_root$/installableApps/WelcomePortlet.war <portlet-app action="update" active="true" uid="com.ibm.wps.portlets.welcome.1"> <portlet action="update" active="true" objectid="thePortlet" name="Welcome Portlet"> <supported-markup markup="html" update="set"/> <portletinstance action="update" portletref="thePortlet"/>

500

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1



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

Chapter 11. Security hardening

501

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 http://tamwin1.itso.ral.ibm.com:9090/admin

򐂰 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

502

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰 򐂰

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.

© Copyright IBM Corp. 2004. All rights reserved.

503

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: 򐂰 Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339 򐂰 Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360 򐂰 WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1, 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 ][-D ][-w <password >][-p <portnumber >]start

504

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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): ibmdirctl [-h ][-D ][-w <password >][-p <portnumber >]stop

Where the portnumber specifies the TCP port where the administration deamon is listening (typically 3538). 򐂰 For information on stopping ibmslapd from the Tivoli Directory Server Web Administration Tool see 12.1.3, “Tivoli Directory Server - Web Administration Tool” on page 507.

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): ibmdirctl [-h ][-D ][-w <password >][-p <portnumber >]status

Where the portnumber specifies the TCP port where the administration deamon is listening (typically 3538). 򐂰 For information on viewing the status of ibmslapd from the Web Administration Tool see 12.1.3, “Tivoli Directory Server - Web Administration Tool” on page 507.

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 -w 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.

506

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 12. Manage a secure portal solution

507

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.

508

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 1. Expand the Directory management menu item in the navigation pane. 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.

Chapter 12. Manage a secure portal solution

509

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: 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. 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 /bin directory, and usage details can be found by running -? 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.

510

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

511

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.

512

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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:///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

Chapter 12. Manage a secure portal solution

513

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: 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

514

“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

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 objectclass=organizationalPerson objectclass=inetOrgPerson 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.

Chapter 12. Manage a secure portal solution

515

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 user user user

import modify import modify

-gsouser newuser1 -gsouser newuser2

newuser1 uid=newuser1,cn=users,dc=itso,dc=ibm,dc=com account-valid yes newuser2 uid=newuser2,cn=users,dc=itso,dc=ibm,dc=com 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: user import -gsouser newuser2 uid=newuser2,cn=users,dc=itso,dc=ibm,dc=com 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

516

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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.

Chapter 12. Manage a secure portal solution

517

򐂰 򐂰 򐂰 򐂰 򐂰

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

518

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

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: http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

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.

Chapter 12. Manage a secure portal solution

519

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 Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1359, product 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/, 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 <meta http-equiv="Content-Type" content= "text/html; charset=UTF-8">

520

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Forbidden

The resource you have requested is secured by Access Manager WebSEAL.

Explanation

There are two possible reasons why this message appeared:

1. You are not logged in to this secure domain.
2. You are logged in to this secure domain, but do not have the correct permissions to access the resource.

Solutions

You have an account for this secure domain but need to log in: You must first access this resource via HTTPS (SSL) and login to the secure domain. Re-access the page using HTTPS.

You do not have an account with this secure domain: Please contact your Account Administrator to obtain login and password information.

You are logged in but still denied access to the page: 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.


[%BACK_NAME% BUTTON]

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.

Chapter 12. Manage a secure portal solution

521

򐂰 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 Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1359, product 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/, 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 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <TITLE>Access Manager for e-business Login Access Manager for e-business Login
%ERROR%



522

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1



<SCRIPT LANGUAGE=JavaScript> var warningString = "WARNING: 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'; }

Username
Password

Chapter 12. Manage a secure portal solution

523

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 Guide, IBM Tivoli Access Manager V5.1, SC32-1359, product guide.

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,

524

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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).

Chapter 12. Manage a secure portal solution

525

Figure 12-1 pdadmin object list command

You will notice that the names of these objects follow a common pattern, namely, WPSv5___@. 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

– object list “/WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User/WPS”

526

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Command output: /WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User/WPS/WebSphere_Portal

– object list “/WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User/WPS/WebSphere_Portal” Command output: “/WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User/WPS/WebSphere_Portal/cell”

– object list “/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 History_3_0_CK@User/WPS/WebSphere_Portal/cell”

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: WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User Effective POP: Effective AuthzRule:

We can see from this output that the associated ACL is: WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User

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

Chapter 12. Manage a secure portal solution

527

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

528

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 12. Manage a secure portal solution

529

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.

530

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

531

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.

532

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 1. Open a command prompt and change to <was_home>\bin. 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>

Explanation of command-line syntax: •

<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.

Chapter 12. Manage a secure portal solution

533

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: 1. Open a command prompt and change to <was_home>\bin. 2. Enter the following command: serverStatus.bat <server>|-all -user <username> -password <password>

Explanation of command-line syntax: – <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. – <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: 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

534

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 2. Enter the following URL: 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

Chapter 12. Manage a secure portal solution

535

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: 1. Enter the following URL: 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.

536

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 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. 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.

Chapter 12. Manage a secure portal solution

537

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 → Access → Resource Permissions. 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.

538

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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:///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

Chapter 12. Manage a secure portal solution

539

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.

540

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: https://<webseal_hostname>/portal/wps/myportal

b. Log on as the wpsadmin user. c. Access the Resource Permissions portlet by clicking Administration → Access → Resource Permissions. 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

Chapter 12. Manage a secure portal solution

541

•

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 for Users or User Groups: Users Search on: uid Search for: <username> (for example, authtestuser)

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. f. Select the following values and click Search: • • •

Search for Users or User Groups: Users Search on: uid Search for: <username> (for example, authtestuser)

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. 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.

542

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. f. Select the following values and click Search: • • •

Search for Users or User Groups: Users Search on: uid Search for: <username> (for example, authtestuser)

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. i. Click Log out. 5. Verify that the test user can access the portlet application: a. Access WebSphere Portal by entering the following URL: https://<webseal_hostname>/portal/wps/myportal

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.

Chapter 12. Manage a secure portal solution

543

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.

544

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

545

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

Explanation of command-line syntax: – <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). – : 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

546

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd" type="export" export-users="false"> <portal action="export"/>

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: http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

Chapter 12. Manage a secure portal solution

547

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 – DB2 (Windows services) – 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) – DB2 (Windows services)

548

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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) DB2 (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 -w

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

Chapter 12. Manage a secure portal solution

549

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.

Tivoli Access Manager 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>]

Where the parameters are: 򐂰 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 \etc \pdbackup.lst. 򐂰 path: The path that the backup file will be written to. If not specified, the path is \pdbackup\. 򐂰 file: The file name of the backup archive. If not specified, the file name is list_filename _ . .dar, where and 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_.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”

550

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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\PDWeb\pdbackup\amwebbackup.list_.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 to <path>

For example: db2 backup db wc1 to c:\ibm\dbbackup

Chapter 12. Manage a secure portal solution

551

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.

552

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: 1. Open a command prompt and change to <was_home>\bin. 2. Enter the following command: backupConfig.bat -user <username> -password <password>

Explanation of command-line syntax: – is the name of the zip file that will contain the node configuration (for example, WebSphereConfig_yyyy-mm-dd>.zip). – <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. 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.

Chapter 12. Manage a secure portal solution

553

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 -n -w

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. 򐂰 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

Tivoli Access Manager 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_.time.dar”

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 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.

554

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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_.time.dar”

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 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

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 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

Chapter 12. Manage a secure portal solution

555

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: 1. Open a command prompt and change to <was_home>\bin. 2. Enter the following command: restoreConfig.bat -user <username> -password <password>

Explanation of command-line syntax: – is the name of the file that will contain the previously backed-up node configuration (for example, WebSphereConfig_yyyy-mm-dd>.zip). – <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.

556

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. b. c. d.

The user hits the ITSO Bank site with the browser. The Tivoli Access Manager login form is presented. The actor fills in the user name and password. The actor submits the login form.

Chapter 12. Manage a secure portal solution

557

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.

558

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

559

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.

560

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

561

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.

562

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

563

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.

564

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

565

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.

566

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Chapter 12. Manage a secure portal solution

567

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

568

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Chapter 12. Manage a secure portal solution

569

570

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Part 3

Part

3

Appendixes

© Copyright IBM Corp. 2004. All rights reserved.

571

572

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. This chapter is organized into the following sections: 򐂰 򐂰 򐂰 򐂰

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

© Copyright IBM Corp. 2004. All rights reserved.

573

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: https://wswin1.itso.ral.ibm.com/portal/wps/myportal

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

574

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

576

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Appendix A. Troubleshooting a secure portal solution

577

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 (, , 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 SELECT * FROM USER_DESC

578

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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) INSERT INTO LNK_USER_ROLE (USER_DESC_TYPE, USER_DESC_OID, ROLE_INST_OID) 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 SELECT * FROM USER_DESC

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) INSERT INTO LNK_USER_ROLE (USER_DESC_TYPE, USER_DESC_OID, ROLE_INST_OID) 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

Appendix A. Troubleshooting a secure portal solution

579

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\\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

580

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.(FileInputStream.java:91) [java] at java.io.FileInputStream.(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:

Appendix A. Troubleshooting a secure portal solution

581

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. 2. Back up the WebSphere Portal configuration properties found in the wpconfig.properties file by entering the following command: wpsconfig backup-main-cfg-file

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

582

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Table A-1 Example wpconfig.properties for disabling security Section in wpconfig.properties file

Keyword

ITSO example value

Portal configuration properties

PortalAdminId

uid=wpsadmin,o=default organization

PortalAdminIdShort

wpsadmin

PortalAdminPwd

<password>

PortalAdminGroupId

cn=wpsadmins,o=default orgainization

4. Save the updated wpconfig.properties file. 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) startServer WebSphere_Portal

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\\. 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.

Appendix A. Troubleshooting a secure portal solution

583

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: 򐂰 򐂰 򐂰 򐂰 򐂰

584

h: Host name for LDAP server p: Port number for LDAP server b: Base dn for search D: Bind dn w: Bind password

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

(&(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 objectclass=organizationalPerson objectclass=inetOrgPerson 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

Appendix A. Troubleshooting a secure portal solution

585

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.

586

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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 <property_name>

• •

: 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

Appendix A. Troubleshooting a secure portal solution

587

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

588

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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_.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

Appendix A. Troubleshooting a secure portal solution

589

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 /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 /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 /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 /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 /etc.

590

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 7. Restart the WebSphere_Portal application server.

Appendix A. Troubleshooting a secure portal solution

591

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. 4. Restart the WebSphere_Portal application server. The trace will be written to the wps_.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.

592

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. https://<webseal_hostname>/portal/wps/myportal

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. The trace will be written to the wps_.log in the <wp_home>\log 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

The trace will be written to the wps_.log in the <wp_home>\log directory.

Appendix A. Troubleshooting a secure portal solution

593

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

The trace will be written to the wps_.log in the <wp_home>\log 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

594

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Appendix A. Troubleshooting a secure portal solution

595

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=

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

596

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

© Copyright IBM Corp. 2004. All rights reserved.

597

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.

598

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: https://wpwin1.itso.ral.ibm.com:9043/admin

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 /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. 2. Open a Windows command window (not pdadmin). 3. From the Windows command line, change to the directory of the wp-junction-ltpa.pd and enter the following command: pdadmin -a sec_master wp-junction-ltpa.pd

4. When prompted for the password, enter the sec_master password.

600

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

602

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

© Copyright IBM Corp. 2004. All rights reserved.

603

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.

604

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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).

606

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Appendix C. CVS configuration

607

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)

608

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Appendix C. CVS configuration

609

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 WebSphere Studio Application Developer.

610

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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).

Appendix C. CVS configuration

611

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

612

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

© Copyright IBM Corp. 2004. All rights reserved.

613

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. 򐂰 Maintainability 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.

614

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 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,

616

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Appendix D. Automate deployment tasks

617

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.

618

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Appendix D. Automate deployment tasks

619

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: ftp://www.redbooks.ibm.com/redbooks/SG246325

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:[email protected]: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.

620

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Appendix D. Automate deployment tasks

621

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.

622

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 1. Open an initialized console window by double clicking the file init-env.bat located on the desktop. 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.

Appendix D. Automate deployment tasks

623

Verification Let us start the verification by building the components, uninstalling them from the target environment, and finally re-deploying them. 1. Open an initialized console window by double clicking the file init-env.bat located on the desktop. 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

624

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html

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

Appendix D. Automate deployment tasks

625

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

626

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Appendix D. Automate deployment tasks

627

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.

628

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Appendix D. Automate deployment tasks

629

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

630

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Appendix D. Automate deployment tasks

631

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.

632

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Example: D-2 Portlet Application build file ]> <project name="ComponentName" basedir="." default="default"> &standard-init; &standard-portletapp;

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

Appendix D. Automate deployment tasks

633

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.

634

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Standard common

Components

Standard specialized

EAR

ear

EJB

ejb

Library

library

Portlet

portlet

init

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

Appendix D. Automate deployment tasks

635

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 <property name="override.dependent.projects" value="ITSOBankEJB" />

Component build file invocation The syntax for invoking a component build file is: ant [-Dtargetenv=] 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.

636

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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=] [-Dtarget=] <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.

Appendix D. Automate deployment tasks

637

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 \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.

638

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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= 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= -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.

Appendix D. Automate deployment tasks

639

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= deploy

640

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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. 2. Change to the solution root directory. 3. Instruct the solution to deploy one or more sets of component types to a specified target environment: ant -Dtargetenv= -Dtarget=deploy []

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= 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.

Appendix D. Automate deployment tasks

641

3. Open a console window. 4. Change to the solution root directory. 5. Instruct the solution to deploy one or more sets of component types to a specified target environment: <was_home>\bin\ws_ant -Dtargetenv= -Dtarget=deploy []

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

642

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

Appendix D. Automate deployment tasks

643

644

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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

© Copyright IBM Corp. 2004. All rights reserved.

645

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

646

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 capacity

The non-functional requirements and volumetric must be 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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 capacity

The nonfunctional requirements and volumetric must be 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.

Risk

It is mission critical since it serves all customer requests accessing the site. Ability to cluster for load balancing/failover.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Appendix E. Node descriptions for architecture models

647

Table E-3 Conceptual Caching Proxy node

648

Subject

Conceptual node: Caching Proxy

Description

A process that supports the use and management of Web pages and other Internet-related material.

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.

Performance and capacity

The non-functional requirements and volumetric must be 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. The node access is defined by the security policies. There is a well-defined relationship between Web Server nodes and App Server nodes.

Risk

It is mission critical since it serves all customer requests accessing the site. Ability to cluster for performance/failover.

Node Management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 capacity

The nonfunctional requirements and volumetric must be 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. There is a well-defined relationship between Portal Server nodes, Directory nodes, and back-end applications.

Risk

It is mission critical since it serves all customer requests accessing the site.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

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.

Appendix E. Node descriptions for architecture models

649

Subject

Conceptual node: 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.

Users and presentation

The administration client is browser based to configure the directory settings. LDAP entries are managed using command line tools or a browser.

Performance and capacity

The non-functional requirements and volumetric must be 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 is strictly enforced, and maintenance access to the directory server runtime is granted based on the security policy definitions.

Risk

Mission critical.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-6 Conceptual Data Server node

650

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Subject

Conceptual node: Data Server

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.

Performance and capacity

The non-functional requirements and volumetric must be handled by this node. The disk capacity and caching configuration ensure reaching the transaction rate for the average/peak transaction rate.

Availability

24x7.

Cost and benefit

N/A.

Security

Access to the data server runtime is granted based on the security policy definitions.

Risk

Mission critical.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-7 Conceptual Web Server node Subject

Conceptual node: Web Server

Description

A process that supports the use and management of Web pages and other Internet-related material.

General

The responsibilities of the Web server node include receiving and serving HTTP/HTTPS requests from the browser client.

Users and presentation

This node serves customers and administrators. The presentation services are only browser based.

Performance and capacity

The non-functional requirements and volumetric must be 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.

Appendix E. Node descriptions for architecture models

651

Subject

Conceptual node: Web Server

Cost and Benefit

N/A.

Security

SSL software support. In case of performance problems, hardware encryption components can be added.

Risk

It is mission critical since it serves all customer requests accessing the site. Ability for clustering for performance/failover.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-8 Conceptual Application Server node

652

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.

Performance and capacity

The non-functional requirements and volumetric must be 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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

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.

Performance and capacity

The non-functional requirements and volumetric must be handled by this node.

Availability

24x7.

Cost and benefit

N/A.

Security

SSL is strictly enforced in compliance with the security policy.

Risk

Mission critical since all security-related services are handled.

Appendix E. Node descriptions for architecture models

653

Subject

Conceptual node: Policy Server

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

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.

Performance and capacity

The non-functional requirements and volumetric must be handled by this node.

Availability

24x7.

Cost and benefit

N/A.

Security

SSL is strictly enforced in compliance with the security policy.

Risk

Mission critical since business resellers are using the collaboration feature for negotiations.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-11 Conceptual Instant Messaging node

654

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Performance and capacity

The non-functional requirements and volumetric must be handled by this node.

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.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

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.

Appendix E. Node descriptions for architecture models

655

Subject

Conceptual node: Portal Development

Performance and capacity

Performance requirements demand a powerful developer 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.

Cost and benefit

N/A.

Security

None.

Risk

N/A.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

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. 򐂰 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 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

656

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

LDAPS(636)

SERP1,SERP2

SMTAM

TAM_SSL(7135)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

From

To

Characteristics

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 O,SPSAMETIME

SPLDAPR

LDAPS(636)

SPLDAPR,SPPORTAL, SPBANK

SPDB

Database client/server connection ports

SMLDAP

SPLDAPR

LDAPS(636)

SMLDAP,SMWAS2,SM WAS1

SMDB

Database client/server connection ports

SMHTTP1

SMWAS1

HTTP(80), HTTPS(443)

SMHTTP2

SMWAS2

HTTP(80), HTTPS(443)

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.

Appendix E. Node descriptions for architecture models

657

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

658

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

128-bit SSL encryption.

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.

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Presentation function

The administration services are command-line based.

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

128-bit SSL encryption.

Data services

N/A.

Hardware

Productive server profile.

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-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.

Appendix E. Node descriptions for architecture models

659

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

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.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving HTTP and HTTPS requests. Access to file system using Java services. JDBC driver from database vendor.

Management

Tivoli systems management software 4.x or later.

Table E-18 Specified SPHTTPD node

660

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

IBM HTTP Web server required to handle HTTP requests. 128-bit SSL encryption.

Data services

Handles <= 3000 connections.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Subject

Specified node: SPHTTPD (Web Server)

Hardware

Productive server profile. For scalability reasons, the hardware must support up to four processors.

Operating system

Supports <= 512 threads. 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-19 Specified SPBANK node Subject

Specified node: SPBANK (App Server)

Description

This node serves banking requests and renders the client page. 24x7.

Presentation function

Browser-based configuration and administration.

Processing function

Processes HTTP request from a HTML capable client browser. Multi-threading services to share the load of serving customer requests. Based on J2EE open standards including Web services.

Data

Logs application server relevant data on the local file system. Uses database repository to maintain application server configuration. Store information and data assets are kept in the commerce database.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

Supports JavaServer Pages and HTML.

Processing services

Generates markup language for HTML and XML. J2EE runtime environment leveraging Java services.

Data services

JDBC driver to access database-relevant information. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving HTTP and HTTPS requests. Access to file system using Java services. JDBC driver from database vendor.

Appendix E. Node descriptions for architecture models

661

Subject

Specified node: SPBANK (App Server)

Management

Tivoli systems management software 4.x or later.

Table E-20 Specified SPLDAPR node Subject

Specified node: SPLDAPR (Directory)

Description

This node serves the enterprise replica-directory. 24x7.

Presentation function

Browser-based configuration and administration. 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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

Serves LDAP and LDAPS V3.0 requests.

Data services

JDBC driver to access database-relevant information. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving LDAP, and LDAPS requests. Database native clients.

Management

Tivoli systems management software 4.x or later.

Table E-21 Specified SPDB node

662

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN. Optimized hard disk access.

Presentation services

None.

Processing services

Relational database supporting SQL.

Data services

JDBC support. Database is able to handle 80 concurrent connections and provides stored procedures. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP. Native database driver from database vendor including JDBC support.

Management

Tivoli systems management software 4.x or later.

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

See Lotus Domino.

Processing services

Lotus Domino base services.

Data services

Requires Lotus Domino Notes.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Appendix E. Node descriptions for architecture models

663

Subject

Specified node: SPDOMINO (Collaboration)

Connections

Based on TCP/IP. Lotus Domino Notes specific extensions.

Management

Tivoli systems management software 4.x or later.

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

See Lotus Sametime.

Processing services

Lotus Sametime base services.

Data services

Requires Lotus Domino Notes.

Hardware

Productive server profile.

Operating system

Multitasking multi-processor operating system.

Connections

Based on TCP/IP. Lotus Domino Notes specific extensions.

Management

Tivoli systems management software 4.x or later.

Table E-24 Specified SMTAM node

664

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.

Presentation function

Browser-based configuration and administration.

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

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. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving HTTP and HTTPS requests. Access to file system using Java services. JDBC driver from database vendor.

Management

Tivoli systems management software 4.x or later.

Table E-25 Specified SMHTTP1 node Subject

Specified node: SMHTTP1 (Web Server)

Description

This node serves the policy server administration requests only.

Presentation function

The administration services are browser-based leveraging HTML.

Processing function

Delivers HTTP response streams.

Data

Logs HTTP requests on the local file system.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

IBM HTTP Web server required to handle HTTP requests. 128-bit SSL encryption.

Data services

Handles <= 5 connections.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Appendix E. Node descriptions for architecture models

665

Subject

Specified node: SMHTTP1 (Web Server)

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-26 Specified SMWAS1 node

666

Subject

Specified node: SMWAS1 (Application Server)

Description

This node serves the policy server administration client request only. 24x7.

Presentation function

Browser-based configuration and administration.

Processing function

Processes HTTP request from a HTML capable client browser. Multi-threading services to share the load of serving customer requests. Based on J2EE open standards including Web services.

Data

Logs application server relevant data on the local file system. Uses database repository to maintain application server configuration. Store information and data assets are kept in the commerce database.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

Supports JavaServer Pages and HTML.

Processing services

Generates markup language for HTML and XML. J2EE runtime environment leveraging Java services.

Data services

JDBC driver to access database-relevant information. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving HTTP and HTTPS requests. Access to file system using Java services. JDBC driver from database vendor.

Management

Tivoli systems management software 4.x or later.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Table E-27 Specified SMHTTP2 node Subject

Specified node: SMHTTP2 (Web Server)

Description

This node serves the directory administration requests only.

Presentation function

The administration services are browser-based leveraging HTML.

Processing function

Delivers HTTP response streams.

Data

Logs HTTP requests on the local file system.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

IBM HTTP Web server required to handle HTTP requests. 128-bit SSL encryption.

Data services

Handles <= 5 connections.

Hardware

Productive server profile.

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-28 Specified SMWAS2 node Subject

Specified node: SMWAS2 (Application Server)

Description

This node serves the directory server administration client request only. 24x7.

Presentation function

Browser-based configuration and administration.

Processing function

Processes HTTP request from a HTML capable client browser. Multi-threading services to share the load of serving customer requests. Based on J2EE open standards including Web services.

Data

Logs application server relevant data on the local file system. Uses database repository to maintain application server configuration. Store information and data assets are kept in the commerce database.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Appendix E. Node descriptions for architecture models

667

Subject

Specified node: SMWAS2 (Application Server)

Presentation services

Supports JavaServer Pages and HTML.

Processing services

Generates markup language for HTML and XML. J2EE runtime environment leveraging Java services.

Data services

JDBC driver to access database-relevant information. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving HTTP and HTTPS requests. Access to file system using Java services. JDBC driver from database vendor.

Management

Tivoli systems management software 4.x or later.

Table E-29 Specified SMLDAP node

668

Subject

Specified node: SMLDAP (Directory)

Description

This node serves the enterprise directory. 24x7.

Presentation function

Browser-based configuration and administration. Directory entities are managed through LDAP synchronisation for the replica nodes.

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN

Presentation services

None.

Processing services

Serves LDAP and LDAPS V3.0 requests.

Data services

JDBC driver to access database relevant information. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Subject

Specified node: SMLDAP (Directory)

Connections

Based on TCP/IP serving LDAP, and LDAPS requests. Database native clients.

Management

Tivoli systems management software 4.x or later.

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.

Presentation function

None.

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN. Optimized hard disk access.

Presentation services

None.

Processing services

Relational database supporting SQL. Directory synchronisation with replicas.

Data services

JDBC support. Database is able to handle 80 concurrent connections and provides stored procedures. Handles data as defined by the nonfunctional requirements.

Hardware

Productive server profile.

Operating system

Multitasking multi-processor operating system.

Connections

Based on TCP/IP. Native database driver from database vendor including JDBC support

Management

Tivoli systems management software 4.x or later.

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

Appendix E. Node descriptions for architecture models

669

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.

Data

Use of native relational database technology.

Infrastructure

Ethernet access with at least 100 Mbps LAN. Optimized hard disk access.

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.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP. Native database driver from database vendor including JDBC support.

Management

Tivoli systems management software 4.x or later.

Conceptual model node descriptions for development The following tables describe the conceptual nodes in detail. 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

Repository node (see Table E-32) Reverse Proxy node (see Table E-33 on page 671) Portal Server node (see Table E-34 on page 672) Directory node (see Table E-35 on page 673) Data Server node (see Table E-36 on page 674) Policy Server node (see Table E-37 on page 675) Development node (see Table E-38 on page 676)

Table E-32 Conceptual Repository node

670

Subject

Conceptual node: Repository

Description

A process that offers version control for development assets.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Performance and capacity

The non-functional requirements and volumetric must be 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 developers.

Availability

7:00 a.m. - 10:00 p.m.

Cost and benefit

N/A.

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 management, recovery time, problem management, software distribution, and configuration management.

Table E-33 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.

Appendix E. Node descriptions for architecture models

671

Subject

Conceptual node: Reverse Proxy

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

Users and presentation

The administration client is browser based to configure the settings. In addition, command line tools are available.

Performance and capacity

The non-functional requirements and volumetric must be 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

7:00 a.m. - 10:00 p.m.

Cost and benefit

N/A.

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.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-34 Conceptual Portal Server node

672

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Subject

Conceptual node: Portal Server

Users and presentation

This node serves customers and administrators. The presentation services are only browser based.

Performance and capacity

The non-functional requirements and volumetric must be 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

7:00 a.m. - 10:00 p.m.

Cost and benefit

N/A.

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.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-35 Conceptual Directory node Subject

Conceptual node: Directory

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).

Users and presentation

The administration client is browser based to configure the directory settings. LDAP entries are managed using command line tools or a browser.

Appendix E. Node descriptions for architecture models

673

Subject

Conceptual node: Directory

Performance and capacity

The non-functional requirements and volumetric must be 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

7:00 a.m. - 10:00 p.m.

Cost and benefit

N/A.

Security

SSL is enforced and maintenance access to the directory server runtime is granted based on the security policy definitions.

Risk

Critical.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-36 Conceptual Data Server node

674

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.

Users and presentation

Administration facilities are Java-based GUIs or using the command-line facilities.

Performance and capacity

The non-functional requirements and volumetric must be handled by this node. The disk capacity and caching configuration ensure reaching the transaction rate for the average/peak transaction rate.

Availability

7:00 a.m. - 10:00 p.m.

Cost and benefit

N/A.

Security

Access to the data server runtime is granted based on the security policy definitions.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Subject

Conceptual node: Data Server

Risk

Critical.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Table E-37 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.

Performance and capacity

The non-functional requirements and volumetric must be handled by this node.

Availability

7:00 a.m. - 10:00 p.m.

Cost and benefit

N/A.

Security

SSL is strictly enforced in compliance with the security policy.

Risk

Mission critical since all security-related services are handled.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Appendix E. Node descriptions for architecture models

675

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 capacity

Performance requirements demand a powerful developer workstation with at least 1 GB of memory. Disk capacity can handle the necessary software components and data volume.

Availability

07:00 a.m. - 10:00 p.m.

Cost and benefit

N/A.

Security

None.

Risk

N/A.

Node management

Follows the node management standards for remote management, recovery time, problem management, software distribution, and configuration management.

Specified model node description for development and test environment The following tables describe the specified nodes in detail. 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰 򐂰

676

Repository node (see Table E-39 on page 677) Reverse Proxy node (see Table E-40 on page 677) Portal Server node (see Table E-41 on page 678) Directory node (see Table E-42 on page 679) Data Server node (see Table E-43 on page 680) Policy Server node (see Table E-44 on page 680) Development node (see Table E-45 on page 681)

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

128-bit SSL encryption for multi-site access via the Internet.

Data services

Handles <= 20 connections in a developer environment.

Hardware

Productive server profile. For scalability reasons, the hardware should support up to two processors.

Operating system

Supports <= 512 threads. 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-40 Specified SDRP Subject

Specified node: SDRP (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. 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.

Appendix E. Node descriptions for architecture models

677

Subject

Specified node: SDRP (Reverse Proxy)

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

128-bit SSL encryption.

Data services

Handles <= 100 connections.

Hardware

Productive server profile. For scalability reasons, the hardware should support up to two processors.

Operating system

Supports <= 512 threads. 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-41 Specified SDPORTAL node

678

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.

Presentation function

Browser-based configuration and administration. 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. Based on J2EE open standards including Web services.

Data

Logs application server relevant data on the local file system. Uses database repository to maintain application server configuration.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

Supports JavaServer Pages, WML and HTML.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Data services

JDBC driver to access database-relevant information. Handles data as defined by the non-functional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving HTTP and HTTPS requests. Access to file system using Java services. JDBC driver from database vendor.

Management

Tivoli systems management software 4.x or later.

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.

Processing function

Processes LDAP and LDAP requests. Multi-threading services to share the load of serving directory requests.

Data

Logs directory-relevant data on the local file system. Uses database repository to maintain directory configuration.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

Processing services

Serves LDAP and LDAPS V3.0 requests.

Data services

Database driver to access database-relevant information. Handles data as defined by the non-functional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Appendix E. Node descriptions for architecture models

679

Subject

Specified node: SDLDAP (Directory)

Connections

Based on TCP/IP serving LDAP, and LDAPS requests. Database native clients.

Management

Tivoli systems management software 4.x or later.

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.

Presentation function

None.

Processing function

Is able to serve the amount of directory database requests per hour. Database provides performance optimizations to handle the load.

Data

Use of native relational database technology.

Infrastructure

Ethernet access with at least 100 Mbps LAN. Optimized hard disk access.

Presentation services

None.

Processing services

Relational database supporting SQL.

Data services

JDBC support. Database is able to handle 80 concurrent connections and provides stored procedures. Handles data as defined by the non-functional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP. Native database driver from database vendor including JDBC support.

Management

Tivoli systems management software 4.x or later.

Table E-44 Specified SDTAM node

680

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

None.

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. Handles data as defined by the non-functional requirements.

Hardware

Productive server profile.

Operating system

Multi-tasking multi-processor operating system.

Connections

Based on TCP/IP serving HTTP and HTTPS requests.

Management

Tivoli systems management software 4.x or later.

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.

Infrastructure

Ethernet access with at least 100 Mbps LAN.

Presentation services

J2EE runtime.

Processing services

N/A.

Appendix E. Node descriptions for architecture models

681

682

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.

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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: ftp://www.redbooks.ibm.com/redbooks/SG246325

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 6325code.zip

Description Secure Portal Solution sample code

© Copyright IBM Corp. 2004. All rights reserved.

683

System requirements for downloading the Web material The following system configuration is recommended: Hard disk space: Operating System: Processor: Memory:

5 MB minimum Windows/UNIX 1 GHz PIII or higher 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 c:\6325code directory.

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.

684

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 򐂰 A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager 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 򐂰 Enterprise Security Architecture Using IBM Tivoli Security Solutions, 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

© Copyright IBM Corp. 2004. All rights reserved.

685

򐂰 IBM Tivoli Access Manager for e-business, REDP3677 򐂰 Identity Management Design Guide with IBM Tivoli Identity Manager, 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 򐂰 Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360 򐂰 Administration Java Classes Developer Reference, IBM Tivoli Access Manager V5.1, SC32-1356 򐂰 Authorization Java Classes Developer Reference, IBM Tivoli Access Manager V5.1, SC32-1350 򐂰 Base Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1362 򐂰 Command Reference, IBM Tivoli Access Manager V5.1, SC32-1354 򐂰 Plug-in for IBM WebSphere Edge Server Integration Guide, IBM Tivoli Access Manager V5.1, SC32-1367 򐂰 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 Manager V5.1, SC32-1368 򐂰 WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1359 򐂰 Web Security Developer Reference, IBM Tivoli Access Manager V5.1, SC32-1358 򐂰 Web Security Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1361

686

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

򐂰 Plug-in for Web Servers Integration Guide, IBM Tivoli Access Manager V5.1, SC32-1365 򐂰 Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339 򐂰 Installation and Configuration Guide, IBM Tivoli Directory Server V5.2, 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: http://www.ibm.com/websphere/portal/library

򐂰 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

688

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Index Numerics 6325code.zip 684

A Access Control List 42, 336 access.log 588 AccessControlConfigService.properties 333 AccessControlDataManagementService.properties 334 account management pages 522 ACL See Access Control List ActiveX Control 296 actors defined 155 add portlets to page 453 Additional security hardening guidelines 501 Administrator rights 229 Apache Ant 616 application architecture 396 application deployment automate tasks 613 application development 395 Architecture secure portal solution 5 architecture node descriptions 645 Architecture overview 362 asymmetric key encryption 28 attributeMap.xml 31 Authentication 4, 38 authentication 30 trace 591 Authentication data 39 Authorization 4, 41 Tivoli Access Manager configuration 322 WebSphere Portal vs TAM 95 authorization trace 593 authorization API Tivoli Access Manager 18 Authorization goals 42 Authorization process flow 43 Authorization rules 42

© Copyright IBM Corp. 2004. All rights reserved.

automation overview 614 availability 151

B Back-end application cookies 110 Basic authentication 40 BMP See Programming Module Enhancement bootstrap port 435 business challenges 145 business requirements 146

C CA See certificate authority Certificate Authority 27 Certificates 29–30 Client-Web application single sign-on 96 Common Secure Interoperability V2 472 Component connections entry runtime environment 133 Concepts authentication 4 authorization 4 Credential Vault 4 global sign-on 4 shared LDAP user registry 4 single sign-on 4 Conceptual model 58 description 53 nodes 61 conceptual model node description Application Server node 652 Caching Proxy node 648 Collaboration node 654 Data Server node 650 Directory node 649 Instant Messaging node 654 Load Balancer node 646 Policy Server node 653 Portal Development node 655 Portal Server node 649

689

Repository node 670 Reverse Proxy node 647 Web Server node 651 node descriptions 645 Concurrent Version System 603 config.was.tai.jacl 309 ConfigService.properties 317 WebSphere Portal configuration for JAAS 325 Configuration authorization WebSphere Portal using TAM 322 Credential Vault 347 CSIv2 SSL settings 472 CVS client for WSAD 386 CVS for NT 606 IBM HTTP Server enable SSL 277 JAAS 324 mutual SSL between WebSEAL and WebSphere Portal 276 PDJRTE for standalone JRE 382 WebSphere Studio WTE 382 PDJRTE for standalone JRE V1.3.1 382 PDJRTE for WebSphere Studio WTE 382 session timeouts 356 WebSEAL 356 WebSphere Portal 356 SSO using LTPA 597 Tivoli Access Manager 208 Web Portal Manager 215 WebSEAL 222 Tivoli Directory Server 195 for Tivoli Access Manager 206 WebSEAL favicon 531 WebSphere Application Server JAAS 325 WebSphere Portal enable SSL 281 login/logout with WebSEAL 313 SOAP connection credentials 495 WebSphere Portal for DB2 261 WebSphere Portal for LDAP 266, 386 WebSphere Portal TAI 309 Configure and load wpconfig.properties file 497 Configure CSIv2 SSL settings 472 Configure SSL certificate and repertoire for SOAP connector 491

690

Configure SSL certificate for LDAP 487 Configure the SSL repertoire for CSIv2 474 Configure Tivoli Directory Server client utilities for SSL 488 Configure Web Admin Tool for LDAP SSL connections 487 Configure WebSphere administration utilities 494 Configure WebSphere Portal SOAP connection credentials 495 Configure WMM for LDAP SSL connections 486 cookie 103 create a certificate 280 Create a suffix for WebSphere Portal 266 Tivoli Directory Server 387 create a WebSEAL junction 297 create admin user and assign rights 183 Create and configure SSL repertoire for SOAP connectors 493 create and ldif file users and groups 267 create portal pages 451 Create SSL keys for CSIv2 473 Create SSL keys for SOAP connector 491 Create users and groups import the LDIF file (wp-itso.ldif) 387 Credential objects 45 Credential Service 4 Credential Vault 4 configuration 347 Tivoli Access Manager 348 trace 594 Cryptography 27 CSIv2 create SSL keys 473 See Common Secure Interoperability V2 SSL repertoire 474 CSIv2 endpoint types mutually authenticated 472 server authenticated 472 CSIv2 inbound transports SSL-Required 472 SSL-Supported 472 TCP/IP 472 CSIv2 SSL configuration 472 CVS client configuration 610 CVS for NT 605

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

D DB2 rebind 188 DB2 UDB V8.1 Fixpack 2 installation Windows 186 DB2 Universal Database First Steps 188 installation 184 verification 188 define additional MIME types WebSphere Application Server 296 Defining and applying ACLs and POPs 42 Demilitarized zone 60 deployed portlets 547 deployment 433 deployment automation component types 625 concepts 625 goals maintainability 614 reproducibility 615 traceability 614 terminology 615 tooling 616 walkthrough 617 Deployment Manager 501 Deployment Manager server 501 Design guidelines 93 WebSphere Portal external web server 107 Design principals 94 access decision evaluation on-demand 94 access evaluated on-demand implication 95 motivation 95 capture access events implication 95 motivation 95 capture authentication events and logs 95 centralized security 94 implication 94 motivation 94 Development enviornment topology selection all-in-one approach 85 develop and deploy without debug 87 develop using share security infrastructure 90 develop, deploy and remote debug 88 Development environment

conceptual model 83 end-to-end development life-cycle 82 hardware used by ITSO 363 ITSO Bank backend EJB server 412 frontend portal server 418 prepare database 408 prepare for ITSO Bank 401 software used by ITSO 364 solution software 8 specified model 84 topology selection 81 Development node 368 digital signature 29 Disable non-SSL access to Tivoli Directory Server 489 disable non-SSL connections 489 disable security for WebSphere Portal 582 Disable the IBM HTTP Server Administration service 502 Disable the IBM HTTP Server on the Policy Server node 502 Domain zone categories 54 controlled 55, 57 External Controlled 55 restricted 55, 57 secured 55, 57 uncontrolled 55 dummy SSL certificates 472 DummyServerKeyFile.jks 472 DummyServerTrustFile.jks 472 dynurl.conf 305

E EJB method level security 19 electronic document 29 Enable LDAP server for SSL connections 476 Enable SSL for LDAP 475 Enable SSL for Tivoli Access Manager LDAP connections 478 Enable SSL for Tivoli Directory Server Web Administration Tool for LDAP connections 487 Enable SSL for WebSEAL LDAP connections 480 Enable SSL for WebSphere Application Server LDAP connections 481 Enable SSL for WebSphere Portal LDAP connections 484 encrypt passwords 586

Index

691

Encryption 29 Enterprise runtime topology 73 Entry runtime topology 70 Enumeration 16 error page customization 520 error.log 588 external authorization 336 ExternalAccessControlService.properties 331 externalize resources 467 externalized role management 524 attach POP to resource-role 529 grant membership to a role 524 revoke role membership 528 externalizing a resource 337

F favicon 531 favicon.ico 359 Firewalls 22 Footprinting 16 Forms authentication 40 forms authentication 300 fully qualified DNS name 232 functional requirements 146

G getCallerPrincipal method 19 Global Sign-on 5, 96 GSKit 188 GSO See Global Sign-on

H http_plugin.log 588 httpd.conf 277

I IBM DB2 UDB 7 IBM GSKit 7 determine version installed 189 installation 188 known issues 190 uninstall 190 IBM HTTP Server configuration certificate 280

692

create a certificate 280 create a keystore 279 export CA certificate 283 import certificate 284 logs access.log 588 error.log 588 http_plugin.log 588 SSL configuration 277 IBM Java Runtime Environment (JRE) 7 IBM Tivoli Access Manager for e-business 7 IBM Tivoli Directory Server 7–8 IBM WebSphere Application Server 7 IBM WebSphere Application Server Enterprise 8 IBM WebSphere Portal Content Publisher 8 IBM WebSphere Portal Extend for Multiplatforms 8 IBM WebSphere Portal Toolkit and Test Environment 9 IBM WebSphere Studio Application Developer 9 IBM WebSphere Test Environment 9 ibmslapd 504 Identity management 105 IllegalBlockSizeException 581 import an ldif file 268 Import LDAP certificate to WebSphere Portal keystore 484 Import LDAP server certificate into the CSIv2 trust file 485 Import SOAP server certificate into cacerts keystore 496 Import SOAP server certificate into CSIv2 trust file 496 import WebSphere Portal users into TAM 303 Important log files 588 initial context 144 Installation CVS for NT 606 DB2 Universal Database 184 Windows 185 IBM GSKit 188 IBM Java Runtime Environment 192 Tivoli Access Manager 207 PDJRTE 381 Web Portal Manager 213 Tivoli Directory Client 219 Tivoli Directory Server 193 Web Administration Tool 196 WebSEAL 220 WebSphere Application Server 197

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

WebSphere Portal 228 Windows 2000 Server 183 Integration guidelines 93, 107 access control of resources within portlets 113 access control of WP resources 113 backend application cookies 110 junction mapping table 112 TAI junction considerations 109 WebSEAL junctions 108 WebSEAL session considerations 114 WebSEAL URL based access control 112 WebSphere Portal session considerations 114 Internal network 60 intruder reconnaissance 15 isCallerInRole method 20 IT architect 10 IT specialist 10 ITSO Bank application architecture and design 396 backend 400 database layer 398 deploy backend application 434 add ITSO attribute to LDAP 437 create application server 435 create data source 440 create database 437 create users and groups 438 deploy EAR 443 determine bootstrap port 435 unpack backend code 436 deploy frontend application 446 add portlets to pages 453 create portal pages 451 externalize resources 467 install portlets 450 modify itsobank.properties 446 modify portlet permissions 463 modify resource permissions 459 wmmLDAPServerAttributes.xml 449 deployment units 399 ITSOBankEAR.ear 400 ITSOBankWAR.war 400 EJB layer 397 frontend 400 helper classes 398 import into WSAD 402 method level security roles ITSOCustomers 400 ITSOManagers 400

modify user info 563 portlets ITSOAccountBalance 397 ITSOTransfer 397 ITSOTransHistory 397 ITSOUser 397 run in WTE 420 sample code download 402 verfiy add user 559 verification 467 verify login 557 verify transfer funds 567 verify view account balance 566 ITSO Bank business scenario 144 ITSO working exampel use case model application login 158 ITSO working example administration secure portal solution 503 application deployment 433 architecture 166 decisions 169 development environment 174 key concepts 168 overview 167 runtime environment 174 business requirements 146 business scenario 144 business challenges 145 initial context 144 development environment architecture 362 hardware used by ITSO 363 planning 362 software used by ITSO 364 functional requirements 146 ITSO Bank customer 146 ITSO Bank manager 147 portal administration 147 security administration 147 ITSO Bank application design 396 prepare development environment 401 presentation layer 396 using Credential Vault 425 using TAM APIs 421 LDAP distinguished name (DN) 267 non-functional requirements 147

Index

693

availability 151 maintainability 152 performance 148 scalability 151 security 152 system constraints 153 runtime environment planning 176 Policy Server node 182 Portal Server node 227 Reverse Proxy node 218 sample code 6325code.zip 684 description 684 download 683 security hardening 471 start / stop servers 548 use case model 155 add user 159 administrative use cases 163 application logout 159 delete user 161 front-end use cases 158 modify user information 160 transfer funds 163 view account balance 162 view transaction history 161 verification add user 559 login 557 modify user info 563 transfer funds 567 view account balance 566 ITSOAccountBalance portlet 397 itsobank.ldif 439 itsobank.properties 447 ITSOBankDataSource data source 440 ITSOBankEAR.ear 400, 443 ITSOBankWAR.war 400, 446 ITSOCustomers 400 ITSOid 419, 437 ITSOManagers 400 ITSOTransfer portlet 397 ITSOTransHistory portlet 397 ITSOUser portlet 397

J J2EE developer 11

694

JAAS See Java Authentication and Authorization Services Java 2 SDK 20 Java Archive 296 Java Authentication and Authorization Services 20 Java Runtime Environment 192 JMT See Junction Mapping Table jmt.conf 308 JRE See Java Runtime Environment junction 297 Junction Mapping Table limitations 112 Junction mapping table 112

K Key concepts 4 keystore 279

L LDAP 31, 193, 266 enable SSL 475–476 LDAP repository 4 ldap-enable-ssl.ldif 477 LDAPHelper class 422 ldaphelper.properties 448 ldapmodify 290, 489 LDAPsearch 584 Light Weight Third Party Authentication 309 Lightweight Third Party Authentication 103 Logical security 17 applications 18 middleware and application software 20 network 22 operating systems 21 IBM AIX 21 Linux 22 Microsoft Windows 21 WebSphere security 18 logout.html 315 Logs access.log 588 error.log 588 http_plugin.log 588 msg_pdacId_utf8.log 590 msg_pdmgrd_utf8.log 590

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

msg_pdmgrdproxyd_utf8.log 590 SystemErr.log 588 SystemOut.log 588 LTPA 597 LTPA configuration 104

M macro support 524 maintainability 152 Management zone 60 MASS See Method for Architecturing Secure Solutions Matching topics to roles 11 Method for Architecting a Security phases analysis 26 developing security architectures 26 integration for solution architecture 26 problem statement 26 system model for security 26 Method for Architecting Secure Solutions 25 Microsoft Windows 2000 Server installation 183 MIME types 296 ActiveX Control (cab) 296 Java Archive (jar) 283, 296 Modifying web.xml 313 msg_pdacld_utf8.log 590 msg_pdmgrd_utf8.log 590 msg_pdmgrdproxyd_utf8.log 590 mutual SSL 276 myportal 535

N Network zone uncontrolled 56 Network zones 56 controlled 57 Node agents 502 nodes Development node 368 Policy Server 182 Portal Server 227 Repository node 366 Reverse Proxy 218 non-functional requirements 147 Novell SuSe Linux 22

O Operational model 52 contents description of each node 52 description of middleware services 52 description of walkthroughs 52 mapping matrix 52 one or more diagrams 52 systems management strategy 52 Outside zone 59

P pages 627 pdadmin 299, 304, 511 pdjrtecfg 382 permission 337, 342 Physical model description 53 Physical security 17 PKI See Public Key Infrastructure Plug-in approach 76 Policy Server node 182, 366 POPs See Protected object policies Portal administrator 11 Portal developer 11 Portal Server node 227 Portal-Backend SSO 96 PQ77683 594 PQ79613 595 PQ79684 595 PQ79819 595 PQ79938 595 PQ80428 595 PQ81912 596 PQ83717 596 PQ86200 596 presentation layer ITSO Bank application 396 private key cryptography 27 Production zone 60 Programming Module Enhancement (PME) 8 Programming Module Extension 237 Project manager 11 Protected object policies 42 public key cryptography 28 Public Key Infrastructure 27

Index

695

R

S

Realms of single sign-on 97 Redbooks Web site 688 Contact us xix Redhat Linux 22 Replace the default SSL certificates for the SOAP connector 490 Repository node 366 requirements ITSO working example 146 performance 148 response time 149 static volumetric 151 throughput 149 utilization 150 Resource Permissions portlet 547 resource type Portlets 547 response time requirements 149 Reverse proxy approach 74 Reverse Proxy node 218 risk management 14 role membership 337 roles 336, 338 Roles and skills 10 IT architect 10 IT specialist 10 J2EE developer 11 portal administrator 11 portal developer 11 project manager 11 security administrator 11 security architect 10 Runtime environment planning hardware used by ITSO 178 installation paths and variables 181 overview 176 prerequisites 177 software used by ITSO 178 using VMWare and Ghost 182 solution software 6 topology selection 69

sample code description 684 download 683 SANS Institute 22 SAS See Security Authentication Service scalability 151 Scanning 16 secret key cryptography 28 secure portal application development 395 Secure portal solution component connections 133 high level architecture 5 high level authentication process 5 high level authorization 6 secure portal solution administration 503 application deployment 433 application development 395 backup key files 549 development environment implementation 361 log files 588 overview 4 authentication 4 authorization 4 credential vault 4 shared LDAP user registry 4 single sign-on 4 runtime environment configuration 259 runtime environment installation 175 security hardening 471 SSO using LTPA 597 SSO using TAI 289 troubleshooting 573 Securing WebSphere Application Server in Network Deployment environment 501 Security network 22 Security administrator 11 Security and design guidelines add external WP Web Server 107 authorization TAM vs WP 95 design principals 94 identity management 105 single sign-on 96 Security architect 10 Security Authentication Service 472

extended enterprise runtime 79 enterprise runtime 73 entry runtime 70

696

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

Security design objectives 54 Security domain 14 intruder reconnaissance 15 logical security 17 logical security categories applications 18 middleware and application software 20 network software 22 operating systems 21 physical security 17 physical security categories buiding access 17 physical network 17 system access 17 systems hardware 17 security policy categories risk analysis 23 security management and audit 23 security policies and procedures 23 source vulnerability 15 security domain figure 14 Security fundamentals 13 security hardening 471 additional guidelines 501 define additional admin roles 501 disable IBM HTTP Server Administration 502 disable unused end points 501 disable unused WebSphere HTTP transports 501 non-admin user 501 secure RMI connectors 501 WAS Network Deployment 501 Security interaction patterns 65 application 67 infrastructure 65 Security policies 23 Security risk management 14, 23 Sequence diagrams common access patterns 115 access protected page with existing valid session 119 access protected portal page with invalid credentials 120 access protected portal page, provide credentials 117 access unprotected portal pages 116 both WebSEAL and WebSphere Portal sessions time out 127

WebSEAL session times out before WebSphere Portal session 121 WebSphere Portal logout after WebSEAL session timeout 131 WebSphere Portal session times out before WebSEAL session 124 server1 application servers 502 serverStatus.bat 534 services.properties 334 Session considerations 114 Session data 39 session timeouts WebSEAL 356 WebSphere Portal 356 Single sign-on 4 guidelines Trust Association Interceptor 99 realms 97 selecting a solution 104 single sign-on configuration LTPA 597 TAI 289 Single sign-on guidelines 96 LTPA token 103 skins 627 SOAP connector replace default SSL cert 490 Software versions 7 Solution software 6 runtime environment 6 Specified model 62 description 53 specified model node description 656 SPNEGO (Keberos) 40 SSL enable IBM HTTP Server 277 enable SSL for LDAP 475 enable Tivoli Access Manager 478 enable WebSEAL 480 enable WebSphere Application Server 281, 481 enable WebSphere Portal 281, 484 Tivoli Directory Server enable client utilities 488 enable Web Admin Tool 487 SSO See Single sign-on

Index

697

SSODomainName 574 starter kit 627 startServer.bat 533 static volumetric 151 Stop and start servers WebSphere Test Environment 392 stopServer.bat 533 Symantec Ghost 182 symmetric key encryption 27 system constraints 153 SystemErr.log 588 SystemOut.log 588

T TAI See Trust Association Interceptor tam-acls.ldif 290 TAMExternalAccessControlServices 336 TAMHelper 398 tamhelper.properties 448 Target redbook audience 10 team development 406 themes 627 throughput 149 Tivoli administration tools 504 Tivoli Acccess Manager global sign-on 46 Tivoli Access Manager apply ACLs to LDAP suffixes 290 authentication goals 38 authentication process flow 40 authorization API 18 authorization APIs 18 authorization vs WebSphere Portal 95 components Authorization Server 36 pdadmin command line utility 36 Policy Server 36 Web Portal Manager 36 WebSEAL 36 configuration 208 Authorization Server 210 Policy Server 209 Runtime 208 Web Portal Manager 213 Windows services startup 213 create objects

698

WebSphere Portal URIs 305 enable SSL for LDAP 478 features authentication 35 authorization 35 centralized security management 35 programmatic authentication and authorization 35 secure communication 35 web single sign-on 35 Global Sign-on 5 installation 207 PDJRTE 213 update Windows registry 211 logs msg_pdacId_utf8.log 590 msg_pdmgrd_utf8.log 590 pdadmin 511 security model authentication 38 client request session and authentication data 38 database used to maintain security policies 36 features and components 35 master authorization database 37 protected object 37 protected object space 37 system resource 37 user registry database 36 web objects 37 WebSEAL 38 start / stop servers 511 trace authentication 591 authorization 593 user create 321 using APIs 421 Web Portal Manager 513 verification 216 WebSEAL configuration 222 create a junction 297 installation 220 Tivoli Access Manager Global Sign-on 46 Tivoli Directory Server client utilities enable SSL for LDAP 488 command line utilities 510

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

configuration 195 configuration tool 506 create a suffix 206 disable non-SSL access 489 enable SSL 476 installation 193 processes 504 start / stop servers 505 Web Administration Tool 507 enable SSL for LDAP 487 Web Administration Tool installation 196 Tivoli Identity Manager 49 ToolBarInclude.jsp 318 Topology zones 53 trace 591 Tracing Trust Association 324 troubleshooting 573 common issues 574 failure creating deployment credentials 575 fixes external access control 594 login 574 2-letter domains 575 browser formatting POST request 574 incorrect SSODomainName 574 usage of hostname in URL 574 problem running portal as service 579 recover portal admin privilage 577 session timeouts 575 tips 582 disable WP security 582 install fixpacks for portal 585 using LDAP client utilities 584 trace 591 authentication 591 WP database tranfers to DB2 fails 580 Trust Association Interceptor 99, 309 methods 100 settings 310 summary how it works 100 Trust Association Interceptor configuration 313

U URL filtering 301 use case model 155 actors defined 155 overview 155 primary actors 155

secondary actors 156 summary of use cases 157 use case diagram 156 user management 513 create users 514 delete users 517 password management 517 user self care 519 User registry 4 utilization 150

V Vault segment 44 Vault slot 44 VaultServices.properties 348 Verfication WebSphere Portal SSL configuration 283 Verification Credential Vault 350 DB2 Universal Database 188 external authorization TAM for WebSphere Portal 336 IBM HTTP Server 280–281 ITSO Bank 467 LDAP configuration 393 Portal Toolkit 380 Portal Toolkit and Test Environment 380 SOAP configuration install porlet via XMLAccess 499 install portlet via GUI 499 TAI configuration 304, 312 create/login new user 321 Tivoli Access Manager ACLs 343 configuration and APIs within Studio 384 object space 343 Web Portal Manager 216 Tivoli Directory Server Web Administration Tool 205 WebSphere Application Server 200 WebSphere Portal 231 Verify SOAP configuration - install portlet via GUI 499 Verify xmlaccess utility- install portlet via xmlaccess 499 Virtual Private Network 23 Virtual Resource resource type 547 VMWare 365

Index

699

VMWare Workstation 182 VPN See Virtual Private Network

W Web objects 37 Web Portal Manager 213, 513 web.xml WebSphere Portal 313 WebSphere Portal SSL 282 webseaId-default.conf 300 WebSEAL 220 additional parameters 303 configuration 222 create a junction 297 create junction syntax parameters 298 customize HTML pages 519 account management pages 522 error pages 520 macro support 524 enable forms authentication 300 enable SSL for LDAP 480 favicon.ico configuration 359 junction cookies 302 junction mapping 302 junction mapping table 307 logs msg_pdmgrdproxyd_utf8.log 590 modify URLs to backend 301 processing of URLs 302 URL based access control 112 URL filtering 301 user sessions 114 WebSEAL authentication methods 39 Basic authentication 40 CDSSO ID token 39 client-side certificate 39 failover cookie 39 forms authentication 40 HTTP headers 40 IP address 40 SPNEGO (Keberos) 40 WebSEAL junction -b supply option 109 -b supply option using mutual SSL 110 custom TAI plugin 110 WebSEAL junctions 108

700

options 108 cookie handling 108 encryption 108 number of junctions 108 TAI 109 WebSEAL to web application authentication flow 98 WebSEAL user sessions 114 WebSphere administration tools 531 WebSphere Application Server Administrative Console 531 authentication protocols CSIv2 472 SAS 472 bootstrap port 435 configuration backup 235 JAAS 325 default_host 281 define additional MIME types 296 disable global security 583 dummy SSL certificates 472 enable SSL 281 enable SSL for LDAP 481 establish trust relationship LTPA 309 TAI 309 host aliases 281 installation 197 logs SystemErr.log 588 SystemOut.log 588 Network Deployment 501 Deployment Manager 501 node agents 502 Programming Module Extension 237 server status 534 serverStatus.bat 534 SOAP connector replace default SSL cert 490 SSL repertoire for CSIv2 474 start / stop servers 533 startServer.bat 533 stopServer.bat 533 verification 200 wsadmin 532 WebSphere Member Services 31 WebSphere Portal

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

access categories WP_admin_access 304 WP_all_access 304 WP_authenticated_access 304 WP_no_access 304 add portlets to pages 453 authorization vs TAM 95 ConfigService.properties 317 configuration Credential Vault 347 login/logout with WebSEAL 313 SOAP connection credentials 495 Content Publisher 242 create portal pages 451 Credential Service 4 Credential Vault 4, 44, 99 credential objects 45 vault segment 45 verification 350 DB2 configuration 261 disable LDAP security 394 disable security 582 enable LDAP security 269 enable LDAP security for WebSphere Portal 388 enable SSL for LDAP 484 encrypt clear text passwords 586 externalize a resource 536 First Steps 231 IBM HTTP Server configuration 264 install portlets 450 installation 228 internalize a resource 537 LDAP configuration 266 logs SystemErr.log 589 SystemOut.log 589 wps_date_time.log 589 manage the Credential Vault 536 modify portlet permissions 463 modify resource permissions 459 read-only LDAP access 269 remove encrypted passwords 587 screens 626 security model administration 31 authentication 32 authorization 34 Credential Vault 33

delegated administration 35 identifyi the user 32 Java security 34 member services 31 persistent connections 33 single sign-on 33 third-party authentication servers 32 self care 31 skins 627 SOAP timeout 241 standalone Web server 107 stop and start server 235 themes 627 trace authentication 592 authorization 593 credential vault 594 URIs 305 define access controls 304 user sessions 114 verification 231 Web administration 535 xmlaccess 544 WebSphere Portal Toolkit installation 378 WebSphere Portal user sessions 114 WebSphere security 18 EJB method level security 19 JAAS 20 WebSphere Studio Application Developer installation 369 WebSphere Studio Application Developer V5.1.1 installation 369 WebSphere Test Environment start and stop 392 wmm_LDAP.xml.IBM_DIRECTORY_SERVER.1.w mm 270 wmmLDAPAttributes_IBM_DIRECTORY_SERVER .xml 271 wmmLDAPServerAttributes.xml 419, 449 WP_admin_access 304 WP_all_access 304 WP_authenticated_access 304 WP_no_access 304 wpconfig.properties DB2 settings 262 disable security 583 LDAP settings 273 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

702

Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1

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 and technologies for a secure portal Deploy a secure portal runtime environment Develop and deploy secure portal application

Portals provide a personalized single point of access to applications, content, and processes through a Web interface. Secure portal solutions are needed to address 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 to 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”, 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”, 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.

INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information: ibm.com/redbooks SG24-6325-00

ISBN 073849044X