Sun Microsystems Sun Java System 2005Q1 Portal Server 6, Portal Server 6 2005Q1 Planning Manual

Download

Sun Java™ System

Portal Server 6

Deployment Planning Guide

2005Q1

Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A.

Part No: 817-7697

Copyright © 2005 S u n Mi c r osys tems, Inc., 4150 Network Circle, Santa Clara, Californi a 95054, U.S.A. All ri g hts r e se r ve d. Sun Microsystems, Inc. has intellec tual property rights relating to technology embodied i n th e p roduct tha t is described in this document. In

particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed at

http://www.sun.com/patents

and one or more additional patents or pending patent applications in the U.S. and in other countries.

THIS PRODUCT CONTAINS CONFIDENTIAL INFORMATION AND TRADE SECRETS OF SUN MICROSYSTEMS, INC. USE, DISCLOSURE OR REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF SUN MICROSYSTEMS, INC.

U.S. Government Rights - Commercial software. Government users are subject to the Sun Microsystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements.

This distribution may include materia ls d eve lo ped by third parties. Parts of the product may be derived from Berkeley BSD syst ems, licensed fro m the University of Cal ifornia. UNIX is a registered t radem ark in the

U.S. and in other c ountries, exclusiv el y licensed through X/Op en Com p any, Ltd. Sun, Sun Microsystems, the Sun logo, Java, Solaris, JDK, Java Naming and Directory Interface, JavaMail, JavaHelp, J2SE, iPlanet, the Duke logo,

the Java Coffee Cup logo, the Solaris logo, the SunTone Certified logo and the Sun ONE logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

All SPARC tradem ar k s ar e u se d under license and are trademarks or r e g istered trademark s of SPARC Internat io nal, Inc. in the U. S. a nd othe r countries. Products bearing SPARC trademarks are based upo n ar chit ect ure develop ed by Sun Microsys te ms, Inc.

Legato and the Legato logo are registered trademarks, and Legato NetWorker, are trademarks or registered trademarks of Legato Systems, Inc . The Netscape Communications Corp logo is a trademark or registered trademark of Netscape Communications Corporation.

The OPEN LOOK and Sun(TM) Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusi ve license from Xerox to the Xe rox Gr aphical User Interface, which license also covers Sun 's l ice nse es who implemen t OPEN LOOK GUIs and otherwise comply with Sun's written license agreements.

Products covered by and information contained in this service manual are controlled by U.S. Export Control laws and may be subject to the export or import laws in other countries. Nuclear, missile, chemical biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited. Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited t o, th e de nie d persons a nd spe c ial ly d es igna te d na ti onals lists is strictly prohibited.

DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTI CULAR PURPOSE O R NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.

_______________________________________________________________________________________________________________ Copyright © 2005 S un Microsystems, Inc. , 4150 Network Circle, S anta Clara, Calif or nia 95054, Etats-Unis. Tous droits rése r vé s. Sun Microsystems, Inc. détient les droits de propriété intellectuels relatifs à la technologie incorporée dans le produit qui est décrit dans ce

document. En particulier, et ce sans limitation, ces droits de propriété intellectuelle peuvent inclure un ou plus des brevets américains listés à l'adresse

http://www.sun.com/patents

et un ou les brevets supplémentaires ou les applications de brevet en attente aux Etats - Unis et dans les

autres pays. CE PRODUIT CONT IENT DES INFORMATI ON S CONFIDENTIELLES ET DES SECRETS CO M ME R CIAUX DE SUN MICROSY S TEM S , INC.

SON UTILISATION, SA DIVULGATION ET SA REPRODUCTION SONT INTERDITES SANS L AUTORISATION EXPRESSE, ECRITE ET PREALABLE DE SUN MICROSYSTEMS, INC.

Cette distribution peut comprendre des composants développés par des tierces parties. Des parties de ce produit pourront être dérivées des systèmes Berkeley BSD licenciés par l'Université de Californie. UNIX est une marque

déposée aux Etats-Unis et dans d'autres pays et licenciée exclusivement par X/Open Company, Ltd. Sun, Sun Microsystems, le logo Sun, Java, Solaris, JDK, Java Naming and Directory Interface, JavaMail, JavaHelp, J2SE, iPlanet, le logo Duke, le

logo Java Coffee Cup, le logo Solaris, le logo SunTone Certified et le logo Sun[tm] ONE sont des marques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d'autres pays.

Toutes les marques SPARC sont utilisées sous licence et sont d es marques de fabrique ou des marques déposées de SPARC International, Inc. aux Etats-Unis et dans d'autre s pays. Les pro duits portan t les marques SPARC sont basé s sur une architecture dé veloppé e par Sun Micro systems, Inc.

Legato, le logo Legato, et Legato NetWorker sont des marques de fabrique ou des marques déposées de Legato Systems, Inc. Le logo Netscape Communications Corp est une marque de fabrique ou une marque déposée de Netscape Communications Corporation.

L'interface d'utilisation graphique OPEN LOOK et Sun(TM) a été développée par Sun Microsystems, Inc. pour ses utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour la recherche et le développement du concept des interfaces d'utilisation visuelle ou graphi q ue pour l'industrie de l'informatique. Sun détient une license non exclusive de Xerox sur l'interface d'utilisation graphique Xerox, cette licence couvrant également les licenciés de Sun qui mettent en place l'interface d'utilisation graphique OPEN LOOK et qui, en outre, se conforment aux licences écrites de Sun.

Les produits qui font l'objet de ce manuel d'entretien et les informations qu'il cont ie nt sont regis par la legi sla t io n americaine en matiere de controle des exportations et peuvent etre soumis au droit d'autres pays dans le domaine des exportations et importations. Les utilisations finales, ou utilisateur s f inaux, pour des arme s nuc leaires, des mis s iles, des armes biolo g iq u e s et chimiques ou du nuc le aire maritime, directement ou indirectement, sont strictement interdites. Les exportations ou reexportations vers des pays sous embargo des Etats-Unis, ou vers des entites figurant sur le s listes d'exclusion d 'e xportation americai ne s, y c omp r is, mais de maniere non exclusive, la li ste de personnes qui f ont objet d' u n ordre de ne pas participer, d'une facon directe ou indirecte, aux exportations des produits ou des services qui sont regi par la legislation americaine en matiere de controle des exportatio ns e t l a l ist e de ressorti ssants specifiquement designes, sont rigoureusement interdites.

LA DOCUMENTATION EST FOURNIE "EN L'ETAT" ET TOUTES AUTRES CO NDI TI ONS, DECLARAT IONS ET GARANTIES E XPRESS ES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A L'APTITUDE A UNE UTI LIS ATI ON PARTICULIE RE OU A L'ABSENCE DE CONTREFACON.

Contents

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Before You Read This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Who Should Read This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

How This Book Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Typographic Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Books in This Documentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Other Portal Server Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Other Server Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Accessing Sun Resources Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Contacting Sun Technical Supp ort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Related Third-Party Web Site Referenc es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Sun Welcomes Your Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 1 Portal Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

What is a Portal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Types of Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Collaborative Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Business Intelligence Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Portal Server Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Sun Java System Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Secure Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Portal Sever in Open Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Portal Server in Secure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Security, Encryption, and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Portal Server Deployment Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Portal Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Identity Man ag e m ent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Portal Server Soft ware Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Software Packa ging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Software Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Compatibility With Java Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A Typical Portal Server Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Chapter 2 Portal Server Secure Remote Access Architecture . . . . . . . . . . . . . . . . . . . . . . . . 37

SRA Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Multiple Gateway Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Multiple Portal Server Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Proxy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Gateway and HTTP Basic Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Gateway and SSL Suppor t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Gateway Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Gateway Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Using Accelerat or s with the Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Netlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Static and Dynamic Port Applicat ions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Netlet and Application Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Split Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Netlet Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

NetFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Validating Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Special Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

NetFile and Multithreadi ng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Rewriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Rewriter Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Proxylet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 3 Identifying and Evaluating Your Business and Technical Requirements . . . . . . 51

Business Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Technical Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Mapping Portal Server Features to Your Business Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

SRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Search Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4 Portal Server 6 2005Q1 • Deployment Planning Guide

Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Aggregation and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Understanding User Behaviors and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 4 Pre-Deployment Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Determine Your Tuning Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Portal Sizing Tip s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Establish Performance Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Portal Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Establish Baselin e Sizi ng Fig ur es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Customize the Baseline Sizing Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Validate Baseline Sizing Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Refine Baseline Si zing Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Validate Your Final Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

SRA Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Identifying Gateway Key Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Advanced Gateway Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

SRA Gateway and SSL Hardware Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

SRA and Sun Enterprise Midframe Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Chapter 5 Creating Your Portal Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Portal Design Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Overview of High-Level Portal Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Overview of Low-Level Portal Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Logical Portal Architec tu re . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Portal Server and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Vertical Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Horizontal Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Portal Server and High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

System Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Degrees of High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Achieving High Availability for Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Portal Server System Communication Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Working with Portal Server Building Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Building Modules and High Availability Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Building Module Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Deploying Your Building Module Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Designing Portal Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Elements of Portal Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Example Use Case: Authenticate Portal User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Designing Portal Security Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Securing the Operating Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Contents 5

Using Platform Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Using a Demilitarized Zone (DMZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Portal Server and Access Manager on Different Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Designing SRA Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Basic SRA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Disable Netlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Proxylet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Multiple Gateway Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Netlet and Rewriter Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Netlet and Rewriter Proxies on Separate Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Using Two Gateways and Netlet Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Using an Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Netlet with 3rd Party Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Reverse Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Designing for Localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Content and Design Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Integration Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Identity and Directory Structure Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Implementing Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Portal Desktop Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Client Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Chapter 6 The Production Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Moving to a Production Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Monitoring and Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Documenting the Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Monitoring Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Memory Consumption and Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

CPU Utili za tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Access Manager Cache and Sessio ns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Thread Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Portal Usage Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Appendix A Installed Product Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Directories Installed for Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Directories Installed for SRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Appendix B Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

mpstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

iostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

6 Portal Server 6 2005Q1 • Deployment Planning Guide

Tuning Parameters for

/etc/system

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Appendix C Portal Server and Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Introduction to Application Server Support in Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Portal Server on an Application Server Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Overview of Application Server Enterprise Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Overview of BEA WebLogic Server Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Overview of IBM WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Appendix D Troubleshooting Your Portal Deployme nt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Troubleshooting Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

UNIX Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Recovering the Search Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Working with the Display Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

High CPU Utilization for Portal Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Configuring a Sun Java System Portal Server Instance to Use an HTTP Proxy . . . . . . . . . . . . . . . 162

Troubleshooting SRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Debugging the Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Introduction to Using

shooter

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

SRA Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Appendix E Portal Deployment Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Portal Assessment Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Portal De sign Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Appendix F Portal Server on the Linux Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Limitations Using Linu x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Comparison of Solaris and Linux Path Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Contents 7

8 Portal Server 6 2005Q1 • Deployment Planning Guide

List of Figures

Figure 1-1 Portal Server in Open Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 1-2 Portal Server in Secure Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 1-3 High-level Architecture for a Bus ines s-t o-Em p loye e Portal . . . . . . . . . . . . . . . . . . . . . . 34

Figure 1-4 SRA Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figure 5-1 Portal Server Communication Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Figure 5-2 Portal Server Building Module Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Figure 5-3 Best Ef fort Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Figure 5-4 No Singl e Point of Failure Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figure 5-5 Transparent Failover Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Figure 5-6 Portal Server and Access Manager on Different Nodes . . . . . . . . . . . . . . . . . . . . . . . . 106

Figure 5-7 Two Portal Servers and One Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Figure 5-8 One Portal Server and Two Access Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Figure 5-9 Two Portal Servers and Two Access Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Figure 5-10 Basic SRA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figure 5-11 Disable Netlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Figure 5-12 Proxylet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Figure 5-13 Multiple Gateway Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Figure 5-14 Netlet and Rewriter Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Figure 5-15 Proxies on Separate Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Figure 5-16 Two Gateways and Netlet Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Figure 5-17 SRA Gateway with External Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Figure 5-18 Netlet and Third-Party Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Figure 5-19 Using a Reverse Proxy in Front of the Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

List of Fi gures 9

10 Portal Server 6 2005Q1 • Deployment Planning Guide

List of Tables

Table 1 Typographical Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Table 3-1 Identity Management Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Table 3-2 SRA Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Table 3-3 Search Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 3-4 Personalization Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Table 3-5 Aggregation Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Table 5-1 Portal Server H ig h Availability Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Table 5-2 Use Case: Authenticate Portal User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Table A-1 Portal Server Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Table A-2 Portal Server, SRA Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Table B-1 Performance Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Table B-2 /etc/system Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Table B-3 TCP/IP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Table E-1 General Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Table E-2 Organizational Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Table E-3 Business Service-level Expectations Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Table E-4 Content Management Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Table E-5 User Management and Security Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Table E-6 Business Intelligence Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Table E-7 Architecture Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Table E-8 Design Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Table F-1 Comparison of Solaris and Linux Path Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

List of Tables 11

12 Portal Server 6 2005Q1 • Deployment Planning Guide

This Administration Guide explains how to plan for and deploy Sun Java™ System Portal Server 6 2005Q1 software. Portal Server Secure Remote Access provides a platform to create portals for your organiza tion’s integrated data, knowledge management, and applications. The Portal Server platform offers a complete infrastructure solution for building and d e ploying all types of portals, including business-to-busine ss, business-to-employee, and business-t o-consumer.

Before You Read This Book

Preface

Portal Server Secure Remote Access is a component of Sun Java Enterprise System, a software infrastructure that supports enterprise applications distributed across a network or Internet environment. You should be familiar with the documentation provided with Sun Java Enterprise System, which can be accessed online at

http://docs.sun.com/coll/entsys_05q1

Who Should Read This Book

This Administration Guide is intended for use by th ose responsible for deploying Portal Server at your sit e.

Before you deploy Portal Server, you must be familiar with the following technologies:

• Sun Java Enterprise System

• Solaris™ Operating System administrative procedures

• Sun Java System Access Manager

• Sun Java System Directory Server

How This Book Is Organized

•Java™ Web Server

• JavaServer Pages™ technology

• Lightweight Directory Access Protocol (LDAP)

• Hypertext Markup Language (HTML)

• Extensible Markup Language (XML)

How This Book Is Organized

Chapters 1 through 5 provide information on Portal Server Secure Remote Access deployment. The following table summarizes the content of this book..

Chapter Description

Chapter 1, “Portal Server Architecture” on page 21

Chapter 2, “Portal Server Secure Remote Access Architecture” on page 37

Chapter 3, “Identifying and Evaluating Your Business and Technical Requirements” on page 51

Chapter 4, “Pre-Deployment Considerations” on page 61

Chapter 5, “Creating Your Portal Design” on page 79

Chapter 6, “The Production Environment” on page 133

Appendix A, “Installed Product Layout” on page 139

This chapter describes types of portals servers, Sun Java System Portal Server in open and secure mode, the Portal Server components.

This chapter describes the Portal Server Secure Remote Access architecture, including the key components of Secure Remote Access with respect to their role in providing secure remote access to corporate intranet resources from outside the intranet.

This chapter describes how to analyze your organization’s needs and requirements that lead to designing your portal deployment.

This chapter describes ho w to establish a baseline sizing figure for your portal. With a baseline figure established, you can then refine that figure to account for scalability, high availability, reliability, and good performance.

This chapter describes ho w to create your high-level and low-level portal design and provides information on creating specific sections of your design plan.

This chapter describes how to tune and monitor your portal.

This appendix describes the directories and configuration files for Portal Server and Remote Access (SRA).

Sun Java System Portal Server Secure

Appendix B, “Analysis Tools” on page 143

14 Portal Server Secure Remote Access 6 2005Q1 • Administration Guide

This appendix describes analysis tools for tuning the ope rating system.

Chapter Description

How This Book Is Organized

Appendix C, “Portal S erver and Application Servers” on page 153

Appendix D, “Troubleshooting Your Portal Deployment” on page 159

Appendix E, “Portal Deployment Worksheets ” on page 167

Appendix F, “Portal Se rver on the Linux Platform” on page 179

Glossary Glossary

This appendix describes the support for application servers.

This appendix describes how to troubleshoot the Portal Server software and the Portal Server S e cure Remote Access (SRA) product.

This appendix provides various worksheets to help in the deployment process.

This appendix contains notes on running Portal Server on a Linux platform.

Conventions Used in This Book

The tables in this section describe the conventions used in this book.

Typographic Conventions

The following table describes the typographic conventions used in this book

Table 1 Typographical Conventions.

Typeface Meaning Examples

AaBbCc123

(Monospace)

AaBbCc123

(Monospace bold)

API and language elements, HTML tags, web site URLs, command names, file names, directory path names, onscreen computer output, sample code.

What you type, when contrasted with onscreen computer output.

Edit your Use

.login

ls -a

file.

to list all files.

% You have mail % su

Password:

Preface 15

Directory

Server

Mail

Server

Legacy

Server

34 Portal Server 6 2005Q1 • Deployment Planning Guide

DMZ

Figure 1-4 shows a Portal Server deployment with SRA services. See Chapter 2, “Portal Server Secure Remote Access Architecture” for details.

Figure 1-4 SRA Deployment

A Typical Portal Server Installation

Portal

Server

Rewriter

Proxy

Client

Proxylet

Netlet

Gateway

Netlet

Proxy

Web

Server

Host

Application

Host

Application

Chapter 1 Portal Server Architecture 35

A Typical Portal Server Installation

36 Portal Server 6 2005Q1 • Deployment Planning Guide

Chapter 2

Portal Server Secure Remote Access

Architecture

This chapter describes the Sun Java™ System Portal Server Secure Remote Access (SRA) architecture.

You administer the configuration information through the Access Manager administration console.

This chapter describes the following SRA compon ents:

• SRA Gateway

• Netlet

• Netlet Proxy

• NetFile

• Rewriter

• Rewriter Proxy

• Proxylet

SRA Gateway

The SRA Gateway is a standalone Java process that can be considered to be stateless, since state information can be rebuilt transparently to the end user. The Gateway listens on configured ports to accept HTTP and HTTPS reques ts. Upon receiving a request, the Gateway checks session validity and header information to determine the type of request. Depending on the type of request, the Gateway performs the following:

SRA Gateway

• Netlet request. Routes the request (traffic) to the server specified in the Netlet rule that the user clicked in the Portal Desktop.

• HTTP(S) traffic. Routes the request to the server as specified by the HTTP header. Upon receiving a response from the server, the Gateway translates the response so that all intranet links wi thin the response work on the extranet.

All the Gateway configuration information is stored in the Access Manag e r’s LDAP database as a profile. A gateway profile consists of all the configuration information related to the Gateway except .

All machine-specific informati on, such as machine-specific information such as host name and IP address, is stored in a confi guration file in the local file system where the Gateway is installed. This enables one gateway profile to be shared between Gateways that are running on multiple machines.

As mentioned previously, you can configure the Gateway to run in both HTTP and HTTPS modes, simultaneously. This helps both intranet and extranet users to access the same Gateway: extranet users over HTTPS, and intranet users over HTTP (without the overhead of SSL).

You can also run the Gateway in Remote Access 6 Administration Guide for more information.

chroot environments. See the Portal Server Secure

Multiple Gateway Instances

If desired, you can run multiple Gateway in stances on a single machine—this is referred as a multihomed Gateway. Each Gateway instance listens on separate port(s). You can configure Gateway instances to contact the same Portal Server instance, or different Portal Server instances. When running multiple instances of a Gateway on the same machine, you can associate an independent certificate database with each instance of the Gateway, and bind that Gateway to a domain. In essence, this provides the flexibility of having a different Gateway server certificate for each domain.

Multiple Portal Server Instances

When you configure the Gateway with multiple instances of Portal Server, the Gateway automatically perfo r ms round-robin load balancing by logging in users with the different servers, a lte rnately. The Gateway also ke eps a list of active servers to avoid trying to login users to an inactive server. This mechanism helps to avoid single points of failure with Portal S e rver.

38 Portal Server 6 2005Q1 • Deployment Planning Guide

SRA Gateway

NOTE Session stickiness is not required in front of a Gateway (unless you

are using Netlet), however performance is impro ved with session stickiness. On the other hand, sessio n stickiness to the Portal Server instances is enforced by SR A.

Proxy Configuration

The Gateway uses proxies that are specified in its profile to retrieve contents from various web servers within the intranet and extranet. You can dedicate proxies for hosts and DNS subdomain s and domai ns . Depending on the proxy configuration, the Gateway uses the appropriate proxy to fetch the required contents. If the proxy requires authentication, the proxy name is stored as part of the gateway profile, that the Gateway uses automatically, when connecting to the proxy.

Gateway and HTTP Basic Authentic ation

The Gateway supports basic authentication, that is , prompting for a user ID and password but not protecting those credentials durin g transmission from the user’s computer to the site’s web server. Such protection usually requires the establishment of a secure HTTP connection, typically through the use of SSL.

If a web server requires basic authentication the client prompts for user name and password and sends the information back to the requesting server. With the Gateway enabled for HTTP basic authentication, it captures the user name and password information and stores a copy in the user’s profile in the Access Manager for subsequent authentications and login attempts. The original data is passed by the Gateway to the destination web server for basic authentication. The web server performs the validation of the user name and password.

The Gateway also enables fine control of denying and allo wing this capability on an individual host basis.

Gateway and SSL Support

The Gateway supports both SSL v2 and SSL v3 encryption while running in HTTPS mode. You can use the Access Manager administration console to en able or disable specific encryption. The Gateway also supports Transport Layer Security (TLS).

SSL v3 has two authentication modes:

Chapter 2 Portal Server Secure Remote Access Architecture 39

SRA Gateway

• Mandatory server authentication. The client must authenticate the server.

• Optional authentication. The server is configured to authenticate the client.

Personal Digital Certificate (PDC) authentication is a mechanism that authenticates a user through SSL client authentication. Th e Ga teway supports PDC authentication with the support of Access Manager authentication modules. With SSL client authentication, the SSL handshake ends at the Gateway. This PDC-based authentication is integrated along with the Access M anager’s certificate-based authentication. Thus, the client certificate is handled by Access Manager and not by the Gateway.

If the session information is not fou nd as part of the HTTP or HTTPS request, the Gateway directly takes the user to the authenticatio n pa ge by obtaining the login URL from Access Manager. Simi larly, if the Gateway finds that th e s es sion is not valid as part of a request, it takes the user to the login URL and at successful login, takes the user to the requested destination.

After the SSL session has been established, the Gateway cont inues to receive the incoming requests, checks session validity, and then forwards the request to the destination web server.

The Gateway server handles all Netlet traffic. If an incoming client request is Netlet traffic, the Gateway checks for session validity, decrypts the traffic, and forwards it to the application server. If Netlet Proxy is enabled, the Gateway checks for session validity and forwards it to Netlet Proxy. The Netlet Proxy then decrypts and forwards it to the application server.

NOTE Because 40-bit encryption is very insecure, the Gateway provides an

option that enables you to reject connections from a 40-bit encryption browser.

Gateway Access Control

The Gateway enforces access control by using Allo wed URLs and Denied URLs lists. Even when URL access is allowed, th e Gat e way checks the validly of the session against the Access Manager session server. URLs that are designated in the Non Authenticated URL list bypa ss session validation, as we ll as the Allowed and Denied lists. Entries in the Denied URLs list take precedence over entries in the Allowed URLs list. If a particular URL is n ot pa rt of any list, then access is denied to that URL. The wildcard character, either the Allow or Deny list.

, can also be used as a part of the URL in

40 Portal Server 6 2005Q1 • Deployment Planning Guide

Netlet

Gateway Logging

You can monitor the complet e u ser behavior by enabling logging on the Ga teway. The Gateway uses the Access Manager logging API for creating logs.

Using Accelerators with the Gate way

You can configure accelerators, which are dedicated hardware co-processors, to off-load the SSL functions from a server's CPU. Using accelerators frees the CPU to perform other tasks and increase s the processing speed for SSL transactions.

Netlet can provide secure access to fixed port applications and some dynamic port applications that are availa ble on the intranet from outside the intran et. The client can be behind a remote firewall and SSL proxy, or directly connected to the Internet. All the secure connections made from outside the intranet to the intranet applications through the Netlet are controlled by Netlet rules.

A Netlet applet running on the browser sets up an encrypted TCP/IP tunnel between the remote client machine and intranet applications on the remote host s. Netlet listens to and accepts connections on preconfigured ports, and routes both incoming and outgoing traffic between the client and the destination server. Both incoming and outgoing traffic is encrypted using an encryption algorithm selected by the user, or configured by the administrator. The Netlet rule contains the details of all servers, ports, and encryption algorithms used in a connection. Administrators create Netlet rules by using the Access Manage r administration console.

Static and Dynamic Port Applications

Static port applications run on known or static ports. Examples include IMAPand POP servers, Telnet daemons, and jCIFS. For static port applications, the Netlet rule includes the destination server port so that requests can be routed directly to their destinations.

Chapter 2 Portal Server Secure Remote Access Architecture 41

Netlet

Dynamic applications agree upon a port for communication as part of the handshake. You can include the destination server port as part of the Netlet rule. The Netlet needs to understand the protocol and examine the data to find the port being used between the client and the server. FTP is a dynamic port application. In FTP, the port for actual data transfer between the client and server is specified through the

PORT command. In this case, the Netlet parses the traffic to obtain the

data channel port dynamically. Currently, FTP and Microsoft Exchange are the only dynamic port application s

that Portal Server supports.

NOTE Although Microsoft Exchange 2000 is supported with Netlet, the

following constraints apply:

• You must configure Exchange to use STATIC ports.

• Netlet does not work with Windows 2000 and XP because Windows 2000 and XP clients reserve the Exchange port (port

135) for the RPC Portmapper, which Active Directory uses. Previous versions of Windows did not reserve this port. Because the port is reserved, you cannot assign Netlet to it, and thus the port cannot provide the necessary tunneling.

• The Outlook 2000 client has the limitation that it does not enable you to change the port on which you want to connect to the Exchange server.

42 Portal Server 6 2005Q1 • Deployment Planning Guide

Netlet

Netlet and Application Integration

Netlet works with many third parties such as Graphon, Citrix, and pcAnywhere. Each of these products provides secure access to the user’s Portal Desktop from a remote machine using Netlet.

Split Tunneling

Split tunneling allows a VPN client to connect to both secure sites and non-secure sites, without having to connect or disconnect the VPN—in this case, the Netlet—connectio n. The client determin es whether to send th e information over the encrypted path, or to send it by using the non-encrypted path. The concern over split tunneling is that you could have a direct connection from the non-secure Internet to your VPN-secured network, via the client. Turning off split tunneling (not allowing both connectio ns simultaneously) reduces the vulnerability of the VPN (or in the case of Netlet) connection to Internet intrusion.

Though Portal Server does not prohibit nor sh ut down multiple network connections while attached to the portal site, it does prevent unauthorized users from “piggybacking” on other users’s sessions in the following ways:

• Netlet is an application specific VPN and not a general purpose IP router. Netlet only forwards packets that have been defined by a Netlet rule. This differs from the standard VPN approach that gives you complete LAN access once you’ve connected to the network.

• Only an authenticated portal user can run the Netlet. No portal application can be run until the user has been successfully authenticated, and no new connections can be made if an authenticated session does not exist.

• All access controls in place on the application side are still in effect so that an attacker would also have to break in to th e back-e nd application.

• Every Netlet connection results in a dialog box posted by the Netlet (running in the authenticated user’s JVM™) to the authenticated user’s display. The dialog box asks for verification and acknowledgement to permit the new connection. For attackers to be able to utilize a Netlet connection, attackers would need to know that the Netlet was running, the port number it was listening on, how to break the back-end application, and convince the user to approve the connection.

Chapter 2 Portal Server Secure Remote Access Architecture 43

Netlet Proxy

A Netlet Proxy helps reduce the number of open ports needed in the firewall to connect the Gateway and the destination hosts.

For example, consider a configuration where users need Netlet to connect with a large number of Telnet, FTP, and Microsoft Exchange servers within the intranet. Assume that the Gateway is in a DMZ. If it routes the traffic to all the destination servers, a large number of ports would need to be open in the second firewall. To alleviate this problem, you can use a Netlet Proxy behind the second firewall and configure the Gateway to forward the traffic to the Netlet Proxy. The Netlet Proxy then routes all the traffic to the destination servers in the intranet and you reduce the number of open ports required in the second firewall. You can also deploy multiple Netlet Proxies behind the second firewall to avoid a single point of failure.

You could also use a third-party proxy to use only one port in the second firewall.

NOTE Installing the Netlet Proxy on a separate node can help with Portal

Server response time by offloading Netlet traffic to a separate node.

NetFile

NetFile enables remote access and operation of file systems that reside within the corporate intranet in a secure manner.

NetFile uses standard protocols such as NFS, jCIFS, and FTP to connect to any of the UNIX® or Windows file systems that are permissible for the user to access. NetFile enables most file operations that a re typical to file manager applications. See the Portal Server S ecure Remote Access 6 Administratio n Guide for more information.

Components

To provide access to various file systems, NetFile has three components:

• NetFile Java 1 Applet. Has an AWT-based user interface. For use with older

browsers that cannot support Java 2.

• NetFile Java 2 Applet. Has a Swing-based user interface. For use with

browsers that support Java plug-ins.

44 Portal Server 6 2005Q1 • Deployment Planning Guide

NetFile

• NetFile servlet(s). Two NetFile servlets are present in the web container, one for each kind of NetFile applet. The servlets are responsible for connectin g to different types of file systems, carrying out the operations that NetFile is configured to handle, and sending the informa tion back to the applets for display.

NetFile is internationalized and provides access to file systems irrespective of their locale (character encodings).

NetFile uses Access Manager to store its own prof ile, as well as user settings and preferences. You administer NetFile through the Access Manager administration console.

Initialization

When a user selects a NetFile link in the Portal Server Deskto p, the NetFile servlet checks if the user has a valid SSO token and permission to execute NetFile. If so, the applet is rendered to the browser. The NetFile applet connects back to the servlet to get its own configuration such as size, locale, resource bundle, as well as user settings and preferences. NetFile obtains the locale information and other user information (such as user name, mail ID, and mail server) using the user’s SSO token. The user settings include any settings that the user has inherited from an organization or role, settings that are customized by th e user, an d settings that the user has stored upon exit from a previous NetFile session.

Validating Credentials

NetFile uses the credentials supplied by users to authenticate users before granting access to the file systems.

The credentials include a user name, password, and Windows or Novell domain (wherever applicable). Each share can have an independent password, therefore, users need to enter their credentials for every share (exce pt fo r co mmon hosts) th at you add.

NetFile uses UNIX Authentication from the Access Manager to grant access to NFS file systems. For file systems that are accessed over FTP and jCIFs protocols, NetFile uses the methods provided by the protocol itself to validate the credentials.

Chapter 2 Portal Server Secure Remote Access Architecture 45

NetFile

Access Control

NetFile provides various means of file system access control. You can deny access to users to a particular file system based on the protocol. For example, you can deny a particular user, role, or organization access to file systems that are accessible only over NFS.

You can configure NetFile to allow or deny access to file systems at any level, from organization, to suborganization, to user. You can also allow or deny access to specific servers. Access can be allowed or denied to file syste ms for users depending on the type of host, includin g Windows, FTP, NFS, and FTP over NetWare. For example, you can deny access for Windows hosts to all users of an organization. You can also specify a set of common hosts at an organization or role level, so that all users in that organization or role can access the common hosts without having to add them for each and every member of the organization or role.

As part of the NetFile service, you can configure the Allowed URLs or Denied URLs lists to allow or deny access to servers at the organization, role, or user level. The Denied URLs list takes precedence over the Allowed URLs. The Allowed URLs and Denied URLs lists can contain the * wildcard to allow or deny access to a set of servers under a single domain or subdomain.

Security

When you use NetFile with SRA configured for SSL, all connections made from NetFile applets to the underlying file system happen over the SSL connection established between the Gateway and the browse r. Because you typically install the Gateway in a DMZ, and open a limited number of ports (usually only one) in the second firewall, you do not compromise security while providing access to the file systems.

Special Operations

NetFile is much like a typical file manager application with a set of features that are appropriate for a remote file manager application. NetFile enables users to upload and download files between th e local and remote file systems (shares). You can limit the size of the upload file (from the local to the remote file system) through the Access Manager administration console.

46 Portal Server 6 2005Q1 • Deployment Planning Guide

Rewriter

NetFile also enables users to select multiple files and compress them by using GZIP and ZIP compression. Users can select m u ltiple files and send them in a sin gle email as multiple attachments. N e tFile also uses the SSO token of Access Manag er to access the user’s email settings (such as IMAP server, user name, password, and reply-to address) for sendi ng e mail.

Double-clicking a file in the NetFile win d ow launches the application corresponding to the MIME type and opens the file. NetFile pro vid es a default MIME types configuration file that has mappings for most popular file types (extensions) and MIME-types that you can edit for adding new mappings.

You can search for files and display the list in a separate window using NetFile. The results of each search are displaye d in a new window while maintaini ng the previous search result windows. The type of character encoding to be used for a particular share is user configurable, and is part of the share’s setting. If no character encoding is specified, NetFile uses ISO-8859-1 while working with the shares. The ISO-8859-1 encoding is capable of handling most common languages. ISO-8859-1 encoding gives NetFile the capability to list files in any language and to transferring files in any language without damaging the file contents.

Rewriter

NetFile creates temporary files only when mailing files (in both NetFile Java 1 and Java 2). Temporary files ar e not created d u ring uploading and downloading files between Windows file systems and the local file systems over the jCIFS protocol.

NOTE NetFile supports deletion of directories and remo te f iles. All the

contents of remote directories are deleted recursively.

NetFile and Multithreading

NetFile uses multithreading to provide the flexibility of running multiple operations simultaneously. For example, users can launch a search operation, start uploading files, then send files by using email. NetFile performs all three operations simultaneously and s till permit the user to browse through the file listing.

Rewriter is an independent co mpon en t th at tra ns lat es al l UR Is (i n bot h HTML and JavaScript code) to ensure that the intranet content is always f e tched through the Gateway. You define a ruleset (a collection of rules) that identifies all URLs that need to be rewritten in a page. The ruleset is an XML fragment th at is written

Chapter 2 Portal Server Secure Remote Access Architecture 47

Rewriter Proxy

according to a Document Type Definition (DTD ). Using the generic ruleset that ships with the Rewriter, you can rewrit e most URLs (but not all) without any additional rules. You can also associate rulesets with domains for domain-based translations. See the Portal Server Secure Remote Ac cess 6 Admi nistrat ion Guide for more information.

An external ruleset identifies the URI in the content. Any request that needs to be served by SRA follows this route:

1. From the request, SRA identifies the URI of the intranet page or Internet page

that needs to be served.

2. SRA uses the proxy settings to connect to the identified URI.

3. The domain of the URI is used to identify the ruleset to be used to rewrite this

content.

4. After fetching the content and ruleset, SRA inputs these to the Rewriter wh ere

identified URIs are translated.

5. The original URI is replaced with the rewritten URI.

6. This process is repeated until the end of the document is reached.

7. The resultant Rewriter output is routed to the browser.

Rewriter Proxy

To minimize the number of open ports in the firewall, use the Rewriter Proxy. When you install the Rewriter Proxy, HTTP requests are redirected to the Rewriter Proxy instead of directly to the destination host. The Rewriter Proxy in turn sends the request to the destination server.

Using the Rewriter Proxy enables secure HTTP traffic between the Gateway and intranet computers and offers two advantages:

• If a firewall is between the Gateway and server, the firewall needs to open only two ports. One firewall is between the Gateway and the Rewriter Proxy and another is between the Gateway and the Portal Server.

• You can use a third-party proxy to use only one port in the second firewall to read the Rewriter Proxy.

• HTTP traffic is now secure between the Gateway and the intranet even if the destination server only supports HTTP protocol (not HTTPS).

48 Portal Server 6 2005Q1 • Deployment Planning Guide

Proxylet

NOTE You can run multiple Rewriter Proxies to avoid a single point of

failure and achieve load balancing.

Proxylet is a dynamic proxy server that runs on a client machine. Proxylet redirects a URL to the Gateway. It does this by reading and modifying the proxy settings of the browser on the client machine so that the settings point to the local proxy server or Proxylet.

It supports both HTTP and SSL, inheriting the transport mode from the Gateway. If the Gateway is configured to run on SSL, Proxylet establishes a secure channel between the client machine and the Gateway. Proxylet uses the JSSE API if the client JVM is 1.4 or higher or if the required jar files reside on the client machin e. Otherwise it uses the KSSL API.

Proxylet is enabled from the Access Manager administration console where the client IP address and port are specified.

Unlike Rewriter, Proxylet is an out-of-the-box solution with very little or no post-installation changes. Also Gateway performance improves because Pro x ylet does not deal with web content.

Chapter 2 Portal Server Secure Remote Access Architecture 49

Proxylet

50 Portal Server 6 2005Q1 • Deployment Planning Guide

Chapter 3

Identifying and Eval uating Your Business

and Technical Requirements

The first step in planning your deployment is id entifying your Sun Java™ System Portal Server business and technical requirements.. You need to gather both business and technical requirements before you can address architecture and design issues.

This chapter contains the following sections:

• Business Objectiv es

• Technical Goals

• Mapping Portal Server Features to Your Business Needs

• Understanding User Behaviors and Patterns

Business Objectives

Your business requirements address your organization’s problems and opportunities, and include such factors as :

•Services

• Service availability

•Future growth

• New technologies

• Capital investment To be useful in formulating design requirements, the business requirements must

address detailed goals and objectives.

Business Objectives

The business goals of your portal affect deployment decision. Understand your objectives. If you do not understand your business requirements, you can easily make erroneous assumptions that could affect the accuracy of your deployment estimates.

Use these questions to help you identify your business objectives:

• What are the business goals of this portal? (For example, do you want to enhance customer service? Increase employee productivity? Reduce the cost of doing business?)

• What kind of portal do you need? (For example, business-to-business, business-to-consumer , business-to-enterprise, or a hybrid?)

• Who is your target audience?

• What services or functions will the portal deliver to users?

• How will the target audience benefit from the portal?

• What are the priorities for the portal? (If you plan to deploy your portal in phases, identify priorities for each phase.)

(Optional) Use these questions to h e lp id entify your business objectives if you are deploying a secure portal:

• Do you need to increase employee productivit y (by making your intranet applications and servers accessible over the Internet)?

• Do you need to provide secure access to your portal?

• Do you need to redu c e c os t of ownership of an existi ng Vir t u al Pr iv a t e Network (VPN) solution?

• Do you want employees to access intranet applications such as Citrix and pcAnywhere from the Internet?

• Do you want your employees to explore intranet servers or machines from the Internet?

• Who is your target audience (all portal users, employees, or customers)?

52 Portal Server 6 2005Q1 • Deployment Planning Guide

Technical Goals

Your technical requirement (often called functional requirement) discuss the details of your organization’s system needs and desired results, and include such factors as:

•Performance

•Security

• Reliability

• Expected performance criteria of the portal The technical requirements define all functions required of an architecture and

provide guidelines for how each component works and integrates to form an entire system. Your organization needs technical requirements to formulate the best design approaches and apply the appropriate technologies to accomplish the desired architectural solution for your po rt al.

The reasons you are offering your portal have a direct affect on how you implement your portal. You must define target population, performance standards, and other factors related to your goals.

Technical Goals

Use these questions to help you identify the goals of your portal:

• What is your portal’s biggest priority?

• What applications will the portal deliver?

• What is your target population?

• What performance standard is necessary?

• What transaction volume do you expect? What transaction volume do you expect during peak use?

• What response time is acceptable during peak use?

• What is the necesary level of concurrency? Concurrency is the number of users who can be connected at any given time?

• Should access to the portal be through intranet or Internet?

• Will your portal be deployed in one phase, or many phases? (Describe each phase and what will change from phase to phase.)

Chapter 3 Identifying and Evaluating Your Business and Technical Requirements 53

Mapping Portal Server Features to Your Business Needs

The previous sections posed questions to you about the various areas of the Portal Server system from a high-level perspective of business and technical needs. This section reviews specific technology features with the goal of determining which technologies are most importan t for your organization. Review these fe atures while keeping in mind your organiz ation’s short-, mid-, and long-term plans.

Use the following sections and tables to assess the benefits of the listed features and determine their relative priority for your organi zation. This information will a ssist you in developing a deployment plan in a timely and cost effective manner.

NOTE In all likelihood, your Sun Java System sal e s rep res entative has

previously discussed these topics with you. Thus, this section serves as a review of that process.

Identity Management

Portal Server uses identity management to control many users spanning a variety of different roles across the organization and sometimes outside the organization while accessing content, applications and services. The challenges include: Who is using an application? In what capacity do us ers serve the organization or company? What do users need to do, and what should users be able to access? How can others help with the administrative work?

Table 3-1 shows the identity management features and their benefits.

Table 3-1 Identity Manag e m ent Fe at u res and Benefits

Feature Description Benefit

Directory service Portal Server uses Access Manager and

Directory Server

Portal Server uses an LDAP directory for storing user profiles, roles, and identity information for the purpose of authentication, single sign-on (SSO), delegated administration, and personalization

Portal Server uses an open schema that can reside in a centralized user directory, thereby leveraging an enterprise or service provider’s investment in the Access Manager and Directory Server products.

54 Portal Server 6 2005Q1 • Deployment Planning Guide

Mapping Portal Server Features to Your Business Needs

Table 3-1 Identity Management Features and Benefits (Continued)

Feature Description Benefit

User, policy, and provisioning management

Single sign-on (SSO)

Access Manager enables you to manage many users spanning a variety of different roles across the organization and sometimes outside the organization while accessing content, applications, and services.

Access Manager integrates user authentication and single sign-on through an SSO API. Once the user is authenticated, the SSO API takes over. Each time the authenticated user tries to access a protected page, the SSO API determines if the user has the permissions required based on their authentication credentials. If the user is valid, access to the page is given without additional authentication. If not, the user is prompted to authenticate again.

Provides a centralized identity management solution for storing and managi ng identity information, which is integrated with a policy solution to enforce access rights, greatly simplifying these challenges. Extends a common identity to handle new applications, enables applications to share administrative work, and simplifies tasks normally associated with building these services from scratch.

Consolidates management of users and applications. Personalizes content and service delivery. Simplifies and streamlines information and service access. Reduces costs associated with managing access and delivery.

Provides secure policy-based access to applications. Ensures secure access as portal deployments expand beyond employee LAN access.

Enhances user productivity by providing a consistent, centralized mechanism to manage authentication and single s ign-on, while enabling employees, partners and customers access to content, applications, and services.

Delegated administration

The Access Manager administration console provides role-based delegated administration capabilities to different kinds of administrators to manage organizations, users, policy, roles, channels, and Portal Desktop providers based on the given permissions.

Security Provides single sign-on for aggregated

applications to the portal.

Enables IT to delegate portal administrative duties to free up valuable IT res ources and administration.

Security is an important fu nctionality in portals. Security can address many different needs within the portal, including authentication into the portal, encryption of the communications between the portal and the end user, and authorization of the content and applications to only users that are allowed access.

Chapter 3 Identifying and Evaluating Your Business and Technical Requirements 55

Mapping Portal Server Features to Your Business Needs

SRA

Table 3-2 shows the Sun Java System Portal Server Secure Remote Access (S RA)

features and their benefits

Table 3-2 SRA Features an d Benefits

Feature Description Benefit

Integrated security Extranet or Virtual Private Network

capabilities “on demand” while providing user, policy, and authentication services. The Gateway component provides the interface and security barrier between remote user sessions originating from the Internet, and your corporate intranet.

SRA core Users achieve remote access through four

components:

• Gateway

• NetFile

• Netlet

• Proxylet

Universal access Enables web browser based universal access

with no client software installation or maintenance necessary.

Extends an enterprise’s content, applications, files, and services located behind firewalls to authorized suppliers, business partners, and employees.

To prevent denial of service attacks, you can use both internal and external DMZ-based Gateways.

This component has four parts:

• Gateway—Controls communication between the Portal Server and the various Gateway instances.

• NetFile—Enables remote access and operation of file systems an d directories.

• Netlet—Ensures secure communication between the Netlet applet on the client browser, the Gateway, and the application servers.

• Proxylet—Redirects a URL to the Gateway.

Simplifies the IT administration and maintenance overhead while dramatically reducing the time and cost of deployment

Netlet Proxy Provides an optional component that extends

the secure tunnel from the clie nt, through the Gateway to the Netlet Proxy that resides in the intranet.

56 Portal Server 6 2005Q1 • Deployment Planning Guide

Restricts the number of open ports in a firewall between the demilitarized zone (DMZ) and the intranet.

Mapping Portal Server Features to Your Business Needs

Feature Description Benefit

Rewriter Proxy Redirects HTTP requests to the Rewriter

Proxy instead of directly to the destination host. The Rewriter Proxy in turn sends the request to the destination server.

Search Engine

The Search Engine service is used in the following channels:

• Subscription channel to summarize the number of hits (relevant information) that match each profile entry defined by the user for categorized documents and discussions.

Using the Rewriter Proxy enables secure HTTP traffic between the Gatew ay and intranet computers and offers two advantages:

• If a firewall exists between the Gateway and server, the firewall needs to open only two ports—one between the Gateway and the Rewriter Proxy, and another between the Gatewa y and the Portal Server.

• HTTP traffic is now secure between the Gateway and the intranet even if the destination server only supports HTTP protocol (no HTTPS).

• Discussion channel to

individually search contents and rate the importance for

comments.

Table 3-3 shows the Search featur es and their benefits.

Table 3-3 Search Features and Benefits

Feature Description Benefit

Search Engine Enables the retrieval of documents based on

criteria specified by the end user.

Categorization Organizes documents into a hierarchy. This

categorization is often referred to as taxonomy.

Robot The Search Engine robot is an agent that

crawls and indexes information across your intranet or the Internet.

Discussions A forum for multiple threaded discussions. Contents are individually searchable and

Chapter 3 Identifying and Evaluating Your Business and Technical Requirements 57

Saves users time by providing access to content.

Provides a different view of documents that enables browsing and retrieval.

Automatically searches and extracts links to resources, describes those resources, and puts the descriptions in the Search database (also called generation or indexing).

importance rating are given for of all comments

Mapping Portal Server Features to Your Business Needs

Table 3-3 Search Features and Benefits (Continued)

Feature Description Benefit

Subscriptions Enables the user to track new or changed

material in different areas of inte rest.

Discussions, search categories, and free-form searches (saved searches) can be tracked.

Personalization

Personalization is the ability to deliver content based on selective criteria and offer services to a user.

Table 3-4 shows the personalization features and their benefits.

Table 3-4 Personalization Features and Benefits

Feature Description Benefit

Deliver content based on user’s role

Enable users to customize content

Portal Server includes the ability to automatically choose which applicatio ns users are able to access or to use, based on their role within the organization.

Portal Server enables end users to choose what content they are interested in seeing. For example, users of a personal finance portal choose the stock quotes they would like to see when viewing their financial portfolio.

Increases employee productivity, improves customer relationships, and streamlines business relationships by providing quick and personalized access to content and services.

The information available in a portal is personalized for each individual. In addition, users can then customize this information further to their individual tastes. A portal puts control of the web experience in the hands of the people using the web, n ot the web site builders.

Aggregate and personalize content for multiple users

Portal Server enables an enterprise or service provider to aggregate and deliver personalized content to multi p le communities of users simultaneously.

Aggregation and Integration

One of the most important aspects of a portal is its ability to aggregate and integrate information, such as applica tions, services, and content. This functionality includes the ability to embed non-persistent informa tion, such as stock quotes, through the portal, and to run applications within, or deliver them through, a portal.

58 Portal Server 6 2005Q1 • Deployment Planning Guide

This enables a company to deploy multiple portals to multiple audiences from one product and manage them from a central management console. Also, new content and services can be added and delivered on demand without the need to restart Portal Server. All of this saves time and money, and ensures consistency in an IT organization.

Table 3-5 shows the aggregation and integration features and their benefits.

Table 3-5 Aggregation Features and Bene fits

Feature Description Benefit

Understanding User Behaviors and Patterns

Aggregated information

Consistent set of tools

Collaboration Portal Server provides control and access to

Integration Portal Server enables you to use the Portal

The Portal Desktop provides the primary end-user interface for Portal Server and a mechanism for extensible content aggregation through the Provider Application Programming Interface (PAPI). The Portal Desktop includes a variety of providers that enable container hierarchy and the basic building blocks for building some types of channels.

Users get a set of tools like web-based email and calendaring software that follows them through their entire time at the company.

data as a company-wide resource.

Desktop as the sole plac e for users to gain access to or launch applications and access data.

Users no longer have to search for the information. Instead, the information finds them.

Users do not have to use one tool for one project, another tool for another location. Also, because these tools all work within the portal framework, the tools have a consistent look and feel and work similarly, reducing training time.

In many companies, data is seen as being owned by individual departments, instead of as a company-wide resource. The portal can act as a catalyst for breaking down these silos and making the data available in a controlled way to the people who need to use it. This broader, more immediate access can improve collaboration.

Iintegration with existing email, calendar, legacy, or web applications enables the portal to serve as a unified access point, enabling users—be that employees, partners, or customers—to access the information users need quickly and easily.

Understanding User Behaviors and Patterns

Study the people who will use your portal. Factors such as when users will use the portal and how users have used predecessor systems are keys to identifying your requirements. If your organization’s experience cannot provide these patterns, you can study the experience of other organizations and estimate them.

Use these questions to help you understand users:

• How many end users will you have? What is the size of your target audience?

Chapter 3 Identifying and Evaluating Your Business and Technical Requirements 59

Understanding User Behaviors and Patterns

• Will users login to the portal at the same time each day? Will they use the portal at work or somewhere else?

• Are users in the same time zone or in different time zones?

• How long do you expect the typical user to be connected, or have a valid portal session open? What use statistics do you have for existing applications? Do you have web traffic analysis figures for an existing portal?

• How many visitor sessions, or number of single-visitor visits, are li kely within a predefined period of time?

• Is portal use likely to increase over time? Or s tay stable?

• How fast will your user base grow?

• How have your users used an application that the portal will deliver to them?

• What portal channels do you expect users to use regularly?

• What expectations about your portal content do your users have? How have users used predecessor web-based information or other resources that your portal will offer?

60 Portal Server 6 2005Q1 • Deployment Planning Guide

Pre-Deployment Considerations

This chapter contains the following sections:

• Determine Your Tuning Goals

• Portal Sizing Tips

• Establish Performance Methodology

• Portal Sizing

Chapter 4

• SRA Sizing

Determine Your Tuning Goals

Before tuning you portal, work with portal system administrators and portal developers to set the portal performance objectives based upon the projected requirements of your portal. Objectives include the number of users, the number of concurrent users at peak load time and their usage pattern in accessing Sun Java™ System Portal Server.

You need to determine these two factors:

• Are you tuning for portal applications rapid response?

• Are you tuning for a large number of user concurrency? As the number of users concurrently connected to the portal increase, the

response time decreases given the same hardware and same set of parameters. Hence, gather information about the level of usage expected o n yo ur Sun Java System Portal Server, the anticipated number of concurrent users at any given

Portal Sizing Tips

time, the number of Portal desktop activity requests, the amo unt of portal channel usage, acceptable response time for the end-user which is determined by your organization, and an optima l hardware configuration to meet the criteria.

Portal Sizing Tips

This section contains a few tips to h elp you in the sizing process.

• A business-to-consumer portal requires that you deploy SRA to use the Gateway and SSL. Make sure you take this into account for your sizing requirements. Once you turn on SSL, the performance of the portal can be up to ten times slower than without SSL .

• For a business-to-employee portal, make sure that you have a user profile that serves as a baseline.

• For any portal, build in headroom for growth. This means not just sizing for today’s needs, but future needs and capacity. This includes usual peaks af ter users return from a break, such as a weekend or holiday, or if usage is increased over time because the portal is more “sticky.”

• If you are deploying your portal solution across multiple geographic sites, you need to fully understand the layout of your networks and data centers

• Decide what type of redundancy you need. Consider items such as production down time, upgrades, and maintenance work. In general, when you take a portal server out of production, the impact to your capacity should be no more than one quarter (1/4) of the overall capacity.

• In general, usage concurrencies for a busin e ss-to-employee portal are higher than a business-to-consumer portal .

Establish Performance Method ology

Once you have established your performance goals, follow the steps below to tune your portal environment.

1. Identify and remove obvious bottlenecks in the processor, memory, netwo rk,

and disk.

62 Portal Server 6 2005Q1 • Deployment Planning Guide

Portal Sizing

2. Setup a controlled environment to minimize the margin of error (defined as

less than ten percent variation between identical runs). By knowing the starting data measurement baseline, you can measure the

differences in data performance between sample gathering runs. Be sure measurements are taken over an adequate period of time and that you are able to capture and evaluate the results of these tests.

Plan to have a dedicated machine for generating load simulation wh ich is separate from the Portal Server machine. A dedicated machine helps you to uncover the origin of performance problems.

See “Portal Sizi ng ” on page 63.

3. Develop and refine the prototype workload that closely simulates the

anticipated production environment agreed between you and the portal administrators and portal developers.

See “Analysis Tools” on page 143

4. Monitor customized portal application s such as portlets.

Portal Sizing

You need to establish a baseline sizing fi gure for your Portal Server. With a baseline figure established, you can then validate and refine that figure to account for scalability, high availability, reliability, and good performance.

The portal sizing process consists of the following steps:

1. Establish Baseline Sizing Figures

2. Customize the Baseline Sizing Figures

3. Validate Baseline Sizing Figures

4. Refine Baseline Sizing Figures

5. Validate Your Final Figures

The following sections describe these steps.

Chapter 4 Pre-Deployment Considerations 63

Portal Sizing

Establish Bas e li ne Sizing Figure s

Once you have identified your business and technical requirements, and mapped Portal Server features to your needs, your sizing requirements emerge as you plan your overall Portal Server deployment. Your design decisions help you make accurate estimates regarding Portal Server user sessions and concurrency.

NOTE Sizing requirements for a secure portal deployment using Sun Java

System Portal Server Secure Remote Access (SRA) software are covered in “SRA Sizing” on page 72.

Your Sun Java System technical representative can provide you with an automated sizing tool to calculate the estimated number of CPUs your Portal Server deployment requires. You need to gather the followin g metrics for input to the sizing tool:

• Peak Numbers

• Average Time Between Page Requests

• Concurrent Users

• Average Session Time

• Search Engine Factors

Other performance metrics that affect the number of CPUs a Portal Server deployment requires, but are not used by the sizing tool, are:

• Portal Desktop Configuration

• Hardware and Applications

• Back-end Servers

•Transaction Time

• Workload Conditions

A discussion of the these performance factors follows.

Peak Numbers

Maximum number of concurrent sessions defines how many connected users a Portal Server deployment can handle.

To calculate the maximum number of concurrent ses sions, use this formula:

64 Portal Server 6 2005Q1 • Deployment Planning Guide

Portal Sizing

maximum number of concu rrent sessio ns = expected percent of use rs online * user base

To identify the size of the user base or pool of potential users for an enterprise portal, here are some suggestions:

• Identify only users who are active. Do not include users who are, for example, away on vacation, or on leave.

• Use a finite figure for user base. For an anonymous portal, estimate this number conservatively.

• Study access logs.

• Identify the geographic locations of your user base.

• Remember what your business plan states regarding who your users are.

Average Time Between Page Requests

Average time between page requests is how often, on average, a user requests a page from the Portal Server. Pages could be the initial login page to th e porta l, or a web site or web pages accessed through the Portal Desktop. A page view is a single call for a single page of information no matter how many items are contained on the page.

Though web server logs record page requests, using the log to calculate the average time between requests on a user basis is not feasible. To calculate the average time between page requests, you would probably need a commercially available statistics tool, such as the WebLoad performance testing to ol. You can then use this figure to determine the number of concurrent users.

NOTE Page requests more accurately measure web server traffic than

“hits.” Every time any file is requested from the web server counts as a hit. A single page call can record many hits, as every item on the page is registered. For example, a page containing 10 graphic files records 11 “hits”—one for the HTML page itself and one for each of the 10 graphic files. For this reason, page requests gives a more accurate determination of web server traffic.

Concurrent Users

A concurrent user is one connected to a running web browser process and submitting requests to or receiving results of requests from Portal Server. The maximum number of concurrent users is the highest possible number of concurrent users within a predefined period of time.

Chapter 4 Pre-Deployment Considerations 65

Portal Sizing

Calculate maximum number of concurrent users after you calculate maximum number of concurrent s essions. To calculate the maximum number of concurrent users, use

this formula:

concurrent users = number of conc urrent sessi ons / averag e time betwe en hit s

For example, consider an intranet Portal Server example of 50,000 users. The number of connected sessions under its peak loads is estimated to be 80% of its registered user base. On average, a user accesses the Portal Desktop once every 10 minutes.

The calculation for this example is:

40000 / 10 = 4 000

The maximum number of concurrent users during the peak hours for this Portal Server site should be 4,000.

Average Session Time

Average session tim e is the time between user login and logout averaged over a number of users. The length of the session time is inversely proportional to the number of logins occurring (that is, the longer the session duration, the fewer logins per second are generated against Portal Server for the same concurrent users base). Session time is the time between user login and user logout.

How the user uses Portal Server often affects average session time. For example, a user session involving interactive applications typically has a longer session time than a user session involving inf ormation only.

Search Engine Factors

If your portal site will offer a Search channel, you need to include sizing factors for the Search Engine in your sizing calculations. Search Engine sizing requ irements depend on the following factors :

• The size of index partitions on the active list of the index directory Partition size is directly proportiona l to the size and number of indexed and

searchable terms.

• Average disk space requirement of a resource description (RD) To calculate this, use this formula:

average disk s pace r equire ment = database size / number of RDs in datab ase

66 Portal Server 6 2005Q1 • Deployment Planning Guide

The average size adjusts for variat ions in sizes of RDs. A collection of lon g, complex RDs with many indexed terms and a list of short RDs with a few indexed terms require different search times, even if the complex RDs have the same number of RDs.

RDs are stored in a hi erarch i cal databa se format, where the intrinsi c s i ze o f the database must be accounted for, even when no RD is stored.

• The number of concurrent users who perform search-related activities To calculate this, use this formula:

number of conc urrent users / average time between search hits

Use the number of concurrent users value calculated in “Average Time

Between Page Requests” on page 140.

• The type of search operators used Types of search functions include basic, combining, proximity, passage and

field operator, and wildcard scans. Each function uses different search algorithms and data structures. Because differences in search algorithms and data structures increase as the number of search and indexed terms increase, the type of search function affects times for search result return trips.

Portal Sizing

TIP You can now give the above figures to your technical representative

and ask that the sizing tool be run to identify your estimated number of CPUs.

Portal Desktop Configuration

Portal Desktop configuratio n explicitly determines the amount of dat a h el d in memory on a per-session basis.

The more channels on the Portal Desktop, the bigger data session size, and the lesser the throughput of Portal Server.

Another factor is how much interactivity the Portal Desktop offers. For example, channel clicks can generate load on Portal Server or on some other external server. If channel selections generate load on Porta l Server, a h igher user activity profile and higher CPU overhead occur on the node that hosts the Portal Desktop than on a node that hosts some other external server.

Chapter 4 Pre-Deployment Considerations 67

Portal Sizing

Hardware and Applicat ions

CPU speed and size of the virtual machine for the Java™ platform (Java™ Virtual Machine or JVM™ software) memory heap affect Portal Server performance.

The faster the CPU speed, the higher the throughput. The JVM memory heap size, along with the heap generations tuning parameters, can also affect Portal Server performance.

Back-End Servers

Portal Server aggregates content from external sources. If external content providers cannot sustain the necessary bandwidth for Portal Server to operate at full speed, Portal Desktop rendering and throughput request times will not be optimum. The Portal Desktop waits until all channels are completed (or timed out) before it returns the request response to the browser.

Plan your back-end infrastructure carefully when you use cha nn e ls that:

• Scrape their content from external sources

• Access corporate databases, which typically have slow response times

• Provide email content

• Provide calendar content

Transaction Time

Transaction time, which is the delay taken for an HTTP or HTTPS operation to complete, aggregates send time, processing time, and response time figures.

You must plan for factors that can affect transaction time. These include:

• Network speed and latency. You need to especially examine latency over a Wide Area Network (WAN).

Latency can significantly increase retrieval times for large amounts of data .

• The complexity of the Portal Desktop.

• The browser’s connection speed. For example, a response time delay is longer with a connection speed of 33.6

kilobytes per second than with a LAN connection speed. However, processing time should remain constant. Transaction time through a dial-up connection should be faster than transaction time displayed by a load generation tool because it performs data compression.

68 Portal Server 6 2005Q1 • Deployment Planning Guide

Portal Sizing

When you calculate tran saction time, size your Portal Server so that processing time under regular or peak load conditions does not exceed your performance requirement threshold and so that you can sustain proce ssing time over time.

Workload Conditions

Workload conditions are the most predominantly used system and JVM software resources on a system. These condition s la rgely d e pend on user behavior and the type of portal you deploy.

The most commonly encountered workload conditions on Portal Server software affect:

•System performance Portal Server performance is impacted when a large number of concurrent

requests are handle d (such as a h igh activi ty profile). F or example, duri ng peak hours in a business-to-enter prise portal, a significant nu mber of company employees connect to the portal at the same time. Such a scenario creates a CPU-intensive workload. In addition, the ratio of concurrent users to connected users is high.

• System capacity Portal Server capacity begins to be impacted when large numbers of users log

in. As more users login, users use more of the available memory, and subsequently, less memory is available to process requests made to the server. For example, in a business-to-consumer web portal, a large number of logged-in users are redirected to external web sites once the initia l Portal Desktop display is loaded. However, as more users continue to login, users create the need for more memory, even though the ratio of users submitting requests to Portal Server and the users merely logged-in is low.

Depending on the user’s behavior at certain times of the day, week, or month, Portal Server can switch between CPU-intensive and memory-intensive workloads. The portal site administrator must determine the most important workload conditions to size and tun e the site to meet the enterprise’s business goals.

Customize the Baseline Sizing Figures

Establishing an appropri ate sizing estimat e for your Portal Server deployment is an iterative process. You might wish to change the inputs to generate a range of sizing results. Customizing your Portal Server deployment can greatly affect its performance.

Chapter 4 Pre-Deployment Considerations 69

Portal Sizing

After you have an estimate of your sizing, consider:

• LDAP Transaction Numbers

• Application Server Requirements

LDAP Transaction Numbers

Use the following LDAP transa ction numbers for an out-of-the-box portal deployment to understand the impact of the service demand on the LDAP ma ster and replicas. These numbers change on ce you begin customizing the system.

• Access to authless anonymous portal - 0 ops

• Login by using the Login channel - 2 BINDS, 2 SRCH

• Removing a channel from the Portal Desktop - 8 SRCH, 2 MOD

• Reloading the Portal Desktop - 0 ops

Application Ser v e r Requ ir ements

One of the primary uses of Portal Server installed on an application server is to integrate portal providers with Enterprise JavaBeans™ architecture and other J2EE™ technology stack construc ts, such as JDBC and JCA, running on the application server. These other applicat ions and modules can consume resources and affect your portal sizing.

Validate Baseline Sizing Figures

Now that you have an estimate of the number of CPUs for your portal deployment, use a trial deployment to measure the performance of the portal. Use load balancing and stress tests to determine:

• Throughput, the amount of data processed in a specified amount of time

• Latency, the period of time that one component is waiting for another component

• Maximum number of concurrent se ssions

Portal samples are provided with the Portal Server. You can use them, with channels similar to the ones you will use, to create a load on the system. The samples are located on the Portal Desktop.

70 Portal Server 6 2005Q1 • Deployment Planning Guide

Portal Sizing

Use a trial deployment to determine your final sizing estimates. A trial deployment helps you to size back-end integr ation, to avoid potential bottlenecks with Portal Server operations.

Refine Baseline Sizing Fi gures

Your next step is to refine your sizing figure. In this section, you build in the appropriate amount of headroom so that you can deploy a portal site that features scalability, high avail abi lity, reliability and good performanc e.

NOTE Refining baseline sizing requirements for a secure portal

deployment using SRA is covered in “SRA Sizing” o n page 72.

Because your baseline sizing figure is based on so many e stimates, do not use this figure without refining it.

When you refine your baseline sizing figure:

• Use your baseline sizing figure as a reference point.

• Expect variations from your baselin e siz ing figure.

• Learn from the experience of others.

• Use your own judgement and kn owledge.

• Examine other factors in your deployment. If the Portal Server deployment involves multiple data centers on several

continents and even traffic, you need a higher final sizing figure than if you have two single data centers on one continent with heavy traffic.

• Plan for changes. A portal site is likely to experience various changes after you launch it.

Changes you might encounter include the following:

❍ An increase in the number of channels ❍ Growth in the user base ❍ Modification of the portal site’s purpose ❍ Changes in security needs ❍ Power failures

Chapter 4 Pre-Deployment Considerations 71

SRA Sizing

❍ Maintenance demands

Considering these factors enables you to develop a sizing figure that is flexible and enables you to avoid risk when your assumptions regarding your portal change following deployment.

The resulting figure ensures that your portal site has the following:

• Scalability high availability, reliability and high performa nce

• Room for whatever you want to provide

• Flexibility for adjusting to changes

Validate Your Final Figures

Use a trial deployment to verify that the portal deployment satis fi es your business and technical requirements.

SRA Sizing

Use this section only if your organ iz ation is implementing a secure portal by installing SRA. As you did for portal, for SRA, you must first establish your Gateway instances baseline sizing estimate (A single ma chine can have one Gateway installation but multiple instances. SRA enables you to install multiple Gateways, each running multiple instances.) Your design decisions help you make accurate estimates regard ing SRA user sessions and concurrency.

You must first establish your Gateway instances baseline sizing estimate. This baseline figure represents what you must have to satisfy your Gateway user sessions and concurrency needs.

Establishing an appropriate sizing estimate for your SRA deployment is an iterative process. You might wish to change the inputs to generate a range of sizing results. Test these results against your original requirements. You can avoid most performance problems by formulating your requirements correctly and setting realistic expectations of SRA performance.

This section explains the following types of performance factors that the Gateway instances baseline sizing process involves:

• Identifying Gateway Key Performance Requirements

• Advanced Gateway Sett ings

72 Portal Server 6 2005Q1 • Deployment Planning Guide

SRA Sizing

Identifying Gateway Key Performance Requirements

Key performance factors are metrics that your technical representative uses as input to an automated sizing tool. The sizing tool calculates the estimated number of Gateway instances you r SR A deployment requires.

Identifying these key performance factors an d giving them to your technical representative is the first step in formulating your baseline sizing figure.

NOTE Properly sizing the Gateway is di fficult, and using the Gateway

sizing tool is only the beginning. Gateway performance depends more on throughput then on the number of users, active users, or user sessions. Any sizing information f or the Gateway has to be based on a set of assumptions. See “Secure Remote Access Example”

on page 152 fore more information.

These are the key performance factors:

• Session Characteristics

• Netlet Usage Characteristics

NOTE After you calculate these key performance factors, give the figures to

your technical representative. Ask that the Gateway sizing too l be run to identify the estimated number of Gateway instances.

Session Characteristics

The session characteristics of the Gatew ay include:

• Total number of SRA (Gateway) users This represents the size of your user base or pool of potential users for the

secure portal. See “Concurrent Sessions” on page 139 for more information on estimating this number.

• Expected percentage of total users using the Gateway (at maximum load) Apply a percentage to your total number of users to determine thi s figure.

• Average time between page hits This is how often on average a user requests a page from the portal server.

Chapter 4 Pre-Deployment Considerations 73

SRA Sizing

• Session average time This determines how many logins per second that the Gatewa y must sustain

for a given number of c oncurrent users.

Netlet Usage Characteristics

Consider the following Netlet characteristics of the Gateway, which can have a impact in calculating the number of Gateway instances:

• Netlet is enabled in the Access Manager administration conso le. If Netlet is enabled, the Gateway needs to determine whether the incoming

traffic is Netlet traffic or Portal Server traffic. Disabling Netlet reduces this overhead since the Gateway assumes that all incoming traffic is either HTTP or HTTPS traffic. Disable Netlet only if you are sure you do not want to use any remote applications with Portal Server.

• Expected percentage of total users using Netlet Apply a percentage to your total number of users to determine thi s figure.

• Expect e d throughp ut Determine the expected throughput of your Gateway, expressed in kilobits per

second (Kbps).

• Netlet Cipher (encryption) being used Choices include Native VM and Java software plugin ciphers.

74 Portal Server 6 2005Q1 • Deployment Planning Guide

SRA Sizing

Advanced Gateway Settings

Use the settings in this section to obtain more accurate results when estimating the number of Gateway instances for your deployment. These advanced Gateway settings are used as input to the automated sizin g tool.

These are the advanced Gateway settings:

• Page Configuration

•Scalability

• Secure Portal Pilot M easured Numbers

NOTE After your technical representative has given you a figure for your

estimated number of CPUs, consider how these related performance factors affect this figure.

Page Configuration

If you are using an authenticated portal, you must specify both Login Type and Desktop Type in the page configuration section of the automated sizing tool

• Login Type. Describes the type of portal page (content configuration and

delivery method) that end users initially see after subm itting user name and password. This process s typically taxin g on the system because the process involves checking credentials, initializing the session, and delivering initial content.

The Measured CPU Performanc e characte ristic associ ated wit h the Login Type is the Initial Desktop Display variable.

• Desktop Type. Describes the type of portal pages (content configuration and

delivery method) that end users see after the initial portal page. These pages are displayed with each subsequent interaction with the portal, or on Desktop refresh. Because the session has already been established and cached content can be exploited, less system resources are typically required and the pages are delivered more rapidly.

The Measured CPU Performance characteristic associated with the Desktop Type is the Desktop Reload variable.

For both Login Type and Desktop Type, select the appropriate content configuration:

• Light-JSP. Describes a configuration of two tabs with five channels each.

Chapter 4 Pre-Deployment Considerations 75

SRA Sizing

• Regular-JSP. Describes a configuration of two ta bs with seven channels each.

• Heavy—JSP. Describes a configuration of three tabs with seventeen channels each.

Scalability

You can choose between one, two, and four CPUs per Gateway instance. The number of CPUs bound to a Gateway instance determines the number of Gateway instances required for the deployment.

Secure Portal Pilot Measured Numbers

If you have numbers from a pilot of the SRA portal, you can use these numbers in the Gateway sizing tool to arrive at more accurate results. You would fill in th e following:

• Measured CPU Performance. The values used to help calculate the number of Gateway instances include:

❍ Initial Portal Desktop Dis play, hits per second per CPU ❍ Portal Desktop Reloads, hits per second per CPU

• Netlet Applications Block Size. This value specifies the Netlet application byte size. The Netlet dynamically determines the block size based on the application that is used. Block size determined by Netlet for a Telnet is based on the amount of data transferred.

NOTE You do not need to specify the Page Configuratio n and Scalability

options if you are using tria l d epl oyment numbers.

SRA Gateway and SSL Hardware Accelerators

SSL-intensive servers, such as the SRA Gateway, require large amounts of processing power to perform the encryption required for each secure transaction. Using a hardware accelerator in the Gateway speeds up the execution of cryptographic algorithms, thereby increasing the performance speed.

The Sun Crypto Accelerator 1000 board is a short PCI board that functions as a cryptographic co-processor to accelerate public key and symmetric cryptography. This product has no external interfaces. The board communicates with the host through the internal PCI bus interface. The purpose of this board is to accelerate a variety of computationally intensive cryptographic algorithms for security protocols in e-commerce applications.

76 Portal Server 6 2005Q1 • Deployment Planning Guide

SRA Sizing

See the Portal Server Sec ure Remote Access 6 Administration Guide for more information on the Sun Crypto Accelerator 1000 board and other accelerators.

NOTE The Sun Crypto Accelerator 1000 board supports only SSL

handshakes and not symmetric key algorithms. This is not generic to all other cryptographic accelerators. Other crypto graphic accelerators are on the market and some of them can support symmetric key encryption. See the following URL for more information:

http://www.zeus .com/p roduct s/zws/s ecurit y/hard ware.h tml

You could use a hardware accelerator on the Netlet Proxy and Rewriter Proxy machine and derive some performance improvement.

SRA and Sun Enterprise Midframe Line

Normally, for a production environment, you would deploy Portal Server and SRA on separate machines. However, in the case of the Sun Enterprise™ midfram e machines, which support multiple hard ware domains, you can instal l both Portal Server and SRA in different domains on the same Sun Enterprise midframe machine. The normal CPU and memory requirements that pertain to Portal Server and SRA still apply; you would implement the requirements for each in the separate domains.

In this type of configuration, pay attention to security issues. For example, in most cases the Portal Server domain is located on the intranet, while the SRA domain is in the DMZ.

Chapter 4 Pre-Deployment Considerations 77

SRA Sizing

78 Portal Server 6 2005Q1 • Deployment Planning Guide

Chapter 5

Creating Your Portal Design

This chapter describes how to create your high-level a nd low-level portal design and provides information on creatin g specif ic sections of your design plan.

This chapter contains the following sections:

• Portal Design Approach

• Portal Server and Scalability

• Portal Server and High Availability

• Portal Server System Communication Links

• Working with Portal Server Bu ild ing Modules

• Designing Portal Use Case Scenarios

• Designing Portal Security Strategies

• Portal Server and Access Manager on Different Nodes

• Designing SRA Deployment Scenarios

• Designing for Localization

• Content and Design Implementation

• Identity and Directory Structure Design

Portal Design Approach

At this point in the Sun Java™ System Portal Server deployment process, you’ve identified your business and technical requirements, and communicated these requirements to the stakeholders for their approval. Now you are ready to begin the design phase, in which yo u d e velop your high- and low-level designs.

Portal Design Approach

Your high-level portal design communicates the architecture of the system and provides the basis for the low-level design of your solution. Further, the high-level design needs to describe a logical architecture that meets the business and technical needs that you previously established. T he logical architecture is broken down according to the various applications that comprise the system as a whole and the way in which users interact with it. In ge neral, the logical architecture includes Portal Server Secure Remote Access (SRA) , high availability, security (including Access Manager, and Directory Server architectural components. See “Logical

Portal Architecture” on page 81 for more information.

The high- and low-level designs also need to account for any factors beyond the control of the portal, including your network, hardware failures, and improper channel design.

Once developed, the high-level design leads toward the creation of the low-level design. The low-level design specifies such items as the physical architecture, network infrastuctu re, Po rt al D es kto p cha nn el an d co nta in er d esi g n an d the act ual hardware and software components. Once you have completed the high- and low-level designs, you can begin a trial d e ployment for testing within your organization.

Overview of High-Level Portal Design

The high-level design is your first iteration of an architecture approach to support both the business and technical requirements. The high-level design addresses questions su c h as:

• Does the proposed architecture support both the busin e ss and technical requirements?

• Can any modifications strengthen this desig n?

• Are there alternative architectures that might accomplish this?

• What is the physical layout of the system?

• What is the mapping of various com p onents and connectivity?

• What is the logical definition describing the different categories of users and the systems and applications users have access to?

• Does the design account for adding more hardware to the system as required by the increase in web traffic over time?

80 Portal Server 6 2005Q1 • Deployment Planning Guide

Portal Design Approach

Overview of Low-Level Portal Design

The low-level design focuses on specifying the processes and standards you use to build your portal solution, and specifying the actual hardware and softwa re components of the solution, including:

• The Portal Server complex of servers.

• Network connectivity, describing how the portal complex attaches to the “outside world.” Within this topic, you need to take into account security issues, protocol s, speeds, and conne c tions to other applications or remote sites.

• Information architecture, including user interfaces, content presentation and organization, d ata sources, and f e eds.

• Access Manager architecture, including the strategy and design of organizations, suborganizations, roles, groups, and users , w hich is critical to long-term success.

• Integration strategy, including how the portal acts as an integration point for consolidating and integrating various information, and bringing people together in new ways.

Logical Portal Architecture

Your logical portal architecture defines all the components that make up the portal, including (but not limited to) the following:

• Portal Server itself

•Contents from RDBMs

• Third-party content providers

• Custom developed providers and content

• Integration with back-end systems such as messaging and calendaring systems

• Web container for deployment

• Role of the Content Management System

• Customer Resource Management

• Whether the portal runs in open or secure mode (requires Secure Remote Access)

Chapter 5 Creating Your Portal Design 81

Portal Design Approach

• Usage estimates, which include your assumptions on the total number of registered users, average percentage of registered users logged in per day, average concurrent users that are logged in per day, average login time, average number of content channels that a logged in user has selected, and average number of application channels that a logged in user has selected.

Additionally, you need to cons id er how the following three network zones fi t into your design:

• Internet. The public Internet is any network outside of the intranet and DMZ. Users portal server and securely access the Gateway and from here.

• Demilitarized Zone (DMZ). A secure area between two firewalls, enabling access to internal resources while limiting po tential for unauthorized entry. The Gateway resides here where it can securely direct traffic from the application and content servers to the Internet.

• Intranet. Contains all resource servers. This includes intranet applications, web content servers, and application servers. The Portal Server and Directory Server reside here.

The logical architecture describes the Portal Desktop look and feel, including potential items such as:

• Default page, with its default banner, logo, channels; total page weight, that is, total number of bytes of all the components of the page, including HTML, style sheet, JavaScript™, and image files; total number of HTTP requests for the page, that is, how many HTTP requests are required to complete downloading the page.

• Personalized pages, with channels that users can conceivably display and what preferences are available.

The logical architecture is where you also develo p a caching strategy, if your site requires one. If the pages returned to your users contain references to large numbers of images, Portal Server can deliver these images for all users. However, if these types of requests can be offloaded to a reverse proxy type of caching appliance, you can free up system resources so that Portal Server can service additional users. Additionally, by placing a caching appliance closer to end users, these images can be delivered to end users somewhat more quickly, thus enhancing the overall end user experience.

82 Portal Server 6 2005Q1 • Deployment Planning Guide

Portal Server and Scalability

Scalability is a system’s ability to accommodate a growing user population, without performance degradation, by the addition of processing resources. The two general means of scaling a system are vertical and horizontal scaling. The subject of this section is the application of scalin g techniques to the Portal Server product.

Benefits of scalable systems include:

•Improved response time

• Fault tolerance

• Manageability

• Expendability

• Simplified application development

• Building modules

Portal Server and Scalab ilit y

Vertical Scaling

In vertical scaling, CPUs, memory, multiple instances of Portal Server, or other resources are added to one machine. This enables more process instances to run simultaneously. In Portal Server, you want to make use of this by planning and sizing to the number of CPUs you need. See Chapter 4, “Pre-Deployment

Considerations” for more information.

Horizontal Scaling

In horizontal scaling, machines are added. This also enables multiple simultaneous processing and a distributed work load. In Portal Server, you make use of horizontal scaling because you can run the Portal Server, Directory Server and Access Manager on different nodes. Horizo ntal scaling can also make use of vertical scaling, by adding more CPUs, for example.

Additionally, you can scale a Portal Server installation horizontally by installing server component instances on multiple ma chines. Each installed server component instance executes an HTTP process, which listens on a TCP/IP port whose number is determined at installation time. Gateway com p onents use a round-robin algorithm to assign new session reque sts to server instances. While a session is established, an HTTP cookie, stored on the client, indicates the session server. All subsequent requests go to that server.

Chapter 5 Creating Your Portal Design 83

Portal Server and High Availability

The section “Working with Portal Server Building Modules” on page 89, discusses an approach to a specific type of configu ration that provides optimum performance and horizont al scalability.

Portal Server and High Availability

High Availability ensures that your portal platform is accessible 24 hours a day, seven days a week. Tod ay, or gani zatio ns req uire that dat a and appli cation s alwa ys be available. High availability has become a requirement that applies not only to mission-critical applications, but also to the whole IT infrastructure.

System availability is affected not only by com p uter hardware and software, but also by people and processes, which can account for up to 80 percen t of system downtime. Availability can be improved through a systematic approach to system management and by using industry best practices to minimize the impact of human error.

One important issue to consider is that not all systems have the same level of availability requirements. Most appl ications can be categorized into the foll owing three groups:

• Task critical. Affects limited number of users; not visible to customers; small impact on costs and profits

• Business critical. Affects significant number of users; might be visible to some customers; significant impact o n costs and profits

• Mission critical. Affects a large number of users; visible to customers; major impact on costs and profits

The goals of these levels are to improve the following:

• Processes by reducing human error, automating procedures, and reducing planned downtime

• Hardware and software availa bility by eliminating single-p oint-of-failure configurations and balancing processing load

The more mission critical the application, the more you need to focus on availability to eliminate any single point of failure (SPOF), and resolve people and processes issues.

Even if a system is always available, instances of failure recovery might not be transparent to end users. Depending on the kind of failure, users can lose the context of their portal application, and might have to login again to get access to their Portal Desktop.

84 Portal Server 6 2005Q1 • Deployment Planning Guide

Portal Server and High Availability

System Availability

System availability is often expressed as a percentage of the system uptime. A basic equation to calculate system availability is:

Availability = uptim e / (u ptime + down time) * 100

For instance, a service level agreement uptime of four digits (99.99 percent) means that in a month the sy stem can be u n avail abl e fo r about s even h ours . F urth ermo re, system downtime is the total time the system is not available for use. This total includes not only unplanned downtime, such as hardware failures and network outages, but also planned downtime, preventive maintena nce, software upgrade, and patches.

If the system is supposed to be available seven d ays a week, 24 hours a day, the architecture needs to include redundancy to avoid planned and unplanned downtime to ensure high availability.

Degrees of High Availability

High availability is not just a switch that you can turn o n a nd of f. Various degrees of high availability refer to the ability of the system to recover from failures and ways of measuring system availability. The degree of high availability depends on your specific organization’s f aul t tolerance requirements and ways of measuring system availability.

For example, your organization might tolerate the need to reauthenticate after a system failure, so that a request resulting in a redirection to another login screen would be considered successful. For other organizations, this might be considered a failure, even though the service is still being provided by the system.

Session failover alone is not the ultimate ans wer to tra nsparent failover, because the context of a particular portal application can be lost after a failover. For example, consider the case where a user is composing a message in NetMail Lite, has attached several documents to the email, then the server fails. The user is redirected to another server and NetMail Lite will have lost the user’s session and the draft message. Other providers, which store contextual data in the current JVM™, have the same problem.

Achieving High Availability for Portal Serve r

Making Portal Server highly available involves ensuring high availability on each of the following c omponents:

Chapter 5 Creating Your Portal Design 85

Portal Server System Communication Links

• Gateway. A load balancer used with the Gateway detects a failed Gateway component and routes new requests to other Gateways. A load balancer also has the ability to intelligently distribute the workload across the server pool. Routing is restored when the fa iled Gateway recovers. Gateway components are stateless (session information is stored on the client in an HTTP cookie) so rerouting around a failed Gateway is transparent to users.

• Portal Server. In open mode, you can use a load balancer to detect a failed server component and redirect requests to other servers. In secure mode, Gateway components can detect the presence of a failed server component and redirect requests to other servers. (This is valid as long as the web container is the Web Server.)

• Directory Server. A number of options make the LDAP directory highly available. See “Building Modules and High Availability Scenarios” on page 90 for more information.

• Netlet and Rewriter Proxies. In the case of a software crash, a watchdog process automatically restarts the proxies. In addition, the Gat eway performs load balancing and failure detection failover for the proxies.

Portal Server System Communication Links

Figure 5-1 on page 87 shows the processes and communication links of a Portal

Server system that are critical to the availability of the solution.

86 Portal Server 6 2005Q1 • Deployment Planning Guide

Figure 5-1 Portal Server Communication Links

Browser Gateway

Portal Server System Communication Links

HTTP(s)

Authentication

Service

(servlet)

LDAP

Module

Access Manager

SSO SDK

LDAP

Authentication

Server

In this figure, the box encloses the Portal Server instance running on Web Server technology. Within the instance are five servlets (Au thentication, Access Manager administration console, Portal Desktop, Communication Channel, and Search), and the three SDKs (Access Manager SSO, Access Manager Logging, and Access Manager Management). The Authentication service servlet also makes use of an LDAP service provider module.

Access Manager

Admin Console

(servlet)

Portal Server instance running on a web container

Portal Desktop

Service

(servlet)

Logging SDK

LDAP

User/Policy/Service

Profile Database Server

Directory Server (LDAP)

Server

Comm Channel

Service (servlet)

Search Service

(servlet)

Access ManagerAccess Manager

Mgmt SDK

SMTP/IMAP

Messaging

Server

A user uses either a browser or the Gateway to communicate with Portal Server. This traffic is directed to the appropriate servlet. Communication occurs between the Authentication service’s LDAP module and the LDAP authentication server; between the Communications channel servlet and the SMTP/IMAP messaging server; between the Access Manager SSO SDK and the LDAP server; and between the Access Manager Management SDK and the LDAP server.

Chapter 5 Creating Your Portal Design 87

Portal Server System Communication Links

• Figure 5-1 on page 87 shows that if the following processes or com munication links fail, the portal solution becomes unavailable to end users: Portal Server Instance. Runs in the context of a web container. Components within an instance communicate through the JVM™ using Java™ APIs. An instance is a fully qualifie d domain name and a TCP port nu mber. Portal Server services are web applications that are implemented as servlets or JSP™ files.

Portal Server is built on top of Access Ma nager for authentication single sign-on (session) management, policy, and profile database access. Thus, Portal Server inherits all the benefits (and constraints) of Access Manager with respect to availability and fault tolerance.

By design, Access Manager’s services are either stateless or the services can share context data. Services can recover to the previous state in case of a service failure.

Within Portal Server, Portal Desktop and NetMail services do not share state data among instances. This means th at an instance redirect causes the user context to be rebuilt for the enabled services. Usually, redirected users do not notice this because Portal Server services can rebuild a user context from the user’s profile, and by using contextual data s tored in the request. While this statement is generally true for out-of-the-box services, it might not be true for channels or custom code. Developers need to be careful to not design stateful channels to avoid loss of context upo n instance failover.

• Profile Database Server. The profile database server is implemented by Directory Server software. Although this serv er is not strictly part of Portal Server, availability of the server and integrity of the database are fundamental to the availability of the system.

• Authentication Server. This is the directory server for LDAP authentication (usually, the same server as the profile database server). You can apply the same high availability techniques to this se rver as for the profile d atabase server.

• SRA Gateway and Proxies. The SRA Gateway is a standalone Java technology process that can be considered stateless, because state information can be rebuilt transparently to end users. The Gateway profile maintains a list of Portal Server instances and does round robin load balancing acro ss the Gateway instances. Session stickiness is not required in front of a Gateway, but with session stickiness, performance is better. On the other hand, session stickiness to Portal Server instances is enforced by SRA.

88 Portal Server 6 2005Q1 • Deployment Planning Guide

Working with Portal Serve r Build i ng Mo dule s

SRA includes other Java technology pro ces ses called Netlet Proxy and Rewriter Proxy. You use these proxies to extend the security perimeter from behind the firewall, and limit the number of holes in the DMZ. You can install these proxies on separate node s.

Working with Portal Server Building Modules

Because deploying Portal Server is a complex process involving many other systems, this section describes a specific configuration that provides optimum performance and horizontal scalability. This configu ration is known as a Portal Server building module.

A Portal Server building module is a hardware and software construct with limited or no dependencies on shared services. A typical deployment uses multiple building modules to achieve optimum performance and horizontal scalability.

Figure 5-2 shows the building module architecture.

Figure 5-2 Portal Server Building Module Architecture

Portal

Server

Instance

Engine

Database

SSe

Directory Server Master Replica

SSe

NOTE The Portal Server building module is simply a recommende d

configuration. In so me cases, a different configuration might result in slightly better throughput (usually a t the cost of added complexity). For example, adding another instance of Portal Server to a four CPU system might result in up to ten percent additional throughput, at the cost of requiring a load balancer even when using just a single system.

Chapter 5 Creating Your Portal Design 89

Working with Portal Serve r Build i ng Mo dule s

Building Modules and High Avail abil ity Sc enari os

Portal Server provides three scenarios for high availability:

• Best Effort The system is available as long as the hardware does not fail and as long as the

Portal Server processes can b e resta r te d by the watchdog process.

• No Single Point of Failure The use of hardware and software replication creates a deployment with no

single point of failure (NSPOF). The system is always available, as long as no more than one failure occurs consecutively anywhere in the chain of components. However, in the case of failures, user sessions are lost.

• Transparent Failover The system is always available but in addition to NSPOF, failover to a backup

instance occurs transparently to end users. In most cases, users do not notice that they have been redirected to a different node or instance. Sessions are preserved across nodes so that users do not have to reauthenticate. Portal Server services are stateless or use checkpointing mechanisms to rebuild the current execution co ntext up to a certain point.

Possible supported architectures include the following:

• Using Sun™ Cluster software on components that support Sun Cluster agents

• Multi-master Directory Server techniques

This section explains implementing these architectures and leverages the building module concept, from a high-avail ability standpoint.

90 Portal Server 6 2005Q1 • Deployment Planning Guide

Table 5-1 summarizes these high availability scenarios along with their supporting

techniques.

Table 5-1 Portal Server High Availability Scenarios

Component Requirements

Hardware Redundancy Yes Yes Yes

Necessary for Best Effort Deployment?

Necessary for NSPOF Deployment?

Necessary for Transparent Failover Deployment?

Working with Portal Serve r Build i ng Mo dule s

Portal Server Building Modules

Multi-master Configuration No Yes Yes Load Balancing Yes Yes Yes Stateless Applications and

Checkpointing Mechanisms

Session Failover No No Yes. Directory Server Clustering No No Yes

No Yes Yes

No No Yes

NOTE Load balancing is not provided out-of-th e -bo x with the Web Server

product.

Chapter 5 Creating Your Portal Design 91

Working with Portal Serve r Build i ng Mo dule s

Best Effort

In this scenario, you install Portal Server and Directory Server on a single node that has a secured hardware configuration for continuous availability, such as S un Fire UltraSPARC® III machines. (Securing a Solaris™ Operating Environment system requires that changes be made to its default configuration.)

This type of server features full hardware redundancy, including: redundant power supplies, fans, system controllers; dynamic reconfiguration; CPU hot-plug; online upgrades; and disks rack that can be configured in RAID 0+1 (striping plus mirroring), or RAID 5 using a volume management system, which prevents loss of data in case of a disk crash. Figure 5-3 show s a small, best effort deployment using the building module architecture.

Figure 5-3 Best Effort Scenario

Browser

Portal

Server

Engine

Database

SSe

Directory Server

In this scenario, for memory allocation, four CPUs by eight GB RAM (4x8) of memory is sufficient for one building module. The Access Manager console is outside of the building module so that it can be shared with other resources. (Your actual sizing calculations might result in a different allocation amount.)

This scenario might suffice for task critical requirements. Its major weakness is that a maintenance action necessitating a system shutdown results in service interruption.

When SRA is used, and a software crash occurs, a watchdog process automatically restarts the Gateway, Netlet Proxy, and Rewriter Proxy.

92 Portal Server 6 2005Q1 • Deployment Planning Guide

No Single Point of Failure

Portal Server natively supports the no single point of failure (NSPOF) scenario. NSPOF is built on top of the best effort scenario, and in addition, introduces replication and load balancing.

Figure 5-4 No Single Point of Failure Example

Building Module 1

Working with Portal Serve r Build i ng Mo dule s

Client

Load

Balancer

Portal

Server

Instance

Search Engine

Database

Building Module 2

Portal

SSe

Server

Directory Server Master Replica

Multi-Master Replication

Directory Server Master Replica

Engine

Database

SSe

Chapter 5 Creating Your Portal Design 93

Working with Portal Serve r Build i ng Mo dule s

As stated earlier, a building module consists o f a a Portal Server instance, a Directory Server master replica for profile reads and a search engine database. As such, at least two building modules are necessary to achieve NSPOF, thereby providing a backup if one of the building m odules fails. These building modules consist of four CPUs by eight GB RAM.

When the load balancer detects Portal Server failures, it redirects users’ requests to a backup building module. Accuracy of failure detection varies among load balancing products. Some products are capable of checking the availability of a system by probing a service involving several functional areas of the server, such as the servlet engine, and the JVM. In particular , most vendor solutions from Resonate, Cisco, Alteon, and others enable you to create arbitrary scripts for server availability. As the load balancer is not part of the Portal Server software, you must acquire it separately from a th ird -party vendor.

NOTE The Access Manager product requires that you set up load

balancing to enforce sticky sessions. This means that once a session is created on a particular instance, the load balancer needs to always return to the same instance for that session. The load balancer achieves this by binding the session cookie with the instance name identification. In principle, that bindin g is reestablished when a failed instance is decommissioned. Sticky se ssions are also recommended for performance reasons.

Multi-master replication (MMR) takes places between the building modules. The changes that occur on each directory are replicated to the other, which means that each directory plays both roles of supplier and consumer. For more information on MMR, refer to the Directory Server 6 Deployment Guide.

NOTE In general, the Directory Server instance in each building module is

configured as a replica of a master directory, which runs elsewhere. However, nothing prevents you from using a master directory as part of the building module. The use of masters on dedicated nodes does not improve the availability of the solution. Use dedica ted masters for performance reasons.

94 Portal Server 6 2005Q1 • Deployment Planning Guide

Working with Portal Serve r Build i ng Mo dule s

Redundancy is equally importan t to the directory master so that profile changes through the administration console or the Portal Desktop, along with consumer replication across building modules, can always be maintained. Portal Server and Access Manager support MMR. The NSPOF scenario uses a multi-master configuration. In this configuration, two suppliers can accept updates, synchronize with each other, and update all consumers. The consumers can refer update requests to both masters.

SRA follows the same replication and load balancing pattern as Portal Server to achieve NSPOF. As such, two SRA Gateways and pair of proxies are necessary in this scenario. The SRA Gateway detects a Portal Server instance failure when the instance does not respond to a request after a certain time-out value. When this occurs, the HTTPS request is routed to a backup server. The SRA Gateway performs a periodic check for availability until the first Portal Server instance is up again.

The NSPOF high availabilit y scenario is suitable to business critical deployments. However, some high availabi lity limitations in this sc enario might not fulfill the requirements of a mission critical deployment.

Chapter 5 Creating Your Portal Design 95

Working with Portal Serve r Build i ng Mo dule s

Transparent Failover

Transparent failover uses the same replication model as the NSPOF scenario but provides additional high availability features, which make the failover to a backup server transparent to end users.

Figure 5-5 on page 96 shows a transparent failover scenario. Two building modules

are shown, consisting of four CPUs by eight GB RAM. Load balancin g is responsible for detecting Portal Server failures and redirecting users’ requests to a backup Portal Server in the building mod ule. B uilding Module 1 stores sessions in the sessions repository. If a crash occurs, the application server retrieves sessions created by Building Module 1 from the sessions repository.

Figure 5-5 Transparent Failover Example Scenario

Browser

Load

Balancer

Building Module 1

Portal

Server

Instance

Search Engine

Database

SSe

Building Module 2

Portal

Server

Instance

Directory Server Master Replica

Multi-Master Replication

Sessions

Repository

Directory Server Master Replica

96 Portal Server 6 2005Q1 • Deployment Planning Guide

Search Engine

Database

SSe

Working with Portal Serve r Build i ng Mo dule s

The session repository is provided by the application server software. Portal Server is running in an application server. Portal Server supports transparent failover on application servers that support HttpSession failover. See Appendix C, “Portal

Server and Application Servers” for more information.

With session failover, users do not need to reauthenticate after a crash. In addition, portal applications can rely on session persistence to store context data used by the checkpointing. You configure session failover in the setting the

The Netlet Proxy cannot support the transparent failover scenario because of the limitation of the TCP protocol. The Netlet Proxy tunnels TCP connections, and you cannot migrate an open TCP connection to another server. A Netlet Proxy crash drops off all outstanding connection s that would have to be reestablished.

com.iplanet.am.session.failover.enabled property to

AMConfig.properties file by

true

Building Module Constraints

The constraints on the scalability of building modules are given by the number of LDAP writes resulting from profile u p dates a nd the maximum size of the LDAP database. For more information, see “Directory Server Requirements” on page 98.

NOTE If the LDAP server crashes with the

the files are lost when the server restarts. This improves performance but also affects availability.

If the analysis at your specific site indicates that the number of LDAP write operations is indeed a constraint, some of the possible solutions include creating building modules that replicate only a specific branch of the directory and a layer in front that directs incoming requests to the appropriate ins tance of portal.

_db files in the /tmp directory,

Deploying Your Building Module Solution

This section describes guidelines for de ploying your building mod ule solution.

Deployment Guidelines

How you construct your building modue affects performance. Consider the following recommendation s to deploy your building module p rop erly:

• Deploy a building module on a single machine.

Chapter 5 Creating Your Portal Design 97

Working with Portal Serve r Build i ng Mo dule s

• If you use multiple machines, or if your Portal Server machine is running a large number of instances, use a fast network interconnect.

• On servers with more than eight CPUs, create processor sets or domains with either two or four CPUs. For example, if you cho ose to install two instances of Portal Server on an eight CPU server, create two four-CPU processor sets.

Directory Server Requirements

Identify your Directory Server requirements for your building module deployment. For specific information on Directory Server deployment, see the Directory Serv er Deployment Guide.

Consider the following Directory Server gu id elines when you plan your Portal Server deployment:

• The amount of needed CPU in the Directory Server consumer replica processor set depends on the number of Portal Server instances in the building module as well as performance and capacity considerations.

• If possible, dedicate a Directory Server instance for the sole use of the Portal Server instances in a building module. (See Figure 5-2 on page 89.)

• Map the entire directory database indexes and cache in memory to avoid disk latency issues.

• When deploying multiple building modules, use a multi-master confi guration to work around bottlenecks caused by the profile updates and replication overhead to the Directory Server supplier.

Search Engine Structure

When you deploy the Search Engine as part of your building module solution, consider the following:

• In each building module, make sure only o ne Po rt al Server instance has the Search Engine database containing the RDs. The remaining Portal Server instances have default empty Search Engine databases.

• Factors that influence whether to use a building module for the portal Search database include the intensity of search ac tivities in a Portal Server deployment, the range of search hits, and the average number of search hits for all users, in addition to the number of concurrent searches. For example, the load generated on a server by the Search Engine can be both memory and CPU intensive for a large index and heavy query loa d .

98 Portal Server 6 2005Q1 • Deployment Planning Guide

Designing Portal Use Case Scen ario s

• You can install Search on a machine separate from Portal Server, to keep the main server dedicated to portal activity. When you do so, you use the

searchURL property of the Search provider to point to the second machine

where Search is installed. The Search instance is a normal portal instance. You install the Search instance just as you do the portal instance, but use it just for Search functionality.

• The size of the Search database dictates whether more than one machine needs to host the Search database by replicating it across machines or building module. Consider using high-end di sk arrays.

• Use a proxy server for caching the search hit results. When doing so, you need to disable the document level security. See the Portal Server 6 Administration Guide for more information on document level security.

Designing Portal Use Case Scenarios

Use case scenarios are written scenarios used to test and present the system’s capabilities and form an important part of your high-level design. Though you implement use case scenarios toward the end of the project, formulate them early on in the project, once you have established your requirements.

When available, use cases can provide valuable insight into how the system is to be tested. Use cases are beneficial in identifying how you need to design the user interface from a navigational perspective. When designing use cases, compare them to your requirements to get a thorough view of their completeness and how you are to interpret the test results.

Use cases provide a method for organizing your requirements. Instead of a bulleted list of requirements, you orga nize them in a way that tells a story of how someone can use the system. This provides for greater completeness and consistency, and also gives you a better un d e rstanding of the importance of a requirement from a user perspective.

Use cases help to identify and clarify the functional requirements of the portal. Use cases capture all the different ways a portal would be used, including the set of interactions between the user and the portal as well as the services, tasks, and functions the portal is required to perform.

A use case defines a goal-oriented set of interactions between external actors and the portal system. (Actors are parties outside the system that interact with the system, and can be a class of users, roles users can play, or other systems.)

Chapter 5 Creating Your Portal Design 99

Designing Portal Use Case Scenarios

Use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain.

Use case scenarios are an instance of a use case, representing a single path through the use case. Thus, there may be a scenario for the main flow through the use case and other scenarios for each possible variation of flow through the use case (for example, representing each option).

Elements of Por ta l Us e Ca s es

When developing use cases for your portal, keep the following elements in mind:

• Priority. Describes the priority, or ranking of the use case. For example, this

could range from High to Medium to Low.

• Context of use. Describes the setting or environment in which the use case

occurs.

• Scope. Describes the conditions and limits of the use ca se.

• Primary user. Describes what kind of user this applies to, for example, an end

user or an administrator.

• Special requirements. Describes any other conditions that apply.

•Stakeholders. Describes the people who have a "vested interest" in how a

product decision is made or carried out.

• Precondition. Describes the prerequisites that must be met for the use case to

occur.

• Minimal guarantees. Describes the minimum that must occur if the use case is

not successfully completed.

• Success guarantees. Describes what happens if the use case is successfull y

completed.

• Trigger. Describes the particular item in the system that causes the event to

occur.

• Description. Provides a step-by-step account of the use case, from start to

finish.

100 Portal Server 6 2005Q1 • Deployment Planning Guide

Sun Microsystems Sun Java System 2005Q1 Portal Server 6, Portal Server 6 2005Q1 Planning Manual

Specifications and Main Features

Frequently Asked Questions

User Manual