Professional Documents
Culture Documents
John Ganci
Hinrich Boog
Melanie Fletcher
Brett Gordon
Ashwin Manekar
Normunds Saumanis
Kai Schwidder
Jonas Tingeborn
ibm.com/redbooks
International Technical Support Organization
August 2004
SG24-6325-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page xiii.
This edition applies to IBM WebSphere Portal Extend for Multiplatforms V5.0.2.1 and IBM Tivoli
Access Manager for e-business V5.1.0.2 on the Microsoft Windows platform.
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
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
iv Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4.4 Component connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Contents v
6.3.3 Install Java Runtime Environment (JRE) . . . . . . . . . . . . . . . . . . . . 219
6.3.4 Install Tivoli Directory Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.3.5 Tivoli Access Manager - WebSEAL installation . . . . . . . . . . . . . . . 220
6.3.6 Tivoli Access Manager - WebSEAL configuration. . . . . . . . . . . . . . 222
6.3.7 Tivoli Access Manager V5.1 Base Fixpack 2 installation . . . . . . . . 225
6.3.8 Tivoli Access Manager V5.1 WebSEAL Fixpack 2 installation . . . . 226
6.4 Implement the Portal Server node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.4.1 Windows 2000 Server installation . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.4.2 WebSphere Portal Server V5.0 installation. . . . . . . . . . . . . . . . . . . 228
6.4.3 WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2)
installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.4.4 WebSphere Application Server V5.0.2 Fixes installation . . . . . . . . 237
6.4.5 WebSphere Portal V5 Fixpack 2 (V5.0.2) installation . . . . . . . . . . . 240
6.4.6 WebSphere Application Server Enterprise V5.0.2 Cumulative Fix
(V5.0.2.3) installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
6.4.7 WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) installation. 251
6.4.8 Java Runtime Environment (JRE) V1.3.1 installation . . . . . . . . . . . 254
6.4.9 Tivoli Access Manager Java Runtime Environment installation . . . 255
6.4.10 DB2 Universal Database installation . . . . . . . . . . . . . . . . . . . . . . . 257
vi Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7.5.6 Configure additional WebSEAL parameters . . . . . . . . . . . . . . . . . . 303
7.5.7 Import WebSphere Portal users and groups into TAM . . . . . . . . . . 303
7.5.8 Define access controls for WebSphere Portal URIs . . . . . . . . . . . . 304
7.5.9 Configure the junction mapping table . . . . . . . . . . . . . . . . . . . . . . . 307
7.5.10 Configure SSO for WebSEAL and WebSphere via TAI . . . . . . . . 308
7.5.11 Configure Portal login/logout for use with WebSEAL . . . . . . . . . . 313
7.6 Configure Portal for authorization with TAM . . . . . . . . . . . . . . . . . . . . . . 322
7.6.1 Configure the SSL between WebSphere and TAM. . . . . . . . . . . . . 322
7.6.2 Implement JAAS authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
7.6.3 Modify WebSphere Portal configuration files . . . . . . . . . . . . . . . . . 331
7.6.4 Verify entries in TAM for Portal external authorization . . . . . . . . . . 336
7.6.5 Example for externalizing a resource . . . . . . . . . . . . . . . . . . . . . . . 337
7.7 Integrate the Credential Vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
7.7.1 Credential Vault overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
7.7.2 Configure the Credential Vault for Tivoli Access Manager . . . . . . . 348
7.7.3 Verify the Credential Vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
7.8 Additional configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
7.8.1 Configure WebSEAL and WebSphere Portal sesssion timeouts . . 356
7.8.2 Configure WebSEAL to handle favicon.ico . . . . . . . . . . . . . . . . . . . 359
Contents vii
8.6 Configure WebSphere Portal for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 386
8.6.1 Create a suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
8.6.2 Import the LDIF file (wp-itso.ldif) to create users and groups . . . . . 387
8.6.3 Enable LDAP security for WebSphere Portal . . . . . . . . . . . . . . . . . 388
8.6.4 Stop/start servers in WebSphere Test Environment . . . . . . . . . . . . 392
8.6.5 Verify the LDAP configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
8.6.6 Disable LDAP security in WebSphere Portal . . . . . . . . . . . . . . . . . 394
8.7 Additional configuration (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
viii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
10.3.6 Add portlets to pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
10.3.7 Modify resource permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
10.3.8 Verify ITSO Bank application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
10.3.9 Externalize the ITSO Bank resources . . . . . . . . . . . . . . . . . . . . . . 467
Contents ix
12.2.3 WebSphere Application Server - Command-line tools . . . . . . . . . 533
12.2.4 WebSphere Portal - Web administration . . . . . . . . . . . . . . . . . . . . 535
12.2.5 WebSphere Portal - XMLAccess. . . . . . . . . . . . . . . . . . . . . . . . . . 544
12.2.6 Externalize virtual resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
12.3 Start and stop servers for ITSO example nodes . . . . . . . . . . . . . . . . . . 548
12.4 Back up and restore of key configuration files and databases . . . . . . . 549
12.4.1 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
12.4.2 Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
12.5 Verifying the ITSO Bank application and runtime . . . . . . . . . . . . . . . . . 557
12.5.1 Banking application login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
12.5.2 Add user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
12.5.3 Modify user information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
12.5.4 View account balance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
12.5.5 Transfer funds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
x Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Import WebSphere Portal users and groups into TAM . . . . . . . . . . . . . . . 601
Define access controls for WebSphere Portal URIs . . . . . . . . . . . . . . . . . 602
Configure the junction mapping table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Configure Portal login/logout for WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 602
Contents xi
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
xii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, and service names may be trademarks or service marks of others.
xiv Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Preface
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 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.
xvi Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Melanie Fletcher is a Software Engineer in the Gold Coast IBM Tivoli® lab,
Australia. She has extensive experience with the Tivoli Access Manager security
products ranging from functional verification testing to consulting. She holds a
degree in Business and a Masters of Information Technology from the
Queensland University of Technology, Australia. Her areas of expertise include
security solutions using Tivoli Access Manager and Tivoli Identity Manager.
Brett Gordon is a Software Engineer in the IBM Software Group, USA. He has
over five years of experience in technical support for IBM Lotus® Software. He
holds a degree in international economics from the University of Texas at Austin,
and he is currently pursuing a Masters degree in Computer Networking from
North Carolina State University in Raleigh. His areas of expertise include
integration, security, and administration of WebSphere Portal and Lotus
Domino®. He is an IBM Certified System Administrator for WebSphere Portal
V5.
Preface xvii
Thanks to the following people for their contributions to this project:
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you'll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
xviii Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
We want our Redbooks™ to be as helpful as possible. Send us your comments
about this or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HZ8 Building 662
P.O. Box 12195
Research Triangle Park, NC 27709-2195
Preface xix
xx Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Part 1
Part 1 Introduction to
secure portal
solutions
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.
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.
Single sign-on
Single sign-on provides users with the ability to log on once (authenticate) and
be able to access resources or applications within the enterprise the user has
been granted permissions.
Credential Vault
WebSphere Portal includes the Credential Service and Credential Vault features
to allow portlet applications to pass user credentials to a back-end application.
The Credential Vault is a portal service that helps portlets and portal users
manage multiple identities. When using Tivoli Access Manager with WebSphere
Portal to create a secure portal solution, the credential storage for the Credential
4 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Vault can be moved to the Tivoli Access Manager Global Sign-on (GSO)
lockbox.
WebSphere WebSphere
Portal Application
I
Server
N
T Reverse
Web Request
E Proxy
WMM ITSO Bank
Protocol Firewall
Domain Firewall
Browser Response R
Client TAM
N WebSEAL
E
T
Policy Directory
Server Server
Domain Name TAM Tivoli Directory
Server Policy Server Server
TAM LDAP
Authorization User Registry
Server
Authorization
The following example illustrates how a customer using a Web browser would
interact with the ITSO Bank secure portal solution to access a protected resource
such as a customer account balance. We will first log on to the ITSO Bank site to
outline the process of authentication, and then highlight the process of
authorization to the secure portal page.
1. Authenticate the customer.
a. The customer enters a URL in the Web browser to access a resource that
is protected by the WebSEAL.
Chapter 1. Introduction 5
b. The WebSEAL determines that the user has attempted to access a
protected resource and will prompt the user with a logon page.
c. The user enters her username and password in the logon form and then
submits them to the WebSEAL.
d. The WebSEAL then interacts with the Tivoli Access Manager Policy
Server and Tivoli Directory Server to validate the identity of the user in the
Tivoli Access Manager user registry.
e. The WebSEAL uses the validated identity to obtain a credential for that
user.
2. Authorized access to the secure resource.
In this example, the customer would like to view her account balance.
a. The WebSEAL interacts with the Tivoli Access Manager authorization
services with the user credentials to permit or deny access to protected
objects (for example, bank account balance) after evaluating the access
control list (ACL) permissions and protected object policy (POP).
b. WebSEAL forwards the request to WebSphere Portal.
c. The account balance portlet interacts with the back-end EJBs to retrieve
the customer account balance.
d. The WebSEAL sends the response to the Web browser client to display
the contents of the portal page.
6 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
extended enterprise). In addition, we provide guidance on selecting the
appropriate runtime topology, as well as define by node the software products
and levels.
Table 1-1 lists the software products and levels included with IBM Tivoli Access
Manager for e-business V5.1, as well as the fixpack levels we used to implement
the secure portal runtime environment for the ITSO working example.
Table 1-1 Software included with Tivoli Access Manager V5.1 and fixpack levels used by the ITSO
Tivoli Access Manager bundled software Tivoli Access Manager ITSO example
product name bundled software fixpack version
version
Table 1-2 lists the software products and levels included with IBM WebSphere
Portal Extend for Multiplatforms V5.0.2, as well as the fixpack levels we used to
implement the secure portal runtime environment for the ITSO working example.
Chapter 1. Introduction 7
Table 1-2 Software included with WebSphere Portal V5.0.2 Extend and fixpack levels used by the ITSO
WebSphere Portal Extend bundled software WebSphere Portal ITSO example
product name bundled software fixpack version
version
The software we used was included with IBM WebSphere Portal Extend for
Multiplatforms V5.0.2, IBM Tivoli Access Manager for e-business V5.1, and
fixpack downloads. In addition, we used IBM WebSphere Studio Application
Developer V5.1 in place of the WebSphere Portal supplied IBM WebSphere
Studio Site Developer V5.1, in large part because the ITSO Bank sample secure
portal application includes both front-end portlets and back-end EJBs, which
require the Application Developer Edition. We used both Microsoft Windows
2000 Professional and Server Editions, plus Service Pack 4 as the operating
system platform for the ITSO development environment.
8 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
For simplicity, we provide the software levels used for the ITSO-defined
all-in-one approach development environment. The all-in-one approach includes
one physical machine, and potentially two VMWare virtual machines to host the
unit testing nodes. For example, the ITSO all-in-one development environment
includes the following “nodes” on one physical system:
Development node - All application development-related software is installed
on the physical system. For details on the software components and levels
used refer to Table 1-3 on page 9.
Policy Server node - This VMWare virtual machine is used to host the Tivoli
Directory Server, Tivoli Access Manager Policy Server, and Authorization
Server for unit testing. The software levels used for this node are the same as
the Tivoli components listed in Table 1-1 on page 7.
Reverse Proxy node - This VMWare virtual machine is optionally used to host
the WebSEAL for unique testing scenarios needed in the development
environment. The software levels used for this node are the same as the
Tivoli components listed in Table 1-1 on page 7.
Note: Detailed procedures for implementing the ITSO all-in-one secure portal
development environment can be found in Chapter 8, “Implement the
development environment” on page 361.
Chapter 1. Introduction 9
Note: In the development environment, we chose to use the Cloudscape™
included with WebSphere Studio Application Developer to host the ITSO Bank
database. In the runtime environment we used DB2 UDB.
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.
IT architect
The IT architect looks after the overall project technical architecture/design,
quality assurance of the solution, knowledge transfer to customer, and mentoring
to the project technical team members. The architect should have WebSphere
Portal and Tivoli Access Manager architecture and design skills.
Security architect
The role of a security architect is to eliminate or greatly reduce the possibility of
an intruder attack. When developing a strategy for providing a secure portal
solution it is critical that the security architect understand the areas of risk and
ensure that the solution architecture addresses the known risk categories.
IT specialist
The role of IT specialist represents a wide range of technical specialists,
including systems administrator, database administrator, pre-sales support,
technical support, and tester.
10 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Portal developer
The portal developer is responsible for developing the portlets for the secure
portal solution. In small projects, a developer may perform several roles,
including J2EE application developer, portal developer, and Web designer.
J2EE developer
The J2EE developer is responsible for developing such application code as EJBs
and servlets for back-end applications.
Project manager
The project manager is responsible for managing and leading the project team
along all phases of the project and also acts as a contact point to interact with the
customer. The project manager should have an understanding of WebSphere
Portal and Tivoli Access Manager, and concepts of a secure portal solution.
Security administrator
The security administrator is responsible for implementing the access control list
(ACL) policies and protected object policies (POP) for protected resources.
Portal administrator
The portal administrator role is responsible for deploying portlets and managing
the portal server, including security-related tasks and troubleshooting.
Chapter 1. Introduction 11
Chapter/appendix Primary Secondary
Chapter 10, “Deploy the secure portal application” IT specialist Portal developer
on page 433 Portal administrator J2EE developer
Security administrator IT architect
12 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2
Attention: The security focus in this redbook for the secure portal solution is
as follows (see Figure 2-1):
Applications
Middleware and application software
Security Policy
Risk Analysis
Logical Security
Applications
Vulnerability and
Intruder Reconnaissance Middleware and Application Software
Operating System
Physical Security
Systems Hardware
Physical Network
14 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
As you can see from Figure 2-1, many of these topics are common to all Web
applications. This section introduces the concepts of each security category and
provides reference information for further reading.
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.
16 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The book Hacking Exposed: Network Security Secrets & Solutions, Forth
Edition, by Stuart McClure et al, provides a good explanation of the process
and strategies used by intruders, as well as methods of denying the attack.
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.
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.
Note: For more information on the Tivoli Access Manager authorization APIs,
refer to the following:
Section 9.3, “Using the Tivoli Access Manager APIs” on page 421,
includes an example of using the Tivoli Access Manager authorization
APIs for the ITSO Bank sample secure portal application.
Authorization Java Classes Developer Reference, IBM Tivoli Access
Manager V5.1, SC32-1350, product guide.
Enterprise Security Architecture Using IBM Tivoli Security Solutions,
SG24-6014.
WebSphere security
The IBM WebSphere Application Server V5 is a J2EE V1.3 compliant Java
application server, and it implements the required security services as they are
specified. IBM WebSphere Application Server security sits on top of the
operating system security and the security features provided by other
components, including the Java language, as shown in Figure 2-2.
18 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
WebSphere Application Resources
HTML
Servlet/JSP
EJBs
Naming WebServices
User Registry
JMX MBeans
Access Control
Java 2 Security
JVM 1.3
For the ITSO working example, we will limit our WebSphere Application Server
security implementation to the WebSphere Security layer depicted in Figure 2-2.
There are two key topics we would like to highlight from the WebSphere security
model:
EJB method level security
The EJB 2.0 specification defines two methods that allow programatic access
to the caller’s security context (javax.ejb.EJBContext):
– java.security.Principal getCallerPrincipal()
The getCallerPrincipal method allows the developer to get the name of
the current caller.
IBM also offers a wide range of application software that also includes features
for scalability, hosting applications, and application development, such as:
DB2 Universal Database™
Lotus Notes® and Domino
20 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Within the ITSO working example secure portal solution, we will leverage the
following security infrastructure features of WebSphere Application Server, Tivoli
Access Manager, WebSphere Portal and Tivoli Directory Server:
Authentication
Authorization
Single sign-on
Credential vault
Operating systems
Although the Microsoft Windows does have a high percentage of the overall
operating system market share, UNIX/Linux variants are mainstream within the
world of the Internet and Web application hosting.
The default settings of most operating system installations leave the system in an
unsecure state. For example, you will need to stop all unused ports, services,
and applications that are not needed.
Microsoft Windows
Regardless of the operating system, it is important to keep current with
service levels. The service packs often contain fixes for security problems. It
seems as though every time you access the Microsoft site, there is some
critical security update that is needed for Windows.
Some common security issues on Windows include gaining access to
Administrator by password guessing, poor account policies, buffer overflows,
cracking the Security Accounts Manager (SAM), and back doors.
For more information on Windows 2000 security issues, refer to the following:
– Microsoft Security home page:
http://www.microsoft.com/security/default.asp
– SANS Institute, Information Reading Room for Windows 2000:
http://rr.sans.org/win2000/win2000_list.php
IBM AIX®
For information on IBM AIX security issues, refer to the following:
– IBM AIX home page:
http://www.ibm.com/servers/aix/
– IBM AIX Service Bulletins and Security Advisories:
http://techsupport.services.ibm.com/server/nav?fetch=sbasa
– SANS Institute, Information Reading Room for general UNIX:
http://rr.sans.org/unix/unix_list.php
Network
There are a variety of elements of a network that need to be considered for a
security strategy. Most companies today use the Internet for Web applications
and protect their networks and systems with firewalls. All it takes is one dial-up
networking analog connection without proper security and your firewall strategy
has been circumvented. In this section, we highlight the key areas of security
consideration as they relate to the network.
Firewalls
A properly configured firewall can go a long way to protect your network. All
too often administrators will rely on firewalls to be a cure-all for their security
strategy, and do not take the necessary corrective action for the other
elements identified. What happens if an intruder does bypass your firewall?
By learning certain information, such as what type of firewall your company
uses, an intruder can try to infiltrate your network using documented security
holes for the given firewall.
Network devices
Through the use of scanning techniques, intruders can discover network
devices and information on your network such as CISCO routers, operating
system identification, SNMP devices, and switches.
22 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Virtual Private Network (VPN)
A Virtual Private Network or VPN is a private network that is configured to be
used within a public network such as the Internet. VPNs provide security over
the public network using encryption. The key point is that along with the many
benefits of VPNs, there is added risk of intruder attack.
These guidelines are very important in implementing a robust security for the
whole system organization-wide.
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.
Risk
Analysis
Security
Policy
Emergency
Plan
Residual
Risk
24 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2.2 Method for Architecting Secure Solutions (MASS)
In the previous section, we reviewed the key types of security within the security
domain. In this section, we provide a summary of how the Method for
Architecting Secure Solutions (MASS) can be used to analyze the security
category risks and develop the security solution architecture.
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.
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.
26 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Authentication
Authorization
WebSphere Portal Credential Vault
Tivoli Access Manager Global Sign-on (GSO)
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.
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.
Key 1 Key 2
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
1 2 3
Alice B B Bob
Alice A A
Bob
Plain Text Private Encrypted Text Public Plain Text
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.
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
Digital certificates encrypt data using Secure Sockets Layer (SSL) technology,
the industry-standard method for protecting Web communications. The SSL
security protocol provides data encryption, server authentication, message
integrity, and optional client authentication for a TCP/IP connection. Because
SSL is built into all major Web browsers and servers, simply installing a digital
certificate turns on the browser’s SSL capabilities.
Transmitting sensitive data, such as credit card numbers and other personal data
across the Web and intranets requires authentication to ensure that the
destination of the data is legitimate. Also, encryption is used to protect the data
against interception or tampering, and message integrity to ensure that the
information is not tampered with during transmission. SSL is the standard
technology used to protect information transmitted over the Web via HTTP
protocol and protects against site spoofing, data interception, and tampering.
Certificates, which are based on the open standard X.509, contain the following
information:
Version number (certificate format)
Serial number (unique value from CA)
Algorithm ID (signing algorithm used)
Issuer (name of CA)
Period of validity (from and to)
Subject (user’s name)
Public key (user’s public key and name of algorithm)
Digital signature
Created by CA
Encrypted with CA’s private key
Managing certificates can be arduous. You can install your own Public Key
Infrastructure (PKI) and maintain it, or use the services of a Certificate Authority
(CA), such as VeriSign. CAs issue digital certificates and validate the holder’s
identity and authority. They embed an individual’s or an organization’s public key
along with other identifying information into each digital certificate and then
cryptographically sign it as a tamper-proof seal, verifying the integrity of the data
within it and validating its use.
30 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2.3.2 WebSphere Portal security model
This section highlights the key features of the WebSphere Portal security model.
Member services
Centralized administration of user identities, credentials, and permissions is
desirable in many environments. The portal server includes facilities for defining
portal users and managing user access rights. The user and group subsystem
includes Web pages where users can register and manage their own account
information, administration portlets for managing user accounts and group
information, plus a repository that stores all the information about portal users. It
provides services to create, read, update, and delete users or groups in the
repository. User profile information includes general information such as the
name of the user and user ID, plus preference information such as news topics of
interest, preferred language, and so on. A user might be a member of one or
more groups, and groups can contain other groups.
The default set of user profile attributes is based on the inetOrgPerson schema,
which is supported by most LDAP directories. The user repository might consist
of multiple data sources. By default, the repository consists of two data sources:
It is a combination of a database and a directory server. The database might be
any of the databases that are supported by WebSphere Portal. Any one of
several LDAP directory products are supported, including the Netscape (iPlanet)
Directory Server, Microsoft Active Directory, Novell eDirectory, Lotus Domino,
and IBM Directory Server.
The mapping of user profile attributes to LDAP object classes is defined in the file
wms.xml. This file specifies the names of the various data repositories and how
they are navigated to retrieve user and group information. These settings are
configured differently for each supported LDAP directory; if you want to try using
a directory that is not supported, these values would need to be set appropriately
for that directory server.
The file attributeMap.xml specifies the details of how each attribute is mapped to
the LDAP directory or database. This mapping file also includes metadata about
each attribute such as its data type, whether it is required, whether it can have
multiple values, and so on.
Administration
Administration of users and groups can be performed by users themselves
known as self care or by portal administrators. The portal server includes forms
for registering new users and administration portlets for updating user and group
information.
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.
When a user tries to access the portal, the third-party authentication proxy
intercepts the request and challenges the user to authenticate. After a successful
32 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
login, the original user request, along with additional security information in the
request header, is passed to the application server. The format and content of
this information is vendor specific. WebSphere Application Server uses the TAI
module (that is specific to the third-party product) to extract the necessary
security information from the request header.
TAI modules for IBM Tivoli Access Manager and Netegrity SiteMinder are
packaged with the portal server (all editions). The WebSphere Application Server
InfoCenter includes information about creating custom TAI modules for other
third-party Reverse Proxy servers.
Single Sign-On
The portal server provides comprehensive single sign-on (SSO) support. Users
want to be able to log on only once, and be known to the different parts of the
portal server with the same consistent user credentials. Users should not be
asked to do multiple logons simply because they access different portal
applications.
The portal server supports single sign-on realms using WebSphere Application
Server and authentication proxies. This means that the user needs to log on only
once to gain access to all enterprise applications that are installed within the
single sign-on realm.
Credential Vault
Refer to 2.3.6, “WebSphere Portal Credential Vault” on page 44, for details.
Persistent connections
Portlets that depend on remote connections require some way of maintaining
that connection as users navigate through the portal. The portal provides a
persistent back-end connection service that maintains TCP/IP connections
across page changes. Some remote applications use forms-based logins and
store cookies during the login form processing. The HttpFormBasedCredential
can be used for handling these form-based logins and will store all the cookies
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.
Granting view access to a page or place means that other users will see pages
and places when they log in. Granting view access to a portlet means that users
can add it to their pages when they customize their portal experience. Granting
edit access means that a user can set the portlet settings or change the contents
of a page. Manage access means that a user can perform view and edit
operations, and can delete the portlet or page.
34 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Delegated administration
Granting view access to administration portlets is an effective way of delegating
certain administrative tasks to other portal users. Those users can add the
administration portlets to their personal pages, and then can perform whatever
task the portlet is designed to do. This way, the user does not have to be given
all administrative privileges or be added to the portal administrator group. Her
administrative abilities are limited to only those tasks that are covered by the
authorized portlets.
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
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.
36 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The user registry contains all users and groups allowed to participate in the
Tivoli Access Manager secure domain.
In the ITSO working example secure portal solution, the Tivoli Directory
Server LDAP directory database (for example, ldapdb) contains the user
registry shared by the Tivoli Directory Server, Tivoli Access Manager,
WebSphere Portal and WebSphere Application Server.
Master authorization (policy) database
The Tivoli Access Manager authorization database contains a representation
of all resources in the protected objects space of the secure domain. The
security administrator is responsible for implementing the access control list
(ACL) policies and protected object policies (POP) for resources that require
protection, which are stored in the authorization database.
The physical resources in the object space that can be protected are as follows:
System resource: This is an actual file or application resource.
Protected object: This is a logical view of a physical resource referenced by
the Tivoli Access Manager authorization service, Web Portal Manager, or
pdadmin command line utility.
The security administrator can define policy templates that can be attached to
the objects in the object space to secure the resource. Policy templates can be
created and attached to the following object space categories:
Web objects: Web objects include resources addressed by an HTTP/HTTPS
request to the WebSEAL.
Tivoli Access Manager management objects.
User defined objects: User-defined objects include customer-defined tasks or
resources protected by applications that use the authorization APIs.
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
38 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
include a username, group memberships, and special extended security
attributes describe the user in a specific content.
40 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7. The session ID and credential are stored as an entry in the WebSEAL
session/credential cache.
8. The WebSEAL interacts with the Tivoli Access Manager authorization
services with the user credentials to permit or deny access to protected
objects (for example, bank account balance) after evaluating the access
control list (ACL) permissions and protected object policy (POP).
9. When the user logs off, the cache entry for that user is removed and the
session is terminated with the WebSEAL.
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.
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.
42 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
These conditions are evaluated as a Boolean expression to determine if the
request should be allowed or denied.
A security policy can be explicity applied or inherited. The Tivoli Access Manager
object space supports inheritence of ACLs, POPs and authentication rules. The
security administrator needs to apply explicit policies only at points of the
hierarchy where the rules change, as seen in Figure 2-7.
Explicit
Rule
Inherited
Rule
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
Slot Ua
Slot Ub
Slot Uc
Administrator-managed
Segment (A1)
Slot A1a
Slot A1b
Slot A1c
Figure 2-8 depicts the Credential Vault organization. We will describe the
following elements of the Credential Vault in more detail:
Vault segment
Vault slot
44 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Credential objects
Vault segment
A vault is broken down into vault segments. Vault segments can be user- or
administrator-managed. However, portlets can only create slots in user-managed
segments. Creating slots in administrator-managed segments is limited to the
administrator. Credential creation and retrieval can be carried out by both user
and administrator in the portlets. Vault segments map to specific vault
implementations through vault adapters. A vault adapter is a plug-in used to
provide the Credential Vault service access to a certain credential repository.
Vault slot
A vault segment is partitioned further into vault slots. The slot is the actual
location for the user credential. Non-shared slots are specific to both the
back-end application and the user. Shared slots are specific only to the back-end
application.
Credential objects
Credentials are returned in the portal in the form of credential objects. These can
be passive or active. Passive credential objects are containers for the
credential’s secret that can then be retrieved by the portlet to authenticate with
back-end. Active credential objects hide the credential's secret from the portlet in
such a way that there is no way of extracting it out of the credential. In return,
active credential objects offer business methods that take care of all the
authentication. A common passive object type returns username and password
credentials. An example of active authentication is HTTP Basic Authentication.
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.
46 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
object classes to be used for authenticating a user rather than performing a call
based on primary identification attributes of a user (user ID and password).
While using an Access Manager GSO junction, Access Manager uses specific
LDAP attributes for storing GSO information for every GSO user. As a result, the
GSO user ID and password provided for a specific junction are not necessarily
the same as the primary ones. However, a junctioned application sharing the
same LDAP repository would then try to authenticate a user using these values
against primary ones (by doing LDAP bind or compare). The need arises to keep
the values of primary user IDs and passwords the same as GSO IDs and
passwords.
inetOrgPerson
Object classes
Application X user object
and attributes
used by
applications Application Y user object
sharing LDAP Synchronization
principalName
User ID
User Password
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
applicationX secUser
principalName: JonDoe
applicationY
eGSOUser
GSO resource
Synchronization User ID: JDoe
User password: secret
48 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
As a result, while performing authentication, the application will try to bind using
its own user IDs and passwords. The GSO user IDs and passwords could be
kept in sync more easily with those maintained by an application. The trade-offs
of this solution are:
The need to maintain the user information sets per application sharing the
same LDAP.
As the same user identity would exist multiple times, it would raise the direct
cost if the licensing of the LDAP software is on a per-user basis.
Figure 2-11 on page 50 depicts the Tivoli Identity Manager provisioning and
password management of Tivoli Access Manager users and GSO credentials.
Person
TAM UserID
TAM
Policy Server
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
Note: For more detailed information on Tivoli Identity Manager refer to the
following redbooks:
Identity Management Design Guide with IBM Tivoli Identity Manager,
SG24-6996
Enterprise Security Architecture Using IBM Tivoli Security Solutions,
SG24-6014
50 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3
52 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Depending on the stage of analysis and design, nodes and connections may be
conceptual, specified, or actual physical computer systems:
Conceptual corresponds to an early stage of design. Conceptual nodes
ignore many technological limitations and focus on application software
components, deferring treatment of middleware and other software.
Specified refers to a detailed specification of a computer platform or network.
Technological limitations are fully taken into account, but the detailed choice
of technology is not made.
Physical refers to the specific types of computers, networks, and software
that make up the system.
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.
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.
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.
54 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
domains you can translate Figure 3-1 into something more targeted, as shown in
Figure 3-2 on page 59.
Restricted
Protocol Firewall
Domain Firewall
Domain Firewall
Uncontrolled Controlled Controlled
Domain Firewall
Secured
Management Zone
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)
56 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Internet DMZ (controlled zone)
The Internet DMZ is generally a controlled zone that contains components with
which clients may directly communicate. It provides a buffer between the
uncontrolled Internet and internal networks. Because this DMZ is typically
bounded by two firewalls, there is an opportunity to control traffic at multiple
levels:
Incoming traffic from the Internet to hosts in the DMZ
Outgoing traffic from hosts in the DMZ to the Internet
Incoming traffic from internal networks to hosts in the DMZ
Outgoing traffic from hosts in the DMZ to internal networks
Other networks
Keep in mind that the network examples we use do not necessarily include all
possible situations. There are organizations that extensively segment functions
into various networks. However, in general, the principles discussed here may be
translated easily into appropriate architectures for such environments.
Tip: Plan your security polices around your business model, not the other way
around.
58 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Location and nature of interfaces to external systems
Business-related deployment units and their operational requirements (such
as resources, availability and security)
Geographical location of these deployment units and the associated
decisions about their replication, distribution, etc.
Identifying the nodes and connections required
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
Domain Firewall
Protocol Firewall
Domain
Client Node
Data
Directory Server
Node Node
Domain
Name
Caching Proxy
Reverse Proxy
Management Zone
Legend:
Data related flows
Security related flows
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
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
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
Management Zone
Legend:
Data related flows
Security related flows
“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
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.
62 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
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
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 flows
Figure 3-4 shows the nodes that are specified in Table 3-1 on page 64.
64 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3.1.5 Security interaction patterns
Based on the given specified model, we identified the common security
interaction patterns to develop and deploy a secure portal. The identified security
interaction patterns are classified based on their characteristics:
Infrastructure (deployment related)
Application (development related)
Infrastructure
The deployment of secure portal solutions is related to the implemented
infrastructure and topology as described in 3.1.2, “Topology zones” on page 53.
In general we can identify two patterns:
Access to non-secured resources
Access to secure resources
1 2
User Load Balancer
4
6
Reverse Proxy Application
5
Directory
1 2
User Load Balancer
4 6
Reverse Proxy 7 Application
8
5
Policy Server
3
Directory
66 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
6. If access is granted the Reverse Proxy redirects the request to the back-end
system, including back-end related security credentials.
7. The request is processed by the back-end and the result is passed to the
Reverse Proxy.
8. The Reverse Proxy redirects the response to the user’s browser.
Application
The application security variations are important in order to define the
relationship between the policy server capabilities and the runtime environment
for the application. An application can be classified as a collection of resources
such as HTML forms, JSPs, servlets, back-end classes, and beans. Each one of
the resources has some or no security context or interface. We can group the
application security into three main categories:
Programmatic approach
Declarative approach
Mixed approach
Programmatic approach
When applications control security by themselves using an internal proprietary
process, code, and database to grant, deny, log, and manage security, they have
implemented programmatic access control. Generally, the applications request
principal information about users and resources, and they use security API calls
to retrieve access control information for those principals. Finally, the application
logic enforces security by granting or denying access to specific resources
provided by the application.
Using this approach, applications become the decision factor for security and
may even bypass important security checks. Usually this is done when there is
no general infrastructure in place to handle security. This encompasses all
resources for the application such as Web pages, back-end classes, and EJBs, if
available.
Declarative approach
Applications use declarative access control by using an external source for the
actual access control checking. There is no proprietary logic, and the application
communicates with the access control system using a specific and well-known
set of rules defined by an API interface. The application does not implement or
combine access rules, it just uses the ones provided, limiting the access control
check to what the API can offer.
After querying the access control subsystem as to whether a given principal may
access a requested resource, the application receives a simple yes or no
answer, and based on that answer it either grants or denies the respective
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.
Application X
Transactional
Backend Interface Pages
Objects
Class Files (JSP, HTML,Portlets)
(EJB)
68 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 3-8 on page 69 provides a view for each secure component showing
which kind of controls we can add using access management capabilities, and
combining those possibilities with the application categories.
Application X
Transactional
Backend Interface pages
Objects
Class Files (JSP, HTML,Portlets)
(EJB)
Secure Secure
Secure Non- Non- Non-
Declarative: Declarative: Realms
Programmatic: Secure Secure Secure
Reverse Proxy (i.e. WebSeal) Programmatic: In-house or
Policy Server Permissions
Programmatic: Session Control Policy Server Permissions
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.
Note: The ITSO working example chapters found in Part 2, “ITSO working
example secure portal solution” on page 141, implement the entry runtime
topology for a secure portal solution.
The entry runtime topology is the minimal setup to deploy a secure portal
solution for a production environment. It consists of at least three physical nodes
as follows:
The Reverse Proxy node, which provides the gateway to control access to the
back-end application in the production zone.
The Portal Server node, which contains the portal solution, including
database components, Web server components, and application server
components.
70 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The Policy Server node, which encompass directory components, policy
components, and database components.
Figure 3-9 on page 72 illustrates the entry runtime model in detail. The
deployment of the node is based on best practices and follows the
recommendations of 3.1.2, “Topology zones” on page 53:
The Reverse Proxy node is deployed within the controlled demilitarized zone.
The Portal Server node is deployed within the restricted production zone
accessible via the Reverse Proxy from the outside.
The Policy Server node is deployed within the secured management zone,
Protocol Firewall
Domain Firewall
Server + SP4
Internet
PERP
Access Manager/Directory Domain
SERP1
PMTAM
Management Zone
Legend:
Data related flows
Security related flows
72 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table 3-2 Node interaction matrix
From To Characteristics
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.
From an architectural point of view their are two approaches to build a secure
demilitarized zone using:
Reverse proxies
Plug-ins
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 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
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
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
Management Zone
Legend:
Data related flows
Security related flows
Figure 3-10 Physical model of the enterprise model using reverse proxies
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.
76 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
In a production zone the services will be split across a set of physical nodes such
that the portal-related tasks are handled by the Portal Server node, the back-end
systems are handled by dedicated physical nodes, and the directory read-only
replicas support the authentication requests as well as the advanced
configuration capabilities. In addition, the database node(s) provides
high-availability features and scalability features for the enterprise.
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
PMLDAP
Management Zone
Legend:
Data related flows
Security related flows
Figure 3-11 Physical model of the enterprise runtime based on security plug-ins
78 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3.2.3 Extended enterprise runtime topology
The extended enterprise topology provides a very solid security infrastructure by
combining Reverse Proxy and caching proxy capabilities as follows:
Strong secured demilitarized zone.
High-availability and scalability capabilities within the demilitarized zone.
Authentication and authorization requests are enforced.
Advanced caching capabilities for static and dynamic content while the
request already passed the authentication and authorization process.
For performance aspects, a set of Reverse Proxy nodes can be placed balanced
through the Load Balancer node. Each physical Reverse Proxy node caches
directory entries to improve performance while connected to directory replicas for
security reasons. In addition, they communicate via a secure channel with the
policy server to verify authorization and authentication requests. If access is
granted, then the request is passed to the corresponding Caching Proxy nodes.
The caching proxies have the capability to cache static and dynamic content.
The Reverse Proxy node is capable of dispatching the request across a set of
caching proxies.
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 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.
Domain Firewall
Load
Domain Firewall
Balancer PECP1 Directory Database PIDEV
Internet
PELB SECP1
SIDEVELOP
SELB PPLDAPR PPDB
PMTAM
PMLDAP
Management Zone
Legend:
Data related flows
Security related flows
80 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
From To Characteristics
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).
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.
Module A
Module B
Handover Handover Handover
Tuning Performs
Module C
Fix to be tested
Analysis Error
Passed to the developer
Module C
82 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
A set of topologies to provide a development/test environment
Teaming aspects when developing and deploying secure portal solutions
Development Repository
Node Node
Policy Server
Node
Development Repository
Node Node
SDWB SDREP
SDRP SDPORTAL
SDLDAP SDDB
Policy Server
Node
SDTAM
The naming conventions for the specified nodes are listed below:
S indicates that it is a node of the specified operational model.
D indicates that it belongs to the development zone within the internal
development zone.
84 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
An abbreviation for the service, for example TAM stands for Tivoli Access
Manager.
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.
SDTAM
PDTAM SDLDAP
SDDB
Legend :
• Tivoli Access Manager 5.1.0.2
Physical
(Policy and Authorization)
Virtual • Tivoli Directory Server 5.2
86 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3.3.4 Develop and deploy without debug
The develop and deploy without debug approach has the aim to provide:
A development environment including tools to develop portlets without a
complete test environment covering the security aspects
A test environment with a secure portal runtime environment
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.
88 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
It is capable of providing a development environment as follows:
An unique environment to develop portal assets
Full testing capabilities including security aspects
Team development by sharing a repository instance
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.
90 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 3-18 on page 89 illustrates the develop using a shared security
infrastructure approach. The specified Repository node is placed on a physical
node. The developer has its own specified development node installed. The test
environment is shared across all developers as follows:
The specified Reverse Proxy node is placed on a physical node.
The specified Policy Server node and specified Directory node are placed on
a physical node.
The specified Portal Server node is placed on a physical node to support the
deployment process for integration tests.
PDWB PDRP
92 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4
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.
94 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
concept of trust (that is, I have let you into my house and now you can do
whatever you like), creating an inherently less secure system.
Motivation: The drivers for this principle are increased security and
performance:
– Increased security through more checks of a user’s or transaction’s
authority to perform a function.
– Increased performance as decisions get made when a user requires
something, meaning that unnecessary decisions about a user’s potential
activity will not be made up front.
Implication: Requires good integration capability to enable a common security
service to permeate an environment. The majority of applications must be
able to use the security services.
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.
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.
96 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Cross-Domain SSO Client-Web App SSO Portal-Backend SSO
Web
Client Application
Back-end
Application
Client Portlet
Authentication WebSphere
Proxy Portal
Other Domain Portlet
Back-end
Authentication
Application
Proxy
Web
Application
Figure 4-2 illustrates the general request processing steps for WebSEAL
authentication and authorization when WebSEAL is configured to use
forms-based login and cookie based session IDs. Note that the diagram does not
include other processing that WebSEAL may perform, such as content filtering,
cookie handling, etc. These steps are common for both TAI- or LTPA-enabled
junctions. The internal details of the two highlighted steps differ between TAI and
LTPA junctions. They are illustrated in Figure 4-3 on page 102 and Figure 4-5 on
page 104, respectively.
Is URL
WebSEAL No accessible to No
session exists? unauthenticated
users?
This section describes the following single sign-on capabilities when integrating
WebSphere Portal and Tivoli Access Manager:
Credential Vault integration with GSO
98 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Trust Association Interceptor (TAI)
LTPA token support
Selecting a single sign-on solution
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.
100 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
com.ibm.websphere.security.WebSEAL.username property for TAI. The
dummy user ID encoded in the BA header is not used by the TAI request
validation.
In this case WebSEAL does not need an actual client user ID to build the
BA header, so unauthenticated user access is possible over this type of
junction.
Figure 4-3 illustrates the WebSEAL request building and WebSphere Application
Server request processing steps in more detail for TAI-based single sign-on
using a junction created with the -b supply option.
Yes
No
-c junction option
specified?
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
Figure 4-3 WebSEAL request processing for TAI junction with -b supply option
102 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
LTPA token support
The WebSphere Application Server can be configured to use a Lightweight Third
Party Authentication (LTPA) token (that is, cookie) to provide single sign-on
across multiple servers. After the user has been authenticated by WebSphere,
an LTPA cookie is created and sent to the browser. The browser will return this
cookie on subsequent requests, enabling the origin WebSphere Application
Server (or other WebSphere Application Server within the same TCP domain) to
recognize the user. The LTPA cookie is protected by a 3DES key, which also
proves that it was created by a trusted source.
The Tivoli Access Manager WebSEAL can generate an LTPA token that will be
accepted by the WebSphere Application Server. WebSphere Application Server
trusts this LTPA token because it is encrypted with the correct shared key.
Figure 4-4 shows a WebSEAL junction that is configured to use LTPA. An LTPA
key is generated on the WebSphere machine and then exported to a keyfile
(protected by a password). This keyfile must then be manually copied to the
WebSEAL machine. When the junction to the WebSphere server is configured, it
is specified as an LTPA junction, and the keyfile and password are given as
parameters.
Key
3 File
Bind
Directory 5
Username=?
Password=?
Figure 4-5 illustrates the WebSEAL request building and WebSphere Application
Server request processing steps in more detail for LTPA-based single sign-on.
Yes
Send request to
WebSphere Application Use the extracted value
Server WebSphere
as authenticated user id
authorization assumes
for WebSphere
unauthenticated user
authorization
104 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
If you assume that Tivoli Access Manager and WebSphere Portal (WebSphere
Application Server) share a common user registry, then GSO would be the last
choice for SSO. Instead, using either the Trust Association Interceptor (TAI) or
the LTPA support would be the preferred solution. GSO is the only option for the
following scenarios:
When WebSEAL and WebSphere rely on different user registries, you may
need to supply a different user ID and password combination for the user to
WebSphere that is meaningful to the WebSphere user registry.
There might be situations, even in the case of a shared user registry, where
-b GSO might be useful. For example, if internal users should be able to
connect to WebSphere directly using basic authentication and then have
indirect access through WebSEAL with WebSEAL being configured to
provide forms-based logon.
An integrated identity management solution can help get users, systems, and
applications online and productive fast, and maintain dynamic compliance to
increase the resiliency and security of the IT environment, while helping to
reduce costs and maximize return on investment. An identity management
solution has four key areas:
Identity lifecycle management (user self-care, enrollment, and provisioning)
Identity control (access and privacy control, single sign-on, and auditing)
Identity federation (sharing user authentication and attribute information
among trusted Web services applications)
Identity foundation (directory, directory integration, and workflow)
106 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4.1.5 Adding an external Web server for WebSphere Portal
In a production environment of a secure portal solution we have the following
approaches to process HTTP-requests:
Using a standalone Web server, which routes HTTP-requests via a plug-in to
the portal server
Using the embedded Web server of the application server
From a security point of view both approaches are feasible with different planning
and installation steps.
When using the standalone Web server, all application servers handled by the
application server plug-in are accessible through the same hostname and port of
the Web server. This allows us to have a single WebSEAL junction for accessing
applications running on separate application servers, such as server1 and
WebSphere_Portal.
When using this approach, each application server runs on a different port. As a
result, separate WebSEAL junctions are required for accessing each application
server.
There are several options that define the junction scheme for WebSphere Portal.
Number of junctions
– A single junction for all WebSphere Portal access
– Separate junctions for unauthenticated and authenticated user access to
WebSphere Portal
Encryption for WebSEAL to WebSphere Portal communications
– Non-encrypted junction
– SSL encrypted junction with server-side certificate
– SSL encrypted junction with client and server certificates (mutual SSL)
Cookie handling
– Junction created with -j option
– Junction created without -j option
There are several questions that need to be prioritized and answered before
choosing a suitable junction scheme:
Will the system allow unauthenticated access to some portal resources?
Will the communication between client and WebSEAL be SSL encrypted?
Will there be some resources accessible over non-encrypted connection, and
some accessible over SSL, thus requiring switching between HTTP and
HTTPS protocols?
108 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Does your planned URL scheme require the same base URL for both
unauthenticated and authenticated access, or does it specify separate base
URLs?
What are the security requirements for the connection between Remote
Proxy node and Portal Server node?
What are the performance requirements for the connection between Remote
Proxy node and Portal Server node?
Typically the most important decision will be the number of junctions, since it is
the only one that directly affects the user experience. This decision also has the
biggest technical impact.
The other option, a single junction, solves the problem with JMT. However, it
imposes another limitation. If both authenticated and unauthenticated access
need to be provided over the same junction, it must use an SSL connection to
the Portal Server node. This limitation does not apply if only authenticated
access needs to be provided. For more details on this issue see 4.2.2, “Junction
considerations for use with TAI” on page 109.
Note: For details on creating a custom TAI plug-in, refer to the IBM
WebSphere V5.0 Security, WebSphere Handbook Series, SG24-6573,
redbook.
110 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table 4-1 Naming convention for cookie examples
Description Value
The cookie handling examples use the following naming convention (Table 4-1).
If the junction is created without specifying the -j option, WebSEAL will send
the back-end cookie to the client browser without modifying its name. It will
update the cookie path to reflect the junction from which it was set. The
following example illustrates cookie filtering for the /portal junction created
without the -j option (Table 4-2).
Note that the filtered cookie path is now set to /portal/wps and therefore the
browser will only send the JSESSIONID cookie with requests for URLs
beginning with /portal/wps.
If the junction is created with specifying the -j option, WebSEAL will rename
the cookie before sending it to the client browser. The new cookie name
includes junction identification and is generated in the following form:
AMWEBJCT!<junction_name>!<original_cookie_name>
The following example illustrates cookie filtering for the /portal junction
created with the -j option (Table 4-3).
There are several limitations for using the Junction Mapping Table:
JMT will not work properly with junctions created without the -j option.
When WebSphere Portal sets the JSESSIONID cookie, WebSEAL will filter it
as illustrated in Table 4-2 on page 111. The cookie path is set to /portal/wps. If
the user tries to access a URL beginning with /wps, the browser will not send
the JSESSIONID cookie with this request. Even though the link can be
accessed, the user session will be lost.
JMT will not work properly if separate junctions are used for authenticated
and unauthenticated access to WebSphere Portal because JMT can only
map /wps URL to a single junction.
Suppose that there are two junctions created, for example /portal for
unauthenticated access and /sportal for authenticated access, and /wps is
mapped to /sportal. If an unauthenticated user accesses a /wps URL,
WebSEAL will map it to the protected junction and access will be denied.
If /wps is mapped to the unsecure /portal junction, and an authenticated user
attempts to access a portal resource, WebSEAL will allow the request
through, but WebSphere Portal may not allow access to protected resources
over an unsecure channel, and the request will fail.
112 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Request Deny Deny Deny
No No
Note: Both settings produce the same behavior - the user is requested by
WebSEAL to reauthenticate. All further references in this book to WebSEAL
session timeouts will not distinguish between session inactivity timeout and
maximum session lifetime timeout because the consequent system
interactions are the same.
114 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
timeout is defined by WebSphere_Portal application server session manager
settings in the WebSphere Application Server. By default, the session timeout is
set to 30 minutes.
The test use cases in “UCT5: WebSEAL session times out before portal session”
on page 121 through “UCT8: WebSphere Portal logout after WebSEAL session
timeout” on page 131 illustrate several common scenarios that can occur
because of WebSEAL and WebSphere Portal session issues. The behavior seen
in UCT6 through UCT8 would typically be perceived by the user as defective,
even though each component works exactly as designed.
There are two approaches that can be used to remedy the problem illustrated in
UCT6 and UCT7.
One possible approach is to reconfigure WebSphere Portal to persist the user
sessions when they time out, instead of invalidating them. In standalone
portal setup such behavior could lead to possible user session-based security
exploits. However, when used together with Tivoli Access Manager, the user
sessions are authenticated and validated by WebSEAL. Since WebSphere
Portal in this setup trusts WebSEAL and does not perform its own user
validation, the WebSphere Portal sessions can be persisted when expiring
without compromising security. This is the approach we will use in our
example environment.
Enabling automatic persistence for expiring WebSphere Portal sessions has
another side effect—the sessions effectively are preserved in the database
forever. This can be a problem for high-volume sites, and sites that create
WebSphere Portal sessions for unauthenticated users. The unauthenticated
user sessions will be persisted at session expiration, but, being anonymous,
they will never be accessed again. In this case it is necessary to perform
regular cleanup of stale sessions from the database.
Another approach is to set the session timeout in the WebSphere Application
Server session manager settings to No timeout.
The benefit of this approach is that the WebSphere Portal session database
will not get polluted with persisted expired sessions. The drawback is that
WebSphere Application Server will keep the sessions in memory indefinitely,
resulting in continuously decreasing performance and eventual depletion of
the JVM memory heap, thus requiring regular restarting of the
WebSphere_Portal application server.
Use cases UCT1 through UCT4 illustrate basic client access patterns. Use cases
UCT5–UCT8 illustrate several specific situations where each component
performs as designed, but the overall system response is not as expected.
Section 7.8, “Additional configuration” on page 356 provides some suggestions
for work arounds for these issues.
The use cases use the naming convention listed in Table 4-4.
Precondition None.
Actors Customer.
116 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Browser WebSEAL Portal
HTTP 200 OK (default unprotected page) HTTP 200 OK (default unprotected page)
Use Case ID: UCT2 UCT2: Access protected portal page, valid credentials
Actors Customer.
POST /pkmslogin.form
Set PD-S-SESSION-ID
HTTP 302 MOVED to /portal/wps/myportal cookie. Path: /
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
Figure 4-8 Sequence diagram - UCT2: Access protected portal page, valid credentials
118 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4.3.3 UCT3: Access protected portal page with existing valid session
This section includes a use case and sequence diagram for access to a
protected portal page with an existing valid session.
Table 4-7 UCT3: Access protected portal page with existing valid session
Use Case ID: UCT3 UCT3: Access protected portal page with existing
valid session
Description This use case is used to access a protected portal page with
an existing valid session.
Actors Customer.
Figure 4-9 Sequence diagram - UCT3: Access protected portal page with existing valid
session
Use Case ID: UCT4 UCT4: Access protected portal page, valid credentials
Precondition None.
Actors Customer.
POST /pkmslogin.form
Figure 4-10 Sequence diagram - UCT4 Access protected portal page, invalid credentials
120 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The steps are:
1. User tries to access customized page at:
https://<webseal_fully_qualified_hostname>/portal/wps/myportal
The browser does not send a PD-S-SESSION-ID cookie in the request or
sends a cookie identifying an expired WebSEAL session.
2. WebSEAL performs URL authorization and determines that the requested
resource is accessible only to authenticated users.
3. WebSEAL sends a login form (login.html) to the user.
4. The user enters an invalid username and password combination and submits
the login form (POST /pkmslogin.form).
5. WebSEAL verifies that the user credentials are invalid and sends the HTTP
403 Access Denied response to the user.
Table 4-9 UCT5: WebSEAL session times out before WebSphere Portal session
Use Case ID: UCT5 UCT5: WebSEAL session times out before WebSphere
Portal session
Actors Customer.
122 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Browser WebSEAL Portal
GET /portal/wps/myportal
Set PD-S-SESSION-ID
HTTP 200 OK (login.html) cookie. Path: /
POST /pkmslogin.form
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
POST /pkmslogin.form
Set PD-S-SESSION-ID
cookie. Path: /
HTTP 302 MOVED to /portal/wps/myportal
JSESSIONID
Send JSESSIONID cookie
session is still valid
GET /portal/wps/myportal GET /wps/myportal
Figure 4-11 Sequence diagram - UCT5: WebSEAL session times out before WebSphere Portal session
124 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table 4-10 UCT6: WebSphere Portal session times out before WebSEAL session
Use Case ID: UCT6 UCT6: WebSphere Portal session times out before
WebSEAL session
Actors Customer.
GET /portal/wps/myportal
Set PD-S-SESSION-ID
HTTP 200 OK (login.html) cookie. Path: /
POST /pkmslogin.form
Set PD-S-SESSION-ID
HTTP 302 MOVED to /portal/wps/myportal cookie. Path: /
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
Wait more than 3 minutes for WebSphere Portal session inactivity timeout
Send PD-S-SESSION-ID and
PD-S-SESSION-ID session is still valid
AMWEB!%2Fportal!JSESSIONID cookies
JSESSIONID
Send JSESSIONID cookie session has expired
GET /portal/wps/myportal GET /wps/myportal
Set JSESSIONID
HTTP 302 MOVED to HTTP 302 MOVED to
cookie. Path:/wps
/wps/portal/!ut/p/.scr/ErrorSessionTimeout /wps/portal/!ut/p/.scr/ErrorSessionTimeout
GET GET
/wps/portal/!ut/p/.scr/ErrorSessionTimeout /wps/portal/!ut/p/.scr/ErrorSessionTimeout
HTTP 200 OK (session timeout
HTTP 200 OK (session timeout message) message)
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
Figure 4-12 UCT6: WebSphere Portal session times out before WebSEAL session
126 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2. The user waits more than 3, but less than 30, minutes. The WebSphere
Portal session expires, while WebSEAL session is still valid.
3. The user tries to access the customized page at:
https://<webseal_fully_qualified_hostname>/portal/wps/myportal
The browser sends the PD-S-SESSION-ID and
AMWEB!%2Fportal!JSESSIONID cookies in the request.
4. WebSEAL determines that the user session identified by the
PD-S-SESSION-ID cookie is still valid and forwards the request to
WebSphere Portal. WebSEAL examines the
AMWEB!%2Fportal!JSESSIONID cookie, and reconstructs and inserts the
original JSESSIONID cookie in the HTTP request header.
5. WebSphere Portal determines that the session identified by the JSESSIONID
cookie has expired and displays an error message: Your portal session has
timed out because of no activity. Please start a new session at your
portal Home.
6. The user clicks the Log in link on the error page.
7. Since the PD-S-SESSION-ID session is valid, WebSEAL does not ask for
authentication, and forwards the request to WebSphere Portal.
8. WebSphere Portal generates a new User session object, renders the home
page for the logged-in user, and sets the JSESSIONID cookie in the response
headers.
9. WebSEAL performs response URL and cookie filtering and sends the
response to the user.
4.3.7 UCT7: Both WebSEAL and WebSphere Portal sessions time out
This use case illustrates a situation where both WebSphere Portal and
WebSEAL sessions have timed out. When trying to access a portal page after
session timeout, the user receives a login prompt. After entering username and
password and submitting the form, the user receives an error message
instructing him to establish a new session. After clicking the Login button, the
system does not ask for a username and password, and displays the
personalized portal home page. Each component works as designed, but the
overall system behavior is not as desired.
Use Case ID: UCT7 UCT7: Both WebSEAL and WebSphere Portal sessions
time out
Actors Customer.
128 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Browser WebSEAL Portal
GET /portal/wps/myportal
Set PD-S-SESSION-ID
cookie. Path: /
HTTP 200 OK (login.html)
POST /pkmslogin.form
Set PD-S-SESSION-ID
cookie. Path: /
HTTP 302 MOVED to /portal/wps/myportal
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
Wait more than 3 minutes for both WebSEAL and WebSphere Portal session inactivity timeout
POST /pkmslogin.form
Set PD-S-SESSION-ID
cookie. Path: /
HTTP 302 MOVED to /portal/wps/myportal
HTTP 200 OK (session timeout message) HTTP 200 OK (session timeout message)
Set AMWEB!%2Fportal!JSESSIONID
cookie. Path:/
Figure 4-13 UCT7: Both WebSEAL and WebSphere Portal sessions time out
130 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
13.WebSphere Portal generates a new User session object, renders the home
page for the logged-in user, and sets the JSESSIONID cookie in the response
headers.
14.WebSEAL performs response URL and cookie filtering and sends the
response to the user.
Table 4-12 UCT8: WebSphere Portal logout after WebSEAL session timeout
Use Case ID: UCT8 UCT8: WebSphere Portal logout after WebSEAL
session timeout
Actors Customer.
Main Scenario 1. Actor clicks the Log out link on the protected portal
page.
2. System displays the login page.
3. Actor provides valid username and password and
submits the page.
4. System performs logout and displays the home page for
unauthenticated portal users.
GET /portal/wps/myportal/!ut/p/.cmd/lo
PD-S-SESSION-ID
session has expired
HTTP 200 OK (login.html)
GET /pkmslogout?filename=wpslogout.html
HTTP 200 OK (default unprotected page) HTTP 200 OK (default unprotected page)
Figure 4-14 Sequence diagram - UCT8: WebSphere Portal logout after WebSEAL session timeout
132 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4. WebSEAL sends the login form (login.html) to the user. WebSEAL creates a
new user session by setting the PD-S-SESSION-ID cookie in the response
headers.
5. The user enters a valid username and password and submits the login form
(POST /pkmslogin.form).
6. WebSEAL verifies the user credentials and sends the HTTP 302 Moved
Temporarily response to the user’s browser, setting the original page URI
(/portal/wps/myportal/!ut/p/.cmd/lo) in the Location header field. It will cause
the browser to immediately redirect to the specified URI. WebSEAL creates a
new user session by setting the PD-S-SESSION-ID cookie in the response
headers.
7. The browser automatically makes a request to:
https://<webseal_full_hostname>/portal/wps/myportal/!ut/p/.cmd/lo
Sending the PD-S-SESSION-ID and AMWEB!%2Fportal!JSESSIONID
cookies in the request.
8. WebSEAL determines that the user session identified by the
PD-S-SESSION-ID cookie is still valid and forwards the request to
WebSphere Portal. WebSEAL examines the
AMWEB!%2Fportal!JSESSIONID cookie, and reconstructs and inserts the
original JSESSIONID cookie in the HTTP request header.
9. The WebSphere Portal logout command invalidates the WebSphere Portal
session and sends a redirect to the WebSEAL logout URL
(/pkmslogout?filename=wpslogout.html).
10.WebSEAL invalidates the user session and displays the wpslogout.html
page.
11.The wpslogout.html page contains an HTML REFRESH meta-tag pointing to
the default unprotected portal page at:
http://<webseal_full_hostname>/portal/wps/portal
12.The browser automatically makes a request to the unprotected page.
13.The system displays the home page for unauthenticated users.
Figure 4-15 on page 135 depicts the runtime environment before security
hardening. Chapter 11, “Security hardening” on page 471 provides guidelines
134 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Client data Reverse Proxy node
wsadmin
Security
WebSphere Portal node startServer
infrastructure xmlaccess
stopServer
33
Administrative Policy Server node serverStatus
communications IHS Admin WAS Admin ...
HTTP
31 32 34 35 36
HTTP
HTTP
SOAP/HTTPS
SOAP/HTTPS
SOAP/HTTPS
:9443 server1 :8880
:8008
Admin Console
IHS Admin
Server :8881
WebSphere_Portal
:80 :80
:50000
WAS 22 DB2 PORTAL
/portal 3 HTTPS IHS :50001
1 HTTP :80 plugin 4 HTTP Portal core DB
junction :443 :9081 23 LDAP
HTTPS :443
2 24 IIOP ITSO Bank
:7234
WebSEAL ITSO Bank portlets 25 DB
User, IIOP
5 6
Portal Admin :50000
:8882
ITSOBankServer :50001
LD
:2810
AP
Policy Server/SSL
30
WebSphere Security
7 HTTP :8008 IHS Admin wsadmin
Server
startServer Access Manager Java
Runtime Environment
LDAP
:80 WAS stopServer
IHS Admin IHS 29 28
plugin serverStatus
Authorization aznAPI/SSL
...
Policy Server/SSL
10
HTTP
11
SOAP/HTTP
:9080
15 :389
TAM Administration/SSL
LDA
AP
P
LD
:7135 17 20
:7135
18 TAM Administration/SSL :7136
Authorization
Policy Server :7137
Server
16
Policy Server/SSL 19
:7135
:7135
136 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
– Usage: Tivoli Directory Server administration, Tivoli Access
Manager administration, WebSphere Application Server
administration
9. Connection from Tivoli Directory Server and Tivoli Access Manager
administrator browser to the HTTP transport port for server1 application
server on Policy Server node.
– Protocol: HTTP
– Port: 9080
– Usage: Tivoli Directory Server administration, Tivoli Access
Manager administration, WebSphere Application Server
administration
10.Connection from IBM HTTP Server to server1 application server HTTP
transport on the Policy Server node.
– Protocol: HTTP
– Port: 9080
– Usage: Tivoli Directory Server administration, Tivoli Access
Manager administration, WebSphere Application Server
administration
11.Connection from WebSphere Application Server administration utilities (for
example wsadmin, startServer, stopServer, serverStatus) to server1
application server SOAP JMX connector on the Policy Server node.
– Protocol: SOAP over HTTP
– Port: 8880
– Usage: server1 application server administration
12.Connection from Tivoli Directory Server Web Administration Tool
(IDSWebApp) application to Tivoli Directory Server directory administration
daemon.
– Protocol: Tivoli Directory Server internal communications (non-SSL)
– Port: 3538
– Usage: Tivoli Directory Server administration commands
13.Connection from Tivoli Directory Server Web Administration Tool
(IDSWebApp) application to LDAP registry (Tivoli Directory Server).
– Protocol: LDAP
– Port: 389
– Usage: LDAP queries and updates
14.Connection from Tivoli Access Manager Web Portal Manager (TAMWPM)
application to LDAP registry (Tivoli Directory Server).
– Protocol: LDAP
– Port: 389
– Usage: LDAP queries
138 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
23.Connection from WebSphere Portal application to LDAP registry (Tivoli
Directory Server).
– Protocol: LDAP
– Port: 389
– Usage: LDAP queries
24.Connection from ITSOBank portlet application to ITSOBank back-end
application.
– Protocol: RMI/IIOP
– Port: Dynamically assigned by WebSphere Application Server
– Usage: Remote EJB calls
25.Connection from ITSOBank portlet application to ITSOBankServer
application server JNDI service.
– Protocol: IIOP
– Port: 2910
– Usage: JNDI lookups
26.Connection from ITSOBank back-end application to DB2 database
(ITSOBANK).
– Protocol: DB2 client
– Port: 50000,50001
– Usage: DB2 queries and updates
27.Connection from ITSO Bank application to LDAP registry (Tivoli Directory
Server).
– Protocol: LDAP
– Port: 389
– Usage: LDAP queries
28.Secure connection from WebSphere Application Server to Tivoli Access
Manager Policy Server.
– Protocol: Tivoli Access Manager internal communications over SSL
– Port: 7135
– Usage: Tivoli Access Manager internal communications
29.Secure connection from WebSphere Application Server to Tivoli Access
Manager Authorization Server.
– Protocol: Tivoli Access Manager internal communications over SSL
– Port: 7136
– Usage: Authorization requests
30.Connection from WebSphere Application Server security services to LDAP
registry (Tivoli Directory Server).
– Protocol: LDAP
140 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Part 2
The business scenario used in this chapter is that of the fictitious ITSO Bank.
The ITSO Bank would like to implement a secure portal banking portal
application to extend the hours of operation to its customers. This scenario will
be used to illustrate the major phases of solution development for a secure portal
application and will thus be referred to in the remaining chapters.
The ITSO Bank wants to extend access to their customers and to do so must
deploy the current application within a proven security infrastructure.
The banking portal provides a basic user interface that allows access to this
functionality depending on the user’s role of bank manager or customer. As a
bank manager, the user is authorized to access all features described above.
The customer role has a limited subset of functionality and is only authorized to
access the account balance query and funds transfer functions. This
authorization is currently determined by the user’s role assignment within the
WebSphere Portal Server.
144 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Outside Zone DMZ Production Zone Internal Network
Intranet
Protocol Firewall
Domain Firewall
Domain Firewall
I
N
T
E
Browser R
User N
E
T
Database Development
Domain Domain
Domain
Name Server
146 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
ITSO Bank manager requirements
The following functional requirements of the ITSO Bank manager have been
identified:
Minimize staff training time for the application.
View a history log of the customer’s transactions.
Provide a single authentication and authorization security infrastructure for all
current and future banking applications.
Delete unused customer accounts from the system.
Access the customer’s account balance data quickly.
Create new customer accounts.
Modify customer information, for example, change their address.
They also feed into the design of technical and application components.
Non-functional requirements therefore provide a basis for early system sizing
and cost estimates. Together with the functional requirements, the non-functional
requirements define the baseline against which the business system must be
designed.
This section also includes the following constraints that the system must conform
to or satisfy:
Performance
Scalability
Availability
Maintainability
Security
Performance
The performance requirements of a system are actually defined by a set of four
sub-requirements:
Response time requirements
Throughput requirements (dynamic volumetric requirements)
Utilization requirements
Static volumetric requirements
148 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Response time requirements
Response time specifies the time within which the system must complete specific
processes, for example, the time within which the system must process a funds
transfer. It is important to focus on the requirements of the business when setting
response time targets rather than becoming seduced by the vision of sub-second
IT transaction response. The real driver for the business is its ability to perform a
business process in a time that will be acceptable to its customers. If this real
driver is overlooked, the cost of achieving the set response time may be greatly
inflated as oversized hardware may be purchased to achieve the result.
Table 5-1 on page 149 provides a set of generic response time bands required
for transactions of different levels of complexity within the ITSO Bank system.
Note: The use case details for the ITSO Bank can be found in 5.3, “Use case
model” on page 155.
UCF3 Add a new user to the application Medium 100 registrations per
registry: Customer details. amount of data day
20000 customer
accounts active
Utilization requirements
This sub-requirement specifies the maximum acceptable load placed on the
nodes of the business system when running the intended workload of the
system. The performance architect must size the system such that the overall
utilization of the key system components is within the bounds of acceptable
behavior when supporting this workload. The ITSO Bank has set the utilization
requirement such that all platform configurations for the solution should result in
a utilization of less of less than 70 percent. For example, the maximum
bandwidth usage must be no more than 70 percent of the actual bandwidth
available to the system.
150 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Static volumetric requirements
This sub-requirement specifies the volume of data entities that exist within the
target system that, although relatively static, are likely to have a significant effect
on the overall sizing of the target system. Examples include the following:
The number of business system users by type
The number of different user locations
The ITSO Bank has identified the following static volumetric data:
Current customer base is approximately 20000 users
Current number of portal administrators is three
Current number of security administrators is two
Each user has on average two accounts with the bank
95 percent of users are located in ITSO Bank’s home country
Scalability
Scalability can be defined as the ability to increase the number of users or
capabilities of a solution without making significant changes to the solution’s
systems or software. Together with performance requirements,
scalability-related requirements provide the baseline against which subsequent
performance engineering activities are scoped and executed.
It has been identified that ITSO Bank currently has a high level of customer
growth of 35 percent and ITSO Bank management expects that this level of
growth will be maintained over the next two years. ITSO Bank management
identified a business challenge in 5.1.2, “Business challenges” on page 145, that
the application should be able to handle this huge increase in customers.
Scalability is therefore a very important requirement of the solution.
Availability
Availability is simply the ability of a solution to perform its required function over a
stated period of time. Availability is usually expressed as a ratio of the time the
service is actually available for use of the stated service hours. In this section we
identify the expected availability for various functionality, fallback plans, recovery
requirements, and the number of acceptable outages per time period.
Availability requirements for the ITSO Bank application vary by use case; each
row of the following table represents a collection of use cases with common
availability requirements. For use case details please refer to Table 5-5 on
page 157.
Maintainability
Maintainability can be defined as ease of which a system can be restored to its
functional state when maintenance is performed on the system. ITSO Bank
identified in their business challenges that they require a solution where
maintenance of the security component of the system must have a reasonable
and predictable cost. They also identified a requirement of a common audit trail
for all applications to increase the ease of maintaining audit data. Maintainability
of the security component of the solution is therefore an important requirement
for ITSO Bank.
Security
The requirements of a security system can be categorized into five sub-systems:
Audit
Access control (authorization)
Flow control
Identity and credentials (authentication)
Solution integrity
152 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
ITSO Bank has identified that in order to make the banking application available
to the customer, a comprehensive and robust security architecture must be
implemented. The chosen security architecture must therefore address all of the
five security sub-systems listed above. ITSO Bank needs to be able to assure
their customers that their accounts and personal details are protected from
attack and that the application data has integrity. As noted in ITSO Bank’s
business requirements, the bank also requires that the implemented security
solution provides a consistent level of security organization-wide and provides an
API to reduce application development time.
To address all the security requirements, ITSO Bank has decided to use IBM
Tivoli Access Manager for e-business V5.1 for their security architecture and the
associated APIs. The Tivoli Access Manager infrastructure will be used for
authentication, single sign-on, and authorization to resources.
System constraints
System constraints are business and technical constraints that impact the design
of the system, for example, geographical location constraints or existing
hardware or software that must be used. Since the ITSO Bank has already
written and internally deployed the application that will be modified to produce
the secure banking application, a number of system constraints have been
imposed. Table 5-4 lists the known system constraints for the ITSO Bank
production environment and the associated prerequisites, including mandatory
standards for the component structure.
SC02 Database
– DB2 Universal Database V8.1, Enterprise Server Edition
SC07 Network
– TCP/IP and Ethernet
154 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
5.3 Use case model
This section presents the use case model, which has been derived from analysis
of the identified business requirements. The use case model helps to break down
the requirements and shows how the users with specific roles will interact with
the system to achieve their goals. Textual descriptions provide further detail for
each use case.
Actors defined
The actors are people or systems outside of the ITSO Bank application that
interact with the system. This section identifies primary and secondary actors,
where a primary actor is one who uses the system’s main functionality, and a
secondary actor is one who performs administration or maintenance tasks on the
system. Figure 5-2 on page 155 depicts the actors of the ITSO Bank application.
Actors
Primary Secondary
Actors Actors
Primary actors
The primary actors in our business scenario are as follows:
Customer
Customer service representative
Note: For the ITSO working example, we did not implement the Customer
Service Representative role.
Secondary actors
The secondary actors in our business scenario are as follows:
Security Administrator
Portal Administrator
Transfer Login to
Portal
Funds
Domain
Banking Logout of
Application Portal
Login Domain
Banking
Add
Application
Portlet
Customer Logout
View
Account Edit
Balance Portlet Portal
Administrator
Delete
Portal
Configure
Portal
Settings
Add
User
Modify
User
Information
View
Configure Contract
Security History
Settings
Delete Bank
Security User
Administrator Manager
156 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Summary of use cases
This section expands on the use case diagram by providing a brief description of
each use case including the name of the use case, the goals of the use case,
and the actors involved.
The primary actor, or front-end, use cases can be found in Table 5-5 and the
secondary actor, or administrative, use cases can be found in Table 5-6 on
page 157.
Description This use case is used by all front-end accessing actors to log
in to the ITSO Bank application.
158 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Use Case ID: Name UCF1: Application login
Description This use case is used by all front-end accessing actors to log
out of the ITSO Bank application.
Alternatives Actor closes browser and session is lost, thus logging the
user off.
Description This is the use case used to add a new customer record to
the banking application.
160 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Use Case ID: Name UCF4: Modify user information
162 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table 5-14 UCF8: Transfer funds
Alternatives None.
Description This is a primary task to add a portlet to the ITSO Bank portal.
It covers the tasks to add an ITSO Bank portlet to a page.
Alternatives None.
Description This is a primary task to delete a portlet from the ITSO Bank
portal. It covers the tasks to delete a portlet from a page.
Precondition None.
Alternatives None.
164 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Use Case ID: Name UCA2: Delete portlet
Description This use case is used for logging out of the WebSphere
Portal administration interface.
Alternatives Actor closes browser and session is lost, thus logging the
user off.
5.4 Architecture
This section presents a high-level architecture diagram of the proposed security
system for the ITSO Bank application. Analysis of the requirements and the use
case diagrams have provided us with the information we need to formulate a
security architecture that will meet the requirements of all the stakeholders of the
ITSO Bank application.
166 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
This section provides a brief architectural overview before detailing the key
concepts of the this high-level architecture, identifying architectural decisions
and introducing the selected runtime and development environments.
Portal
Portal Database
Reverse
Browser Proxy
I Management Zone
N
T
E
R Enterprise Directory
N
E Directory Database
T
Policy Master
Server Authorization
DB
Note: For further details about architecture models and high availability and
scalability options please see Chapter 3, “Architecture and topology selection”
on page 51. This high-level diagram maps to the selected runtime
environment discussed in Chapter 6, “Install the runtime environment” on
page 175.
168 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
content lies. WebSEAL communicates with the Enterprise Directory Server
and the Policy Server for authentication and authorization decisions.
For the ITSO Bank working example, we have identified the following
architectural decisions:
AD01: Product to use for the security architecture
AD02: Authorization code to be used within application
AD03: Where user data is to be stored
AD04: Data component placement
AD05: The protocol for user communication with the WebSEAL Reverse
Proxy server
AD06: The protocol to be used for communication between WebSEAL and
the portal server
AD07: Protocol to be used for communication with the directory server
Architectural Decision Which product should be used for the system’s security
architecture.
Assumptions None.
170 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Architectural Decision AD02
ID
Architectural Decision Where the user data for the banking application is to be
stored.
Architectural Decision Where the main data components of the system are to be
located.
Problem Statement Mission-critical data assets are stored within the ITSO Bank
databases. A possible attack from the Internet could result
in database manipulations with unknown side effects.
Alternatives None.
Architectural Decision The protocol to be used for users to communicate with the
WebSEAL Reverse Proxy server.
Problem Statement The ITSO Bank application’s users must trust that their data
will be secure when accessing the ITSO Bank application.
Assumptions None.
Table 5-25 AD06: Protocol communication between WebSEAL and Portal server
Architectural decision AD06
ID
172 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Architectural decision AD06
ID
Problem Statement Using HTTPS for all communications with the portal server
can lead to slow performance, especially in the case of
accessing image data. If the components that are
communicating are in trusted zones, then HTTP may be
used to increase performance. However, the use of HTTP
prevents unauthenticated access when TAI is used to
establish a trust relationship between WebSEAL and
WebSphere Portal.
Assumptions None.
Table 5-26 AD07: Protocol for communication with the directory server
Architectural decision AD07
ID
Architectural Decision The protocol to be used for users to communicate with the
directory server.
Assumptions None.
174 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
6
The value add of the ITSO working example runtime implementation is three fold.
First, we provide detailed procedures for installing the software components by
node. Second, the procedures include sample values that put into context the
information found in the product guides. Third, the procedures include best
practices, tips and workarounds based on our first-hand experiences.
176 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Outside Zone Demilitarized Zone Production Zone
Protocol Firewall
N
Domain Firewall
wswin1 wpwin1
E
T
Domain Firewall
Policy Server
Node
tamwin1
Management Zone
Legend: Data related flows
Security related flows
Figure 6-1 ITSO working example: Secure Portal runtime environment on Windows
178 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Software Version
Note: Due to the vast number IBM WebSphere Portal Extend for
Multiplatforms V5.0.2 CDs and not so obvious naming of the CDs, we have
provided a listing of the CDs we used in our environment for reference
purposes (Table 6-4 on page 180).
Table 6-4 IBM WebSphere Portal Extend for Multiplatforms V5.0.2 CDs
CD WebSphere Portal component Version
1-6 WebSphere Application Server Fixpack and Fixes for Fixpack 1 (V5.0.1)
Windows and Linux
180 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
CD WebSphere Portal component Version
VMWare was used to capture the system state during the installation and
configuration of the nodes. VWMare images can be copied from various system
types since the device drivers are virtualized. The downside is that system
performance is not as good as on a native operating system.
Note: When installing and configuring the Policy Server node, we referenced
the following product guides and redbooks:
Installation and Configuration Guide, IBM Tivoli Directory Server V5.2,
SC32-1338
Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339
Base Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1362
Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360
A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager
V4.1, SG24-6077, redbook
Enterprise Security Architecture Using IBM Tivoli Security Solutions,
SG24-6014, redbook
The high-level tasks to install the Policy Server node are as follows:
1. Windows 2000 Server installation
182 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2. DB2 Universal Database installation
3. IBM GSKit upgrade installation
4. Java Runtime Environment (JRE) V1.3.1 installation
5. Tivoli Directory Server installation
6. Tivoli Directory Server configuration
7. Tivoli Web Administration Tool installation
8. Configure Directory Server for Tivoli Access Manager
9. Tivoli Access Manager installation
10.Tivoli Access Manager configuration
11.Tivoli Access Manager Web Portal Manager installation
12.Tivoli Access Manager V5.1 Base Fixpack 2 installation
Ensure that the fully qualified hostname is returned if resolved by a domain name
server. Alternatively, you may be using a host file for an environment such as
development (use ping instead of nslookup).
184 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: We found that IBM Tivoli Directory Server V5.2, IBM Tivoli Access
Manager for e-business V5.1, and IBM WebSphere Portal Extend for
Multiplatforms V5.0.2 all included different versions of IBM DB2 Universal
Database V8.1. When installing DB2 UDB it is important to understand the
licensing for the product it is included with. Information regarding the IBM
Software licensing can be found at:
http://www.ibm.com/software/sla/sladb.nsf/
There are many possibilities from which DB2 UDB can be installed:
Existing DB2 UDB V8.1, Enterprise Server Edition database server
New DB2 UDB licence for multi-user access
Use on of the various DB2 UDB V8.1 CDs included.
Note: Depending on the DB2 UDB V8.1 CD distribution you are using, the
installation panels may be slightly different than we have described.
Note: The DB2 UDB installation with the Typical installation type takes
approximately 376 MB of disk space.
11.When the Set User Information for DB2 Administration Server window
appears, enter the following and then click Next:
– Domain: We left this field blank.
– User name: db2admin (default)
– Password: <password>
– Confirm password: <password>
– Check Use the same username and password for remaining DB2
services (default).
12.When the Setup the Administration Contact List appears, we accepted the
default settings (local) and then clicked Next.
13.When the warning message Notification SMTP server has not been
specified appears, click OK.
14.When the Configure DB2 instances window appears, we accepted the default
(DB2) and then clicked Next.
15.When the Prepare the DB2 tools catalog window appears, select Do not
prepare the DB2 tools catalog on this computer and then click Next.
16.When the Specify a contact for health monitor notification window appears,
select Defer the task after installation is complete, and then click Next.
17.When the Start copying files window appears, review the selected options
and then click Install.
18.When the Setup is Complete window appears, click Finish.
19.When the IBM DB2 First Steps window appears, click Exit First Steps.
186 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: For more information regarding the contents of the IBM DB2 UDB V8.1
Fixpack 4a, refer the FixpackReadme.txt which can be found at:
http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8fphis
t.d2w/report#WIN-32
To download and install the IBM DB2 UDB V8.1 Fixpack 4a, do the following:
1. The IBM DB2 UDB V8.1 Fixpack 4a can be downloaded at:
http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/v8fphist.
d2w/report#WIN-32
2. We downloaded the FP4a_WR21338_ESE.exe, which is the fixpack 4a for
the IBM DB2 Universal Database V8.1, Enterprise Server Edition.
3. Stop all DB2 services in the Windows services.
Note: If you have trouble stopping any of the DB2 services, you can
proceed with the fixpack installation. When the DB2 Setup Wizard
launches for the fixpack, it will warn that certain processes are locking DB2
and will ask you if you want to shut them down. You can click Yes and the
Wizard will shut down the processes for you.
4. Install the IBM DB2 UDB V8.1 Fixpack 4a. We accepted the default
installation options.
5. We recommend that you restart your system after installing the fixpack to
ensure that all fixes are applied and active in memory.
6. The internal DB2 level is 8.1.4.428 after the installation of Fixpack 4a. In our
example, we do not have any existing databases that need special attention
(rebind DB2 utilities).
After the system has restarted, open a DB2 command window (or Windows
command window) and enter the following command:
db2level
It should return 8.1.4.428 after Fixpack 4a has been installed.
If you have created databases before you installed the fixpack 4a, you will
need to rebind the DB2 utilities to the databases. This step is necessary for
the fixes to become effective on existing databases. The binding procedure
needs to be performed only once per database. Note, this is not required for
any database created after the fixpack is installed. We have summarized the
rebind procedure found in the FixpackReadme.txt.
To rebind existing DB2 UDB databases after installing Fixpack 4a enter the
following commands from a DB2 command window for each database:
db2 terminate
db2 CONNECT TO <dbname>
db2 BIND <DB2_home>\BND\@db2ubind.lst GRANT PUBLIC
db2 BIND <DB2_home>\BND\@db2cli.lst GRANT PUBLIC
db2 terminate
There are two reasons that we need the new GSKit for the ITSO example
runtime environment. First, the GSKit V7.0.1.9 installed with the Tivoli Directory
Server V5.2 on the Policy Server node includes root certificates that have
expired. For this reason, users will not be able to create a new keystore using the
iKeyman utility. Second, the IBM GSKit V7.0.1.16 is a prerequisite for the Tivoli
188 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Access Manager V5.1 Base Fixpack 2, which we install in 6.2.12, “Tivoli Access
Manager V5.1 Base Fixpack 2 installation” on page 216. In addition, the IBM
GSKit V7.0.1.16 addresses a potential denial-of-service attack vulnerability.
In our example, the Policy Server node includes three products that include a
version of the IBM GSKit, as seen in Table 6-6. In our example, we only need to
upgrade the IBM GSKit V7.0.1.9 to V7.0.1.16.
Note: The ITSO procedure installs the IBM GSKit V7.0.1.16 to be used by the
Tivoli products.
Note: The GSKit version can be obtained by using the gsk7ver.exe command
or by retrieving the version from the Windows registry. We chose to use the
Windows registry method, since we also needed the REGAPPS value in
addition to the version.
If you have not installed Tivoli Directory Server or other software containing the
IBM GSKit, you can skip this section. To determine the level of the GSKit
installed, do the following:
1. Start the Windows registry editor (regedit.exe) by clicking Start → Run and
entering regedit in the Open field, and then clicking OK.
2. Select and expand HKEY_LOCAL_MACHINE → SOFTWARE → IBM.
3. In our example, you will see both the GSK5 and GSK7 registry entries.
Prior to installing the new IBM GSKit V7.0.1.16, if a GSKit already has been
installed, you must manually uninstall the existing IBM GSKit V7.0.1.9 as follows:
1. Ensure the IBM Tivoli Directory Server V5.2 Windows service has been
stopped, as well as other services that may be using the GSKit.
2. Open a command window and navigate to the c:\winnt directory.
3. Run the following command to uninstall the GSKit:
gsk7bui LDAP
Where LDAP is the name of the application using the GSKit recorded.
4. Verify that the GSK7 Windows registry has been removed.
5. Verify that the GSK7 directory has been removed (for example, C:\Program
Files\IBM\GSK7).
Note: If files still exist, such as DLLs, manually delete the C:\Program
Files\IBM\GSK7 directory after the services that locked the files have been
stopped.
Note: If you have previously installed applications that use the old GSKit
V7.0.1.9, they may have updated the system path to include the GSKit
installation path. If you decided to change the default GSKit installation path,
you may need to manually update the system path to include the correct
GSKit installation path.
For example, our procedure is now in an order that this problem will not be an
issue, but when we initially set up our environment we had already install the
Tivoli Access Manager Policy Server and Authorization Server. These
Windows services are started by the Access Manager Auto-Start Service,
which looks for the GSKit in the system path. If the GSKit path is not correct,
the services will not start. After updating the system path in the Windows
environment, you will need to restart your system.
190 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Install GSKit V7.0.1.16
To download and install the IBM GSKit V7.0.1.16, do the following:
1. The IBM GSKit V7.0.1.16 can be obtained by one of the following methods:
– Request the GSKit V7.0.1.16 from IBM support at:
http://techsupport.services.ibm.com/guides/tivoli_contacts.html
or
– Download the IBM HTTP Server V1.3.28, which includes IBM GSKit
V7.0.1.16, at:
http://www-1.ibm.com/support/docview.wss?rs=177&context=SSEQTJ&uid=swg24
006718
Note: From the URL listed, you will have to log in as a registered user (or
register first). Once you navigate to the download page by platforms you
will see a listing of many fixes.
2. Open a command window and navigate to the directory in which you have
unpacked the WINDOWSPQ86671IHS1.3.28.zip file.
3. Enter the following at the command line to extract the GSKit:
gsk7bas c:\temp
Where c:\temp is the directory to which to extract the GSKit installation files.
4. From the command window, navigate to the directory where you have
extracted the GSKit installation files (for example, c:\temp).
5. Run the GSKit installer as follows:
setup <application_name>
Where <application_name> is the name of the application using GSKit
V7.0.1.16. For example:
– Policy Server node application_name: LDAP
– Reverse Proxy node application name: policydirector
6. When the Welcome window appears, click Next.
7. When the Choose Destination Location window appears, we entered
c:\ibm\gsk7 for the destination folder from the Browse button. Click Next to
proceed.
8. When the setup is complete, click Finish.
192 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
6.2.5 Tivoli Directory Server installation
This section describes how to install the Tivoli Directory Server V5.2 on the
Policy Server node. WebSphere Portal V5.0.2 includes Tivoli Directory Server
V5.1, and Tivoli Access Manager V5.1 includes Tivoli Directory Server V5.2. We
chose to use Tivoli Directory Server V5.2 to verify the configuration with the
newer version and avoid GSKit issues with the older level.
The high-level steps to install and configure the Tivoli Directory Server are as
follows:
Create DB2 database owner
Install Tivoli Directory Server
10.When the Installation Summary page appears, review the selections and click
Next to begin installing files.
11.When the installation completes, review the readme files for the client and
server and click Next.
194 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
12.When prompted, select Yes, restart my computer and click Next. Click
Finish.
For the ITSO working example, we chose to install the Web Administration Tool
provided with Tivoli Access Manager V5.1 on WebSphere Application Server
V5.0.2, which will allow us to later configure WebSphere Application Server
security.
The high-level steps to install and configure the Web Administration Tool are as
follows:
WebSphere Application Server installation
Tivoli Directory Server Web Administration Tool installation
Web Administration Tool configuration
196 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
WebSphere Application Server installation
This section describes how to install WebSphere Application Server V5.0 and
Fixpack 2 (V5.0.2) on the Policy Server node as a prerequisite to the Tivoli
Access Manager V5.1 Web Administration Tool.
198 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
9. When the Node name and Host name window appears, we entered the
following and then clicked Next:
– Node name: tamwin1
– Host name or IP Address: tamwin1.itso.ral.ibm.com
10.When the Windows Services window appears, we entered the following and
then clicked Next:
– Deselect Run WebSphere Application Server as a service.
– Select Run IBM HTTP Server as a service.
– User ID: admin
– Password: <password>
11.When the Installation Summary window appears, review your selections and
then click Next to begin copying files.
12.When the Register window appears, take the appropriate action.
13.When the First Steps window appears, click Exit.
14.Click Finish on the Installation Wizard page.
Note: The Fixpack will attempt to update the IBM HTTP Server and will not
be able to update the server if it is started.
200 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. After completing the Verify Installation, click Exit from the First Steps page.
4. Ensure that the IBM HTTP Server (WebSphere plug-in) is started.
5. Ensure that the server1 application server is started. If not, start the server as
follows:
cd \ibm\WebSphere\AppServer\bin
startServer server1
202 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
– Uncheck DB2 V8.1.
– Uncheck GSKit.
10.When the Summary page appears, click Next to begin the installation.
11.When the Review Readme file appears, click Next.
12.When the installation is complete, you will be prompted to restart the system.
This is not necessary since we just installed the Web Administration Tool.
Select No, I will start my computer at a later time. Note, it is not necessary
in this case to restart, since the installer only copied the Web Administration
Tool war file (IDSWebApp.war). Click Next.
13.Click Finish.
Note: The file can either be on the client machine (the machine that
runs the Web browser) or on the server machine (the machine to which
the client is connected).
204 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
b. When the Change Console administrator logon appears, enter the
following and click OK.
• Console administrator login: webadmin
We created the administrator webadmin, but this could be any name
you desire.
• Current password: <password> (default is secret)
c. Select Change console administrator password. Enter the current and
new password. Click OK.
5. Add the Directory Server node.
a. Click Console administration → Manage console servers.
b. Click Add.
c. Enter the Directory Server hostname and change the port numbers if not
using defaults (for example, tamwin1.itso.ral.ibm.com), and click OK.
• Hostname: tamwin1.itso.ral.ibm.com
• Port: 389
• Administration port: 3538
• Uncheck SSL enabled (default).
We will examine SSL enabling the connection to adminstration tools in
Chapter 11, “Security hardening” on page 471.
You should see the new server listed after adding it.
d. Click Logout from the Web Administration Tool.
Note: If you are using IBM Tivoli Directory Server V4.1 or V5.1 refer to the
Base Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1362, for
additional steps for preparing the schema.
206 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Attention: The first time we configured the runtime environment, we later
discovered while troubleshooting that the suffix was not saved. On our
system, the display resolution was set to 1024x768. The OK button to save
the settings was not visible unless you scrolled down the page. We have
added this note to click OK to save to alert others of this pitfall.
5. Click Logout, and close the Tivoli Directory Server - Web Administration Tool.
When installing Tivoli Access Manager V5.1, you can set up the system using
one of the following installation methods:
Installation wizard
This method is very useful if you are not experienced with using Tivoli Access
Manager and want to quickly implement a base configuration.
Installation using native installation utilities by platform
We performed the installation using the native installation utilities. First, we
wanted to have greater control of how and where the components are
installed. Also, we wanted to have a better understanding of what was being
configured to build critical knowledge needed for debugging.
To install the IBM Tivoli Access Manager V5.1 Policy Server, do the following:
1. Ensure that the Tivoli Directory Server is started.
2. Ensure that the proper GSKit is installed.
The GSKit V7.0.1.9 included with the Tivoli Directory Server V5.2 contains
certificates that have expired. To address this issue we have downloaded and
installed a newer GSKit V7.1.0.16 in 6.2.3, “IBM GSKit upgrade installation”
on page 188.
3. Ensure that the Tivoli Directory Client SDK is installed.
In our example, the Tivoli Directory Client SDK was installed with the Tivoli
Directory Server V5.2.
4. Insert the Tivoli Access Manager Base for Windows NT®, Windows XP,
Windows 2000 and Windows 2003 CD.
5. Navigate to the <CD_Root>\windows\PolicyDirector\Disk Images\Disk1 folder
and run Setup.exe to start the installer.
On occasion, if you do not stop the WebSphere Application Server from the
command line by entering the following, you may not be able to start the
WebSphere Application Server after the restart:
c:/ibm/WebSphere/AppServer/bin/stopServer server1
208 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
1. Ensure that the Tivoli Directory Server is started.
2. Start the Access Manager Configuration by clicking Start → Programs →
IBM Tivoli Access Manager → Configuration.
Alternatively, open a command window and enter pdconfig, which is in the
environment after the system restart.
3. From the Access Manager Configuration, select Access Manager Runtime
and click Configure.
4. Select LDAP and click Next.
5. When the LDAP Server Information page appears, we entered the following
and then clicked Next:
– LDAP host name: tamwin1.itso.ral.ibm.com
– LDAP port number: 389
6. When the SSL with the registry server window appears, we selected No next
to enable SSL with the registry server and then clicked Next.
7. When the Logging Information page appears, we entered the following and
then clicked Next:
– Check Enable Tivoli Common Directory for logging.
– Log directory: c:\ibm\Tivoli\common
8. When the Configuration Summary page appears, review the settings and
click Finish.
The Access Manager Configuration tool should display configured status Yes for
Access Manager Runtime.
Figure 6-5 Tivoli Access Manager Policy Server configuration success message
We later discovered that the suffix for Tivoli Access Manager meta data
(secAuthority=Default) was not saved. We have included a note in the section
where the suffix is added to ensure that you scroll down the page and click OK
to save the suffix. After successfully adding the suffix, we reran the Policy
Server configuration successfully.
The Access Manager Configuration tool should display configured status Yes for
Access Manager Policy Server.
210 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
1. From the Access Manager Configuration, select Access Manager
Authorization Server and click Configure.
2. When the Domain Information window appears, enter Default in the Domain
field and click Next.
3. When the Policy Server Information window appears, we entered the
following and then clicked Next:
– Policy server hostname: tamwin1.itso.ral.ibm.com
– Policy server port: 7135
4. When the Administrator ID for domain Default window appears, we entered
sec_master, <password> and then clicked Next.
5. When the Authorization Server window appears, we entered the following and
then clicked OK:
– Local host name: tamwin1.itso.ral.ibm.com
– Administration request port: 7137
– Authorization request port: 7136
The Access Manager Configuration tool should display configured status Yes
for Access Manager Authorization Server.
6. Click Close to exit the Access Manager Configuration utility.
Note: If you install Tivoli Access Manager V5.1 to a path other than the default
installation path, you will see a Windows service startup error, as in
Figure 6-6.
212 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Tivoli Access Manager Windows services startup
In our example, we have installed Tivoli Directory Server and the Tivoli Access
Manager components on the same node (Policy Server node). The Tivoli Access
Manager - Access Manager Auto-Start Service is set to automatic startup by
default. The purpose of the Access Manager Auto-Start Service is to start other
Tivoli Access Manager services automatically, such as the Policy Server and
Authorization Server.
The Tivoli Access Manager services startup is dependent on the Tivoli Directory
Server being started. Even after attempting to make the Access Manager
Auto-Start Service dependent on the Tivoli Directory Server service startup, we
found that it timed-out. To resolve this issue, we set the Access Manager
Auto-Start Service to manual, and manually started the service after the Tivoli
Directory Server service had completed startup.
Note: Configuring Web Portal Manager against JREs other than the IBM
JRE V1.3.1 may cause the configuration to fail.
Note: The Web Portal Manager war file and the runtime are installed to the
target system.
10.When the installation is complete you should see a dialog with the message
All Access Manager components have been installed. Installation
completed successfully. Click OK to exit.
214 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Configure Web Portal Manager
To configure the PDJRTE and the Web Portal Manager, do the following:
1. Configure the Access Manager Java Runtime Environment (PDJRTE).
a. Open a command window and navigate to the following directory where
the Tivoli Access Manager components have been installed:
cd \ibm\Tivoli\tam\sbin
b. Run the following command to start the pdjrtecfg configuration tool:
pdjrtecfg -action config -interactive
c. From the Configuration Type window, select Full and then click Next.
d. When the Java Runtime Environment window appears, ensure that you
enter the JRE path to the WebSphere Application Server V5.0.2 JRE. In
our example, we entered the following and clicked Next:
JRE Path: c:\ibm\WebSphere\AppServer\java\jre
e. When the Policy Server Information window appears, we entered the
following and then clicked Next:
• Hostname: tamwin1.itso.ral.ibm.com
• Port: 7135
• Domain: Default
f. When the Logging Information window appears, we entered the following
and then clicked Finish:
• Check Enable Tivoli Common Directory for logging.
• Log directory: c:\ibm\Tivoli\common
This option is greyed out, and defaults to the path set during
configuration.
g. You should see a dialog with the message Configuration of Access
Manager Java Runtime Environment completed Successfully. Click OK.
2. Configure the Web Portal Manager.
a. Open a command window and navigate to the following directory where
the Tivoli Access Manager components have been installed:
cd \ibm\Tivoli\tam\sbin
b. Run the following command to start the Web Portal Manager configuration
tool:
amwpmcfg -action config -interactive
c. When the WebSphere Application Server Information window appears, we
accepted the detected path (for example, c:\ibm\WebSphere\AppServer)
and clicked Next.
Note: For more detailed information on installing the Tivoli Access Manager
V5.1 Base Fixpack 2, refer to the Readme, which can be found at:
http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2bT
ivoli+%2bAccess+%2bManager&uid=swg24006925&loc=en_US&cs=utf-8&cc=us&lang=all
216 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
1. Back up the Tivoli Access Manager V5.1 Base databases on the Policy
Server node be before installing Fixpack 2 as follows:
a. Create a database backup directory (for example, c:\ibm\tamdb.bak).
b. Open a command window and the following command:
pdbackup -action backup -list c:\ibm\Tivoli\tam\etc\pdbackup.lst -path
c:\ibm\tamdb.bak
2. Ensure that you have installed IBM GSKit V7.0.1.16, which is a prerequisite to
Fixpack 2.
Refer to 6.2.3, “IBM GSKit upgrade installation” on page 188 for details.
3. Ensure that the Tivoli Access Manager Windows services are stopped before
installing the fixpack:
– Access Manager Authorization Server
– Access Manager Policy Server
4. Ensure that the server1 application server where Web Portal Manager has
been deployed is stopped.
5. Download Tivoli Access Manager V5.1 Base Fixpack 2 from the following
URL to a temporary directory (for example, c:\temp\tam51.fp2) on the Policy
Server node:
http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2b
Tivoli+%2bAccess+%2bManager&uid=swg24006925&loc=en_US&cs=utf-8&cc=us&lang=a
ll
6. Navigate to the temporary directory where you downloaded the fixpack (for
example, c:\temp\tam51.fp2), and run 5.1-TAM-FP02-WIN.exe to start the
Access Manager V5.1 Fixpack Setup (5.1.0.2).
7. When the Welcome window appears, click Next.
8. When the License Agreement window appears, review the terms, and if in
agreement click Yes.
9. When the installation is complete, click Finish.
10.When the Configuration Type window appears, select Full and click Next.
11.When the Java Runtime Environment window appears, specify the path to the
WebSphere Application Server JRE (for example,
c:\ibm\WebSphere\AppServer\java\jre) and then click Next.
12.To verify that the Fixpack installation was successful, enter the following
command:
pdversion
This should return a list of components installed at the 5.1.0.2 level (Fixpack
2).
13.Restart the Access Manager Auto-Start Service Windows service.
– Access Manager Authorization Server.
– Access Manager Policy Server.
The installation and base configuration for the Policy Server node components is
complete.
Note: When installing and configuring the Reverse Proxy node, we referenced
the following product guides and redbook:
Web Security Installation Guide, IBM Tivoli Access Manager V5.1,
SC32-1361
WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1359
A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager
V4.1, SG24-6077, redbook
The high level tasks to install the Reverse Proxy node are as follows:
1. Windows 2000 Server installation.
218 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2. Install GSKit.
3. Install Java Runtime Environment (JRE)
4. Install Tivoli Directory Client.
5. Tivoli Access Manager - WebSEAL installation.
6. Tivoli Access Manager - WebSEAL configuration.
7. Tivoli Access Manager V5.1 Base Fixpack 2 installation.
8. Tivoli Access Manager V5.1 WebSEAL Fixpack 2 installation.
For details as to why the IBM GSKit V7.0.1.16 is needed and how to install it,
refer to 6.2.3, “IBM GSKit upgrade installation” on page 188.
For the ITSO working example, we chose to use the native installation utilities.
220 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
For details see “Install GSKit” on page 219.
– Ensure that the Java Runtime Environment is installed, which is required
by the iKeyman utility used by GSKit to create a keystore and certificates.
For details see “Install Java Runtime Environment (JRE)” on page 219.
– Ensure that the Tivoli Directory Client is installed.
For details see “Install Tivoli Directory Client” on page 219.
2. Insert the IBM Tivoli Access Manager Web Security for Windows 2000 CD.
3. Navigate to the <CD_Root>\windows\PolicyDirector\Disk Images\Disk1 folder
and run Setup.exe to start the installation program.
4. When the Choose Setup Language window appears, select the desired
language (for example, English) and click OK.
5. When the Welcome window appears, click Next.
6. When the License Agreement window appears, review the terms and, if in
agreement, click Yes.
7. When the Select Packages window appears, we checked the following
packages and then clicked Next:
– Check Access Manager Runtime.
– Check Access Manager Java Runtime Environment.
– Check Access Manager Web Security Runtime.
– Check Access Manager WebSEAL.
8. Access Manager Runtime installation.
When the Access Manager Runtime Choose Destination Directory window
appears, we did the following:
a. Click Browse.
b. Enter the destination directory c:\ibm\Tivoli\tam and click OK.
c. Click Next.
d. When the Access Manager Runtime Installation Summary window
appears, click Next to begin copying files.
9. Access Manager Web Security Runtime installation.
a. When the Welcome Access Manager Web Security Runtime window
appeared, click Next.
b. When the License Agreement window appears, review the terms and, if in
agreement, click Yes.
c. When the Access Manager Java Runtime Environment Choose
Destination Directory window appears, we did the following:
i. Click Browse.
222 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
• Host name: tamwin1.itso.ral.ibm.com
• Listening port: 7135
b. When the Registry window appears, select LDAP and click Next.
c. When the Domain Information window appears, we accepted Default
(default-supplied value—do not change) in the Local domain name field
and then clicked Next.
d. When the LDAP Server Information window appears, we entered the
following and then clicked Next:
• LDAP host name: tamwin1.itso.ral.ibm.com
• LDAP port number: 389
e. When the SSL with the registry server window appears, we selected No
next to Enable SSL with the registry server and clicked Next.
224 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
f. After configuration, click OK.
g. When done, close the configuration utility by clicking Close.
Ensure that the Tivoli Access Manager WebSEAL Windows service is stopped
prior to installing the fixpack.
For details on installing Tivoli Access Manager V5.1 Base Fixpack 2, refer to
6.2.12, “Tivoli Access Manager V5.1 Base Fixpack 2 installation” on page 216.
Note: For more detailed information on installing the Tivoli Access Manager
V5.1 WebSEAL Fixpack 2, refer to the readme, which can be found at:
http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2bT
ivoli+%2bAccess+%2bManager&uid=swg24006926&loc=en_US&cs=utf-8&cc=us&lang=all
1. Ensure that you are logged into the Reverse Proxy node as an administrator.
2. Back up the Tivoli Access Manager V5.1 WebSEAL databases on the
Reverse Proxy node be before installing Fixpack 2 as follows:
a. Create a database backup directory (for example, c:\ibm\websealdb.bak).
b. Open a command window and enter the following command:
pdbackup -action backup -list c:\ibm\Tivoli\tam\etc\pdbackup.lst -path
c:\ibm\websealdb.bak
3. Ensure that you have installed IBM GSKit V7.0.1.16, which is a prerequisite to
Fixpack 2.
Refer to “Install GSKit V7.0.1.16” on page 191 for details.
4. Ensure that the Tivoli Access Manager WebSEAL-<instance> Windows
service is stopped before installing the fixpack.
5. Download Tivoli Access Manager V5.1 WebSEAL Fixpack 2 from the
following URL to a temporary directory (for example, c:\temp\tam51ws.fp2) on
the Reverse Proxy node:
http://www-1.ibm.com/support/docview.wss?rs=203&context=SW000&q1=%2bfix+%2b
Tivoli+%2bAccess+%2bManager&uid=swg24006926&loc=en_US&cs=utf-8&cc=us&lang=a
ll
6. Navigate to the temporary directory where you downloaded the fixpack (for
example, c:\temp\tam51ws.fp2) and run 5.1-AWS-FP02-WIN.exe to start the
Access Manager V5.1 WebSEAL Fixpack 2 Setup (5.1.0.2).
7. When the Welcome window appears, click Next.
8. When the License Agreement window appears, review the terms and, if in
agreement, click Yes.
9. When the installation completes, click Finish.
Note: If a configuration window appears for the PDJRTE, you can click
Cancel since we have already configured the Access Manager Java
Runtime Environment.
226 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
10.To verify that the Fixpack installation was successful, open a command
window and enter the following command:
pdversion
This should return a list of components installed at the 5.1.0.2 level (Tivoli
Access Manager Base and WebSEAL Fixpack 2).
11.Start the Access Manager Auto-Start Service Windows service.
This completes the base installation and configuration of the Reverse Proxy
node.
Note: When installing and configuring the Portal Server node, we referenced
the following:
IBM WebSphere Portal Extend for Multiplatforms V5.0.2 InfoCenter at:
http://www.ibm.com/websphere/portal/library
IBM WebSphere Portal for Multiplatforms V5 Handbook, SG24-6098,
redbook
A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager
V4.1, SG24-6077, redbook
The high-level tasks to install the Portal Server node are as follows:
1. Windows 2000 Server installation
2. WebSphere Portal Server V5.0 installation
3. WebSphere Application Server Enterprise V5 Fixpack 2 (V5.0.2) installation
4. WebSphere Application Server V5.0.2 Fixes installation
5. WebSphere Portal V5 Fixpack 2 (V5.0.2) installation
6. WebSphere Application Server Enterprise V5.0.2 Cumulative Fix (V5.0.2.3)
installation
7. WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) installation
8. Java Runtime Environment (JRE) V1.3.1 installation
9. Tivoli Access Manager Java Runtime Environment installation
10.DB2 Universal Database installation
Tip: You may have to minimize the command prompt window if it stays on
top and obscures the language prompt.
2. When the Install Shield Language window appears, select the desired
language (for example, English) and click OK.
3. When the Welcome window appears, you are provided with an option to
launch the InfoCenter (optional). Click Next to continue the installation.
4. When the License Agreement page appears, review the terms and, if in
agreement, select I accepts the terms in the license agreement and then
click Next.
The installer will check for the required operating system and prerequisites.
5. The next window provides the installation options to choose from Full (all
components) or Custom (useful when components such as WebSphere
Application Server are already installed).
In our example, we selected Full and click Next to continue.
6. The wizard displays a window for the WebSphere Application Server
installation directory. We used the following path and then clicked Next:
228 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
– Installation directory: C:\ibm\WebSphere\AppServer
7. The next window displays the IBM HTTP Server installation directory. We
used the following path and then clicked Next:
– Installation directory: C:\ibm\IBMHTTPServer
8. The next window prompts for us the System Logon user ID and password that
will be used to start the WebSphere Application Server and IBM HTTP Server
programs, if these are selected to be run as a service. We used the following
settings and clicked Next:
– Check Run WebSphere Application Server as a service.
– Check Run IBM HTTP Server as a service.
– User ID: admin
In our example, we create the admin user as part of our Windows
configuration in 6.4.1, “Windows 2000 Server installation” on page 228.
– Password: <password>
Note: If the User ID had not been created or you did not give administrator
rights to the current user, you will see an error message like Figure 6-7.
You should then proceed to create the user exactly as specified in, “Create
admin user and assign user rights” on page 183.
9. The next window prompts for the node name and host name to be used for
the WebSphere Application Server install. We used the following values and
clicked Next:
– Node name: wpwin1
– WebSphere Application Server hostname: wpwin1.itso.ral.ibm.com
10.We are now prompted for the WebSphere Portal installation directory. We
used the following path and clicked Next:
– Installation directory: C:\ibm\WebSphere\PortalServer
11.The next window prompts for the Portal administrative user and password.
We used the following values, confirmed the password, and clicked Next:
– Administrative user: wpsadmin
– Password: <password>
The <password> for wpsadmin is user defined during the installation.
– Confirm Password: <password>
12.The next window will display the different components that are going to be
installed. Click Next.
230 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
13.The Installer program will then prepare the installation. After a while, you will
be prompted to insert CD #1-1 WebSphere Application Server Enterprise for
Windows. It will first start locating a Java Virtual Machine, then begin the
install of WebSphere Application Server (Base and PME).
After this installation is completed, you will be prompted to insert CD #1-6
WebSphere Application Server Fixpack and eFixes for Windows and Linux.
Note: For the ITSO example, we avoided the necessity of replacing CDs
by putting the CD images on the network drive. By verifying that you use
the following directory names for each CD image (and place the images in
the same directory on the network), you will not be prompted to insert any
CDs:
setup
cd1-1
cd1-6
cd2
The wizard will then perform the following tasks, displaying a progress meter
for each task:
– Preparing the WebSphere Application Server Fix Pack files
– Installing WebSphere Application Server Fix Pack 1
– Installing WebSphere Application Server Enterprise Fix Pack 1
– Installing WebSphere Application Server Fixes
14.When these tasks are complete, the installer will start the WebSphere
Application Server (server1 application server). After the server starts, you
will be prompted to insert CD #2 WebSphere Portal Server - WebSphere
Portal Content Publisher. It will start installing WebSphere Portal.
15.When this completes, the InfoCenter will install and then WebSphere Portal
Server will start (WebSphere_Portal application server). The install is then
validated and the portlets will begin to be installed. Once this has finished, the
Installer will go on to install the content publishing features. Once the whole
procedure is completed, you should be presented with a window stating that
the installation was successful.
Leave the checkbox selected for Launch First Steps and click Finish.
The installation program will then complete and close. Note that as its final task,
it will load the WebSphere Portal First Steps application.
If you have restarted the system where WebSphere Portal is installed after the
installation and WebSphere Portal and the First Steps are not running, do the
following:
1. Start the WebSphere Portal application by clicking Start → Programs →
IBM WebSphere → Portal Server v5.0 → Start the Server.
Alternatively, start the WebSphere Portal application server from the
command line as follows:
c:\ibm\WebSphere\AppServer\bin\startServer Webphere_Portal
2. Start First Steps application by selecting Start → Programs → IBM
WebSphere → Portal Server v5.0 → First Steps.
Tip: When launching the portal from the first step GUI, be sure that the
URL contains the fully qualified DNS name in case the URL has only the
hostname. This could happen if the System properties → Network
Identification → Full computer name does not contain the domain name
extension. If this is the case then add the computer to the domain or add
the domain name.
2. Log in to the portal by clicking the Log in link located in the upper right corner.
This will take you to a new page prompting for login information.
– User ID: wpsadmin
This user ID was created during the WebSphere Portal installation.
– Password: <your_password>
The password was user defined during the WebSphere Portal installation.
3. You should be presented with the personalized portal pages for the logged in
user. If the install is successful and you have Internet access, you should see
a portal a page like Figure 6-8 displayed.
If your computer does not have direct access to the Internet, you will see a
page like Figure 6-9 on page 234. This error is purely cosmetic and happens
232 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
because some of the given portlets obtain content to display by connecting to
servers available on the Internet.
234 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Application Server (Base), WebSphere Application Server Network Deployment,
WebSphere MQ, and Programming Module Enhancements (PME).
236 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Install WebSphere Application Server PME V5 Fixpack 2
To install WebSphere Application Server Programming Module Extension (PME)
V5 PME Fixpack 2 (V5.0.2), do the following:
1. Copy the WebSphere Application Server PME Fixpack 2 files and sub
directories found in the <CD_Root>\pmefp2\win directory of the WebSphere
Application Server Fixpack and eFixes for Windows and Linux CD to a
temporary directory (for example, c:\temp\was5pme.fp2).
2. Set up the environment by running the setupCmdLine.bat as follows:
c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat
3. To start the WebSphere Update Installer (updateWizard.bat) supplied with
WebSphere Application Server PME Fixpack 2 we entered the following:
c:\temp\was5pme.fp2\updateWizard.bat
4. When the WebSphere Update Installer language window appears, select the
appropriate language for the wizard (for example, English) and then click OK.
5. When the Welcome window appears, click Next.
6. The WebSphere Update Installer will detect your current WebSphere
Application Server version. Click Next.
Notice that the base version is now V5.0.2 since the base Fixpack was has
been installed (IBM WebSphere Application Server V5.0.2 + Enterprise
V5.0.1) in the installation directory (c:\ibm\WebSphere\AppServer).
7. Select Install fix packs and then click Next.
8. Enter the directory where you have copied the fixpack. For example, we
entered the following in the Fix pack directory field and then clicked Next:
c:\temp\was5pme.fp2\fixpacks
9. Select the was50_pme_fp2_win fixpack (default) and then click Next.
10.Review the fixpack settings and then click Next to begin the fixpack
installation of files.
11.When the WebSphere Application Server V5 PME Fixpack 2 installation is
complete, click Finish.
The following additional fixes are required for proper operation of WebSphere
Portal Server V5.0.2:
PQ75469.jar
PQ77008.jar
PQ77142.jar
PQ78370_Fix.jar
PQ78382_fix.jar
PQ78882_Fix.jar
PQ79083_5.0.2_Fix.jar
PQ79193_fix.jar
PQ81020_fix.jar
WAS_Adapter_10-30-2003_5.0.2_cumulative_Fix.jar
WAS_Sessions_08-12-2003_5.0.2_cumulative_Fix.jar
WAS_Security_07-07-2003_5.0.2-5.0.1-5.0.0_JSSE_cumulative_Fix.jar
WAS_Plugin_09-03-2003_5.0.X_cumulative_Fix_Win.jar
238 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
5. When the WebSphere Update Installer language window appears, select the
appropriate language for the wizard (for example, English) and then click OK.
6. When the Welcome window appears, click Next.
7. The WebSphere Update Installer will detect your current WebSphere
Application Server version. Click Next.
Notice that the base version is now V5.0.2 since the base Fixpack was has
been installed (IBM WebSphere Application Server V5.0.2 + Enterprise
V5.0.2) in the installation directory (c:\ibm\WebSphere\AppServer).
Note: If the base version is not detected, enter the path to the WebSphere
Application Server installation directory.
11.Review the fixes selected to install and then click Next to begin the fix
installation of files.
12.When the WebSphere Application Server V5.0.2 Fixes installation is
complete, click Finish.
For details on how to verify the WebSphere Application Server refer to “Verify
WebSphere Application Server V5.0.2” on page 200.
When the Fixpack is complete, you should see the message Fix pack
installation completed successfully.
7. Update the WebSphere Portal configuration.
240 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: Configuration failure due to WebSphere SOAP timeout.
After the WebSphere Portal V5 Fixpack installation is complete, you will need
to update the WebSphere Portal configuration.
a. Restart the IBM HTTP Server.
b. Open a command window and enter the following command to update the
WebSphere Portal configuration:
c:\ibm\WebSphere\PortalServer\config\WPSConfig.bat WP-PTF-502
-DPortalAdminPwd=<password>
Where <password> is the WebSphere Portal administrator password.
If you have installed and are using WebSphere Portal Content Publisher V5
installed the Content Publisher Fixpack 2, you will also need to update the
Document Manager search index.
When the fixpack is installed, the existing search index for Document Manager is
deleted. Before you can use the search function with Document Manager after
installing the fixpack, WebSphere Portal must update the search index through
the usual automated process, where the search index is updated according to a
specified interval. You can either wait until the next scheduled update occurs, or
you can change the interval to the shortest possible time to cause the update to
occur sooner.
242 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Refer to the Managing documents → Document Manager → Search topic in
the WebSphere Portal Information Center for details on setting the update
interval:
http://www.ibm.com/websphere/portal/library
244 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
6. The WebSphere Update Installer will detect your current WebSphere
Application Server version. Click Next.
The version should be IBM WebSphere Application Server V5.0.2 +
Enterprise V5.0.2, and installation directory c:\ibm\WebSphere\AppServer.
Note: If the base version is not detected, enter the path to the WebSphere
Application Server installation directory.
Note: If the base version is not detected, enter the path to the WebSphere
Application Server installation directory.
246 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
1. Download the WebSphere Application Server V5.0.2 Cumulative Fix 3
(V5.0.2.3) for Windows (was502_cf3_win.zip) to a temporary directory
(c:\temp) on the Portal Server node from the following URL:
http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&uid=swg24006
289
2. Unpack the cumulative fix download (was502_cf3_win.zip) to a temporary
directory (for example, c:\temp\was502.cf3).
3. To start the WebSphere Update Installer (updateWizard.bat) supplied with
WebSphere Application Server Cumulative Fix 3, we entered the following in
a command window:
c:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat
c:\temp\was502.cf3\updateWizard.bat
4. When the WebSphere Update Installer language window appears, select the
appropriate language for the wizard (for example, English) and then click OK.
5. When the Welcome window appears, click Next.
6. The WebSphere Update Installer will detect your current WebSphere
Application Server version. Click Next.
The version should be IBM WebSphere Application Server V5.0.2.2 +
Enterprise V5.0.2.2, and the installation directory
c:\ibm\WebSphere\AppServer.
Note: If the base version is not detected, enter the path to the WebSphere
Application Server installation directory.
Normally, you would need to download the efixes individually from the
WebSphere Application Server Support Web site. However, there is a file located
on the WebSphere Portal Support Web site that includes all of these efixes and
targets specifically WebSphere Application Server 5.0.2.3 for Windows.
Therefore, we chose to download this file from the following location:
http://www6.software.ibm.com/dl/websphere33/wps-h?S_PKG=dlwps50fp&S_TACT=&S
_CMP=
Note: The WebSphere Portal Support Web site requires you to log in as a
registered user (or register first). Once you navigate to the download page you
will see a listing of many fixes. We downloaded the following file: WAS 5.0.2.3
Fixes (WAS5023CumulativeWindows.zip).
The readme file for WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) can
be found at:
http://publib.boulder.ibm.com/pvc/wp/5021/ent/en/readme/install.html
248 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: When you access the above URL, you will first need to click the
Portal Server 5.0 Fix pack 2 link. Next you will need to log in (or
register). You will then see a WAS 5.0.2.3 fixes link to download the
fixes (WAS5023CumulativeWindows.zip).
Note: If the base version is not detected, enter the path to the WebSphere
Application Server installation directory.
WAS_Dynacache_01-30-2004_5.0.2_cumulative
PQ78370
PQ81248
PQ81416
WAS_CM_08-12-2003_5.0.2-5.0.1_cumulative_Fix
WAS_Adapter_10-30-2003_5.0.2_cumulative_Fix
Note: If one of the three following fixes is selected, you will receive an error
stating that the fix(es) are not supported on your installed products:
PQ75469
PQ77008
PQ78166
Also, we did not select PQ76567 or PQ79083 since the readme states that
they are included in WAS_Dynacache_01-30-2004_5.0.2_cumulative.
Finally, there are seven remaining efixes that we did not select for two
reasons:
They are not required per the WebSphere Portal Server V5.0.2
Cumulative Fix 1 readme file.
We tested the selection of all efixes and eventually had problems
running the WPSconfig.bat WP-PTF-5021 configuration task after
installing WebSphere Portal Server V5.0.2 Cumulative Fix 1.
10.On the install summary page, review the fixes to be installed or refreshed and
then click Next to begin the fix pack installation of files.
11.When the WebSphere Application Server V5.0.2.3 Fixes installation is
complete, click Finish.
For details on how to verify the WebSphere Application Server refer to “Verify
WebSphere Application Server V5.0.2” on page 200.
Note: The WebSphere Portal Server will not work with the level of WebSphere
Application Server at this stage. WebSphere Portal will work after applying the
WebSphere Portal Cumulative Fix 1 (V5.0.2.1) in the next section.
250 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
6.4.7 WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) installation
This section describes how to download and install a new WebSphere Portal
V5.0.2 Update Installer and the WebSphere Portal V5.0.2 Cumulative Fix 1
(V5.0.2.1).
Note: From the URL listed, you will have to log in as a registered user (or
register first). Once you navigate to the download page you will see a
listing of many fixes. We downloaded the following:
WebSphere Portal Update Installer (PortalUpdateInstaller.zip)
Portal 5.0.2 Cumulative Fix 1: (WP_PTF_5021.jar)
252 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2. Unzip the contents of PortalUpdateInstaller.zip to the <wp_root>\update
directory (overwriting any current files if necessary).
3. Change the timeout for the SOAP client (if you have not done so previously):
a. Open the soap.client.props file in <was_home>\properties.
b. Modify the request timeout as follows (default is 180 seconds):
com.ibm.SOAP.requestTimeout=6000
c. Save and close the file.
4. Open a command window and enter the following command to set up the
Java environment for the WebSphere Portal update installer:
C:\ibm\WebSphere\AppServer\bin\setupCmdLine.bat
5. Navigate to the WebSphere Portal update directory:
cd \ibm\WebSphere\PortalServer\update
6. To start the WebSphere Portal update installer, enter the following command:
updatePortal -fixpack -installDir “c:\ibm\WebSphere\PortalServer”
-fixpackDir “c:\ibm\WebSphere\PortalServer\update” -install -fixpackID
WP_PTF_5021
When the Fixpack is complete, you should see the message Fix pack
installation completed successfully.
If you receive an error, you can review the log information in the
c:\ibm\WebSphere\PortalServer\log directory.
7. Restart the IBM HTTP Server.
8. Open a command window and enter the following command to update the
WebSphere Portal configuration:
c:\ibm\WebSphere\PortalServer\config\WPSConfig.bat WP-PTF-5021
-DPortalAdminPwd=<password>
Where <password> is the WebSphere Portal administrator password.
For details refer to 6.2.4, “Java Runtime Environment (JRE) V1.3.1 installation”
on page 192.
254 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
6.4.9 Tivoli Access Manager Java Runtime Environment installation
This section describes how to install and configure the following:
Install Tivoli Access Manager Java Runtime Environment.
Install Tivoli Access Manager V5.1 Base Fixpack 2.
Configure PDJRTE for WebSphere Application Server JRE.
Configure PDJRTE for standalone JRE V1.3.1.
Note: If you have already downloaded this fixpack for your TAM installation
on the Policy Server node, you can use it for this node as well.
2. Navigate to the temporary directory where you downloaded the fixpack (for
example, c:\temp\tam51.fp2), and run 5.1-TAM-FP02-WIN.exe to start the
Access Manager V5.1 Fixpack Setup (5.1.0.2).
3. When the Welcome window appears, click Next.
4. When the License Agreement window appears, review the terms and, if in
agreement, click Yes.
5. When the installation is complete, click Finish.
256 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Configure PDJRTE for standalone JRE V1.3.1
To configure the Tivoli Access Manager Java Runtime Environment (PDJRTE)
for the standalone JRE V1.3.1, do the following Portal Server node:
For this reason, we installed the Tivoli Access Manager Java Runtime
Environment V1.3.1 and configured the Tivoli Access Manager Java Runtime
Environment (PDJRTE) to use the standalone JRE V1.3.1.
For details on installing a DB2 Server refer to 6.2.2, “DB2 Universal Database
installation” on page 184.
For the ITSO scenario, we found that the Configuration Wizard did not perform
many of the configuration tasks we needed for our environment; thus we
configured the environment manually. By performing the configuration
manually, we are able to describe what the configuration tasks accomplish,
demonstrate by example configuration options and procedures, and provide
verification steps before proceeding.
260 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7.1 Configure WebSphere Portal for DB2
This section describes how to configure and verify WebSphere Portal V5.0.2.1 to
use DB2 UDB V8.1 in place of the default Cloudscape database.
DbType db2
WpsDbName wps50
DbDriver COM.ibm.db2.jdbc.app.DB2Driver
DbDriverDs COM.ibm.db2.jdbc.DB2XADataSource
DbUrl jdbc:db2:wps50
DbUser db2admin
DbPassword <your_dbuser_password>
DbLibrary c:/ibm/sqllib/java/db2java.zip
Note: Directory is java ,not java12
WpsDsName wps50DS
WpsXDbName wps5TCP
WpsDbNode wpsNode
FeedbackXDbName fdbk5TCP
WpcpDbName wpcp50
Note: Seperate database
WpcpDbUser db2admin
WpcpDbPassword <your_dbuser_password>
WpcpDbUrl jdbc:db2:wpcp50
FeedbackDbName fdbk50
FeedbackDbUser db2admin
FeedbackDbPassword <your_dbuser_password>
FeedbackDbUrl jdbc:db2:fdbk50
262 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Section of Keyword ITSO value
wpconfig.properties file
WmmDbUser db2admin
WmmDbPassword <your_dbuser_password>
WmmDbUrl jdbc:db2:wps50
Note: If you are using a remote DB2 database, ensure that your databases
have been created manually. Refer to the WebSphere Portal InfoCenter
(search on Setting up DB2).
Note: This section does not apply to runtime topologies such as the
development WebSphere Test Environment or a runtime environment
architected not to include an external Web server.
To configure an external IBM HTTP Server for WebSphere Portal in place of the
WebSphere Application Server internal HTTP service, do the following:
1. Verify that the IBM HTTP Server is started.
2. Navigate to the <wp_home>\config directory.
3. Back up the WebSphere Portal configuration properties found in the
wpconfig.properties file by entering the following command:
wpsconfig backup-main-cfg-file
264 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4. Change the wpconfig.properties values as seen in Table 7-2 on page 265. For
a detailed description of each of the keywords refer to the WebSphere Portal
InfoCenter found at (search on Configuring your Web server) go to:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html
Table 7-2 ITSO example wpconfig.properties values for external Web server
Section in wpconfig.properties file Keyword ITSO example value
WpsHostPort 80
Note: Prior to adding the external Web server, you needed to include the
port number 9081 for the internal HTTP transport the WebSphere Portal
Server was using in the URL. For example,
http://wpwin1.itso.ral.ibm.com:9081/wps/portal
Now that we have configured the external Web server, we do not need to
specify the port (default port 80) in the URL:
http://wpwin1.itso.ral.ibm.com/wps/portal
Note: For more detailed information, refer to the WebSphere Portal V5.0.2
InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html
266 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7.3.2 Create LDIF file containing users and groups
Users and groups can be created for the Tivoli Directory Server from the Web
Administration Tool or by importing an LDIF file containing users and groups. The
main structure of the wp-itso.ldif file is displayed in Figure 7-1 on page 267.
dc=itso,dc=ibm,dc=com
cn=users cn=groups
For the ITSO working example, we created the wp-itso.ldif based on the
PortalUsers.ldif file found on the WebSphere Portal Setup CD. We have included
the wp-itso.ldif file in the ITSO sample code c:\6325code\config\ldap directory
(see Example 7-1).
dn: dc=itso,dc=ibm,dc=com
objectclass: domain
objectclass: top
# Add lines according to this scheme that correspond to your suffix
dc: itso,dc=ibm,dc=com
dc: itso,dc=ibm
dc: itso
dn: cn=users,dc=itso,dc=ibm,dc=com
objectclass: container
objectclass: top
cn: users
dn: uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: wpsadmin
userpassword: wpsadmin
sn: admin
givenName: wps
cn: wps admin
dn: uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: wpsbind
userpassword: wpsbind
sn: bind
givenName: wps
cn: wps bind
dn: cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com
objectclass: groupOfUniqueNames
objectclass: top
uniquemember: uid=wpsadmin,cn=users,dc=itso,dc=ibm,dc=com
cn: wpsadmins
7.3.3 Import the LDIF file (wp-itso.ldif) to create users and groups
To import the ITSO-provided wp-itso.ldif file to create users and groups to the
Tivoli Directory Server, do the following on the Policy Server node (where Tivoli
Directory Server is installed in our example):
1. Stop the IBM Tivoli Directory Server V5.2 Windows service.
2. Copy the ITSO-provided c:\6325code\config\ldap\wp-itso.ldif file to a
temporary directory where Tivoli Directory Server is installed (for example,
c:\temp).
268 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. Start the Tivoli Directory Server Configuration Tool by clicking Start →
Programs → IBM Tivoli Directory Server V5.2 → Directory
Configuration.
4. Select Import LDIF data.
5. When the Import LDIF Data page appears, we entered the following and then
clicked Import (bottom of page):
– Path and LDIF file name: c:\temp\wp-itso.ldif
– Select Standard import.
After the import has finished successfully, a message will be displayed
reporting how many entries have been imported into the directory server.
6. When the import is complete, click Close. Close the Configuration Tool.
7. Restart the IBM Tivoli Directory Server V5.2 Windows service.
8. Verify that the LDAP entries where created properly by performing an LDAP
search. For example, we entered the following from a command window on
the Policy Server node:
ldapsearch -h tamwin1 -b dc=itso,dc=ibm,dc=com -D
uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com -w its0ral0 -s sub uid=wpsadmin
Note: If you are running WebSphere Portal 5.0 or 5.0.2, you will need to install
PQ83389 before proceeding. More information on this fix for WebSphere
Member Manager can be found at:
http://www-1.ibm.com/support/docview.wss?rs=688&context=SSHRKX&q1=PQ83389
&uid=swg24006269&loc=en_US&cs=utf-8&lang=en+en
270 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
</ldapRepository>
<!-- Define which LDAP attribute is used for storing static group members -->
<attributeMap wmmAttributeName="groupMember"
pluginAttributeName="@LDAPGroupMember@"
applicableMemberTypes="Group"
dataType="String"
valueLength="1024"
multiValued="true"
readOnly="true" <!--Add attribute if not defined. -->
defaultValue="uid=dummy" />
<!--Continue modifying the rest of the attributeMap tags for readOnly access-->
</repositoryAttributes>
272 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Example 7-4 ITSO example wpconfig.properties values for LDAP security
Section in Keyword ITSO example value
wpconfig.properties file
PortalAdminPwd <password>
PortalAdminGroupId cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com
PortalAdminGroupId wpsadmins
Short
SSODomainName itso.ral.ibm.com
LDAPPort 389
LDAPAdminUId uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
LDAPAdminPwd <password>
LDAPServerType IBM_DIRECTORY_SERVER
LDAPBindID uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
LDAPBindPassword <password>
LDAPUserSuffix cn=users
LdapGroupPrefix cn
LDAPGroupSuffix cn=groups
LDAPUserObjectCla inetOrgPerson
ss
LDAPGroupObjectCl groupOfUniqueNames
ass
LDAPGroupMember uniqueMember
LDAPUserFilter (&(uid=%v)(objectclass=inetOrgPerson))
LDAPGroupFilter (&(cn=%v)(objectclass=groupOfUniqueNames))
LDAPsslEnabled false
Note: If you are not using an external HTTP server, you will want to set the
WpsHostName property in the wpconfig.properties file. For example:
WpsHostName=wpwin1.itso.ral.ibm.com
274 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
If the task completes successfully, you will see the message BUILD
SUCCESSFUL.
Note: You may receive the following error when running the configuration
task to enable security:
action-create-deployment-credentials:
[xmlaccess] XMLA0006I: Connecting to URL
http://localhost:9081/wps/config
[xmlaccess] XMLA0002I: Reading input file
C:\ibm\WebSphere\PortalServer\config\work\createDeploymentCredentials.
xml
[xmlaccess] XMLA0011I: Request was accepted.
[xmlaccess] <?xml version="1.0" encoding="UTF-8" ?>
[xmlaccess] <failure>
[xmlaccess]
com.ibm.wps.command.xml.XmlCommandServlet$AuthorizationException:
XMLC0005E: Authorization for user wpsadmin failed.
[xmlaccess] </failure>
. . . .
BUILD FAILED
file:../config/actions/wps_cfg.xml:289: XMLA0015E: Server response
indicates an error.
If you have received this error, it usually means that the following two items
are true:
Your LDAPAdminUId does not have write permissions to the LDAP
server.
Your Portal server is not configured for read-only access.
Therefore, you must either give your LDAPAdminUId (as defined in the
wpconfig.properties) write permissions via the LDAP server administration
interface, or you can configure your WebSphere Portal server for read-only
access as we have done in the ITSO example in “Configure WebSphere
Portal for read-only LDAP access” on page 269.
b. From the WebSphere Portal Welcome page, click Log in at the top right
corner (for example, we used the wpsadmin user ID and password).
Note: For information on disabling LDAP security for WebSphere Portal, refer
to “Disabing global security for WebSphere Application Server” on page 583.
276 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The section is organized into the following tasks:
1. IBM HTTP Server SSL configuration.
2. Configure WebSphere Portal for SSL.
3. Export IBM HTTP Server CA certificate.
4. Import IBM HTTP Server certificate into WebSEAL keystore.
5. Export WebSEAL certificate.
6. Import WebSEAL certificate into IBM HTTP Server keystore.
7. Enable mutual SSL for IBM HTTP Server.
Note: Substitute your fully qualified host name in this line (for example,
<VirtualHost wpwin1.itso.ral.ibm.com:443>).
– Uncomment:
SSLEnable
– Uncomment:
</VirtualHost>
– Uncomment and update the following:
Keyfile "c:\ibm\IBMHttpServer/ssl/keyfile.kdb"
Note: The keyfile path has been modified to include ssl instead of keys.
For example:
Keyfile "c:\ibm\IBMHttpServer/ssl/keyfile.kdb"
– Uncomment:
SSLV2Timeout 100
SSLV3Timeout 1000
6. Save the changes to the httpd.conf file.
278 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
WebSpherePluginConfig
"c:\ibm\WebSphere\AppServer/config/cells/plugin-cfg.xml"
Tip: The above text is two separate lines. Within the httpd.conf, the lines
are not wrapped.
If you backed up the httpd.conf.org, you can cut and paste the plug-in
entries to the SSL-enabled httpd.conf.
Note: This path must match the keyfile path in the httpd.conf.
4. In the Password Prompt window, enter the following and then click OK:
– Password: <your_password> (to protect the keystore file)
– Check Set expiration time? and enter the number of days before the
password will expire. If no expiration is required, do not check this.
5. When the information window appears with the following message, click OK:
The password has been encrypted and saved in file:
280 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Verify the IBM HTTP Server
To verify that the IBM HTTP Server is working properly, enter the following URLs
in a Web browser after the IBM HTTP Server has been started:
Verify HTTP:
http://<hostname>
Verify HTTPS:
https://<hostname>
To enable SSL for the WebSphere Application Server where WebSphere Portal
is installed, do the following:
1. Ensure that the WebSphere Application Server server1 is started on the
Portal Server node.
2. Start the WebSphere Application Server Administrative Console:
a. Enter the URL:
https://wpwin1.itso.ral.ibm.com:9043/admin
b. Enter WebSphere administrator credentials (for example, wpsbind).
3. Select Environment → Virtual Hosts.
4. Click default_host.
5. Click Host Aliases.
6. To add a Host Alias for port 443, click New.
Note: In our example, the IBM HTTP Server and plugin-cfg.xml are installed
on the same node as the WebSphere Application Server. The plugin-cfg.xml is
reloaded with the updated settings based on the RefreshInterval set in the
plugin-cfg.xml. By default, it is set to refresh after 60 seconds. If you want this
to take effect immediately, restart the IBM HTTP Server.
282 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<description></description>
<role-name>All Role</role-name>
</auth-constraint>
<user-data-constraint id="UserDataConstraint_4">
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Log in with the wpsadmin user ID and password. Verify that the Welcome page is
displayed.
284 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
and IBM CMS security providers. As part of our configuration of the GSKit
iKeyman utility, we added the IBM JCE and IBM CMS security providers (see
“Configure GSKit iKeyman utility” on page 225).
This section describes how to import the IBM HTTP Server certificate into the
WebSEAL keystore on the Reverse Proxy node.
1. Ensure that you have added the IBM CMS security provider to the
java.security file (see “Configure GSKit iKeyman utility” on page 225).
2. Determine the WebSEAL keystore file name and location.
a. Navigate to the c:\ibm\Tivoli\PDWeb\etc directory on the Reverse Proxy
node.
b. Open the webseald-default.conf file in a text editor.
c. Search webseal-cert-keyfile and record the value (for example,
c:/ibm/Tivoli/PDWeb/www-default/certs/pdsrv.kdb).
3. Copy the IBM HTTP Server certificate (for example, wp_httpd_cert.arm) from
the Portal Server node (c:\ibm\IBMHttpServer\ssl\) to the
c:/ibm/Tivoli/PDWeb/www-default/certs directory on the Reverse Proxy node.
4. Start the iKeyman utility on the Reverse Proxy node by entering the following
commands from a Windows command window:
cd \ibm\gsk7\bin
set JAVA_HOME=c:\ibm\Java131\jre
gsk7ikm
5. From the menu bar select Key Database File → Open.
6. When the Open window appears, do the following and then click OK:
– Key database type: Select CMS.
– Filename: pdsrv.kdb
– Location: c:/ibm/Tivoli/PDWeb/www-default/certs
7. When prompted, enter the password for the keystore. By default the
password is pdsrv.
The password can be changed by selecting Key Database File → Change
Password.
8. From the Key database content drop-down list, select Signer Certificates.
9. Click Add.
10.When the Add CA’s Certificate from a file window appears, we entered the
following and then clicked OK:
– Data type: Select Base64-encoded ASCII data.
– Certificate file name: wp_httpd_cert.arm
– Location: c:/ibm/Tivoli/PDWeb/www-default/certs
286 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. Click Extract Certificate.
4. When the Extract Certificate to a File window appears, we entered the
following and then clicked OK:
– Data Type: Select Base64-encoded ASCII data (default).
– Certificate file name: webseal_default_cert.arm
– Location: c:/ibm/Tivoli/PDWeb/www-default/certs
5. Close the iKeyman utility.
Note: Once the SSLClientAuth required keyword and value are set, we will
no longer be able to directly connect to the IBM HTTP Server via HTTPS.
HTTPS connections to the IBM HTTP Server will only be permitted from
WebSEAL.
7. Verify that you are not able to access the IBM HTTP Server directly via
HTTPs by entering the following URL in a Web browser:
https://wpwin1.itso.ral.ibm.com
288 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 7-3 Client Authentication message
8. You should see a message like Figure 7-3. Click Cancel. If you are then
prompted with a Security Alert, click No.
Note: For more information on applying Tivoli Access Manager ACLs to a new
LDAP suffix, refer to Appendix D, “Managing user registries, section Applying
IBM Tivoli Access Manager ACLs to new LDAP suffixes,” in the Base
Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360, product
guide.
Note: Apply TAM ACLs to new LDAP suffix via ldif file import.
This note offers an alternative solution for applying Tivoli Access Manager
ACLs to a new LDAP suffix using an ldif file import in the Tivoli Directory
Server. The ITSO sample code includes c:\6325code\config\ldap\tam-acls.ldif.
If you choose to import ACLs via the ldif, you can skip the rest of this section.
To apply Tivoli Access Manager ACLs to a new LDAP suffix, do the following:
1. Copy the c:\6325code\config\ldap\tam-acls.ldif file to the c:\temp directory.
2. Modify the tam-acls.ldif file for your suffix.
3. From command line, execute the following command.
ldapmodify -h tamwin1.itso.ral.ibm.com -D cn=root -w <password> -i
c:\temp\tam-acls.ldif
To apply Tivoli Access Manager ACLs to a new LDAP suffix, do the following on
the Policy Server node:
1. Ensure that the following IBM Tivoli Directory Server 5.2 Windows service is
running.
2. Start server1 via the command prompt:
cd /ibm/websphere/appserver/bin
startServer server1
290 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. Start the Tivoli Directory Server Web Administration Tool in a Web browser
at:
http://tamwin1.itso.ral.ibm.com:9080/IDSWebApp/IDSjsp/Login.jsp
Where tamwin1.itso.ral.ibm.com is the host name of the application server
where the IBM Directory Server Web Administration Tool has been installed.
4. From the Web Administration Tool, do the following and then click Login:
– Select the newly created server (for example, tamwin1.itso.ral.ibm.com)
from the drop-down list on the Login page.
– Username: cn=root
– Password: <password>
5. From the Web Administration Tool, select Directory management →
Manage entries.
6. When the Manage entries page appears, select the suffix from the list (for
example, dc=itso,dc=ibm,dc=com) by clicking it in the Select column, and
then click Edit ACL.
7. To add the cn=SecurityGroup,secAuthority=Default ACL to the ITSO suffix
dc=itso,dc=ibm,dc=com, do the following:
a. When the Edit ACL page appears, click Non-filtered ACLs.
b. When the Edit ACL → Non-filtered ACLs page appears, do the following
and then click Add:
• Check Propagate ACLs.
• DN (distinguished name): cn=SecurityGroup,secAuthority=Default
• Type: Select group.
c. When the Add access rights page appears, do the following and then click
OK at the bottom of the page (see Figure 7-4 on page 292):
• Add child: Select grant.
• Delete entry: Select grant.
• Select grant for all security classes (normal, sensitive, critical, system,
restricted) and actions (read, write, search, compare).
Note: You cannot grant write permission for the system security class
(menu option is disabled).
292 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
• Set the normal and system Security classes to grant for the read,
search and compare actions. Leave the Add child, Delete entry, and all
other Security classes blank (see Figure 7-5).
294 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
• Type: Select group.
c. When the Add access rights page appears, do the following and then click
OK at the bottom of of page (see Figure 7-7):
• Add child: Leave blank.
• Delete entry: Leave blank.
• Set the normal, system and restricted Security classes to grant for the
read, search and compare actions. Leave the Add child, Delete entry,
and all other Security classes blank (see Figure 7-7).
Table 7-3 lists the MIME type definitions we will add in this section. If your portlet
application uses other MIME types not found by default within WebSphere
Application Server, follow the same procedure to add the MIME type definitions.
296 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
8. On the Save to Master Configuration page, click Save.
9. Click Logout.
For the ITSO example, we chose to create an input file. In our example, we will
use multiple command mode with a command file containing the commands to
create the junction. Figure 7-8 depicts the ITSO sample /portal WebSEAL
junction for WebSphere Portal.
298 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: For scenarios using the internal HTTP service built-in to WebSphere
Application Server (development WebSphere Test Environment or no external
Web Server), update the port to 9444 for SSL instead of port 443 in the
wp-junction.pd (see Example 7-6).
Note: When creating the junction, WebSEAL will attempt to connect to the
back-end system (for example, WebSphere Portal). If the system is not
available, you will see the following message:
DPWWA1222E A third-party server is not responding. Possible causes:
the server is down, there is a hung application on the server, or
network problems. This is not a problem with the WebSEAL server.
DPWIV1054E Could not connect
[forms]
#--------------------------
#Forms
#--------------------------
#Enable authentication using forms
#One of <http, https, both, none>
forms-auth = https
300 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Now that forms are enabled, users will be able to log out without needing to close
the Web browser.
http://wpwin1.itso.ral.ibm.com/wps/portal http://wswin1.itso.ral.ibm.com/portal/wps/portal
For the ITSO example, we chose to use the junction cookies option for the base
configuration. When creating the junction in 7.5.3, “Create a WebSEAL junction”
on page 297, we used the -j option for junction cookies of processing URLs in the
request.
302 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7.5.6 Configure additional WebSEAL parameters
This section describes additional parameters we modified in the
webseaId-default.conf file for the ITSO working example.
[junction]
http-timeout=300
https-timeout=300
[session]
ssl-id-sessions=no
WP_no_access No access
304 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Create TAM objects for WebSphere Portal URIs
To create Tivoli Access Manager objects for WebSphere Portal URIs, do the
following on the Reverse Proxy node:
Note: For more information on creating Tivoli Access Manager objects, refer
to Chapter 12, “Application integration,”in the WebSEAL Administration Guide,
IBM Tivoli Access Manager V5.1, SC32-1359, product guide.
Note: We have added entries for both before the mapping and after the
mapping versions of URLs that will be handled by the JMT. This is
necessary, as WebSEAL will perform two ACL checks, one on the URL
before the JMT transformation and one after. Both must pass for access to
be granted.
Given that the real access control check is the second one, we have added
dummy entries for the before versions and mapped them to an object that
is readable by both unauthenticated and authenticated users (/portal/wps),
so the first ACL check will now always pass.
306 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
acl modify WP_no_access set unauthenticated T
acl modify WP_authenticated_access set user sec_master TcmdbsvaBrxl
acl modify WP_authenticated_access set group iv-admin Tcmdbsvarxl
acl modify WP_authenticated_access set group webseal-servers Tgmdbsrxl
acl modify WP_authenticated_access set group wpsadmins Tr
acl modify WP_authenticated_access set any-other Tr
acl modify WP_authenticated_access set unauthenticated T
acl modify WP_all_access set user sec_master TcmdbsvaBrxl
acl modify WP_all_access set group iv-admin Tcmdbsvarxl
acl modify WP_all_access set group webseal-servers Tgmdbsrxl
acl modify WP_all_access set group wpsadmins Tr
acl modify WP_all_access set any-other Tr
acl modify WP_all_access set unauthenticated Tr
2. To create the Tivoli Access Manager ACLs, modify the access and attach to
objects using the wp-tam-acl.pd file by entering the following from a Windows
command window:
pdadmin -a sec_master -p <password> wp-tam-acl.pd
To enable the JMT function, define an ASCII text file called jmt.conf as follows on
the Reverse Proxy node:
1. Create the jmt.conf file in the c:/ibm/Tivoli/PDWeb/www-default/lib directory.
The location of this file is specified in the [junction] stanza of the
webseald-default.conf configuration file jmt-map = lib/jmt.conf.
2. The format for data entry in the table consists of the junction name, a space,
and the resource location pattern. You can also use wildcard characters to
express the resource location pattern.
The ITSO-provided jmt.conf is displayed in Example 7-13.
You should see the default WebSphere Portal page for unauthenticated users.
308 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
There are two ways to establish a trust relationship between WebSphere
Application Server and WebSEAL:
Trust Association Interceptor (TAI)
For the ITSO working example runtime environment, we chose to use TAI for
the implementation procedure found in this section.
or
Light Weight Third Party Authentication (LTPA) Token
For details on implementing using an LTPA Token for the single sign-on
configuration, refer to Appendix B, “Configure single sign-on using LTPA” on
page 597.
There are three possible methods of verifying that the request to the WebSphere
Application Server came from WebSEAL:
TCP junction without SSL, with basic authentication credentials supplied
SSL junction with basic authentication
Mutual SSL junction without basic authentication credentials
To run the command once you have modified it for your environment, enter the
following:
c:\ibm\WebSphere\AppServer\bin\wsadmin" -f "c:\temp\config.was.tai .jacl"
-user wpsbind -password password
com.ibm.websphere.security.trustassociation.types webseal
com.ibm.websphere.security.webseal.id iv-user
com.ibm.websphere.security.webseal.ports 80,443
com.ibm.websphere.security.webseal.ignoreProxy false
com.ibm.websphere.security.webseal.mutualSSL true
Note: SSL between the
WebSEAL and the IBM HTTP
Server on the Portal Server node.
310 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 7-9 Trust association properites
After you have created all these properties, the Custom Properties should
look as shown in Figure 7-9.
Tip: Check and double-check the names and values of all the Custom
properties before saving the configuration changes.
10.Click Save. When the Save to Master Configuration page appears, click
Save.
11.Click Logout.
12.Restart the WebSphere_Portal application server.
312 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: The Logout link will not work at this stage. In the next section we
configure the WebSphere Portal login/logout for use with WebSEAL.
Modifying web.xml
To modify the WebSphere Portal login, such that login requests are directed to
the personalized portal URL, do the following:
Create wpslogout.html
When a WebSphere Portal user log outs of WebSEAL, we would like to display
the public (unauthenticated) portal page at:
http://wswin1.itso.ibm.com/portal/wps/portal
314 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
var cookie_string = "" + document . cookie;
var cookie_array = cookie_string . split ("; ");
// -->
</script>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Refresh"
content="2;URL=http://wswin1.itso.ral.ibm.com/portal/wps/portal">
<BR><BR>
<BR><BR>
Redirecting to public portal page ... select <a
href="http://wswin1.itso.ral.ibm.com/portal/wps/portal">here</a> if your browser does not
automatically redirect after 2 seconds.
</body>
</html>
Modify logout.html
When users from other applications (non WebSphere Portal) accessed through
WebSEAL perform logout, the logout.html page will be displayed.
1. Navigate to the following directory on the Reverse Proxy node:
C:\ibm\Tivoli\PDWeb\www-default\lib\html\C
2. Back up the existing logout.html to logout.html.org.
316 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
// Get cookie list and split into an array of cookie entries
var cookie_string = "" + document . cookie;
var cookie_array = cookie_string . split ("; ");
// -->
</script>
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=UTF-8">
<title>PKMS Administration: User Log Out</title>
</head>
<body bgcolor="#FFFFFF" text="#000000" onLoad=delete_all_cookies("/",exception_list)>
<font size="+2"><b>User %USERNAME% has logged out.</b></font>
</body>
</html>
Modify ConfigService.properties
To modify the WebSphere Portal logout command to point to the WebSEAL
logout command, do the following:
1. Navigate to the following directory on the Portal Server node:
c:\ibm\WebSphere\PortalServer\shared\app\config\services
2. Back up the ConfigService.properties file to ConfigService.properties.org.
3. Modify the ConfigService.properties with the contents seen in Example 7-17.
You will need to update the redirect.logout and redirect.logout.ssl to true, and
redirect.logout.url for your environment.
Note: Example 7-17 only includes the values we changed, not the entire
contents of the ConfigService.properties file.
In addition, you will need to update the ToolBarInclude.jsp (if found) in the
../wps.ear/wps.war/themes/html/<theme_name> directory for each theme.
318 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Where <theme> is the theme directory of interest. We have listed the themes
we updated the ToolBarInclude.jsp:
– Admin
– AdminLeftNavigation
– Corporate
– Engineering
– Finance
– Science
– YourCoFinancial
– YourCoFinancial2
2. Back up the ToolBarInclude.jsp.
3. Open the file in a text editor. Comment out the forgot password, selfcare, and
enroll buttons as shown Example 7-18.
Example 7-18 ITSO example ToolBarInclude.jsp snippet to be used as the default theme
<%-- forgot password button --%>
<%--
<wps:if loggedIn="no" notScreen="ForgotPassword">
<td class="wpsToolBar" valign="middle" align="<%=bidiAlignRight%>" nowrap>
<a class="wpsToolBarLink" href='<wps:url screen="ForgotPassword"
home="public"/>'><wps:text key="link.password" bundle="nls.engine"/></a>
</td>
</wps:if>
--%>
<%-- selfcare button --%>
<%--
<wps:if loggedIn="yes" notScreen="SelfcareUserForm,SelfcareUserConf" portletSolo="no">
<td class="wpsToolBar" valign="middle" align="<%=bidiAlignRight%>" nowrap>
<a class="wpsToolBarLink" href='<wps:url command="PrepareSelfcare"
reqid="no"/>'><wps:text key="link.selfcare" bundle="nls.engine"/></a>
</td>
</wps:if>
--%>
<%-- enroll button --%>
<%--
<wps:if loggedIn="no">
<%
String dt = com.ibm.wps.puma.UserManager.instance().getDirectoryType();
if (dt==null)
{
dt = "";
4. Edit the login button section as seen in Example 7-18 on page 319 for each
theme used.
5. Save and close the file.
6. Open and save the version of Default.jsp found in the root of the html
directory and corresponding theme directory (if they exist).
c:/ibm/WebSphere/AppServer/installedApps/wpwin1/wps.ear/wps.war/themes/html
/Default.jsp
This is necessary to make the application server recompile the JSP pages in
order to have the changes take effect (touch operation).
320 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
To (Reverse Proxy node hostname):
WpsHostName=wswin1.itso.ral.ibm.com
3. Save and close the file.
4. Execute the wpsconfig.bat command to load the configuration changes:
a. Open a command window and navigate to the following directory:
c:\IBM\WebSphere\PortalServer\config
b. Execute the wpsconfig command:
wpsconfig httpserver-config
5. Restart the WebSphere_Portal application server.
Note: The syntax of the user create command for Tivoli Access Manager
is:
user create -gsouser <user_name> <user_dn> <common name> <surname>
<password>
Tip: The user password chosen has to conform to the Tivoli Access
Manager password policy. It requires a minimum length of eight characters
formed by at least four alphabetical characters and one non-alphabetical
character with no more than two repeated characters. The password policy
can be changed on a user base or global base. For more information refer
to the Base Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1360 product guide.
The SrvSslCfg command also creates the user who is specified as <was_id> and
inserts this user in the following Tivoli Access Manager LDAP groups:
cn=remote-acl-users
cn=SecurityGroup,secauthority=Default
Note: We found that the Java Runtime Environment included with IBM
WebSphere Application Server V5.0.2.3 (Base) is incompatible with the
SvrSslCfg command. For this reason, we installed the Tivoli Access Manager
Java Runtime Environment V1.3.1 and configured the Tivoli Access Manager
Runtime to use the standalone IBM JRE V1.3.1.
322 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
1. Open a command window on the Portal Server node.
2. In our example, we created a command file named wpwin1_svrsslcfg.bat (see
Example 7-19) in the c:\6325code\config\wps directory of the ITSO sample
code containing the SvrSslCfg command and parameters for the ITSO
environment. In Example 7-19 <password> needs to be updated with the
correct sec_master password.
Note: The value is user defined. In our example, we entered amwas for
the <was_id>.
When the SvrSslcfg command completes, you should see the message:
The configuration completed successfully.
3. To verify that the SvrSslCfg command worked properly, do the following:
a. Open a command window on the Policy Server node.
b. Enter the following command to log in to pdadmin:
pdadmin -a sec_master -p <password>
c. Enter the following command to list the servers defined in Tivoli Access
Manager:
server list
You should see the newly created server amwas-wpwin1, where amwas is
the appsvr_id and wpwin1 is the host name of the Portal Server node
(WebSphere Application Server is installed).
324 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
1. Modify ConfigService.properties.
a. Navigate to the following directory on the Portal Server node:
c:\ibm\WebSphere\PortalServer\shared\app\config\services
b. Modify the ConfigService.properties file as follows:
execute.portal.jaas.login=true
c. Save and close the file.
2. Modify callbackheaderslist.properties.
a. Navigate to the following directory on the Portal Server node:
c:\ibm\WebSphere\PortalServer\shared\app\config
b. Modify the callbackheaderslist.properties file as follows by uncommenting
the following entries:
header.1=iv-user
header.2=iv-creds
c. Save and close the file.
3. Modify ExternalAccessControlService.properties.
a. Navigate to the following directory on the Portal Server node:
c:\ibm\WebSphere\PortalServer\shared\app\config\services
b. Modify the ExternalAccessControlService.properties file as follows:
externalaccesscontrol.pdurl=file:///c:/ibm/WebSphere/AppServer/java/jre/
PdPerm.properties
c. Save and close the file.
Ensure server1 on the Portal Server node is running and then enter the
following to execute the JACL command script:
cd \ibm\WebSphere\AppServer\bin
Note: This section describes how to create four new JAAS Login Modules that
add Tivoli Access Manager specific subclasses of java.security.Principal to
the WebSphere Portal JAAS subject.
326 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
• Authentication Strategy: Select REQUIRED.
f. From the JAAS Login Modules page, click the following under Module
Classname:
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
g. Click Custom Properties in the Additional Properties section.
h. Click New.
i. From the New Custom Properties page, enter the following and then click
OK:
• Name: delegate
• Value: com.ibm.wps.sso.WebSealLoginModule
4. Add the com.tivoli.mts.PDLoginModule to the Portal_Login Application Login
Configuration.
a. From the WebSphere Application Server Administrative Console, select
Security → JAAS Configuration → Application Logins.
b. From the Application Login Configuration page, click Portal_Login.
c. From the Portal Login page, click JAAS Login Modules in the Additional
Properties section.
d. From the JAAS Login Modules page, click New.
e. From the New JAAS Login Modules page, enter the following and then
click OK:
• Module Classname:
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
• Authentication Strategy: Select REQUIRED.
f. From the JAAS Login Modules page, click the following under Module
Classname (ensure that you click the second listed module)
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
g. Click Custom Properties in the Additional Properties section.
h. Click New.
i. From the New Custom Properties page, enter the following and then click
OK:
• Name: delegate
• Value: com.tivoli.mts.PDLoginModule
If you were to now navigate to the Application Login Configuration →
Portal_Login → JAAS Login Modules page, you should see something
similar to Figure 7-11.
Note: Even though the JAAS Login Modules have the same module
classname, they still are unique given their Name:Value pair in Custom
Properties.
328 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
d. From the JAAS Login Modules page, click New.
e. From the New JAAS Login Modules page, enter the following and then
click OK:
• Module Classname:
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
• Authentication Strategy: Select REQUIRED.
f. From the JAAS Login Modules page, click the following under Module
Classname:
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
g. Click Custom Properties in the Additional Properties section.
h. Click New.
i. From the New Custom Properties page, enter the following and then click
OK:
• Name: delegate
• Value: com.ibm.wps.sso.WebSealLoginModule
6. Add the com.tivoli.mts.PDLoginModule to the Portal_SubjectRebuild
Application Login Configuration.
a. From the WebSphere Application Server Administrative Console, select
Security → JAAS Configuration → Application Logins.
b. From the Application Login Configuration page, click
Portal_SubjectRebuild.
c. From the Portal_SubjectRebuild page, click JAAS Login Modules in the
Additional Properties section.
d. From the JAAS Login Modules page, click New.
e. From the New JAAS Login Modules page, enter the following and then
click OK:
• Module Classname:
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
• Authentication Strategy: Select REQUIRED.
f. From the JAAS Login Modules page, click the following under Module
Classname (ensure that you click the second listed module).
com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
g. Click Custom Properties in the Additional Properties section.
h. Click New.
Note: Even though the JAAS Login Modules have the same module
classname, they still are unique given their Name:Value pair in Custom
Properties.
7. Click Save.
330 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
8. When the Save to Master Configuration page appears, click Save.
9. Click Logout.
Normally, we would now restart the WebSphere_Portal application server.
However, we will defer this task until after we modify the WebSphere Portal
configuration files.
## ---------------------------------------
## Access Manager configuration
## ----------------------------------------
## Provide the root of your Protected Object Space for Portal Server entries
externalaccesscontrol.pdroot=/WPSv5
## Specify the location of the Access Manager propeties file for PDJRTE
## This URL must be in the format file:///<path to properties file. http://
## urls are not supported.
externalaccesscontrol.pdurl=file:///c:/IBM/WebSphere/AppServer/java/jre/PdPerm.properties
## (optional) Specify whether to create ACLs in Access Manager for roles stored externally
## If this value is set to false, the Access Manager administrator will be responsible
## for all ACL linkages between TAM and WP
## values:
## true - if an TAM ACL will be created for EVERY resource
## false - if no ACLs will be created for WP objects
externalaccesscontrol.createAcl=true
## (optional) Specify the action group and the customized actions to map to Portal
## role membership. If these items do not exist, they will be created at startup
## default values:
## externalaccesscontrol.pdactiongroup=[WPS]
## externalaccesscontrol.pdAction=m
externalaccesscontrol.pdactiongroup=[WPS]
332 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
externalaccesscontrol.pdaction=m
Modify AccessControlConfigService.properties
To modify the AccessControlConfigService.properties file, do the following:
1. Navigate to the <wp_home>/shared/app/config/services directory.
2. Make a backup copy of the AccessControlConfigService.properties.
3. Modify the following value in the AccessControlConfigService.properties file:
accessControlConfig.enableExternalization=true
4. Save and close the file.
Note: Some of the values in Example 7-21 are wrapped to the following
line.
Modify AccessControlDataManagementService.properties
To modify the AccessControlDataManagementService.properties file, do the
following:
1. Navigate to the <wp_home>/shared/app/config/services directory.
2. Make a backup copy of the
AccessControlDataManagementService.properties file.
3. Modify the following values in the
AccessControlDataManagementService.properties file:
accessControlDataManagement.enableNestedGroups=false
accessControlDataManagement.cacheTimeout=30
4. Add the following entries at the bottom of the file if they do not exist:
accessControlDataManagement.externalizeAllRoles=false
accessControlDataManagement.createAdminMappingXMLAccess=true
334 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: Explanation of parameters:
cacheTimeout: Portal Access Control maintains caches for better
performance of requests. When a role mapping is changed in the
external system, Portal Access Control does not know about these
changes unless the affected user(s) logs out and in again. This property
automatically invalidates the Portal Access Control caches after the
given time (in seconds).
externalizeAllRoles: This property is only applicable for externalization
of resources through the user interface. If the property is set to false
and a resource is externalized, the following happens:
a. The resource and all descendants of this resource that are not
private and not externalized so far are externalized.
b. The roles (and the role mappings) that exist on all resources that
were identified in the previous step are written into the external
security manager object space.
c. For the root resource that was chosen to be externalized, a role
mapping for the Administrator role for the executing user is created
in the external security manager object space.
If this property is set to true, then in addition to the three steps above,
roles are created in the external security manager object space for all
action sets for the root resource that have not already been created in
steps b and c.
createAdminMappingXMLAccess: This property is only applicable for
externalization of resources through XMLAccess. If the property is set
to false and a resource is externalized, the following happens:
a. The resource will be externalized.
b. The roles that exist (and the role mappings) on the resource are
written into the external security manager object space.
If the property is set to true, then in addition to the two steps above a
role mapping for the Administrator role is created for the executing user
in the external security manager object space.
enableNestedGroups: Tivoli Access Manager V5.1.0.2 does not
support nested groups. WebSphere Portal V5.0.2 does support nested
groups, but due to the Tivoli Access Manager limitation we must set this
to false (do not use nested groups).
To reorder the role names when listed, do the following on the Portal Server
node:
1. Navigate to the <wp_home>/shared/app/config/services directory.
2. Make a backup copy of the
AccessControlDataManagementService.properties file.
3. Modify the AccessControlDataManagementService.properties file as follows:
accessControlDataManagement.reorderRoleNames=true
If the property does not exist, add it.
4. Save and close the file.
5. Restart the WebSphere_Portal application server.
336 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
To confirm this, execute the following commands in a pdadmin session on the
Reverse Proxy node:
1. Open a command window and log in to pdadmin:
pdadmin -a sec_master -p <password>
2. Verify the /WPSv5 objectspace has been created by entering the following
command:
objectspace list
You should see the/WPSv5 objectspace in the list.
3. Verify the WPS action group has been created by entering the following
command:
action group list
You should see the WPS action group in the list.
4. To verify that the portal administrator has the Administrator role, view the ACL
for the namespace entry representing the
Administrator@VIRTUAL/EXTERNAL ACCESS CONTROL_1 role by
entering the following command on the pdadmin command line:
acl show WPSv5_Administrator-VIRTUAL_wps-EXTERNAL_ACCESS_CONTROL_1
You should see the following new entry:
User wpsadmin [WPS]m
We will use the YourCo Financial page to illustrate, by example, the behavior of
an externalized resource when externalaccesscontrol.createAcl=true. The
YourCo Financial page will have the Administrator and Privilaged User roles
assigned. Each resource and role combination will have a seperate object and
ACL created in Tivoli Access Manager. In the example of the YourCo Financial
page, the following objects and ACLs will be created as a result of externalizing
the page resource:
Objects:
– /WPSv5/CONTENT_NODE_yourCo.Financial_6_0_69@Administrator
– /WPSv5/CONTENT_NODE_yourCo.Financial_6_0_69@Privileged User
ACLs:
– WPSv5_CONTENT_NODE_yourCo-Financial_6_0_69-Administrator
– WPSv5_CONTENT_NODE_yourCo-Financial_6_0_69-Privileged-User
Important: When you externalize the roles for a resource, any access control
inheritance from internally controlled parent resources is severed (that is, the
external resource no longer inherits role assignments from the internalized
parent resource). Since, for most resources, the Administrator Role Type is
inherited, it would be lost when a resource is externalized. Access controls
that are explicitly defined will be preserved when externalized.
338 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table 7-7 defines the YourCo Financial resource permission assignments
defined within WebSphere Portal. As part of the example for externalizing the
YourCo Financial pages resource, we will need to explicitly define the permission
assignments for the pages due to the inheritence being severed.
YourCo wpsadmins
Financial
Home wpsadmins All authenticated anonymous
portal users portal user
340 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 7-14 YourCo Financial Resource Permissions
8. Figure 7-15 on page 342 shows all the possible roles that can be defined for
the YourCo Financial pages resource, and is used to determine which users
or groups belong to a role.
Since role assignments are not inherited for the resource when externalized,
you will need to check all the current role assignments. The inherited role
assignments will need to be defined explicitly.
In our example, we have the following roles:
– Administrator
– Security Administrator
– Delegator
– Manager
– Editor
– Privileged User
– User
The following procedure demonstrates how to examine a role assignement
for the User role. This should be performed for each role listed.
a. Click the pencil icon in the Edit Role column for the User role.
b. In the case of User role, there are no role assignments. Click Done.
9. Privileged User role assignment (see Table 7-7 on page 339 for a role
assignment summary).
The Privileged User role assignments for the all authenticated portal users
group were explicitly assigned by default, and thus do not need to be modified
for each of the following pages: Home, My Account, Company Info, Sales,
Customer Support.
10.User role assignment (see Table 7-7 on page 339 for a role assignment
summary).
The User role assignment for the anonymous portal user was explicitly
assigned by default, and thus does not need to be modified for each of the
following pages: Home, Company Info, Sales, Customer Support.
11.Once you are done reviewing the permissions, navigate up the page tree to
Root → Content Root → MyPortal.
12.Click the right-facing arrow in the Externalize/Internalize column.
13.You will be prompted Are you sure you want to place the resource under
External Access Control? Click OK for the process to begin.
When complete, you should see the following message:
APRV4012I: Resource successfully externalized.
342 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
14.Click Done. The arrow in the Externalize/Internalize column is not updated
until you click Done and reopen this resource (see Figure 7-16).
Note: If you are running WebSphere Portal 5.0.2.1, you may see an
additional role:
Administrator@CONTENT_NODE_yourCo.Financial_6_0_69
344 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
5. To verify that the ACLs where created properly within Tivoli Access Manager,
do the following:
a. From the Web Portal Manager, click ACL → List ACL.
b. You should see something like Figure 7-18. For verification purposes, click
WPSv5_CONTENT_NODE_yourCo-CompanyInfoPage_6_0_6C-User.
c. You should see something like Figure 7-19 on page 346, which should
display the unauthenticated and any other entry type.
346 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
a. Enter the following URL to access the unauthenticated portal page:
http://wswin1.itso.ral.ibm.com/portal/wps/portal
b. Click YourCo Financial.
You should see the navigation tabs for the Home, Company Info, Sales
and Customer Support pages.
The Credential Service contains objects that handle Basic Authentication, LTPA
Token authentication, and simple form-based user ID/password login challenges.
Credentials can take their input identity from the portlet configuration or from the
Credential Vault service. Portlet developers can use the credential vault service
The Credential Vault is a portal service that helps portlets and portal users
manage multiple identities. The Credential Vault stores credentials that allow
portlets to log in to applications outside the portal realm on behalf of the user.
WebSphere Portal provides one simple database vault implementation for
mappings to secrets for other enterprise applications. By default, the Credential
Vault contains an administrator-managed vault segment and a user-managed
vault segment. Administrator-managed vaults allow users to update mappings;
however, users cannot add new applications to this vault.
To configure the WebSphere Portal Credential Vault for use with Tivoli Access
Manager, do the following on the Portal Server node:
1. Ensure that you have completed the steps in 7.6.1, “Configure the SSL
between WebSphere and TAM” on page 322.
2. Navigate to the <wp_home>\shared\app\config\services directory.
3. Make a backup copy of the VaultServices.properties file.
4. Add the definitions to the types value in the VaultServices.properties file, as
seen in Example 7-22.
348 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
accessmanager.manageresources=true
accessmanager.readonly=false
350 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. Click Administration.
4. Click Access → Credential Vault.
5. Create the Vault Segment.
a. Click Add a vault segment.
b. Enter the following values and click OK:
• Vaults: Select accessmanager(0).
• Vault segment name: WPS-TAM segment
6. Create the Vault Slot.
a. Click Add a vault slot.
b. Enter the following values and click OK:
• Vault: Select accessmanager.
• Name: WPS-TAM Vault Slot
• Vault Segment: Select WPS-TAM segment.
• Vault resource associated with vault slot: Click new radio button and
enter: WPS-TAM GSO Resource
7. Click Log out.
8. Verify that the GSO resource is created in the TAM database:
a. Open a command window on the Policy Server node.
b. Enter the following command to log in to pdadmin:
pdadmin -a sec_master -p <password>
c. Enter the following command to list servers defined in Tivoli Access
Manager:
rsrc list
You should see the newly created resource WP-TAM GSO Resource.
352 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
• Name: vault_test
• Password: passw0rd
You should see the message:
Congratulations, your Credential Vault integration was successful!
Note: At this point, the credential vault integration has not actually been
proven succesful. We have just confirmed that we can authenticate to our
test realm on the Web server with our test user.
13.Click Finish.
354 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4. Select the test portlet and click OK.
5. Click Done.
2. Copy the vault-test-acl.pd command file to the c:\temp directory on the Policy
Server node.
3. Open the file and change the <dummy_password> value to a new password.
4. Save and close the file.
5. Open a Windows command window (not pdadmin).
6. From the Windows command line, change to the directory of the
vault-test-acl.pd and enter the following command:
pdadmin -a sec_master vault-test-acl.pd
7. When prompted for the password, enter the sec_master password.
Note: Running the command will change the password in TAM for the
vault_test user from passw0rd to a dummy password.
8. Return to your Web browser, hold down the Shift key, and click the Refresh
button on the browser.
This section includes the following tasks to configure WebSphere Portal and
WebSEAL session timeouts:
Modify the WebSphere Portal session timeout.
Configure WebSphere Portal to resume timed out sessions.
Modify the WebSEAL session timeout.
356 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Modify the WebSphere Portal session timeout
Modify the WebSphere Portal session timeout values on the Portal Server node
from the WebSphere Application Server Administrative Console, as follows:
1. Ensure the server1 application server is started. If not, start the server as
follows:
cd \ibm\WebSphere\AppServer\bin
startServer server1
2. Start the WebSphere Application Server Administration Console by entering
the following URL in a Web browser:
http://<was_hostname>:9090/admin
3. Log on to the WebSphere Administration Console (for example, wpsbind).
4. Click Servers → Application Servers.
5. Click WebSphere_Portal.
6. Click Web Container.
7. Click Session Management.
8. From the Session Management Configuration page, modify the following
setting and then click OK:
Session timeout:
– Select Set timeout.
– Minutes: 25 (default 30)
9. Click Save.
10.When the Save to Master Configuration page appears, click Save.
11.Log out and close the WebSphere Administrative Console.
12.The WebSphere_Portal application server needs to be restarted for this
change to take effect. If you plan on performing the steps in “Configure
WebSphere Portal to resume timed out sessions” on page 357, the restart
can be defered until after that task is complete.
358 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: The inactive-timeout value should not exceed the WebSEAL
timeout value (located above the inactive-timeout value in the .conf file).
By default, timeout = 3600 seconds. Simply increase the timeout value
to be equal to or greater than the inactive-timeout value.
When implementing the test nodes in the environment, we will note the unique
settings and reference the procedures found in Chapter 6, “Install the runtime
environment” on page 175; and Chapter 7, “Configure the runtime environment”
on page 259.
We would like to highlight a few key points regarding the ITSO development
enviornment.
Although Figure 8-1 displays four physical nodes, we used VMWare for the
Policy Server node and Reverse Proxy node test nodes.
The Development node includes WebSphere Studio Application Developer,
Portal Toolkit, and Test Environment, and is the primary node for
development.
The Reverse Proxy node is optional, and only needed if you plan on testing
authentication using the WebSEAL within the development environment.
362 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The Repository node is optional, and in our example hosts the CMS system
for source control management.
Note: The Reverse Proxy node is optional unless you plan on testing
authentication in your development environment testing needs.
– VMWare image
• 1 CPU, Intel Pentium 4 1,8 GHz
• 150 MB main memory
• 5 GB harddisk
• 1 AMD PCNET Ethernet Adapter
• Hostname: wsdev1.itso.ral.ibm.com
Development node
– IBM Thinkpad T30 (2366-DG3)
• 1 CPU, Mobile Intel Pentium 4-M 1,8 GHz
• 1024 GB main memory
• 27 GB harddisk
• 1 IBM Ethernet Adapter
• Hostname: wpdev1.itso.ral.ibm.com
CVSNT 2.0.4
364 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Software Version
8.1.4 VMWare
Within the development environment, we implemented the Reverse Proxy node
and Policy Server node in VMware images. This allowed for greater flexability,
including the capability to run the Development node (WebSphere Studio
Application Developer and portal toolkit), Reverse Proxy node, and Policy Server
node on the same physical system with 2 GB of RAM.
We have listed the unique settings for the Policy Server node for the
development environment:
Policy Server node hostname in the development environment:
tamdev1.itso.ral.ibm.com
Policy Server node WebSphere Application Server node name tamdev1
(used by the Web Administration Tool and Web Portal Manager).
366 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: In the development environment we have, in general, weaker
requirements concerning security than in the runtime environment, since all
development activities are usually done in the same network zone with
internal resources, and maybe even internal subnets that are sealed anyway
from the outside. However, if we want to develop applications that modify the
security settings of our runtime environment, we need to test them in the
development environment to supply a thorough development process.
For the reasons mentioned above, we will set up the WebSEAL and Tivoli
Access Manager configuration only with regards to development, not
necessarily security. We have so far set up the different components as in the
runtime environment. Now we have to configure the security settings.
For details on implementing the Reverse Proxy node, refer to 6.3, “Implement the
Reverse Proxy node” on page 218. Within the development environment, we
installed the Reverse Proxy node in a VMWare image.
We have listed the unique settings for the Reverse Proxy node for the
development environment:
Reverse Proxy node hostname in the development environment:
wsdev1.itso.ral.ibm.com
Tivoli Access Manager - WebSEAL configuration
The Access Manager Policy Server is installed on another machine:
– Host name: tamdev1.itso.ral.ibm.com
– Listening port: 7135
When the LDAP Server information appears, we entered the following:
– LDAP host name: tamdev1.itso.ral.ibm.com
– LDAP port number: 389
In the configuration for the Access Manager WebSEAL enter the following for
the hostname:
– WebSEAL instance name: default
– WebSEAL Server Information hostname: wsdev1
All settings (except the hostnames above) are the same as in the runtime
environment.
The Development node is used as the workbench to create and test the portlet
and J2EE applications. The primary components of the Development node are
the WebSphere Studio Application Developer, WebSphere Portal toolkit ,and
portal server test environment. The Development node in our environment will
integrate with the Policy Server node running Tivoli Access Manager Policy and
Authorization Servers, and the Tivoli Directory Server and the Reverse Proxy
node running the Tivoli Access Manager WebSEAL. Optionally, the Development
node can be configured to use the Repository node where CVS is installed.
This section includes the following task to implement the Development node:
1. Windows 2000 installation.
2. WebSphere Studio Application Developer V5.1.1 installation.
3. WebSphere Studio Application Developer V5.1.1 Interim Fix 002 installation.
4. WebSphere Studio Application Developer - WebSphere Test Environment
fixpack installation.
5. WebSphere Portal Toolkit and test environment installation.
6. Verify the Portal Toolkit and Test Environment installation.
7. Java Runtime Environment (JRE) V1.3.1 installation.
8. Tivoli Access Manager Java Runtime Environment installation.
9. Configure the SSL between the WTE and TAM.
10.Verify the TAM configuration within WebSphere Studio.
11.CVS client configuration for WebSphere Studio.
Note: The procedure documented in this section assumes that you have a
clean Windows environment. If you had installed a previous version of
WebSphere Portal toolkit and it was not properly removed, the installation may
fail.
368 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
8.5.1 Windows 2000 installation
This section highlights the key issues addressed when installing Microsoft
Windows 2000 Professional or Microsoft Windows 2000 Sever.
Note: The installation guide for the WebSphere Portall toolkit V5.0.2 states as
a requirement the operation system Microsoft Windows 2000 Professional
with Service Pack 2 or later. In our scenario we used Windows 2000
Professional with Service Pack 4.
8. When the Installation Summary window appears, review the information and
then click Next to begin copying files.
370 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
9. When the installation is complete you should see a message stating The
InstallShield Wizard has successfully installed IBM WebSphere Studio
Application Developer V5.1.1. Click Finish.
10.When the WebSphere Studio Installatation Launchpad main window appears,
click Exit.
11.Verify that WebSphere Studio Application Developer V5.1.1 installed
correctly.
a. Start WebSphere Studio Application Developer by clicking Start →
Programs → IBM WebSphere Studio → Application Developer 5.1.1.
b. When you start WebSphere Studio the first time, you will be prompted for
the workspace directory. Do the following and then click OK.
• Change the default location for the workspace to a shorter directory
name (for example, c:\ibm\workspace).
• Uncheck “Use this workspace as the default and do not show this
dialog box again”.
Note: If you have problems downloading the file, search for Interim Fix
002 for WebSphere Studio Application Developer v5.1.1 on the
WebSphere Portal support page at:
http://www.ibm.com/software/genservers/portal/support/
372 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7. When the Preview window for the Interim Fix 002 for WebSphere Studio
Application Developer 5.1.1 appears, check Install by adding to the
selected updates. The fix will now appear in the Selected Updates window,
as seen in Figure 8-4.
Figure 8-4 Install by adding selected updates for Interim Fix 002
To run the batch file to correct the uninstallation information, do the following:
1. Download the WebSphere Portal Toolkit V5.0.2.1 (PortalToolkit5021MP.exe)
from the following URL to a temporary directory (for example, c:\temp):
http://www.ibm.com/websphere/portal/toolkit
2. Ensure that WebSphere Studio Application Developer is not running.
3. Start the WebSphere Portal Toolkit self-extracting installer by running
PortalToolkit5021MP.exe from the temporary download directory (c:\temp).
4. When prompted, enter the directory to which you want to extract the
WebSphere Portal Toolkit (for example, c:\temp\PortalToolkit5021), and then
click Next.
5. When Portal Toolkit V5.0.2.1 Installer starts automatically, click Cancel to the
installation. In this case, we simply wanted to extract the Portal Toolkit files to
get access the the fixWTE_forCF.bat script file.
6. Open the command window and navigate the to directory you unpacked the
toolkit (for example, c:\temp\PortalToolkit5021).
374 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7. Run the following script file to fix the WebSphere Studio Application
Developer WebSphere Test Environment:
fixWTE_forCF.bat <wsad_home>\runtimes\base_v5
Where <wsad_home> is the directory where WebSphere Studio Application
Developer is installed.
Note: The WebSphere Portal Support Web site requires you to log in as a
registered user (or register first). Once you navigate to the download page you
will see a listing of many fixes. We downloaded the following file: WAS 5.0.2.3
Fixes (WAS5023CumulativeWindows.zip).
The readme file for WebSphere Portal V5.0.2 Cumulative Fix 1 (V5.0.2.1) can
be found at:
http://publib.boulder.ibm.com/pvc/wp/5021/ent/en/readme/install.html
376 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: Normally, you would need to download the efixes individually
from the WebSphere Application Server Support Web site. However,
there is a file located on the WebSphere Portal Support Web site that
includes all of these efixes and targets, specifically WebSphere
Application Server 5.0.2.3 for Windows.
When you access the above URL, you will first need to click the Portal
Server 5.0 Fix pack 2 link. Next you will need to log in (or register). You
will then see a WAS 5.0.2.3 fixes link to download the fixes
(WAS5023CumulativeWindows.zip).
– Alternatively, download the fixes listed in Table 8-5 individually from the
WebSphere Application Server V5 Support site at:
http://www-306.ibm.com/software/webservers/support.html
2. Unpack the efixes download (WAS5023CumulativeWindows.zip) to a
temporary directory (for example, c:\temp\was5023.fixes).
3. Open a command window and navigate to the directory you have extacted
the fixes (for example, c:\temp\was5023.fixes).
4. Set the JAVA_HOME environment as follows:
set JAVA_HOME=<wsad_home>\runtimes\base_v5\java
Where <wsad_home> is the WebSphere Studio Application Developer
installation directory.
5. To start the WebSphere Update Installer, run updateWizard.bat from the
command window.
6. When the WebSphere Update Installer language window appears, select the
appropriate language for the wizard (for example, English) and then click OK.
7. When the Welcome window appears, click Next.
8. The WebSphere Update Installer will attempt to detect the current
WebSphere Application Server version. In our example, it did not detect the
WebSphere Application Server location. We manually entered the target
installation directory c:\ibm\wsad\runtimes\base_v5 and then clicked Next.
9. Select Install fixes and then click Next.
10.Enter the directory where you have copied the fixes. For example, we entered
c:\temp\was5023.fixes\efixes in the Fix directory text field, and then clicked
Next.
11.When the window appears with a list of fixes, only select the six fixes listed in
Table 8-5, and then click Next.
PQ81248
PQ81416
WAS_Adapter_10-30-2003_5.0.2_cumulative_Fix
WAS_CM_08-12-2003_5.0.2-5.0.1_cumulative_Fix
WAS_Dynacache_01-30-2004_5.0.2_cumulative
WAS_Security_12-13-2003_5.0.2.3-5.0.2.2-5.0.2.1-5.0.2-5.0.1-5.0.0_JSSE_cumulativ
e_Fix
12.On the install summary page, review the fixes to be installed or refreshed and
then click Next to begin the installing the fixes.
13.When the WebSphere Application Server V5.0.2.3 Fixes installation is
complete, click Finish.
Note: For more detailed information on the Portal Toolkit V5.0.2.1 and Test
Environment installation, refer to the Installation Guide, WebSphere Portal
Toolkit V5.0.2.1.
378 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
4. Download the WebSphere Portal Toolkit V5.0.2.1 (PortalToolkit5021MP.exe)
from the following URL to a temporary directory (for example, c:\temp):
http://www.ibm.com/websphere/portal/toolkit
5. Start the WebSphere Portal Toolkit self-extracting installer by running
PortalToolkit5021MP.exe from the temporary download directory (c:\temp).
6. When prompted, enter the directory to which you want to extract the
WebSphere Portal Toolkit (for example, c:\temp\PortalToolkit5021), and then
click Next.
7. When the WebSphere Update Installer language window appears, select the
appropriate language for the wizard (for example, English), and then click
OK.
8. When the Welcome window appears, click Next.
9. When the Software License Agreement window appears, review the terms
and, if in agreement, select I accept the terms in the license agreement,
and then click Next.
10.When the Select Components to Install window appears, check the following
and then click Next:
– Check Portal Toolkit V5.0.2.1.
– Check WebSphere Portal V5.0 for Test Environment.
11.When the Portal Toolkit Summary window appears, review the installation
options and then click Next to start installing files.
12.When the Path Information to the WebSphere Portal installer window
appears, insert the WebSphere Portal Server CD #2. Browse to the
<cd_root>\wps directory containing the wpsinstall.jar file (for example,
WebSphere Portal V5.0 installer f:\wps\wpinstall.jar, where f: is the CD Rom
drive). Click Next.
13.When the WebSphere Portal V5.0 for Test Environment Summary page
appears, review the settings and click Next.
14.When the installation is complete, click Finish.
15.Start WebSphere Studio Application Developer by clicking Start →
Programs → IBM WebSphere Studio → Application Developer 5.1.1.
16.The first time you start WebSphere Studio Application Developer after the
fixpack and toolkit installation, you will be prompted to apply changes that
have been made to the configuration. Accept those changes by clicking
Finish.
17.You will be prompted to restart of the workbench.
We found that if the Portal Toolkit and Test Environment installation failed, we
had to do the following for it to correctly install afterwards:
Uninstall the Portal Toolkit from the Windows Add remove programs.
Delete the <wsad_home>\runtimes\portal_v50 and
<wsad_home>\PortalToolkit directories.
Rename the vpd.properties file found in the \winnt directory.
Search the Windows registry for WebSphere Portal and delete the entries
found.
Restart the system.
Close all other applications to reduce memory usage and retry the
installation.
For more information on Portal Toolkit V5.0.2.1 installation failures, refer to the
Troubleshooting section in the Installation Guide, WebSphere Portal Toolkit
V5.0.2.1 product guide.
380 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
b. Select Portlet Development → Portlet Application Project and then
click Next.
c. When the Define a Portlet Project window appears, enter the following and
then click Finish:
• Project name: ITSOPortletTest
• Select Create basic project.
d. When prompted with the message This kind of project is associated
with the Portlet Perspective. Do you want to swith to this
perspective, click Yes.
3. Run the newly created portlet in the Test environment.
a. Select ITSOPortletTest.
b. Right-click Run on Server.
c. When the Server Selection window appears, enter the following and then
click Finish:
• Select Create a new server.
• Server Type: Select WebSphere Portal v5.0 Test Environment.
You should see server messages in the console view as the server starts.
After the server starts, a Web browser will open showing a page with the
portlet.
3. Afer the command has completed, verify that the PolicyDirector directory has
been created in the c:\ibm\wsad\runtimes\base_v5\java\jre directory. Also,
verify that the PdPerm.properties file has been created in the same directory.
382 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: The Java Runtime Environment included with IBM WebSphere Studio
Application Developer WebSphere Test Environment (V5.0.2.3) is
incompatible with the SvrSslCfg command (used in 7.6.1, “Configure the SSL
between WebSphere and TAM” on page 322). For this reason, we installed the
Tivoli Access Manager Java Runtime Environment V1.3.1 and configured the
Tivoli Access Manager Java Runtime Environment (PDJRTE) to use the
standalone JRE V1.3.1.
The SrvSslCfg command also creates the user who is specified as <was_id>,
and inserts this user in the following Tivoli Access Manager LDAP groups:
cn=remote-acl-users
cn=SecurityGroup,secauthority=Default
Note: We found that the Java Runtime Environment included with IBM
WebSphere Application Server V5.0.2.3 (WebSphere Test Environment) is
incompatible with the SvrSslCfg command. For this reason, we installed the
Tivoli Access Manager Java Runtime Environment V1.3.1 and configured the
Tivoli Access Manager Runtime to use the standalone IBM JRE V1.3.1.
Note: The ITSO sample code includes the wpdev1_svrsslcfg.bat file found
in the c:\6325code\config\wps directory, which can be modified with the
appropriate values for your environment and then run.
When the SvrSslcfg command completes, you should see the message:
The configuration completed successfully.
3. To verify that the SvrSslCfg command worked properly, do the following:
a. Open a command window on the Policy Server node.
b. Enter the following command to log in to pdadmin:
pdadmin -a sec_master -p <password>
c. Enter the following command to list servers defined in Tivoli Access
Manager:
server list
You should see the newly created server wps-wpdev1, where wps is the
appsvr_id and wpdev1 is the host name of the Development node.
384 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
To create a test portlet to verify the Tivoli Access Manager API in the WebSphere
Test Environment, do the following:
1. Start WebSphere Studio Application Developer on the Development node.
2. First you have to make the libraries available to the project:
a. In the workbench, select your project and select Project → Properties →
Java Build Path.
b. Click the Libraries tab.
c. Click Add Variable.
d. Select WAS_50_PLUGINDIR from the list and click extend.
e. Navigate to the directory java/jre/lib/ext and select the file PD.jar. Click
OK.
f. Click OK and exit the property configuration.
3. Navigate to the ITSOPortletTest → Java Resources → itsoportlettest.
Where ITSOPortletTest is the test portlet project created in 8.5.6, “Verify the
Portal Toolkit and Test Environment installation” on page 380.
4. Open the ITSOPortletTest.java and search for the doView() method.
5. Insert the sample code listed in Example 8-1 into the doView () method.
Example 8-1 ITSO code to verify Tivoli Access Manager APIs in WTE
// TAM test configuration - begin
System.out.println("TAM test configuration - begin" );
PDMessages messages = new PDMessages();
try {
PDAdmin.initialize("MyPortlet", messages);
Locale locale = new Locale("ENGLISH", "US");
String admin = "sec_master";
String pw = "its0ral0";
// the file we specified in the connection setup with SvrSslCfg
java.net.URL configUrl = new
java.net.URL("file:///C:/ibm/wsad/runtimes/base_v5/java/jre/PdPerm.properties");
6. After inserting the code we need to import the classes referenced by the
sample code. Select the class, and right-click Source → Organize Imports.
7. Save and close ITSOPortletTest.java.
8. Run the portlet on the server in the test environment and access it through a
browser.
In the console output of WebSphere Studio Application Developer you should
now see some objects from Access Manager, including sec_master and the
development server itself.
Note: The parameter for the connection file location in the code sample above
should be moved inside a configuration file or deployment description of the
Web/portal application, since that location will be specific to the installation.
Now the environment should be ready to develop applications with Tivoli Access
Manager.
386 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Import the LDIF file (wp-itso.ldif) to create users and groups.
Enable LDAP security for WebSphere Portal.
Stop/start servers in WebSphere Test Environment.
Verify the LDAP configuration.
Disable LDAP security in WebSphere Portal.
Note: For more detailed information, refer to the WebSphere Portal V5.0.2
InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/index.html
8.6.2 Import the LDIF file (wp-itso.ldif) to create users and groups
To import the ITSO-provided wp-itso.ldif file to create users and groups to the
Tivoli Directory Server, do the following on the Policy Server node (where Tivoli
Directory Server is installed in our example):
1. Stop the IBM Tivoli Directory Server V5.2 Windows service.
2. Copy the ITSO-provided c:\6325code\config\ldap\wp-itso.ldif file to a
temporary directory where Tivoli Directory Server is installed (for example,
c:\temp).
3. Start the Tivoli Directory Server Configuration Tool by clicking Start →
Programs → IBM Tivoli Directory Server V5.2 → Directory
Configuration.
388 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Example 8-2 ITSO example wpconfig.properties values for LDAP security
Section in Keyword ITSO example value
wpconfig.properties file
WpsHostName wpdev1.itso.ral.ibm.com
PortalAdminIdShort wpsadmin
PortalAdminPwd wpsadmin
PortalAdminGroupId cn=wpsadmins,cn=groups,dc=itso,dc=ibm,dc=com
PortalAdminGroupId wpsadmins
Short
LTPATimeout 120
SSODomainName itso.ral.ibm.com
LDAPPort 389
LDAPAdminUId cn=root
LDAPAdminPwd <password>
LDAPServerType IBM_DIRECTORY_SERVER
LDAPBindID uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com
LDAPBindPassword wpsbind
390 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Section in Keyword ITSO example value
wpconfig.properties file
LDAPUserSuffix cn=users
LdapGroupPrefix cn
LDAPGroupSuffix cn=groups
LDAPUserObjectCla inetOrgPerson
ss
LDAPGroupObjectCl groupOfUniqueNames
ass
LDAPGroupMember uniqueMember
LDAPUserFilter (&(uid=%v)(objectclass=inetOrgPerson))
LDAPGroupFilter (&(cn=%v)(objectclass=groupOfUniqueNames))
LDAPsslEnabled false
Note: Ensure that you have entered the fully qualified hostname (not
localhost).
392 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Tip: There are some things you should be aware of when working with the
security enabled within the WebSphere Studio Application Developer
WebSphere Test Environment:
Using localhost or just the hostname for accessing the portal might cause
problems after configuring LDAP security. Always use the full qualified
hostname for browsing.
For example:
http://wpdev1.itso.ral.ibm.com:9081/wps/portal
There is a difference between the various scripts for starting and stopping
the standalone portal from outside the Application Developer. The
startServer.bat scripts found in the base_v5\bin directory need to get the
credentials passed as parameter, whereas the wpsconfig.bat
start-portal-server command reads the credentials from files that the
setup configured. It is in general more convenient to use the latter. The
same applies to the stop commands.
WebSphere Studio Application Developer has a problem with switching an
existing test server to security. So instead of using the existing server that
has been worked with before enabling LDAP security, you should delete
that server in Application Developer and create a new one. Application
Developer will apply the needed security settings during creation.
c. From the WebSphere Portal Welcome page, click Log in at the top right
corner. Log in as user ID wpsadmin and password.
You should now be able to use the test environment without the LDAP Server.
394 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
9
9.1.1 Architecture
The architecture of the ITSO Bank sample application consists of a presentation
layer that uses an EJB-based layer, which accesses a database layer. Figure 9-1
depicts an overview of the ITSO Bank application architecture.
Presentation Layer
JSPs Portlets
Model
View
Controller
Data Beans
Manager
Session
Facade
EJB Layer
Trans- Entity
Accounts Users
History Beans
Accounts
Database Layer
Presentation layer
The presentation layer is the part of the application that is visible to the user. The
presentation layer consists of portlets, JSPs, and data beans, as well as
additional helper classes if needed.
396 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The ITSO Bank portlets for the presentation layer are as follows:
ITSOUser
The ITSOUser portlet manages users. This portlet will access the LDAP
directory for general user actions and the bank database for more specific
information.
ITSOAccountBalance
The ITSOAccountBalance portlet is used to read and display the account
details.
ITSOTransfer
The ITSOTransfer portlet is used to transfer funds between accounts.
ITSOTransHistory
The ITSOTransHistory portlet is used to show the transaction history.
Each of the four portlets has an associated JSP that defines the basic layout of
the portlet. In addition to JSPs, the portlets have a data bean that encapsulates
the data that is passed between portlet and back-end. Each of the portlets has an
associated view bean that is used to encapsulate the data passed to the JSP.
These view beans are not displayed in the architecture overview diagram seen in
Figure 9-1 on page 396. This is a classical implementation of the
Model-View-Controller pattern, where the data bean is the model, the JSP the
view, and the portlet the controller.
EJB layer
The EJB layer performs the communication and transaction from the portlet to
the database and consists of two sub layers:
Entity beans relating directly to database tables.
A session bean that acts as an implementation of the session façade pattern
to prevent the direct use of the entity bean interfaces. This bean implements
method level security as described in 9.1.3, “Method level security” on
page 400.
The EJB layer contains implementation classes specific to the DB2 database
deployment of the runtime environment. However, throughout this chapter, we
will generate deployment code for the Cloudscape database within the
development environment. We chose to use Cloudscape in the development
environment to lighten the memory requirements of the Development node
system during application development, and thus have a more responsive
Note: The EJB Layer is indeed independent from the database vendor. The
code can be generated for several vendors and included in the project. The
only specific code to a certain implementation is the database binding in the
WebSphere binding files.
Database layer
The database layer consists of the following tables that contain the relevant
information needed for the ITSO Bank sample application:
Users
Accounts
Transhistory
An invocation of the manager session bean will result in the invocation of one or
more entity beans, and therefore read from or write to one or more database
tables. The table information is included in the Table.ddl file that is included in the
EJB project. As part of the application deployment in the runtime environment,
the Table.ddl will be applied manually to the ITSO Bank database. In the
development environment, this task will be performed with wizards available in
WebSphere Studio Application Developer.
Helper classes
The helper classes contained in the portlet archive supports the creation of new
users in the LDAP directory and in Tivoli Access Manager. The helper classes for
LDAP and Access Manager are triggered only from the user portlet and the user
data bean. Note that only the user portlet that uses the Access Manager helper
(TAMHelper) writes to the LDAP directory.
The operations on Access Manager always follow the operations on the LDAP
directory, since the user has to be created in LDAP first, and then the Access
Manager operation can be executed to add additional attributes to the LDAP
directory and register the users in Tivoli Access Manager.
If you want to remove the Access Manager part from the application (for
example, if the environment is not completely set up yet or if you do not desire
those security features), simply uncomment the TAMHelper calls (as shown in
Example 9-1 on page 399) that are used in the ITSOUser.java class. The
application will work exactly the same way, but there will be no users added to the
Tivoli Access Manager users that are allowed to access the general
infrastructure through WebSEAL.
398 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Example 9-1 Disabling the Access Manager import
...
LDAPHelper.addUser(itsoUserBean, log);
// write operation on TAM removed.
//TAMHelper.importUser(itsoUserBean);
...
ITSOBankEAR.ear META-INF/application.xml
ITSOBankEJB.jar
ITSOBankWAR.war WEB-INFf/web.xml
WEB-INF/portlet.xml
WEB-INF/classes
WEB-INF/lib/ITSOBankEJB.jar
com_ibm_itso_bank_portlets/jsp/html
Note: All deployment units also contain the source code. Since the source
code is not needed for the deployment on the runtime, it will not be mentioned
explicitly.
400 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The ITSOManagers role is allowed to execute all remote methods on the
Manager EJB, whereas the ITSOCustomers role is limited to remote methods
listed in Table 9-1.
Table 9-1 Access permissions of the ITSOCustomers role on the manager EJB
Method Triggered by portlet
getAccounts ITSOAccountBalance
getAccountsData ITSOAccountBalance
transfer ITSOTransfer
createTransHistoryData ITSOTransfer
<method-permission>
<role-name>Customer</role-name>
<method>
<ejb-name>Manager</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getAccounts</method-name>
<method-params>
<method-param>java.lang.String</method-param>
</method-params>
</method>
...
</method-permission>
Note: The import of the source code can be done either from the EAR file or
from some previously set up version control system, thus the steps in “Import
the sample projects from CVS” on page 407 are optional if you are not using a
version control system.
Note: For a description of the ITSO sample code and where to download it,
refer to Appendix F, “Additional material” on page 683.
2. Unpack the 6325code.zip file. For example, we unpacked the zip to the
c:\6326code directory.
402 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: WebSphere Studio treats every Web project as part of an enterprise
project, so a plain import of a *.war file in the workbench where only one EAR
project exists will automatically add the Web project in the *.war file to the
EAR project. This is not desired for the ITSOBankEAR project.
To set up the variables, perform the following steps to set the variable values for
each of the variables listed in Table 9-2 on page 404:
1. Select Window → Preferences.
2. From the Preferences window, select Java → Classpath Variables.
3. From the Classpath Variable window, do the following:
– If the variables listed in Table 9-2 on page 404 are present, select the
variable and click Edit to change the value accordingly for your
environment.
Note: The values for the variables mentioned in Table 9-2 are specific to the
installation path for the Development node.
WPS_LIB c:/ibm/wsad/runtimes/portal_v50/shared/app
WPS_TRANS_LIB c:/ibm/wsad/runtimes/portal_v50/IBMTrans/lib
XML_API_LIB c:/ibm/wsad/wstools/eclipse/plugins/com.ibm.etools.xalanrt_2.3.11
WPS_V5_PLUGINDIR c:/ibm/wsad/wstools/eclipse/plugins/com.ibm.wps_v5_5.0.2
WCM_PLUGINDIR c:/ibm/wsad/wstools/eclipse/plugins/com.ibm.wcm.resource.wizards_5.0.0.20
040219_2218
To define the which variables are used by the ITSOBankWAR project, do the
following:
1. Select the ITSOBankWAR project.
2. Select Project → Properties from the menu bar.
3. From the Properties for ITSOBank window, select Java Build Path.
4. Click the Projects tab.
5. From the Java Build Path window for Projects, check the ITSOBankEJB
project.
6. Click the Libraries tab.
7. Add the variable extension.
a. Click Add Variable.
b. Select WAS_50_PLUGINDIR/java/lib/ext/PD.jar and click Extend.
404 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
c. Select wps.jar from the list and click OK.
8. Repeat step 7 for all variables listed in Table 9-3 on page 405.
When all variables have been defined, the ITSOBankWAR project should not
contain any errors and the workbench should look like Figure 9-3 on page 406.
This includes the projects just imported, as well as the portal application project
and default EAR project created when validating the WebSphere Studio
Application Developer installation.
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/java/lib/ext/PD.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/dynacache.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/j2ee.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/ras.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/runtime.jar
WAS_50_PLUGINDIR WAS_50_PLUGINDIR/lib/servletevent.jar
WPS_LIB WPS_LIB/jlog-2.2.1.jar
WPS_V5_PLUGINDIR WPS_V5_PLUGINDIR/portlet-api.jar
WPS_V5_PLUGINDIR WPS_V5_PLUGINDIR/wps.jar
WPS_V5_PLUGINDIR WPS_V5_PLUGINDIR/wpsportlets.jar
Note: When importing the projects from an existing CVS repository, these
variable extensions probably do not need to be performed, since the
.classpath file is checked into CVS (as opposed to the EAR archive).
To share the projects with other developers using CVS, do the following:
1. Open the context menu (right mouse button) on a project and choose
Team → Share Project.
406 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2. Choose the existing repository location and click Next.
3. Choose to use a specific module name and enter the above-mentioned
common prefix in front of the project name (see Figure 9-4).
4. Click Next and Finish to share the project.
You can now switch to the J2EE perspective of WebSphere Studio Application
Developer, set the variables as described in “Define the library variables” on
page 403, and continue working on the project.
Tip: Should you need to delete the Cloudscape database, simply delete the
directory on the file system where the database was created.
408 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Create the EJB mapping for the database
As described in 9.1.1, “Architecture” on page 396, we will use an EJB layer to
connect to the newly created database.
To create the EJB mapping for the newly created itsobank database, do the
following:
1. From WebSphere Studio Application Developer, select J2EE perspective →
J2EE Hierarchy View.
2. Expand the EJB Modules.
3. Select the ITSOBankEJB module.
4. Right-click and select Generate → EJB to RBD Mapping.
5. When the EJB to RDB Mapping window appears, do the following:
a. Select Create a new backend folder and click Next.
b. Select Top Down and click Next.
c. When the Select Top Down Mapping Options window appears, do the
following and then click Finish:
• Target Database: Select Cloudscape, V5.0.
410 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: We found that the wizard would sometimes fail with an error
message stating that the database server could not be started. Running
the wizard again resolved this problem.
Note: It is possible to set up the portal front-end and EJB back-end on the
same server. In this case do not use an URL, as introduced in the
programming example below, when obtaining an initial context for JNDI
lookup. Just use the JNDI name.
412 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
5. When the Edit JAAS Authentication Entries page appears, enter the following
and then click OK:
– Alias: localhost/ITSOBankAlias
– User ID: wpsadmin
– Password: wpsadmin
– Description: ITSO Bank Alias
6. Click File → Save.
12.Under the heading Resource properties defined in the data source selected
above, scroll up and select databaseName. Click Edit.
13.When the Edit a resource property window appears, enter the path to the
database in the value field (for example, c:\ibm\wsad\itsobank) and then click
OK.
When done, the data source definition for the back-end EJB should look like
Figure 9-8 on page 415.
414 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 9-8 ITSO Data Source definition for the back-end EJB
14.Select File → Save and then close the server configuration file.
416 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
14.Select the ITSOBankEJB project, right-click, and select Run on Server.
15.When the Server Selection window appears, select Use and existing server
and then server1. Click Next.
16.If this is the first deployment of the EJBs, select Deploy EJB beans and click
Finish.
17.An external or internal browser should open, depending on your workbench
settings, that will display the test client. Click JNDI Properties.
18.When the JNDI Properties page appears, enter wpsadmin for the user and
password. Click Set.
This will result in an authenticated call matching the security settings defined
in the EAR deployment descriptor above. If you are using any other user from
LDAP, only the EJB methods assigned to the customer role can be executed
unless you change the role assignment in the EAR Deployment Descriptor.
19.Return to the test client page by clicking the browser back button. Browse the
JNDI objects by clicking JNDI Explorer.
20.Call the methods of the different beans.
a. For example, select ITSO.
b. You should see a listing of EJBs.
c. Select the Manager (com.ibm.itso.bank.ejb ..).
d. Click Manager → ManagerHome → Manager create ().
e. Click Invoke.
f. The object should be retrieved. Click Work with Object.
g. Click the newly created Manager 1 instance.
h. You should see a listing of the methods under Manager 1 instance. Select
the UserData createUserData(UserData) method.
i. Click Invoke.
The string representation of the user data object should be displayed.
If the test environment gives an error message that the current database is
already in use, change to the Data perspective of Application Developer and
delete or disconnect the DB server entries.
418 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
a. Change the parameters in a parameter=value syntax according to
Table 9-4 on page 419, dependent on the specific settings you chose for
LDAP setup.
b. Save and close the file.
java.naming.provider.url ldap://tamdev1.itso.ral.ibm.com:389
java.naming.security.principal cn=root
java.naming.security.credentials <password>
parent_dn cn=users,dc=itso,dc=ibm,dc=com
parent_dn_admin cn=users,dc=itso,dc=ibm,dc=com
In addition to creating the attribute, we have to edit the mapping between Portal
Server and LDAP to make them exchange the attribute:
1. Stop the test environment portal server in case it is running.
2. Edit the wmmLDAPServerAttributes.xml file, which is in the
<portalHome>\wmm directory, for example:
C:\ibm\wsad\runtimes\portal_v50\wmm\wmmLDAPServerAttributes.xml
3. Insert the section listed in Example 9-4 towards the end of the
wmmLDAPServerAttributes.xml file (before </repositoryAttributes>, which
ends the file). The ITSOid is a correlation ID between the ITSO Bank portlet
application and the user data in the LDAP repository.
To optionally create groups and users for the ITSO Bank application refer to
10.2.5, “Create the groups and users for the ITSO Bank application” on
page 438.
To run and test the ITSO Bank application in the test environment, do the
following:
1. From WebSphere Studio Application Developer, select the Server
perspective.
2. Expand Servers and select WebSphere Portal v5.0 Test Environment.
3. Right-click and select Add and remove projects.
4. When the Add and remove projects window appears, ensure that the
DefaultEAR is added to the configured projects (if not, add it). Expand
DefaultEAR to ensure ITSOBankWAR is present. Click Finish.
5. Expand Server and select WebSphere Portal v5.0 Test Environment.
6. Right-click Publish.
7. You should see the message Publishing was successful. Click OK.
8. Right-click Start.
Review the contents of the console and monitor the server startup. You
should see the message WebSphere Portal open for e-business.
420 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
We chose this way of deploying the project since we do not want any other
projects to be published on the server. Now the Portal can be tested.
9. Select the ITSOBankWAR project.
10.Right-click and select Run on Server.
11.Select Use an existing server and select WebSphere Portal v5.0 Test
Environment. Click Finish.
12.Now a browser window should open with the login page.
Note: Ensure that the fully qualified hostname is entered in the URL. For
example:
http://wpdev1.itso.ral.ibm.com:9081/wps/myportal
13.Log in with the wpsadmin user ID. After login the debug page should present
the portlets. For the development you can now create your own pages and
place the portlets wherever they should appear later in a production
environment.
Refer to the deployment chapter for a recommended page and rights
assignment for users and portlets. Unless the application gets completely
removed from the test environments, changes to the code should be reflected
in the portlets.
Note: For details on testing the functionality of the ITSO Bank application,
refer to 12.5, “Verifying the ITSO Bank application and runtime” on page 557.
The portlet used in this example is the ITSOUser portlet, which is used to register
new users and create a bank account for these users. After the users are
created, they have access to the portal in general, their account details, and the
portlets for account balance and transfer.
The data specific to the user is split into two parts, of which the core attributes
(for example, surname, firstname, userid, etc.) will be stored in LDAP, and the
information more specific to the ITSO Bank back-end application will be stored in
the itsobank database.
ITSOUser LDAP
Portlet Helper
Specific Core
User User Authentication
Data Data
Directory
Server
In this case the ITSOUser portlet uses the LDAPHelper class to store information
in the LDAP server and make that information available for the portal from now
on. Example 9-5 includes a code snippet for creating a user in LDAP with the
LDAPHelper class.
Example 9-5 Example of creating a user in LDAP with the LDAPHelper class
Properties env = getContextProperties(log);
422 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
try {
DirContext ctx = new InitialDirContext(env);
Attributes attSet = getAttrSet(userData, objectClass);
ctx.createSubcontext(dn, attSet);
ctx.close();
} catch (NameAlreadyBoundException e) {
log.error("NameAlreadyBoundException while adding user: " +
e.getMessage());
} catch (NamingException e) {
log.error(logPrefix + " NamingException while adding user: " +
e.getMessage());
}
These calls in the current application are made through the classes in the
javax.naming.* and javax.naming.directory.* packages.
Authentication
LDAP
Import User
Helper
Specific Core
User User
Data Data
Example 9-6 Importing a user from the Directory Server into Access Manager
try {
URL configURL = new URL(configURLStr);
424 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
messages);
// now the user can bypass webSEAL with a TAM authentication
} catch (MalformedURLException e) {
log.error(logPrefix + " MalformedURLException while importing user: " +
e.getMessage());
} catch (PDException e) {
log.error(logPrefix + " PDException while importing user: " +
e.getMessage());
}
Once the context for Tivoli Access Manager is created, all API calls can be
performed on the various Access Manager objects. These include working with
users (PDUser), policies (PDPolicy), ACLs (PDAcl), etc.
For more information on the Tivoli Access Manager APIs, refer to the
Authorization Java Classes Developer Reference, IBM Tivoli Access Manager
V5.1, SC32-1350, product guide.
Portlet
WebSphere
Authentication
Portal
Portlet
Authentication
Authentication Backend
Proxy Applications
(For example,
WebSEAL)
Other
Other
Web
Other
Web
Applications
Web
Applications
Applications
The usage of the credential vault is well documented in the Portal InfoCenter as
well as in a number of articles in the WebSphere Technical Journal of IBM
developerWorks. Therefore the following example will be brief.
In this section we introduce a simple application the makes use of the credential
vault in a way that an administrator initially specifies a common username and
password, as well as an URL for a protected resource. This resource is displayed
for every user that can see the portlet. The protected resource will be the Web
page from “Create test portlet to verify Credential Vault” on page 351, which is
secured with basic authentication.
426 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Since we want all users to access the same information with the same
combination of username and password, we need to take a system slot to share
the information among users.
Portlets can store data to and retrieve data from the credential vault via the
credential vault service. To access the service as well as the vault segments and
slot, the com.ibm.wps.portletservice.credentialvault package is used. This
contains three interfaces:
CredentialSlotConfig
CredentialVaultService
VaultSegmentConfig
Out of these, the CredentialVaultService will mostly be used, since the others are
only needed when working directly with segments and slots, for example,
creation and deletion. Besides the package above, there is the package
com.ibm.wps.portletservice.credentialvault.credentials that contains different
credential objects that are used to handle the credentials. A part of the class
hierarchy is displayed in Figure 9-12 on page 428.
Credential
Passive Active
Credential Credential
Http HttpForm
BasicAuth ... BasedAuth
Credential Credential
The credentials are split into active and passive credentials. Passive credentials
are objects that act as a containers for credentials, whereas active credentials
hide the credentials from the user and provide convenience methods instead.
Since basic authentication is used for the resource to access, we can use the
HttpBasicAuthCredential. Once this object is initialized, it can authenticate
connections for us without revealing the credentials.
428 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Parameter Value
Slotname ITSOTestSlot
Credential HttpBasicAuthCredential
An application walk-through
The application consists of the following classes/files:
ITSOCredentialVaultPortlet.java: The main portlet class
ITSOCredentialVaultConfigBean.java: A simple bean to wrap the settings that
are passed from and to the config mode
ITSOCredentialVaultPortletError.jsp: An error page that is displayed in case
that exceptions occur
ITSOCredentialVaultPortletConfig.jsp: The page used for the configuration
The portlet application used here consists of two modes, the general view mode
and a configure mode to set the settings, which are reflected by the doView() and
doConfigure() methods in the portlet class. The doConfigure() mode includes the
ITSOCredentialVaultPortletConfig.jsp page and displays the settings for the
portlet. These settings can be changed by an administrator in the configure
mode. If the parameters are changed, the actionPerformed() method of the
portlet will store the new settings.
try {
vaultService.setCredentialSecretUserPassword(SLOTNAME, userID,
password.toCharArray(), request);
} catch (PortletServiceException e) {
throw new PortletException(e);
}
}
When the Save button on the config page is pressed, the request is passed to
the actionPerformed() method. This method will do a few checks on parameters
and then call the storeCredentials() method (displayed in Example 9-7) that will
call the CredentialVaultService to store the credentials.
After storing the credentials, the other important thing would be to use the
credentials to authenticate against the protected HTML page. As described
return credential.getAuthenticatedConnection(urlString);
} catch (MalformedURLException e) {
throw new PortletException(e);
} catch (IOException e) {
throw new PortletException(e);
}
}
All other actions needed to perform on the WebSphere Portal credential vault
service are variations on the API, and therefore will not be discussed in detail.
430 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Finally, add the variable extensions to the project as described in section “Define
the project dependencies” on page 404. In addition to the variable extensions
listed, add also the variable WAS_50_PLUGINDIR/lib/utils.jar.
Now the project can be run and tested in the test environment. For details
concerning the setup, see the next section.
Note: As described above, the URL to the protected page is a portlet setting.
Unless you specify this setting in the portlet deployment descriptor portlet.xml,
every execution of the Run on server option of the workbench will redeploy the
application, and therefore set this parameter to null. This will not be the case
with the credentials, since they are stored in the credential vault independently
from the application.
Then you should create a portal page and place the portlet on that page. How
this can be done is described in 10.3.5, “Create portal pages” on page 451, and
10.3.6, “Add portlets to pages” on page 453.
Now that the portlet is installed, the settings have to be configured once by
clicking the configure icon in the portlet header. The settings are displayed in
“Parameters for the credential vault portlets” on page 432.
User ID vault_test
Password passw0rd
After the settings have been specified, a click the Save button should display the
protected page in the view mode.
432 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
10
This application provides the following personalized services to the user that
belongs to the role of customer:
View balance in the savings and checking accounts.
Transfer funds between savings and checking accounts.
This application provides the following administrative services to the user that
belongs to the role of manager:
Enter customer information.
Modify customer information.
View balance in the savings and checking accounts of any customer.
View transaction history of customer accounts.
The ITSO Bank back-end is a J2EE application that uses a DB2 database (or
Cloudscape database in the development environment). The ITSO Bank
back-end and database can be installed on a remote WebSphere Application
Server. In our example, we will deploy both the back-end J2EE application and
front-end portlets on the Portal Server node. For the purposes of showing proper
configuration, we will create a separate application server (for example,
ITSOBankServer) to deploy the back-end application.
434 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
10.2.1 Create an application server
This section describes how to create the ITSOBankServer application server
used to deploy and run the ITSO Bank back-end enterprise application.
Note: In our example, we used the port value that was generated by
WebSphere Application Server for the newly created ITSOBankServer
application server. Alternatively, you could change the port value to a new
value.
Note: For a description of the ITSO sample code and where to download it,
refer to Appendix F, “Additional material” on page 683.
2. Unpack the 6325code.zip file. For example, we unpacked the zip to the
c:\6326code directory.
3. Create the directory c:\temp\ITSOBankApp.
4. Copy the ITSOBankEAR.ear file from the ITSO sample code
c:\6325code\deploy directory to the c:\temp\ITSOBankApp directory.
5. Extract the ITSOBankEJB.jar from ITSOBankEAR.ear.
a. Open a command window and change to the temporary directory (for
example, c:\temp\ITSOBankApp).
b. Enter the following to extract the EJB jar file:
c:\ibm\WebSphere\AppServer\java\bin\jar -xvf ITSOBankEAR.ear
ITSOBankEJB.jar
6. Extract the Table.ddl from the ITSOBankEJB.jar.
a. Open a command window and change to the c:\temp\ITSOBankApp
directroy.
436 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
b. Enter the following to extract the files:
c:\ibm\WebSphere\AppServer\java\bin\jar -xvf ITSOBankEJB.jar
META-INF/Table.ddl
Note: At the time of writing this redbook, we found that we were not able to
successfully restart the Tivoli Directory Server remotely using the Web
Administration Tool. For this reason, we restarted the Tivoli Directory Server
via Windows services.
10.2.5 Create the groups and users for the ITSO Bank application
This section describes how to create groups and users needed for the ITSO
Bank application. We will create a ITSOManagers and ITSOCustomers group. In
addition, we will create a manager user ID in the managers group. The manager
user ID is required. However, the customer user IDs can be created from the
ITSO Bank application.
438 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
ITSO Bank. The itsobank.ldif file can be found in the ITSO sample code
c:\6325code\deploy directory.
dn: uid=manager1,cn=users,dc=itso,dc=ibm,dc=com
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: manager1
userpassword: passw0rd
sn: Manager
givenName: ITSOBank
cn: ITSOBank Manager
dn: cn=ITSOManagers,cn=groups,dc=itso,dc=ibm,dc=com
objectclass: groupOfUniqueNames
objectclass: top
uniquemember: uid=manager1,cn=users,dc=itso,dc=ibm,dc=com
cn: ITSOManagers
dn: cn=ITSOCustomers,cn=groups,dc=itso,dc=ibm,dc=com
objectclass: groupOfUniqueNames
objectclass: top
uniquemember: uid=ITSOBankDummyUser,cn=users,dc=itso,dc=ibm,dc=com
cn: ITSOCustomers
440 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. Start the WebSphere Administrative Console by entering the following URL in
a Web browser:
http://wpwin1.itso.ral.ibm.com:9090/admin
4. Log on as the user ID wpsbind.
5. Create an authentication alias used by the datasource.
The ITSO Bank application uses an authentication alias to connect with the
database through the datasource configured for a DB2-based JDBC Provider.
This authentication alias can be configured in the WebSphere Administrative
Console by completing the following steps:
a. Click Security → JAAS Configuration → J2C Authentication Data.
b. From the J2C Authentication Data page, click New to create a new alias.
c. When the New alias page appears, enter the following, as seen in
Figure 10-1, and then click OK:
• Alias: ITSOBankAlias
• User ID: admin
This is the DB2 instance owner used to create a database.
• Password: <db2_password>
• Description: ITSO Bank Alias
Note: The default DB2 JDBC Provider is deprecated. For this reason
we chose to use the DB2 Legacy CLI-based Type 2 JDBC Driver.
e. From the DB2 Legacy CLI-base Type 2 JDBC Drive page, enter the
following and then click OK:
• Name: DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO Bank
Application
• Description: DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO
Bank Application
7. Create the datasource.
a. From the JDBC Providers page, click the newly created JDBC provider
DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO Bank
Application.
b. Click Data Sources in the Additional Properties found by scrolling down
the page.
c. From the Data Sources page, click New.
d. From the New Data Sources page, enter the following and then click OK:
• Name: ITSOBankDataSource
• JNDI Name: jdbc/ITSO
• Container managed persistence: Check Use this Data Source in
container managed persistence (CMP).
• Description: DB2 JDBC DataSource for ITSOBank
• Component-managed Authentication Alias: Select
wpwin1/ITSOBankAlias.
• We accepted the defaut values for the remaining options.
e. Click ITSOBankDataSource.
f. Click Custom Properties under the Additional Properties heading.
442 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
g. Click databaseName and set the value to ITSOBANK. Click OK.
h. Click Environment → Manage WebSphere Variables.
Ensure that the variable DB2_JDBC_DRIVER_PATH is set to the location
of db2java.zip fle (for example, DB2_JDBC_DRIVER_PATH
c:\ibm\sqllib\java).
i. Click Save.
j. When the Save to Master Configuration page appears, click Save.
8. Test the connection to the database:
a. Select Resources → JBDC Providers.
b. Click DB2 Legacy CLI-based Type 2 JDBC Driver for ITSO Bank
Application.
c. Click Data Sources under Additional Properties.
d. Check ITSOBankDataSource, and then click Test Connection.
You should see a message like the following if successful:
Test connection for the datasource ITSOBankDataSource on server server1
at node wpwin1 was successful.
444 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 10-2 Results of role mapping
Note: For a description of the ITSO sample code and where to download it,
refer to Appendix F, “Additional material” on page 683.
2. Unpack the 6325code.zip file. For example, we unpacked the zip to the
c:\6326code directory.
3. Copy ITSOBankWAR.war to the c:\temp\ITSOBankApp directory.
4. Extract the contents of ITSOBankWAR.war to
C:\temp\ITSOBankApp\ITSOBankWAR.
a. Open a command window and create the
c:\temp\ITSOBankApp\ITSOBankWAR directory.
b. Change to the c:\temp\ITSOBankApp\ITSOBankWAR directory.
c. Enter the following command to extract the ITSOBankWAR.war:
c:\ibm\WebSphere\AppServer\java\bin\jar -xvf ..\ITSOBankWAR.war
446 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2. Modify the itsobank.properties file.
a. Modify the the following values in the itsobank.properties file for that of the
target system, as seen in Example 10-3 on page 447 (values to change in
bold):
• host: Change the hostname to match with the hostname of the node
where the application will be deployed. In our example, this is the
Portal Server node.
• port: Change the port to the bootstrap value of the application server
that you wish to deploy the application to. To determine this value, refer
to “Determine application server bootstrap port” on page 435 (for
example, 2810).
• managerjndi: You will need to update the node name (for example,
wpwin1) and application server (for example, ITSOBankServer), as
seen in Example 10-3.
com.ibm.itso.bank.appserver.host=iiop://wpwin1.itso.ral.ibm.com
com.ibm.itso.bank.appserver.port=2810
com.ibm.itso.bank.appserver.managerjndi=cell/nodes/wpwin1/servers/ITSOBankServer/ITSO/Manager
java.naming.provider.url=ldap://tamwin1.itso.ral.ibm.com:389
java.naming.security.principal=cn=root
java.naming.security.credentials=passw0rd
448 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
credential=passw0rd
This file will be overwritten for certain wpsconfig tasks like disable-security,
enable-security-ldap. In that case, this entry will have to be added again.
</repositoryAttributes>
450 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 10-3 ITSO Bank portlets to be installed
When installation completes, you should see a message that the portlets
were successfully installed.
452 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
b. From the New page: ITSO Bank page, do the following and then click OK:
• Title: Modify User
c. You should seethe message Modify User has been created
successfully. Click OK.
6. Create Access Account page.
a. Click New page.
b. From the New page: ITSO Bank page, do the following and then click OK:
• Title: Access Account
c. You should see a message Access Account has been created
successfully. Click OK.
5. From the Edit Layout page, click the one column icon, as seen in Figure 10-6
on page 455.
6. When the message If you have derived or personalized pages based off
this page, then all those changes will be lost. Do you wish to
continue? appears, click OK.
454 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 10-6 Edit page layout - Single column page
The portlet ITSO Modify User provides an integrated interface similar to the
portlet ITSO Add User, which is used to modify the personal details of the chosen
customer and the accounts held by the customer. This portlet also incorporates a
Click-To-Action icon that enables portlet messaging between the three
administration portlets placed on this page. Currently WebSphere Portal Server’s
The portlet ITSO Transaction History allows the manager to view the details of
transactions executed on an account or customer.
The portlet ITSO Account Balance Admin allows the manager to view the details
of the accounts held by the selected customer.
456 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 10-7 Edit page layout for Modify User page after adding portlets
b. Click the right-hand arrow icon (>) to move the ITSO Transaction History
portlet to the right-column container.
c. From the right-column container, click the up arrow (^) for the ITSO
Transaction History portlet.
When complete, the portlets should be arranged on the page as seen in
Figure 10-8 on page 458.
8. Click Done.
458 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
6. Click Add portlets.
7. From the Edit Layout page, do the following and then click Search:
– Search on: Select Title contains.
– Search for: ITSO
8. When the search results are displayed, you should see a list of ITSO portlets.
Check the following and then click OK:
– Check ITSO Account Balance.
– Check ITSO Transfer Funds.
9. Rearrange the portlet layout on the Access Account page by clicking the
down arrow icon to move the ITSO Account Balance portlet below the ITSO
Transfer Funds portlet.
10.Click Done.
To change the page permission such that user IDs with the customer role do not
have access permissions to the Add User and Modify User pages, do the
following:
1. From the Administration page, click Access → Resource Permissions.
2. From the Resource Types page, click Pages.
3. Click Content Root.
4. Click My Portal.
5. Assign access to the ITSO Bank page.
a. Click the key icon under Assign access for ITSO Bank page.
b. Uncheck the Allow Inheritance checkboxes for the Privileged User role
and User role.
b. Uncheck the Allow Inheritance checkboxes for the Privileged User role
and User role, as seen in Figure 10-10 on page 461.
460 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 10-10 Uncheck privileged user
c. Click the pencil icon in the Edit Role column for the Privileged User.
d. From the Assign Access for: Pages → Add User page, click Add.
e. When the Search for Users and User Groups page appears, do the
following:
i. Select User Groups from the Search for Users or User Groups
drop-down list.
ii. Select cn from the Search on drop-down list.
iii. Enter ITSOManagers in the Search for text box.
iv. Click Search.
f. After clicking search, the page will be updated. Check the checkbox in the
Select column for the ITSOManagers group.
g. Click OK.
h. Click Done.
i. Click OK.
462 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
h. Click Done.
i. Click OK.
j. Click Done.
From the results of the search, you should have a list of ITSO portlets, as seen in
Figure 10-11 on page 464.
464 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
d. From the Assign: Portlets → ITSO Account Balance Admin page, click
Add.
e. When the Search for Users and User Groups page appears, do the
following:
i. Select User Groups from the Search for Users or User Groups
drop-down list.
ii. Select cn from the Search on drop-down list.
iii. Enter ITSOManagers in the Search for text box.
iv. Click Search.
f. After clicking Search, the page will be updated. Check the checkbox in the
Select column for the ITSOManagers group.
g. Click OK.
h. Click Done.
i. Click OK.
2. Repeat the process to modify portlet permissions (step 1) for each of the
remaining portlets for the ITSOManagers group.
– ITSO Modify User
– ITSO Transaction History
Note: The ITSO Modify User portlet, ITSO Transaction History portlet, and
ITSO Account Balance portlet are developed to incorporate
Click-To-Action technology supported by WebSphere Portal’s Property
Broker. They are programmatically enhanced to support the creation and
deletion of wire between the Click-To-Action enabled portlets. This
administration of wire requires the role of Privileged User. So the
ITSOManagers group is granted the role of Privileged User only for these
three portlets.
3. Modify the ITSO Add User portlet permissions for the ITSOManagers group
as follows:
a. Click the key icon under Assign access for ITSO Add User portlet.
b. Uncheck the Allow Inheritance checkbox for the User role.
c. Click the pencil icon in the Edit Role column for the User.
d. From the Assign: Portlets → ITSO Add User page, click Add.
466 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
i. Click OK.
2. Repeat the process to modify portlet permissions (step 1) for the ITSO
Transfer Funds portlet for the ITSOCustomers group.
3. Log out of WebSphere Portal.
Note: Chapter 12, “Manage a secure portal solution” on page 503, includes
use case validation for the ITSO Bank.
1. Access the WebSphere Portal Home page by entering the following URL in a
Web browser:
https://wswin1.itso.ral.ibm.com/portal/wps/myportal
2. Log in as user ID manager1.
The manager1 user ID was created in 10.2.5, “Create the groups and users
for the ITSO Bank application” on page 438.
3. Click the ITSOBank tab.
4. Click Add User.
Note: If the Add User portlet fails with the error message The portlet was not
available. Please contact your portal administrator, you probably have
missed the step to restart the ITSOBankServer. Restart the ITSOBankServer
for changes to take effect.
When externalizing the ITSO Bank page resources, we will need to explicitly
define the permission assignments for the pages due to the inheritence being
severed.
468 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Externalize the ITSO Bank pages resource
This section describes how to extrenalize the ITSO Bank pages resource using
the WebSphere Portal Resource Permission portlet.
1. Start the WebSphere Portal Administration Console by entering the following
URL:
https://wswin1.itso.ral.ibm.com/portal/wps/myportal
2. Log on as the wpsadmin user.
3. Access the Resource Permission portlet by clicking Administration →
Access → Resource Permissions.
4. Externalize the resource permissions for the ITSO Bank page.
a. Click Pages under Resource Type column.
b. Click Content Root in the Page Title column.
c. Click My Portal.
d. Click the right arrow (>) in the Externalize/Internalize column for the ITSO
Bank page.
e. You will be prompted Are you sure you want to place the resource
under External Access Control? Click OK.
You should see the message Resource Successfully externalized.
f. Click Done.
5. Externalize the resource permissions for portlets.
a. Click Portlets.
b. From the Portlet search page do the following:
• Search on: Select Title contains.
• Search for: ITSO
• Click Search.
c. Repeat the following steps for each of the listed portlets:
• ITSO Account Balance
• ITSO Account Balance Admin
• ITSO Add User
• ITSO Modify User
• ITSO Transaction History
• ITSO Transfer Funds
i. Click the right arrow (>) in the Externalize/Internalize column for the
respective portlet.
ii. You will be prompted Are you sure you want to place the resource
under External Access Control? Click OK.
470 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
11
SAS is a legacy protocol used in WebSphere Application Server Version 3.x, and
Version 4.x. CSIv2 is an Object Management Group (OMG) industry standard
protocol that offers more vendor interoperability, as well as additional features.
The use of SAS protocol is only recommended for interoperability with
WebSphere Application Server V3.x and V4.x servers. In our environment we will
use the CSIv2 protocol.
WebSphere Application Server supports the following options for CSIv2 inbound
transport settings:
TCP/IP: Only non-encrypted connections are used; SSL is not enabled.
SSL-Supported: Both TCP/IP and SSL connections are accepted.
SSL-Required: Only SSL connections are accepted.
472 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
In our example we will configure the CSIv2 endpoint with server authentication
and SSL-Required setting. We will configure it to use static port 7345.
474 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
• Provider: Select IBMJSSE.
• Protocol: Select SSLv3.
d. Click Security → Authentication Protocol → CSIv2 Inbound
Transport.
e. Enter the following settings and click OK.
• Transport: Select SSL-Required.
• SSLSettings: Select wpwin1/CSIv2SSLSettings.
f. Click Security → Authentication Protocol → CSIv2 OutBound
Transport.
g. Enter the following settings and click OK.
• Transport: Select SSL-Required.
• SSLSettings: Select wpwin1/CSIv2SSLSettings.
5. Click Save.
6. When the Save to Master Configuration screen appears, click Save.
7. Log out from the Administrative Console.
8. Restart application server server1.
Note: At this time only server1 is needed. The changes will not take effect
on the other application servers (ITSOBankServer, WebSphere_Portal)
until restarted.
The IBM Tivoli Directory Server has the ability to protect LDAP access by
encrypting data with either Secure Sockets Layer (SSL) security or Transaction
Layer Security (TLS) or both. Both server authentication and client authentication
(mutual SSL) are supported when using SSL or TLS. We will use SSL with server
authentication. For more information about configuring TLS or mutual SSL,
476 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
i. Modify the following fields and click OK:
• Data Type: Select Base64-encoded ASCII data.
• Certificate file name: ldapcert.arm
• Location: c:\ibm\ldap\lib
j. Close the IBM Key Management window.
5. Ensure the Tivoli Directory Server is started.
6. Modify the ldap-enable-ssl.ldif file found in the ITSO sample code
c:\6325code\hardening\ldap directory to point to the LDAP server keystore
that was created in previous steps. The contents of the ldap-enable-ssl.ldif
are listed in Example 11-1.
dn: cn=SSL,cn=Configuration
changetype: modify
replace: ibm-slapdSslAuth
ibm-slapdSslAuth: serverAuth
-
replace: ibm-slapdSecurity
ibm-slapdSecurity: SSL
-
replace: ibm-slapdSslKeyDatabase
ibm-slapdSslKeyDatabase: c:\ibm\ldap\lib\ldapkey.kdb
After performing these steps, the Tivoli Directory Server will accept both
non-SSL LDAP connections on port 389 and SSL LDAP connections on port
636. The Tivoli Directory Server Admin Daemon will accept non-SSL
connections on port 3538 and SSL connections on port 3539.
Tip: To use the ldapsearch command after enabling SSL, specify the -Z
option. For example:
ldapsearch -Z -b dc=itso,dc=ibm,dc=com -s one objectclass=*
478 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
• Location: c:\ibm\Tivoli\TAM\keytab
g. When prompted to enter a label for the certificate, enter LDAP Server
Certificate. Click OK.
h. Close the IBM Key Management window.
5. Modify the c:\ibm\Tivoli\TAM\etc\ldap.conf file and update the entries shown
in Example 11-2. Note that we checked stash password to keyfile; thus the
LdapSSLKeyFilePwd value is not needed.
480 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
g. When prompted to enter a label for the certificate, enter LDAP Server
Certificate. Click OK.
h. Close the IBM Key Management window.
6. Modify the c:\ibm\Tivoli\TAM\etc\ldap.conf file and update the entries shown
in Example 11-6.
Note: Since we do not use mutual SSL connections for LDAP, we can
specify LdapClientTrustFile.jks for both Key File Name and Trust File
Name settings. For mutually authenticated connections, a self-signed
certificate would need to be generated for WebSphere Application Server.
Key File Name should then point to the key file containing the private key
for the generated certificate.
– Alias: LDAPSSLSettings
– Key File Name:
C:\ibm\WebSphere\AppServer\etc\LdapClientTrustFile.jks
– Key File Password: <password>
– Key File Format: Select JKS.
482 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
– Trust File Name:
C:\ibm\WebSphere\AppServer\etc\LdapClientTrustFile.jks
– Trust File Password: <password>
– Trust File Format: Select JKS.
– Client Authentication: Uncheck.
– Security Level: Select HIGH.
– Cipher Suites: Do not modify.
– Cryptographic Token: Uncheck.
– Provider: Select IBMJSSE.
– Protocol: Select SSLv3.
– Fix Advanced LDAP Settings.
– Port: 636
– Check SSL Enabled.
– SSL Configuration: Select wpwin1/LDAPSSLSettings.
12.You should now be on the Global Security page. Click Apply to validate the
LDAP connection.
Important: Verify that after clicking Apply you do not receive any LDAP
validation errors. If there are any errors, correct the problems before saving
the configuration, otherwise WebSphere Application Server will not be able
to start.
Note: At this time only server1 is needed. The changes will not take effect
on the other application servers (ITSOBankServer, WebSphere_Portal)
until restarted.
To import the LDAP server certificate into the WebSphere Portal keystore, do the
following:
1. Copy the c:\ibm\ldap\lib\ldapcert.arm file from the Policy Server node to the
c:\ibm\WebSphere\AppServer\java\jre\lib\security directory on the Portal
Server node.
2. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the
ikeyman.bat command.
3. Import the LDAP server certificate:
a. Click Key Database File → Open.
b. Enter the following values in the pop-up window:
• Key database type: Select JKS.
• File Name: cacerts
• Location: C:\IBM\WebSphere\AppServer\java\jre\lib\security
c. When prompted for the password, enter changeit. Click OK.
484 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
d. Select Signer Certificates from the pull-down menu underneath Key
database content.
e. Click Add.
f. Modify the following fields and click OK:
• Data Type: Select Base64-encoded ASCII data.
• Certificate file name: ldapcert.arm
• Location: C:\IBM\WebSphere\AppServer\etc
g. When prompted to enter a label for the certificate, enter tamwin1 LDAP
Server Certificate. Click OK.
h. Close the IBM Key Management window.
486 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
11.2.6 Enable SSL for Web Admin Tool LDAP connection
To enable the Tivoli Directory Server Web Administration Tool to manage the
directory server over the SSL connection, do the following on the Policy Server
node.
To configure the Tivoli Directory Server client utilities for SSL on the Reverse
Proxy node, do the following:
1. Navigate to the c:\ibm\ldap\lib directory on the Reverse Proxy node.
488 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
2. Copy the c:\ibm\Tivoli\TAM\keytab\ldapcert.kdb file to
c:\ibm\ldap\lib\ldapkey.kdb. (Note: Change the file name to ldapkey.kdb.)
3. Copy the c:\ibm\Tivoli\TAM\keytab\ldapcert.sth file to
c:\ibm\ldap\lib\ldapkey.sth. (Note: Change to the file name to ldapkey.sth.)
4. Verify the ldapsearch command using SSL. Open a command prompt and
enter the following command on a single line:
ldapsearch -h tamwin1 -D cn=root -w passw0rd -s base -b
cn=connections,cn=monitor -Z objectclass=*
You should see a list of active connections on the LDAP server similar to
Example 11-9. Verify that the connection for the CN=ROOT user has the SSL
attribute set. This is the connection from the ldapsearch utility.
Note: Do not complete this section if using the ITSO Bank application.
We were not able to configure the ITSO Bank sample portlets for access to the
LDAP server via SSL. For this reason, the ITSO Bank sample application will
not work if you complete this section on disabling non-SSL access to the Tivoli
Directory Server.
This procedure describes how to disable non-SSL access to the Tivoli Directory
Server.
1. Disable non-SSL connections to the Tivoli Directory Server by executing the
following command on the Policy Server node:
ldapmodify -h tamwin1 -D cn=root -w passw0rd -i ldap-disable-nonssl.ldif
2. Restart the following Windows services for the Tivoli Directory Server:
– IBM Tivoli Directory Server V5.2
– IBM Tivoli Directory Server Admin Daemon V5.2
3. After performing these steps, the Tivoli Directory Server will only accept SSL
LDAP connections on port 636. The Admin Daemon will only accept SSL
connections on port 3539.
Enter the following command in a Windows command window on the Policy
Server node:
netstat -an | more
Look for open tcp listening ports on 389 and 3538. These ports should not be
listed, as they are the non-ssl ports for LDAP that have been turned off in this
section.
This section describes how to create your own key and trust files:
Configure SSL certificate and repertoire for SOAP connector.
Configure WebSphere administration utilities.
Configure WebSphere Portal SOAP connection credentials.
490 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
11.3.1 Configure SSL certificate and repertoire for SOAP connector
This section describes how to configure the SSL certificate and repertoire for the
SOAP connector on the Portal Server node.
492 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
d. Select Signer Certificates from the pull-down menu underneath Key
database content.
e. Click Add.
f. Modify the following fields and click OK:
• Data Type: Select Base64-encoded ASCII data.
• Certificate file name: soapclientcert.arm
• Location: C:\IBM\WebSphere\AppServer\etc
g. When prompted to enter a label for the certificate, enter wpwin1 SOAP
Client Certificate. Click OK.
6. Close the IBM Key Management tool.
Note: At this stage you will not be able to manage any application servers
using WebSphere utilities such as serverStatus or stopServer because
they have not been configured yet for the new SOAP SSL settings.
494 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
#------------------------------------------------------------------------------
# SSL Configuration
#
# - keyStore and trustStore (fully qualified path to file)
# - keyStorePassword and trustStorePassword (string specifying password - encoded or not)
#------------------------------------------------------------------------------
com.ibm.ssl.keyStore=C\:/ibm/WebSphere/AppServer/etc/SOAPClientKeyFile.jks
com.ibm.ssl.keyStorePassword=passw0rd
com.ibm.ssl.trustStore=C\:/ibm/WebSphere/AppServer/etc/SOAPClientTrustFile.jks
com.ibm.ssl.trustStorePassword=passw0rd
Note: The steps in this section are mandatory if you have modified the
WebSphere Application Server SOAP certificate settings as described in
“Configure SSL certificate and repertoire for SOAP connector” on page 491.
The xmlaccess utility has no configuration setting to use a specific Java Key
Store file for secure SOAP connections. Therefore the certificates needed by
xmlaccess have to be imported into the JVM default keystore. The JVM default
keystore file is called cacerts and it is located in the
<WAS_HOME>/java/jre/lib/security directory. By default, the password for this
file is changeit.
1. Copy the c:\ibm\WebSphere\AppServer\etc\soapservercert.arm file created in
“Create SSL keys for SOAP connector” on page 491 to the
c:\ibm\WebSphere\AppServer\java\jre\lib\security directory on the Portal
Server node.
2. Navigate to the c:\ibm\WebSphere\AppServer\bin directory and execute the
ikeyman.bat command.
496 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. Import the LDAP server certificate:
a. Click Key Database File → Open.
b. Enter the following and click OK:
• Key database type: Select JKS
• File Name: cacerts
• Location: c:\ibm\WebSphere\AppServer\java\jre\lib\security
c. Enter and confirm the key file password. The default password is
changeit. Click OK.
d. Select Signer Certificates from the pull-down menu underneath Key
database content.
e. Click Add.
f. Modify the following fields and click OK:
• Data Type: Select Base64-encoded ASCII data.
• Certificate file name: soapservercert.arm
• Location: C:\IBM\WebSphere\AppServer\java\jre\lib\security
g. When prompted to enter a label for the certificate, enter wpwin1 SOAP
Server Certificate. Click OK.
4. Close the IBM Key Management window.
1. Back up the
c:\ibm\WebSphere\PortalServer\wmm\wmmLDAPServerAttributes.xml.
2. Back up the c:\ibm\WebSphere\PortalServer\shared\app\wmm\wmm.xml.
3. Edit the c:\IBM\WebSphere\PortalServer\config\wpconfig.properties file and
modify the settings shown in Example 11-12.
Example 11-12 Modify wpsconfig.properties for SOAP trust and key files
##################################################################
#
# Credentials for WAS administration secure SOAP connection
#
# Used for Portlet deployment with WAS security enabled
#
##################################################################
# WpsHostName=wswin1.itso.ral.com
WpsHostName=wpwin1.itso.ral.ibm.com
498 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
8. Change the WpsHostName back to the hostname of the Reverse Proxy node
after running wpconfig in the wpconfig.properties file.
WpsHostName=wswin1.itso.ral.com
9. Restart the WebSphere_Portal application server.
<!-- Sample for deploying a portlet and creating a page within the portlet. -->
<portal action="locate">
<!-- Parent element under which the new page is inserted -->
<content-node action="locate" objectid="parentPage" uniquename="wps.My Portal"/>
<!-- The new page. contentparentref attribute must match the objectid of the parent.
Change the uniquename attribute to create another page. -->
<content-node action="update" uniquename="wps.SamplePage" ordinal="last"
content-parentref="parentPage" active="true" allportletsallowed="false"
create-type="explicit" type="page">
<supported-markup markup="html" update="set"/>
<localedata locale="en"><title>Sample Page</title></localedata>
500 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
</content-node>
</portal>
</request>
Node agents
When the WebSphere Application Server node is federated into a cell, a node
agent application is deployed and started on the node. The nodeagent
application server must be hardened similarly to other application servers
running on WebSphere Portal node.
11.4.3 Disable the IBM HTTP Server on the Policy Server node
The IBM HTTP Server on this node is used only for administrator access to the
WebSphere Application Server Administrative Console, Tivoli Directory Server
Web Administration Tool, and Tivoli Access Manager Web Portal Manager. We
recommend disabling the IBM HTTP Server and IBM HTTP Administration
services completely and accessing the Web applications directly on WebSphere
Application Server HTTP Transport ports, for example:
WebSphere Application Server Administrative Console
http://tamwin1.itso.ral.ibm.com:9090/admin
Tivoli Directory Server Web Administration
https://tamwin1.itso.ral.ibm.com:9443/IDSWebApp/IDSjsp/Login.jsp
Tivoli Access Manager Web Portal Manager
https://tamwin1.itso.ral.ibm.com:9443/pdadmin
502 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
12
Note: For more detailed information on Tivoli Access Manager V5.1 and Tivoli
Directory Server V5.2 refer to the following:
Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339
Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360
WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1359
Command Reference, IBM Tivoli Access Manager V5.1, SC32-1354
Important: Do not forget Tivoli Directory Server depends on DB2. Ensure that
DB2 processes are running.
Start
Tivoli Directory Server can be started from either the Windows Services panel,
the command line, or the Tivoli Directory Server Web Administration Tool:
To start the directory server from Windows services, select IBM Tivoli
Directory Server V5.2, right-click, and select Start.
To start the directory sever from a command prompt, type in ibmslapd or use
the following command (requires the administration daemon ibmdiradm to be
running):
ibmdirctl [-h <hostname >][-D <adminDN >][-w <password >][-p <portnumber
>]start
504 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Where the portnumber specifies the TCP port where the administration
daemon is listening (typically 3538). The above command can also be used to
stop, restart or view the status of the directory server.
For information on starting ibmslapd from the Tivoli Directory Server Web
Administration Tool see 12.1.3, “Tivoli Directory Server - Web Administration
Tool” on page 507.
Stop
Tivoli Directory Server can be stopped from either the Windows Services panel,
the command line, or the Tivoli Directory Server Web Administration Tool:
To stop the directory server from the Windows services panel, select IBM
Tivoli Directory Server V5.2, right-click, and select Stop.
To stop the directory server from a command prompt use the following
command (requires the administration daemon ibmdiradm to be running):
ibmdirctl [-h <hostname >][-D <adminDN >][-w <password >][-p <portnumber
>]stop
Where the portnumber specifies the TCP port where the administration
deamon is listening (typically 3538).
For information on stopping ibmslapd from the Tivoli Directory Server Web
Administration Tool see 12.1.3, “Tivoli Directory Server - Web Administration
Tool” on page 507.
View status
Tivoli Directory Server’s status can be viewed from either the Windows Services
panel, the command line, or the Tivoli Directory Server Web Administration Tool:
To view the status of the directory server from the Windows services panel,
select IBM Tivoli Directory Server V5.2 and view the status column.
To view the status of the directory server from a command prompt use the
following command (requires the administration daemon ibmdiradm to be
running):
ibmdirctl [-h <hostname >][-D <adminDN >][-w <password >][-p <portnumber
>]status
Where the portnumber specifies the TCP port where the administration
deamon is listening (typically 3538).
For information on viewing the status of ibmslapd from the Web
Administration Tool see 12.1.3, “Tivoli Directory Server - Web Administration
Tool” on page 507.
Start
The directory administration daemon can be started from either the Windows
services panel or the command line:
To start the administration daemon from the Windows Services panel select
IBM Tivoli Directory Admin Daemon V5.2, right-click, and select Start.
To start the admin daemon from the command prompt type in ibmdiradm.
Stop
The directory administration daemon can be stopped from either the Windows
services panel or the command line:
To stop the admin daemon from the Windows Services panel select IBM
Tivoli Directory Admin Daemon V5.2, right-click, and select Stop.
To stop the admin daemon from the command prompt type:
ibmdirictl -D <adminDN> -w <adminPW> admstop
506 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Define the administrator distinguished name and password
Please refer to “Set the administrator DN and password” on page 195 for details
on how to perform this task.
Add suffixes
Please refer to 7.3.1, “Create a suffix” on page 266 for detailed instructions for
this task.
For more detailed information refer to the Administration Guide, IBM Tivoli
Directory Server V5.2, SC32-1339, product guide.
508 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Managing directory entries
This section details how to add and delete directory entries using the Web
Administration tool. We document the example of viewing, adding and deleting
user entries. It must be noted that this is not the most efficient method of adding
entries to the directory. Importing LDIF files is a more efficient process. For
details on how to import an LDIF file please see “Import LDIF data” on page 507.
Note: Adding a user entry in LDAP will not make that user a valid user of the
ITSO Bank secure system. For full details on user management please see
12.1.8, “User management” on page 513.
View entries
In the ITSO example the users and groups directory entries are not listed under
the Users and groups navigation section of the Web Administration Tool. This
would require additional configuration, including the creation of a realm and a
user template. Our users and groups are simply listed as directory entries under
the Directory management navigation section.
Add entries
To add a user entry to the directory do the following:
Note: Adding a user to the directory will not give that user access to the ITSO
Bank application. For full details on user management please see 12.1.8,
“User management” on page 513.
Delete entries
Note: To delete a user cleanly from the ITSO Bank secure system, the user
should be deleted from Tivoli Access Manager rather than from Tivoli
Directory Server. For full details please see 12.1.8, “User management” on
page 513.
These utilities can all be found in the <tam_home>/bin directory, and usage
details can be found by running <utilityname> -? at the command prompt or in
the Command line utilities chapter of the Administration Guide, IBM Tivoli
Directory Server V5.2, SC32-1339, product guide.
510 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
For a usage example of a client utility please see 7.5.1, “Apply Tivoli Access
Manager ACLs to new LDAP suffixes” on page 290. For a usage example of a
server utility see 12.4, “Back up and restore of key configuration files and
databases” on page 549.
Note: The AutoStart Service automatically starts each of the Tivoli Access
Manager servers if the Startup configuration is set to automatic.
This section documents some key tasks that can be performed with pdadmin.
For full details of how to perform administration tasks with pdadmin please see
chapter one of Command Reference, IBM Tivoli Access Manager V5.1,
SC32-1354.
Access pdadmin
The pdadmin tool is installed as part of the Tivoli Access Manager runtime
package and can therefore be used on any machine with the runtime installed.
Simply type pdadmin -a sec_master -p <password> at a command prompt.
User tasks
This section details the Tivoli Access Manager user show commands that may
be helpful when troubleshooting your system.
For example:
user show bsmith
For example:
user show-groups bsmith
ACL Management
For details on ACL management using pdadmin see “Grant membership to a
role” on page 524 and “Revoke role membership” on page 528.
Policy Management
For details on policy management see “Password Management” on page 517.
Junction management
For details of how to create a WebSEAL junction using pdadmin see 7.5.3,
“Create a WebSEAL junction” on page 297.
512 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Protected Object Policy (POP) management
For details on POP management using pdadmin see “Attach a POP to a
resource-role combination” on page 529.
As a result, to be a valid user in the ITSO Bank secure system, a user must have
both the specific attributes that identify them as an ITSO Bank application user
and those that identify them as a Tivoli Access Manager user. These attributes
Create users
This section documents the process for creating an ITSO Bank application user.
The process involves creating the user in the directory, followed by importing the
user into Tivoli Access Manager.
The most efficient ways to create ITSO Bank users are the first and the third
methods. We will demonstrate the first method in this section as full details on
how to create a users programmatically are available in 9.3.2, “The portlet
application using Tivoli Access Manager” on page 423.
To create a user using the second method please refer to the following sections:
“Create users in LDAP using LDIF files” on page 515
“Managing directory entries” on page 509
“Tivoli Directory Server - Command line utilities” on page 510
“Tivoli Access Manager - pdadmin” on page 511
“Tivoli Access Manager - Web Portal Manager” on page 513
“Grant membership to a role” on page 524
514 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
For another example of user creation please see 10.2.5, “Create the groups and
users for the ITSO Bank application” on page 438.
To create an LDIF file to add a user or users to the LDAP directory create a text
file with the extension ldif (for example, user_add.ldif) with user data like that in
Example 12-1.
Import the newly created LDIF file into LDAP using Tivoli Directory Server
Configuration Tool. For details on how to do this please see 7.3.3, “Import the
LDIF file (wp-itso.ldif) to create users and groups” on page 268.
Users can also be added to groups while being imported into Tivoli Access
Manager. To do this simply add the name of the group that you wish the user to
be a part of at the end of the user import command. For example, to import the
user newuser2 into a previously create group called testgroup2, type the
following at a pdadmin command prompt or insert into a pdadmin command file:
Note: The text has been wrapped in the example to fit on the page.
For another example of creating users using this method, please see the
following sections:
7.3.2, “Create LDIF file containing users and groups” on page 267
516 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
7.3.3, “Import the LDIF file (wp-itso.ldif) to create users and groups” on
page 268
7.5.7, “Import WebSphere Portal users and groups into TAM” on page 303
Delete users
The method for deleting users from the ITSO Bank secure system is somewhat
simpler than that of creating a user. Users can be deleted from the system by
using either pdadmin or Web Portal Manager. The following command can be
used at a pdadmin command prompt to delete a user:
user delete [-registry] username
For example, to delete the user newuser1 from both Tivoli Access Manager and
the Tivoli Directory Server database enter the following command:
user delete -registry newuser1
However, if the ITSO Bank wished to keep all of the unused user account data in
the directory while ensuring these users would no longer be able to access the
system, the registry flag would not be used in the delete command.
Using the Tivoli Access Manager user delete command also ensures that any
resource credentials associated with the user are also removed.
Password Management
This section documents how to manage user passwords in the ITSO Bank
system. Specifically, it explains the following:
How to set the user password policy
The method for users to initiate a password change
How to force users to change their password on first access to their account
How to reset a user’s password.
These password management procedures are all Tivoli Access Manager based
because after a user is created in a secure portal system, their access details
must all be managed through Tivoli Access Manager in order to maintain the
integrity of the system security.
For details on how to use the policy command to execute the other password
policy changes listed above, please see chapter one of the Command
Reference, IBM Tivoli Access Manager V5.1, SC32-1354.
Note: For the ITSO example, we removed the “I forgot my password” link from
the WebSphere Portal interface since it used the portal’s native password
change facility. Furthermore, you would most likely want the link on the login
form for WebSEAL in an integrated environment.
The user will be presented with a password change form where she must enter
her old password followed by her new password twice for confirmation purposes.
A password change success or failure form will then be presented, depending on
the result, and the user will be required to use the new password on her next
login to the system. For details on how to customize this page please see
“Customize the WebSEAL HTML pages” on page 519.
518 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
he has changed his password. To make this change, type the following
command at a pdadmin command prompt or add it to the pdadmin command file
used when importing the users into Tivoli Access Manager.
user modify username password-valid no
Password reset
Tivoli Access Manager administrators can reset the password of a user using
either pdadmin or Web Portal Manager. The administrator does not need to know
the user’s old password. At a pdadmin command prompt (see “Access pdadmin”
on page 511) type the following command:
user modify <username to modify> password <new pasword>
For example:
user modify newuser1 password passw0rd2
For details of how to execute this command using Web Portal Manager see
Chapter 11, “User and group management,” of Base Administration Guide, IBM
Tivoli Access Manager V5.1, SC32-1360.
User self-management
We do not provide an example in the ITSO environment of user management of
account information such as phone number, address, etc., but it should be
pointed out that account management is possible in an environment where
WebSphere is configured for read-only access to the LDAP server. An additional
database called a lookaside database could be set up via WebSphere Member
Manager as a repository for editable profile information. The setup would require
ensuring that editable attributes were stored in the lookaside database instead of
LDAP.
One of the default pages that users may come across is the 38cf0427.html page,
which documents the 403 Forbidden error. The default HTML page is shown in
Example 12-3.
Error details:
* Code: %ERROR_CODE%
* Text: %ERROR_TEXT%
-->
<html>
<head>
<meta http-equiv="Content-Type" content= "text/html; charset=UTF-8">
<!-- Enter message title -->
520 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
<title>Forbidden</title>
</head>
<body bgcolor="#FFFFFF">
<p><!-- Enter error description --> The resource you have requested is secured
by Access Manager WebSEAL.
<BR><BR><BR>
<BR>
<P><B>You do not have an account with this secure domain:</B> Please contact
your Account Administrator to obtain login and password information.
<P><B>You are logged in but still denied access to the page:</B> If you
continue to get this message, you probably do not have the correct
permissions to access the resource. Please contact your Security
Administrator for assistance.
<br>
<br>
<br>
<a href="%BACK_URL%">[%BACK_NAME% BUTTON]</a></p>
</body>
</html>
When modifying the default error message pages you must observe the following
guidelines:
Do not modify the name of the file, as WebSEAL displays the error pages
based on the hexadecimal error number.
One of the default pages that we have seen while configuring our ITSO system is
the forms-login page. The HTML for this default page can be seen in
Example 12-4.
%ERROR%
<BR><BR>
<!--- DO NOT TRANSLATE OR MODIFY any part of the hidden parameter(s) --->
522 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
<!---
The following block of code provides users with a warning message
if they do not have cookies configured on their browsers.
If this environment does not use cookies to maintain login sessions,
simply remove or comment out the block below.
--->
<BR>
<FORM METHOD=POST ACTION="/pkmslogin.form">
<FONT SIZE="+2">
<TABLE BORDER="0" WIDTH="400">
<TR>
<TD ALIGN="LEFT"><UL><LI>Username</LI></UL></TD>
<TD><INPUT NAME="username" SIZE="15"></TD>
</TR>
<TR>
<TD ALIGN="LEFT"><UL><LI>Password</LI></UL></TD>
<TD><INPUT TYPE="PASSWORD" NAME="password" SIZE="15"></TD>
</TR>
</TABLE>
</FONT>
</BODY>
</HTML>
Macro support
When modifying the default error message pages and the default account
management pages, a large number of macros are available for use. When
placed in the default HTML files, these macro strings will be substituted with the
appropriate information if relevant to that page and if macro support is enabled in
the WebSEAL configuration file. By default, macro support is enabled. To disable
support set the utf8-template-macros-enabled property to no in the content
stanza of the WebSEAL configuration file. Macros available include those to
display the authentication level, the back-url, error messages, protocol and
username. For a full listing of the macros available and their descriptions please
see the WebSEAL server configuration chapter in the WebSEAL Administration
Guide, IBM Tivoli Access Manager V5.1, SC32-1359, product guide.
524 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
when we externalized the resources of the ITSO example. The basic procedure
is outlined and an example is given.
We will use the example of granting the ITSOCustomer group membership to the
User role of the ITSO Transaction History portlet. Please note that this access is
not part of the business requirements of the ITSO Bank, nor is it a portlet that
would be appropriate for the customers to have access. It just serves as an
example that you can use to apply to any situation where you might need to grant
membership to a role after the role is externalized. We followed the above
process and executed the following commands to do so:
1. To locate the Tivoli Access Manager object that represents the combination
of the ITSO Transaction History resource and the User role, we executed the
following command at a pdadmin prompt (see “Access pdadmin” on
page 511):
object list /WPSv5
This command returned the following list of Tivoli Access Manager objects
representing all the resource-role combinations from the ITSO example (see
Figure 12-1).
You will notice that the names of these objects follow a common pattern,
namely, WPSv5_<resource type>_<resource name>_<alphanumeric
code>@<role>. From this pattern we can determine that the object that best
matches the ITSO Transaction History resource and User role combination is:
/WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User
This object, however, is an intermediate object, that is, it is not the lowest,
cell-level object of this branch of the cell tree object structure. To find the
lowest level we executed the following commands, using the output of the
previous command as input to the next command. (This is the equivalent of
expanding a non-leaf object using the Web Portal Administration tool.)
– object list “/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User”
Command output:
/WPSv5/PORTLET_DEFINITION_ITSO Transaction History_3_0_CK@User/WPS
– object list “/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS”
526 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Command output:
/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS/WebSphere_Portal
– object list “/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS/WebSphere_Portal”
Command output:
“/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS/WebSphere_Portal/cell”
– object list “/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS/WebSphere_Portal/cell”
This command did not produce any output, signifying that it is a lowest
level object.
2. To find the ACL that is attached to that object we executed the following
pdadmin command:
object show “/WPSv5/PORTLET_DEFINITION_ITSO Transaction
History_3_0_CK@User/WPS/WebSphere_Portal/cell”
This command produced the following output:
Description: WP role: PORTLET_DEFINITION/ITSO Transaction
History/3_0_CK@User
Type: 0 (Unknown)
Is Policy Attachable: Yes
Attached ACL:
WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
Attached POP:
Attached AuthzRule:
Effective ACL:
WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
Effective POP:
Effective AuthzRule:
We can see from this output that the associated ACL is:
WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
3. To view the current ACL users and groups entries we executed the following
pdadmin command:
acl show WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
The output of this command was as follows:
ACL Name: WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
Description: ACL for WP rolePORTLET_DEFINITION/ITSO Transaction
History/3_0_CK@User
528 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
WebSphere Portal resource for the secure portal solution. We investigate the
situation where the User role is no longer needed by the ITSOCustomer group
for the ITSO Transaction History portlet.
The basic procedure for removing access from a role of a resource is as follows:
1. Locate the Tivoli Access Manager object that represents the resource-role
combination.
2. Find the ACL that is attached to the object.
3. View the ACL user and group entries.
4. Modify the ACL to remove the user or group for which access is to be
revoked.
5. Test the application to demonstrate that user or group no longer has
membership of that role for that resource.
To remove all access to the Privileged User role of the Account Balance Admin
page we followed the above process and executed the following commands to
do so:
1. To locate the Tivoli Access Manager object that represents the combination
of the Account Balance Admin resource and the Privileged User role, we
executed the commands in step one of “Grant membership to a role” on
page 524 for procedure.
2. To find the ACL that is attached to the object, we executed the commands in
step two of “Grant membership to a role” on page 524.
3. To view the ACL users and groups entries we executed the commands in
step three of “Grant membership to a role” on page 524. This confirmed that
we have granted the ITSOCustomer group membership to the User role for
the this resource.
4. To revoke the role membership we modified the ACL and removed the
ITSOCustomer group. To do this we executed the following command:
acl modify WPSv5_PORTLET_DEFINITION_ITSO-Transaction-History_3_0_CK-User
remove group ITSOCustomers
5. To test that role membership had been revoked, we tried to execute the
commands listed in step five of “Grant membership to a role” on page 524.
We found that the user did not have the option of adding the ITSO Transaction
History portlet to her new page, thus proving membership had been revoked.
A POP might, for example, define what time of day the resource is allowed to be
accessed or which IP address endpoints are allowed to access the object. POPs
also allow for more complex authentication procedures to be implemented on
specific objects, for example, step-up authentication where a user may be forced
to authenticate again to step up to a higher level of authentication before being
allowed access to a specific object. This section shows how to create and attach
a basic POP to a WebSphere Portal resource in the ITSO system.
We will use the example where the User role to the Modify User portlet should
only be allowed between the hours of 9:00 p.m. and 5:00 p.m. only on weekdays.
To enforce this access we must create a time of day POP and attach it to the
object in Tivoli Access Manager that represents the User role of the ITSO Modify
User resource. To do this we did the following:
1. Created a POP using the pdadmin command:
pop create tod_0900-1700_weekdays
2. Modified the POP to only allow access between the specified times on the
specified days:
pop modify tod_0900-01700_weekdays set tod-access weekday:0900-1700:local
3. Located the object to which we were to attach the POP (see step one of
“Grant membership to a role” on page 524 for full details). From this we
determined that the object we want to restrict access to is:
/WPSv5/PORTLET_DEFINITION_ITSO Modify
User_3_0_CH@User/WPS/WebSphere_Portal/cell
4. Attached the POP to the object:
pop attach “/WPSv5/PORTLET_DEFINITION_ITSO
ModifyUser_3_0_CH@User/WPS/WebSphere_Portal/cell” tod_0900-1700_weekdays
5. To test the scenario we did the following:
a. Created a valid testuser called testuser. For details on how to create a
user in the ITSO Bank application please refer to 12.1.8, “User
management” on page 513.
b. Added the testuser to the ITSOManagers group:
group modify ITSOManagers add testuser
c. Logged into the Portal as the testuser outside the hours of 9 a.m.–5 p.m.
weekdays.
d. Navigated to the Modify User page and found that the ITSO Modify User
portlet was not displayed.
530 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
e. Logged into the Portal as the testuser during the hours of 9 a.m.–5 p.m.
weekdays.
f. Navigated to the Modify User page and found that the ITSO Modify User
portlet was displayed and available for use.
This demonstrated that the access to the resource was limited by the
conditions we set in the POP. To clean up the environment we deleted the
testuser using the following command:
user delete -registry testuser
These two steps will allow unauthenticated access to the Favicon, and thus
prevent the browser from receiving a forbidden message and producing
unexpected results when trying to access the icon.
You are now in the administrative console and can manage your application
servers.
532 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Explanation of command-line syntax:
– <username> is the username for authentication when WebSphere security
is enabled (for example, wpsbind).
– <password> is the username for authentication when WebSphere security
is enabled.
3. To leave the interactive session, type quit or exit.
Note: Script and property files can also be used with wsadmin. For detailed
information regarding the WebSphere administrative scripting program,
please refer to the following resources:
Chapter 16, “Command-line administration and scripting,” in IBM
WebSphere Application Server V5.1 System Management and
Configuration WebSphere Handbook Series, SG24-6195-01
Appendix D, “Using wsadmin scripting for security configuration,” in IBM
WebSphere V5.0 Security WebSphere Handbook Series, SG24-6573-00
You may be prompted for your admin username and password when using
these shortcuts if you have security enabled.
534 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
12.2.4 WebSphere Portal - Web administration
The Web administration interface for WebSphere Portal is the primary tool for
managing WebSphere Portal. It is the gateway to the administration portlets that
allow you perform tasks such as installing portlet applications, configuring Portal
settings, and managing access control for resources.
Note: If you log in with a user ID that does not have administrative rights,
the Administration link will not be present.
You are now on the Administration page. On the left side of the page, you will
see the five different links (clicking each link will present nested links):
Portal User Interface: Manage page hierarchy and look and feel of portal.
Portlets: Install and configure portlet applications (and individual portlets).
Access: Work with resource permissions and view users and groups.
Portal Settings: Manage overall portal settings.
Portal Analysis: Gather statistics and tracing on the portal.
You can now manage your vault segments and slots from the current location.
Note: Further details on the Credential Vault and how it can be used can be
found in the following resources:
WebSphere Portal V5.0.2 InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wpf/sec_vault.
html
A Secure Portal Extended With Single Sign-On, REDP3743, redpaper
The decision to externalize a resource depends upon the security needs of the
resource itself, as well as the overall environment of an organization. Security
administrators may have certain portlets/pages that contain sensitive data and
are considered part of the organization’s enterprise security domain.
536 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Furthermore, an organization can have other enterprise security resources
outside of WebSphere Portal, and may wish to administer them from a central
location.
538 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
e. Click Log out.
2. Verify that the TAM objects for the resource have been deleted from the TAM
objectspace:
a. Ensure that the server1 application server is started on the Policy Server
node.
b. Start the Web Portal Manager by entering the following URL in a Web
browser:
http://<tam_host>/pdadmin
c. Log on as user ID sec_master (since we only have one domain, it is not
necessary to enter the Default domain).
d. To verify the objects where created in the Tivoli Access Manager object
space, do the following:
i. Select Object Space → Browse Object Space.
ii. When the Browse Object Space page appears, expand the / (root) →
WPSv5 by clicking the + symbol, as seen in Figure 12-3 on page 539.
You should now see that the TAM objects for the resource (for
example, the YourCo pages) no longer exist in the object space.
iii. Click Sign Off in the bottom right corner of the page.
Security Administrator Allows creating and deleting role assignments for roles tied
to specific resources.
540 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Assign roles to test user for managing a portlet application
To experience Portal Access Control at work, you can do the following
procedure. The following steps assume that you have a test user created in your
LDAP directory (for example, we created authtestuser) and the Reminder portlet
is installed on the WebSphere Portal server. Our goal will be to allow a test user
to manage a portlet application (Reminder) with the Manage Applications portlet.
In order to reach this goal, we will need to assign the following roles to our test
user via the Resource Permissions portlet:
User@Reminder Web module: Permits test user to see the information that is
contained in a the Web module and to use the Manage Applications portlet to
navigate to the portlet applications that are contained in this Web module
Manager@Reminder portlet application: Permits test user to manage the
portlet application
User@Manage Portlet Applications portlet
User@Manage Applications page
Note: Rather than explicitly assigning the user to the role for each
resource, you could simply add the user to a group that already has the
needed role(s) via LDAP. However, for our example, we will show the
explicit assignments of roles in order to display the process of using the
Resource Permissions portlet to assign access.
542 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
c. You should see the Manage Applications page. Click the key icon next to
the page to assign access.
d. Click the pencil icon for the Manager role located on the right side of the
page.
e. Click Add.
f. Select the following values and click Search:
• Search for Users or User Groups: Users
• Search on: uid
• Search for: <username> (for example, authtestuser)
g. Check the Select box for the test user and click OK.
h. Click Done → OK → Done to get back to the Resource Types page.
i. Click Log out.
5. Verify that the test user can access the portlet application:
a. Access WebSphere Portal by entering the following URL:
https://<webseal_hostname>/portal/wps/myportal
b. Log on as the test user (for example, authtestuser).
c. Click the Administration link in the top right corner of the page
Note: By giving the test user the role User@Manage Applications page,
he is actually able to see the Administration link when he logs in.
However, he will not have access to the other administration portlets
unless he is assigned access to each portlet.
d. You should now see the Manage Portlet Applications portlets displayed on
the Manage Applications page. Click the Reminder Portlet portlet
application. You should see a page similar to Figure 12-4.
From this interface, your test user can now manage the Reminder portlet
application.
544 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
XMLAccess can be used for the following purposes:
Export an entire portal configuration or parts of the configuration to an xml file.
You can then import this file into another portal in order to recreate the
desired configuration.
Install additional resources to the current portal.
Perform common administrative tasks in a scripted manner.
In order to use the XMLAccess configuration interface, you must have the
manager role on the virtual resource XMLACCESS, as well as the administrator
role on the virtual resource PORTAL.
Note: You may have to adapt the PATH settings in the .bat file to point to
your Java runtime. The XMLAccess.bat and tools.jar are initially placed in
the <wp_home\bin directory during the WebSphere Portal installation.
Note: The <xml_file> must be created and reside in the working directory
(or you can specify a path to the file in your command line) prior to running
XMLAccess.
546 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
type="export"
export-users="false">
<!-- This exports the complete portal configuration (not including users).
Exporting users is not desirable when you transfer configurations
between different portal installations because the systems should be configured
to use the same LDAP. It may, however, be useful when transferring
configurations between development installations. See also: ExportAllUsers.xml
-->
<portal action="export"/>
</request>
Note: For details on how to start up and shut down the application servers
please refer to “Starting and stopping the application server” on page 533.
When shutting down the system, the following order should be followed:
1. Reverse Proxy node
This node could be stopped either first or second.
– Tivoli Access Manager Proxy Server (Windows services)
2. Portal Server node
– Applications servers (server1 and/or WebSphere_Portal)
– IBM HTTP Server (Windows services)
– DB2 (Windows services)
548 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
3. Policy Server node
– Tivoli Access Manager Authorization Server (Windows services)
– Tivoli Access Manager Policy (Windows services)
– IBM Directory Server and admin daemon (Windows services)
– DB2 (Windows services)
12.4.1 Backup
This section documents the basic procedure for backing up configuration data
and databases on the three nodes.
To back up the Tivoli Directory Server on the ITSO Bank system we executed the
following command:
c:\ibm\LDAP\bin\dbback -d c:\temp -w tdsbackup
To back up the Policy Server on the ITSO system execute the following
command:
pdbackup -action backup -list “c:\ibm\tivoli\Policy
Server\etc\pdbackup.lst”
The output of the command is recorded in a log file, the location of which is
specified on command completion. A return code of zero indicates a successful
backup.
The Tivoli Access Manager pdbackup tool should be used when backing up
Tivoli Access Manager configuration files. Use the following command to back up
the WebSEAL files on the ITSO system:
pdbackup -action backup -list “c:\ibm\tivoli\PDWeb\etc\amwebbackup.lst”
550 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The output of the command is recorded in a log file, the location of which is
specified on command completion. A return code of zero indicates a successful
backup.
We will provide the general procedure for backing up DB2 databases via a
command line as well as via the Control Center:
10.Click Finish.
11.The Backup Wizard will close and the Progress window will open.
552 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
12.After a few minutes a window with the completion status of the backup will
open.
This command will stop all running processes, but it will not restart them once the
backup is complete. You will need to manually restart the desired processes.
12.4.2 Restore
This section documents the basic procedure for restoring the backed-up
configuration data on three nodes.
To restore the Tivoli Directory Server on the ITSO Bank system we executed the
following command:
c:\ibm\LDAP\bin\dbrestore -d c:\temp -w tdsbackup
Where the parameter file is the path to the archive created when backing up the
system. See “Policy Server node” on page 549 for details on the archive file
names.
To restore the Policy Server configuration on the ITSO system, execute the
following command:
pdbackup -action restore -file “c:\ibm\tivoli\Policy
Director\pdbackup\pdbbackup.list_<date>.time.dar”
The output of the command is recorded in a log file, the location of which is
specified on command completion. A return code of zero indicates a successful
restore.
554 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
To restore the Proxy Server configuration on the ITSO system, execute the
following command:
pdbackup -action restore -file
“c:\ibm\tivoli\PDWeb\pdbackup\amwebbackup.list_<date>.time.dar”
The output of the command is recorded in a log file, the location of which is
specified on command completion. A return code of zero indicates a successful
restore.
Note: If the codeset and territory are not specified, you cannot be sure that
the DB2 create database command will create the database with the
desired locale information.
Information on the desired codeset and territory can be found in the DB2
command reference.
5. To restore the database, enter the following from a DB2 command window:
db2 restore db <wc_dbname> from <path>
For example:
db2 restore db wc1db from c:\ibm\dbbackup
If you only need to restore parts of the configuration, you can strip out parts
of the export_result.xml file prior to the import. For more details, please
refer to WebSphere Portal V5.0.2 InfoCenter at:
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wps/admxmla
i.html
556 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
12.5 Verifying the ITSO Bank application and runtime
This section steps through the use cases to verify that the ITSO Bank system
has met the specified requirements. Selected uses cases have been chosen to
demonstrate key functionality that has been implemented. Please note that not
every use case will be documented.
2. The system receives the login request and makes the authentication and
authorization decision.
3. The system creates the user credential.
4. The actor is logged in.
558 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 12-7 Actor is logged in
2. The actor fills out the new user’s information in the form. The compulsory
fields are Userid, Password and Date of birth.
560 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 12-9 Actor fills out information in form
562 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 12-12 User data added
2. The actor types in the user ID of the customer in question and clicks Query
User.
564 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 12-15 Confirm user modification
566 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure 12-17 Account balance is displayed
568 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
5. The system performs the transfer and updates the information in the
database. The confirmation is displayed.
Part 3 Appendixes
Login problems
After entering your credentials into the login form and pressing Submit, you are
reprompted with the login form. You have verified that you are using the correct
user ID and password. We will address four causes of this issue.
574 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
problem, please apply Critical Update 831167 from Microsoft’s support site.
Details and a downloadable fix are available on Microsoft’s support site:
http://support.microsoft.com/default.aspx?kbid=831167
This issue can occur in Microsoft’s Internet Explorer 6 due to a problem with the
SetCookie function. To resolve the issue, you can obtain the latest service pack
and follow the instructions on Microsoft’s support site:
http://support.microsoft.com/?kbid=310676
Session timeouts
It is quite common in an integrated environment involving WebSphere Portal and
Tivoli Access Manager WebSEAL for unexpected results to occur due to session
timeouts. These unexpected results can include:
Error messages requesting the user to establish a new session
Prompting the user for credentials when clicking the Log out button
Not prompting the user for credentials when clicking the Log in button
These results occur because both the portal and proxy servers establish a
session with the user independently of each other. For details on the specific
sessions, refer to 4.2.8, “WebSEAL and WebSphere Portal session
considerations” on page 114. It is possible to configure the portal and proxy
servers to handle the session timeouts in a way that avoids these unexpected
results. For an example of this configuration, please refer to the modifications we
made to the ITSO example in 7.8.1, “Configure WebSEAL and WebSphere
Portal sesssion timeouts” on page 356.
576 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Recovering from lost administrator privileges to the portal
There are various ways for a WebSphere Portal administrator to get into trouble
by removing administration access to the WebSphere Portal. We will discuss two
issues and explain how to rectify them.
A user becomes an administrator within the portal through a role mapping for the
Administrator role on the virtual resource PORTAL or via direct membership in a
group that has such a role mapping. If the following property is set to true, users
will also inherit access rights from groups of which they are not direct members
via nested membership:
accessControlDataManagement.enableNestedGroups
Note: If the portal administrator group (for example, wpsadmins) was not
deleted or the role mappings of that group were not deleted, the best solution
is to add members to this group directly in the LDAP. The new members
become portal administrators after their next login to the portal.
Note: Only one portal administrator user ID should have the OID 10, and
one portal administrator group should have the OID 11 in the USER_DESC
table to guarantee the correct function of Portal.
b. If the result of the previous query was not empty, run the following:
DELETE FROM USER_DESC WHERE OID=10
SELECT * FROM USER_DESC
578 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
c. Check if the result contains an entry that contains the intended admin
user's distinguished name (one of the following):
• uid=wpsadmin,dc=users,dc=itso,dc=ibm,dc=com with security enabled
• uid=wpsadmin,o=default organization with security disabled.
If you actually tried to log into the portal with this user, the entry will be
there.
d. If the entry is there, run the following:
DELETE FROM USER_DESC WHERE OID=[oid of the entry found in step 3]
INSERT INTO USER_DESC (OID, NAME, TYPE, CREATED, MODIFIED) VALUES (10,
'[dn of the user found in step c]', 9, 1022882400000, 1022882400000)
INSERT INTO LNK_USER_ROLE (USER_DESC_TYPE, USER_DESC_OID, ROLE_INST_OID)
VALUES (9, 10, 1)
e. Restart WebSphere_Portal application server.
2. Check administrative user group.
a. Connect to the WebSphere Portal database using a database client:
CONNECT TO WPS50 USER [dbuser] USING [dbpassword]
SELECT * FROM USER_DESC WHERE OID = 11
If the result is empty or the distinguished name contained in the name field
of the result does not match the distinguished name of your intended
admin user group, proceed with the following.
b. If the result of the previous query was not empty, run the folloiwng:
DELETE FROM USER_DESC WHERE OID=11
SELECT * FROM USER_DESC
c. Check if the result contains an entry that contains the intended admin user
group’s distinguished name (one of the following):
• uid=wpsadmins,dc=users,dc=ibm,dc=com with security enabled
• uid=wpsadmins,o=default organization with security disabled
d. If the entry is there, run the following:
DELETE FROM USER_DESC WHERE OID=[oid of the entry found in step 3]
INSERT INTO USER_DESC (OID, NAME, TYPE, CREATED, MODIFIED) VALUES (11,
'[dn of the user found in step c]', 9, 1022882400000, 1022882400000)
INSERT INTO LNK_USER_ROLE (USER_DESC_TYPE, USER_DESC_OID, ROLE_INST_OID)
VALUES (8, 11, 1)
e. Restart WebSphere Portal server.
In order to address the problem, you can do either of the following steps to
modify the <was_root>/properties/soap.client.props file:
In the SOAP Client Security Enablement section of the file, enter the
authorized user after com.ibm.SOAP.loginUserid= and enter the password
after com.ibm.SOAP.loginPassword= .
Stop the server with the stopServer command including credentials. Refer to
“Starting and stopping the application server” on page 533.
Note: The first option would be less secure since you are placing a password
in a file on the file system.
If you do not complete either of these steps, the Java process for the
WebSpere Portal Application Server JVM will remain active, and the following
error might be logged in <was_home>\logs\<app_server>\stopServer.log:
ADMU0111E: Program exiting with error:
javax.management.JMRuntimeException:
ADMN0022E: Access denied for the stop operation on Server MBean due to
insufficient or empty credentials.
580 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
BUILD FAILED
file:../config/actions/dbt_cfg.xml:925: Java returned: 3
You can find more information as to why this error occurred by examining the
earlier sections of the import task output:
[java] Formatting Exported Item (215) CTAREQUESTATTRS
[java] Formatting Exported Item (216) CMACTIVITY
[java] Formatting Exported Item (217) WPCPMETADATA
[java] java.io.FileNotFoundException:
/opt/WebSphere/PortalServer/config/DBTransfer/wps/[WCM.SCHEMA].LOCKS.exp
(No such file or directory)
[java] at java.io.FileInputStream.open(Native Method)
[java] at java.io.FileInputStream.<init>(FileInputStream.java:91)
[java] at java.io.FileInputStream.<init>(FileInputStream.java:54)
[java] at
com.ibm.wps.config.db.transfer.DumpDatabaseSchema.process(DumpDatabaseSc
hema.java:945)
[java] at
com.ibm.wps.config.db.transfer.DumpDatabaseSchema.main(DumpDatabaseSchem
a.java:1147)
The problem can occur due to the optional creation of the LOCKS table provided
by wpcp during the database transfer. In order to address this problem, you can
attempt one of two options:
Modify the database tables template.
– Edit the file <wp_home>/config/templates/db/wpstableslist.txt and delete
the line that includes [WCM.SCHEMA].LOCKS.
– Rerun the configuration task:
<wp_home>/config/WPSconfig database-transfer-import
Verify that the PTF configuration task was run successfully after installing the
latest fixpack for WebSphere Portal. If it did not complete successfully, you
may run into this error.
Instead of:
adminPassword="5mApqlzuuPW7iNQpYWkEKQ=="
WebSphere Member Manager (WMM) accepts both clear text passwords and
encrypted passwords, but for clear text passwords, you will see the exception in
the log.
http://publib.boulder.ibm.com/pvc/wp/502/ent/en/InfoCenter/wpf/sec_was_di
s.html
582 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table A-1 Example wpconfig.properties for disabling security
Section in Keyword ITSO example value
wpconfig.properties file
PortalAdminIdShort wpsadmin
PortalAdminPwd <password>
PortalAdminGroupId cn=wpsadmins,o=default
orgainization
Note: If the admin console is not accessible, but you are able to start/stop the
application server, you can use wsadmin to disable security as follows:
1. Run the following command and press Enter:
<was_root>/bin/wsadmin -conntype NONE
2. Type the following and press Enter after each command:
securityoff
exit
You can run the tool to verify your LDAP settings. For example, we can run the
following:
ldapsearch -h tamwin1.itso.ral.ibm.com -p 389 -b "dc=itso,dc=ibm,dc=com" -D
"uid=wpsbind,cn=users,dc=itso,dc=ibm,dc=com" -w "<password>"
“(&(uid=wpsbind)(objectclass=inetOrgPerson))"
Explanation of options:
h: Host name for LDAP server
p: Port number for LDAP server
b: Base dn for search
D: Bind dn
w: Bind password
584 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
(&(uid=wpsbind)(objectclass=inetOrgPerson)) is the search filter that includes
the entry to be searched.
Note: The parameter -Z can be used with the ldapsearch command to use a
secure ldap connection via SSL. The command ldapsearch -? can be used to
list all of the options for the tool.
Graphical tools
Two graphical tools that can be used to query an LDAP server include:
Microsoft’s LDP: Details on the usage of this tool can be found at:
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.
com:80/support/kb/articles/q224/5/43.asp&NoWebContent=1&NoWebContent=1
Java LDAP Browser: Details on the usage of this tool can be found at:
http://www.iit.edu/~gawojar/ldap/
586 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Encrypt an existing password string by directing an encoder towards the
target file and field. For example:
a. Open a command prompt and change to the <was_home>/bin directory.
b. Encrypt the existing password in the target file by entering the appropriate
command:
PropFilePasswordEncoder.bat <filename> <property_name>
Name: SystemErr.log
Description: Records exception stack trace information that can be used to
troubleshoot a problem with the application server
Name: error.log
Description: Records errors that occur in IBM HTTP Server.
588 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: Detailed information on logging for WebSphere Application Server and
IBM HTTP Server can be found in the following locations:
Chapter 15, “Troubleshooting,” in IBM WebSphere Application Server V5.1
System Management and Configuration WebSphere Handbook Series,
SG24-6195-01
Log Files - Apache HTTP Server:
http://httpd.apache.org/docs/logs.html
Name: SystemErr.log
Description: Contains exception strack trace information for the
WebSphere_Portal application server
Note: Further details on Tivoli Access Manager logging and routing and XML
output for logging and auditing logs can be found in chapters 17 and 18 of the
Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360.
590 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Tivoli Access Manager event logging
For auditing and other serviceability purposes, other than messages produced
when starting a Tivoli Access Manager server, all messages generated by Tivoli
Access Manager are created in a structured hierarchy of events. Logging of
these events can be configured in the aznapi-configuration stanza of the
configuration file of each server. For further details refer to chapter 19 of the
Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360.
Note: When the trace string is added via the WebSphere Portal Web
administration, the tracing will only be active until the application server is
restarted. Since we will also be enabling WMM tracing for this example and
it requires an application server restart, we have enabled the trace in the
properties file so that the trace will still be present after the server restart.
Once the server is restarted with the new settings, you will find a trace.log file in
the <wp_home>\log directory.
592 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Tracing authorization issues
When a user runs into problems accessing a resource, the source of the issue
may be the permissions that the user has on the resource. To troubleshoot this
possibility, tracing can be enabled.
Note: Since we enabled the portal tracing via the portal administration
interface, the tracing is active automatically. However, once the server is
restarted, the tracing is disabled. If you wish the tracing to last beyond the
current server session, refer to “Enabling authentication trace via portal
administration” on page 592 for the procedure.
Note: When you are finished collecting traces, remember to remove the trace
string and restart the application server. Traces can negatively affect
performance and result in very large log files.
PQ77683
Descriptions of this item follow:
Resources that do not have a Unique_Name specified do not have a title in
the role names in the external security manager. The title of the default locale
will now be used if no Unique_Name is defined for the resource.
When a resource is externalized without an existing role, it will neither show
up in the resource permissions portlet, nor will a role for this resource be
visible in the external security manager. Now the administrator role is
automatically created during externalization. The administrator role will
therefore be visible in the external security manager.
The role name in the external system was built in the order
RoleType@ResourceType_ResourceName_ObjectID. Due to this, the
594 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
resources were difficult to find in the external security manager. Now the
property accessControlDataManagement.reorderRoleNames in the file
<wp_home>/shared/
app/config/services/AccessControlDataManagement.properties controls how
the role names are built. If the flag is set to true, the role name is built in the
order ResourceType_ResourceName_ObjectID@RoleType.
PQ79613
Descriptions of this item follow:
If an XMLAccess request sets a resource to an externalized state and
specifies role mappings for this resource, an exception occurs.
If an XML request specifies a parent resource as externalized, all child
resources are also externalized, even if the XML request does not specify
this.
PQ79684
Description: It is not possible to externalize resources of the Resource type Page
and URLMapping.
PQ79819
Description: After installing PQ77683, WebSphere Portal cannot be accessed
anymore.
PQ79938
Description: If an XML request first creates role mappings for a resource and
then externalizes that resource and you run the XML request once more, an
exception occurs.
PQ80428
Description: The role mappings that user groups have for a resource that is
externalized are not transferred to the external security manager if the user
groups do not have the common name property defined in the LDAP.
PQ83717
Description: When externalizing a resource, only the roles/role mappings that
existed before the externalization took place are externalized. This means that if
the administrator in the external security manager wants to assign a principal to a
resource for a role that was not externalized, he has to use WebSphere Portal
again to create the roles. This is very inconvenient for the external security
manager’s administrator, especially because he is usually not the WebSphere
Portal administrator.
PQ86200
Title: PQ86200 TAM protected object space entries are all one protected object.
Description: The externalization model for WebSphere Portal 5 includes the
creation of three levels of child objects under the role object to indicate
context. This fix allows the context information to be omitted if desired.
Description: This option allows for multiple WebSphere Portal servers to
share the same Tivoli Access Manager (TAM) object space by permitting an
additional TAM container to be inserted between the WebSphere Portal root
object and the role objects.
The parameter in the ExternalAccessControlService.properties is as follows:
externalaccesscontrol.instance=<TAM_object_container>
Omitting this parameter just means that it will not be used.
Description: This option increases the use of TAM inheritance for WebSphere
Portal roles by allowing WebSphere Portal to be configured to search for the
rolename component of the TAM object name in the results of the TAM
entitlements query when determining access rights for a user.
The parameter in the ExternalAccessControlService.properties is as follows:
externalaccesscontrol.allowSubStringSearch=false
596 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
B
Note: For more information on single sign-on refer to 4.1.3, “Single sign-on
guidelines” on page 96.
Note: Mutual SSL in this example is not required when using LTPA.
LTPA configuration
This section outlines the configuration tasks needed to set up LTPA for single
sign-on. The majority of the steps are common to the procedure used to
configure TAI.
598 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Define additional MIME types for WebSphere Application Server
For details refer to 7.5.2, “Define additional MIME types for WebSphere
Application Server” on page 296.
Note: For scenarios using the internal HTTP service built in to WebSphere
Application Server (development WebSphere Test Environment or no external
Web Server), update the port to 9081 for HTTP instead of port 80 in the
wp-junction-ltpa.pd (see Example B-1).
600 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: When creating the junction, WebSEAL will attempt to connect to the
back-end system (for example, WebSphere Portal). If the system is not
available, you will see the following message:
DPWWA1222E A third-party server is not responding. Possible causes:
the server is down, there is a hung application on the server, or
network problems. This is not a problem with the WebSEAL server.
DPWIV1054E Could not connect
602 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
C
Both SCM plug-ins are installed with the default WebSphere Studio Application
Developer installation, the SCM Server products are not installed. The built-in
CVS client support includes CVS Team Provider Core 2.0.0, CVS SSH Core
2.0.0, and CVS Team Provider UI 2.0.1 plug-ins.
We selected CVS for the ITSO example for several reasons. First, we wanted to
use a SCM tool that people could easily download for free. Second, we wanted to
keep the software configuration management within this redbook at a basic level
so that it would not detract too much from the core WebSphere Portal
development. Finally, CVS is relatively easy to use and many people are already
familiar with how to install, configure, and use it.
It stores all the versions of a file in a single file using forward-delta versioning,
keeping only the most current version and differences from earlier versions.
It insulates the different developers from each other. Every developer works
in his own directory, and CVS merges the work in the repository when each
developer is done. Conflicts should be resolved in the process.
604 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
It keeps your shared projects’ data in repositories. Each repository has a root
directory on the file system.
CVS maintains a history of the source code revisions. Each change is
stamped with the time it was made and the user name of the person who
made it. It is recommended and good practice that developers also provide a
description of the change. Given that information, CVS can help you find who
made the change and when it was made and why.
Depending on the version, different bugs may occur. In our case, we used
CVSNT 2.0.4 without any problems.
CVSNT was ideal for our environment because we had a pure Windows
environment, and it is easy to use. We did not experience any significant
problems using the CVSNT version.
606 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Figure C-1 CVSNT service configuration (Service Status page)
608 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
8. Select the Advanced tab. Do the following and then click Apply (see
Figure C-4 on page 608):
– Check Server side support for ntserver protocol.
– Check Impersonation enabled.
– Check Use local users for pserver authentication instead of domain
users.
CVSNT uses either the domain or the local server directory for user
authentication under the pserver protocol. You have to choose the correct
value for your environment. This setting only applies if your machine is
connected to a Windows domain.
9. Select the Services Status tab. Click Start for the CVS service and CVS
Lock service. The status should change to Running.
Note: As mentioned when configuring the CVS repository, you can choose
between local accounts or domain accounts (we used local accounts). Within
the development environment example we are not focused on security for
CVS. In a production environment, we recommend that you refer to the CVS
documentation to secure your environment for your needs.
For the ITSO development environment, we create one Windows user for each
CVS user as follows:
1. To add the Windows user for each developer using CVS, do the following:
a. Add the desired CVS user to Windows on the Build and SCM node by
clicking Start → Settings → Control Panel → Administrative Tools →
Computer Management.
b. Select Local Users and Groups → Users.
c. From the menu bar, click Action → New User.
d. We created a user called boog.
e. Add boog to the group Power Users.
f. We repeat the same for the user manekar.
610 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Set CVS DTD file extension to ASCII
We discovered when adding DTD files to the CVS repository that by default the
file would be added as a binary file. This is not the desired or expected behavior.
To address this issue, we did the following:
1. From within WebSphere Commerce Studio Workspace, select Window →
Preferences.
2. Select and expand Team → File Content.
3. Click Add, and enter dtd in the file extension text box, then click OK.
When done, you should see dtd file extension listed as ASCII content type.
This will make sure that the icons of any resource that is under source control will
get a small cylinder icon, the release number appended to the resource name,
the file type (ASCII/Binary), and a greater-than sign (>) in front of the resource
name if the file is locally modified and therefore not in synchronization with the
repository. If the resource is not under source control, it will have a small
question-mark added to its icon, signifying that the file is unknown to CVS.
612 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
D
There are generally two choices when it comes to deploying a unit. Either you
deal with the complexity of configuring it when building the unit, or you defer until
later during deployment to deal with it. This is a sliding scale and constraints are
usually what ultimately decide where on the scale a unit ends up.
The following three requirements exist in most any project and will be the driving
force when we approach automation pertaining to deployment of our ITSO Bank
sample application:
Traceability
Knowing what components you have deployed and being able to trace them
back to source in a repository.
Maintainability
The simplification of administrative chores such as configuration, packaging,
and deployment processes, aimed at reducing the probability that
errors/defects appear due to high complexity. As the portal application grows
and the number of deployment nodes increase, so does the complexity and
administrative difficulty.
614 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Reproducibility
Being able to reproduce a given version of the application with a given
configuration for different deployment nodes. For example, nodes in
development, test, or production environments.
We will limit the scope of our discussion of the component types in this appendix
to what is relevant from a packaging and deployment standpoint. Focus will be
on our ITSO Bank sample application developed in this book, but some
comments will be made for how to manage situations that are likely to occur in
various projects, but were not specifically addressed while creating our example
application.
Terminology
Table D-1 on page 616 provides a definition of key terms used throughout the
appendix to provide a context and meaning. The domain of build and deployment
bridges the development and runtime domains. We have attempted to use terms
for concepts which are distinct and not to be confused with concepts with the
same name in other domains.
Solution The result of all custom development effort aimed at solving one or
more business requirements.
Portal application One or more portal components that run on a WebSphere Portal
node. Essentially a subset of the solution.
Tooling
The majority of the ITSO automation scripts have been developed using Apache
Ant. The reason we choose Ant is because it is a very flexible tool, easily
extensible, and is used by WebSphere Portal and WebSphere Application Server
as a base for their respective configurations. In addition, it is also freely availably,
616 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
and there are many developers familiar with Ant, as it has become the tool of
choice for deployment.
As Ant is a Java-based tool, it will run on a lot of different platforms; in fact, any
platform for which a Java Development Kit is provided. Since we will be working
with WebSphere Application Server and Portal technology, we will have
additional constraints, since we are dependent on certain libraries provided by
these two products. Thus, a build or deployment node requires these products to
be installed.
Deployment walkthrough
This section walks you through the steps involved in starting a WebSphere Portal
project and includes adding, building, and deploying components. Some of the
steps are similar, or just an alternative way of doing the same thing, as has
previously been described in Chapter 10, “Deploy the secure portal application”
on page 433. As with all automation, we will begin by relying on manual
processes, and thus will reference the manual steps during the phase where we
create the components. The real benefit of this excercise comes when doing
repeated deployments.
This section assumes that WebSphere Studio Application Developer has been
set up on the current working environment. If not, refer to Chapter 8, “Implement
the development environment” on page 361, for details for setting up the
development environment.
Solution structuring
The ITSO Bank portal application will consist of one Portlet Application and four
custom pages. This implies that the component types we will be concerned with
are the following:
Portlet Applications
Grouping of related Portlets
Pages
Composition of content areas and navigation
Environment Configurations
Specific configurations for the target environment
One of the goals with our setup is to make it self contained. That is, we should be
able to build, package, and deploy using only the assets contained in the project
directory structure. Having all dependent libraries within in the project also helps
avoid incompatibilities between library versions, which might otherwise occur if
developers are using their own selection of external libraries.
618 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: Actually, we have dependencies on libraries outside the project, the
libraries provided by WebSphere Portal and WebSphere Application Server.
We bend the rules for self-containment here in order to abide the licensing
agreement for the products. However, if the license for a dependent entity
allows you to include it in the project and use it as part of your build and
deployment scenarios, then we would recommend that you do so.
Preparation
WebSphere Portal Test Environment contains a basic but functional runtime
environment configuration, and you will start by backing up the current
configuration by serializing it to an XML document. This will enable us to revert to
the current configuration should something go wrong at any point while modifying
the WebSphere Portal configuration.
After having serialized the WebSphere Portal configuration, we will initialize the
solution working area, which will configure the starter kit for the environment we
are currently working in.
There is now a file named init-env.bat in current directory. This file contains
environment variables used by the starter kit in order to find needed libraries and
for proper directory navigation. Copy this file to your desktop and use it instead of
starting an ordinary console window from now on when working with the build
files.
Note: If you try to execute a build file without having the needed environment
variables set, Ant will fail immediately, stating that the needed environment
variables are not available. For this reason, always use the init-env script
when you want to work with build files relying on the starter kit.
620 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Populating the solution
Now we have an initialized solution working area without any components, so it
is time to fill it with the components we will be using.
Note: With the starter kit we have created directories for the WebSphere
Studio Application Developer projects we use in this redbook and populated
them with pre-edited build.xml files in order to make this walkthrough feasible.
In a real project you would start by removing all directories under
wsad\projects, followed by copying a template build.xml file from
wsad\templates to the corresponding component’s directory. Developers will
likely want to edit the component build files in order suit their particular
components. These templates work as a starting point for them.
Creating pages
We will be using WebSphere Portal’s page administration portlet in the Web
interface, since we are creating an initial page hierarchy. Begin by following
10.3.5, “Create portal pages” on page 451, through 10.3.6, “Add portlets to
pages” on page 453 to create the pages and assign the portlets to them. Then
give the top page in the new page hierarchy (the page titled itsobank), a custom
unique name so that we can reference it later via xmlaccess. This is done as
follows:
1. In the Web administration interface menu on the left side of the screen, click
Portal settings → Custom Unique Names.
2. In the resource type list, click Pages.
3. In the search field titled Search For, input ITSOBank and click Search.
4. Click the pencil icon (Edit unique name or Page) to the right on the screen.
5. In the field titled Custom name, enter itso.page.itsobank and click OK.
622 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Modifying resource permissions
Follow the instructions in 10.3.7, “Modify resource permissions” on page 459,
through 10.3.8, “Verify ITSO Bank application” on page 467.
Now we will serialize the configuration of the pages together with their assigned
permissions. The result will be two XML documents, one containing the page
composition and the other the access control information.
1. Open an initialized console window by double clicking the file init-env.bat
located on the desktop.
2. Change to directory of the pages component:
cd c:\6325sol\ui\pages directory
3. Run the following command (all on one line), which will export the pages and
associated access control directives to two XML files:
wpdsk-util -Dtargetenv=wpwin1 -Dexport.pageroot=itso.page.itsobank
export-pages
4. Rename the file exported_pages.xml to pages.xml.
5. Rename the file exported_access-control.xml to access-control.xml.
Next we will serialize the access control for the Portlet Application component.
The result will be an XML document containing the access control configuration.
1. Change to the ITSOBankWAR component directory:
cd c:\6325sol\wsad\projects\ITSOBankWAR
2. Once again we will let the wpdsk-util command assist us:
wpdsk-util -Dtargetenv=wpwin1 export-pages
3. Rename the file exported_access-control.xml to access-control.xml.
You now have the pages component and the WebSphere Studio Application
Developer components comprising the WebSphere Portal part of the application
set up for automatic build and deployment. You can deploy any of the
components to any environment remotely by mounting an SMB share (Windows
file share) to the current environment and creating a build.properties file for the
624 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
environment. If you do not have the ability to mount a share from the target host,
then you can create a solution archive, transfer it to the target host, unpack the
archive, and deploy the components, as described in “Deploying from the target
host” on page 641.
Component types
Here we touch on some of the key portal concepts and how they relate to
deployment units.
Portal services
A Portlet service is an implementation of the PortletService interface, making it
possible for portlets to share the implementation. The portlet service is from a
deployment perspective, essentially a utility library. This library has certain
specific deployment requirements. It must be deployed from the WebSphere
Portal into the <wp_home>/shared/app directory. Additionally, it must be added
to the application server’s WPSLib shared library, and also receive a registration
entry in
<wp_home>/shared/app/config/services/PortletServiceRegistryService.propertie
s. For further details, refer to the WebSphere Portal 5.02 InfoCenter.
The container for a Portlet Application is a J2EE Web Archive, also referred to as
a war file, due to its extension.
Table D-2 shows a typical structure and elements of a Portlet Application Web
Archive.
WEB-INF/classes Optional. Directory containing the compiled Java code for all
portlets within the Portlet Application
Note: In order to support different markups and locales, you can optionally
create further directories within the jsp folder, such as jsp/<markup>/<locale>.
So for example, if we need to support html and the German locale, we would
create two additional sub directories like jsp/html/de, and put our content in
the third-level directory.
User interface
The user interface components consist primarily of four different types: Themes,
skins, screens, and pages. The first three can be made to render their visual
representation differently, depending on the specifics of the client accessing
WebSphere Portal.
Screens
This is the area of the portal that typically displays portlets, but can also display
other content in its place, for example, a login form or error message. Screens
are selected from navigation icons in the theme.
626 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Themes
Themes determine the look and layout of the portal, including colors, fonts, and
images outside of the portlet content area. Themes often provide the initial
navigation to portal pages.
Themes are divided into separate directories, one for each theme. At least one
Java Server Page file named Default.jsp must exist for each theme. This file can
be seen as the entry point for the rendering of a page.
Skins
Skins represent the border rendering around components, such as the
navigation provided by the theme, containers, or portlets. Skins also provide
navigation themselves, to levels deeper than the navigation that is provided by
the themes. Skins are installed independently from themes. However, the
administrator can set a default skin for a theme.
Skins are partitioned into their own directories, which hold all elements specific to
a certain skin. Inside its directory, at least one file is required, a Java Server
Page file named Control.jsp. This file is responsible for rendering the skin area.
Skins have a relationship to themes, in that a theme is what is triggering the
rendering of a skin and that a theme can be configured with a default skin.
Pages
This is a form of configuration of WebSphere Portal governing the navigational
structure of the portal, also acting as containers for portlet instances, dictating
the layout of the portlets. A page have no file system resource representation,
and thus does not require anything to be deployed to the target node’s file
system.
The requirements for each component are that it should be able to build,
package, and optionally configure for a target environment. In some cases,
depending what type of component it is, it should also be able to deploy itself
and, if so, also undeploy as well. Additionally we place the same requirements
for the solution, so that it should be possible to perform a build and deployment
on a solution-level or component-type level. These requirements make the
solution easy to administer for different kinds of job roles. For example, a portlet
developer might simply want to create the pages in his private WebSphere Portal
Test Environment, and can thus issue the Pages component to deploy itself to
that environment. Another example is when the team wants to deploy the entire
solution to another environment. They can then issue the entire solution to
deploy itself to a specified node/target environment.
The starter kit scripts are primarily based on Apache Ant. Each element of the kit
is either an XML or XSL document, or a plain text property file. The goal of
sticking to these three types of documents was to make it accessible for as many
people as possible to understand and modify the kit in order to satisfy particular
needs. Also, using existing libraries instead of writing custom ones ensures that
the starter kit will be usable even when new versions of WebSphere Application
Server, WebSphere Portal, or WebSphere Studio Application Developer come
out.
628 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Note: Some modifications might still be required if the middleware is
upgraded. However, in our view the cost of modification will likely be lower
compared to the cost had we solved the problems by providing custom
libraries instead of sticking to the previously mentioned document types
coupled with functions provided by the middleware.
Project structure
The structure of the project is designed to group similar items logically. The main
groups are configurations, support tools, user interface, and WebSphere Studio
Application Developer projects. This separation is done since different people
are likely to be working with different aspects of the solution. A portlet developer
is likely to work with components inside WebSphere Studio Application
Developer’s workbench, and thus needs the component structure to be
compatible with that tool. A graphics designer, on the other hand, might use
other tools, giving another set of requirements regarding the file structure; thus
the separation of user interface and WebSphere Studio Application Developer
components. Configuration is managed on a solution global level, making
administration easier, and ensuring that all components are properly configured
for the targeted environments.
tools/lib Optional libraries that are needed in order to build the solution.
Used by the starter kit, but is a proposed place to store libraries
needed during build, but already available on the targeted
WebSphere Portal runtime environments.
ui/templates Templates that can be copied when creating a new user interface
component.
Solution configuration
Configuration is managed on a solution level, which allows us to easily configure
the solution for deployment to new environments. It also reduces the amount of
work needed when aspects relating to the runtime environments change.
Having central configuration might in some cases incur a certain overhead when
creating new components. When developing a component, thought must be
given as to what external aspects required by the component are likely to
change. After the external aspects have been identified, the configuration step
for the component should incorporate override capability for the component
elements identified. The way we suggest for allowing override capability is to
make sure that the component is configured using plain text files, such as XML
files or property files.
630 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
sync, a form of inheritance is used. Any configuration property not defined in a
specific environment configuration file will be inherited from a base configuration.
The starter kit currently supports two methods for configuring a component:
Property substitution
Modifies property values in plain text property files having the format
key=value.
Filtering
Searches for tokens in a text document such as an XML file, and replaces
predefined tokens with values specified in the solution configuration files. A
drawback of this method is that the document cannot be used until it has been
filtered, which might make this method unsuitable in certain cases.
Component structures
There is one common element, that must exist in each component directory for
the starter kit framework to function properly: A build.xml file. This is an XML
document containing various instructions that will be processed and performed
by Ant when executed from a directory containing such a file. If access control is
to be applied to the component, a file named access-control.xml should be
placed in the component’s root directory. Aside from this, the contents of the
component directories can be laid out in any way desired.
All components share a common file called build.xml. This file is responsible for
performing all tasks related to building, configuring, and deploying the
component. The file is made up of a number of targets. A target is an Ant term,
and is a grouping of a set of activities / tasks that are to be performed when the
target is triggered. Targets can be dependent on other targets, which makes
them suitable for performing small specialized operations, and because of the
dependency scheme, act as entry points for operations on a larger scale as well.
Note: At the time of writing, the latest version of Ant is Version 1.6.1 and the
online documentation is written for that version. WebSphere Application
Server 5.0.2 is using Ant Version 1.5.2, which means that some of the latest
features in the online version of the Ant documentation will not be available in
the version we are using. Aside from new features, Ant is backwards
compatible, so Ant-specific detail in the starter kit files should still be properly
explained in the online version of the Ant documentation.
Required targets
The starter kit requires a number of targets to be defined in any component’s
build file. The required targets are listed in Table D-4 (target being the literal
name of the target).
clean Deletes all generated files and directories created during the building of
the component
init Initializes the component and allows the component to override default
properties
632 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Example: D-2 Portlet Application build file
<?xml version="1.0"?>
<!DOCTYPE project [
<!ENTITY standard-init SYSTEM
"file:../../../tools/itso-wpdsk/ant/standard-init.xml">
<!ENTITY standard-portletapp SYSTEM
"file:../../../tools/itso-wpdsk/ant/standard-portletapp.xml">
]>
<!--
Initialize the component and trigger build of dependent components.
This is the place to override default configuration of the standard tasks.
-->
<target name="init" depends="standard-init" />
</project>
Although Example D-2 on page 633 does not look like much more than a number
of declarations, it is a good example for illustrating important concepts of the
starter kit. We will go through the build file from top to bottom and explain
important concepts as we go.
Ant build files are XML documents composed of a root element named project. In
our example, project has three attributes: name, basedir and default. The
attribute name is meant to contain the name of the component. We use this
After the project declaration we reference two XML entities, which are defined at
the top of the file. These entities contain XML fragments of utility targets provided
by the starter kit. Any target having a name prefixed by standard belongs to the
starter kit framework, containing common targets which are provided for use by
component build files. These targets contain default behavior for operations
common to modules of given types, which can substantially reduce the amount
of work required when creating a new component. The first document included in
the build file, referenced as standard-init, contains targets that define the solution
global properties, as well as provide functionality that all components are likely to
make use of. The next file, referenced via the standard-portletapp entity, includes
component type specific targets useful for Portlet Application components. See
Figure D-1 on page 635 for how the standard documents relate to the various
component types.
634 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Standard Standard
common Components specialized
EAR ear
EJB ejb
init
Library library
Portlet portlet
Figure D-1 Relationship between the component types and the standard targets
As previously mentioned, the default target for this build file is standard-default.
This target is defined in the standard-init.xml file, which can be deduced by the
standard prefix. Since we delegate the choice of what target to run by default to
the target defined in standard-init.xml, we have essentially moved this specific
configuration out of the specific component build file to a common file. This is an
example of a design choice made in order to ease maintenance, since only one
file needs changing if a decision is made to change the default target for the
solution. The point we try to highlight is that when making new component build
files, try to identify patterns of configuration and move them to a common
location for easier management.
Finally, the two non-public targets (public targets have a description attribute in
their target element) will receive some mentioning. The init target is where you
will override default properties for standard targets. The second, named
configure, will be called from standard-build targets, allowing component
Where the argument within the square brackets is optional and will use a default
value if omitted. The value tenv is the alias for the environment the component
will be configured for and target is a public target defined in the component’s
build file. Example D-4 shows how to invoke a single target followed by multiple
ones.
The first command removes any files and directories generated by a previous
call to the build or dist targets. The second command creates a deployment unit
of the component, configured for the target environment wpwin1 and deploys it to
said environment.
636 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Solution build file
The root directory of the solution contains a build file that can be used to execute
any public target on all components of a certain type. The targets in this file refer
to groups of components by type. There is one public target for each component
type plus an additional target named all. The latter will execute a specified
component target on all components in the solution. Since each component has
its own build file, the solution build file will simply delegate the specified
component target to each component in turn. Target delegation helps keep
complexity down in the solution build file. The available public targets are shown
in Table D-5.
all Calls targets on ejbs, wars, ears, pages, and the solution-specific dist target
in the stated order.
clean Solution-specific target, will clean the solution archive created by the solution
dist target.
dist Solution specific target, creates a solution archive containing all component
deployment units/distributables available at the time of execution. Note that
this target simply packages the deployment units, it does not build them. The
reason for this is to allow the creation of a solution archive containing a set of
components for several different target environments. In that case you would
create distributables for all environments targeted and then package them
into one archive by invoking this target.
The first command creates deployment units for all components configured for
the target environment wpwin1 and packages all deployment units into a solution
archive. The second command deploys only the Portlet application and Pages
components to wpwin1 (alias for WebSphere Portal node).
Note: The name wpwin1 does not actually reflect the hostname of a node, but
is an arbitrary alias as defined by having a subdirectory in conf/env. The actual
hostname of the environment containing the target node is defined within the
build.properties file contained in the alias’s directory. The reason for this is to
decouple hostnames from environments, since hostnames might change.
Another reason is that using an alias might provide more meaning for various
people about an environment than a hostname. For example, in previous
projects we used aliases like sys-test, int-test, acc-test, and prod to symbolize
the different environment types. Further, this also shields us if a node, for
example, is clustered using a deployment manager, while other environments
are not. From the development standpoint, they are all just environments with
the specifics uninteresting and shielded away.
638 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
To build any component, double click the init-env.bat file on the desktop,
change the directory to an arbitrary component’s directory, and invoke the dist
target of the build file:
1. Change to the directory of the component.
2. Start by cleaning any leftovers from a previous build:
ant clean
3. Invoke the distributable target of the component’s build file and specify the
alias for the target environment:
ant -Dtargetenv=<tenv> dist
The resulting distributable will end up in a newly created directory called dist in
the component’s directory. All intermediate files created during the build phase
are located in a directory called build.
The distributable for the solution is the solution archive, which is contained in a
newly created directory called dist. The solution archive comprises the contents
of all components’ dist directories. This archive can be moved to other
WebSphere Portal nodes for deployment.
Tip: To see what public targets are defined in a build file, change to the
directory containing the build file you are interested in and issue the
command:
ant -projecthelp
This command also lists further details about the build file, such as optional
arguments when invoking it, provided that information has been included in
the build file’s project description element.
640 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Removing/undeploying the component from the target runtime environment is
performed using the same steps as above, but instead of specifying the deploy
target in step 3, specify undeploy.
To deploy on a solution level from the same host the solution was built on, do as
follows:
1. Open an initialized console window by double clicking the init-env.bat file on
the desktop.
2. Change to the solution root directory.
3. Instruct the solution to deploy one or more sets of component types to a
specified target environment:
ant -Dtargetenv=<tenv> -Dtarget=deploy <ctype> [<ctypes..>]
Where tenv is the target environment alias, ctype is the type of components to
deploy, and the ctypes within square brackets are optional additional component
types to deploy.
To deploy parts of a solution from a host other than the one the components
were built on is performed as follows:
1. Copy the solution archive to a directory on the host from which deployment
will occurr.
2. Extract the solution archive to a directory.
Where tenv is the target environment alias, ctype is the type of components to
deploy, and the ctypes within square brackets are optional additional component
types to deploy.
642 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
The export-portlet-access subcommand extracts access control configuration for
a portlet application and stores that information in an XML document. This
document is intended to be renamed access-control.xml and stored in the portlet
application component’s root directory. The access control will be applied during
the deployment of the component if available when the deploy target is invoked.
The available options for the command are shown in Table D-6. If the
sub-command is omitted, a usage description will be shown.
Availability 24x7.
646 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Conceptual node: Load Balancer
Users and presentation The administration client is browser based to configure the
settings.
In addition, command line tools are available.
Availability 24x7.
Availability 24x7.
648 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table E-4 Conceptual Portal Server node
Subject Conceptual node: Portal Server
Users and presentation This node serves customers and administrators. The
presentation services are only browser based.
Availability 24x7.
Users and presentation The administration client is browser based to configure the
directory settings. LDAP entries are managed using
command line tools or a browser.
Availability 24x7.
650 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Conceptual node: Data Server
Users and presentation Administration facilities are Java-based GUIs, or using the
command line facilities.
Availability 24x7.
Users and presentation This node serves customers and administrators. The
presentation services are only browser based.
Availability 24x7.
Availability 24x7.
652 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Conceptual node: Application Server
Availability 24x7.
Availability 24x7.
654 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Conceptual node: Instant Messaging
Cost and benefit The network must handle the additional traffic and data
volume for instant messaging streaming.
Security None.
Risk N/A.
The node interaction matrix is shown in Table E-13 on page 656. It describes the
relationship of specified nodes with their characteristics, for example, which type
communication protocol is used.
656 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
From To Characteristics
658 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table E-16 Specified SECP1 and SECP2 node
Subject Specified node: SECP1 and SECP2 (Caching Proxy)
Description This node serves portal requests and renders the client
page. It supports multi-channel access serving HTML and
WAP WML clients.
24x7.
Processing function Runs 100 or more HTTP services to serve HTTP requests.
Delivers HTTP response streams.
Processing services IBM HTTP Web server required to handle HTTP requests.
128-bit SSL encryption.
660 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Specified node: SPHTTPD (Web Server)
Description This node serves banking requests and renders the client
page.
24x7.
Processing services Generates markup language for HTML and XML. J2EE
runtime environment leveraging Java services.
Description This node is the data store for the enterprise applications
including the portal, bank application and directories. The
directory entities are optimized for read access.
24x7.
662 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Specified node: SPDB (Data Server)
Processing function Is able to serve 10000 directory database requests per hour.
Database provides performance optimizations to handle the
load.
Description This node serves the security service requests from the
Reverse Proxy nodes and the app server nodes.
24x7.
664 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Specified node: SMTAM (Policy Server)
Processing services IBM HTTP Web server required to handle HTTP requests.
128-bit SSL encryption.
Processing services Generates markup language for HTML and XML. J2EE
runtime environment leveraging Java services.
666 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table E-27 Specified SMHTTP2 node
Subject Specified node: SMHTTP2 (Web Server)
Processing services IBM HTTP Web server required to handle HTTP requests.
128-bit SSL encryption.
Processing services Generates markup language for HTML and XML. J2EE
runtime environment leveraging Java services.
668 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Specified node: SMLDAP (Directory)
Description This node is the master data store for the enterprise
directory.
24x7.
Processing function Is able to serve 10000 directory database requests per hour.
Database provides performance optimizations to handle the
load.
670 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Conceptual node: Repository
Users and presentation The administration client is browser based to configure the
settings.
In addition, command line tools are available.
672 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Conceptual node: Portal Server
Users and presentation This node serves customers and administrators. The
presentation services are only browser based.
Users and presentation The administration client is browser based to configure the
directory settings. LDAP entries are managed using
command line tools or a browser.
Risk Critical.
Users and presentation Administration facilities are Java-based GUIs or using the
command-line facilities.
674 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Conceptual node: Data Server
Risk Critical.
Security None.
Risk N/A.
676 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Table E-39 Specified SDREP
Subject Specified node: SDREP (Repository)
Processing services 128-bit SSL encryption for multi-site access via the Internet.
Description This node serves portal requests and renders the client
page. It supports multi-channel access serving HTML and
WAP WML clients. In a developer environment each
developer has a local instance, while in a test environment
they share a single instance.
678 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Specified node: SDPORTAL (Portal Server)
Description This node is the data store for the enterprise applications
including the portal, bank application and directories.
Description This node serves the security requests from the Reverse
Proxy nodes and the Portal Server nodes.
680 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Subject Specified node: SDTAM (Policy Server)
Data N/A.
Management N/A.
682 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
F
Select the Additional materials and open the directory that corresponds with
the redbook form number, SG246325.
c:\6325code Root directory of redbook sample configuration files and sample code.
c:\6325code\config Secure portal solution configuration files used during the installation
and configuration chapters to se tup the runtime environment.
c:\6325code\deploy ITSO Bank secure portal application source and deployment code. This
includes the front-end WAR (portlets) and back-end EAR (EJBs).
684 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
IBM Redbooks
For information on ordering these publications, see “How to get IBM Redbooks”
on page 688. Note that some of the documents referenced here may be available
in softcopy only.
IBM WebSphere Portal for Multiplatforms V5 Handbook, SG24-6098
IBM WebSphere Portal V5, A Guide for Portlet Application Development,
SG24-6076
A Secure Portal Extended With Single Sign-On, REDP3743
A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager
V4.1, SG24-6077
IBM WebSphere Application Server V5.0 Systems Management and
Configuration: WebSphere Handbook Series, SG24-6195
IBM WebSphere V5.0 Security, WebSphere Handbook Series, SG24-6573
WebSphere V5.0 Applications: Ensuring High Performance and Scalability,
SG24-6198
WebSphere Studio Application Developer Version 5 Programming Guide,
SG24-6957
Enterprise Security Architecture Using IBM Tivoli Security Solutions,
SG24-6014
A Portal Composite Pattern Using WebSphere Portal V5, SG24-6087
Lotus Security Handbook, SG24-7017
A Secure Way to Protect Your Network: IBM SecureWay Firewall for AIX
V4.1, SG24-5855
AIX V4.3 Elements of Security, SG24-5962
IBM Host Integration in a Secure Network, SG24-5988
Understanding LDAP - Design and Implementation, SG24-4986-01
Enterprise Business Portals II with IBM Tivoli Access Manager, SG24-6885
Other publications
These publications are also relevant as further information sources:
WebSphere Portal V5.0.2.1 with Tivoli Access Manager V5.1.0.2 Integration
Guide, Volume 1: Installation and Configuration white paper by Ray Neucom,
found at:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD101710
Stuart McClure, et al., Hacking Exposed: Network Security Secrets &
Solutions, Osborne/McGraw Hill, 2001, ISBN 0072193816
Base Administration Guide, IBM Tivoli Access Manager V5.1, SC32-1360
Administration Java Classes Developer Reference, IBM Tivoli Access
Manager V5.1, SC32-1356
Authorization Java Classes Developer Reference, IBM Tivoli Access
Manager V5.1, SC32-1350
Base Installation Guide, IBM Tivoli Access Manager V5.1, SC32-1362
Command Reference, IBM Tivoli Access Manager V5.1, SC32-1354
Plug-in for IBM WebSphere Edge Server Integration Guide, IBM Tivoli Access
Manager V5.1, SC32-1367
Error Message Reference, IBM Tivoli Access Manager V5.1, SC32-1353
Performance Tuning Guide, IBM Tivoli Access Manager V5.1, SC32-1351
Problem Determination Guide, IBM Tivoli Access Manager V5.1, SC32-1352
IBM Global Security Kit, Secure Sockets Layer Introduction and iKeyman
User’s Guide V7a, SC32-1363
IBM WebSphere Application Server Integration Guide, IBM Tivoli Access
Manager V5.1, SC32-1368
WebSEAL Administration Guide, IBM Tivoli Access Manager V5.1,
SC32-1359
Web Security Developer Reference, IBM Tivoli Access Manager V5.1,
SC32-1358
Web Security Installation Guide, IBM Tivoli Access Manager V5.1,
SC32-1361
686 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Plug-in for Web Servers Integration Guide, IBM Tivoli Access Manager V5.1,
SC32-1365
Administration Guide, IBM Tivoli Directory Server V5.2, SC32-1339
Installation and Configuration Guide, IBM Tivoli Directory Server V5.2,
SC32-1338
Performance Tuning Guide, IBM Tivoli Directory Server V5.2, SC32-1342
Online resources
These Web sites and URLs are also relevant as further information sources:
IBM WebSphere Portal for Multiplatforms InfoCenter:
http://www.ibm.com/websphere/portal/library
IBM WebSphere Portal Extend for Multiplatforms home page
http://www.ibm.com/software/genservers/portal/
IBM WebSphere Portal Extend for Multiplatforms technical library home page
http://www.ibm.com/software/genservers/portal/library/
IBM Tivoli Access Manager for e-business home page
http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/
IBM Tivoli Access Manager for e-business technical information home page
http://publib.boulder.ibm.com/tividd/td/IBMAccessManagerfore-business5.1.ht
ml
System Administration, Networking and Security Institute (SANS)
http://www.sans.org/
The Center for Internet Security (CIS)
http://www.cisecurity.org/
Microsoft Security home page
http://www.microsoft.com/security/default.asp
SANS Institute, Information Reading Room for Windows 2000
http://rr.sans.org/win2000/win2000_list.php
IBM AIX home page
http://www.ibm.com/servers/aix/
IBM AIX Service Bulletins and Security Advisories
http://techsupport.services.ibm.com/server/nav?fetch=sbasa
688 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Index
automation overview 614
Numerics availability 151
6325code.zip 684
A B
Back-end application cookies 110
Access Control List 42, 336
Basic authentication 40
access.log 588
BMP
AccessControlConfigService.properties 333
See Programming Module Enhancement
AccessControlDataManagementService.proper-
bootstrap port 435
ties 334
business challenges 145
account management pages 522
business requirements 146
ACL
See Access Control List
ActiveX Control 296 C
actors defined 155 CA
add portlets to page 453 See certificate authority
Additional security hardening guidelines 501 Certificate Authority 27
Administrator rights 229 Certificates 29–30
Apache Ant 616 Client-Web application single sign-on 96
application architecture 396 Common Secure Interoperability V2 472
application deployment Component connections
automate tasks 613 entry runtime environment 133
application development 395 Concepts
Architecture authentication 4
secure portal solution 5 authorization 4
architecture Credential Vault 4
node descriptions 645 global sign-on 4
Architecture overview 362 shared LDAP user registry 4
asymmetric key encryption 28 single sign-on 4
attributeMap.xml 31 Conceptual model 58
Authentication 4, 38 description 53
authentication 30 nodes 61
trace 591 conceptual model
Authentication data 39 node description
Authorization 4, 41 Application Server node 652
Tivoli Access Manager configuration 322 Caching Proxy node 648
WebSphere Portal vs TAM 95 Collaboration node 654
authorization Data Server node 650
trace 593 Directory node 649
authorization API Instant Messaging node 654
Tivoli Access Manager 18 Load Balancer node 646
Authorization goals 42 Policy Server node 653
Authorization process flow 43 Portal Development node 655
Authorization rules 42 Portal Server node 649
690 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
D conceptual model 83
DB2 rebind 188 end-to-end development life-cycle 82
DB2 UDB V8.1 Fixpack 2 hardware used by ITSO 363
installation ITSO Bank
Windows 186 backend EJB server 412
DB2 Universal Database frontend portal server 418
First Steps 188 prepare database 408
installation 184 prepare for ITSO Bank 401
verification 188 software used by ITSO 364
define additional MIME types solution software 8
WebSphere Application Server 296 specified model 84
Defining and applying ACLs and POPs 42 topology selection 81
Demilitarized zone 60 Development node 368
deployed portlets 547 digital signature 29
deployment 433 Disable non-SSL access to Tivoli Directory Server
deployment automation 489
component types 625 disable non-SSL connections 489
concepts 625 disable security for WebSphere Portal 582
goals Disable the IBM HTTP Server Administration ser-
maintainability 614 vice 502
reproducibility 615 Disable the IBM HTTP Server on the Policy Server
traceability 614 node 502
terminology 615 Domain zone categories 54
tooling 616 controlled 55, 57
walkthrough 617 External Controlled 55
Deployment Manager 501 restricted 55, 57
Deployment Manager server 501 secured 55, 57
Design guidelines 93 uncontrolled 55
WebSphere Portal external web server 107 dummy SSL certificates 472
Design principals 94 DummyServerKeyFile.jks 472
access decision evaluation on-demand 94 DummyServerTrustFile.jks 472
access evaluated on-demand dynurl.conf 305
implication 95
motivation 95
E
capture access events EJB method level security 19
implication 95 electronic document 29
motivation 95 Enable LDAP server for SSL connections 476
capture authentication events and logs 95 Enable SSL for LDAP 475
centralized security 94 Enable SSL for Tivoli Access Manager LDAP con-
implication 94 nections 478
motivation 94 Enable SSL for Tivoli Directory Server Web Admin-
Development enviornment istration Tool for LDAP connections 487
topology selection Enable SSL for WebSEAL LDAP connections 480
all-in-one approach 85 Enable SSL for WebSphere Application Server
develop and deploy without debug 87 LDAP connections 481
develop using share security infrastructure Enable SSL for WebSphere Portal LDAP connec-
90 tions 484
develop, deploy and remote debug 88 encrypt passwords 586
Development environment
Index 691
Encryption 29 create a certificate 280
Enterprise runtime topology 73 create a keystore 279
Entry runtime topology 70 export CA certificate 283
Enumeration 16 import certificate 284
error page logs
customization 520 access.log 588
error.log 588 error.log 588
external authorization 336 http_plugin.log 588
ExternalAccessControlService.properties 331 SSL configuration 277
externalize resources 467 IBM Java Runtime Environment (JRE) 7
externalized role management 524 IBM Tivoli Access Manager for e-business 7
attach POP to resource-role 529 IBM Tivoli Directory Server 7–8
grant membership to a role 524 IBM WebSphere Application Server 7
revoke role membership 528 IBM WebSphere Application Server Enterprise 8
externalizing a resource 337 IBM WebSphere Portal Content Publisher 8
IBM WebSphere Portal Extend for Multiplatforms 8
IBM WebSphere Portal Toolkit and Test Environ-
F ment 9
favicon 531
IBM WebSphere Studio Application Developer 9
favicon.ico 359
IBM WebSphere Test Environment 9
Firewalls 22
ibmslapd 504
Footprinting 16
Identity management 105
Forms authentication 40
IllegalBlockSizeException 581
forms authentication 300
import an ldif file 268
fully qualified DNS name 232
Import LDAP certificate to WebSphere Portal key-
functional requirements 146
store 484
Import LDAP server certificate into the CSIv2 trust
G file 485
getCallerPrincipal method 19 Import SOAP server certificate into cacerts keystore
Global Sign-on 5, 96 496
GSKit 188 Import SOAP server certificate into CSIv2 trust file
GSO 496
See Global Sign-on import WebSphere Portal users into TAM 303
Important log files 588
initial context 144
H
http_plugin.log 588 Installation
httpd.conf 277 CVS for NT 606
DB2 Universal Database 184
Windows 185
I IBM GSKit 188
IBM DB2 UDB 7 IBM Java Runtime Environment 192
IBM GSKit 7 Tivoli Access Manager 207
determine version installed 189 PDJRTE 381
installation 188 Web Portal Manager 213
known issues 190 Tivoli Directory Client 219
uninstall 190 Tivoli Directory Server 193
IBM HTTP Server Web Administration Tool 196
configuration WebSEAL 220
certificate 280 WebSphere Application Server 197
692 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
WebSphere Portal 228 modify user info 563
Windows 2000 Server 183 portlets
Integration guidelines 93, 107 ITSOAccountBalance 397
access control of resources within portlets 113 ITSOTransfer 397
access control of WP resources 113 ITSOTransHistory 397
backend application cookies 110 ITSOUser 397
junction mapping table 112 run in WTE 420
TAI junction considerations 109 sample code download 402
WebSEAL junctions 108 verfiy add user 559
WebSEAL session considerations 114 verification 467
WebSEAL URL based access control 112 verify login 557
WebSphere Portal session considerations 114 verify transfer funds 567
Internal network 60 verify view account balance 566
intruder reconnaissance 15 ITSO Bank business scenario 144
isCallerInRole method 20 ITSO working exampel
IT architect 10 use case model
IT specialist 10 application login 158
ITSO Bank ITSO working example
application architecture and design 396 administration
backend 400 secure portal solution 503
database layer 398 application deployment 433
deploy backend application 434 architecture 166
add ITSO attribute to LDAP 437 decisions 169
create application server 435 development environment 174
create data source 440 key concepts 168
create database 437 overview 167
create users and groups 438 runtime environment 174
deploy EAR 443 business requirements 146
determine bootstrap port 435 business scenario 144
unpack backend code 436 business challenges 145
deploy frontend application 446 initial context 144
add portlets to pages 453 development environment
create portal pages 451 architecture 362
externalize resources 467 hardware used by ITSO 363
install portlets 450 planning 362
modify itsobank.properties 446 software used by ITSO 364
modify portlet permissions 463 functional requirements 146
modify resource permissions 459 ITSO Bank customer 146
wmmLDAPServerAttributes.xml 449 ITSO Bank manager 147
deployment units 399 portal administration 147
ITSOBankEAR.ear 400 security administration 147
ITSOBankWAR.war 400 ITSO Bank
EJB layer 397 application design 396
frontend 400 prepare development environment 401
helper classes 398 presentation layer 396
import into WSAD 402 using Credential Vault 425
method level security roles using TAM APIs 421
ITSOCustomers 400 LDAP distinguished name (DN) 267
ITSOManagers 400 non-functional requirements 147
Index 693
availability 151 JAAS
maintainability 152 See Java Authentication and Authorization Ser-
performance 148 vices
scalability 151 Java 2 SDK 20
security 152 Java Archive 296
system constraints 153 Java Authentication and Authorization Services 20
runtime environment Java Runtime Environment 192
planning 176 JMT
Policy Server node 182 See Junction Mapping Table
Portal Server node 227 jmt.conf 308
Reverse Proxy node 218 JRE
sample code See Java Runtime Environment
6325code.zip 684 junction 297
description 684 Junction Mapping Table
download 683 limitations 112
security hardening 471 Junction mapping table 112
start / stop servers 548
use case model 155
add user 159
K
Key concepts 4
administrative use cases 163
keystore 279
application logout 159
delete user 161
front-end use cases 158 L
modify user information 160 LDAP 31, 193, 266
transfer funds 163 enable SSL 475–476
view account balance 162 LDAP repository 4
view transaction history 161 ldap-enable-ssl.ldif 477
verification LDAPHelper class 422
add user 559 ldaphelper.properties 448
login 557 ldapmodify 290, 489
modify user info 563 LDAPsearch 584
transfer funds 567 Light Weight Third Party Authentication 309
view account balance 566 Lightweight Third Party Authentication 103
ITSOAccountBalance portlet 397 Logical security 17
itsobank.ldif 439 applications 18
itsobank.properties 447 middleware and application software 20
ITSOBankDataSource data source 440 network 22
ITSOBankEAR.ear 400, 443 operating systems 21
ITSOBankWAR.war 400, 446 IBM AIX 21
ITSOCustomers 400 Linux 22
ITSOid 419, 437 Microsoft Windows 21
ITSOManagers 400 WebSphere security 18
ITSOTransfer portlet 397 logout.html 315
ITSOTransHistory portlet 397 Logs
ITSOUser portlet 397 access.log 588
error.log 588
http_plugin.log 588
J msg_pdacId_utf8.log 590
J2EE developer 11
msg_pdmgrd_utf8.log 590
694 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
msg_pdmgrdproxyd_utf8.log 590 O
SystemErr.log 588 Operational model 52
SystemOut.log 588 contents
LTPA 597 description of each node 52
LTPA configuration 104 description of middleware services 52
description of walkthroughs 52
mapping matrix 52
M
macro support 524 one or more diagrams 52
maintainability 152 systems management strategy 52
Management zone 60 Outside zone 59
MASS
See Method for Architecturing Secure Solutions P
Matching topics to roles 11 pages 627
Method for Architecting a Security pdadmin 299, 304, 511
phases pdjrtecfg 382
analysis 26 permission 337, 342
developing security architectures 26 Physical model
integration for solution architecture 26 description 53
problem statement 26 Physical security 17
system model for security 26 PKI
Method for Architecting Secure Solutions 25 See Public Key Infrastructure
Microsoft Windows 2000 Server Plug-in approach 76
installation 183 Policy Server node 182, 366
MIME types 296 POPs
ActiveX Control (cab) 296 See Protected object policies
Java Archive (jar) 283, 296 Portal administrator 11
Modifying web.xml 313 Portal developer 11
msg_pdacld_utf8.log 590 Portal Server node 227
msg_pdmgrd_utf8.log 590 Portal-Backend SSO 96
msg_pdmgrdproxyd_utf8.log 590 PQ77683 594
mutual SSL 276 PQ79613 595
myportal 535 PQ79684 595
PQ79819 595
PQ79938 595
N
Network zone PQ80428 595
uncontrolled 56 PQ81912 596
Network zones 56 PQ83717 596
controlled 57 PQ86200 596
Node agents 502 presentation layer
nodes ITSO Bank application 396
Development node 368 private key cryptography 27
Policy Server 182 Production zone 60
Portal Server 227 Programming Module Enhancement (PME) 8
Repository node 366 Programming Module Extension 237
Reverse Proxy 218 Project manager 11
non-functional requirements 147 Protected object policies 42
Novell SuSe Linux 22 public key cryptography 28
Public Key Infrastructure 27
Index 695
R S
Realms of single sign-on 97 sample code
Redbooks Web site 688 description 684
Contact us xix download 683
Redhat Linux 22 SANS Institute 22
Replace the default SSL certificates for the SOAP SAS
connector 490 See Security Authentication Service
Repository node 366 scalability 151
requirements Scanning 16
ITSO working example 146 secret key cryptography 28
performance 148 secure portal
response time 149 application development 395
static volumetric 151 Secure portal solution
throughput 149 component connections 133
utilization 150 high level architecture 5
Resource Permissions portlet 547 high level authentication process 5
resource type Portlets 547 high level authorization 6
response time requirements 149 secure portal solution
Reverse proxy approach 74 administration 503
Reverse Proxy node 218 application deployment 433
risk management 14 application development 395
role membership 337 backup key files 549
roles 336, 338 development environment implementation 361
Roles and skills 10 log files 588
IT architect 10 overview 4
IT specialist 10 authentication 4
J2EE developer 11 authorization 4
portal administrator 11 credential vault 4
portal developer 11 shared LDAP user registry 4
project manager 11 single sign-on 4
security administrator 11 runtime environment configuration 259
security architect 10 runtime environment installation 175
Runtime environment security hardening 471
planning SSO using LTPA 597
hardware used by ITSO 178 SSO using TAI 289
installation paths and variables 181 troubleshooting 573
overview 176 Securing WebSphere Application Server in Network
prerequisites 177 Deployment environment 501
software used by ITSO 178 Security
using VMWare and Ghost 182 network 22
solution software 6 Security administrator 11
topology selection 69 Security and design guidelines
add external WP Web Server 107
extended enterprise runtime 79 authorization TAM vs WP 95
enterprise runtime 73 design principals 94
entry runtime 70 identity management 105
single sign-on 96
Security architect 10
Security Authentication Service 472
696 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Security design objectives 54 WebSEAL session times out before Web-
Security domain 14 Sphere Portal session 121
intruder reconnaissance 15 WebSphere Portal logout after WebSEAL
logical security 17 session timeout 131
logical security categories WebSphere Portal session times out before
applications 18 WebSEAL session 124
middleware and application software 20 server1 application servers 502
network software 22 serverStatus.bat 534
operating systems 21 services.properties 334
physical security 17 Session considerations 114
physical security categories Session data 39
buiding access 17 session timeouts
physical network 17 WebSEAL 356
system access 17 WebSphere Portal 356
systems hardware 17 Single sign-on 4
security policy categories guidelines
risk analysis 23 Trust Association Interceptor 99
security management and audit 23 realms 97
security policies and procedures 23 selecting a solution 104
source vulnerability 15 single sign-on
security domain figure 14 configuration
Security fundamentals 13 LTPA 597
security hardening 471 TAI 289
additional guidelines 501 Single sign-on guidelines 96
define additional admin roles 501 LTPA token 103
disable IBM HTTP Server Administration skins 627
502 SOAP connector
disable unused end points 501 replace default SSL cert 490
disable unused WebSphere HTTP trans- Software versions 7
ports 501 Solution software 6
non-admin user 501 runtime environment 6
secure RMI connectors 501 Specified model 62
WAS Network Deployment 501 description 53
Security interaction patterns 65 specified model
application 67 node description 656
infrastructure 65 SPNEGO (Keberos) 40
Security policies 23 SSL
Security risk management 14, 23 enable IBM HTTP Server 277
Sequence diagrams enable SSL for LDAP 475
common access patterns 115 enable Tivoli Access Manager 478
access protected page with existing valid enable WebSEAL 480
session 119 enable WebSphere Application Server 281,
access protected portal page with invalid 481
credentials 120 enable WebSphere Portal 281, 484
access protected portal page, provide cre- Tivoli Directory Server
dentials 117 enable client utilities 488
access unprotected portal pages 116 enable Web Admin Tool 487
both WebSEAL and WebSphere Portal ses- SSO
sions time out 127 See Single sign-on
Index 697
SSODomainName 574 WebSphere Portal URIs 305
starter kit 627 enable SSL for LDAP 478
startServer.bat 533 features
static volumetric 151 authentication 35
Stop and start servers authorization 35
WebSphere Test Environment 392 centralized security management 35
stopServer.bat 533 programmatic authentication and authoriza-
Symantec Ghost 182 tion 35
symmetric key encryption 27 secure communication 35
system constraints 153 web single sign-on 35
SystemErr.log 588 Global Sign-on 5
SystemOut.log 588 installation 207
PDJRTE 213
update Windows registry 211
T logs
TAI
msg_pdacId_utf8.log 590
See Trust Association Interceptor
msg_pdmgrd_utf8.log 590
tam-acls.ldif 290
pdadmin 511
TAMExternalAccessControlServices 336
security model
TAMHelper 398
authentication 38
tamhelper.properties 448
client request session and authentication
Target redbook audience 10
data 38
team development 406
database used to maintain security policies
themes 627
36
throughput 149
features and components 35
Tivoli
master authorization database 37
administration tools 504
protected object 37
Tivoli Acccess Manager
protected object space 37
global sign-on 46
system resource 37
Tivoli Access Manager
user registry database 36
apply ACLs to LDAP suffixes 290
web objects 37
authentication goals 38
WebSEAL 38
authentication process flow 40
start / stop servers 511
authorization API 18
trace
authorization APIs 18
authentication 591
authorization vs WebSphere Portal 95
authorization 593
components
user create 321
Authorization Server 36
using APIs 421
pdadmin command line utility 36
Web Portal Manager 513
Policy Server 36
verification 216
Web Portal Manager 36
WebSEAL
WebSEAL 36
configuration 222
configuration 208
create a junction 297
Authorization Server 210
installation 220
Policy Server 209
Tivoli Access Manager Global Sign-on 46
Runtime 208
Tivoli Directory Server
Web Portal Manager 213
client utilities
Windows services startup 213
enable SSL for LDAP 488
create objects
command line utilities 510
698 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
configuration 195 secondary actors 156
configuration tool 506 summary of use cases 157
create a suffix 206 use case diagram 156
disable non-SSL access 489 user management 513
enable SSL 476 create users 514
installation 193 delete users 517
processes 504 password management 517
start / stop servers 505 user self care 519
Web Administration Tool 507 User registry 4
enable SSL for LDAP 487 utilization 150
Web Administration Tool installation 196
Tivoli Identity Manager 49
ToolBarInclude.jsp 318
V
Vault segment 44
Topology zones 53
Vault slot 44
trace 591
VaultServices.properties 348
Tracing Trust Association 324
Verfication
troubleshooting 573
WebSphere Portal SSL configuration 283
common issues 574
Verification
failure creating deployment credentials 575
Credential Vault 350
fixes
DB2 Universal Database 188
external access control 594
external authorization
login 574
TAM for WebSphere Portal 336
2-letter domains 575
IBM HTTP Server 280–281
browser formatting POST request 574
ITSO Bank 467
incorrect SSODomainName 574
LDAP configuration 393
usage of hostname in URL 574
Portal Toolkit 380
problem running portal as service 579
Portal Toolkit and Test Environment 380
recover portal admin privilage 577
SOAP configuration
session timeouts 575
install porlet via XMLAccess 499
tips 582
install portlet via GUI 499
disable WP security 582
TAI configuration 304, 312
install fixpacks for portal 585
create/login new user 321
using LDAP client utilities 584
Tivoli Access Manager
trace 591
ACLs 343
authentication 591
configuration and APIs within Studio 384
WP database tranfers to DB2 fails 580
object space 343
Trust Association Interceptor 99, 309
Web Portal Manager 216
methods 100
Tivoli Directory Server
settings 310
Web Administration Tool 205
summary how it works 100
WebSphere Application Server 200
Trust Association Interceptor configuration 313
WebSphere Portal 231
Verify SOAP configuration - install portlet via GUI
U 499
URL filtering 301 Verify xmlaccess utility- install portlet via xmlaccess
use case model 155 499
actors defined 155 Virtual Private Network 23
overview 155 Virtual Resource resource type 547
primary actors 155 VMWare 365
Index 699
VMWare Workstation 182 options 108
VPN cookie handling 108
See Virtual Private Network encryption 108
number of junctions 108
TAI 109
W WebSEAL to web application authentication flow
Web objects 37
98
Web Portal Manager 213, 513
WebSEAL user sessions 114
web.xml
WebSphere
WebSphere Portal 313
administration tools 531
WebSphere Portal SSL 282
WebSphere Application Server
webseaId-default.conf 300
Administrative Console 531
WebSEAL 220
authentication protocols
additional parameters 303
CSIv2 472
configuration 222
SAS 472
create a junction 297
bootstrap port 435
create junction
configuration
syntax parameters 298
backup 235
customize HTML pages 519
JAAS 325
account management pages 522
default_host 281
error pages 520
define additional MIME types 296
macro support 524
disable global security 583
enable forms authentication 300
dummy SSL certificates 472
enable SSL for LDAP 480
enable SSL 281
favicon.ico configuration 359
enable SSL for LDAP 481
junction cookies 302
establish trust relationship
junction mapping 302
LTPA 309
junction mapping table 307
TAI 309
logs
host aliases 281
msg_pdmgrdproxyd_utf8.log 590
installation 197
modify URLs to backend 301
logs
processing of URLs 302
SystemErr.log 588
URL based access control 112
SystemOut.log 588
URL filtering 301
Network Deployment 501
user sessions 114
Deployment Manager 501
WebSEAL authentication methods 39
node agents 502
Basic authentication 40
Programming Module Extension 237
CDSSO ID token 39
server status 534
client-side certificate 39
serverStatus.bat 534
failover cookie 39
SOAP connector
forms authentication 40
replace default SSL cert 490
HTTP headers 40
SSL repertoire for CSIv2 474
IP address 40
start / stop servers 533
SPNEGO (Keberos) 40
startServer.bat 533
WebSEAL junction
stopServer.bat 533
-b supply option 109
verification 200
-b supply option using mutual SSL 110
wsadmin 532
custom TAI plugin 110
WebSphere Member Services 31
WebSEAL junctions 108
WebSphere Portal
700 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
access categories delegated administration 35
WP_admin_access 304 identifyi the user 32
WP_all_access 304 Java security 34
WP_authenticated_access 304 member services 31
WP_no_access 304 persistent connections 33
add portlets to pages 453 single sign-on 33
authorization vs TAM 95 third-party authentication servers 32
ConfigService.properties 317 self care 31
configuration skins 627
Credential Vault 347 SOAP timeout 241
login/logout with WebSEAL 313 standalone Web server 107
SOAP connection credentials 495 stop and start server 235
Content Publisher 242 themes 627
create portal pages 451 trace
Credential Service 4 authentication 592
Credential Vault 4, 44, 99 authorization 593
credential objects 45 credential vault 594
vault segment 45 URIs 305
verification 350 define access controls 304
DB2 configuration 261 user sessions 114
disable LDAP security 394 verification 231
disable security 582 Web administration 535
enable LDAP security 269 xmlaccess 544
enable LDAP security for WebSphere Portal WebSphere Portal Toolkit
388 installation 378
enable SSL for LDAP 484 WebSphere Portal user sessions 114
encrypt clear text passwords 586 WebSphere security 18
externalize a resource 536 EJB method level security 19
First Steps 231 JAAS 20
IBM HTTP Server configuration 264 WebSphere Studio Application Developer
install portlets 450 installation 369
installation 228 WebSphere Studio Application Developer V5.1.1
internalize a resource 537 installation 369
LDAP configuration 266 WebSphere Test Environment
logs start and stop 392
SystemErr.log 589 wmm_LDAP.xml.IBM_DIRECTORY_SERVER.1.w
SystemOut.log 589 mm 270
wps_date_time.log 589 wmmLDAPAttributes_IBM_DIRECTORY_SERVER
manage the Credential Vault 536 .xml 271
modify portlet permissions 463 wmmLDAPServerAttributes.xml 419, 449
modify resource permissions 459 WP_admin_access 304
read-only LDAP access 269 WP_all_access 304
remove encrypted passwords 587 WP_authenticated_access 304
screens 626 WP_no_access 304
security model wpconfig.properties
administration 31 DB2 settings 262
authentication 32 disable security 583
authorization 34 LDAP settings 273
Credential Vault 33 Web server settings 265
Index 701
WpsHostName 320
wp-itso.ldif 267
wp-junction.pd 297
wp-junction-ltpa.pd 600
wps_date_time.log 589
wpsconfig 261
wpslogout.html 313
wp-tam-acl.pd 306
wp-tam-user-import.pd 303–304
wpwin1_svrsslcfg.bat 323
wsadmin.bat 532
X
XMLAccess 544
verfication 499
Y
YourCo Financial 338
702 Develop and Deploy a Secure Portal Solution Using WebSphere Portal V5 and Tivoli Access Manager V5.1
Develop and Deploy a Secure Portal Solution
Using WebSphere Portal V5 and Tivoli Access
Manager V5.1
Back cover ®