A Secure Portal Extended With Single Sign-On

Front cover
A Secure Portal
Extended With Single
gle
Sign-On
WebSphere Portal V5 and Tivoli Access
Manager V4.1 integration
Design guidelines and

technology options
Step-by-step guide
Michele Galic
ibm.com/redbooks Redpaper
International Technical Support Organization
Secure Portal with Single Sign-On
February 2004
Note: Before using this information and the product it supports, read the information in “Notices” on page v.
First Edition (February 2004)
This edition applies to WebSphere Portal Version 5 and Tivoli Access Manager Version 4.1.
This document created or updated on February 20, 2004.
© Copyright International Business Machines Corporation 2004. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Credential vault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Credential vault organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chapter 2. Requirements and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Requirements analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Solution design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Functional view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Operational view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Application design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Design guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Portlet development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Using the credential vault portletservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 SSO guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.4 Extended SSO Runtime patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 3. Technology options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Approaches to achieve SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Extending the security realm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Credential vault PortletService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Vault Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Vault organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 Types of credential objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Chapter 4. Implementing the runtime environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Setting up the back-end business applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Installing a WebSphere Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.2 Setting up security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.3 Deploying the back-end sample applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.4 Verifying the back-end sample applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Installing and configuring TAM credential vault adapter . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Using portal default and TAM credential vaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1 Logging into the portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.2 Installing sample portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
© Copyright IBM Corp. 2004. All rights reserved. iii

4.4.3 Create/Manage vault segments, slots, and user credentials . . . . . . . . . . . . . . . . 47
4.4.4 Creating a page and deploying the portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 5. Sample applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1 The sample portlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Running the basic authentication portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1 Incorrect slot credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 Running the Web service authentication portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.1 Incorrect slot credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Appendix A. Implementing the development environment . . . . . . . . . . . . . . . . . . . . . . 65

Development environment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
WebSphere Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Portal Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Development environment configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Local debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Remote server attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
WebSphere Studio Site Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Portal Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Importing the sample source into WSSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Packaging the application for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
iv Secure Portal with Single Sign-On

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

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Eserver® Domino® Redbooks™
Eserver® DB2® Sametime®
Redbooks (logo) ™ IBM® Tivoli Enterprise™
Eserver™ Lotus® Tivoli®
ibm.com® MQSeries® WebSphere®
The following terms are trademarks of other companies:
Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other
countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
Other company, product, and service names may be trademarks or service marks of others.
vi Secure Portal with Single Sign-On

Preface
Many portals are required to access external applications that need some form of user
authentication. In most cases, the user credentials required by these applications will differ
from those used by WebSphere® Portal. It is possible for the portlet to prompt the user for
this credential information and then present it to the external application. However, such an
approach is seldom implemented due to the unsatisfactory user experience. Therefore, a
single sign-on (SSO) is required to provide seamless access to the different applications in a
Portal solution.
Implementing a secure Portal using an external security manager is part of solving this
problem. This provides a centralized access management system. It is also a basis for
creating an SSO domain for multiple applications that can share common user credentials.
However, back-end applications can still exist outside of this domain because of a need for
specific custom user IDs and passwords. For these, we can use credential mapping to map
the common credential to the back-end one. This is implemented as Credential Service in
WebSphere Portal.
This publication is intended to help IT architects, IT specialists, security architects, and

security administrators understand and implement a secure portal with SSO. This publication
is build on and extends the IBM® Redbook A Secure Portal Using WebSphere Portal V5 and
Tivoli Access Manager V4.1, SG24-6077. The ideas presented there will help you to
understand the concepts covered in this IBM Redpaper.
This Redpaper will cover the following topics:

An introduction of SSO and WebSphere Portal credential vault concepts
A discussion of functional and non-functional requirements and design with
business/technical use cases
Coverage of design guidelines and technology choices
Documentation of the steps necessary to install and configure the SSO environment
An illustration of a sample application
Additional material that contains the sample code
The team that wrote this Redpaper

This Redpaper was produced by a team of specialists from around the world working at the
International Technical Support Organization, Raleigh Center.
Michele Galic is an IT Specialist at the International Technical Support Organization, Raleigh

Center. Her focus is on the WebSphere family of products and Patterns for e-business. She
has 13 years of experience in the IT field. She holds a degree in Information Systems. Before
joining the ITSO, Michele was a Senior IT Specialist in IBM Global Services in the Northeast,
specializing in the WebSphere field.
Alison Halliday is an IT Architect from IBM Global Services, Sweden. She primarily works in
the application architecture, design, and development of e-business and enterprise Java™
solutions. Alison has seven years of experience in the industry and holds a MSc (Computer
Science) from Queen's University, Belfast, Northern Ireland. Her areas of expertise include
the WebSphere family of products, J2EE, and Java.
© Copyright IBM Corp. 2004. All rights reserved. vii

Andrew Hatzikyriacos is an IT Architect in South Africa. He has worked at IBM for 5 years
and is currently with IBM Global Services - Strategic Outsourcing. Andrew has a BSc
Honours degree from the University of the Witwatersrand, Johannesburg, South Africa, and
has 12 years of experience in the IT field. His areas of expertise include Tivoli® Enterprise™
Systems Management and Security Management.
Maria Munaro is an IT Specialist with IBM Venezuela. She joined Lotus® four years ago as a
Senior Consultant for the Consulting Division in Venezuela. Currently Maria works as a
WebSphere Technical Specialist in the Software Group. She is both an IBM MQSeries®
Certified Specialist and a Lotus Domino® CLP. Before joining Lotus, Maria worked for two
years for a Lotus Business Partner based in Argentina. Her most recent projects have been
with MQSeries and WebSphere Portal Server.
Sailaja Parepalli is a Software Consultant at Miraclesoftware systems, Inc., MI. She has 6
years of experience in software analysis, design, and development. Her software industry
experience includes Business Analysis and Object Modeling using UML and Application,
Web, and Portal development using Java/J2EE and WebSphere family of products. You can
reach her at sparepalli@miraclesoft.com.
David Yang is a staff software engineer in the Solution Test team of the WebSphere Platform
System House organization located in Research Triangle Park, North Carolina. He has
worked with IBM in a variety of development and test roles and has areas of expertise in
Java, Linux, WebSphere, security, and TCP/IP.
Figure 0-1 A Secure portal residency team
Thanks to the following people for their contributions to this project:
viii Secure Portal with Single Sign-On

Gianluca Gargaro
IBM Italy
Helen Rehn
IBM US
Tinny Ng
IBM Toronto
Margaret Ticknor
International Technical Support Organization, Raleigh Center
Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with
specific products or solutions, while getting hands-on experience with leading-edge
technologies. You'll team with IBM technical professionals, Business Partners, and/or
customers.
Your efforts will help increase product acceptance and client 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:
http://ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about this
Redpaper or other Redbooks™ in one of the following ways:
Use the online Contact us review redbook form found at:
http://ibm.com/redbooks
Send your comments in an Internet note to:
mailto://redbooks@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 ix
x Secure Portal with Single Sign-On
1
Chapter 1. Introduction
Web technology use has expanded for the delivery of information and services, both inside
and outside a company’s network. Unfortunately most Web applications and packages
provide a plethora of security standards and implementations. Many companies are now
looking for a consolidated authentication and authorization approach to better manage this
distribution of business services. Implementing a secure Portal using an external security
manager is part of solving this problem. This provides a centralized access management
system. It is also a basis for creating a singe sign-on (SSO) domain for multiple applications
that can share common user credentials. However, back-end applications can still exist
outside of this domain because of a need for specific custom user IDs and passwords. For
these, we can use credential mapping to map the common credential to the back-end one.
This is implemented as Credential Service in WebSphere Portal.
This chapter introduces the topic of SSO in broad terms and the credential services structure
as implemented in WebSphere Portal. This publication is build on and extends the redbook A
Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager V4.1, SG24-6077. The
ideas presented there will help you to understand the concepts covered in this IBM Redpaper.
© Copyright IBM Corp. 2004. All rights reserved. 1

1.1 Single sign-on
By definition, once a user has successfully authenticated in the SSO domain, that user is not
required to present his authentication information again. These established credentials are
used to automatically authenticate the user to the applications participating in the SSO
domain.
Many portals are required to access external applications that need some form of user
authentication. In most cases, the user credentials required by these applications will differ
from those used by WebSphere Portal. Although it is possible for the portlet to prompt the
user for this credential information and then present it to the external application, such an
approach is seldom implemented due to the unsatisfactory user experience. Therefore, a
Portal solution requires an SSO to provide seamless access to different applications.
The redbook Access Integration Pattern Using IBM WebSphere Portal Server, SG24-6267-00
describes two SSO application patterns.
Web Single Sign-On pattern: This pattern provides seamless access to multiple Web
applications located in the same security domain. This is the typical SSO scenario where
a company wants a common authentication mechanism for a number of applications. User
credential tokens that can be validated by the other applications within the SSO domain
can be generated either by (1) the applications themselves or (2) by using an
authentication proxy. This establishes a trust between the applications. For example
WebSphere Application Server and Domino can generate and validate LTPA (Lightweight
Third Party Authentication) tokens, forming an SSO domain together. The pattern is
depicted in Figure 1-2 on page 3.
synchronous synchronous
Client Single Sign-On Application1
Tier Tier
Application2
Application node Application node containing

Read / Write data containing new or existing components with
modified components no need for modification
or which cannot be changed
Figure 1-1 Access Integration::Web Single Sign-on pattern
Extended Single Sign-On pattern: This pattern provides SSO to back-end applications
that are outside the security domain. It may not be possible for the applications in an SSO
domain to share the same user credentials as in the Web SSO application pattern. For
example, there may only be a system user ID available for an internal back-end
application. To solve this issue, WebSphere Portal provides a credential vault service
where these back-end credentials can be stored in a credential vault and retrieved by
portlets to access the back-end application. This is described in more detail in the next
section. Note that Extended SSO also is often called Double-realm SSO in other
publications. This pattern is shown in Figure 1-3 on page 3.
2 Secure Portal with Single Sign-On

Client Application 1 Security Enterprise
Tier Single Sign-On Integration Application
Application 2
Figure 1-2 Access Integration::Extended Single Sign-On pattern
Chapter 2 will show the available Runtime patterns for SSO application patterns.
1.2 Credential vault

This section provides an overview of the credential vault service that is provided by
WebSphere Portal. 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. These credentials are physically
stored in a credential implementation. By default, this credential implementation is the
WebSphere Portal database, but it also can be the Tivoli Access Manager lock box or another
custom repository. Examples for credentials are user ID/password, SSL client certificates, or
private keys. Please refer to 2.3.2, “Using the credential vault portletservices” on page 18, for
a discussion on the usage of credential vault features.
1.2.1 Credential vault organization

Figure 1-3 gives an overview of the credential vault organization. The elements are then
discussed further in this section.
Vault Implementations
Vault Service WebSphere Portal Vault
User-managed Segment (U)
Slot Ua
Slot Ub
Slot Uc
Administrator-managed
Segment (A1)
Slot A1a
Slot A1b
Slot A1c
Other Vault Implementation

Administrator-managed
Segment (A2)
Slot A2a
Slot A2b
Slot A2c
Figure 1-3 Credential vault organization
Chapter 1. Introduction 3
Vault segment
A vault is broken down into vault segments. These can be user- or administrator-managed.
However, portlets can create slots in user-managed segments only. Creating slots in
administrator-managed segments is limited to the administrator. Credential creation and
retrieval can be carried out in both by portlets. Vault segments map on 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. For non-shared slots, are specific to both the back-end application and the
user. Shared slots are specific only to the back-end application.
The credential vault provided by the WebSphere Portal distinguishes between four different
types of vault slots:
A system slot stores system credentials where the actual secret is shared among all users
and portlets. In this case, a group of portlets shares the same password.
A shared slot stores user credentials that are shared among the user’s portlets.
A portlet private slot stores user credentials that are not shared among portlets.
An administrative slot allows each user to store a secret for an administrator-defined
resource.
Credential objects
Credentials are returned in WebSphere 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. Please see
3.3.3, “Types of credential objects” on page 27 for more information.
1.3 Summary
Single sign-on has two principle application patterns, Web SSO and Extended SSO. In this
publication, we will explain how to implement an Extended SSO application using credential
vaults. Credential vaults are repositories for user credentials to be used for external systems
outside the Web SSO realm. Credential vaults are organized into segments and slots.

2
Chapter 2. Requirements and Design

This chapter discusses the requirements analysis and design for the SSO solution that is built
on the secure portal.
The requirements are addressed from both the functional and non-functional business
perspective. Some simple use cases are outlined below in order to depict the core
functionalities of the SSO solution.
The solution design, subsystems, and operational view are then presented. These are
followed by sample portlets and sample back-end applications.
We will also look at various SSO design guidelines.

2.1 Requirements analysis
An SSO solution provides a framework for (1) demonstrating the invocation of various
external functions from the front-end systems and (2) exercising some of the security aspects
of the front-end to back-end interactions.
Using SSO, a user can authenticate once when logging into the front-end system
(WebSphere Portal). Then, the user’s identity is passed on to back-end or external
applications without requiring additional identity verification from the user. The SSO approach
focuses on security integration between the products.
This solution is an add-on to A Secure Portal Using WebSphere Portal V5 and Tivoli Access
Manager V4.1, SG24-6077. Please refer to Chapter 2, Requirements and design, in this
redbook for information about authentication and authorization mechanisms.
We discuss the functional and non-functional business requirements for the SSO solution in
the following sections. Together, these provide the baseline for the design of the system.
Note: For additional information about SSO, refer to the WebSphere Portal InfoCenter
using the following URL:
http://publib.boulder.ibm.com/pvc/wp/500/ent/en/InfoCenter/index.html
2.1.1 Functional requirements

Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks, or functions that the system is required to perform. The use
case model has become a widespread practice for capturing these functional requirements.
A use case is initiated by a user/actor with a particular goal in mind; it completes successfully
when that goal is satisfied. It describes the sequence of interactions between actors and the
system necessary to deliver the service that satisfies the goal. Actors are parties outside the
system that interact with the system.
Tip: Although the discussion of UML and use case modeling is out of the scope of this
document, the following URL provides more information about UML and use cases if you
want to explore further:
http://www.rational.com/uml/index.jsp
The sections below present the graphical and textual representations of the identified use
cases for the SSO solution.
Use case diagram

A graphical representation of the main use cases and actors involved in the SSO is depicted
in Figure 2-1 on page 7.

UC-01-a:Retrieve user credentials
from the vault slot
<<include>>
UC-01:Access the external system

(back-end) through portal
(front-end) <<include>>
Customer System/Portlet
UC-01-b:Pass the credentials to the

external system (back-end)
UC-ADM-01:Create/Manage
Vault Segment
UC-ADM-02-a:Create/
<<include>> Modify User Credentials
Site
UC-ADM-02:Create/Manage
Administrator Vault Slot
Figure 2-1 SSO use case diagram
Use cases list

An actor may be a class of users, the roles users can play, or other systems.
A primary actor is one having a goal requiring the assistance of the system. A secondary
actor is one from which the system needs assistance.
Primary actor(s)
The list of primary actor(s) in the current process follows:

Client
Site administrator
Secondary actor(s)
The list of secondary actor(s) in the current process follows:

System (portlet)
Business use cases are summarized in Table 2-1.
Table 2-1 Business use cases

Use case ID Use case name Goal in context Actor (Primary or
Secondary)
UC-01 Access the external Actor needs to access Client

system (back end) the external system
through portal (front (back end) through the
end) portal (front end).
Chapter 2. Requirements and Design 7

Use case ID Use case name Goal in context Actor (Primary or
Secondary)
UC-01-a Retrieve user Actor retrieves the System (portlet)

credentials from the credentials from the
vault slot vault slot
UC-01-b Pass the user Actor passes the System (portlet)

credentials to the retrieved credentials to
external system (back the back end system
end)
Administration use cases are summarized in Table 2-2.
Table 2-2 Administration use cases

Use case ID Use case name Goal in context Primary actor
UC-ADM-01 Create/manage vault Create/manage a vault Site administrator

segment segment using
credential vault portlet.
UC-ADM-02 Create/manage vault Create/manage a vault Site administrator

slot slot using credential
vault portlet.
UC-ADM-02-a Create user Create user Site administrator

credentials credentials in the vault
implementation (user
ID and password
information)
Use case details

This section provides information about specific business and administration use cases.
Business use cases

Use case UC-01 is summarized in Table 2-3.
Table 2-3 UC-01: Access the external system (back end) through portal (front end)
Use case ID and name UC01: Access the external system (back end)
through portal (front end)
Description Primary use case for an actor to access the

external system (back end) through the portal
(front end)
Preconditions Actor logged in the secure portal
Primary actor Client
Secondary actor System/portlet

Main scenario The system retrieves the user credentials from
the vault slot.
The system prompts for the user input if needed
(for example, entering the user input or clicking a
button).
The system/portlet passes the user credentials to
the back-end system.
The system displays the portlet data along with
the information from the back-end.
The use case ends successfully.
Alternatives
Related information Data

Any user input
Note: The use case detail above also includes the details of use cases UC01-a and
UC01-b. The implementation of the business use cases summarized above is covered in
“Sample applications” on page 59.
Administration use cases

Use case UC-ADM-01 is summarized in Table 2-4.
Table 2-4 UC-ADM-01: Create/manage vault segment

Use Case ID and name UC01: Create/manage vault segment
Description Primary use case for an actor to create/manage

credential vault segment
Preconditions Actor logged in with administrator rights
Primary actor Site administrator
Secondary actor None
Main scenario The system prompts for the vault segment name
and other related information.
The actor inputs the necessary data.
The system creates the new vault segment using
the credential vault service.
The system acknowledges that the new vault
segment has been created.
Alternatives

Vault segment name
Use case UC-ADM-02 is summarized in Table 2-5.
Table 2-5 UC-ADM-02: Create/manage vault slot and user credentials

Use Case ID and name UC02: Create/manage vault slot
UC02-a: Create/modify user credentials
Description Primary use case for an actor to create/manage

credential vault slot.
Included use case for an actor to create/modify
user credentials.

Preconditions Actor logged in with administrator rights.
Primary actor Site administrator
Secondary actor None
Main scenario The system prompts for the vault slot name and
other details, user credential information.
The actor inputs the necessary data to create a
vault slot and user credentials.
The system creates the new vault slot and
associated user credentials using the credential
vault service.
The system acknowledges the new vault slot has
been created.
Alternatives

Vault slot name
In the use case details provided above, the main scenarios talk only about the creation part of
credential vault segment, slot, and user credentials.
This level of detail is provided because the management of the vault segment only allows a
user to delete the segment. If you want to modify an existing segment name or other
information, just delete the segment and create another with the necessary data.
Similarly, managing a vault slot involves the deletion of a vault segment or modification of the
user credentials.
Note: Refer to “Implementing the runtime environment” on page 29 for the implementation
of the administration use cases above.
2.1.2 Non-functional requirements

While the functional requirements are associated with specific functions, tasks, or behaviors
the system must support, non-functional requirements are constraints on various attributes of
these functions or tasks. Non-functional requirements are also stated as constraints on the
results of tasks or functional requirements (such as constraints on the performance or
efficiency of a given task).
We can categorize and discuss the non-functional requirements for an SSO solution into
Scalability requirements
Security requirements
Performance requirements
Scalability requirements
Scalability is the degree to which something can be modified to increase its existing
capacities.
The SSO solution is an extension to the secure portal to provide centralized security when
the users are allowed to have access to multiple systems using different sets of user
credentials.
Collaborative features like Lotus Instant Messaging (Sametime®) chat can also take
advantage of SSO.

Security requirements
These security requirements relate to identification and authentication mechanisms.
All users who require access to secure portal resources must be identified.
Users are logged out after a defined period of inactivity.
Authorization/access control mechanisms considerations include the following:
– Securable resources in the portal application can be either pages or portlets.
– Authorization control is always checked when a user accesses the portal application.
Access management considerations include the following:
– Access authorizations can be given to either users or groups.
– Centralized management of access control and user accounts is performed.
– The system owner grants and controls all authorizations.
– Client-sensitive data is encrypted using SSL.
Other examples of common client security requirements address the physical infrastructure of
the system, such as protecting the internal IP addresses and site structure, providing denial
of service defense, and providing intrusion detection.
Managing multiple identities

In addition to the security requirements covered above, the system should allow users to
manage multiple identities in a secure way while accessing external systems. This
requirement means that the system must be able to provide a mechanism to store, retrieve,
and map different sets of user secrets or credentials.
Performance requirements
The system performance level depends on the response times and availability of the external
systems.
Additional non-functional requirements that can be captured include usability, reliability, and
portability requirements.
2.2 Solution design

The solution design follows on from the requirements analysis described in section 2.1 above.
The IT system has two aspects. The infrastructure design must create the environment for
the storing and sharing of the SSO credentials between the applications. At the same time,
the portlet application must be written to make use of these credentials. Therefore, we have
chosen to implement two sample portal applications in our solution. They are:
Basic Authentication portlet: This portlet application uses a HttpBasicAuthCredential
active object to call a protected resource in the business tier using system credential
secrets. The business scenario that this simulates is when, for example, a company wants
their employees to access a protected intranet application through the Internet. Instead of
duplicating all the portal users to the security configuration on the business server, it can
use a system user for that resource. Then, it can use the secure portal configuration to
control and administer access for the employees. This centralized security management
will be especially advantageous when a number of applications are added.
Web Service Authentication portlet: This portlet application uses a
UserPasswordPassive passive credential object to retrieve the system username and
password credential secrets. It then uses them to call a StockData Web service that is a

protected business tier application. This example simulates a business application,
StockData, that has been made available through the Web by the creation of a Web
Service around its public operations. In this case, the only public operation exposed by the
Web Service is get StockData. Refer to redbook Web Services Wizardry with WebSphere
Studio Application Developer, SG24-6292-00 for more information. Refer to WebSphere
Version 5.1 Application Developer 5.1.1 Web Services Handbook, SG24-6801 for
information about how to implement security using the new WS-Security 1.0 Standard
(authentication, integrity, and confidentiality).
Both of these sample applications follow the Extended SSO Application pattern. Their
Runtime pattern uses the credential mapping approach. This consists of mapping the Web
user identity to another user ID to access the back-end system. In our samples, we use
system credentials stored in the vault to access protected business applications. The
authorization to access the back-end is actually implemented in the front-end. In other words,
if the user has the authorization to access the portlet, then it follows that he or she has
authorization to access the business application.
2.2.1 Functional view

The functional view diagram in Figure 2-2 shows the main subsystems and connections
involved in this SSO credential mapping application. It builds clearly upon A Secure Portal
Using WebSphere Portal V5 and Tivoli Access Manager V4.1, SG24-6077 components with
the addition of a new business tier. This represents existing business applications that need
to be accessed through the secure portal.
Internet Security Tier Application Tier Business Tier
Https request Authentication Mutual SSL Web Server Mutual Application Server Application Server
Browser Authentication Proxy SSL Credential
WAS Trust Trust
Session Plug-in Association Mapping Association
Portal Portal
Interceptor Interceptor
Server Server
LDAP
over LDAP over SSL
SSL
Directory User
Server Registry
LDAP
over User
SSL Repository
Policy/
Authorization Policy
Server Store
Key
JAAS API
Subsystem Read/Write
Datastore Vault Adapter
Component Credential
Vault
Tier
Synchronous
Connection
Figure 2-2 SSO credential mapping solution functional view
Below is a summary of those components, plus a description of the new ones.
Key concepts
The key concepts to the functional view include the following:
Authentication proxy: Manages the authentication process
Directory server: Provides access to the user registry and user repository
Policy/authorization server: Maintains the policy store and manages the authorization
process
Portal Server: The Portal Server where the SSO credential mapping application operates

Credential vault: The repository used to store the credential secrets. The vault
implementation is the actually repository used to store the credentials, for example
WebSphere Portal’s database or TAM’s lock box. For a full overview of credential vault,
please see 1.2.1, “Credential vault organization” on page 3
Vault adapter: The means by which the WebSphere Portal Server accesses the different
implementations of credential vault
Application server: The IBM J2EE application server, WebSphere Application Server
WebSphere security: The component of WebSphere that is responsible for security
management of the J2EE applications. The back-end business applications that the SSO
application accesses are protected using standard WebSphere security mechanisms
Business applications: The back-end business applications that will be accessed by the
portlets
2.2.2 Operational view

Figure 2-3 depicts the SSO credential mapping solution from an infrastructure perspective.
Internet External Network Firewall Intranet
Customer
Security Node Application Node Business Node
Security
Administrator
Figure 2-3 SSO credential mapping solution operation view
We show three locations: the Internet, an external network, and the intranet. The Internet and
the external network are as described in the A Secure Portal Using WebSphere Portal V5 and
Tivoli Access Manager V4.1, SG24-6077 solution with no firewall protection. But we have
chosen to place our back-end node in the intranet protected by a firewall. We assume that it is
part of an already existing company infrastructure. As such, the implementation of the firewall
is out of scope for this publication. The system comprises of the following three physical
nodes:
Security node: Responsible for security services such as authentication, access
management, and directory services
Application node: Responsible for providing application services such as the portal
application
Business node: Responsible for the delivery of a company’s business services that must
be accessed via the Web or even internally through other clients. Business data will be
held here. Therefore, this node requires strong security.
The security and application nodes are the same nodes that are covered in A Secure Portal
Using WebSphere Portal V5 and Tivoli Access Manager V4.1, SG24-6077. Please note that
the security and application nodes could also be behind the firewall, assuming that the
firewall is configured correctly.

2.2.3 Application design
In this section, we describe the design of the sample portlet applications used to show SSO
credential mapping.
Component model
The component model describes the IT system from the software viewpoint. It details the
components in terms of their responsibilities, interfaces, and relationships. It also documents
how they collaborate together to fulfill the required functionality. A component is an
independent part of the overall system. It can be large or small, such as a number of classes,
a program, or a software product. The model can be either at a specification (technology- and
product-agnostic) level or a physical (technical) level. In this chapter, we have chosen to
document the specification level.
Component relationship diagram

Figure 2-4 presents the components and their relationships in the system.
<<component>>
Security S ervices
<<component >>
Credential Vault Services
<<component>> <<component>>
Dialog Portal Server
<<component>>
Portlet credential applications
Figure 2-4 SSO credential mapping component relationship diagram
Component descriptions
The following components are included:
Dialog: Responsible for controlling the HTTP requests and responses into and out of the
system. It uses the security services component to authenticate the requests. This
component will be implemented using WebSeal.
Security services: Responsible for security management and authentication and
authorization services. This is implemented using TAM.
Portal Server: Responsible for portal services and implemented by WebSphere Portal
Server
Credential vault services: Responsible for managing and storing the credential secrets.
It offers several interfaces to these values. In our sample, we are interested in the
HttpBasicAuthCredential active credential objects and the UserPasswordPassive
credential objects.
Portlet credential application: Represents the portlet credential applications that the
portal offers to the client. In our case, these are the basic authentication and the Web
service authentication portlet application.

Component Interaction diagram
The UML sequence diagram in Figure 2-5 shows the inter-component communication for use
case UC-01 described in “Use cases list” on page 7.
Subcomponents of the portal credential application component Represents back-end

business components
: Dialog : Security : Portal Server : Port let : PortletCredentialManager : Credential : Business

Services Vault Services Services
: Customer
request
checkAuthentication
callPortlet
check authorization
callCredentialPortlet
getCredentials
getCredentials
callBusiness Service
response
Figure 2-5 SSO credential mapping interaction diagram
Walkthrough
1. The user requests the credential mapping portlet.
2. The Dialog component receives the request and checks for authentication in combination
with the security services.
3. Once authentication is established, the request is forwarded to the Portal Server.
4. The Portal Server then checks for user authorization on the requested portlet through the
security services component.
5. Once authorized, the portlet then retrieves the credential secrets from the credential vault
services via the Portlet Credential Manager.
6. The external back-end business service is then called using the retrieved credential
secrets.
7. The response is transferred back to portlet, which creates the page fragment to be
displayed.
8. The Portal Server then aggregates the page fragments together to return to the user.
Solution micro design

In this section we describe the micro design (a phase in the Global Services method designed
to prepare for the build cycle(s) of a specific release of the system) of the two samples that
were built. For each sample, we list the code elements created and provide a summary of
their function. Also, the credential retrieval model is shown in the form of sequence diagrams.
The classes listed below are found in the sample code. Instructions for obtaining the sample
code from this Redpaper can be found in the Appendix B, “Additional material” on page 93.

Basic authentication portlet
The Basic Authentication portlet contains the following:
BasicAuthPortlet.java: Uses the credentials stored in PortletConfig variable slotname to
call the link stored in PortletConfig as url
BasicAuthPortletSecretManager.java: Initiates and provides methods to access the
credential vault service
BasicAuthPortletViewBean.java: Encapsulates the response values for the portlet JSP
page
BasicAuthPortletView.jsp: Displays the portlet page fragment for the view mode
The sequence diagram in Figure 2-6 shows the method calls and interactions that take place
when the portlet is displayed on a page.
: : : : : :
: System BasicAuthPortlet BasicAuthPortletSecretManager CredentialVaultService HttpBasicAuthCredential BasicAuthPort letViewBean BasicAuthPortletView.jsp
doView()
basicAuthConnection()
getCredential()
getAuthenticatedConnection()
setUrlres p(String)
service()
Figure 2-6 Basic Authentication sample portlet sequence diagram
Web Service Authentication portlet

The Web Service portlet contains the following:
WsAuthPortlet.java: This portlet class retrieves the credentials stored in PortletConfig
variable slotname
WsAuthPortletSecretManager.java: Initiates and provides methods to the credential
vault service to obtain the credential secrets
WsAuthPortletViewBean.java: Encapsulates the credential and other response values
for the portlet JSP page
StockDataProxy.java: Provides the StockData Web Service client
WsAuthPortletView.jsp: Displays the portlet response for the view mode
The sequence diagram in Figure 2-7 on page 17 shows the method calls and interactions that
take place when the invoke action is called for this portlet.

: : : CredentialVaultService : : WsAuthPortletViewBean : :
: System WsAuthPortlet WsPortletSecretManager UserPasswordPassiveCredential WsAuthPortletView.jsp StockDataProxy
doView()
getCredentialSecret()
getCredential()
getUserId( )
getPassword( )
setUsername(String)
setPassword(String)
service() setUsername()
setPassword()
getStockData()
Figure 2-7 Web Service Authentication sample portlet sequence diagram
Business service sample applications.

This is a short introduction to the back-end business sample applications that the SSO
credential mapping examples will access. More information about the sample applications is
provided in Chapter 5., “Sample applications” on page 59.
SimpleServlet Basic Authentication Sample: A servlet that is protected by HTTP Basic
Authentication using WebSphere security. This is used to show active credential objects.
Stock Data Web Service Sample: Simulates a bean (StockData) that accesses some
legacy business stock information. This data is then made available via the Web through
the creation of a Web service on the StockData bean. It has also been protected using
standard WebSphere security and is used to show passive credential objects.
2.3 Design guidelines

The following describes the guidelines to keep in mind when designing an SSO application.
2.3.1 Portlet development

The WebSphere Portal architecture is an extension to the Java servlet architecture and as
such conforms to standard Web application guidelines. It also follows the MVC (Model, view,
controller) design pattern. However, the portal has unique features that include, among
others, multiple portlets per page, portlet page flow control, and inter-portlet communication.
The topic of best practices for portlet development is too large to go into in this publication
and is already thoroughly discussed in other publications. Instead, please refer to the
following Redbooks and guides.
Redbooks:
IBM WebSphere Portal V5, A Guide for Portlet Application Development, SG24-6076
Portal Application Design and Development Guidelines, REDP-3829

Portlet coding guidelines:
http://www7b.software.ibm.com/wsdd/zones/portal/portlet/portletcodingguidelines.html
Understanding the portlet component model:

http://www7b.boulder.ibm.com/wsdd/library/techarticles/0309_fischer/fischer.html
Info-center link (choose left-hand frame option Information Development):

http://pvcid.raleigh.ibm.com/
2.3.2 Using the credential vault portletservices

The credential vault portletservice provides a way to single sign-on to applications outside
WebSphere Portal’s security realm. In this section, we detail the various choices to make
when developing an application that uses the credential vault. For a technical description of
the credential vault, please refer to 3.3, “Credential vault PortletService” on page 27.
Segment type
Segments can be either administrator- or user-managed. The main technical difference is that
users can create vault slots only in user-managed segments. Only administrators are allowed
to create in administrator-managed segments. Users can set and retrieve credentials in both
types.
Slot type
There are 4 different type of slots: private, user, system, and administrative. See section
“Vault slot” on page 4 for full details. For user-managed credentials, it makes sense to choose
private or user slots. An example of a private slot is a POP3 mail account portlet. In this
scenario, the portlet is unlikely to be used by all users. Therefore, an edit screen can be
created for the each user to define his or her slot and credentials. There also is no need to
share this information between other portlets.
A shared slot example would be if you wanted to allow a user access to various server
applications through a portal: for example, an expenses and time reporting application that
normally runs from a LAN workstation. The user’s LAN ID and password are then stored in
the credential vault and shared between the different portlets. This gives the user access to
his or her desktop applications remotely through a Web interface.
The administrator-created slot types are system and administrative. Only these slots can be
viewed through the WPS admin, and only system credentials can be edited. An example of
system slot usage is, for example, a legacy application that is protected by a single system
ID. This ID can be stored and then shared among the users who wish to access that
resource. It provides seamless SSO accessibility while keeping the system ID secret.
The last example is the administrative slot. This should be used for administrator-defined
resources such as a company’s e-mail system. Since it is assumed that all users will use this
portlet, the slot can be created by the administrator beforehand. The portlet is then written to
allow the users to manage their credentials in that slot.
Credential object types

The CredentialVault PortletService returns credentials in form of credential objects. These
can be passive (where the portlet can extract the secret) or active (where the secret is hidden
and an authentication method provided). Please see section 3.3.3, “Types of credential
objects” on page 27 for full details.

Passive credential objects are necessary to use when accessing a custom-built external
application that does not support any common security standard. Because the secret is
actually retrieved from the vault, this method is therefore less secure than active.
The active credential object is the most secure method, but it is limited by the business
methods available. They are httpbasicauth, httpformbasedauth, javamail, LTPA token,
siteminder token, and Webseal token. These are discussed in full in 3.3.3, “Types of
credential objects” on page 27. Applications and websites can be easily protected by
HTTP basic and form-based authentication. Therefore, these forms of credential objects
are probably the mostly used.
An example of Webseal and Siteminder usage would be an extranet portal application that
needs to access an existing internal application protected by Webseal or Siteminder.
However, it is probably more common for a company to try to integrate all its applications into
one security management system.
More information about credential vault applications can be found in the redbook IBM
WebSphere Portal V5, A Guide for Portlet Application Development, SG24-6076 and the
following URLs.
Using active credentials objects to connect to secured web applications:

http://www7b.software.ibm.com/wsdd/library/techarticles/0307_konduru/konduru.html
Using credential vault to provide SSO for portlets:

2.3.3 SSO guidelines

In this section, we discuss general guidelines for SSO application design.
The SSO performed in the Web tier is appropriate for environments with no back-end
systems or where access to back-end systems does not need to be executed under the Web
user’s identity.
The key consideration in establishing a Web SSO solution is the diversity of the e-business
environment. There are two key types of environments to consider: a homogeneous
application server environment or a heterogeneous environment (multiple vendors/versions
of application servers).
Web SSO
Web SSSO provides seamless access to multiple Web applications located in the same
security domain. Web SSO runtime patterns include a homogeneous application server and
heterogeneous application servers. The Homogeneous Application Server pattern is where a
single Web tier is used for SSO and all applications are implemented on the same application
server. The Heterogeneous Application Servers pattern uses an authentication proxy to
control SSO access to multiple application servers of various types.
The Application pattern for these Runtime patterns is discussed in “Single sign-on” on
page 2.
Homogeneous application servers

A homogenous application server is a Web tier environment where all applications are
implemented on the same application server and can exploit that application server's security
server for SSO functionality. Figure 2-8 on page 20 depicts a Homogenous Application server
pattern.

Directory &
Security Server
Application
Server
Application
Browser
Server
Client Single Application 1

Tier Sign-On
Application 2
Web Single Sign-On application pattern
Figure 2-8 Web SSO (homogenous application servers) Runtime pattern
Pros:
Simple, effective security model for applications built within the same application server
environment.
Cons:
Does not support applications outside the application server domain.
Heterogeneous application servers

A Web tier with multiple different vendor application servers can only implement SSO with the
deployment of a separate security server. The external security server provides an
authentication proxy that intercepts requests to map or transform user credentials into the
appropriate credential format for that application server. This arrangement is shown in
Figure 2-9 on page 21.

Directory &
Security Server
Application
Server
Authentication
Browser Application
Proxy
Server
Client Single Application 1

Tier Sign-On
Application 2
Web Single Sign-On application pattern
Figure 2-9 Web SSO (Heterogeneous Application Servers) Runtime pattern
Pros:
Provides a unified, secure authentication model.
Supports multiple vendors/platforms.
Cons:
Will require modification and migration to include existing applications.
Can be difficult to model the separation or aggregation of authorization data across many
applications.
Requires that applications support an externally-managed security proxy.
2.3.4 Extended SSO Runtime patterns

Extended SSO Runtime patterns provide SSO to back-end applications. There are two such
extended Runtime patterns: the Credential Propagation pattern and the Central Authorization
Service pattern. Credential propagation can be further broken down into credential mapping
and credential transformation. The central authorization service is the addition of the
back-end application into the control of the security server.
There are two major approaches to implementing the Extended Single Sign-On Application
pattern discussed in “Single sign-on” on page 2. These approaches are:
Credential Propagation pattern
Extending the security context to back-end systems enables the non-repudiation of

transactions initiated by the user at the back-end. Credential propagation takes one of two
approaches:

– Credential mapping: The Web user identity is mapped to a user ID used to access the
back-end system.
– Credential transformation: The Web user identity is forwarded to the back-end
system but is transformed into the format acceptable to that system.
The Credential Propagation pattern is depicted in Figure 2-10.
Directory &
Security Server
Application
Server
Application
Browser Application Server
Server

Application 2
Extended Single Sign-On application pattern
Figure 2-10 Extended SSO (Credential Propagation) Runtime pattern

Pros:
Allows for maximum flexibility and incorporation of non-compliant applications
Cons:
Introduces complexities related to credential management
Introduces requirements for additional error handling and transaction support at each
application node
Central Authorization Service pattern

Another alternative for extending the security context to back-end systems is to allow the
same security service that controls the Web tier to control the back-end applications. The
security server provides the role-based authorization for controlling back-end resources. No
credential mapping or transformation is required. The security context is preserved all the way
through to the back-end system. The Central Authorization Service pattern is depicted in
Figure 2-11.
Directory &
Security Server
Application
Server
Authentication Application
Browser Application
Proxy Server
Server

Application 2
Extended Single Sign-On application pattern
Figure 2-11 Extended SSO (Central Authorization Service) Runtime pattern

Pros:
Simplifies user management across all applications
Unifies user profile information and reduces redundancy
Cons:
All applications have to support the chosen security proxy and may require complex
modification and migration.
Design considerations
There are some characteristics of the applications that will affect the solution of choice:
Does the application let the application server do the authorization? If not, a proxy solution
may be required.
When incorporating an existing application with its own security model into a larger
security domain, deactivate the application's security mechanism, if possible, and defer
authentication and authorization to the larger secure domain.
If the application requires a form-based login, there may be no solution short of modifying
the application or providing custom code to wrap the application and simulate the posting
of the application's login form.
For further information about the Access Integration patterns please refer to A Portal
Composite Pattern Using WebSphere Portal V5, SG24-6087 and Access Integration Pattern
Using WebSphere Portal Server, SG24-6267.

3
Chapter 3. Technology options

In this chapter, we discuss technology options available for implementing SSO for
WebSphere Portal. We also cover WebSphere Portal credential services.

3.1 Introduction
In order to provide an SSO experience, we must shield the user from experiencing multiple
authentication challenges from any back-end applications they may access. Various
approaches are available for performing this shielding.
In the following sections, we review approaches to achieving an SSO. If you decide to use the
portal credential vault, you also have some technology choices. These also are reviewed.
Finally, we implement the portal credential vault in this chapter.
3.2 Approaches to achieve SSO

It may be possible to modify the back-end applications so that they fall within the same
security realm as the WebSphere Portal. Any portlet can then present a user’s existing portal
credential and it will be honored by the back-end application.
If the back-end application is outside of the portal’s security realm, portlets must be able to
store and retrieve user credentials for the back-end application they need to access.
For accessing applications outside the portal’s security realm, the Portal Server provides a
credential vault service that portlets can use to store user ID and password (or other
credential) information.
3.2.1 Extending the security realm

This section addresses the options available for the creation of a security domain between
multiple Web applications.
LTPA Authentication
WebSphere Application Server can provide single sign-on between itself and certain Web
application servers by sharing Lightweight Third Party Authentication (LTPA) tokens. LTPA
tokens contain user data, expiration time, and a digital signature that is signed with a private
key of the authenticating user. They are stored as encrypted cookies. The key for decrypting
the cookie is normally generated by WebSphere Application Server and shared with any
back-end application servers.
Normally, a shared LTPA token will be used to provide single sign-on between WebSphere
Portal and a back-end Lotus Domino Application Server. It is also possible to use LTPA to
provide single sign-on between WebSphere Portal and other WebSphere Application Servers
(that do not fall within the same WebSphere security realm as the application server used by
WebSphere Portal).
It is important to note that IBM has developed the LTPA mechanism. While they have
published the specification, it is generally only supported by IBM products. The wider
computer security community has largely adopted Kerberos technology to provide the same
functionality. The pros and cons of the LTPA approach and implementation are not discussed
here.
External Security Manager

You can use an external security manager to perform an authentication between the various
Web applications in the SSO domain. Choices for WebSphere Portal are Tivoli Access
Manager (TAM) and Netegrity SiteMinder. TAM uses a WebSeal token and SiteMinder uses
the SiteMinder token as the authentication credential.

Credential vault
Due to their design and because of various security aspects, it is often not possible or not
reasonable for back-end applications to relinquish control of their application security. This
requirements applies even if it is possible to ensure that users access these applications
solely through the WebSphere Portal and not directly via a Web browser (or other client
software).
Therefore, those back-end systems should still be able to use their own authentication and
authorization mechanisms. To allow for this and still obtain single sign-on, the portlet must
present appropriate credentials to the back-end system. This, in turn, means that the portlet
requires some method to store and retrieve credentials. The portlet can store credentials as
user-specific portlet data. Of course, the credentials can even be hard-coded into the portlet,
but this approach is not desirable from an architectural and security standpoint.
It is preferable that a secure, scalable service be implemented, with a primary requirement of

ensuring the security of the stored credentials. Then, the portlet uses calls to this service to
store and retrieve credentials, as needed, without knowledge of the low-level implementation.
Such a service is referred to as a credential vault.
3.3 Credential vault PortletService

WebSphere Portal offers a credential vault as a PortletService. The PortletService interface
of the Portlet API enables portlets to use pluggable services via dynamic discovery. The
credential vault is such a system. It provides portlets with a mechanism for mapping from a
user identity to a credential, such as a secret. Therefore, portlets do not need to store user
credentials as part of the user-specific portlet data.
3.3.1 Vault Implementation

The vault implementation is the repository where the credential secrets are actually stored.
Choices are:
Portal database: The default vault implementation
Tivoli Access Manager lock box: The TAM vault adapter plug-in shipped with
WebSphere Portal. This is more applicable in a centralized security scenario where
central credential management and storage is required.
Custom repository: A custom repository such as an already existing database that holds
users credentials. To do this, you must write a vault adapter and plug it into the
WebSphere Portal. Plugged-in vaults can be managed only by an administrator.
3.3.2 Vault organization

There are a number of choices available in the organization of the vault segments and slots.
These are discussed in 1.2.1, “Credential vault organization” on page 3. Here, we are
concerned with the available technologies that can be used for storing credentials and the
methods available for calling the back-end application.
3.3.3 Types of credential objects

Passive credential objects
The passive credential objects include the following:
UserPasswordPassive: Stores secrets in the form of user ID/password pairs
Chapter 3. Technology options 27

SimplePassive: Stores credentials as a “serializable” Java object
JaasSubjectPassive: Stores credentials as javax.security.auth.Subject objects. It is used
to provide portlets with the JAAS subject that the portal established for the user.
Active Credential Objects

The active credential objects include the following:
HttpBasicAuth: Stores user ID/password secrets and supports HTTP Basic
Authentication
HttpFormBasedAuth: Stores user ID/password secrets and supports HTTP Form-Based
Authentication
JavaMail: Stores user ID/password pairs and leverages the authentication functionality of
the javax.mail API
LtpaToken: Authenticates with a back-end system that is within the same WebSphere
Application Server SSO domain as the portal
SiteMinderToken: Authenticates with a back-end system that is within the same
SiteMinder SSO domain as the portal. This credential should be used when SiteMinder is
used as an authentication proxy for the portal.
WebSealToken: Authenticates with a back-end system that is within the same WebSEAL
SSO domain as the portal. This credential should be used when a WebSEAL
authentication proxy is used by the portal.
3.4 Summary
This chapter presents the various SSO solution alternatives. Then, it continues with a
discussion of the technical options available for the WebSphere Portal credential vault
service.

4
Chapter 4. Implementing the runtime

environment
The objective of this chapter is to provide an overview of the runtime architecture for the SSO
solution implementation described in Chapter 2, “Requirements and Design” on page 5. In
addition, we provide the high level implementation steps and detailed implementation
instructions for the installation and configuration of all the required components needed to
implement this environment. We also provide references to find more detailed information.
As we already mentioned in previous chapters, the SSO solution is based on an A Secure

Portal Using WebSphere Portal V5 and Tivoli Access Manager V4.1, SG24-6077
implementation.
Note: Please refer to chapter 4 of the above redbook for the base runtime environment
implementation.
This chapter is organized into the following sections:

Planning
Back-end Installation, configuration, and application setup
TAM credential vault adapter installation and configuration
Using portal and TAM credential vaults for accessing back-end applications

4.1 Planning
Figure 4-1 shows the hardware and software configurations used in SSO solution
implementation.
Hardware:
IBM Netfinity 5100
PIII 933MHz
1152MB RAM
18GB HDD
Software stack:
Windows 2K + SP3
IBM HTTP Server V1.3.26
WebSphere Application Server
Enterprise Edition V5.0
WebSphere Portal Server V5.0.1
Internet External Network Firewall Intranet
Customer
Security Node Application Node Business Node
Security Hardware: Hardware:

Administrator IBM PC 300PL IBM PC 300PL
PIII 660MHz PIII 660MHz
512MB RAM 512MB RAM
20GB HDD 20GB HDD
Software stack: Software stack:
Windows 2K + SP3 Windows 2K + SP3
Tivoli Access Manager V4.1 + FP6 WebSphere Application Server
(WebSeal, Policy & Authorization Enterprise Edition V5.0
Servers)
IBM Directory Server V4.1.1 + FP2
Figure 4-1 Hardware and software used in the SSO implementation
For the WebSphere Application server hardware requirements, installation, and configuration
information about the back-end machine (named as Business Node in the diagram above),
refer to “Installing a WebSphere Application Server” on page 31.
4.2 Setting up the back-end business applications

The SSO sample application is an example of how to use system credential slots for
credential mapping. It accesses these credentials using both active and passive credential
objects to call protected external applications. To show this, we have created two simple
back-end J2EE applications that the portlets will call. These back-end applications are:
SimpleServlet Basic Authentication Sample: A servlet that is protected by HTTP Basic
Authentication using WebSphere security
Stock Data Web Service Sample: A Web service that has been protected using standard
WebSphere security. It is used to show passive credential objects.

These samples are standard J2EE applications that have been developed to run on
WebSphere Application Server. We install on the Enterprise Edition, as that is the version that
comes with WebSphere portal. However, any other edition would do. The following sections
outline the steps required to install and configure the back-end sample applications.
4.2.1 Installing a WebSphere Application Server

The infrastructure overview in Figure 4-1 on page 30, shows an overview of the software and
hardware that was used to implement this SSO sample application. The installation and
configuration of this firewall is out of the scope for this publication. We are concentrating on
the sample application only.
Hardware requirements for WAS

Operating system: Windows® 2000 with Service Pack 3
Processor: Intel® Pentium® processor at 500 MHz, or faster
Physical Memory: Minimum 256 MB memory; 512 MB recommended
Disk space: Minimum 710 MB free disk space for installation (includes SDK)
To simplify the installation, install WebSphere Application Server without the HTTP server.
For the Enterprise Edition, select custom install and decline everything except the javadoc.
The sample application doesn’t require any special Enterprise features.
For installation documentation, please refer the WebSphere Application Server installation
guide. The WebSphere library can be found at:
http://www-306.ibm.com/software/webservers/appserv/infocenter.html
4.2.2 Setting up security

The sample application uses WebSphere global security to protect the two back-end
applications. For simplicity, we use the local operating system as the security user registry. To
enable this, we need to set up certain users and groups.Two users, basicuser and
wsauthuser, need to be created for the simpleservlet and webservice examples respectively.
The webservice example requires that the wsauthuser user is in a new member group called
StockManagers. For further information about WebSphere security, please refer to the
redbook IBM WebSphere V5.0 Security, SG24-6573-00, and also check the WAS information
center at the link below. To access the information, click WebSphere Application Server ->
All topics by feature -> Security.
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp
Set up the users/groups

The following is a step-by-step guide to setting up the users and groups in the local operating
system that are needed for the sample application.
Creating users
1. Click Start -> Settings -> Control Panel -> Administrative Tools -> Computer
Management -> Local Users and Groups -> Users to display the screen in Figure 4-2
on page 32.
Chapter 4. Implementing the runtime environment 31

Figure 4-2 Computer management window
2. Right-click Users -> New User.

3. Add the users basicuser and wsauthuser with a password. Select User must change
password at next logon. Then select Password never expires and click Create. The
users should then appear in the computer management window in Figure 4-3.
Figure 4-3 Adding a user
Creating StockManagers group

1. Click Start -> Settings -> Control Panel -> Administrative Tools -> Computer
Management -> Local Users and Groups -> Users. It should appear as in Figure 4-2.
2. Right-click Groups -> New Group
3. Add the StockManagers group, as shown below in Figure 4-4 on page 33. Also, add
wsauthuser as a member to that group.

Figure 4-4 Adding a group
Set up WebSphere security

WebSphere is installed with security disabled by default. Here, we show here a step-by-step
guide to switching on the global security configuration needed for the sample application that
runs on the business node. Switching on global security requires that a user and password be
used when starting and stopping the default server. A username/password also is required to
log in to the administration console. It is probably a good idea to back up the current
WebSphere configuration before setting up security in case of any errors that may occur. Use
the following standard commands to backup your WebSphere configuration:
<websphere install root>\bin\backupconfig -nostop
By default, the backup file is the following:

<websphere install root>\bin\WebSphereConfig_YYYY-MM-DD.zip
You can use the restoreconfig command to return to the original settings. See the WebSphere
Info Center for more details.
1. Assuming that WebSphere server1 is started, open a browser and access WebSphere’s
admin console at http://<hostname>:9090/admin where hostname is the host name of the
business node. Log in once you access the administrative console.
2. Click Security -> User Registries -> Local OS and enter the username and password
used when installing WebSphere and click OK. This is normally Administrator. In the
example below use wsuser.
These settings are depicted in Figure 4-5 on page 34.

Figure 4-5 Setting up local OS server user and password
3. Go to Security -> Global Security and check the Enabled checkbox to enable the global
security. By default, this step enables the Enforce J2EE security. We do not need it, so
uncheck it again. The other settings should be left as defaulted, using the local OS and
SWAM. Then, click OK. The screen in Figure 4-6 on page 35 is displayed.

Figure 4-6 Enabling WebSphere global security
4. You should see the following notification of changes to be made to the master
configuration at the top of your WebSphere window. Click Save to display the screen in
Figure 4-7.
Figure 4-7 WebSphere master configuration save notification message

5. The Save to master configuration screen will appear as in Figure 4-8. You can see the
changes made to the security configuration. Click Save again and a success message
should appear confirming that the changes have been added to the master configuration.
Figure 4-8 Save master configuration dialog
6. For global security to take effect, you need to stop and start server1 either by using the
standard WebSphere commands or by going through the services panel.
Note: With global security enabled, the server username and password will be required
after the first time you stop and start the server or when you access the administrative
console.
These commands include the following:

<websphere install root>\bin\startserver server1 -username wsuser -password wsuser
<websphere install root>\bin\stopserver server1 -username wsuser -password wsuser
4.2.3 Deploying the back-end sample applications

The two sample applications come as EAR (Enterprise Archive) packaged files. Refer to
Appendix B., “Additional material” on page 93 for instructions on how to obtain the sample
code.
The files you need include

SimpleServlet sample: itsoSSOEAR.ear
Stock data Web service sample: itsowsEAR.ear
The following describes the deployment procedure for both of the EAR files. You need to
perform these procedures twice, one for each EAR file. This process consists of a number of
screens that should retain the default settings (except on the first screen).

Assuming that WebSphere server1 is started, open a browser and access WebSphere’s
administration console at http://<hostname>:9090/admin. Since global security is enabled,
the servers username and password will need to be entered.
7. Click Applications -> Install New Application
8. Preparing the install - Specify the EAR module screen: Choose Local path and
browse to the EAR file location on the file system. Click Next.
9. Preparing the install - Default bindings and mappings screen: Leave as the default:
Do not override existing bindings and Default virtual host name for Web modules
(default_host). Click Next.
10.Step1 - Provide options screen: Leave as default. Application name is either
itsoSSOEAR or itsowsEAR.
11.Step2 - Map virtual hosts screen: Leave as the default_host.
12.Step3 - Map modules to application servers screen: Leave as default.
13.Step4 - Map security roles to users/groups screen: In this screen, you should see the
security configuration that was set up in the EAR file for each application. For the
itsoSSOEAR.ear, “All Authenticated Users” is checked. This means that all valid users in
the operating system can be used to view that application.
The SimpleServlet security setup screen is shown in Figure 4-9.
Figure 4-9 SimpleServlet security setup

Only users in the group StockManagers have access to the itsowsEAR.ear. This relates to the
wsauthuser created earlier. The Stock data Web service security setup is shown in
Figure 4-10.
Figure 4-10 Stock data Web service security setup
14.Step5 - Summary screen: You should see a summary of the EAR installation. If
successful, then click Save to Master Configuration.
15.Save to master configuration screen: This lists the changes to be made to the master
configuration. Click Save to Master Configuration. On the next screen, click “Save:”
Now repeat this process for any other EAR files that you have.
You then should be able to see the two new enterprise applications by clicking on
Applications -> Enterprise Applications. Select the checkboxes and click Start.
4.2.4 Verifying the back-end sample applications

The last step is to verify that the back-end sample applications are running correctly before
continuing with the next section. There are two applications to test: the SimpleServlet basic
authentication sample and the StockData Web service sample.
SimpleServlet basic authentication sample

1. Assuming that WebSphere server1 and the SimpleServlet application are running, open a
browser and go to
http://<hostname>:9080/itsoSSO/SimpleServlet
(where hostname is the host name of the business node).

2. The authentication pop-up in Figure 4-11 should appear. Type in the basicuser username
and password created earlier.
Figure 4-11 SimpleServlet basic authentication pop-up
3. If the username and password are correct, the response in Figure 4-12 should be seen
from the SimpleServlet.
Figure 4-12 SimpleServlet response
4. To test that security is really working, try closing the browser and doing the same
procedure with an erroneous username and password. You should be allowed three tries.
Then, a blank screen should be shown.
StockData Web service sample

Assuming that WebSphere server1 is running and the Web service application is open, open
a browser and go to
http://<hostname>:9080/itsoSSOwsClient/sample/StockData/TestClient.jsp
where hostname is the host name of the business node. A screen similar to Figure 4-13 on
page 40 should be shown.

Figure 4-13 StockData Web service sample
5. Click the getStockData() link. Then, enter the wsauthuser username and password
created earlier.
6. Click Invoke and the result should appear as above.
7. Try using a non-existent username and password to check that security is working. You
should see an exception message in the result frame.
4.3 Installing and configuring TAM credential vault adapter

Perform the following procedures on the Application node to implement the Vault adapter for
WPS V5.0 and Tivoli Access Manager V4.1. You need to contact IBM Level2 support for
PQ78315.
1. Place the PQ78315.jar in the <WPS_ROOT>/shared/app subdirectory
2. Expand the jar file in the <WPS_ROOT./shared/app subdirectory by using the jar -xvf
PQ78315.jar command (or by using one of the winZip or pkZip utilities).
3. Modify the <WAS_ROOT>/shared/app/config/services/VaultService.properties file to
reference the new class name (com.ibm.wps.vaultservice.AccessManager41Vault
Adapter)
You will see the following example entries:
types=default,am
default.vaultadapter=com.ibm.wps.sso.vaultservice.DefaultVault
default.config=defaultvault
default.manageresources=true
default.readonly=false
am.vaultadapter=com.ibm.wps.sso.vaultservice.AccessManager41VaultAdapter
am.config=services/am.properties
am.manageresources=true
am.readonly=false
4. Create or modify the properties file referenced by the <am.config> parameter above. In
the example above, the complete path to the file is <WAS_ROOT>/shared/app/config/
services/am.properties.

Attention: Please note that you may have a different sec_master password. If you are
following A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager V4.1,
SG24-6077, sah309r is the password for sec_master.
Modify or add the following parameters to the file:

pduser=sec_master
pdpw=sah309r
pdurl=file:///c:/Program files/WebSphere/AppServer/java/jre/PDPerm.properties
5. Restart WPS
The portal may restart successfully, but then it not be able to serve any pages. If this
happens, check the portal log (such as wps_yyyy.mm.dd-hh.mm.ss.log) to determine
whether the adapter failed to initialize properly.
Note: For more information about the pdurl and where the PDPerm.properties reside,
please review the section “Configure Tivoli Access Manager Java Runtime Environment” in
Chapter 4 of A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager
V4.1, SG24-6077.
4.4 Using portal default and TAM credential vaults

If you have been following along from A Secure Portal using WebSphere V5 and Tivoli
Access Manager V4.1, SG24-6077, we now pick up to logging into the portal.
4.4.1 Logging into the portal

To access the portal through webSEAL, open a new browser window and type in the following
URL and press enter:
https://<host_name>/portal/wps/myportal
where <host_name> is the fully-qualified name of the machine where you have installed
webSEAL. For example, the URL should be similar to
https://m23caatk.itso.ral.ibm.com/portal/wps/myportal
The window in Figure 4-14 on page 42 appears.

Figure 4-14 webSEAL security alert
Click Yes to continue. You will be prompted for the user ID and password in the next screen.
Enter the portal admin user ID and password. For example, we use wpsadmin as the user ID
and sah309r as the password in SSO. Then, click OK.
Click Yes in the security information window if it appears.
The portal's welcome page appears on the screen upon successful authentication, as shown
in Figure 4-15 on page 43.

Figure 4-15 Welcome page
4.4.2 Installing sample portlets

click the Administration Menu that is located on the upper-right-hand corner of the screen
and go to Portlets->Install, as shown in Figure 4-16 on page 44.
Important: At the time of this writing of this Redpaper, we had the following limitation. If
you have Mutually Authenticated SSL, you must turn off mutual SSL, deploy your portlets,
and then turn mutual SSL back on in order to deploy portlets using the Install Portlets
portlet. For more information refer to Chapter 5, “Modifying WebSphere Web Container to
use Mutually Authenticated SSL” in A Secure Portal Using WebSphere Portal V5 and Tivoli
Access Manager V4.1, SG24-6077.

Figure 4-16 Portlet Installation screen
Browse to the location where you have placed the sample war files, itsoSSOPortal.war and
itsowsPortal.war. We can use these files to demonstrate the usage of active and passive
credentials. See Figure 4-17.
Figure 4-17 Browse war file

Select the war file itsoSSOPortal.war (the active credentials sample) from the folder and click
Open. Then, click Next on the browser screen.
The portlet name that is going to be installed will be displayed on the screen, as shown in
Figure 4-18.
Figure 4-18 Portlet to be installed
Click Install. The screen in Figure 4-19 on page 46 appears to confirm that the portlet has
been installed.
Install the other portlet (the passive credentials sample) by following the steps above and
selecting the itsowsPortal.war file. After installing these two portlets successfully, navigate to
Administration-> Portlets-> Manage Applications on the portal screen.

Figure 4-19 Manage applications
Check for the war files in the webmodules list by scrolling down through the existing war files.
The war files discussed above (itsoSSOPortal.war, itsowsPortal.war) should appear in the list
in alphabetical order. You also can find the concrete portlet names deployed through the
above war files in the list box titled Portlets of the Administration->Portlets->Manage
Applications screen, as shown in Figure 4-20 on page 47.

Figure 4-20 Manage portlets
4.4.3 Create/Manage vault segments, slots, and user credentials

If you choose to store the credentials in the TAM Credential Vault, the user ID used to store
the credentials is the value of systemcred.dn in VaultServices.properties, and it must be
defined in Tivoli Access Manager as a Global Sign On (GSO) user. For example, before we
continued in our environment, we had to execute the a command using the following syntax
on the security node for a new user:
user import <shortName><distinguishedName>
An example of a valid command is:

user import wpsbind uid=wpsbind,cn=users,dc=ibm,dc=com
Use the following command syntax if the user already exists:

user modify <shortName> gsouser yes
An example of a valid command in this syntax is:

example: user modify wpsbind gsouser yes
Note: You must start a pdadmin console and log in to issue the command.

Creating a vault segment (using either Default or TAM credential vault)
Navigate to Administration->Access->Credential Vault in the portal window, as shown in
Figure 4-21.
Figure 4-21 Credential vault options
Click the Add a vault segment option to create a new vault segment, as shown in

Figure 4-22 Creation of vault segment
Select either the default credential vault (named Default) or the TAM vault (named am) from
the drop-down list. Enter the vault segment name (for example, ITSOsegment) and other
needed details and click OK. A message saying “the vault segment was created successful”
is displayed on top of the screen, as shown in Figure 4-23 on page 50.

Figure 4-23 Segment created
You can also delete the created vault segment by clicking Manage vault segments and by
navigating to Administration->Access->Credential Vault.
Creating a vault slot under the segment

Navigate to Administration->Access->Credential Vault in the portal window.
click Add a vault slot to create a new vault slot, as shown in Figure 4-24 on page 51.

Figure 4-24 Create vault slot
Enter the following data in the displayed fields for the vault slot creation.
Name: Type basicauthslot.
Vault resource associated with vault slot: Select New and enter basicauthportlet (the
portlet instance name).
Vault segment: Enter the segment name that you have created in the previous steps (for
example, ITSOsegment).
Vault slot is shared: Check this box and enter the shared user credentials (for example,
userid:basicuser and password:basicuser; this is the password you created in “Creating
users” on page 31). Also, enter a description of the slot.
The screen should appear as shown in the Figure 4-25 on page 52 after you enter all of the
necessary details.

Figure 4-25 Vault slot details
Click OK. A message saying “the vault slot was created successfully” will be displayed on top
of the screen.
You also can delete the vault slot created or modify the user credentials by selecting the
Manage system vault slots option of Administration->Access->Credential Vault.
4.4.4 Creating a page and deploying the portlets

click the New Page link on the home page to create a new page, as shown in Figure 4-26 on
page 53. (This link is located on the upper-right-hand corner in the second menubar.)

Figure 4-26 New page
Expand the Advanced options option in the next screen. You will be presented with

Figure 4-27 New page properties
Enter the page title (for example, ITSO_SSO Samples) and other page properties.
Then, select the page layout and set the other properties. (For instance, select single row and
single column page. Then, set the mark up as HTML and leave the other options as they are.)
Click OK. The page Figure 4-28 on page 55 appears on the screen.

Figure 4-28 Created page layout
click Add portlets. Select the portlets that you want to appear on the screen (such as ITSO
Basic Auth Portlet and ITSO Ws Auth Portlet) by browsing through the available portlets
in the next screen, as shown in Figure 4-29 on page 56.

Figure 4-29 Add portlets to the page
Click OK. The screen shown in Figure 4-30 on page 57 is displayed.

Figure 4-30 Portlets added to the screen
Click Done.
The portlets will appear on the screen in the order you have added them, as shown in the

Figure 4-31 ITSO samples page
Note: Refer to Chapter 5, “Sample applications” on page 59 for the portlet execution
details.
4.5 Summary
This chapter contains the implementation guide for the SSO credential mapping sample
applications. It builds on the solution created for A Secure Portal using WebSphere Portal V5
and Tivoli Access Manager V4.1, SG24-6077. First, the environment is introduced, followed
by the installation process for the back-end applications. After that, the creation of the TAM
credential vault is presented. Finally, the sample portlets are installed and deployed.

5
Chapter 5. Sample applications

This chapter shows the realization of the SSO business use-cases as described in 2.1,
“Requirements analysis” on page 6. It also uses the SSO credential mapping sample
applications and the credential vaults deployed and configured in Chapter 4., “Implementing
the runtime environment” on page 29. We display the two portlet samples in operation, basic
authentication and Web service authentication. These show the use of active and passive
credential objects, respectively.

5.1 The sample portlets
This is a summary of the sample application portlets that are run in this chapter.
Basic Authentication portlet: Calls a protected resource using the
HttpBasicAuthCredential active credential object stored as system credentials
Web Service Authentication portlet: Retrieves the credential secrets using a
UserPasswordCredential passive credential object. Then it uses them to call a protected
Web Service. Again, system credentials are used.
These portlets are a practical implementation of the programming for credential mapping
outlined in UC-01 in “Use cases list” on page 7.
5.2 Running the basic authentication portlet

The basic authentication portlet uses the basicauthslot system slot credentials to call the
back-end SimpleServlet application. The portlet uses the HttpBasicAuthCredential active
credential objects to make this call. The portlet has been deployed and added to the portal
page ITSO SSO samples as described in 4.4, “Using portal default and TAM credential
vaults” on page 41. To run these examples, use the following steps.
1. Log on to the portal with a user that has the rights to see the ITSO SSO samples. This
should be any authenticated portal user.
2. Click the ITSO SSO samples link on the first level pages bar.
The portlet then calls the SimpleServlet using the stored credentials.The result should appear
as in Figure 5-1. The settings show the portlet configuration parameters, slotname, and URL.
It also displays the SimpleServlet response that is returned. You can check that this response
is correct by directly calling the URL shown for your back-end application. Note that the
credential’s username and password are not shown because the portlet does not have
access to them using the active credential object method. Therefore, this method is
considered quite secure.
Figure 5-1 Basic authentication sample

5.2.1 Incorrect slot credentials
We also can test the basic authentication portlet with an incorrect user ID and/or password.
1. First, we need to modify the slot credentials
a. Logon into the portal as an administrator and click the Administration link in the top
right corner.
b. Click Access -> Credential Vault -> Manage system vault slots to display a list of all
the system and admin credential slots.
c. Choose Modify Shared Slot for the basicauthslot.
d. The screen in Figure 5-2, which allows you to change the user ID and password for this
slot, should be seen as below. Change them to values appropriate for a non-existent
OS user. These steps show the UC-ADM-02-a as described in “Use cases list” on
page 7.
Figure 5-2 Updating slot credentials
2. The next step is to call the basic authentication portlet. This is described in 5.2, “Running
the basic authentication portlet” on page 60.
3. Figure 5-3 on page 62 shows the exception that is caught when the portlet tries to call
SimpleServlet with the incorrect credentials.
Chapter 5. Sample applications 61

Figure 5-3 Basic authentication portlet using incorrect credentials
5.3 Running the Web service authentication portlet

The Web service authentication portlet uses the wsauthslot to call the business StockData
Web service. The portlet uses passive credential objects to obtain the user ID and password
stored in the wsauthslot. It then sets them in the StockData client proxy that calls the
StockData Web service. Passive credential objects need to be used in this example because
there is no active method provided for Web services as there is with HTTP Basic
authentication. This is not as secure as active credential objects because the credentials are
accessed directly. However, this is the most useful when integrating with bespoken code or
where no ready made standard exists.The portlet has been deployed and added to the portal
page ITSO SSO samples. This is described in 4.4.4, “Creating a page and deploying the
portlets” on page 52. To run these examples, undertake the following steps.
1. Log on to the portal with a user that has the rights to see the ITSO SSO sample. This can
be any authenticated portal user.
2. Click the ITSO SSO samples link on the first level pages bar.
3. Figure 5-4 on page 63 shows the Web service portlet description. Click Invoke to call the
StockData Web service.

Figure 5-4 Web Service portlet
4. The portlet collects the username and password from the slotname defined in the portlet
configuration. Using them, the portlet then calls the StockData Web service located at the
hostname specified in the portlet configuration. The result should appear as in Figure 5-5.
The settings show the portlet configuration parameters, slotname, and hostname. The slot
username and password also are displayed, showing that the portlet has access to those
values. The return data from the StockData Web service is shown just below. Use the
instructions in “StockData Web service sample” on page 39 to call the webservice directly
to check that the return data is correct.
Figure 5-5 Web Service portlet result
Chapter 5. Sample applications 63

5.3.1 Incorrect slot credentials
We have also tested the passive credentials portlet with incorrect user ID and/or password.
We created these by modifying the slot using the procedure outlined in 5.2.1, “Incorrect slot
credentials” on page 61.
1. Call the passive credential portlet again by following the steps in 5.3, “Running the Web
service authentication portlet” on page 62.
2. The Figure 5-6 shows the exception that is caught when the portlet tries to call the Stock
Data Web service with incorrect credentials.
Figure 5-6 Web Service portlet with incorrect credentials
5.4 Summary
The credential mapping sample applications are shown in operation step-by-step. Scenarios
where the user credentials are incorrect are also explained.

A
Appendix A. Implementing the development

environment
The objective of this appendix is to provide the high-level implementation steps necessary to
implement the development environment used for this solution.
This appendix is organized into the following sections:

Development environment overview
Development environment configurations
WebSphere Studio Site Developer
Portal Toolkit
Importing the project source into WSSD
Packaging the application for deployment

Development environment overview
You can set up your development environment to support testing and debugging your portlets
on the local development machine or on a remote server.
WebSphere Studio
The following WebSphere Studio products are supported:
WebSphere Studio Application Developer V5.0.1
WebSphere Studio Application Developer V5.0.1 Integration Edition V5.0.1
WebSphere Studio Site Developer V5.0.1
WebSphere Studio Enterprise Developer V5.0.1
Portal Toolkit
Portal Toolkit V5.0 allows you to set up a portlet development environment by plugging in to
WebSphere Studio. Portal Toolkit provides:
Portlet projects, in which you can create basic portlets based on the PortletAdapter class
WebSphere Portal configuration, with which you can publish your portlet application on
your local WebSphere Portal or on remote WebSphere Portal. Your portlet will appear on
the debug page of your WebSphere Portal.
Portlet application examples for enterprise applications
Development environment configurations

The following sections show the hardware and software requirements to publish portlets on a
local or remote WebSphere Portal.
Local debug
During the installation of Portal Toolkit, the Portal Server is installed to the WebSphere Test
Environment of WebSphere Studio. After installation, you need to create a server with an
environment type of WebSphere Portal Test Environment. Authentication is not provided in
this configuration.
The full portlet development environment with all prerequisite software on a single machine
requires the following:
Table 1 Prerequisite software

Development machine, local debug
Hard disk space 3 GB plus storage for portlet development projects
Memory 768 MB minimum, 1 GB recommended
Operating system Windows 2000 with Service Pack 3 or Windows XP

Development machine, local debug
Software WebSphere Studio V5.0.1

Portal Toolkit V5.0
WebSphere Portal V5.0
Network Fixed IP Address (no DHCP)
Important: For local debugging, the following updates must be installed into the
WebSphere Application Server V5 runtime environment:
WebSphere Application Server Fixpack 1

PQ73644.jar
PQ76567.jar
WAS_Dynacache_05-08-2003_5.0.1_cumulative_fix.jar
WAS_CM_08_12_2003_5.0.1_cumulative_fix.jar
Remote server attach

This configuration allows you to test portlets using a remote WebSphere Portal V5.0
installation. After installation, you need to create a server with an environment type of
WebSphere Portal Remote Server Attach.
This configuration requires the following:
Table 2 Development machine configuration

Development Machine, remote server attach
Hard disk space 2 GB plus storage for portlet development

projects
Operating system Windows 2000 with Service Pack 3 or Windows

XP

Portal Toolkit V5.0
Table 3 Remote server configuration

Remote server
Hard disk space 2 GB plus storage for portlet development

projects
Operating system Windows 2000 with Service Pack 3 or Windows

XP

Portal Toolkit V5.0
Appendix A. Implementing the development environment 67

The primary development tool used for this project is the IBM WebSphere Studio Site
Developer V5.0 with 5.0.1 update. We chose this edition for the host connector support.
Attention: WebSphere Studio Site Developer must be installed from the CD. The
installation fails if attempted from a network drive.
For more information about WebSphere Studio Site Developer visit

http://www-3.ibm.com/software/awdtools/studiositedev/
Installation steps
We can now perform the following steps to install/update the required software for test
environment:
1. Install WebSphere Studio Site Developer 5.0
2. Install the 5.0.1 PTF (update) for WebSphere Studio Site Developer
3. Update the WebSphere Application Server v5.0 runtime environment with the following:
a. Fixpack1 for WebSphere Application Server
b. Interim fixes for WebSphere Application Server
Install WebSphere Studio Site Developer 5.0

Insert the CD labeled WebSphere Studio Site Developer V5.0 (Disc-1) into the CD-ROM
Drive.
The WebSphere Studio Installation Launcher starts automatically, as shown in Figure A-1 on
page 69.

Figure A-1 WebSphere Studio Installation Launcher
Place the mouse pointer over the rectangles in front of the titles to get a brief description of
each of the items listed on the window.
Clicking on a rectangle opens the appropriate HTML document or starts the installation
process of the software.
To start installing WebSphere Studio Site Developer V5.0, click Install IBM WebSphere
Studio Site Developer. This step will displays the installation wizard, as shown in Figure A-2
on page 70.

Figure A-2 WSSD 5: InstallShield Wizard
Click Next to continue. Accept the license agreement shown in Figure A-3.
Figure A-3 WSSD 5: License Agreement
Click Next to continue, as shown in Figure A-4 on page 71.

Figure A-4 WSSD 5: Installation folder
Choose a different folder to install the software or click Next to continue installation in the
default folder.
The screen in Figure A-5 presents you with a list of available program features.
Figure A-5 WSSD 5: Program Features
Make sure that the WebSphere Application Server 5.0 runtime environment is already
selected and click Next. The installation continues in the screen shown in Figure A-6 on
page 72.

Figure A-6 WSSD 5: Begin installation
Click Install to begin the installation process, as shown in Figure A-7.
Figure A-7 WSSD 5: Installing
You will be prompted for the Disc-2 in the middle of the installation process: Insert the CD
WebSphere Studio Site Developer for Windows V5.0 (Disc-2) into the CD-ROM Drive and
click OK to continue the installation process. The results display in Figure A-8 on page 73.

Figure A-8 WSSD 5: Installation done
Click Finish to continue.
When installation is complete, launch the WebSphere Studio Site Developer from the Start
Menu and verify that the installation was successful, as shown in Figure A-9 on page 74.
Note: You do not need to reboot the machine at this point.

Figure A-9 Launch WSSD
Note: The WebSphere Application Server used for the test environment is installed into the
\runtimes subdirectory of WebSphere Studio.
Installing the 5.0.1 PTF for WebSphere Studio Site Developer

In order to update the 5.0 version of WebSphere Studio Site Developer to version 5.0.1, you
need to perform the following steps.
Note: There are known issues that may result in problems during or after applying the PTF.
To ensure proper installation:
Follow the instructions below carefully.
If you have disabled any plug-ins either through the update manager or by modifying
plugin.xml files, re-enable them prior to installation.
1. Log on to your system with a user ID that has write access to the install location (This is
typically an ID with administrator authority on Windows and root authority on Linux).
2. Insert the CD labelled WebSphere Studio Site Developer PTFs into the CD Drive and
copy the contents of /wssdptf to a temporary directory on to your hard drive (for example,
C:/wssd501_update).
3. Start WebSphere Studio Site Developer 5.0.

4. Open the Install/Update perspective (select Help → Software Updates → Update
Manager). Navigate the My Computer section in the Feature Updates view to find the
directory where you unzipped the PTF. From there, find the wssd501/update/WebSphere
Studio Site Developer Updates section. Once there, choose WebSphere Studio Site
Developer (Windows/Linux), as shown in Figure A-10.
Figure A-10 Navigate Update
5. Details about this update are shown in the Preview view. For more information about what
is included in the update, click the More Info link. Click Update to begin the installation.
6. An install wizard is displayed, as depicted in Figure A-11.
Figure A-11 WSSD 501 Update Install Wizard
7. Click Next to continue.

8. Once you have read and accepted the license agreement, click Next.
9. The Optional Features page will appear, as shown in Figure A-12 on page 76.

Figure A-12 Optional Features page
10.Click Next to continue.
Attention: Do not modify the selections. Changing the default choices may result in errors.
11.The final screen of the Install Wizard displays the Install Location, as shown in Figure A-13
on page 77.

Figure A-13 Install location
12.Click Finish to begin the installation.
Attention: Errors may occur if you change the default Install Location.
13.If you are warned that you are about to install an unsigned feature, click Install to
continue. This warning will not cause problems during installation.
14.When the installation is complete, you will be asked to restart the product. Click No
because you must now install the second part of the PTF.
15.Return to the Install/Update perspective. Navigate the My Computer section in the Feature
Updates view and select WebSphere Studio Site Developer Product (Windows/Linux), as
shown in Figure A-14.
Figure A-14 Navigate product update

16.Details about this update are shown in the Preview view. For more information about what
is included in the update, click the More Info link. Click Update to begin the installation.
17.Repeat steps 4 through 8 for this update.
18.When the installation is complete, you will be asked to restart the product. Click Yes to
complete the installation, as shown in Figure A-15.
Note: This action will not reboot your machine.
Figure A-15 Restart workbench
19.To verify that the installation was successful, switch to the Install/Update Perspective
(select Help → Software Updates → Update Manager). Verify that the two features are
at version 5.0.1 (from the Install Configuration view), as shown in Figure A-16.
Figure A-16 Configuration_501
20.Your installation is now complete.
Tip: The following PTFs are available for other WebSphere Studio products:
IBM WebSphere Studio Application Developer 5.0.1 PTF
http://www3.software.ibm.com/ibmdl/pub/software/websphere/studiotools/html/501/wsad/i
nstall.html
IBM WebSphere Studio Application Developer Integration Edition PTF 001 -
General Fixes
http://www3.software.ibm.com/ibmdl/pub/software/websphere/studiotools/html/501/wsadie
/instructions/install.htm
IBM WebSphere Studio Enterprise Developer v5.0.1 Fix Pack
http://www-1.ibm.com/support/docview.wss?uid=swg24004902
Update the WebSphere Application Server v5.0 runtime environment

This step needs to be performed for local debugging.
Run Fixpack 1 for WebSphere Application Server
a. Make sure WebSphere Studio is not running.

b. Locate the file was50_fp1_win.zip in the \wasptf directory of the CD labelled
WebSphere Studio Site Developer PTFs.
c. Extract the contents of this file to the root directory where WebSphere Studio is
installed (for example, C:\Program Files\IBM\WebSphere Studio).
d. Using a command prompt, change to the \runtimes\base_v5\ptf directory where
WebSphere Studio is installed.
e. Run wteInstall.bat, as shown in Figure A-17.
Figure A-17 Executing wteinstall.bat
The installation starts immediately and goes on for quite a while, as shown in Figure A-18.
Figure A-18 Fix Pack 1 for WAS installation
When complete, install messages are written to the log files in the \runtimes\base_v5
\properties\version\log directory where WebSphere Studio is installed.
Run interim fixes for WebSphere Application Server
a. Insert the CD labelled WebSphere Application Server 5.0 fix pack 1 and eFixes.

b. Copy the contents of the \fixes directory to a temporary directory on your hard drive (for
example, C:\WASFixes).
c. Using a command prompt, go to the temporary directory you created.
d. Set the JAVA_HOME environment variable to the path to runtimes\base_v5\java under
WebSphere Studio installation directory, as shown in Figure A-19.
Note: For example the variable can be set to the following:

JAVA_HOME=C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\java
Figure A-19 Setting JAVA_HOME environment variable
e. Run updateWizard.bat from the same command prompt, as shown in Figure A-20 on
page 81.

Figure A-20 WAS Interim fixes Update Installation Wizard
f. Click Next to continue to the screen in Figure A-21.
Figure A-21 WAS Interim fixes Product Info and Installation Directory selection
g. Make the following selections as you follow the installation prompts.

i. Make sure Specify product information is checked. Enter \runtimes\base_v5 in
the Installation directory field. This will specify the directory where WebSphere
Studio is installed.
h. Click Next to continue. Select the Install fixes radio button in the next screen and click
Next to display the screen in Figure A-22.
Figure A-22 WAS interim fixes source directory
Enter the directory where you copied the WebSphere Application Server interim fixes (for
example, C:\WASFixes) into the File directory field. Click Next.
Select the following interim fixes on the screen that is displayed:
– PQ73644.jar
– PQ76567.jar
– WAS_Dynacache_05-08-2003_5.0.1_cumulative_fix.jar
– WAS_CM_08_12_2003_5.0.1_cumulative_fix.jar
Click Next to display screen in Figure A-23 on page 83, which displays the list of selected
fixes.

Figure A-23 WAS Interim fixes selected files list
Click Next to install the selected fixes, as shown in Figure A-24.
Figure A-24 WAS Interim fixes installation done

You can run the wizard again if you want to install any more latest fixes, or you can click
Finish to exit the wizard.
Portal Toolkit
If you have a version of Portal Toolkit prior to V5.0, you should remove it before installing
Portal Toolkit V5.0. Also, make sure WebSphere Studio is installed but not running before
installing Portal Toolkit.
Note: For the local debug configuration, you will also need to have the CD labelled Portal
Server available.
Complete the following steps:

Stop the HTTP server if it has been started.
Hold down the Shift key to bypass the automatic starting of installation.
Insert the WebSphere Portal Setup CD while depressing the Shift key.
Release the Shift key after the CD has been inserted.
Run D:\PortalTookit\install.bat (where D: is the CD-drive).
Select the language and click OK to display the screen in Figure A-25.
Figure A-25 Portal Toolkit: Welcome Panel
Click Next on the welcome panel to display the screen in Figure A-26 on page 85.

Figure A-26 Portal Toolkit: license agreement
Read and accept the license agreement. Then, click Next to display the screen in
Figure A-27.
Figure A-27 Portal Toolkit: installation folder
Make sure that the folder displayed is the installation folder of WebSphere Studio and click
Next to display the screen in Figure A-28 on page 86.

Select the WebSphere Portal for Test Environment you want to use for debug on the next
screen.
Note: If you plan to debug only with the remote server, you do not have to install
WebSphere Portal for Test Environment.
Figure A-28 Portal Toolkit: test environment
Select WebSphere Portal V5.0 for Test Environment and click Next to continue to the
screen displayed in Figure A-29 on page 87.
Note: We use only WebSphere Portal V5.0 for Test Environment to implement the secure
portal.

Figure A-29 Portal Toolkit: install location
Click Next to continue. You will be prompted to enter the CD WebSphere Portal V5.0 for Test
Environment, as shown in Figure A-30.
Figure A-30 Portal Toolkit: prompt for Portal V5.0
Insert the CD of WebSphere Portal V5.0 into the CD drive and Click Next. The installation
starts, as shown in Figure A-31 on page 88.

Figure A-31 Portal Toolkit: WPS installer
When the installation is complete, perform the following steps:

Reboot the machine.
Open WebSphere Studio after the machine is restarted to allow the occurrence of auto
updates.
When you are prompted to open Update Manager, click Yes. The pending configuration
changes are displayed by a date and time stamp.
Select the date and time for the Portal Toolkit installation. If you expand the selection, you
will see a list of all of the pending configuration changes, as shown in Figure A-32 on
page 89.

Figure A-32 Updating pending configuration changes
Click Finish.
When the update is complete, you are prompted to restart WebSphere Studio. You only need
to restart the WebSphere Studio, not the machine. You are ready to start work in the portlet
development environment after you restart WebSphere Studio.
Importing the sample source into WSSD

The following are the steps needed to import the sample application source into the
development environment (WebSphere Studio Site Developer 5.0.1with Portal Toolkit 5.0).
Importing the application source allows you to review the source files that form the application
and do any modifications you wish if you want to experiment with it later.
Perform the following steps:

1. Create a new project in WebSphere Studio by selecting File->New->Portlet Application
Project and following the instructions provided by the project creation wizard.
2. Import the war files into this project by selecting File->Import->WAR file and browsing to
the folder where you have downloaded and unzipped the war and ear files that form the
sample application. Do not forget to use the existing Web project that you have created in
the previous step when you imported the war files into WebSphere Studio.
3. Create a new enterprise application project to import the ear files (of the back-end
application) and import the source from the ear files into the project. This step is similar to
the first two steps.

Note: Go to WebSphere Studio help for detailed information about creating a project in
WebSphere Studio and importing war files into it.
Packaging the application for deployment

Use the following steps to package the application for deployment if you are going to perform
any modifications in the source code after testing it as it is or anytime.
1. Export the portlet application into a WAR file using the File->Export->WAR file menu path
in WebSphere Studio, as shown in Figure A-33.
Figure A-33 Creating a war file in WSSD
2. Export the enterprise application into an EAR file by selecting the File->Export->EAR file
menu path in WebSphere Studio.
3. These WAR and EAR files are now ready to be deployed on the Portal Server and on the
back-end WebSphere Application server, respectively.
Note: Refer to Chapter 4, “Implementing the runtime environment” on page 29 of SSO for
information about deploying portlets on Portal Server and for deploying the back-end
application on WAS server.

Note: Refer to the Developers guide of WebSphere Portal infocenter at the following URL
for information about (1) creating the war files manually and (2) the war file structure:

B
Appendix B. Additional material

This Redpaper refers to additional material that can be downloaded from the Internet as
described below.
Locating the Web material

The Web material associated with this Redpaper is available in softcopy on the Internet from
the IBM Redbooks Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/REDP3743
Alternatively, you can go to the IBM Redbooks Web site at:

http://ibm.com/redbook
Select the Additional materials link and open the directory that corresponds with the
Redpaper form number, REDP3743
Using the Web material

The additional Web material that accompanies this Redpaper includes the following files:
File name Description
ITSO_SSO_Samples.ZIP Zipped Code Samples
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web
material zip file into this folder.

Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this Redpaper.
IBM Redbooks
For information about ordering these publications, see “How to get IBM Redbooks” on
page 96. Note that some of the documents referenced here may be available in softcopy only.
A Secure Portal Using WebSphere Portal V5 and Tivoli Access Manager V4.1,
SG24-6077
Access Integration Pattern Using IBM WebSphere Portal Server, SG24-6267
Web Services Wizardry with WebSphere Studio Application Developer, SG24-6292
WebSphere Version 5.1 Application Developer 5.1.1 Web Services Handbook,
SG24-6891
IBM Websphere Portal V5, A Guide for Portlet Application Development, SG24-6076
Portal Application Design and Development Guidelines, REDP-3829
A Portal Composite Pattern Using WebSphere Portal V5, SG24-6087
IBM WebSphere V5.0 Security, SG24-6573
Online resources
These Web sites and URLs are also relevant as further information sources:
WebSphere Portal InfoCenter
Rational website
http://www.rational.com/uml/index.jsp
Portlet Coding Guidelines
http://www7b.software.ibm.com/wsdd/zones/portal/portlet/portletcodingguidelines.html
Understanding the Portlet Component Model
http://www7b.boulder.ibm.com/wsdd/library/techarticles/0309_fischer/fischer.html
InfoCenter link (choose left-hand frame option Information Development
http://pvcid.raleigh.ibm.com/
Using Active Credentials Objects to Connect to Secured Web Applications
Using Credential Vault to Provide Single Sign-on for Portlets
WebSphere Application Server installation guide
WebSphere Application Server InfoCenter

http://www-3.ibm.com/software/awdtools/studiositedev/
IBM WebSphere Studio Application Developer 5.0.1 PTF
http://www3.software.ibm.com/ibmdl/pub/software/websphere/studiotools/html/501/wsad/inst
all.html
IBM WebSphere Studio Application Developer Integration Edition PTF 001 - General
Fixes
http://www3.software.ibm.com/ibmdl/pub/software/websphere/studiotools/html/501/wsadie/in
structions/install.htm
IBM WebSphere Studio Enterprise Developer v5.0.1 Fix Pack
http://www-1.ibm.com/support/docview.wss?uid=swg24004902
How to get IBM Redbooks

You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft
publications and Additional materials, as well as order hardcopy Redbooks or CD-ROMs, at
this Web site:
http://ibm.com/redbooks
Help from IBM

IBM Support and downloads
http://ibm.com/support
IBM Global Services

http://ibm.com/services

Index
A D
deployment 90
access control 11
design 5, 17, 24
access management 11
development environment 66, 89
active credential object 4, 17–18, 28, 60
dialog component 14
actors 6
different vendor application servers 20
administrative slot 4, 18
Domino 2
application design 14, 19
double-realm single sign on 2
application node 13
Application pattern 19
application server 13 E
authenticate 2, 6 enterprise archive packaged files (EAR) 36
authentication 26, 60 existing application 24
authentication credential 26 Extended Single Sign-On Application pattern 12
authentication proxy 12, 19–20 Extended Single Sign-On pattern 2, 21
authorization 6, 11–12, 24 Extended Single Sign-On Runtime patterns 21
authorization/access control mechanisms 11 external applications 2
external security manager 26
extranet portal application 19
B
back-end applications 2, 4–5, 21, 23, 26–27, 31, 60
back-end business applications 30 F
back-end credentials 2 firewall 13
back-end systems 19 form-based login 24
business applications 12–13 framework 6
business node 13, 33 functional requirements 5–6
functional view diagram 12
C
Central Authorization Service pattern 21, 23 G
centralized security 10–11 global security 36
component interaction diagram 15 Global Services method 15
component model 14
component relationship diagram 14
components 14 H
creating a vault segment 48 heterogeneous application servers 20
Credential homogeneous application server 19
mapping 22 HTTP server 31
transformation 22 HttpBasicAuthCredential active credential object 11, 60
credential mapping 22, 58
credential object types 18
credential objects 4
I
infrastructure 31
credential propagation 21
Credential Propagation pattern 21
credential repository 4 J
credential retrieval model 15 Java servlet architecture 17
credential secrets 27
credential transformation 21–22
credential vault 3–4, 13, 18, 27, 47 K
credential vault implementation 27 Kerberos technology 26
credential vault organization 3, 27
credential vault portletservice 27 L
credential vault portletservices 18 Lightweight Third Party Authentication (LTPA) 2, 26
credential vault service 2, 14 Lotus Domino Application Server 26
credentials 2–3, 18, 27 Lotus Instant Messaging (Sametime) 10
custom repository 3, 27 LTPA authentication 26

LTPA token 26 shared slot 4
single sign-on 5, 10, 20, 25
single sign-on application 17
M Single Sign-On Application pattern 3
multiple identities 11 single sign-on credential mapping 13, 17, 59
mutually suthenticated SSL 43 single sign-on credentials 11
MVC (Model, view, controller) design pattern 17 single sign-on domain 2
single sign-on guidelines 19
N Siteminder 19
Netegrity SiteMinder 26 SiteMinder token 26
non-functional requirements 5, 10 slot type 18
solution design 5, 11
solution micro design 15
O stored credentials 27, 60
operational view 5, 13 subsystems 5
system slot 4, 18
P
passive credential object 4, 17–18, 27, 45, 60 T
policy/authorization server 12 technology options 25
portal credential vault 26 Tivoli Access Manager 3, 26
portal database 27 Tivoli Access Manager lock box 27
portal realm 3 transform user credentials 20
Portal Server 12, 14
portal service 3
Portal Toolkit V5.0 66, 84 U
portlet API 27 UML sequence diagram 15
portlet application 11, 14 use case diagram 6
portlet credential application 14 use cases 5–6, 59
portlet development 17 user credentials 4, 10, 47
Primary actor 7 user slot 18
private slot 4, 18 user/actor 6
UserPasswordPassive passive credential object 11
R
repository 27 V
requirements 5, 27 vault adapter 4, 13, 27, 40
requirements analysis 6 vault resource 51
role-based authorization 23 vault segment 4, 10, 47
runtime architecture 29 vault slot 4, 10, 18, 47
Runtime patterns 3, 12, 19
W
S Web applications 17, 19
scalability requirements 10 Web service 62
seamless access 2, 19 Web single sign-on 2, 19
secondary actor 7 Web Single Sign-On Application pattern 2
secret 19 Web Single Sign-On Runtime patterns 19
secure portal 10, 12 Web tier 19
security 6, 27, 31 Web user 12
security domain 19, 24, 26 Webseal 19
security management system 19 WebSeal token 26
security model 24 WebSphere Application Server 2, 26, 30
security node 13 WebSphere global security 31
security realm 26 WebSphere Portal 2–4, 25–27, 67
security requirements 11 WebSphere Portal architecture 17
security server 20 WebSphere Portal credential services 25
security service 23 WebSphere security 13, 33
security services component 14 WebSphere Studio 66
segment type 18 WebSphere Studio Site Developer 68
sequence diagram 16 WebSphere Test Environment 66

Back cover ®
A Secure Portal Extended

With Single Sign-On
Redpaper
WebSphere Portal V5 Many portals are required to access external applications that
need some form of user authentication. In most cases, the user
INTERNATIONAL
and Tivoli Access
credentials required by these applications will differ from those TECHNICAL
Manager V4.1
used by WebSphere Portal. While it is possible for the portlet to SUPPORT
integration
Design guidelines and prompt the user for this credential information and then present ORGANIZATION
technology options it to the external application, such an approach is seldom
implemented due to the unsatisfactory user experience.
Step-by-step guide
Therefore, a single sign-on (SSO) is required to provide seamless
access to the different applications in a portal solution.
BUILDING TECHNICAL
INFORMATION BASED ON
Implementing a secure portal using an external security
PRACTICAL EXPERIENCE
manager is part of solving this problem. This provides a
centralized access management system. It is also a basis for IBM Redbooks are developed
creating an SSO domain for multiple applications that can share by the IBM International
common user credentials. However, back-end applications can Technical Support
still exist outside of this domain because of a need for specific Organization. Experts from
custom user IDs and passwords. For these, we can use IBM, Customers and Partners
from around the world create
credential mapping to map the common credential to the timely technical information
back-end one. This is implemented as Credential Service in based on realistic scenarios.
WebSphere Portal. Specific recommendations
are provided to help you
This publication is intended to help IT architects, IT specialists, implement IT solutions more
security architects, and security administrators with effectively in your
understanding and implementing a secure portal with SSO. This environment.
publication is built on and extends A Secure Portal Using
WebSphere Portal V5 and Tivoli Access Manager V4.1,
SG24-6077.
For more information:
ibm.com/redbooks

A Secure Portal Extended With Single Sign-On

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A Secure Portal Extended With Single Sign-On

Hochgeladen von

Copyright:

Verfügbare Formate

Front cover

Design guidelines and

Secure Portal with Single Sign-On

First Edition (February 2004)

This document created or updated on February 20, 2004.

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

Chapter 2. Requirements and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 3. Technology options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 4. Implementing the runtime environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

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

Chapter 5. Sample applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Appendix A. Implementing the development environment . . . . . . . . . . . . . . . . . . . . . . 65

Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

iv Secure Portal with Single Sign-On

© Copyright IBM Corp. 2004. All rights reserved. v

The following terms are trademarks of other companies:

vi Secure Portal with Single Sign-On

This publication is intended to help IT architects, IT specialists, security architects, and

This Redpaper will cover the following topics:

The team that wrote this Redpaper

Michele Galic is an IT Specialist at the International Technical Support Organization, Raleigh

© Copyright IBM Corp. 2004. All rights reserved. vii

Figure 0-1 A Secure portal residency team

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

viii Secure Portal with Single Sign-On

Become a published author

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

Application node Application node containing

Figure 1-1 Access Integration::Web Single Sign-on pattern

2 Secure Portal with Single Sign-On

Figure 1-2 Access Integration::Extended Single Sign-On pattern

1.2 Credential vault

1.2.1 Credential vault organization

User-managed Segment (U)

Other Vault Implementation

Figure 1-3 Credential vault organization

4 Secure Portal with Single Sign-On

Chapter 2. Requirements and Design

We will also look at various SSO design guidelines.

© Copyright IBM Corp. 2004. All rights reserved. 5

2.1.1 Functional requirements

Use case diagram

6 Secure Portal with Single Sign-On

UC-01:Access the external system

UC-01-b:Pass the credentials to the

Figure 2-1 SSO use case diagram

Use cases list

The list of primary actor(s) in the current process follows:

The list of secondary actor(s) in the current process follows:

Business use cases are summarized in Table 2-1.

Table 2-1 Business use cases

UC-01 Access the external Actor needs to access Client

Chapter 2. Requirements and Design 7

UC-01-a Retrieve user Actor retrieves the System (portlet)

UC-01-b Pass the user Actor passes the System (portlet)

Administration use cases are summarized in Table 2-2.

Table 2-2 Administration use cases

UC-ADM-01 Create/manage vault Create/manage a vault Site administrator

UC-ADM-02 Create/manage vault Create/manage a vault Site administrator

UC-ADM-02-a Create user Create user Site administrator

Use case details

Business use cases

Description Primary use case for an actor to access the

Preconditions Actor logged in the secure portal