Redpaper. A Secure Portal Extended With Single Sign-On. Front cover. ibm.com/redbooks. WebSphere Portal V5 and Tivoli Access Manager V4.

Transcription

1 Front cover A Secure Portal Extended With Single 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

2

3 International Technical Support Organization Secure Portal with Single Sign-On February 2004

4 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, Copyright International Business Machines Corporation All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 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 Single sign-on Credential vault Credential vault organization Summary Chapter 2. Requirements and Design Requirements analysis Functional requirements Non-functional requirements Solution design Functional view Operational view Application design Design guidelines Portlet development Using the credential vault portletservices SSO guidelines Extended SSO Runtime patterns Chapter 3. Technology options Introduction Approaches to achieve SSO Extending the security realm Credential vault PortletService Vault Implementation Vault organization Types of credential objects Summary Chapter 4. Implementing the runtime environment Planning Setting up the back-end business applications Installing a WebSphere Application Server Setting up security Deploying the back-end sample applications Verifying the back-end sample applications Installing and configuring TAM credential vault adapter Using portal default and TAM credential vaults Logging into the portal Installing sample portlets Copyright IBM Corp All rights reserved. iii

6 4.4.3 Create/Manage vault segments, slots, and user credentials Creating a page and deploying the portlets Summary Chapter 5. Sample applications The sample portlets Running the basic authentication portlet Incorrect slot credentials Running the Web service authentication portlet Incorrect slot credentials Summary Appendix A. Implementing the development environment Development environment overview WebSphere Studio Portal Toolkit Development environment configurations Local debug Remote server attach WebSphere Studio Site Developer Installation steps Portal Toolkit Importing the sample source into WSSD Packaging the application for deployment Appendix B. Additional material Locating the Web material Using the Web material How to use the Web material Related publications IBM Redbooks Online resources How to get IBM Redbooks Help from IBM Index iv Secure Portal with Single Sign-On

7 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 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 All rights reserved. v

8 Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Eserver Eserver Redbooks (logo) Eserver ibm.com Domino DB2 IBM Lotus MQSeries Redbooks Sametime Tivoli Enterprise Tivoli 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

9 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, SG 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 All rights reserved. vii

10 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

11 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: 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: 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 Research Triangle Park, NC Preface ix

12 x Secure Portal with Single Sign-On

13 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, SG The ideas presented there will help you to understand the concepts covered in this IBM Redpaper. Copyright IBM Corp All rights reserved. 1

14 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, SG 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. Client Tier synchronous Single Sign-On Tier synchronous Application2 Application1 Read / Write data Application node containing new or modified components Application node containing existing components with 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

15 Client Tier Single Sign-On Application 1 Security Integration Enterprise 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 Credential vault organization Figure 1-3 gives an overview of the credential vault organization. The elements are then discussed further in this section. Vault Service Vault Implementations WebSphere Portal Vault User-managed Segment (U) Slot Ua Slot Ub Slot Uc Administrator-managed Segment (A1) Slot A1a Slot A1b Slot A1c Administrator-managed Segment (A2) Slot A2a Slot A2b Slot A2c Other Vault Implementation Figure 1-3 Credential vault organization Chapter 1. Introduction 3

16 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. 4 Secure Portal with Single Sign-On

17 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. Copyright IBM Corp All rights reserved. 5

18 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, SG 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: 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: 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. 6 Secure Portal with Single Sign-On

19 <<include>> UC-01-a:Retrieve user credentials from the vault slot Customer UC-01:Access the external system (back-end) through portal (front-end) <<include>> System/Portlet UC-01-b:Pass the credentials to the external system (back-end) UC-ADM-01:Create/Manage Vault Segment <<include>> UC-ADM-02-a:Create/ Modify User Credentials Site Administrator UC-ADM-02:Create/Manage 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 system (back end) through portal (front end) Actor needs to access the external system (back end) through the portal (front end). Client Chapter 2. Requirements and Design 7

20 Use case ID Use case name Goal in context Actor (Primary or Secondary) UC-01-a Retrieve user credentials from the vault slot Actor retrieves the credentials from the vault slot System (portlet) UC-01-b Pass the user credentials to the external system (back end) Actor passes the retrieved credentials to the back end system System (portlet) 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 segment Create/manage a vault segment using credential vault portlet. Site administrator UC-ADM-02 Create/manage vault slot Create/manage a vault slot using credential vault portlet. Site administrator UC-ADM-02-a Create user credentials Create user credentials in the vault implementation (user ID and password information) Site administrator 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 Description Preconditions Primary actor Secondary actor UC01: Access the external system (back end) through portal (front end) Primary use case for an actor to access the external system (back end) through the portal (front end) Actor logged in the secure portal Client System/portlet 8 Secure Portal with Single Sign-On

21 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 Description Preconditions Primary actor Secondary actor Main scenario UC01: Create/manage vault segment Primary use case for an actor to create/manage credential vault segment Actor logged in with administrator rights Site administrator None 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. The use case ends successfully. Alternatives Related information Data 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 Description UC02: Create/manage vault slot UC02-a: Create/modify user credentials Primary use case for an actor to create/manage credential vault slot. Included use case for an actor to create/modify user credentials. Chapter 2. Requirements and Design 9

22 Preconditions Primary actor Secondary actor Main scenario Actor logged in with administrator rights. Site administrator None 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. The use case ends successfully. Alternatives Related information Data 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 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. 10 Secure Portal with Single Sign-On

23 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 Chapter 2. Requirements and Design 11

24 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, SG for more information. Refer to WebSphere Version 5.1 Application Developer Web Services Handbook, SG 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 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, SG 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 Browser Https request Authentication Session Authentication Proxy Mutual SSL Web Server WAS Plug-in Mutual SSL Application Server Trust Association Interceptor Portal Server Credential Mapping Application Server Trust Association Interceptor Portal Server LDAP over SSL LDAP over SSL Directory Server User Registry LDAP over SSL User Repository Policy/ Authorization Server Policy Store Key Subsystem Component Synchronous Connection Read/Write Datastore Tier Credential Vault JAAS API Vault Adapter 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 12 Secure Portal with Single Sign-On

25 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 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 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, SG 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 Administrator 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, SG Please note that the security and application nodes could also be behind the firewall, assuming that the firewall is configured correctly. Chapter 2. Requirements and Design 13

26 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 Services <<component>> Dialog <<component>> Portal Server <<component>> Credential Vault Services <<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. 14 Secure Portal with Single Sign-On

27 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 : Customer request : Dialog : Security Services checkauthentication : Portal Server : Port let : PortletCredentialManager : Credential : Business Vault Services Services 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. Chapter 2. Requirements and Design 15

28 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 : BasicAuthPortletViewBean : 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. 16 Secure Portal with Single Sign-On

29 : System doview() : WsAuthPortlet getcredentialsecret() : WsPortletSecretManager getcredential() : CredentialVaultService : UserPasswordPassiveCredential : WsAuthPortletViewBean : WsAuthPortletView.jsp : StockDataProxy 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 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, SG Portal Application Design and Development Guidelines, REDP-3829 Chapter 2. Requirements and Design 17