Develop and deploy a secure portal solution using web sphere portal v5 and tivoli access manager v5.1 sg246325
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Develop and deploy a secure portal solution using web sphere portal v5 and tivoli access manager v5.1 sg246325

on

  • 3,972 views

 

Statistics

Views

Total Views
3,972
Views on SlideShare
3,972
Embed Views
0

Actions

Likes
0
Downloads
64
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Develop and deploy a secure portal solution using web sphere portal v5 and tivoli access manager v5.1 sg246325 Document Transcript

  • 1. Front coverDevelop and Deploy aSecure Portal SolutionUsing WebSphere Portal V5 and Tivoli Access Manager V5.1Solution architecture and technologiesfor a secure portalDeploy a secure portal runtimeenvironmentDevelop and deploysecure portal application John Ganci Hinrich Boog Melanie Fletcher Brett Gordon Ashwin Manekar Normunds Saumanis Kai Schwidder Jonas Tingebornibm.com/redbooks
  • 2. International Technical Support OrganizationDevelop and Deploy a Secure Portal SolutionUsing WebSphere Portal V5 and Tivoli AccessManager V5.1August 2004 SG24-6325-00
  • 3. 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 TivoliAccess 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 ADPSchedule Contract with IBM Corp.
  • 4. Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiiPart 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
  • 5. 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. 131iv Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 6. 4.4 Component connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Part 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
  • 7. 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 . . . . . . 301vi Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 8. 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 . . . . . . . . . . 3137.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 . . . . . . . . . . . . . . . . . . . . . . . 3377.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3507.8 Additional configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 7.8.1 Configure WebSEAL and WebSphere Portal sesssion timeouts . . 356 7.8.2 Configure WebSEAL to handle favicon.ico . . . . . . . . . . . . . . . . . . . 359Chapter 8. Implement the development environment . . . . . . . . . . . . . . . 3618.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3658.2 Implement the Repository node (optional) . . . . . . . . . . . . . . . . . . . . . . . 3668.3 Implement the Policy Server node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3668.4 Implement the Reverse Proxy node (optional) . . . . . . . . . . . . . . . . . . . . 3668.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
  • 9. 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451viii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 10. 10.3.6 Add portlets to pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 10.3.7 Modify resource permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 10.3.8 Verify ITSO Bank application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 10.3.9 Externalize the ITSO Bank resources . . . . . . . . . . . . . . . . . . . . . . 467Chapter 11. Security hardening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47111.1 Configure CSIv2 SSL settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 11.1.1 Create SSL keys for CSIv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473 11.1.2 Configure the SSL repertoire for CSIv2 . . . . . . . . . . . . . . . . . . . . 47411.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. . . . . . . . . . . . 48911.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 . . . . 49511.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. . . . . . . 502Chapter 12. Manage a secure portal solution. . . . . . . . . . . . . . . . . . . . . . 50312.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53112.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
  • 11. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567Part 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 . . . . . . . . . . . . . . . . . . . . . . . 601x Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 12. 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 . . . . . . . . . . . . . . . . . . . . . . . 602Appendix C. CVS configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603CVS overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604CVSNT Server implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605 CVS Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 CVS Server repository configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606 Create CVS users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609CVS 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611Appendix D. Automate deployment tasks. . . . . . . . . . . . . . . . . . . . . . . . . 613Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616Deployment walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617 Solution structuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619 Populating the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621Concepts and background discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 Component types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625 ITSO WebSphere Portal development starter kit . . . . . . . . . . . . . . . . . . . 627 wpdsk-util command reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642Appendix E. Node descriptions for architecture models . . . . . . . . . . . . 645Conceptual model node description for the runtime environment . . . . . . . . . 646Specified model node description for the runtime environment . . . . . . . . . . . 656Conceptual model node descriptions for development . . . . . . . . . . . . . . . . . 670Specified model node description for development and test environment . . . 676Appendix F. Additional material. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683 System requirements for downloading the Web material . . . . . . . . . . . . . 684 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684Description of sample code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685 Contents xi
  • 13. Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689xii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 14. NoticesThis information was developed for products and services offered in the U.S.A.IBM may not offer the products, services, or features discussed in this document in other countries. Consultyour local IBM representative for information on the products and services currently available in your area.Any reference to an IBM product, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product, program, or service thatdoes not infringe any IBM intellectual property right may be used instead. However, it is the usersresponsibility to evaluate and verify the operation of any non-IBM product, program, or service.IBM may have patents or pending patent applications covering subject matter described in this document.The furnishing of this document does not give you any license to these patents. You can send licenseinquiries, in writing, to:IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.The following paragraph does not apply to the United Kingdom or any other country where such provisionsare inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDESTHIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimerof express or implied warranties in certain transactions, therefore, this statement may not apply to you.This information could include technical inaccuracies or typographical errors. Changes are periodically madeto the information herein; these changes will be incorporated in new editions of the publication. IBM maymake improvements and/or changes in the product(s) and/or the program(s) described in this publication atany time without notice.Any references in this information to non-IBM Web sites are provided for convenience only and do not in anymanner serve as an endorsement of those Web sites. The materials at those Web sites are not part of thematerials for this IBM product and use of those Web sites is at your own risk.IBM may use or distribute any of the information you supply in any way it believes appropriate withoutincurring any obligation to you.Information concerning non-IBM products was obtained from the suppliers of those products, their publishedannouncements or other publicly available sources. IBM has not tested those products and cannot confirmthe accuracy of performance, compatibility or any other claims related to non-IBM products. Questions onthe capabilities of non-IBM products should be addressed to the suppliers of those products.This information contains examples of data and reports used in daily business operations. To illustrate themas completely as possible, the examples include the names of individuals, companies, brands, and products.All of these names are fictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.COPYRIGHT LICENSE:This information contains sample application programs in source language, which illustrates programmingtechniques on various operating platforms. You may copy, modify, and distribute these sample programs inany form without payment to IBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operating platform for which thesample programs are written. These examples have not been thoroughly tested under all conditions. IBM,therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,modify, and distribute these sample programs in any form without payment to IBM for the purposes ofdeveloping, using, marketing, or distributing application programs conforming to IBMs applicationprogramming interfaces.© Copyright IBM Corp. 2004. All rights reserved. xiii
  • 15. TrademarksThe following terms are trademarks of the International Business Machines Corporation in the United States,other countries, or both: AIX® HACMP™ Redbooks™ Balance® IBM® Redbooks (logo) ™ ClearCase® ibm.com® Sametime® Cloudscape™ Lotus Notes® Tivoli® developerWorks® Lotus® WebSphere® Domino® NetView® xSeries® DB2 Universal Database™ Notes® DB2® Rational®The following terms are trademarks of other companies:Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, othercountries, or both.Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in theUnited States, other countries, or both.Java and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the United States, other countries, or both.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
  • 16. 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
  • 17. 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
  • 18. Melanie Fletcher is a Software Engineer in the Gold Coast IBM Tivoli® lab,Australia. She has extensive experience with the Tivoli Access Manager securityproducts ranging from functional verification testing to consulting. She holds adegree in Business and a Masters of Information Technology from theQueensland University of Technology, Australia. Her areas of expertise includesecurity solutions using Tivoli Access Manager and Tivoli Identity Manager.Brett Gordon is a Software Engineer in the IBM Software Group, USA. He hasover five years of experience in technical support for IBM Lotus® Software. Heholds a degree in international economics from the University of Texas at Austin,and he is currently pursuing a Masters degree in Computer Networking fromNorth Carolina State University in Raleigh. His areas of expertise includeintegration, security, and administration of WebSphere Portal and LotusDomino®. He is an IBM Certified System Administrator for WebSphere PortalV5.Ashwin Manekar is a Software Engineer in IBM Software Group Solution Test,USA. He has eight years of experience in application development and ITConsulting for e-business solutions. He holds a Masters degree in ComputerScience from the University of North Carolina at Charlotte, USA. His areas ofexpertise include developing J2EE enterprise applications, portlet development,Click-To-Action technolog,y and Web applications. He has published severalpapers in the area of WebSphere Portal environment setup and portletdevelopment on the IBM developerWorks® technical forum.Normunds Saumanis is an IT Architect in IBM Global Services, Latvia. He hasover 10 years experience in systems support, systems integration, applicationdevelopment and IT consulting. He holds a degree in Computer Science fromMichigan 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. Hehas 14 years of experience in the fields of consulting, application development,and systems integration for e-business and e-commerce solutions. He holds adegree in Computer Science from the Technical University in Berlin, Germany.His areas of expertise include systems integration, application architecture anddevelopment, business to technology consulting, technical team leadership,WebSphere Portal, Tivoli Access Manager, WebSphere Commerce, andWebSphere MQ.Jonas Tingeborn is an IT Specialist in IBM Global Services, Sweden. He hasworked at IBM for six years, of which the last four spent at various e-businessengagements for different customers. His focus areas and previous project rolesinclude application development, e-business consulting, and configurationmanagement with WebSphere Portal, J2EE and Linux. Preface xvii
  • 19. 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, USABecome a published author Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. Youll team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, youll develop a network of contacts in IBM development labs, and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.htmlComments welcome Your comments are important to us!xviii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 20. We want our Redbooks™ to be as helpful as possible. Send us your commentsabout this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an Internet note to: redbook@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HZ8 Building 662 P.O. Box 12195 Research Triangle Park, NC 27709-2195 Preface xix
  • 21. xx Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 22. Part 1Part 1 Introduction to secure portal solutions© Copyright IBM Corp. 2004. All rights reserved. 1
  • 23. 2 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 24. 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
  • 25. 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 Credential4 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 26. Vault can be moved to the Tivoli Access Manager Global Sign-on (GSO) lockbox.1.1.2 Secure portal solution high level architecture There are many possible runtime topologies that can be implemented for a secure portal solution, depending on the security, performance, scalability and integration needs of the business. Figure 1-1 depicts the high level secure portal solution architecture. The figure includes the ficticious ITSO Bank secure portal application. The solution architecture can be applied to many types of applications. Outside Zone Demilitarized Zone Production Zone Portal Server Backend Server Public Key ITSO Bank ITSO Bank Infrastructure Portlets EJBs WebSphere WebSphere Portal Application I Server N T Reverse Web Request E Proxy WMM ITSO Bank Protocol Firewall Domain Firewall Browser Response R Client TAM N WebSEAL E T Policy Directory Server Server Domain Name TAM Tivoli Directory Server Policy Server Server TAM LDAP Authorization User Registry Server AuthorizationFigure 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
  • 27. 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
  • 28. extended enterprise). In addition, we provide guidance on selecting the appropriate runtime topology, as well as define by node the software products and levels. Table 1-1 lists the software products and levels included with IBM Tivoli Access Manager for e-business V5.1, as well as the fixpack levels we used to implement the secure portal runtime environment for the ITSO working example.Table 1-1 Software included with Tivoli Access Manager V5.1 and fixpack levels used by the ITSO Tivoli Access Manager bundled software Tivoli Access Manager ITSO example product name bundled software fixpack version version IBM DB2® UDB, Enterprise Server Edition 8.1 8.1.4.428 Note: 8.1 + Fixpack 4a IBM GSKit 7.0.1.9 7.0.1.16 IBM Java Runtime Environment (JRE) 1.3.1 1.3.1 IBM WebSphere Application Server 5.0.2 5.0.2 Note: Used to host Web administration tools. IBM Tivoli Directory Server 5.2 5.2 * Directory Server * Directory Client SDK * Web Administration Tool IBM Tivoli Access Manager for e-business 5.1 5.1.0.2 * Access Manager Runtime Note: 5.1 + TAM Base * Access Manager Java Runtime Environment Fixpack 2 + WebSEAL (PDJRTE) Fixpack 2 * Access Manager Policy Server * Access Manager Authorization Server * Access Manager Web Portal Manager * Access Manager Web Security Environment *Access Manager WebSEAL Table 1-2 lists the software products and levels included with IBM WebSphere Portal Extend for Multiplatforms V5.0.2, as well as the fixpack levels we used to implement the secure portal runtime environment for the ITSO working example. Chapter 1. Introduction 7
  • 29. Table 1-2 Software included with WebSphere Portal V5.0.2 Extend and fixpack levels used by the ITSO WebSphere Portal Extend bundled software WebSphere Portal ITSO example product name bundled software fixpack version version IBM DB2 UDB, Enterprise Server Edition 8.1.1 8.1.4.428 Note: 8.1 + Fixpack 4a IBM WebSphere Application Server Enterprise * WebSphere Application Server (Base) 5.0.2 5.0.2.3 Note: 5.0 + Fixpack 2 + Note: 5.0 + Fixpack 2 + Fixes Cumulative Base Fix 3 + Fixes * Programming Module Enhancement (PME) 5.0.2 5.0.2.2 Note: 5.0 + Fixpack 2 Note: 5.0 + Fixpack 2 + Cumulative PME Fix 2 IBM Tivoli Directory Server 5.1 5.2 * Directory Server * Directory Client SDK * Web Administration Tool IBM WebSphere Portal Extend for 5.0.2 5.0.2.1 Multiplatforms Note: 5.0 + Fixpack 2 + Note: 5.0 + Fixpack 2 + * WebSphere Portal Fixes Cumulative Fix 1 + Fixes * WebSphere Portal Content Publisher Note: Although we used IBM WebSphere Portal Extend for Multiplatforms V5.0.2, the solution should also work with WebSphere Portal Enable.1.2.2 Development environment solution software Like the runtime environment, there are several possible configurations for implementing a secure portal development environment. The development environment topologies, software products, and levels are described in detail in 3.3, “Development environment topology selection” on page 81. The software we used was included with IBM WebSphere Portal Extend for Multiplatforms V5.0.2, IBM Tivoli Access Manager for e-business V5.1, and fixpack downloads. In addition, we used IBM WebSphere Studio Application Developer V5.1 in place of the WebSphere Portal supplied IBM WebSphere Studio Site Developer V5.1, in large part because the ITSO Bank sample secure portal application includes both front-end portlets and back-end EJBs, which require the Application Developer Edition. We used both Microsoft Windows 2000 Professional and Server Editions, plus Service Pack 4 as the operating system platform for the ITSO development environment.8 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 30. For simplicity, we provide the software levels used for the ITSO-definedall-in-one approach development environment. The all-in-one approach includesone physical machine, and potentially two VMWare virtual machines to host theunit testing nodes. For example, the ITSO all-in-one development environmentincludes the following “nodes” on one physical system: Development node - All application development-related software is installed on the physical system. For details on the software components and levels used refer to Table 1-3 on page 9. Policy Server node - This VMWare virtual machine is used to host the Tivoli Directory Server, Tivoli Access Manager Policy Server, and Authorization Server for unit testing. The software levels used for this node are the same as the Tivoli components listed in Table 1-1 on page 7. Reverse Proxy node - This VMWare virtual machine is optionally used to host the WebSEAL for unique testing scenarios needed in the development environment. The software levels used for this node are the same as the Tivoli components listed in Table 1-1 on page 7. Note: Detailed procedures for implementing the ITSO all-in-one secure portal development environment can be found in Chapter 8, “Implement the development environment” on page 361.Table 1-3 Development node Software Version Microsoft Windows 2000 2000 + Service Pack 4 IBM WebSphere Studio Application 5.1.1 Developer IBM WebSphere Test Environment 5.0.2.3 included with WebSphere Studio Note: Fixpack 2 + Cumulative Fix 3 + Application Developer Fixes IBM WebSphere Portal Toolkit and Test 5.0.2.1 Environment IBM Java Runtime Environment (JRE) 1.3.1 IBM Tivoli Access Manager for e-business 5.1.0.2 * Access Manager Java Runtime Note: 5.1 + Base Fixpack 2 Environment (PDJRTE) Chapter 1. Introduction 9
  • 31. 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
  • 32. Portal developer The portal developer is responsible for developing the portlets for the secure portal solution. In small projects, a developer may perform several roles, including J2EE application developer, portal developer, and Web designer. J2EE developer The J2EE developer is responsible for developing such application code as EJBs and servlets for back-end applications. Project manager The project manager is responsible for managing and leading the project team along all phases of the project and also acts as a contact point to interact with the customer. The project manager should have an understanding of WebSphere Portal and Tivoli Access Manager, and concepts of a secure portal solution. Security administrator The security administrator is responsible for implementing the access control list (ACL) policies and protected object policies (POP) for protected resources. Portal administrator The portal administrator role is responsible for deploying portlets and managing the portal server, including security-related tasks and troubleshooting.1.3.2 Matching redbook topics to roles and skills Table 1-4 provides a summary of the redbook topics by part and chapter/appendix for the defined roles and skills.Table 1-4 Matching redbook topics to roles and skills Chapter/appendix Primary Secondary Part 1, “Introduction to secure portal solutions” on page 1 Chapter 1, “Introduction” on page 3 All user roles Chapter 2, “Security fundamentals” on page 13 All user roles Chapter 3, “Architecture and topology selection” on IT architect All user roles page 51 Security architect Chapter 4, “Design and integration guidelines” on IT architect All user roles page 93 Security architect Part 2, “ITSO working example secure portal solution” on page 141 Chapter 1. Introduction 11
  • 33. Chapter/appendix Primary Secondary Chapter 5, “Requirements and solution design” on IT architect All user roles page 143 Security architect Project manager Chapter 6, “Install the runtime environment” on IT specialist IT architect page 175 Chapter 7, “Configure the runtime environment” on IT specialist IT architect page 259 Security administrator Security architect Portal administrator Chapter 8, “Implement the development Portal developer IT architect environment” on page 361 J2EE developer IT specialist Chapter 9, “Develop the secure portal application” Portal developer IT architect on page 395 J2EE developer Chapter 10, “Deploy the secure portal application” IT specialist Portal developer on page 433 Portal administrator J2EE developer Security administrator IT architect Chapter 11, “Security hardening” on page 471 IT specialist IT architect Security administrator Security architect Chapter 12, “Manage a secure portal solution” on Portal administrator IT specialist page 503 Security administrator IT architect Part 3, “Appendixes” on page 571 Appendix A, “Troubleshooting a secure portal IT specialist Portal developer solution” on page 573 Portal administrator J2EE developer Security administrator IT architect Appendix B, “Configure single sign-on using LTPA” IT specialist IT architect on page 597 Security administrator Security architect Appendix C, “CVS configuration” on page 603 Portal developer IT architect J2EE developer IT specialist Appendix D, “Automate deployment tasks” on IT specialist Portal developer page 613 Portal administrator J2EE developer Security administrator IT architect Appendix E, “Node descriptions for architecture IT architect All user roles models” on page 645 Security architect Appendix F, “Additional material” on page 683 IT specialist IT architect Note: Sample configuration files and ITSO Bank Portal developer sample secure portal application J2EE developer12 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 34. 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
  • 35. 2.1 Security domain and risk management Security is a very vast topic. When developing a strategy for providing a secure environment for your company’s Web site and applications, it is critical to understand the areas of security risk as well as how to reduce security risk. Attention: The security focus in this redbook for the secure portal solution is as follows (see Figure 2-1): Applications Middleware and application software Both WebSphere Portal and Tivoli Access Manager include infrastructure components and APIs to help implement authentication, single sign-on, and authorization for the above-mentioned security categories. The remaining security categories displayed in Figure 2-1 need to be addressed using other tools and processes. Security Policy Security Policies and Procedure Security Management and Audit Risk Analysis Logical Security Applications Vulnerability and Intruder Reconnaissance Middleware and Application Software Operating System Network Software and Communications Physical Security Systems Hardware Physical Network Building and Access to SystemsFigure 2-1 Elements of the security domain14 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 36. 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
  • 37. 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.php16 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 38. 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
  • 39. 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
  • 40. WebSphere Application Resources HTML Servlet/JSP EJBs Naming WebServices User Registry JMX MBeans Access Control WebSphere Security WebSphere Security J2EE Security API Java Security Corba Security / CSIv2 Java 2 Security JVM 1.3 Platform Security Operating System SecurityFigure 2-2 WebSphere Application Server environment security layersFor the ITSO working example, we will limit our WebSphere Application Serversecurity implementation to the WebSphere Security layer depicted in Figure 2-2.The WebSphere Application Server provides the security infrastructure forapplication security, which is transparent to the application developer. In mostcases the security is handled at deployment and runtime. Having said that, whendeveloping EJBs and servlets, there are a few security calls available if thedeveloper wants greater control of what the end user is allow to do beyond whatis provided by the WebSphere infrastructure.There are two key topics we would like to highlight from the WebSphere securitymodel: 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
  • 41. – 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 Domino20 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 42. Within the ITSO working example secure portal solution, we will leverage thefollowing security infrastructure features of WebSphere Application Server, TivoliAccess Manager, WebSphere Portal and Tivoli Directory Server: Authentication Authorization Single sign-on Credential vaultOperating systemsAlthough the Microsoft Windows does have a high percentage of the overalloperating system market share, UNIX/Linux variants are mainstream within theworld of the Internet and Web application hosting.The default settings of most operating system installations leave the system in anunsecure 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
  • 43. – 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
  • 44. 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
  • 45. Prevent Protect Mitigate Risk Risk Analysis Security Policy Emergency Plan Residual Risk Figure 2-3 Risk categorization For risk categorization: 1. First, you have to analyze where the major risks for your enterprise are in order to define procedures that will help prevent these risks from happening. 2. The next step is to define a security policy to deal with assets where you cannot prevent malicious actions without putting protective measures into place. 3. In case protective measures are overcome, you need to have an emergency plan that tells you what to do in those cases. 4. Because these problems are not solved simply by defining a security policy, but require investing money for certain activities and countermeasures, it is for the senior management to decide what residual risk can be accepted. There are always insurance carriers who can provide coverage for these residual risks.24 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 46. 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
  • 47. We have outlined the key phases and tasks of the Method for Architecting a Security (Mass): 1. Problem statement 2. Analysis a. Security-specific taxonomies, models, and methods b. Common Criteria i. Security audit ii. Communication iii. Cryptographic support iv. User data protection v. Identification and authentication vi. Management of security functions vii. Privacy viii.Protection of security functions ix. Resource utilization x. Component access xi. Trusted path or channel 3. System model for security Security subsystems 4. Developing security architectures a. Business process model b. Security design objectives c. Selection and enumeration of subsystems d. Documenting conceptual security architecture 5. Integration into the overall solution architecture a. Solution models b. Documenting architectural decisions c. Use cases d. Refining the functional design e. Integrating requirements into component architectures2.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 model26 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 48. 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
  • 49. The advantages and disadvantages of secret key cryptography are as follows: The advantage of the secret key algorithms is that they are faster in comparison to public key cryptography introduced in “Public key cryptography” on page 28. The disadvantage is that the same key is needed for encryption and decryption, and both parties must have the same keys. In today‘s cryptography, the secret key does not belong to a person, but rather a communication session. At the beginning of a session, one of the parties creates a session key and delivers it to the other party so they can securely communicate. At the end of the session, both parties delete the key and, if they want to communicate again, must create another key. Public key cryptography The public key cryptography (asymmetric key encryption) method uses different keys, such as the Riverst-Shamir-Adleman (RSA) algorithm created by RSA Security Inc., for encrypting and decrypting. For example if you encrypt something with key 1, you can only decrypt it with key 2, as shown in Figure 2-5. Key 1 Key 2 Plain Text Encryption Cipher Text Decryption Plain Text Figure 2-5 Public key cryptography The public key cryptography method allows the use of one public key and the other private. This means that the recipient has a private key that is kept secret, and a public key available to everyone. If a user wants to send an encrypted message to another person, the sender looks up the recipient’s public key (certificate) and uses it to encrypt the message. The message can only be decrypted by the recipient’s private key.28 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 50. 1 2 3 Alice B B Bob Plain Text Public Encrypted Text Private Plain Text Alice A A Bob Plain Text Private Encrypted Text Public Plain TextFigure 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
  • 51. 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
  • 52. 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
  • 53. 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 users 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 successful32 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 54. login, the original user request, along with additional security information in therequest header, is passed to the application server. The format and content ofthis information is vendor specific. WebSphere Application Server uses the TAImodule (that is specific to the third-party product) to extract the necessarysecurity information from the request header.TAI modules for IBM Tivoli Access Manager and Netegrity SiteMinder arepackaged with the portal server (all editions). The WebSphere Application ServerInfoCenter includes information about creating custom TAI modules for otherthird-party Reverse Proxy servers.Single Sign-OnThe portal server provides comprehensive single sign-on (SSO) support. Userswant to be able to log on only once, and be known to the different parts of theportal server with the same consistent user credentials. Users should not beasked to do multiple logons simply because they access different portalapplications.The portal server supports single sign-on realms using WebSphere ApplicationServer and authentication proxies. This means that the user needs to log on onlyonce to gain access to all enterprise applications that are installed within thesingle 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 portalserver creates an LTPA single sign-on cookie containing the authenticated usercredential. This encrypted cookie conforms to the format that is used byWebSphere Application Server and can be decrypted by all application servers inthe shared domain, provided they all have the same cipher key. This cookieenables all servers in the cluster to access the user credentials without additionalprompting, resulting in a seamless single sign-on experience for the user. Tobenefit from the LTPA method of single sign-on, the browser of the user mustsupport cookies and have its support for session cookies enabled.Credential VaultRefer to 2.3.6, “WebSphere Portal Credential Vault” on page 44, for details.Persistent connectionsPortlets that depend on remote connections require some way of maintainingthat connection as users navigate through the portal. The portal provides apersistent back-end connection service that maintains TCP/IP connectionsacross page changes. Some remote applications use forms-based logins andstore cookies during the login form processing. The HttpFormBasedCredentialcan be used for handling these form-based logins and will store all the cookies Chapter 2. Security fundamentals 33
  • 55. 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
  • 56. 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
  • 57. – 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
  • 58. 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 spaceThe protected object space is a hierarchical representation of resources includedin 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 tothe objects in the object space to secure the resource. Policy templates can becreated 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 definingaccess control lists (ACLs) and protected object policies (POPs), and thenapplying the ACLs and POPs to the objects. The Tivoli Access Managerauthorization service evaluates these policies to determine if access should bepermitted to the protected resource. Policies can be explicit or inherited. Chapter 2. Security fundamentals 37
  • 59. 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 credential38 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 60. include a username, group memberships, and special extended securityattributes describe the user in a specific content.If a user is not a member of the user registry (anonymous) WebSEAL builds anunauthenticated credential for that user.Remember that an ACL can contain special rules governing unauthenticatedusers. These credentials are available to the authorization service that permits ordenies access to requested objects in the WebSEAL protected object space.Client request session and authentication dataWhen WebSEAL receives a client request, WebSEAL looks for session data first,followed by authentication data. The initial client request does not containsession 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
  • 61. 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
  • 62. 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
  • 63. 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
  • 64. These conditions are evaluated as a Boolean expression to determine if the request should be allowed or denied. A security policy can be explicity applied or inherited. The Tivoli Access Manager object space supports inheritence of ACLs, POPs and authentication rules. The security administrator needs to apply explicit policies only at points of the hierarchy where the rules change, as seen in Figure 2-7. Explicit Rule Inherited Rule Management Web User-Defined Objects Objects ObjectsFigure 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
  • 65. 2.3.6 WebSphere Portal Credential Vault IBM WebSphere Portal includes the Credential Service and Credential Vault features to allow portlet applications to pass user credentials to a back-end application. The Credential Vault is a portal service that helps portlets and portal users manage multiple identities. The credential vault stores credentials that allow portlets to log in to applications outside the portal realm on behalf of the user. By default, this credential implementation is the portal database, but it also can be a third-party component or another custom repository. Examples of credentials include username and password, SSL client certificates, and private keys. When using Tivoli Access Manager with WebSphere Portal to create secure portal solution, the credential storage for the Credential Vault can be moved to the Tivoli Access Manager Global Sign-on (GSO) lockbox. Vault Implementations Vault Service WebSphere Portal Vault User-managed Segment (U) Slot Ua Slot Ub Slot Uc Administrator-managed Segment (A1) Slot A1a Slot A1b Slot A1c Other Vault Implementation Administrator-managed Segment (A2) Slot A2a Slot A2b Slot A2c Figure 2-8 Credential Vault organization Figure 2-8 depicts the Credential Vault organization. We will describe the following elements of the Credential Vault in more detail: Vault segment Vault slot44 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 66. Credential objectsVault segmentA vault is broken down into vault segments. Vault segments can be user- oradministrator-managed. However, portlets can only create slots in user-managedsegments. Creating slots in administrator-managed segments is limited to theadministrator. Credential creation and retrieval can be carried out by both userand administrator in the portlets. Vault segments map to specific vaultimplementations through vault adapters. A vault adapter is a plug-in used toprovide the Credential Vault service access to a certain credential repository.Vault slotA vault segment is partitioned further into vault slots. The slot is the actuallocation for the user credential. Non-shared slots are specific to both theback-end application and the user. Shared slots are specific only to the back-endapplication.The credential vault provided by the WebSphere Portal distinguishes betweenfour 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 objectsCredentials are returned in the portal in the form of credential objects. These canbe passive or active. Passive credential objects are containers for thecredential’s secret that can then be retrieved by the portlet to authenticate withback-end. Active credential objects hide the credentials secret from the portlet insuch 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 theauthentication. A common passive object type returns username and passwordcredentials. An example of active authentication is HTTP Basic Authentication. Chapter 2. Security fundamentals 45
  • 67. 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 defining46 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 68. object classes to be used for authenticating a user rather than performing a callbased on primary identification attributes of a user (user ID and password).While using an Access Manager GSO junction, Access Manager uses specificLDAP attributes for storing GSO information for every GSO user. As a result, theGSO user ID and password provided for a specific junction are not necessarilythe same as the primary ones. However, a junctioned application sharing thesame LDAP repository would then try to authenticate a user using these valuesagainst primary ones (by doing LDAP bind or compare). The need arises to keepthe values of primary user IDs and passwords the same as GSO IDs andpasswords. inetOrgPerson Primary user ID (uid) Common Primary user password (userPassword) attributes Object classes Application X user object and attributes used by applications Application Y user object sharing LDAP Synchronization Access Manager user object (secUser) principalName Access Manager GSO user object (eGSOUser) GSO resource for Application X Object classes used by User ID Access Manager User Password GSO resource for Application Y User ID User PasswordFigure 2-9 LDAP shared by Access Manager and other applications Chapter 2. Security fundamentals 47
  • 69. 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: secretFigure 2-10 Shared LDAP with separate user entries48 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 70. As a result, while performing authentication, the application will try to bind usingits own user IDs and passwords. The GSO user IDs and passwords could bekept in sync more easily with those maintained by an application. The trade-offsof 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 ManagerTo address the user ID and password synchronization issues, IBM Tivoli IdentityManager software can be used. It provides capabilities for provisioning andmanagement of Tivoli Access Manager users and GSO credentials.Figure 2-11 on page 50 depicts the Tivoli Identity Manager provisioning andpassword management of Tivoli Access Manager users and GSO credentials. Chapter 2. Security fundamentals 49
  • 71. TAM Directory Person TAM UserID TAM Policy Server TAM GSO Credential TAM GSO Credential TAM Admin TAM Admin over SSL over SSL TAM GSO Credential TAM Node TAM TAMGSO Agent Agent over SSL over SSL DAML DAML ITIM Directory Person TAMAccount TAM TAMGSO Service Services TAMGSOAccount ITIM Server TAMGSOAccount TAMGSOAccount Figure 2-11 Tivoli Identity Manager Note: For more detailed information on Tivoli Identity Manager refer to the following redbooks: Identity Management Design Guide with IBM Tivoli Identity Manager, SG24-6996 Enterprise Security Architecture Using IBM Tivoli Security Solutions, SG24-601450 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 72. 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
  • 73. 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 patterns3.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
  • 74. 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
  • 75. 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 security54 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 76. domains you can translate Figure 3-1 into something more targeted, as shown in Figure 3-2 on page 59. Outside Zone Demilitarized Zone Production Zone Internal Network Restricted Protocol Firewall Domain Firewall Domain Firewall Uncontrolled Controlled Controlled Domain Firewall Secured Management ZoneFigure 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
  • 77. 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
  • 78. Internet DMZ (controlled zone)The Internet DMZ is generally a controlled zone that contains components withwhich clients may directly communicate. It provides a buffer between theuncontrolled Internet and internal networks. Because this DMZ is typicallybounded by two firewalls, there is an opportunity to control traffic at multiplelevels: 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 networksThe transport between a controlled and an uncontrolled zone is classified aspublic. The transport between a controlled and another controlled or a restrictedzone is classified as managed.Production zone (restricted zone)One or more network zones may be designated as restricted, that is, theysupport functions to which access must be strictly controlled and, of course,direct access from an uncontrolled network should not be permitted. As with anInternet 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 asmanaged. The transport between a restricted and a secured zone is classified astrusted.Intranet (controlled zone)Like the Internet DMZ, the corporate intranet is generally a controlled zone thatcontains components with which clients may directly communicate. It provides abuffer to the internal networks.Management zone (secured zone)One or more network zones may be designated as a secured zone. Access isonly available to a small group of authorized staff. Access into one area does notnecessarily give you access to another secured area.The transport into a secured zone is classified as trusted.Other networksKeep in mind that the network examples we use do not necessarily include allpossible situations. There are organizations that extensively segment functionsinto various networks. However, in general, the principles discussed here may betranslated easily into appropriate architectures for such environments. Chapter 3. Architecture and topology selection 57
  • 79. 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 users58 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 80. 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 Portal Domain Reverse Proxy Portal Server Backend Domain Node Web Server App Server Caching Proxy Reverse Proxy Node Node Public Key Infrastructure Instant Collaboration Messaging Node Node Web Development Browser Domain Client Load Balancer Portal Internet Directory Replica Database Domain Rich Development Domain Firewall Domain Firewall Protocol Firewall Domain Client Node Data Directory Server Node Node Domain Name Caching Proxy Reverse Proxy Server Domain Firewall Load Balancer Hot Standby Access Manager Domain Policy App Web Server Server Server Node Node Node Wireless Gateway Directory Domain App Web Data Mobile Directory Server Server Server Client Node Node Node Node Management Zone Legend: Data related flows Security related flowsFigure 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
  • 81. 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
  • 82. Outside Zone Demilitarized Zone Production Zone Internal Network • Static Page Serving • Data Source Connectivity Authentication • Servlet Redirector Portal Domain • Business Logic (Also request routing • Transaction Management Reverse Proxy and authorization) Portal • Content Transcoding Server Backend Domain Node Web Server App Server Caching Proxy Load Balancing Node Node Reverse Proxy • Content Transcoding Public Key (Request routing) • Access Control List Infrastructure • Content Aggregation Instant Collaboration • Document Management Messaging Advanced Caching Node • Document Editors Node Web (Also request routing and • Credential Services Development Browser • UDDI Directory Services dynamic caching) Domain Client Load Balancer Asynchronous Synchronous Portal Internet Directory Replica Database Domain Rich Interaction Interaction Development Domain Firewall Domain Firewall Protocol Firewall Domain Client (e-Mail) (e-Meeting, etc.) Node Data Directory Server Node Node • Authentication & Domain Authorization Engine Caching Proxy Name Reverse Proxy • Rule-Based Policies Server Domain Firewall • Role-Based Policies Load Balancer Hot Standby Access Manager Domain • Database supporting LDAP • User Records Policy App Web • Group Data Server Server Server • Organizational Data Node Node Node Wireless • Credential Repository Gateway Directory Domain App Web Data Mobile Directory Server Server Server Client Node Node Node Node Management Zone Legend: Data related flows Security related flowsFigure 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
  • 83. 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
  • 84. Outside Zone Demilitarized Zone Production Zone Internal Network Portal Domain Caching Reverse Proxy App Proxy Backend Domain Server SECP1 Node SIRP Web Web Server App Server Browser SPPORTAL Node Node Client Reverse SPHTTPD SPBANK Proxy Instant Collaboration Development SERP1 Messaging Domain Node Node Portal SPDOMINO SPSAMETIME Development Caching Node Domain Firewall Load Directory Database Domain Internet Proxy Replica Domain SIDEVELOP Balancer Protocol Firewall Domain Firewall SECP2 Directory Data Server SELB Node Node SPLDAPR SPDB Reverse Proxy Domain Firewall SERP2 Access Manager Domain Policy App Web Server Server Server Node Node Node SMTAM SMWAS1 SMHTTP1 Directory Domain App Web Data Directory Server Server Server Node Node Node Node SMLDAP SMWAS2 SMHTTP2 SMDB Management Zone Legend: Data related flows Security related flowsFigure 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
  • 85. The node interaction matrix is shown in Table 3-1. It describes the relationship of specified nodes with their characteristics, for example, which type of communication protocol is used. Table 3-1 Node interaction matrix From To Characteristics User SELB HTTP (80), HTTPS (443) SELB SERP1,SERP2 HTTP (80), HTTPS (443) SERP1,SERP2 SECP1,SECP2 HTTP (80), HTTPS (443) SERP1,SERP2 SPLDAPR LDAP(389), LDAPS(636) SERP1,SERP2 SMTAM TAM_SSL(7135,7136) SMTAM SERP1,SERP2 TAM_SSL(7234) SECP1,SECP2 SPPORTAL HTTP (9081), HTTPS (9444) SPPORTAL SPHTTPD HTTP(80), HTTPS(443) SPHTTPD SPBANK HTTP(9082), HTTPS(9445) SPPORTAL SPDOMINO HTTP(80), HTTPS(443) SPPORTAL SPSAMETIME HTTP(80), HTTPS(443) SPPORTAL,SPDOMIN SPLDAPR LDAP(389), LDAPS(636) O,SPSAMETIME SPLDAPR,SPPORTAL, SPDB Database client/server SPBANK connection ports (50000,50001) SMLDAP SPLDAPR LDAP(389), LDAPS(636) SMLDAP,SMWAS2,SM SMDB Database client/server WAS1 connection ports (50000,50001) SMHTTP1 SMWAS1 HTTP(9080), HTTPS(9443) SMHTTP2 SMWAS2 HTTP(9080), HTTPS(9443) SMTAM SMLDAP LDAP(389), LDAPS(636) SIDEVELOP SPPORTAL FTP(21)64 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 86. 3.1.5 Security interaction patterns Based on the given specified model, we identified the common security interaction patterns to develop and deploy a secure portal. The identified security interaction patterns are classified based on their characteristics: Infrastructure (deployment related) Application (development related) Infrastructure The deployment of secure portal solutions is related to the implemented infrastructure and topology as described in 3.1.2, “Topology zones” on page 53. In general we can identify two patterns: Access to non-secured resources Access to secure resources Access to non-secured resources A secure portal solution may have assets that are not protected at all. In general, the portal provides public information and portlets that are accessible to the public. 1 2 User Load Balancer 4 6 Reverse Proxy Application 5 3 DirectoryFigure 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
  • 87. 3. The Reverse Proxy accesses the directory to verify if the requested resource is protected. 4. The Reverse Proxy redirects the request to the back-end system, including back-end related security credentials fetched from the directory. 5. The request is processed by the back-end and the result is passed to the Reverse Proxy. 6. The Reverse Proxy redirects the response to the user’s browser. Access to secure resources A secure portal solution has assets which are protected. Therefore, the user has to be authenticated and authorized to access the protected assets. 1 2 User Load Balancer 4 6 Reverse Proxy 7 Application 8 5 Policy Server 3 DirectoryFigure 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
  • 88. 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.ApplicationThe application security variations are important in order to define therelationship between the policy server capabilities and the runtime environmentfor the application. An application can be classified as a collection of resourcessuch as HTML forms, JSPs, servlets, back-end classes, and beans. Each one ofthe resources has some or no security context or interface. We can group theapplication security into three main categories: Programmatic approach Declarative approach Mixed approachProgrammatic approachWhen applications control security by themselves using an internal proprietaryprocess, code, and database to grant, deny, log, and manage security, they haveimplemented programmatic access control. Generally, the applications requestprincipal information about users and resources, and they use security API callsto retrieve access control information for those principals. Finally, the applicationlogic enforces security by granting or denying access to specific resourcesprovided by the application.Using this approach, applications become the decision factor for security andmay even bypass important security checks. Usually this is done when there isno general infrastructure in place to handle security. This encompasses allresources for the application such as Web pages, back-end classes, and EJBs, ifavailable.Declarative approachApplications use declarative access control by using an external source for theactual access control checking. There is no proprietary logic, and the applicationcommunicates with the access control system using a specific and well-knownset of rules defined by an API interface. The application does not implement orcombine access rules, it just uses the ones provided, limiting the access controlcheck to what the API can offer.After querying the access control subsystem as to whether a given principal mayaccess a requested resource, the application receives a simple yes or noanswer, and based on that answer it either grants or denies the respective Chapter 3. Architecture and topology selection 67
  • 89. access. This can be considered the ideal situation, since it defines the scope and responsibility of the application in the authorization request and transaction execution steps. This also implies that the application does not control the actual flow of the logic, and that it is more difficult, if not impossible, to bypass the authorization layer in this case. Mixed approach This is not really a category of its own, but covers the situation where applications benefit from the infrastructure available when possible (using declarative techniques) and implement only a few special controls using standard API calls (ideally compliant with JAAS, J2EE, or some other well-known standard). We recommend that you carefully use the programmatic approach to enhance the rule checking mechanism by providing fine-grained access controls when there is a lack of native APIs to offer that capability, but still utilizing one unique API set to handle the core requests. Figure 3-7 shows each application component separated in secure/non-secure sections. Since we want to discuss the security measures that we can accommodate in Access Manager, we concentrate on examining the secure components. Application X Transactional Backend Interface Pages Objects Class Files (JSP, HTML,Portlets) (EJB) Non- Non- Non- Secure Secure Secure Secure Secure SecureFigure 3-7 Simple application security categories68 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 90. Figure 3-8 on page 69 provides a view for each secure component showing which kind of controls we can add using access management capabilities, and combining those possibilities with the application categories. Application X Transactional Backend Interface pages Objects Class Files (JSP, HTML,Portlets) (EJB) Secure Secure Secure Non- Non- Non- Declarative: Declarative: Realms Programmatic: Secure Secure Secure Reverse Proxy (i.e. WebSeal) Programmatic: In-house or Policy Server Permissions Programmatic: Session Control Policy Server PermissionsFigure 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
  • 91. 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
  • 92. 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. Thedeployment of the node is based on best practices and follows therecommendations 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 involvedcomponent 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
  • 93. Outside Zone Demilitarized Zone Production Zone • IBM WebSphere Portal Extend V5.0.2.1 • IBM WebSphere Application Server Enterprise 5.0.2.3 • IBM DB2 UDB 8.1.4, ESE • IBM JRE 1.3.1 • Tivoli Access Manager 5.1 (PDJRTE) • Microsoft Windows 2000 Server + SP4 Web • Tivoli Access Manager Browser Portal/Backend Domain 5.1.0.2 (Runtime, PDJRTE, Client Web Security, WebSeal) • IBM GSKit 7.0.1.16 PPBANK • IBM JRE 1.3.1 • Microsoft Windows 2000 SPPORTAL SPHTTPD SPBANK SPDB Protocol Firewall Domain Firewall Server + SP4 Internet Reverse Proxy Domain Firewall PERP Access Manager/Directory Domain SERP1 PMTAM SMTAM SMLDAP SMDB SMHTTP2 • Tivoli Access Manager 5.1.0.2 (Runtime, PDJRTE, Policy, Authorization, Web Portal Mgr) • Tivoli Directory Server 5.2 (Server, Client SDK, Web Administration Tool) • IBM DB2 UDB 8.1.4, ESE • IBM GSKit 7.0.1.16 • IBM JRE 1.3.1 • IBM WebSphere Application Server 5.0.2 • Microsoft Windows 2000 Server + SP4 Management Zone Legend: Data related flows Security related flowsFigure 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
  • 94. 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
  • 95. 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
  • 96. Outside Zone Demilitarized Zone Production Zone WebSphere Internal Network WebSphere Portal Extend 5.0.2.1 Application Server 5.0.2.3 Portal Domain Tivoli Access Manager 5.1.0.2 (WebSEAL) PPPORTAL Backend Domain Web SPPORTAL Browser Reverse PPBANK Proxy Lotus Client Sametime Lotus Domino/Notes SPBANK SPHTTPD PERP1 WebSphere Edge SERP1 PPNOTES PPST Components Development Tivoli Directory Server 5.2 SPDOMINO SPSAMETIME Domain Load Balancer Directory DB2 Database PIDEV Internet Replica Domain Domain Protocol Firewall Domain Firewall Domain Firewall PELB SIDEVELOP PPLDAPR PPDB SELB SPLDAPR SPDB Reverse Tivoli Access Manager 5.1.0.2 Proxy (Policy and Authorization) Domain Firewall PERP2 Access Manager Domain SERP2 PMTAM • Tivoli Directory Server 5.2 SMTAM SMWAS1 SMHTTP1 • DB2 Tivoli Access Manager 5.1.0.2 (WebSEAL) Directory Domain PMLDAP SMLDAP SMWAS2 SMHTTP2 SMDB Management Zone Legend: Data related flows Security related flowsFigure 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
  • 97. 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 PPDB DB(50000,50001) ANK PMTAM PMLDAP LDAP(386), LDAPS(636) PMLDAP PPLDAPR LDAP(389), LDAPS(636) PIDEV PPPORTAL FTP(21) Plug-in approach The plug-in approach has the advantage of implementing a secure infrastructure in three phases: 1. Implementation of the topology zones including the load balancing and caching proxy components. Setting up the enterprise directory and policy services without enabling the security capabilities in the demilitarized zone. 2. Enabling the plug-in capability to perform authorization and authentication requests. 3. Leveraging the plug-in by extending existing Web servers. For performance reasons, a set of Caching Proxy nodes can be provided balanced through the Load Balancer node. Each physical Caching Proxy node includes the security plug-in to connect to directory replicas for security reasons. In addition, they communicate via a secure channel with the policy server to verify authorization and authentication requests. If access is granted, then the request is passed to the corresponding back-end system. For each back-end system a so called junction is defined, which rules the mapping.76 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 98. 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. Outside Zone Demilitarized Zone Production Zone WebSphere Internal Network WebSphere Portal Extent 5.0.2.1 Application Server 5.0.2.3 • WebSphere Caching Proxy Portal Domain • Tivoli Access Manager 5.1.0.2 Plugin PPPORTAL Backend Domain Web SPPORTAL Caching/ PPBANK Browser Plugin Proxy Lotus Client Lotus Domino/ SPHTTPD SPBANK Sametime PECP1 Notes WebSphere Edge SECP1 PPNOTES PPST Components Tivoli Directory Development Server 5.2 SPDOMINO SPSAMETIME Domain Load Balancer Directory DB2 Database PIDEV Internet Replica Domain Protocol Firewall Domain Domain Firewall PELB Domain Firewall SIDEVELOP SELB PPLDAPR PPDB SPLDAPR SPDB Caching/ Plugin Proxy Tivoli Access Manager Domain Firewall 5.1.0.2 (Policy and PECP2 Authorization.) Access Manager Domain SECP2 PMTAM SMTAM SMWAS1 SMHTTP1 • WebSphere Caching Proxy • Tivoli Directory • Tivoli Access Manager Server 5.2 5.1.0.2 Plugin • DB2 Directory Domain PMLDAP SMLDAP SMWAS2 SMHTTP2 SMDB Management Zone Legend: Data related flows Security related flowsFigure 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
  • 99. 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 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 PPDB DB(50000,50001) ANK PMTAM PMLDAP LDAP(389), LDAPS(636) PMLDAP PPLDAPR LDAP(389), LDAPS(636) PIDEV PPPORTAL FTP(21)78 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 100. 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
  • 101. Outside Zone Demilitarized Zone Production Zone Internal Network WebSphere Portal Extend 5.0 • WebSphere Application WebSphere Caching Proxy Server 5.0.2.3 Portal Domain • IBM HTTP Server 1.3.26 Reverse Tivoli Access Manager Caching Proxy 5.1.0.2 (WebSEAL) Proxy PPPORTAL Backend Domain PIRP PECP2 SPPORTAL Web Reverse PPHTTP PPBANK SIRP Browser SECP2 Proxy Client Lotus Domino/Notes SPHTTPD SPBANK PERP1 Lotus Sametime WebSphere Edge SERP1 PPNOTES PPST Components Tivoli Directory Caching Development Server 5.2 SPDOMINO SPSAMETIME Proxy Domain Domain Firewall Load Domain Firewall Balancer PECP1 Directory Database PIDEV Internet Replica Domain DB2 Domain Protocol Firewall PELB SECP1 SIDEVELOP SELB PPLDAPR PPDB WebSphere Caching Proxy SPLDAPR SPDB Reverse Proxy Domain Firewall PERP2 Tivoli Access Manager 5.1.0.2 (Policy and Authorization) SERP2 Access Manager Domain PMTAM 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 flowsFigure 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 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)80 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 102. 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 PPDB DB(50000) ANK 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
  • 103. Pre-production tests (performance analysis and tuning aspects). Deployment within the production (solution goes live). Figure 3-13 illustrates the end-to-end steps to develop, test, optimize, and deploy a secure portal solution. The developer develops source code and performs unit-tests. If they pass the unit-test, a package is created with additional information for integration on a test environment. When tests have passed, the package is prepared for a pre-production deployment, including further release documentation. Within the pre-production environment the performance characteristics are analyzed and, if necessary, the solution has to be tuned. If it passes the pre-production tests the package is ready to be deployed to a production environment. At that time the secure portal solution is deployed and accessible by the customers. In case of an error, the application is analyzed within the pre-production environment. The analysis outcome is passed to the developer based on a trouble ticket, which contains detailed information about the error and its behavior. The assigned developer fixes the error and passes the corrected module to the test environment. Development Test/Integration Pre-Production Production (Optional) Module A Module B Handover Handover Handover Tuning Performs Module C Fix to be tested Analysis Error Passed to the developer Module CFigure 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 characteristics82 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 104. A set of topologies to provide a development/test environment Teaming aspects when developing and deploying secure portal solutions3.3.1 Conceptual model The conceptual model of the development/test environment sketches all required nodes and provides detailed information at a conceptual level. The level of abstraction affects the description of the conceptual nodes, such as: Numbers and location of developers Location and nature of interfaces to external systems for testing purposes Business-related deployment units and their operational requirements (such as resources, availability and security) Identifying the nodes and connections required for deployment information Development Repository Node Node Reverse Proxy Portal Server Node Node Directory Server Data Server Node Node Policy Server NodeFigure 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
  • 105. 3.3.2 Specified model Based on the given conceptual model, we refine the nodes by specifying the characteristics within the boundary of the associated development/test domain. At that stage technological limitations are fully taken into account but the detailed choice of technology is not made. The following factors affect the description of the specified nodes depending on various levels of abstraction: Detailed specifications of connections, computer system, operating systems characteristics, and nonfunctional characteristics, communications protocols, middleware, quantity, etc. Problem management, configuration management, change management, performance management etc. Simulations and prototypes are developed and run to verify design decisions, etc. Development Repository Node Node SDWB SDREP Reverse Proxy Portal Server Node Node SDRP SDPORTAL Directory Server Data Server Node Node SDLDAP SDDB Policy Server Node SDTAMFigure 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
  • 106. 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
  • 107. Physical Machine using VMWare for Test Nodes SDWB PDWB SDPORTAL Tivoli Access Manager 5.1.0.2 SDREP (WebSEAL) • WebSphere Studio Application Developer 5.1.1 PDRP • WebSphere Portal Toolkit and SDRP Test Environment 5.0.2.1 • CVS • Windows 2000 + SP4 SDTAM PDTAM SDLDAP SDDB Legend : • Tivoli Access Manager 5.1.0.2 Physical (Policy and Authorization) Virtual • Tivoli Directory Server 5.2Figure 3-16 All-in-one approach Table 3-6 Node interaction matrix 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)86 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 108. 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
  • 109. Development Domain Test Domain PDWB PDRP PDPORTAL SDWB SDRP SDPORTAL • WebSphere Studio Application W WebSphere Portal Developer 5.1.1 PDREP Extend 5.0.2.1 • WebSphere Portal SDREP Toolkit 5.0.2.1 PDTAM Tivoli Access SDTAM SDLDAP SDDB CVS Manager 5.1.0.2 • Tivoli Access Manager 5.1.0.2 (WebSEAL) (Policy and Authorization) • Tivoli Directory Server 5.2Figure 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 sessions88 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 110. 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. Development Domain Test Domain PDWB PDRP PDPORTAL SDWB SDRP SDPORTAL Tivoli Access Manager WebSphere Portal • WebSphere Studio 5.1.0.2 (WebSEAL) Extend 5.0.2.3 PDREP Application Developer 5.1.1 • WebSphere Portal Toolkit SDREP PDTAM 5.0.2.1 SDTAM SDLDAP SDDB CVS • Tivoli Access Manager 5.1.0.2 (Policy and Authorization) • Tivoli Directory Server 5.2Figure 3-18 Develop, deploy, and remote debugging Chapter 3. Architecture and topology selection 89
  • 111. 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: Sharing a common security infrastructure Supporting a large team of development process Minimizing the required hardware investments Providing a secure portal integration environment90 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 112. 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 SDRP PDPORTAL • WebSphere Studio Application Developer 5.1.1 PDREP PDTAM • WebSphere Portal Extend WebSphere Portal Extend V5.0.1 SDREP V5.0.2.1 • Portal Toolkit 5.0.2.1 SDTAM SDLDAP SDDB CVS • Tivoli Access Manager 5.1.0.2 (Policy & Authorization Servers) • Tivoli Directory Server 5.2Figure 3-19 Develop using a shared security infrastructure Chapter 3. Architecture and topology selection 91
  • 113. Table 3-9 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 PDWB HTTP(9081), HTTPS(9444) PDWB PDTAM LDAPS(636) PDRP PDPORTAL HTTP(9081), HTTPS(9444) PDPORTAL PDTAM LDAPS(636)92 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 114. 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
  • 115. 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 Portal4.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 the94 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 116. 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
  • 117. 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
  • 118. Cross-Domain SSO Client-Web App SSO Portal-Backend SSO Web Client Application Back-end Application Client Portlet Authentication WebSphere Proxy Portal Other Domain Portlet Back-end Authentication Application Proxy Web ApplicationFigure 4-1 Realms of single sign-onFigure 4-2 illustrates the general request processing steps for WebSEALauthentication and authorization when WebSEAL is configured to useforms-based login and cookie based session IDs. Note that the diagram does notinclude other processing that WebSEAL may perform, such as content filtering,cookie handling, etc. These steps are common for both TAI- or LTPA-enabledjunctions. The internal details of the two highlighted steps differ between TAI andLTPA junctions. They are illustrated in Figure 4-3 on page 102 and Figure 4-5 onpage 104, respectively. Chapter 4. Design and integration guidelines 97
  • 119. User requests a URL from a web browser Is URL WebSEAL No accessible to No session exists? unauthenticated users? Yes Yes Create a session by setting PD-S- SESSION-ID cookie in HTTP response Is URL No accessible to this user? Send HTTP 302 Yes response redirecting Create a new session the web browser to by setting PD-S- the WebSEAL login SESSION-ID cookie page in HTTP response Build HTTP request to the junctioned server User enters username Send HTTP 302 and password response redirecting and submits the web browser to the form the original URL Issue the HTTP request and get the response from the junctioned server Web browser Validate user automatically credentials in LDAP requests the URL. user registry PD-S-SESSION-ID session cookie is sent to WebSEAL Build HTTP response for the user No User credentials Yes valid? Send the response to Send an error the user page Display the WebSEAL response Figure 4-2 WebSEAL to Web application authentication flow This section describes the following single sign-on capabilities when integrating WebSphere Portal and Tivoli Access Manager: Credential Vault integration with GSO98 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 120. Trust Association Interceptor (TAI) LTPA token support Selecting a single sign-on solutionCredential Vault integration with GSOWebSphere Portal provides an implementation of Vault Adapter(com.ibm.wps.sso.vaultservice.AccessManager41VaultAdapter) that uses theGSO Lockbox to store the user credentials. It allows you to consolidate thesensitive user data into a single GSO repository.Trust Association Interceptor (TAI)When using Tivoli Access Manager for a secure portal solution, the WebSEAL isused as Reverse Proxy and entry point to all service requests. The intent of thisimplementation is to have WebSEAL as the only exposed entry point. As such, itauthenticates all requests that come in and provides course-granularity junctionpoint authorization.When the WebSphere Application Server is used as a back-end server it furtherexploits its fine-grained access control. The WebSEAL can pass HTTP requeststhat include credentials of the authenticated used to the WebSphere ApplicationServer. The WebSphere Application Server then uses these credentials toauthorize the request.WebSphere Application Server includes the Trust Association Interceptor Modewithin its security framework, which is capable of interfacing with third-partyobjects that intercept requests issued by trusted proxy servers, such asWebSEAL. These objects are collectively known as Trust AssociationInterceptors (TAI) or simply interceptors. WebSphere Application Server includesa TAI plug-in for the WebSEAL.TAI implies that the WebSphere Application Server security applicationrecognizes and processes HTTP requests received from WebSEAL. WebSphereand WebSEAL engage in a contract in which the former gives its full trust to thelatter, which means that WebSEAL applies its authentication policies on everyWeb request that is dispatched to the WebSphere Application Server.This trust is validated by the interceptors that reside in the WebSphereApplication Server environment for every request received. The method ofvalidation is agreed on by WebSEAL and the interceptor. Setting values forparameters defined in the webseal.properties file that resides on the WebSphereApplication Server server determine the method of validation for the interceptors. Chapter 4. Design and integration guidelines 99
  • 121. 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 the100 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 122. 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 ApplicationServer request processing steps in more detail for TAI-based single sign-onusing a junction created with the -b supply option. Chapter 4. Design and integration guidelines 101
  • 123. Start building the TAI validates in LDAP request to the the WebSEAL user id junctioned server specified in TAI username property with the extracted password Create BA header using actual client id and dummy password No User/password combination valid? Yes No -c junction option specified? Extract client username from iv_user header Yes Insert iv_user, iv_groups, iv_creds headers as specified by No -c option iv_user extracted successfully? Yes Send request to Use the extracted value WebSphere Application WebSphere as authenticated user id Server authorization assumes for WebSphere unauthenticated user authorization TAI extracts the password from BA header Process the request in WebSphere Application Server Send response back to WebSEAL Figure 4-3 WebSEAL request processing for TAI junction with -b supply option102 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
  • 124. LTPA token supportThe WebSphere Application Server can be configured to use a Lightweight ThirdParty Authentication (LTPA) token (that is, cookie) to provide single sign-onacross multiple servers. After the user has been authenticated by WebSphere,an LTPA cookie is created and sent to the browser. The browser will return thiscookie on subsequent requests, enabling the origin WebSphere ApplicationServer (or other WebSphere Application Server within the same TCP domain) torecognize the user. The LTPA cookie is protected by a 3DES key, which alsoproves that it was created by a trusted source.The Tivoli Access Manager WebSEAL can generate an LTPA token that will beaccepted by the WebSphere Application Server. WebSphere Application Servertrusts 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 LTPAkey is generated on the WebSphere machine and then exported to a keyfile(protected by a password). This keyfile must then be manually copied to theWebSEAL machine. When the junction to the WebSphere server is configured, itis specified as an LTPA junction, and the keyfile and password are given asparameters. Key 3 File WebSphere Application Server HTTP Request Internet WebSEAL 4 John John Application 6 John 2 Bind Directory 5 Username=? Password=?Figure 4-4 WebSEAL creates LTPA cookies for authenticated usersWhen a user authenticates to WebSEAL and requests a resource on thisjunction, WebSEAL creates an LTPA cookie using the key from the keyfile. Thisencrypted cookie contains the user’s Access Manager user ID and is included inthe HTTP request sent to the WebSphere server. When WebSphere receives theHTTP request, it extracts the user ID from the LTPA cookie and uses it to build aWebSphere credential for the user. It would be usual for WebSEAL and Chapter 4. Design and integration guidelines 103
  • 125. WebSphere to share a registry to avoid synchronization problems. WebSphere then applies its own authorization decision to the request. Note: Appendix B, “Configure single sign-on using LTPA” on page 597, includes a configuration example for using an LTPA token in a secure portal single sign-on configuration. Figure 4-5 illustrates the WebSEAL request building and WebSphere Application Server request processing steps in more detail for LTPA-based single sign-on. Start building the request to the junctioned server Create LTPA token with No LTPA token valid? the current user id Yes Encrypt the LTPA token with the imported LTPA Use the extracted value encryption key as authenticated user id for WebSphere authorization Send request to WebSphere Application Use the extracted value Server WebSphere as authenticated user id authorization assumes for WebSphere unauthenticated user authorization WAS decrypts the LTPA token