Wsplam3508d SW 5

OpenSSO Deployment
WSPL-AM-3508-D
Student Workbook for Self-Paced Lab Users
Sun Microsystems, Inc.

500 Eldorado Blvd.
MS UBRM05-104
Broomfield, CO 80021
U.S.A.
Revision A.0.4
September 9, 2008 11:19 am
Copyright 2008 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved.
This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and
decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of
Sun and its licensors, if any.
Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.
Sun, Sun Microsystems, the Sun logo, Sun Java, Java, JavaScript, JavaServer Pages, JDK, JSP, JVM, J2SE, J2EE, GlassFish, and Solaris are
trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
Mozilla is a trademark or registered trademark of Netscape Communications Corporation in the United States and other countries.
UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.
Federal Acquisitions: Commercial Software – Government Users Subject to Standard License Terms and Conditions
Export Laws. Products, Services, and technical data delivered by Sun may be subject to U.S. export controls or the trade laws of other
countries. You will comply with all such laws and obtain all licenses to export, re-export, or import as may be required after delivery to
You. You will not export or re-export to entities on the most current U.S. export exclusions lists or to any country subject to U.S. embargo
or terrorist controls as specified in the U.S. export laws. You will not use or provide Products, Services, or technical data for nuclear, missile,
or chemical biological weaponry end uses.
DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND
WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE
LEGALLY INVALID.
THIS MANUAL IS DESIGNED TO SUPPORT AN INSTRUCTOR-LED TRAINING (ILT) COURSE AND IS INTENDED TO BE
USED FOR REFERENCE PURPOSES IN CONJUNCTION WITH THE ILT COURSE. THE MANUAL IS NOT A STANDALONE
TRAINING TOOL. USE OF THE MANUAL FOR SELF-STUDY WITHOUT CLASS ATTENDANCE IS NOT RECOMMENDED.
Export Commodity Classification Number (ECCN) assigned: 11 August 2008
Please
Recycle
Copyright 2008 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, Etats-Unis. Tous droits réservés.
Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la copie, la distribution,
et la décompilation. Aucune partie de ce produit ou document ne peut être reproduite sous aucune forme, par quelque moyen que ce soit,
sans l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a.
Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un copyright et licencié
par des fournisseurs de Sun.
Sun, Sun Microsystems, le logo Sun, Sun Java, Java, JavaScript,, JavaServer Pages, JDK, JSP, JVM, J2SE, J2EE, GlassFish, et Solaris sont des
marques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays.
Mozilla est une marque de Netscape Communications Corporation aux Etats-Unis et à d'autres pays.
UNIX est une marques déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company, Ltd.
Législation en matière dexportations. Les Produits, Services et données techniques livrés par Sun peuvent être soumis aux contrôles
américains sur les exportations, ou à la législation commerciale dautres pays. Nous nous conformerons à lensemble de ces textes et nous
obtiendrons toutes licences dexportation, de ré-exportation ou dimportation susceptibles dêtre requises après livraison à Vous. Vous
nexporterez, ni ne ré-exporterez en aucun cas à des entités figurant sur les listes américaines dinterdiction dexportation les plus courantes,
ni vers un quelconque pays soumis à embargo par les Etats-Unis, ou à des contrôles anti-terroristes, comme prévu par la législation
américaine en matière dexportations. Vous nutiliserez, ni ne fournirez les Produits, Services ou données techniques pour aucune utilisation
finale liée aux armes nucléaires, chimiques ou biologiques ou aux missiles.
LA DOCUMENTATION EST FOURNIE “EN L’ETAT” ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET GARANTIES
EXPRESSES 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
UTILISATION PARTICULIERE OU A L’ABSENCE DE CONTREFAÇON.
CE MANUEL DE RÉFÉRENCE DOIT ÊTRE UTILISÉ DANS LE CADRE D’UN COURS DE FORMATION DIRIGÉ PAR UN
INSTRUCTEUR (ILT). IL NE S’AGIT PAS D’UN OUTIL DE FORMATION INDÉPENDANT. NOUS VOUS DÉCONSEILLONS DE
L’UTILISER DANS LE CADRE D’UNE AUTO-FORMATION.
Please
Recycle
Table of Contents
About This Workbook .................................................. Lab Preface-ix
Lab Goals........................................................................ Lab Preface-ix
Conventions ......................................................................Lab Preface-x
Icons ..........................................................................Lab Preface-x
Typographical Conventions ....................................... Preface-xi
Additional Conventions...................................... Lab Preface-xii
Preparing an Environment for a Complex OpenSSO Deployment ...
Lab 1-1
Objectives .................................................................................... Lab 1-1
Exercise 1: Logging in to, Starting Zones on, and Navigating
Around the Learning Virtual Machine .................................Lab 1-2
Preparation..........................................................................Lab 1-2
Task – Navigating Around The Learning VM...............Lab 1-5
Exercise 2: Installing and Configuring Apache Tomcat for Use as an
OpenSSO Web Container........................................................Lab 1-9
Preparation........................................................................Lab 1-10
Task 1 – Installing Tomcat Software .............................Lab 1-10
Task 2 – Configuring Tomcat Port Numbers ...............Lab 1-11
Task 3 – Modifying Tomcat Start Pages .......................Lab 1-12
Task 4 – Starting and Stopping Tomcat Instances.......Lab 1-13
Exercise 3: Securing the Tomcat Instances ............................Lab 1-16
Preparation........................................................................Lab 1-16
Task 1 – Creating a Certificate Database and a Local CA
Certificate .......................................................................Lab 1-17
Task 2 – Creating Java Key Stores for Each Tomcat Instance...
Lab 1-19
Task 3 – Creating Server Certificates for Each Instance .....Lab
1-21
Task 4 – Signing and Storing the Server Certificates ..Lab 1-24
Task 5 – Configuring Tomcat for SSL Access ..............Lab 1-26
Task 6 – Preparing the JVM Key Store for OpenSSO
Configuration ................................................................Lab 1-28
Task 7 – Testing SSL Access ...........................................Lab 1-29
v
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Sun Services, Revision A.0.4
Exercise 4: Installing, Securing and Configuring a Software-Based
Load Balancer .........................................................................Lab 1-31
Preparation........................................................................Lab 1-31
Task 1 – Installing Web Server 7.0 .................................Lab 1-32
Task 2 – Installing the Local CA Certificate in the Web Server
Instance...........................................................................Lab 1-33
Task 3 – Obtaining and Installing a Server Certificate for the
Web Server Instance .....................................................Lab 1-35
Task 4 – Configuring and Securing a New Listener Port...Lab
1-37
Task 5 – Configuring and Testing the Load Balancer.Lab 1-39
Exercise Summary.....................................................................Lab 1-42
Deploying a Multi-Instance OpenSSO Site .............................Lab 2-1
Objectives .................................................................................... Lab 2-1
Exercise 1: Deploying a Multi-Instance OpenSSO Site..........Lab 2-2
Preparation..........................................................................Lab 2-3
Task 1 – Modifying the Web Container Configuration as
Specified in the Release Notes .........................................Lab 2-7
Task 2 – Deploying the OpenSSO Web Archive File on the
Two Tomcat Instances..................................................Lab 2-10
Task 3 – Configuring OpenSSO on the First Tomcat Instance .
Lab 2-11
Task 4 – Configuring OpenSSO on the Second Tomcat
Instance...........................................................................Lab 2-15
Task 5 – Testing the Load-Balanced, Multi-Instance OpenSSO
Deployment ...................................................................Lab 2-18
Exercise 2: Setting Up the OpenSSO Command-Line Tools.......Lab
2-20
Preparation........................................................................Lab 2-20
Task – Installing and Testing the famadm
Command-Line Interface .............................................Lab 2-20
Configuring Session Failover ..................................................Lab 3-1
Objectives .................................................................................... Lab 3-1
Exercise 1: Configuring Session Failover for an OpenSSO Site..Lab
3-2
Preparation..........................................................................Lab 3-3
Task 1 – Installing the Session Failover Tools................Lab 3-7
Task 2 – Encrypting the Message Queue Password .....Lab 3-9
Task 3 – Configuring Settings in the amsfo.conf File.......Lab
3-10
Task 4 – Adding a Secondary Configuration Instance to the
Session Service...............................................................Lab 3-11
Exercise 2: Verifying that OpenSSO Sessions Fail Over......Lab 3-13
Preparation........................................................................Lab 3-13
vi OpenSSO Deployment
Task 1 – Starting the Message Queue Broker and Restarting
Servers ............................................................................Lab 3-13
Task 2 – Testing Session Failover ..................................Lab 3-15
Task 3 – Disabling Session Failover...............................Lab 3-18
Installing a Web Policy Agent to Manage Access to a Web Site Lab
4-1
Objectives .................................................................................... Lab 4-1
Exercise 1: Deploying a Web Server Instance That Hosts a Web Site
Lab 4-2
Preparation..........................................................................Lab 4-3
Task 1 – Copying the Local CA Certificate Into the zone2
Zone ..................................................................................Lab 4-7
Task 2 – Installing Web Server Software ........................Lab 4-8
Task 3 – Installing the Local CA Certificate Into the Web
Server Instance ..............................................................Lab 4-10
Exercise 2: Preparing the Environment for the Web Policy Agent
Installation...............................................................................Lab 4-12
Preparation........................................................................Lab 4-12
Task 1 – Preparing the JVM Key Store for Policy Agent
Installation......................................................................Lab 4-13
Task 2 – Creating an Agent Administrator ..................Lab 4-14
Task 3 – Logging in as the Agent Administrator and Creating
an Agent Profile.............................................................Lab 4-17
Task 4 – Copying the Policy Agent Software and Create a
Password File for the Agent Profile ...........................Lab 4-19
Exercise 3: Installing and Testing the Web Policy Agent....Lab 4-20
Preparation........................................................................Lab 4-20
Task 1 – Installing the Web Policy Agent Software ....Lab 4-20
Task 2 – Restarting Servers.............................................Lab 4-22
Task 3 – Testing the Web Policy Agent.........................Lab 4-22
Installing a J2EE Policy Agent to Manage Access to J2EE
Applications .............................................................................. Lab 5-1
Objectives .................................................................................... Lab 5-1
Exercise 1: Deploying a GlassFish Application Server Instance Lab
5-2
Preparation..........................................................................Lab 5-3
Task 1 – Installing GlassFish Application Server SoftwareLab
5-7
Task 2 – Installing the Local CA Certificate Into the Domain
Administration Server Key Store..................................Lab 5-9
Exercise 2: Preparing the Environment for the J2EE Policy Agent
Installation...............................................................................Lab 5-11
Preparation........................................................................Lab 5-11
vii
Task 1 – Logging in as the Agent Administrator and Creating
an Agent Profile.............................................................Lab 5-12
Task 2 – Copying the Policy Agent Software and Creating a
Password File for the Agent Profile ...........................Lab 5-13
Exercise 3: Installing and Testing the J2EE Policy Agent....Lab 5-14
Preparation........................................................................Lab 5-14
Task 1 – Installing the J2EE Policy Agent Software ....Lab 5-14
Task 2 – Deploying the Agent Application ..................Lab 5-16
Task 3 – Deploying the Sample Application................Lab 5-16
Task 4 – Testing the J2EE Policy Agent ........................Lab 5-17
viii OpenSSO Deployment

Preface
About This Workbook
Lab Goals
Upon completion of this workbook, you should be able to:
● Log in to, start zones on, and navigate around the learning virtual
machine
● Install and configure Apache Tomcat (Tomcat) for use as an
OpenSSO web container
● Secure Tomcat instances
● Install, secure, and configure a software-based load balancer
● Deploy a multi-instance OpenSSO site
● Set up the OpenSSO command-line tools
● Configure session failover for an OpenSSO site
● Verify that OpenSSO sessions fail over
● Deploy a Web Server instance that hosts a web site
● Prepare the environment for the Web Policy Agent installation
● Install and test the Web Policy Agent
● Deploy a GlassFish™ application server instance
● Prepare the environment for the Java™ 2 Platform, Enterprise
Edition (J2EE™) Policy Agent installation
● Install and test the J2EE Policy Agent
Preface-ix
Conventions
Conventions
The following conventions are used in this course to represent various
training elements and alternative learning resources.
Icons
Additional resources – Indicates other references that provide additional

information on the topics described in the module.
Discussion – Indicates a small-group or class discussion on the current

topic is recommended at this time.
!
?
Note – Indicates additional information that can help students but is not
crucial to their understanding of the concept being described. Students
should be able to understand the concept or complete the task without
this information. Examples of notational information include keyword
shortcuts and minor system adjustments.
Caution – Indicates that there is a risk of personal injury from a

nonelectrical hazard, or risk of irreversible damage to data, software, or
the operating system. A caution indicates that the possibility of a hazard
(as opposed to certainty) might happen, depending on the action of the
user.
Preface-x OpenSSO Deployment

Conventions
Typographical Conventions
Courier is used for the names of commands, files, directories,
programming code, and on-screen computer output; for example:
Use ls -al to list all files.
system% You have mail.
Courier is also used to indicate programming constructs, such as class

names, methods, and keywords; for example:
The getServletInfo method gets author information.
The java.awt.Dialog class contains Dialog constructor.
Courier bold is used for characters and numbers that you type; for
example:
To list the files in this directory, type:
# ls
Courier bold is also used for each line of programming code that is
referenced in a textual description; for example:
1 import java.io.*;
2 import javax.servlet.*;
3 import javax.servlet.http.*;
Notice the javax.servlet interface is imported to allow access to its
life cycle methods (Line 2).
Courier italics is used for variables and command-line placeholders

that are replaced with a real name or value; for example:
To delete a file, use the rm filename command.
Courier italic bold represents variables whose values are to be

entered by the student as part of an activity; for example:
Type chmod a+rwx filename to grant read, write, and execute
rights for filename to world, group, and users.
Palatino italics is used for book titles, new words or terms, or words that
you want to emphasize; for example:
Read Chapter 6 in the User’s Guide.
These are called class options.
About This Workbook Preface-xi

Conventions
Additional Conventions
Java programming language examples use the following additional
conventions:
● Courier is used for the class names, methods, and keywords.
● Method names are not followed with parentheses unless a formal or
actual parameter list is shown; for example:
“The doIt method...” refers to any method called doIt.
“The doIt() method...” refers to a method called doIt that takes
no arguments.
● Line breaks occur only where there are separations (commas),
conjunctions (operators), or white space in the code. Broken code is
indented four spaces under the starting code.
Preface-xii OpenSSO Deployment

Lab 1
Preparing an Environment for a Complex

OpenSSO Deployment
Objectives
Upon completion of this lab, you should be able to:
● Log in to, start zones on, and navigate around the learning virtual
machine
● Install and configure Apache Tomcat (Tomcat) for use as an
OpenSSO web container
● Secure Tomcat instances
● Install, secure, and configure a software-based load balancer
Lab 1-1
Exercise 1: Logging in to, Starting Zones on, and Navigating Around the Learning
Exercise 1: Logging in to, Starting Zones on, and

Navigating Around the Learning Virtual Machine
In this exercise, you explore your lab system and review software binaries
and student files that are available on this system.
Preparation
The following section contains information you need and describes
actions you take prior to proceeding to the first task in this exercise.
Prerequisite Labs
There are no prerequisite labs for performing this lab.
Task 1 – Assessing the State of Your Lab System
In this task, you assess the state of your lab system.
Your lab system can be in one of two states defined in Table 1-1 on
page L1-2. Determine which of these two states describes your lab system.
Then, depending on the state of your lab system, follow the instructions
in the table.
Table 1-1 Lab System Start States and Instructions
Lab System
Description Instructions
State
First Time • You installed the learning Perform the steps in the
Doing Labs virtual machine on your section, ‘‘Task 2 –
system Starting the Learning
Virtual Machine’’ on
• You have not done any page L1-3.
labs on the learning
virtual machine
Not at You completed other labs in Perform the steps in the

Starting the learning virtual machine, section, ‘‘Task 3 –
Point and now you want to come Bringing the Learning
back and do this lab Virtual Machine to the
Starting Point for This
Lab’’ on page L1-3.
Lab 1-2 OpenSSO Deployment

Task 2 – Starting the Learning Virtual Machine
Perform the following steps:

1. Start your VMware software.
2. Power up the learning virtual machine.
3. Log in to the Solaris OS as the root user. The password is cangetin.
Caution – When possible, examples in this course demonstrate security

best practices. However, your own specific security requirements might
be more stringent than the techniques followed in this course. Do not
assume that the techniques demonstrated in this course meet your security
requirements.
For your convenience, most of the passwords used in this class have the
same value: cangetin. Setting system passwords to the same value is not
a security best practice.
4. Prepare the whole root zone zone1 for doing lab exercises:
global # lab -p
5. Perform the steps in ‘‘Task 4 – Starting the zone1 Zone’’ on
page L1-4.
Task 3 – Bringing the Learning Virtual Machine to the Starting

Point for This Lab

1. Start your VMware software, if necessary.
2. Power up the learning virtual machine, if necessary.
3. Log in to the Solaris OS as the root user, if necessary. The password
is cangetin.
4. Start a terminal window, if necessary.
5. If you are logged in to the zone1 zone, log out of this zone and stop
the zone:
a. Log out of the zone1 zone:
zone1 # exit
b. Stop the zone1 zone:
global # zoneadm -z zone1 halt
Preparing an Environment for a Complex OpenSSO Deployment Lab 1-3

6. Run the lab -n command, which brings the learning virtual

machine to the starting point for this lab:
global # lab -n 1
Progress messages appear in the terminal window as the lab -n
command restores the learning virtual machine’s state to the starting
point for this lab.
Note – In many cases, the lab -n command processes large quantities of

data. Therefore, this command might require a significant amount of time
to complete.
7. Prepare the learning VM zones for doing these lab exercises:

global # lab -p
8. Perform the steps in the section, ‘‘Task 4 – Starting the zone1 Zone’’
on page L1-4.
Task 4 – Starting the zone1 Zone

1. Boot the zone1 zone:
global # zoneadm -z zone1 boot
2. Log in to the zone1 zone:
global # zlogin zone1
The zone1 # prompt appears, indicating that you have successfully
logged into the zone1 zone.
3. If your lab system requires a proxy server to access the Internet,
configure the proxy server address in the Firefox browser.
Your lab system is now ready for the lab. Proceed to ‘‘Task – Navigating
Around The Learning VM’’ on page L1-5.

Task – Navigating Around The Learning VM

In this task, you explore your lab system and review software binaries
and student files that are available on this system.
Complete the following steps:

1. Open a terminal window (if necessary).
2. Make sure that you are logged in to the zone1 zone.
The prompt in the terminal window indicates which zone you are
logged into. For example:
zone1 #
Caution – If you skipped ‘‘Preparation’’ on page L1-2, please go back now

and follow these instructions. They are critical to your success in this self-
paced format. The Preparation activity explains how to work with the
learning VM’s zones, how to make networking work in this environment,
and how to set the state of the learning VM to the starting point for this
lab.
3. Change to the /opt/ses/shared/software directory:

cd /opt/ses/shared/software

4. List the content in the /opt/ses/shared/software directory:

ls
The following subdirectories are present:
agent-v3.20080627-appserver-v9
agent-v3.20080627-webserver-v7
apache-tomcat-6.0.14
glassfish-v2ur2
opensso-v1b4.5
webserver-v7u2
The subdirectory names indicate the name and version numbers of
software that has been downloaded to the learning VM and
unzipped for your use with these labs.
Note – Four zones are available on the learning VM. The

/opt/ses/shared/software directory is available as a read-only
directory from all four zones.
If you would like to learn how a directory can be shared as a read-only

directory among multiple zones, log in to the global zone, change to the
/etc/zones directory, and review the zone configuration files zone1.xml,
zone2.xml, zone3.xml, and zone4.xml.
5. Review the following locations from which software was

downloaded for this course:
a. Start a web browser:
firefox &
Note – The learning VM is configured so that you can start a web browser
from any zone, and so that networking works in any zone. If you attempt
to start a web browser, but no browser window appears, you have most
likely not run the lab -p command in the global zone before running the
zlogin command to log in to a whole root zone.

b. Using the browser, navigate to the locations from which

binaries were downloaded for these labs to familiarize yourself
with the download sites:
● Subdirectory – /opt/ses/shared/software/agent-
v3.20080627-appserver-v9
Software – Sun OpenSSO Policy Agent 3.0 for Sun Java
System Application Server 9.0 (Policy Agent for
Application Server)
URL – https://opensso.dev.java.net
Note – Under some conditions, JavaScript™ code stalls the OpenSSO site
when running in Firefox in the learning VM. If the OpenSSO site does not
render when you navigate to the site, then temporarily disable JavaScript
in your browser to view the site.
If you disable JavaScript to view the OpenSSO site, be sure to re-enable it.
Subsequent labs require JavaScript to be enabled in your browser.
● Subdirectory – /opt/ses/shared/software/agent-
v3.20080627-webserver-v7
Software – Sun OpenSSO Policy Agent 3.0 for Sun Java
System Web Server 7.0 (Policy Agent for Web Server)
● Subdirectory – /opt/ses/shared/software/apache-
tomcat-6.0.14
Software – Tomcat 6.0.14
URL – http://tomcat.apache.org
● Subdirectory – /opt/ses/shared/software/glassfish-
v2ur2
Software – GlassFish application server (GlassFish)
URL – https://glassfish.dev.java.net
● Subdirectory – /opt/ses/shared/software/opensso-
v1b4.5
Software – OpenSSO build 4.5

● Subdirectory – /opt/ses/shared/software/webserver-
v7u2
Software – Sun Java™ System Web Server 7.0 Update 2
(Web Server)
URL – http://developers.sun.com/webtier/
community/index.jsp
6. In a terminal window, change to the /opt/ses/lab/scripts
directory and list the content in that directory:
cd /opt/ses/lab/scripts
ls
The /opt/ses/lab/scripts directory contains bash shell scripts
that provide shortcuts for typing long commands.
7. Log out of the zone1 zone:
exit
8. Verify that the same software binaries that are accessible from the
zone1 zone are also accessible from the zone2 zone.
zoneadm -z zone2 boot
zlogin zone2
ls /opt/ses/shared/software
9. Change to the /opt/ses/lab directory and list the content in that
directory:
cd /opt/ses/lab
ls
In the zone2 zone, the /opt/ses/lab directory contains both bash
shell scripts and a small web site that you use to demonstrate
OpenSSO web access management.
10. Verify that the set of bash shell scripts available in the zone2 zone
differ from the scripts available in the zone1 zone:
cd scripts
ls
11. Return to the zone1 zone:
exit
zlogin zone1
Note – You perform the remaining tasks in this lab in the zone1 zone.

Exercise 2: Installing and Configuring Apache Tomcat for Use as an OpenSSO Web
Exercise 2: Installing and Configuring Apache Tomcat for

Use as an OpenSSO Web Container
In this exercise, you install and configure two Tomcat instances in the
zone1 zone on your virtual machine.
In this exercise, you perform the following tasks:

● Install Tomcat software
● Configure Tomcat port numbers
● Modify Tomcat start pages
● Start and stop Tomcat instances
After you have completed this exercise, you take the following actions in
subsequent exercises and labs to build a complex OpenSSO deployment:
● You configure a software-based load balancer to distribute the
requests between the Tomcat instances
● You install the OpenSSO web application into each of the Tomcat
instances
● You configure session failover for the OpenSSO instances
● You install a web site on a Web Server instance, then install Policy
Agent for Web Server to provide web access management for the
web site
● You install a sample application on a GlassFish instance, then install
Policy Agent for Application Server to provide web access
management for the sample application

Preparation
No special preparation is required for this exercise.
Task 1 – Installing Tomcat Software

In this task, you install Tomcat software.

1. Open a terminal window and log into the zone1 zone (if necessary).
2. Create directories into which the Tomcat software is installed:
cd /opt
mkdir -p apache-tomcat-6.0.14/instance1
mkdir -p apache-tomcat-6.0.14/instance2
3. Install the instance1 Tomcat instance:
cd apache-tomcat-6.0.14/instance1
cp -r /opt/ses/shared/software/apache-tomcat-6.0.14/* .
4. Install the instance2 Tomcat instance:
cd ../instance2
cp -r /opt/ses/shared/software/apache-tomcat-6.0.14/* .

Task 2 – Configuring Tomcat Port Numbers

By default, Tomcat instances use port numbers starting with the number
“8”. For example:
● Port 8080 is the non-secure HTTP port
● Port 8443 is the secure HTTPS port
Because you work with two Tomcat instances, you cannot use the default
Tomcat port numbers. You need to use different port numbers for each
instance so that you can differentiate between the two simultaneously-
running instances.
In this task, you configure the two Tomcat instances to use different port
numbers.

1. Run the instance1ports script:
/opt/ses/lab/scripts/instance1ports
The instance1ports script changes the port numbers in a Tomcat
configuration so that they start with the number 10 instead of
starting with the number 8. For the instance1 instance:
2. Run the instance2ports script:
/opt/ses/lab/scripts/instance2ports
The instance2ports script changes the port numbers in a Tomcat
configuration so that they start with the number 20 instead of
starting with the number 8. For the instance2 instance:

Task 3 – Modifying Tomcat Start Pages

In this task, you modify the Tomcat default start page.
Modifying the default Tomcat start page lets you easily determine which
of the two Tomcat instances are being accessed.

1. Change to the directory that contains the instance1 instance
installation:
cd /opt/apache-tomcat-6.0.14/instance1
2. Remove DOS end-of-line characters from the file containing the start
page for the instance1 instance:
dos2unix webapps/ROOT/index.html webapps/ROOT/ \
index.html
Note – These labs use the “\” character at the ends of lines in example
commands to indicate line continuation. When you see a command that
appears in multiple lines, each ending with the “\” character, enter the
command on a single line, without pressing Enter. Do not type the “\”
character when entering the command.
Note – It is not necessary to remove DOS end-of-line characters from the

index.html file. It simply makes the file easier to read when you edit it in
the next step.
3. Using any text editor, edit the start page—the

webapps/ROOT/index.html page—for the instance1 instance:
a. Find the second occurrence of the string, Apache Tomcat, in the
file.
b. Modify the string Apache Tomcat to Apache Tomcat on
Instance 1.
The modified line should appear as follows:
<td align="left" valign="top"><b>Apache Tomcat on
Instance 1</b></td>
c. Save and close the start page for the instance1 instance.

4. Change to the directory that contains the instance2 instance

installation:
cd /opt/apache-tomcat-6.0.14/instance2
5. Remove DOS end-of-line characters from the file containing the start
page for the instance2 instance:
dos2unix webapps/ROOT/index.html webapps/ROOT/ \
index.html
6. Using any text editor, edit the start page—the
webapps/ROOT/index.html page—for the instance2 instance:
a. Find the second occurrence of the string, Apache Tomcat, in the
file.
b. Modify the string Apache Tomcat to Apache Tomcat on
Instance 2.
The modified line should appear as follows:
<td align="left" valign="top"><b>Apache Tomcat on
Instance 2</b></td>
c. Save and close the start page for the instance2 instance.
Task 4 – Starting and Stopping Tomcat Instances

In this task, you start and stop the Tomcat instances, and verify that they
are working correctly.

1. Change to the directory that contains the startup script for the first
Tomcat instance:
cd ../instance1/bin
2. Set environment variables required for successful Tomcat startup:
CATALINA_HOME=/opt/apache-tomcat-6.0.14/instance1
export CATALINA_HOME
JAVA_HOME=/usr/jdk/jdk1.5.0_14
export JAVA_HOME
The CATALINA_HOME environment variable provides the location of
the Tomcat installation directory.
The JAVA_HOME environment variable provides the location of the
JDK™ software.

3. Start the first Tomcat instance:

./startup.sh
4. In a browser, navigate to the start page for the first Tomcat instance:
http://zone1.example.com:10080
The start page for Tomcat appears. The following text should appear
on the start page:
Apache Tomcat on Instance 1
5. Change to the directory that contains the startup script for the
second Tomcat instance:
cd ../../instance2/bin
6. Change the value of the CATALINA_HOME environment variable,
which is required to start up the instance2 instance:
Note – The JAVA_HOME setting still has the value /usr/jdk/jdk1.5.0_14

in the shell, therefore it is not necessary to set it in this step.
7. Start the second Tomcat instance:

./startup.sh
8. In a browser, navigate to the start page for the second Tomcat
instance:
on the start page:
9. Stop the first Tomcat instance:
./shutdown.sh
10. Stop the second Tomcat instance:
./shutdown.sh

11. Practice using the startservers and stopservers scripts.

These two scripts let you start and stop one or both Tomcat
instances. You can use these scripts to start and stop Tomcat in lieu
of manually setting environment variables, changing to the Tomcat
installation directory, and executing the script on the command line.
a. Start both Tomcat instances:
/opt/ses/lab/scripts/startservers -f
b. Stop both Tomcat instances:
/opt/ses/lab/scripts/stopservers -f
c. Verify that both Tomcat instances are down before you attempt
to restart the instances.
Run the following command:
ps -ef | grep apache
The presence of output similar to the following indicates that
Tomcat instances have not completely shut down:
root 5306 4391 1 13:18:16 pts/4 1:37
/usr/jdk/jdk1.5.0_14/bin/java -
Djava.util.logging.manager=org.apache.juli.Class
Do not proceed to the next step until you have verified that all
Tomcat instances are shut down.
d. Start the first Tomcat instance:
/opt/ses/lab/scripts/startservers -1
e. Stop the first Tomcat instance:
/opt/ses/lab/scripts/stopservers -1
f. Verify that the first Tomcat instance is down before you attempt
to restart the instances. Do not proceed to the next step until
you have verified that this Tomcat instance is shut down.
g. Start the second Tomcat instance:
h. Stop the second Tomcat instance:
i. Verify that the second Tomcat instance is down before you
proceed to the next step.

Exercise 3: Securing the Tomcat Instances

In this exercise, you secure the two Tomcat instances.
You start by creating a local certificate authority (CA) certificate. In a

production environment, this would almost certainly not be necessary, since the
CA issuing your server certificates would likely be a commercial provider,
such as Verisign. But in the learning environment, it is not always possible
to get a server certificate from a commercial provider. So for these labs,
you create a CA certificate and set yourself up as the CA.
After creating this local CA, you create server certificates for each of the
Tomcat instances, and have the local CA sign the server certificates. Then
you store the certificates in Java key stores, which Tomcat uses for its
certificate database. Finally, you reconfigure Tomcat so that the two
instances are secured, and verify that you can access the Tomcat instances
using the secure HTTP (HTTPS) ports, rather than the HTTP ports with
which you accessed Tomcat in the last exercise.

● Create a certificate database and a local CA certificate
● Create Java key stores for each Tomcat instance
● Create server certificates for each instance
● Sign the server certificates with the local CA and storing the
certificates in the Java key stores
● Configure Tomcat for secure sockets layer (SSL) access
● Insert the local CA certificate into the virtual machine for the Java
platform (JVM™) key store to prepare for OpenSSO configuration
● Restart the Tomcat instances and verify that HTTPS access works
You configure OpenSSO in the next lab.
Preparation

Task 1 – Creating a Certificate Database and a Local

CA Certificate
In this task, you use the certutil command to create a certificate
database and a local CA certificate.
These labs make use of two security tool sets:

● Network Security Services (NSS) tools – This tool set includes the
certutil utility, which lets you create CA certificates and sign
server certificates.
● Java Secure Socket Extension (JSSE) tools – This tool set includes the
keytool utility, which lets you work with JSSE digital certificates
and Java key stores. When you secure a Tomcat instance, you
reference a Java key store containing digital certificates.

2. Create a directory for storing certificates:
mkdir /opt/certs
3. Create a password file for use when creating certificates:
cd /opt/certs
echo cangetin > password
4. Verify that you have created the password file correctly:
cat password
The output of the cat command should show the content of the
password file to be the string cangetin.
Caution – One more warning: for your convenience, most of the

passwords used in this class have the same value: cangetin. Setting
system passwords to the same value is not a security best practice.

5. For many of the steps in this lab, including this step, there are two
ways you can perform the step:
● Use scripts provided for you, to save you from having to type
long commands
● Execute the certutil and keytool commands from the
command line, and gain greater insight into how you enable
SSL
Either execute the script or run the commands, but do not do both.
Create a certificate database, then create a local CA certificate that
you use to sign certificates later in this lab.
● Commands:
Create the certificate database:
/usr/sfw/bin/certutil -N -d /opt/certs \
-f /opt/certs/password
Create the local CA certificate:
/usr/sfw/bin/certutil -S -n LocalCA -x \
-t "CTu,Cu,Cu" -s "CN=LocalCA,o=example.com" \
-m 1000 -d /opt/certs -z /etc/passwd \
● Script:
/opt/ses/lab/scripts/createCertDBWithLocalCA
6. Verify that you have created the certificate database and the local CA
certificate:
/usr/sfw/bin/certutil -L -d /opt/certs

Task 2 – Creating Java Key Stores for Each Tomcat

Instance
In this task, you use the keytool command to create two Java key stores
and insert the local CA certificate into the key stores. In a subsequent task,
the two Tomcat instances are configured to reference these two Java key
stores.

1. Store the content of the local CA certificate in the LocalCA.crt file:
/usr/sfw/bin/certutil -L -d /opt/certs -n LocalCA -a \
-o /opt/certs/LocalCA.crt
Note – The LocalCA.crt file is used in numerous other steps throughout

this course.
2. Review the content of the LocalCA.crt file:

cat /opt/certs/LocalCA.crt
3. Use the keytool command to review the local CA certificate details:
keytool -printcert -v -file LocalCA.crt
4. Change permissions on the LocalCA.crt file:
chmod 666 LocalCA.crt
Note – You import the LocalCA.crt file into a Web Server instance that
serves as a load balancer later in this lab. Importing a certificate file into a
Web Server instance requires execute permission.

5. Create two Java key stores—one for each Tomcat instance. When you
create the Java key stores import the local CA certificate into the key
stores.
● Commands:
Create the Java key store for the first Tomcat instance:
keytool -import -v -keystore \
/opt/certs/instance1.jks -storepass cangetin \
-alias localca -file LocalCA.crt
Respond yes to the Trust this certificate? prompt.
Create the Java key store for the second Tomcat instance:
keytool -import -v -keystore \
/opt/certs/instance2.jks -storepass cangetin \
-alias localca -file LocalCA.crt
● Script:
/opt/ses/lab/scripts/createJavaKeystores
Respond yes to the Trust this certificate? prompt both
times it appears during script execution.
6. Review the content of the two Java key stores:
keytool -list -keystore /opt/certs/instance1.jks \
-storepass cangetin
-storepass cangetin

Task 3 – Creating Server Certificates for Each Instance

In this task, you use the keytool command to create certificates for each
Tomcat instance.

1. Create a server certificate for the first instance.
● Command:
keytool -genkey -alias instance1 \
-keyalg RSA -sigalg MD5withRSA -validity 356 \
-keystore /opt/certs/instance1.jks \
-storepass cangetin
Prompts appear in the terminal window. Proceed to step 2 for
responses to the prompts.
● Script:
/opt/ses/lab/scripts/createInstance1Key
2. Respond to prompts requesting certificate details as follows:
a. Prompt – What is your first and last name?
Response – Type zone1.example.com
b. Prompt – What is the name of your organizational
unit?
Response – Type instance1
c. Prompt – What is the name of your organization?
Response – Type example.com
d. Prompt – What is the name of your City or Locality?
Response – Press Enter
e. Prompt – What is the name of your State or Province?
f. Prompt – What is the two-letter country code for
this unit?

g. Prompt – Is CN=zone1.example.com, OU=instance1,

O=example.com, L=Unknown, ST=Unknown, C=Unknown
correct?
Response – Type yes
h. Prompt – Enter key password for <instance1> (RETURN
if same as keystore password)
3. Create a server certificate for the second instance.
● Command:
keytool -genkey -alias instance2 \
-keyalg RSA -sigalg MD5withRSA -validity 356 \
-storepass cangetin
● Script:
/opt/ses/lab/scripts/createInstance2Key
4. Respond to prompts requesting certificate details as follows:
a. Prompt – What is your first and last name?
Response – Type zone1.example.com
Note – Do not make the mistake of automatically typing

zone2.example.com in this step. Both Tomcat instances are deployed in
the zone1 zone.
b. Prompt – What is the name of your organizational

unit?
Response – Type instance2
c. Prompt – What is the name of your organization?
Response – Type example.com
d. Prompt – What is the name of your City or Locality?

e. Prompt – What is the name of your State or Province?

f. Prompt – What is the two-letter country code for
this unit?
g. Prompt – Is CN=zone1.example.com, OU=instance2,
O=example.com, L=Unknown, ST=Unknown, C=Unknown
correct?
Response – Type yes
h. Prompt – Enter key password for <instance1> (RETURN
if same as keystore password)

Task 4 – Signing and Storing the Server Certificates

In this task, you use the keytool command to create a certificate signing
request (CSR) for your two server certificates. Then you use the certutil
command to sign the certificates, specifying the local CA as the signing
authority. Finally, you use the keytool command to store the signed
server certificates in the Java key stores.

1. Sign the server certificates. The signing authority is the local CA.
● Commands:
Create certificate signing requests for both server certificates:
keytool -certreq -alias instance1 \
-sigalg MD5withRSA \
-storepass cangetin \
-v -file /opt/certs/instance1.csr
keytool -certreq -alias instance2 \
-sigalg MD5withRSA \
-storepass cangetin \
-v -file /opt/certs/instance2.csr
Sign the server certificates:
/usr/sfw/bin/certutil -C -c LocalCA -a \
-i instance1.csr -o instance1.crt -m 1001 -v 12 \
-d /opt/certs -f /opt/certs/password
/usr/sfw/bin/certutil -C -c LocalCA -a \
-i instance2.csr -o instance2.crt -m 1002 -v 12 \
-d /opt/certs -f /opt/certs/password
Import the signed certificates into the Java key stores:
keytool -import -v -alias instance1 \
-storepass cangetin -file instance1.crt
keytool -import -v -alias instance2 \
-storepass cangetin -file instance2.crt

● Script:
/opt/ses/lab/scripts/signAndStoreServerCerts
Output appears in the terminal window indicating that a
certification request was created, and that a certificate replies
were installed in the /opt/certs/instance1.jks and
/opt/certs/instance2.jks key stores.
2. Validate that the signed server certificate is present in the Java key
stores that are used by the two Tomcat instances:
-storepass cangetin
-storepass cangetin
Entries for the local CA certificate and the server certificate should be
present in both key stores.

Task 5 – Configuring Tomcat for SSL Access

To configure Tomcat for SSL access, you configure a connector port in the
Tomcat server.xml file with the SSLEnabled="true" argument.
After Tomcat installation, the Tomcat server.xml file contains a

definition for an SSL-enabled connector port. However this definition is
commented, therefore, it is inactive.
In this task, you uncomment definitions for the SSL-enabled connector

ports for the two Tomcat instances and modify the definitions to reference
the Java key stores created in previous tasks in this lab.

1. Configure the first Tomcat instance for SSL:
a. Using any text editor, open the /opt/apache-tomcat-6.0.14/
instance1/conf/server.xml file.
b. Locate the definition for connector port 10443.
This definition starts with the following text:
<Connector port="10443" protocol="HTTP/1.1"
SSLEnabled="true"
The definition is commented:
● The line preceding the definition contains the string .
c. Uncomment the definition for connector port 10443 by
removing the line preceding the definition and removing the
line following the definition.
d. Configure the Java key store and the key store password. Add
the following new lines below the <Connector port="10443"
protocol="HTTP/1.1" SSLEnabled="true" line:
keystoreFile="/opt/certs/instance1.jks"
keystorePass="cangetin"
e. Save and close the /opt/apache-tomcat-
6.0.14/instance1/conf/server.xml file.

2. Configure the second Tomcat instance for SSL:

a. Using any text editor, open the /opt/apache-tomcat-
6.0.14/instance2/conf/server.xml file.
b. Locate the definition for connector port 20443.
This definition starts with the following text:
<Connector port="20443" protocol="HTTP/1.1"
SSLEnabled="true"
The definition is commented:
● The line preceding the definition contains the string .
c. Uncomment the definition for connector port 20443 by
removing the line preceding the definition and removing the
line following the definition.
d. Configure the Java key store and the key store password. Add
the following new lines below the <Connector port="20443"
protocol="HTTP/1.1" SSLEnabled="true" line:
keystoreFile="/opt/certs/instance2.jks"
keystorePass="cangetin"
e. Save and close the /opt/apache-tomcat-6.0.14/
instance2/conf/server.xml file.

Task 6 – Preparing the JVM Key Store for OpenSSO

Configuration
OpenSSO requires CA certificates to be present in its JVM Java key store
under certain circumstances.1 In this task, you insert the local CA
certificate into the JVM Java key store.
Note – This task is not required to enable SSL on a Tomcat instance. It is

preparatory for subsequent labs.

1. Store the local CA certificate in the JVM certificates store.
● Command:
keytool -import -keystore \
/usr/jdk/jdk1.5.0_14/jre/lib/security/cacerts \
-storepass changeit -alias localca \
-file LocalCA.crt
● Script:
/opt/ses/lab/scripts/importLocalCACertIntoJVM
2. Validate that the local CA certificate is present in the JVM Java key
stores:
keytool -list -keystore \
-storepass changeit | grep localca
An entry for the local CA certificate should be present.
1. CA certificates are required to be present in the JVM Java key store in the
following cases:
● When configuring the first OpenSSO instance of a multi-instance site,
in which the OpenSSO instances are deployed on web containers that
are SSL-enabled
● When configuring an OpenSSO instance that uses a directory server
that is accessed using the LDAPS protocol
● When installing Policy Agent software that accesses an SSL-enabled
OpenSSO instance

Task 7 – Testing SSL Access

In this task, you restart the two Tomcat instances. Then you display the
start pages for both instances using HTTPS to verify that you have
configured SSL correctly for both instances.

1. Stop the two Tomcat instances:
If one or both of the Tomcat instances are down and you execute the
stopservers script, a stack trace appears in the terminal window. If
this is the case now, it is not a problem.
2. Verify that both Tomcat instances are down before you attempt to
restart the instances.
The presence of output similar to the following indicates that Tomcat
instances have not completely shut down:
root 5306 4391 1 13:18:16 pts/4 1:37
3. Restart the two Tomcat instances:
4. In a browser, navigate to the start page for the first Tomcat instance:
https://zone1.example.com:10443
5. The browser presents you with a message offering to give you an
opportunity to examine the server’s certificate. Examine the
certificate and verify the following:
● The certificate is, in fact, the certificate for the first Tomcat
instance.
● The certificate details are identical to the details you provided
when you created the certificate in Task 3 – Creating Server
Certificates for Each Instance on page L1-21.
6. Click Close to close the window with certificate details.

7. Select Accept This Certificate Temporarily for this Session and click
OK.
on the start page:
8. In a browser, navigate to the start page for the second Tomcat
instance:
9. The browser presents you with a message offering to give you an
opportunity to examine the server’s certificate. Examine the
● The certificate is, in fact, the certificate for the second Tomcat
instance.
● The certificate details are identical to the details you provided
when you created the certificate in Task 3 – Creating Server
Certificates for Each Instance on page L1-21.
10. Click Close to close the window with certificate details.
11. Select Accept This Certificate Temporarily for this Session and click
OK.
on the start page:

Exercise 4: Installing, Securing and Configuring a Software-Based Load Balancer
Exercise 4: Installing, Securing and Configuring a

Software-Based Load Balancer
In this exercise, you deploy a software-based load balancer into the zone1
zone.
In typical production deployments, you would probably choose to use a

hardware-based load balancer in order to obtain superior performance
and, optionally, make use of features such as SSL termination. In the
learning environment, it is not possible to provide hardware-based load
balancers, so you use a software-based load balancer that lets you practice
deploying OpenSSO in a somewhat complex environment.
The load balancer that you use in these labs is Web Server 7.0 with the
reverse proxy feature.

● Install Web Server 7.0
● Install the local CA certificate in the Web Server instance
● Obtain and install a server certificate for the Web Server instance
● Configure and secure a new listener port
● Configure and test the load balancer
Preparation

Task 1 – Installing Web Server 7.0

In this task, you install Web Server software.
You configure the Web Server instance created during installation as a

load balancer in a subsequent task.

2. Run the following command to start software installation:
/opt/ses/shared/software/webserver-v7u2/setup
3. Reply to the installer dialog boxes as follows:
a. Welcome: Click Next.
b. Software License Agreement: Select Yes, then click Next.
c. Software Installation Directory: Type /opt/webserver and
click Next.
d. Click Yes in response to the Create New Directory dialog box.
e. Select the Type of Installation: Choose Custom, and click Next.
f. Component Selection: Click Next.
g. Java Configuration: Click Next.
h. Administration Options: Click Next.
i. Administration Server Settings:
● Runtime User ID: Type webservd
● Administrator User Name: Type admin
● Administrator Password: Type cangetin
● Retype Password: Type cangetin
Click Next.
j. Web Server Settings: Click Next.
k. Ready to Install: Click Install Now.
The Installing dialog box appears and informs you of
installation progress.
l. Installation Complete: Click Finish.

4. Display the contents of the /opt directory:

ls /opt
The webserver subdirectory should now be present.
5. Start the Web Server instance:
/opt/ses/lab/scripts/startservers -l
Note – In the preceding command, you use the ”-l ” argument to start
the load balancer. You can also use the “-1” argument to start the first
Tomcat instance. Be careful to use the correct argument with the
startservers script.
Task 2 – Installing the Local CA Certificate in the Web

Server Instance
In this task, you use the Web Server administration console to install the
local CA certificate in the Web Server instance’s certificate database.

1. Start the Web Server administration console by navigating to the
following URL:
2. Log in to the console as the admin user. The password is cangetin.
3. Select the Configurations tab.
4. Select the zone1.example.com configuration.
5. Select the Certificates tab.
6. Select the Certificate Authorities tab.
7. Install the certificate for the local CA:
a. Click Install to start the Install CA Certificate wizard.
The Select Tokens and Passwords dialog box appears.
b. Click Next.
The Enter Certificate Data dialog box appears.

c. Select Certificate File and type /opt/certs/LocalCA.crt in

the Certificate File field.
Click Next.
The Certificate Type dialog box appears.
d. Select CA Certificate and click Next.
The Review dialog box appears.
Review the values you have entered. If incorrect values appear
in the Review dialog box, make corrections as necessary.
e. Click Finish.
The Installation Successful dialog box appears.
f. Click Close.
8. Navigate to the end of the list of certificate authorities. The entry,
LocalCA - example.com, appears as the last entry in the list.
9. The Deployment Pending link appears in the upper right corner of
the administration console.
10. Deploy and restart the Web Server instance:
a. Click Deployment Pending.
The Configuration Deployment dialog box appears.
b. Click Deploy.
After deployment has completed, the Results dialog box
appears, with the message Instance(s) Require Restart.
c. Select Now, then click OK to restart the instance.
After the restart has completed, the Results dialog box appears,
with the message Instance(s) restarted successfully.
d. Click Close.
Leave the Web Server administration console open for the next task.

Task 3 – Obtaining and Installing a Server Certificate

for the Web Server Instance
In this task, you use the Web Server administration console to create a
certificate signing request (CSR) for a server certificate for the Web Server
instance. Then you use the certutil command to sign the certificate,
specifying the local CA as the signing authority. Finally, you use the Web
Server administration console to import the signed server certificates into
the Web Server instance’s certificate database.

1. Click Configurations from the Configurations > zone1.example.com
link in the upper left corner of the administration console.
2. Select the zone1.example.com configuration.
3. Select the Certificates tab.
4. Create a certificate signing request:
a. Click Request to start the Request Server Certificate wizard.
b. Click Next.
The Enter Server Details dialog box appears.
c. Enter data in the Enter Server Details dialog box as follows:
● Server Name (CN): Type zone1.example.com
● Organization (O): Type example.com
● Organizational Unit (OU): Type lb
Click Next.
The Certificate Options dialog box appears.
d. Click Next.
The Certificate Type dialog box appears.
e. Select CA Signed Certificate and click Next.
f. Click Finish.
The Results dialog box appears.

g. Copy all of the text, including the BEGIN NEW CERTIFICATE

REQUEST and END NEW CERTIFICATE REQUEST headers, into a
copy-and-paste buffer.
h. Click Close.
5. Create a certificate signing request file:
a. Using any text editor, open a new file named
/opt/certs/lb.csr.
b. Paste all the text from the copy-and-paste buffer into the new
file.
c. Save and close the lb.csr file.
6. Sign the certificate.
● Command:
/usr/sfw/bin/certutil -C -c LocalCA -a -i lb.csr \
-o lb.crt -m 1003 -v 12 -d /opt/certs \
● Script:
/opt/ses/lab/scripts/signLBCert
7. Change permissions on the lb.crt file:
chmod 666 /opt/certs/lb.crt
Note – Importing a certificate file into a Web Server instance requires

execute permission.
8. Return to the Web Server administration console and select the

Server Certificates tab.
9. Install the signed certificate into the Web Server instance’s certificate
database:
a. Click Install to start the Install Server Certificate wizard.
b. Click Next.
The Enter Certificate Data dialog box appears.
c. Select Certificate File and type /opt/certs/lb.crt in the
Certificate File field.
Click Next.
The Certificate Details dialog box appears.

d. Enter lb for Nickname and click Next.

e. Click Finish.
The Installation Successful dialog box appears.
f. Click Close.
The lb certificate appears in the Server Certificates list.
b. Click Deploy.
d. Click Close.
Leave the Web Server administration console open for the next task.
Task 4 – Configuring and Securing a New Listener Port

In this task, you secure create listener port 8443 on the Web Server.

1. Select the HTTP Listeners tab in the Web Server administration
console.

2. Create an SSL-enabled HTTP listener on port 8443:

a. Click New to start the New HTTP Listener wizard.
The Add HTTP Listener dialog box appears.
b. Enter data in the Add HTTP Listener dialog box as follows:
● Port: Type 8443.
● Server Name: Type zone1.example.com.
● SSL: Select Enabled.
● Certificate: Select lb.
Click Next.
c. Review the values you have entered. If incorrect values appear
d. Click Finish.
The Results dialog box appears.
e. Click Close.
Port 8443 appears in the HTTP Listeners list.
b. Click Deploy.
d. Click Close.
5. Open a new tab page in your web browser.
6. Verify that the HTTP listener on port 8443 is active and SSL-enabled:
a. Navigate to the following URL:

b. The browser presents you with a message offering to give you

an opportunity to examine the server’s certificate. Examine the
● The certificate is, in fact, the certificate for the load balancer.
● The certificate details are identical to the details you
provided when you created the certificate in a previous
task in this exercise.
c. Click Close to close the window with certificate details.
d. Select Accept This Certificate Temporarily for this Session and
click OK.
The default start page for Web Server appears.
Task 5 – Configuring and Testing the Load Balancer

In this task, you configure load balancing on the Web Server instance.
Then you test your deployment, verifying that requests sent to the Web
Server (now acting as a load balancer) are passed on to each of your two
Tomcat instances.

1. Return to the Web Server administration console.
2. Select the Virtual Servers tab.
3. Select the zone1.example.com virtual server.
4. Select the Content Handling tab.
5. Select the Reverse Proxy tab.
6. Configure load balancing:
a. Click New.
The Add Reverse Proxy URI dialog box appears.
b. Enter values in the Add Reverse Proxy URI dialog box as
follows:
● URI: Type a single forward slash character (“/”)
● Server URLs: Type
https://zone1.example.com:10443,https://zone1.
example.com:20443.

c. Click OK.
The Reverse Proxy URI Created Successfully message
appears.
The entry for the “/” URI appears in the reverse proxies list.
d. Select the “/” URI.
A dialog box that lets you enter load balancing details appears.
e. Specify the following value in the dialog box:
● Sticky cookie: Type amlbcookie
Note – Specifying a sticky cookie when configuring a load balancer for

use with OpenSSO instances is highly recommended for performance
reasons. Sticky cookies let the load balancer route requests to OpenSSO
servers, eliminating much back-channel communication between load-
balanced OpenSSO instances in a site.
f. Click OK.
g. The Deployment Pending link appears in the upper right corner
of the console.
h. Click the Deployment Pending link.
i. Click Deploy to deploy the changes to the configuration.
The message, The configuration has been deployed
successfully to all available nodes, appears in the
Configuration Deployment dialog box.
Note – The preceding configuration change does not require Web Server
restart.
j. Click Close.
7. Log out of the Web Server administration console.
8. Verify that load balancing works correctly:
a. Clear cache and remove cookies from the browser session.
b. Shut down the browser.
c. Restart the browser.

d. Navigate to the following URL:

You should see the default start page for one of the two Tomcat
instances.
e. Clear cache and remove cookies from the browser session.
f. Shut down the browser.
g. Restart the browser.
h. Navigate to the following URL:
You should see the default start page for the other Tomcat
instance.
Repeat step 8 several times to demonstrate that the Web Server is
load balancing the requests to the Tomcat instances.

Exercise Summary
Exercise Summary
Discussion – Take a few minutes to discuss what experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Lab 2
Deploying a Multi-Instance OpenSSO Site
Objectives
● Deploy a multi-instance OpenSSO site
● Set up the OpenSSO command-line tools
Lab 2-1
Exercise 1: Deploying a Multi-Instance OpenSSO Site

In this exercise, you install OpenSSO software into the two Tomcat web
containers that you installed and configured in the “Preparing an
Environment for a Complex OpenSSO Deployment” lab. Then you
configure the two OpenSSO instances and verify that your configuration
works correctly.

● Modify the web container configuration as specified in the Release
Notes
● Deploy the OpenSSO web archive on the two Tomcat instances
● Configure OpenSSO on the first Tomcat instance
● Configure OpenSSO on the second Tomcat instance
● Test the load-balanced, multi-instance OpenSSO deployment

Preparation
This section contains preparatory information and describes actions you
must take prior to proceeding to the first lab exercise.
Prerequisite Labs
The following lab is prerequisite for performing this lab:

“Preparing an Environment for a Complex OpenSSO Deployment”
The tasks to prepare your lab system depends on whether you performed
the prerequisite lab, and whether you have performed other labs, in
addition to the prerequisite lab.
Your lab system can be in one of three states defined in Table 2-1 on
page L2-3. Determine which of these three states describes your lab
system. Then, depending on the state of your lab system, follow the
instructions in the table.
Lab System
State
Ready to Go, • You completed the No additional

Powered Up prerequisite labs and no preparation is required.
additional labs Proceed directly to
‘‘Task 1 – Modifying the
• After completing the Web Container
prerequisite labs, you did Configuration as
not power down the Specified in the Release
learning virtual machine, Notes’’ on page L2-7.
and you stayed logged in
to the zone1 zone
Deploying a Multi-Instance OpenSSO Site Lab 2-3

Lab System
State
Ready to Go, • You completed the Perform the steps in the
Powered prerequisite labs and no section, ‘‘Task 2 –
Down additional labs Restarting the Learning
• After completing the page L2-4.
preceding lab, you
powered down the
learning virtual machine
Not at Either: Perform the steps in the

Starting section, ‘‘Task 3 –
Point • You did not complete the Bringing the Learning
prerequisite labs Virtual Machine to the
• Or, you completed other
labs in addition to the
prerequisite labs
Task 2 – Restarting the Learning Virtual Machine

4. Start a terminal window.
global # lab -p
6. Perform the steps in ‘‘Task 4 – Restarting the zone1 Zone and
Servers’’ on page L2-5.

Point for This Lab



is cangetin.
the zone:
zone1 # exit
global # lab -n 2
point for this lab.

to complete.

global # lab -p
8. Perform the steps in the section, ‘‘Task 4 – Restarting the zone1 Zone
and Servers’’ on page L2-5.
Task 4 – Restarting the zone1 Zone and Servers


3. Start server processes that were started in previous lab exercises:

/opt/ses/lab/scripts/startservers -f -l
The preceding command starts:
● The two Tomcat instances that serve as OpenSSO web
containers
● The Web Server instance that serves as a load balancer
Your lab system is now ready for the lab. Proceed to ‘‘Task 1 – Modifying
the Web Container Configuration as Specified in the Release Notes’’ on
page L2-7.

Task 1 – Modifying the Web Container Configuration as

Specified in the Release Notes
Before deploying OpenSSO, you should always review the following
documentation:
● Installation and Configuration Guide – This manual describes the
installation and configuration procedures
● Release Notes – This document contains the most current information
about installation and configuration
It is important to read both the Installation and Configuration Guide and the
Release Notes to obtain the most up-to-date information about OpenSSO
deployment.
You can find the Installation and Configuration Guide at the OpenSSO web
site—https://opensso.dev.java.net—along with other product
documentation. To access OpenSSO documentation, navigate to the
OpenSSO web site, then select the Early Access link (under the
Documentation link) on the left side of the screen.
You can also find the Release Notes at the OpenSSO web site. To access the
OpenSSO Release Notes, navigate to the OpenSSO web site and select the
Downloads link on the left side of the screen. A list of builds appears. For
each build, there is a Release Notes link.
Caution – The locations of the Installation and Configuration Guide and the
Release Notes provided in the previous text, while current as of this
writing, are subject to change.

1. Review the Release Notes for OpenSSO build 4.5, which is the version
of OpenSSO that you use with these labs.
You can find the Release Notes at the following URL:
http://download.java.net/general/opensso/stable/
openssov1-build4.5/B45-ReleaseNotes.html
2. Note the steps required before OpenSSO deployment and
configuration for the Tomcat 6.x web container in the spaces below:
_________________________________________________
_________________________________________________


4. Make sure that you are logged in to the zone1 zone.
The prompt in the terminal window indicates which zone you are
logged into. For example:
zone1 #

lab.
5. Open the /opt/ses/lab/scripts/startservers file using any text

editor.
6. Make the following changes to the /opt/ses/lab/scripts/
startservers file:
a. Locate the following code, which sets the CATALINA_HOME
variable for the instance1 instance:
b. Insert the following code after the line,
export CATALINA_HOME:
CATALINA_OPTS="-server -Xmx512m"
export CATALINA_OPTS
The inserted code sets two options used by the Tomcat JVM:
● The -server option – This option enables optimization of
just-in-time compilation.
● The -Xmx512m option – This option specifies the maximum
heap size for the JVM. By setting the value of the option to
-Xmx512m, you increase the default maximum heap size for
Tomcat 6.x.
used by the first Tomcat instance’s JVM. Note – The Release Notes for OpenSSO build 4.5 specify setting the Xmx
option to 1024m, which is double the memory you specify in step 6b. In
the learning environment, using the -Xmx512m option provides adequate
memory for your needs, and helps learning VM performance. For other
environments, be sure to use the -Xmx1024m option.

The Release Notes for OpenSSO build 4.5 do not specify that you use the -
server option for Tomcat 6.x web containers. The
-server option should be used in all environments except the simplest
test environments. Even though the -server option is not specified in the
Release Notes, use this option in the learning environment to become
accustomed to specifying it.
c. Locate the other three instances of the following code:

CATALINA_HOME=/opt/apache-tomcat-6.0.14/instance_n
In the preceding example, instance_n can have a value of
instance1 or instance2.
d. Insert the following code after the line,
export CATALINA_HOME:
CATALINA_OPTS="-server -Xmx512m"
export CATALINA_OPTS
e. Review the changes you have made to the
/opt/ses/lab/scripts/startservers file.
Verify that you have added commands to set the
CATALINA_OPTS environment variable four times.
f. Save and close the /opt/ses/lab/scripts/startservers file.
7. Restart the two Tomcat instances:
a. Stop the two Tomcat instances:
If one or both of the Tomcat instances are down and you
execute the stopservers script, a stack trace appears in the
terminal window. If this is the case now, it is not a problem.
b. Verify that both Tomcat instances are down before you attempt
root 5306 4391 1 13:18:16 pts/4 1:37

c. Restart the two Tomcat instances:

Task 2 – Deploying the OpenSSO Web Archive File on

the Two Tomcat Instances
In this task, you deploy the OpenSSO web archive file (WAR file).
WAR file deployment for Tomcat is almost trivially simple—you just copy
the WAR file to the Tomcat webapps directory.
Note – As of this writing, the Installation and Configuration Guide describes

WAR file deployment on the GlassFish and Sun Java System Application
Server (Application Server) web containers only. To deploy the OpenSSO
WAR file on another supported web container, refer to the documentation
for that web container.
:Complete the following steps:

1. Stop both Tomcat instances:
2. Copy the OpenSSO binaries into a local directory:
mkdir /opt/opensso
cd /opt/ses/shared/software/opensso-v1b4.5/opensso
cp -r * /opt/opensso
3. Deploy the OpenSSO WAR file to the first Tomcat instance:
cd /opt/opensso/deployable-war
cp opensso.war /opt/apache-tomcat-6.0.14/instance1/ \
webapps
4. Deploy the OpenSSO WAR file to the second Tomcat instance:
cp opensso.war /opt/apache-tomcat-6.0.14/instance2/ \
webapps
1. Start both Tomcat instances:

Task 3 – Configuring OpenSSO on the First Tomcat

Instance
In this task, you run the OpenSSO configurator to configure OpenSSO on
the first Tomcat instance.
In the next task, you configure OpenSSO on the second Tomcat instance.
The two OpenSSO instances plus the load balancer comprise an OpenSSO
site.
You can configure OpenSSO from the command-line using the curl
command. This lab does not describe command-line configuration.
Refer to the following URL for information about configuring OpenSSO

from the command line:
http://blogs.sun.com/indira/entry/
configuring_opensso_the_curl_y

1. Make sure that JavaScript is enabled in your browser.
2. In a browser window, navigate to the following URL:
https://zone1.example.com:10443/opensso
A page appears with a link that lets you create a new configuration.
Note – In most cases in these labs, you access OpenSSO instances by

specifying URLs that use the load balancer port 8443. In this step, you
specifically want to configure the OpenSSO instance running on the first
Tomcat instance. To do so, you must use a URL that specifies port 10443.
3. Configure the OpenSSO instance:

a. Click Create New Configuration.
The General page appears.
b. Enter data in the Default User Passwords section of the General
page as follows:
● Default User [amAdmin]: Type cangetin
● Confirm: Type cangetin
Click Next.
The Server Settings page appears.

c. Enter data in the Server Settings page as follows:

● Server URL: Verify that the default value is
https://zone1.example.com:10443.
For server URL, you specify the URL that you use to access
the web container to which you deployed the OpenSSO
WAR file. In this lab, you use the fully qualified host name
(FQHN) to specify the host, but you can also use the value
localhost.
● Cookie Domain: Verify that the default value is
.example.com.
The cookie domain value should have a period (“.”) as its
first character.
● Configuration Directory: Type /opt/opensso/instance1
Click Next.
The Configuration Store page appears.
Note – In the OpenSSO configurator pages, the terms configuration

directory and configuration store might be easily confused.
The configuration directory is a file system directory that contains flat files
used for system configuration and other purposes. XML schema files,
directory server schema files, log files, and debug files are all located in
the configuration directory. In Sun Java System Access Manager (Access
Manager) 7.1—the predecessor release to OpenSSO—these files were
stored in various locations, depending on operating system platform. For
example, on the Solaris™ Operating System (Solaris OS), these files were
located in the /etc and /var directories.
The configuration store is an Lightweight Directory Access Protocol (LDAP)

directory that contains information about OpenSSO realm, authentication,
policy, and other service configuration. This LDAP directory is an
OpenDS directory. In Access Manager 7.1, the configuration store was
referred to as the Access Manager information tree.
d. Click Next.
The User Store Settings page appears.
e. Select Embedded and click Next.
The Site Configuration page appears.

f. Enter data in the Site Configuration page as follows:

● Will This Instance be Deployed Behind a Load Balancer?:
Select Yes.
● Site Name: Type WS7LB
● Primary URL: Type
Click Next.
The Default Agent User page appears.
g. Enter data in the Default Agent User page as follows:
● Default Agent [amldapuser]: Type cangetinam
● Confirm: Type cangetinam
Note – Make sure you have not typed cangetin as the password for the
default agent user.
Click Next.
The Configurator Summary Details page appears.
on the Configurator Summary Details page, make corrections as
necessary.
h. Click Create Configuration.
Progress messages inform you of configuration progress.
The Configuration Complete page appears.
Caution – In some environments, if you click the Proceed to Login link,

the Server Not Found page appears. Please refer to OpenSSO issues 2021
and 2765 for more information. Steps 3i through 3k are a workaround for
these two issues.
i. Stop the two Tomcat instances:


j. Verify that both Tomcat instances are down before you attempt
root 5306 4391 1 13:18:16 pts/4 1:37
k. Restart the two Tomcat instances:
4. Remove cache and cookies from your browser, and restart the
browser.
5. Navigate to the following URL:
6. The OpenSSO login screen appears.
Log in to OpenSSO as the amAdmin user. The password is cangetin.
7. The OpenSSO console start page appears.
8. Verify that the site configuration is correct:
a. Select the Configuration tab.
b. Select the Sites and Servers tab.
c. Note that a site named WS7LB is present, and that a server with
the URL https://zone1.example.com:10443/opensso is
assigned to the WS7LB site.
9. Log out of the console.

Task 4 – Configuring OpenSSO on the Second Tomcat

Instance
In this task, you run the OpenSSO configurator to configure OpenSSO on
the second Tomcat instance.

1. In a browser window, navigate to the following URL:
A page appears with a link that lets you create a new configuration.
Note – In most cases in these labs, you access OpenSSO instances by

specifying URLs that use the load balancer port 8443. In this step, you
specifically want to configure the OpenSSO instance running on the
second Tomcat instance. To do so, you must use a URL that specifies port
20443.
2. Configure the OpenSSO instance:

a. Click Create New Configuration.
The General page appears.
b. Enter data in the Default User Passwords section of the General
page as follows:
● Default User [amAdmin]: Type cangetin
● Confirm: Type cangetin
Click Next.
The Server Settings page appears.

c. Enter data in the Server Settings page as follows:

● Server URL: Verify that the default value is
https://zone1.example.com:20443.
● Cookie Domain: Verify that the default value is
.example.com.
When configuring load-balanced OpenSSO instances, you
configure the cookie domain with the same value for all the
instances.
● Configuration Directory: Type /opt/opensso/instance2
Click Next.
The Configuration Store page appears.
d. Click Add to Existing Deployment.
Enter data in the Configuration Store page as follows:
● Server URL: Type
Click Next.
The Site Configuration page appears.
e. Enter data in the Site Configuration page as follows:
● Will This Instance be Deployed Behind a Load Balancer?:
Select Yes.
● Site Name: Type WS7LB
● Primary URL: Type
Click Next.
The Configurator Summary Details page appears.
on the Configurator Summary Details page, make corrections as
necessary.
f. Click Create Configuration.
Progress messages inform you of configuration progress.
The Configuration Complete page appears.
Caution – In some environments, if you click the Proceed to Login link,

the Server Not Found page appears. Please refer to OpenSSO issues 2021
and 2765 for more information. Steps 3g through 3i are a workaround for
these two issues.

g. Stop the two Tomcat instances:

h. Verify that both Tomcat instances are down before you attempt
root 5306 4391 1 13:18:16 pts/4 1:37
i. Restart the two Tomcat instances:
browser.
5. The OpenSSO login screen appears.
Log in to OpenSSO as the amAdmin user. The password is cangetin.
6. The OpenSSO console start page appears.
7. Verify that the site configuration is correct:
a. Select the Configuration tab.
b. Select the Sites and Servers tab.
c. Note that a site named WS7LB is present, and that two servers
with the URLs https://zone1.example.com:10443/
opensso and https://zone1.example.com:20443/opensso
are assigned to the WS7LB site.

Task 5 – Testing the Load-Balanced, Multi-Instance

OpenSSO Deployment
In this task, you test your OpenSSO site. You access the site by navigating
to a URL that is passed to the load balancer—
http://zone1.example.com:8443/opensso
The load balancer forwards the request to one of the OpenSSO instances,
and that instance challenges you for authentication credentials. If you
authenticate correctly, the OpenSSO console appears on the screen.
You use the Sessions tab to determine the OpenSSO instance on which
your session resides.
Then you log out of the console, restart your browser, authenticate a
second time, and, again, determine which OpenSSO instance holds your
session. It should be the other instance.

1. In a terminal window, restart both Tomcat instances:
a. Stop the two Tomcat instances:
b. Verify that both Tomcat instances are down before you attempt
root 5306 4391 1 13:18:16 pts/4 1:37
c. Restart the two Tomcat instances:

2. In a browser, log in to the OpenSSO console:

a. Navigate to the following URL:
The login screen appears.
b. Log in as the amAdmin user. The password is cangetin.
3. Select the Sessions tab.
4. View the sessions that reside on the zone1.example.com:10443 and
zone2.example.com:20443 OpenSSO instances.
There should be a single session for the amAdmin user.
Note the server on which your session resides in the space below:
_________________________________________________
5. In your browser, examine the cookies in the example.com domain:
a. Examine the amblcookie cookie.
The amblcookie cookie is the sticky cookie that identifies the
OpenSSO instance on which your session resides.
When you configured content handling for the Web Server
reverse proxy plug-in in the previous lab, you specified that
Web Server should issue a sticky cookie named amlbcookie.
b. Examine the iPlanetDirectoryPro cookie.
The iPlanetDirectoryPro cookie holds session information.
This cookie is created after a user authenticates successfully to
an OpenSSO instance.
7. Look for the cookies in the example.com domain.
The cookies should be gone. Logging out of the OpenSSO console
terminates an OpenSSO session.
browser.
9. Repeat the process you followed in steps 2 through 8 several times.
OpenSSO sessions should be created on both the
zone1.example.com:10443 and zone2.example.com:20443
OpenSSO instances.

Exercise 2: Setting Up the OpenSSO Command-Line Tools
Exercise 2: Setting Up the OpenSSO Command-Line

Tools
In this exercise, you set up the OpenSSO command-line tools.
The command-line tools are distributed in the famAdminTools.zip file,

which is part of the OpenSSO distribution. Before you can use the
command-line tools, you must unzip the famAdminTools.zip file and
run a setup utility.
A separate file, the famSessionTools.zip file, contains additional

OpenSSO command-line tools that are used with the session failover
feature. You set up the session failover command-line tools in the
“Configuring Session Failover” lab.
Preparation
Task – Installing and Testing the famadm

Command-Line Interface
In this task, you install the OpenSSO command-line interface (CLI) on
both OpenSSO instances, then run a quick test that verifies that the CLI
works as expected.

2. Change to the OpenSSO instance1 directory and make a directory
for the CLI tools:
cd /opt/opensso/instance1
mkdir cli
3. Copy the .zip file that contains the CLI tools into the cli directory
that you just created:
cd cli
cp /opt/opensso/tools/famAdminTools.zip .

4. Unzip the CLI tools .zip file, then remove the .zip file from the cli
directory:
unzip famAdminTools.zip
rm famAdminTools.zip
5. Set up the OpenSSO CLI:
a. Start the setup script:
export JAVA_HOME
./setup
The setup script prompts you to enter the path to the server
configuration files:
Path to config files of server (example:
/fam_config/opensso):
b. Type /opt/opensso/instance1 and press Enter.
The following messages appear in the terminal window:
The scripts are properly setup under directory:
/opt/opensso/instance1/cli/opensso
The version of this tools.zip is: 8.0
The version of your server instance is: 8.0 (2008-
June-27 10:01)
6. Create a read-only file containing the amAdmin user’s password:
echo cangetin > /opt/opensso/instance1/password
chmod 400 /opt/opensso/instance1/password
You use the password file when executing the OpenSSO CLI.
7. Verify that the OpenSSO CLI works as expected by executing the
famadm command with the list-servers option:
/opt/opensso/instance1/cli/opensso/bin/famadm \
list-servers --adminid amAdmin \
--password-file /opt/opensso/instance1/password
The following output appears in the terminal window:
for the CLI tools:
mkdir cli

9. Copy the .zip file that contains the CLI tools into the cli directory
that you just created:
cd cli
cp /opt/opensso/tools/famAdminTools.zip .
10. Unzip the CLI tools .zip file, then remove the .zip file from the cli
directory:
unzip famAdminTools.zip
rm famAdminTools.zip
export JAVA_HOME
./setup
The setup script prompts you to enter the path to the server
configuration files:
Path to config files of server (example:
/fam_config/opensso):
b. Type /opt/opensso/instance2 and press Enter.
/opt/opensso/instance2/cli/opensso
The version of this tools.zip is: 8.0
The version of your server instance is: 8.0 (2008-
June-27 10:01)
12. Create a read-only file containing the amAdmin user’s password:
echo cangetin > /opt/opensso/instance2/password
chmod 400 /opt/opensso/instance2/password
You use the password file when executing the OpenSSO CLI.
13. Verify that the OpenSSO CLI works as expected by executing the
famadm command with the list-servers option:
/opt/opensso/instance2/cli/opensso/bin/famadm \
list-servers --adminid amAdmin \
--password-file /opt/opensso/instance2/password

Exercise Summary
Exercise Summary

!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Lab 3
Configuring Session Failover
Objectives
● Configure session failover for an OpenSSO site
● Verify that OpenSSO sessions fail over
Lab 3-1
Exercise 1: Configuring Session Failover for an OpenSSO Site
Exercise 1: Configuring Session Failover for an OpenSSO

Site
In this exercise, you configure session failover for an OpenSSO site.
In previous labs, you installed and configured two OpenSSO instances

behind a load balancer. The two OpenSSO instances plus the load
balancer comprise an OpenSSO site.
When a user logs in to an OpenSSO site, an OpenSSO session is

established for the user on one of the OpenSSO instances that comprise
the site. Since all the OpenSSO instances in a site use the same
configuration store, it does not matter which instance the session resides
on.
OpenSSO sessions are stored in random access memory (RAM), and are,
therefore, volatile. Without session failover, if a server on which an
OpenSSO instance goes down, the sessions are lost, and all the users who
had sessions on that server are forced to reauthenticate if they want to
access resources being protected by the OpenSSO site.
With the session failover feature enabled, sessions still reside in RAM, but
are also written to a persistent data store. If an OpenSSO instance goes
down, the session information stored in the OpenSSO instance is lost.
However, OpenSSO clients, such as the OpenSSO console or Policy
Agents, can connect to another OpenSSO instance. This other OpenSSO
instance can then determine that it does not have the session information
in memory and can retrieve it from the persistent data store.
Session failover uses the Sun Java System Message Queue (Message
Queue) software to communicate with the persistent data store.

● Install the session failover tools
● Encrypt the message queue password
● Configure settings in the amsfo.conf file
● Add a secondary configuration instance to the Session Service

Preparation
Prerequisite Labs
The following labs are prerequisites for performing this lab:

● “Preparing an Environment for a Complex OpenSSO Deployment”
● “Deploying a Multi-Instance OpenSSO Site”
the prerequisite labs, and whether you have performed other labs, in
addition to the prerequisite labs.
Lab System
State

‘‘Task 1 – Installing the
• After completing the Session Failover Tools’’
prerequisite labs, you did on page L3-7.
not power down the
learning virtual machine,
to the zone1 zone
Configuring Session Failover Lab 3-3

Lab System
State
preceding lab, you
powered down the

prerequisite labs

global # lab -p

Point for This Lab



is cangetin.
the zone:
zone1 # exit
global # lab -n 3
point for this lab.

to complete.

global # lab -p



containers
Your lab system is now ready for the lab. Proceed to ‘‘Task 1 – Installing
the Session Failover Tools’’ on page L3-7.

Task 1 – Installing the Session Failover Tools

In this task, you install the CLI for session failover on the first OpenSSO
instance.

for the session failover tools:
mkdir sfo

lab.
3. Copy the .zip file that contains the session failover tools into the
sfo directory that you just created:
cd sfo
cp /opt/opensso/tools/famSessionTools.zip .
4. Unzip the session failover tools .zip file, then remove the .zip file
from the sfo directory:
unzip famSessionTools.zip
rm famSessionTools.zip
export JAVA_HOME
./setup
The setup script prompts you to enter the directory into which
you want to install the session failover scripts:
Directory to install the scripts (example:
sfoscripts):

b. Type scripts and press Enter.

/opt/opensso/instance1/sfo/scripts
JMQ is properly setup under directory
/opt/opensso/instance1/sfo/jmq
6. Verify that the directories containing session failover scripts and
Message Queue software are present:
ls
The scripts and jmq directories should be present.
Note – In this lab, you deploy a single Message Queue broker on a single
Solaris OS zone, giving you an easy path to explore OpenSSO session
failover in the learning environment.
In production environments, the best practice is to deploy multiple

Message Queue brokers, each on its own host system, then cluster the
Message Queue brokers. Deploying clustered Message Queue brokers that
reside on separate hosts assures that if one of the hosts goes down,
Message Queue services are still available.
To deploy multiple Message Queue brokers, install the session failover

tools on each system that hosts a Message Queue broker.

Task 2 – Encrypting the Message Queue Password

In this task, you use the amsfopassword utility to encrypt the password
of the Message Queue software’s guest account.
In “Task 3 – Configuring Settings in the amsfo.conf File” you configure

the location of the encrypted password file in the amsfo.conf file.
Caution – In a production environment, you would probably not want to

use the guest account as part of your system configuration, but rather set
up a separate account with a secure password.

1. Change to the directory containing the amsfopassword script:
cd /opt/opensso/instance1/sfo/scripts/bin
2. Run the amsfopassword script, which creates an encrypted
password for the Message Broker guest account in the
/opt/opensso/instance1/sfo/mqpassword file:
./amsfopassword \
-f /opt/opensso/instance1/sfo/mqpassword -e guest
- os.name=SunOS
- SUCCESSFUL
3. Change privileges on the encrypted password file:
chmod 644 /opt/opensso/instance1/sfo/mqpassword

Task 3 – Configuring Settings in the amsfo.conf File

In this task, you configure settings in the amsfo.conf file. This file is read
by the amsfo script, which starts the Message Queue software.

1. Change to the directory containing the amsfo.conf configuration
file:
cd /opt/opensso/instance1/sfo/scripts/config/lib
2. Using any text editor, apply the following settings in the
amsfo.conf file:
a. Set the CLUSTER_LIST setting to the value
zone1.example.com:7777
The CLUSTER_LIST setting specifies hosts in the Message Queue
cluster that participate in the session failover deployment. In
this lab, you specify a single Message Queue broker instance to
make the learning environment as simple as possible to deploy.
In production environments, you would specify a
comma-delimited list of hosts in the CLUSTER_LIST setting to
provide high availability.
b. Set the PASSWORDFILE setting to the value
/opt/opensso/instance1/sfo/mqpassword
The PASSWORDFILE setting specifies the location of the file
containing the encrypted Message Queue password. You
created this file in “Task 2 – Encrypting the Message Queue
Password.”
c. Set the AMSESSIONDB_ARGS setting to the value "-v"
(including the quotes).
Setting the AMSESSIONDB_ARGS setting to the value "-v"
enables verbose logging of session failover operations. This
setting is normally not used in production environments. You
use this setting in this lab in order to review session failover
operations.
3. Save and close the amsfo.conf file.

Task 4 – Adding a Secondary Configuration Instance

to the Session Service
OpenSSO instances in a session failover deployment need to be able to
access one or more Message Queue brokers in order to retrieve OpenSSO
sessions.
You configure information about Message Queue brokers in the Session

Service by creating a secondary configuration instance.
Part of the secondary configuration instance is a check box that lets you
enable session failover. This check box is enabled by default, therefore,
when you create a new secondary configuration instance, session failover
is automatically enabled. Take note of this check box when you create
your secondary configuration instance.
At the end of this lab, you disable session failover by unchecking the
Session Failover Enabled check box.

1. Log in to the OpenSSO console as the amAdmin user. Use the
following URL:
The password is cangetin.
The OpenSSO console start page appears.
2. Select the Configuration tab.
3. Select the Global tab.
4. Select Session from the list of service names.
5. Locate the Secondary Configuration Instance panel.
6. Click New to create a new secondary configuration instance.
7. Enter data in the New Secondary Configuration Instance page as
follows:
● Session Store Password – Type guest
● Session Store Password (confirm) – Type guest
● Database Url – Type zone1.example.com:7777

8. Click Add.
The WS7LB secondary configuration instance appears in the Session
Service configuration.
9. Click Save.

Exercise 2: Verifying that OpenSSO Sessions Fail Over

In this exercise, you stop the OpenSSO instances, start the Message Queue
broker using the amsfo script, then start the OpenSSO instances to
activate an OpenSSO deployment with session failover enabled.
Then you shut down one of the servers to see what happens.

● Start the Message Queue broker and restart servers
● Test session failover
● Disable session failover
Preparation
Task 1 – Starting the Message Queue Broker and

Restarting Servers
In this task, you stop the OpenSSO instances, start the Message Queue
broker using the amsfo script, then start the OpenSSO instances. The
order of these actions is critical. If you start the Message Queue broker
when OpenSSO instances in a site are already up, session failover will not
be activated.
Review session failover log files to demonstrate that session failover is

active.


3. Verify that both Tomcat instances are down before you perform the
next step.
root 5306 4391 1 13:18:16 pts/4 1:37
4. Activate session failover by running the amsfo script with the start
argument:
/opt/opensso/instance1/sfo/scripts/bin/amsfo start
5. Start the two Tomcat instances:
6. Review the session failover log file:
more /tmp/amsession/logs/amsessiondb.log
You should see log records similar to the following:
Starting... true
/usr/jdk/instances/jdk1.5.0/jre/bin/java -Xms128m -
Xmx512m -classpath
/opt/opensso/instance1/sfo/jmq/mq/lib/imq.jar:/opt/open
sso/instance1/sfo/jmq/mq/lib/jms.jar:/opt/opensso/insta
nce1/sfo/ext/je.jar:/opt/opensso/instance1/sfo/locale:/
opt/opensso/instance1/sfo/lib/am_sessiondb.jar:.
com.sun.identity.ha.jmqdb.client.FAMHaDB
Initailizing and connecting to the Message Queue server
...
Checking for peer BDB daemon processes. Please wait ...
Successfully started.
7. Verify that the message, Successfully started, appears in the log
file.
This message indicates successful startup of session failover.

Task 2 – Testing Session Failover

Now, for some fun. Log in to one of the OpenSSO instances and
determine the instance on which your session resides. Then shut down
that instance. With session failover in effect, your session should migrate
to the other OpenSSO instance.
Review session failover log files to demonstrate that the session was
migrated.
Finish the task by disabling session failover to improve learning VM

performance in subsequent labs.

following URL:
2. Determine which instance your OpenSSO session is on:
a. Select the Sessions tab.
b. If your session appears in the Sessions tab, note the current
setting of the View drop list in the space below:
_____________________________________________
c. If your session is not present in the Sessions tab, select the other
OpenSSO instance using the View drop list. Your session should
now appear in the Sessions tab.
Note the current setting of the View drop list in the space
below:
_____________________________________________

3. Leaving the console open, use the terminal window to review the
session failover log file:
OP=WRITE
service=session
WRITE message received.
>>>>>>>>>>>>>> Write by Primary Key : -1279015892
OP=WRITE
service=session
The preceding log records indicate that a session was written to the
session database.
4. Shut down the OpenSSO instance on which your session resides:
● If your session resides on the zone1.example.com:10443
instance, shut down the first OpenSSO instance:
● If your session resides on the zone1.example.com:20443
instance, shut down the second OpenSSO instance:
5. Return to the OpenSSO console and use the View drop list to verify
that your session has migrated to the other OpenSSO instance:
● If your session originally resided on the
zone1.example.com:10443 instance, it now resides on the
zone1.example.com:20443 instance.
zone1.example.com:20443 instance, it now resides on the
zone1.example.com:10443 instance.
6. Verify that no active sessions appear when you display the Sessions
tab for the instance that you shut down in step 4.
You should see an error message indicating that sessions cannot be
viewed on this instance. This error message indicates that the
instance is down.

7. Review the session failover log file to confirm that session failover
has occurred:
OP=READ
service=session
READ message received.
>>>>>>>>>>>>>> Read by Primary Key : -1098220087
>>>>>>>>>>>>>> Found record !
OP=WRITE
service=session
OP=WRITE
service=session
The preceding log records indicate that a session was retrieved from
the session database to achieve failover.
8. Start the OpenSSO instance on which your original session resided:
zone1.example.com:10443 instance, start the first OpenSSO
instance:
zone1.example.com:20443 instance, start the second
OpenSSO instance:

Task 3 – Disabling Session Failover

For improved learning VM performance, it is best to shut down the
Message Queue broker and disable session failover if you are not using it.
You can restart the Message Queue broker and re-enable session failover
any time you would like to do so while performing other labs.

1. Disable session failover in the WS7LB secondary configuration
instance configuration:
a. In the OpenSSO console, select the Configuration tab.
b. Select the Global tab.
c. Select Session from the list of service names.
d. Locate the Secondary Configuration Instance panel.
e. Select the WS7LB secondary configuration instance.
f. Uncheck the Session Failover Enabled check box.
g. Click Save to save changes to the WS7LB secondary
configuration instance.
h. Click Save to save changes to the Session Service configuration.
4. Verify that both Tomcat instances are down before you perform the
next step.
root 5306 4391 1 13:18:16 pts/4 1:37
5. Stop the Message Queue broker:
/opt/opensso/instance1/sfo/scripts/bin/amsfo stop

6. Start the two Tomcat instances:

7. Which actions would you need to take to reactivate session failover
on the WS7LB site? Note your answer in the spaces below.
_________________________________________________
_________________________________________________
_________________________________________________
_________________________________________________
_________________________________________________

Exercise Summary
Exercise Summary

!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Lab 4
Installing a Web Policy Agent to Manage

Access to a Web Site
Objectives
● Deploy a Web Server instance that hosts a web site
● Prepare the environment for the Web Policy Agent installation
● Install and test the Web Policy Agent
Lab 4-1
Exercise 1: Deploying a Web Server Instance That Hosts a

Web Site
In this exercise, you deploy an example web site.
In this lab, you work with components that reside in two zones:
● The zone1 zone – The OpenSSO site, comprising load-balanced two
OpenSSO instances, resides in the zone1 zone.
You use the following URL to access the OpenSSO instances:
https://zone1.example.com:8443/opensso.
● The zone2 zone – A Sun Java System Web Server (Web Server)
instance serves the example web site in the zone2 zone. In a
subsequent exercise, you install Policy Agent software into the Web
Server instance to protect the example web site.
You use the following URL to access the example web site:
https://zone2.example.com:8080/index.html.
Note – If you configured session failover in the “Configuring Session

Failover” lab, you disabled it at the end of the lab. Session failover is not
enabled in any other labs.
You start the exercise by starting the load balancer and the OpenSSO
instances in the zone1 zone. Then you install the sample web site in the
zone2 zone.

● Copy the local CA certificate into the zone2 zone
● Install Web Server software
● Install the local CA certificate into the Web Server instance

Preparation
Prerequisite Labs

● “Configuring Session Failover”
Lab System
State

‘‘Task 1 – Copying the
• After completing the Local CA Certificate
prerequisite labs, you did Into the zone2 Zone’’ on
not power down the page L4-7.
to the zone1 zone
Installing a Web Policy Agent to Manage Access to a Web Site Lab 4-3
Lab System
State
preceding lab, you
powered down the

prerequisite labs

global # lab -p

Point for This Lab



is cangetin.
the zone:
zone1 # exit
global # lab -n 4
point for this lab.

to complete.

global # lab -p


containers
Note – Session failover is not used in this lab, so there is no need to start
the message queue broker.

Your lab system is now ready for the lab. Proceed to ‘‘Task 1 – Copying
the Local CA Certificate Into the zone2 Zone’’ on page L4-7.

Task 1 – Copying the Local CA Certificate Into the

zone2 Zone
In this task, you copy the local CA certificate stored in the zone1 zone’s
/opt/certs.LocalCA.crt file to the /opt/certs.LocalCA.crt file in
the zone2 zone.
This is the only task in this lab that requires you to log in to the zone1
zone. You perform all remaining tasks and exercises in the zone2 zone.


lab.
2. If you are not logged in to the zone1 zone, log in to the zone1 zone.
3. Change to the directory containing the certificate for the local CA:
cd /opt/certs
4. Display the local CA certificate in the terminal window:
cat LocalCA.crt
5. Copy the certificate contents—the output from the cat command—
to a copy-and-paste buffer.
Be sure to copy the entire certificate, including the -----BEGIN
CERTIFICATE----- and -----END CERTIFICATE----- labels, into
the copy-and paste buffer.
6. Log out of the zone1 zone:
exit
7. Boot up and log in to the zone2 zone:
zlogin zone2
You perform the rest of this lab in the zone2 zone.
8. Create a directory in which you can store certificates in the zone2

zone:
cd /opt
mkdir certs
9. Change to the zone2 zone’s certificate directory:
cd /opt/certs
10. Using any text editor, create a new file named LocalCA.crt in the
zone2 zone’s certificate directory.
11. Paste the content in the copy-and-paste buffer into the LocalCA.crt
file.
12. Save and close the LocalCA.crt file.
13. Change permissions on the LocalCA.crt file:
chmod 666 LocalCA.crt
Note – You import the LocalCA.crt file into the Web Server instance that
you install later in this lab. Importing a certificate file into a Web Server
instance requires execute permission.
Task 2 – Installing Web Server Software

In this task, you install Web Server software.
During Web Server installation, you set the document root setting to the
/opt/ses/lab/site directory. The /opt/ses/lab/site directory
contains the example web site.
Following Web Server installation, you navigate to the URL,

https://zone2.example.com:8080, and browse the example web site.

1. Run the following command to start software installation:
/opt/ses/shared/software/webserver-v7u2/setup
2. Reply to the installer dialog boxes as follows:
a. Welcome: Click Next.
b. Software License Agreement: Select Yes, then click Next.

c. Software Installation Directory: Type /opt/webserver and

click Next.
d. Click Yes in response to the Create New Directory dialog box.
e. Select the Type of Installation: Choose Custom, and click Next.
f. Component Selection: Click Next.
g. Java Configuration: Click Next.
h. Administration Options: Click Next.
i. Administration Server Settings:
● Runtime User ID: Type webservd
● Administrator User Name: Type admin
● Administrator Password: Type cangetin
● Retype Password: Type cangetin
Click Next.
j. Web Server Settings:
● Select Use the Following Directory as the Document Root.
● Document Root Directory: Type /opt/ses/lab/site
Click Next.
k. Ready to Install: Click Install Now.
The Installing dialog box appears and informs you of
installation progress.
l. Installation Complete: Click Finish.
3. Start the Web Server instance:
/opt/webserver/https-zone2.example.com/bin/startserv
4. In a browser, navigate to the following URL:
You should see the Example Chocolates web site home page.
Task 3 – Installing the Local CA Certificate Into the

Web Server Instance
In this deployment, the Web Server that serves the example web site is not
SSL-enabled. However, this Web Server instance sends requests to the
SSL-enabled OpenSSO site after Policy Agent installation, which you
perform in “Exercise 3: Installing and Testing the Web Policy Agent.”
Therefore, the Web Server must have the local CA certificate in its
certificate database, or SSL handshaking fails when the Policy Agent
attempts to access the OpenSSO site.
Use the Web Server wadm CLI to install the local CA certificate in the Web
Server instance’s certificate database.

1. Start the wadm CLI:
/opt/webserver/bin/wadm --host zone2.example.com \
--port 8989 --user admin
The following prompt appears:
Please enter admin-user-password>
Caution – For some users, the following message appears:
CLI104 Unable to communicate with the administration

server: Unexpected end of file from server
After this message appears, users are not able to run the wadm shell. This
bug is Web Server bug number CR6687299.
If you encounter this bug, you might be able to circumvent it by adding

the following directive to the /opt/webserver/admin-server/config/
server.xml file:
<jvm-options>-XX:LargePageSizeInBytes=4194304</jvm-options>
Add the preceding directive to the <jvm> section of the server.xml file,
together with the other <jvm-options> directives. Then restart the Web
Server administration server as follows:
/opt/webserver/admin-server/bin/stopserv
/opt/webserver/admin-server/bin/startserv

If the preceding circumvention is unsuccessful, you can work around the

problem by taking the following actions:
1. Download Web Server 7.0 Update 3 from http://www.sun.com.

2. Install Web Server 7.0 Update 3 in the zone2 zone
3. Use Web Server 7.0 Update 3 for the remainder of this lab, instead of
using the version of Web Server provided with the learning VM.
2. Type cangetin.
Connected to zone2.example.com:8989
Sun Java System Web Server 7.0U2 B12/09/2007 07:28
wadm>
3. Do not press Return while typing the following:
install-cert --config=zone2.example.com --cert-type=ca
--nickname=localca /opt/certs/LocalCA.crt
CLI201 Command 'install-cert' ran successfully
wadm>
4. Type the following command:
deploy-config --restart zone2.example.com
CLI201 Command 'deploy-config' ran successfully
wadm>
5. Type exit to terminate the wadm CLI.
6. Verify that the local CA certificate is present in the Web Server
instance’s certificate database:
/usr/sfw/bin/certutil -L \
-d /opt/webserver/https-zone2.example.com/config
The entry, LocalCA - example.com, should be the only entry in the
list.
Exercise 2: Preparing the Environment for the Web Policy Agent Installation
Exercise 2: Preparing the Environment for the Web Policy

Agent Installation
In this exercise, you perform several tasks that are either required or
beneficial before installing a Policy Agent:
● You must install the CA certificates of any CAs that signed server
certificates for the OpenSSO site into the certificate store of the JVM
that the Policy Agent installer uses.
If you do not install needed certificates into the JVM certificate store,
Policy Agent installation fails in the next exercise.
● You create an agent administrator user and delegate administrative
privileges to that user.
While it is not required to have a separate agent administrator user—
you could use the amAdmin user to perform agent administration—it
might be useful depending on your production environment.
Additionally, creating this user lets you explore the OpenSSO
delegated administration capability.
● You create an agent profile in the OpenSSO console. Agent profiles
contain the agent configuration.
You can either create an agent profile in advance of agent
installation, as you do in this exercise, or during agent installation.
● You create a file containing the password for the agent profile.

● Prepare the JVM key store for Policy Agent installation
● Create a agent administrator
● Log in as the agent administrator and create an agent profile
● Copy the Policy Agent software and create a password file for the
agent profile
Preparation

Task 1 – Preparing the JVM Key Store for Policy Agent

Installation
The Policy Agent installer program, which you run in “Exercise 3:
Installing and Testing the Web Policy Agent,” accesses the SSL-enabled
OpenSSO site.
In order for the installer program to successfully access the OpenSSO site,
you must install the CA certificate of the CA that signed server certificates
for the OpenSSO site into the certificate store of the JVM that the Policy
Agent installer uses.

2. Store the local CA certificate in the JVM certificate store.
● Command:
-storepass changeit -alias localca \
-file LocalCA.crt
● Script:
/opt/ses/lab/scripts/importLocalCACertIntoJVM
stores:
Task 2 – Creating an Agent Administrator

In this task, you create an agent administrator user for managing agent
profiles.
When the agent administrator user logs in to the OpenSSO console, the
only information available to the user pertains to agent profiles. Other
information, such as realm definitions, authentication configuration, and
policy definitions, is hidden from the agent administrator user.
Using the agent administrator user to administer agent profiles illustrates

the OpenSSO delegated administration facility. It is not required that you
delegate agent profile administration to a special user. You could perform
agent profile administration using the amAdmin user account. But it might
be useful in some production environments to restrict OpenSSO console
access.
Other types of delegated administration supported out-of-the-box in

OpenSSO include the following:
● Policy administration
● Log file administration

following URL:
2. Create an agent administrators group named agentadmins:
a. Select the Access Control tab.
b. Select the opensso realm.
c. Select Subjects.
d. Select Group.
e. Click New.
The New Group page appears.
f. Enter data in the New Group page as follows:
● ID – Type agentadmins

g. Click OK.
The agentadmins group appears in the groups list.
3. Create an agent administrator user named agentadmin:
a. Select the User tab.
b. Click New.
The New User page appears.
c. Enter data in the New User page as follows:
● ID – Type agentadmin
● First Name – Type Agent
● Last name – Type Administrator
● Full Name – Type Agent Administrator
● Password – Type cangetin
● Password (confirm) – Type cangetin
● User Status – Select Active.
d. Click OK
The Agent Administrator user appears in the users list.
4. Make the agentadmin user a member of the agentadmins group:
e. Select the Group tab.
f. Select agentadmins
g. Select the User tab.
h. Select the Agent Administrator user from the Available column.
i. Click Add.
The Agent Administrator user entry moves from the Available
column to the Selected column.
j. Click Save.
5. Assign administrative privileges to the agent administrators group:
a. Click Back to Subjects.
b. Select the Privileges tab.
c. Select the agentadmins group.
d. Select the Read And Write Access to All Configured Agents
privilege.
e. Click Save.

7. When you configured OpenSSO in the “Deploying a Multi-Instance
OpenSSO Site” lab, you specified that user entries are stored in an
embedded user store.
Run the following command in the terminal window to review user
and group entries in the embedded user store:
ldapsearch -b dc=opensso,dc=java,dc=net \
-h zone1.example.com -p 50389 \
-D "cn=Directory Manager" -w cangetin "cn=*" dn
Using the ldapsearch command to review the content of OpenSSO
user stores can be helpful while troubleshooting OpenSSO issues.
Note – The embedded user store’s cn=Directory Manager user has, on

default, the same password as the OpenSSO amAdmin user.

Task 3 – Logging in as the Agent Administrator and

Creating an Agent Profile
In this task, you log in to the OpenSSO console as the agent administrator
user and define an agent profile. Then you enable a load-balancing option
in the agent profile, so that the Policy Agent correctly handles the load-
balanced OpenSSO site.

1. Log in to the OpenSSO console as the agentadmin user. Use the
following URL:
The OpenSSO console start page appears. The Access Control tab is
the only tab on the start page.
If you see the normal OpenSSO start page, you probably logged in as
the amAdmin user. If you see the normal OpenSSO start page, then
log out of the console, and log back in as the agentadmin user.
When you logged in to the OpenSSO console in previous steps, you
logged in as the amAdmin user. The amAdmin user has privileges to
modify all OpenSSO configuration.
Now, you log in as the agentadmin user. The agentadmin user has
limited privileges. Because of this, the agentadmin user is given
access only to those portions of the OpenSSO console that this user is
permitted to modify.
2. Create an agent profile for the Web Policy Agent you install in the
next exercise:
a. Select the opensso realm.
The Agents tab appears. It is the only tab page that is available.
b. Select the Web tab.
c. Locate the Agent panel.
d. Click New.
The New Agent page appears.
e. Enter data in the New Agent page as follows:

● Name – Type zone2-ws
● Re-enter Password – Type cangetin
● Configuration – Select Centralized.
● Server URL – Type
● Agent URL – Type http://zone2.example.com:8080
f. Click Create.
The zone2-ws agent profile appears in the agents list.
3. Configure load balancing support in the agent profile:
a. Select the zone2-ws agent.
b. Select the Advanced tab.
c. Locate the Load Balancer Setup option.
d. Check the Enabled check box to let the Policy Agent that uses
this agent profile support load-balanced OpenSSO servers.
e. Click Save.
5. Run the following commands in the terminal window to review the
entry for the agent profile in the embedded user store:
a. Run the following command to list the entire agent profile
directory entry:
-D "cn=Directory Manager" -w cangetin "ou=zone2*"
b. Run the following command to list the portion of the agent
profile directory entry pertinent to the load balancing
configuration:
-D "cn=Directory Manager" -w cangetin "ou=zone2*" \
| grep load

Task 4 – Copying the Policy Agent Software and

Create a Password File for the Agent Profile
In this task, you copy the Policy Agent binaries to the zone2 zone and
create a file containing the password for the agent profile. This password
is the same password you specified when you created the agent profile in
“Task 3 – Logging in as the Agent Administrator and Creating an Agent
Profile.”

1. Copy the Web Policy Agent software to a local directory:
cd /opt
cp -r /opt/ses/shared/software/ \
agent-v3.20080627-webserver-v7 .
2. Create a file containing the password for the agent profile in the
Policy Agent software directory:
cd agent-v3.20080627-webserver-v7/web_agents/ \
sjsws_agent
3. Set permissions on the password file to read-write only by the file
owner:
chmod 600 password
Exercise 3: Installing and Testing the Web Policy Agent

In this exercise, you install Policy Agent software to protect the web site.
Then you verify that the Policy Agent protects the example web site.
You start the exercise by installing the Policy Agent in the zone2 zone.
Then, you verify that the Policy Agent protects the example web site by
demonstrating that in order to access the web site, you must first
authenticate to OpenSSO.

● Install the Web Policy Agent software
● Restart servers
● Test the Web Policy Agent
Preparation
Task 1 – Installing the Web Policy Agent Software

In this task, you stop the Web Server instance that serves the example site,
then you install the Web Policy Agent software using the agentadmin
program.
After the installation has completed, you examine the log files to verify
that no installation errors occurred.

2. Stop the Web Server instance that serves the example site:
/opt/webserver/https-zone2.example.com/bin/stopserv
3. Change to the directory that contains the Web Policy Agent
installation program:
cd /opt/agent-v3.20080627-webserver-v7/web_agents/ \
sjsws_agent/bin

4. Install the Web Policy Agent software:

./agentadmin --install
5. Respond to prompts from the agentadmin program as follows:
a. Please read the license agreement carefully – Type n and press
Return.
b. Do you completely agree with all the terms and conditions of
this License Agreement – Type yes and press Return.
c. Sun Java System Web Server Config Directory Path – Type
/opt/webserver/https-zone2.example.com/config and
press Return.
d. Access Manager URL – Type
https://zone1.example.com:8443/opensso and press
Return.
e. Agent URL – Type http://zone2.example.com:8080 and
press Return.
f. Agent Profile name – Type zone2-ws and press Return.
g. Path to the password file – Type /opt/agent-v3.20080627-
webserver-v7/web_agents/sjsws_agent/password and
press Return.
Text appears with a summary of your responses. Verify that you
have entered your responses exactly as described in the
preceding steps.
h. Please make your selection - Type 1 and press Return.
6. After Policy Agent installation has completed, review the Policy
Agent installation log file to verify that installation was successful.
The installation log file is located at the following path:
/opt/agent-v3.20080627-webserver-v7/web_agents/
sjsws_agent/installer-logs/audit/install.log
Task 2 – Restarting Servers

In this task, you change permissions on the Policy Agent configuration
files. Changing permissions is necessary, because you installed the Policy
Agent as the root user, but the Web Server runs as the webservd user.
After you change file permissions, you restart the Web Server.

1. Change to the directory containing Policy Agent files:
cd /opt/agent-v3.20080627-webserver-v7/web_agents/ \
sjsws_agent
2. Change the ownership of the Policy Agent files:
chown -R webservd:webservd Agent_001
3. Start the Web Server instance that is protected by the Policy Agent:
/opt/webserver/https-zone2.example.com/bin/startserv
Task 3 – Testing the Web Policy Agent

Now you are ready to verify that the Policy Agent protects the example
web site.
Start a new browser session and attempt to access the example web site.
The Policy Agent should intercept your request to access the site and
redirect the request to the OpenSSO site, which then challenges you for
authentication credentials.

1. Clear cache and remove cookies from your current browser session.
2. Shut down the browser.
3. Restart the browser.


Previously, you saw the Example Chocolates web site home page
after navigating to the preceding URL.
Now, the OpenSSO log in screen appears.
The Policy Agent is protecting the Example Chocolates web site. In
order to gain access to the web site:
● You must supply valid authentication credentials.
● The OpenSSO administrator must configure a policy that lets
users access the site.
5. In a terminal window, stop the Web Server instance that is protected
by the Policy Agent:
/opt/webserver/https-zone2.example.com/bin/stopserv
Note – For improved learning VM performance, it is best to shut down

the Web Server instance if you are not using it. You can restart the Web
Server instance any time you would like to do so while performing other
labs.
Exercise Summary
Exercise Summary

!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Lab 5
Installing a J2EE Policy Agent to Manage

Access to J2EE Applications
Objectives
● Deploy a GlassFish application server instance
● Prepare the environment for the J2EE Policy Agent installation
● Install and test the J2EE Policy Agent
Lab 5-1
Exercise 1: Deploying a GlassFish Application Server Instance
Exercise 1: Deploying a GlassFish Application Server

Instance
In this exercise, you deploy a GlassFish application server (GlassFish)
instance.
In this lab, you work with components that reside in two zones:
● The zone1 zone – The OpenSSO site, comprising load-balanced two
OpenSSO instances, resides in the zone1 zone.
You use the following URL to access the OpenSSO instances:
https://zone1.example.com:8443/opensso.
● The zone2 zone – A GlassFish instance serves J2EE applications in
the zone2 zone. In a subsequent exercise, you install Policy Agent
software into the GlassFish instance to protect J2EE applications
served by the GlassFish instance.
You use the following URL to access the GlassFish instance:
https://zone2.example.com:8080/ndex.html.
Note – If you configured session failover in the “Configuring Session

Failover” lab, you disabled it at the end of that lab. Session failover is not
required for this lab.
If you deployed an example web site and protected it with a Web Policy
Agent in the “Installing a Web Policy Agent to Manage Access to a Web
Site” lab, you stopped the Web Server instance at the end of the lab. The
Web Server instance is not needed for this lab.

● Install GlassFish application server software
● Install the local CA certificate into the domain administration server
key store

Preparation
Prerequisite Labs

● “Configuring Session Failover”
● “Installing a Web Policy Agent to Manage Access to a Web Site”
Lab System
State

‘‘Task 1 – Installing
• After completing the GlassFish Application
prerequisite labs, you did Server Software’’ on
not power down the page L5-7.
to the zone1 zone
Installing a J2EE Policy Agent to Manage Access to J2EE Applications Lab 5-3
Lab System
State
preceding lab, you
powered down the

prerequisite labs

global # lab -p

Point for This Lab



is cangetin.
the zone:
zone1 # exit
global # lab -n 5
point for this lab.

to complete.

global # lab -p


containers
Note – Session failover is not used in this lab, so there is no need to start
the message queue broker.
The web site that you deployed in the “Installing a Web Policy Agent to
Manage Access to a Web Site” lab is not used in this lab, so there is no
need to start the Web Server instance that serves the web site.

Your lab system is now ready for the lab. Proceed to ‘‘Task 1 – Installing
GlassFish Application Server Software’’ on page L5-7.

Task 1 – Installing GlassFish Application Server

Software
In this task, you install the GlassFish software.


lab.
2. If you have not booted up the zone2 zone, do so using the following
command:
3. If you are not logged in to the zone2 zone, log in to the zone2 zone:
zlogin zone2
You perform the rest of this lab in the zone2 zone.
4. Copy the GlassFish software to a local directory:
cd /opt
cp /opt/ses/shared/software/glassfish-v2ur2/ \
glassfish-installer-v2ur2-b04-sunos_x86.jar .
5. Set the JAVA_HOME environment variable:
export JAVA_HOME
The GlassFish installer requires this setting.
6. Install the GlassFish software:
java -Xmx256m -jar \
glassfish-installer-v2ur2-b04-sunos_x86.jar
A dialog box with the GlassFish license appears.
7. Scroll to the bottom of the license agreement, then click Accept.
Messages appear in the terminal window as GlassFish installation
proceeds.
When installation is complete, the Installation Complete
message appears in the terminal window.
8. Delete the GlassFish installer (to save disk space in the learning VM):
rm glassfish-installer-v2ur2-b04-sunos_x86.jar
9. Configure the GlassFish instance as a non-clustered instance:
a. Set the ANT_HOME environment variable:
ANT_HOME=/opt/glassfish/lib/ant
export ANT_HOME
GlassFish setup requires this setting.
b. Change permissions on the ant binary so that it this binary
executable:
chmod -R +x $ANT_HOME/bin
c. Set up the GlassFish instance:
$ANT_HOME/bin/ant -f /opt/glassfish/setup.xml
10. Start the GlassFish domain administration server (DAS):
/opt/glassfish/bin/asadmin start-domain domain1
In this lab, you deploy the sample J2EE application to the DAS as a
convenience for learning purposes. When you install the Policy
Agent later in this lab, you install it on the DAS, so that the Policy
Agent protects the sample J2EE application.
In this lab, you do not create additional GlassFish instances. To
protect J2EE applications deployed to GlassFish instances other than
the DAS, install Policy Agent software on those instances.
11. Verify that you can run the administration console for the GlassFish
instance:
a. In a browser, navigate to the following URL:
You should see the GlassFish login screen.
b. Log in to the console as the admin user. The password is
adminadmin.
c. The console main page appears.
d. Log out of the console.

Task 2 – Installing the Local CA Certificate Into the

Domain Administration Server Key Store
When you install the Policy Agent later in this lab, you install it on the
DAS, so that the Policy Agent protects J2EE applications running on the
DAS.
In this deployment, the DAS is not SSL-enabled. However, the DAS sends
requests to the SSL-enabled OpenSSO site after Policy Agent installation,
which you perform in “Exercise 3: Installing and Testing the J2EE Policy
Agent.”
Therefore, the DAS must have the local CA certificate in its certificate
store, or SSL handshaking fails after the Policy Agent attempts to access
the OpenSSO site.

1. Store the local CA certificate in the JVM certificates store.
● Command:
/opt/glassfish/domains/domain1/config/cacerts.jks \
-storepass changeit -alias localca -trustcacerts \
-file LocalCA.crt
Respond yes to the following prompt:
Certificate already exists in system-wide CA
keystore under alias <localca> prompt.
Do you still want to add it to your own keystore?
[no]:
● Script:
/opt/ses/lab/scripts/importLocalCACertIntoDomain
Respond yes to the following prompt:
Certificate already exists in system-wide CA
keystore under alias <localca> prompt.
Do you still want to add it to your own keystore?
[no]:
stores:
/opt/glassfish/domains/domain1/config/cacerts.jks \

Exercise 2: Preparing the Environment for the J2EE Policy Agent Installation
Exercise 2: Preparing the Environment for the J2EE Policy

Agent Installation
In this exercise, you perform several tasks that are either required or
beneficial before installing a Policy Agent:
● You create an agent profile in the OpenSSO console. Agent profiles
contain the agent configuration.
You can either create an agent profile in advance of agent
installation, as you do in this exercise, or during agent installation.
● You create a file containing the password for the agent profile.
Note – Prior to Policy Agent installation, you would normally:
– Install the CA certificates of any CAs that signed server certificates for
the OpenSSO site into the certificate store of the JVM that the Policy
Agent installer uses
– Create an agent administrator, if you wanted to delegate agent

administration tasks
Both of these tasks were performed in the “Installing a Web Policy Agent
to Manage Access to a Web Site” lab and need not be repeated in this lab.

● Log in as the agent administrator and create an agent profile
● Copy the Policy Agent software and create a password file for the
agent profile
Preparation
Task 1 – Logging in as the Agent Administrator and

Creating an Agent Profile
In this task, you log in to the OpenSSO console as the agent administrator
user and define an agent profile.
You created the agent administrator user in the “Installing a Web Policy
Agent to Manage Access to a Web Site” lab.

1. Log in to the OpenSSO console as the agentadmin user. Use the
following URL:
The OpenSSO console start page appears. The Access Control tab is
the only tab on the start page.
If you see the normal OpenSSO start page, you probably logged in as
the amAdmin user. If you see the normal OpenSSO start page, then
log out of the console, and log back in as the agentadmin user.
2. Create an agent profile for the J2EE Policy Agent you install in a
subsequent exercise:
a. Select the opensso realm.
The Agents tab appears. It is the only tab page that is available.
b. Select the J2EE tab.
c. Locate the Agent panel.
d. Click New.
The New Agent page appears.

e. Enter data in the New Agent page as follows:

● Name – Type zone2-gf
● Re-enter Password – Type cangetin
● Configuration – Select Centralized.
● Server URL – Type
● Agent URL – Type
http://zone2.example.com:8080/agentapp
f. Click Create.
The zone2-gf agent profile appears in the agents list.
Task 2 – Copying the Policy Agent Software and

Creating a Password File for the Agent Profile
In this task, you copy the Policy Agent binaries to the zone2 zone and
create a file containing the password for the agent profile. This password
is the same password you specified when you created the agent profile in
“Task 1 – Logging in as the Agent Administrator and Creating an Agent
Profile.”

1. Copy the J2EE Policy Agent software to a local directory:
cd /opt
cp -r /opt/ses/shared/software/ \
agent-v3.20080627-appserver-v9 .
2. Create a file containing the password for the agent profile in the
Policy Agent software directory:
cd agent-v3.20080627-appserver-v9/j2ee_agents/ \
appserver_v9_agent
3. Set permissions on the password file to read-write only by the file
owner:
chmod 600 password
Exercise 3: Installing and Testing the J2EE Policy Agent

In this exercise, you install Policy Agent software to protect J2EE
applications deployed on the GlassFish instance. Then you verify that the
Policy Agent protects the sample J2EE application.
You start the exercise by installing the Policy Agent in the zone2 zone.
Then you deploy the Agent application and the Policy Agent sample
application on the GlassFish instance.
Finally, you verify that the Policy Agent protects the sample application
by demonstrating that in order to access the sample application, you must
first authenticate to OpenSSO.

● Install the J2EE Policy Agent software
● Deploy the Agent application
● Deploy the sample application
● Test the J2EE Policy Agent
Preparation
Task 1 – Installing the J2EE Policy Agent Software

In this task, you stop the DAS, then you install the J2EE Policy Agent
software using the agentadmin program.
After the installation has completed, you examine the log files to verify
that no installation errors occurred, then restart the DAS.

2. Stop the DAS:
/opt/glassfish/bin/asadmin stop-domain domain1

3. Change to the directory that contains the J2EE Policy Agent

installation program:
cd /opt/agent-v3.20080627-appserver-v9/j2ee_agents/ \
appserver_v9_agent/bin
4. Grant the agentadmin file executable permission:
chmod +x agentadmin
5. Install the Web Policy Agent software:
./agentadmin --install
6. Respond to prompts from the agentadmin program as follows:
a. Please read the license agreement carefully – Type n and press
Return.
b. Do you completely agree with all the terms and conditions of
this License Agreement – Type yes and press Return.
c. Application Server Config Directory Path – Type
/opt/glassfish/domains/domain1/config and press Return.
d. Federated Access Manager URL – Type
https://zone1.example.com:8443/opensso and press
Return.
e. Agent URL – Type
http://zone2.example.com:8080/agentapp and press
Return.
f. Agent Profile name – Type zone2-gf and press Return.
g. Path to the password file – Type /opt/agent-v3.20080627-
appserver-v9/j2ee_agents/appserver_v9_agent/
password and press Return.
Text appears with a summary of your responses. Verify that you
have entered your responses exactly as described in the
preceding steps.
h. Please make your selection - Type 1 and press Return.
7. After Policy Agent installation has completed, review the Policy
Agent installation log file to verify that installation was successful.
The installation log file is located at the following path:
/opt/agent-v3.20080627-appserver-v9/j2ee_agents/
appserver_v9_agent/installer-logs/audit/install.log
8. Start the DAS:
/opt/glassfish/bin/asadmin start-domain domain1
Task 2 – Deploying the Agent Application

In this step, you deploy the J2EE Policy Agent web application, which is
distributed as the agentapp.war file.
The agent application a housekeeping application that receives notifications

from an OpenSSO server and passes them on to the Policy Agent. You
should always deploy the agent application after installing J2EE Policy
Agent software on an application server.

1. Deploy the agent application using the asadmin CLI:
/opt/glassfish/bin/asadmin deploy --user admin \
/opt/agent-v3.20080627-appserver-v9/j2ee_agents/ \
appserver_v9_agent/etc/agentapp.war
2. Verify that the agent application was deployed:
/opt/glassfish/bin/asadmin list-components --user admin
agentapp <web-module> appears in the list of components
deployed to the GlassFish instance.
Task 3 – Deploying the Sample Application

In this step, you deploy the Policy Agent sample J2EE application on the
GlassFish DAS.
The sample application is distributed as part of the J2EE Policy Agent

software. While not required, deploying and running the sample
application provides a convenient test of whether Policy Agent
installation and configuration has been successful.

1. Deploy the sample J2EE application using the asadmin CLI:
/opt/glassfish/bin/asadmin deploy --user admin \
/opt/agent-v3.20080627-appserver-v9/j2ee_agents/ \
appserver_v9_agent/sampleapp/dist/agentsample.ear
2. Verify that the sample application was deployed:
/opt/glassfish/bin/asadmin list-components --user admin
agentsample <j2ee-application> appears in the list of
components deployed to the GlassFish instance.

Task 4 – Testing the J2EE Policy Agent

Now you are ready to verify that the Policy Agent protects the sample
J2EE application.
Start a new browser session and attempt to access the sample application.
The Policy Agent should intercept your request to access the application
and redirect the request to the OpenSSO site, which then challenges you
for authentication credentials.

1. Clear cache and remove cookies from your current browser session.
2. Shut down the browser.
3. Restart the browser.
http://zone2.example.com:8080/agentsample
The OpenSSO log in screen appears.
The Policy Agent is protecting the sample application. In order to
gain access to the sample application:
● You must supply valid authentication credentials.
● The OpenSSO administrator must configure a policy that lets
users access the application.
5. In a terminal window, stop the DAS:
/opt/glassfish/bin/asadmin stop-domain domain1
Note – For improved learning VM performance, it is best to shut down

the GlassFish instance if you are not using it. You can restart the GlassFish
instance any time you would like to do so while performing other labs.
Exercise Summary
Exercise Summary

!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Wsplam3508d SW 5

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Wsplam3508d SW 5

Загружено:

Авторское право:

Доступные форматы

OpenSSO Deployment

Student Workbook for Self-Paced Lab Users

Sun Microsystems, Inc.

Export Commodity Classification Number (ECCN) assigned: 11 August 2008

viii OpenSSO Deployment

About This Workbook

Additional resources – Indicates other references that provide additional

Discussion – Indicates a small-group or class discussion on the current

Caution – Indicates that there is a risk of personal injury from a

Preface-x OpenSSO Deployment

Courier is also used to indicate programming constructs, such as class

Courier italics is used for variables and command-line placeholders

Courier italic bold represents variables whose values are to be

About This Workbook Preface-xi

Preface-xii OpenSSO Deployment

Preparing an Environment for a Complex

Exercise 1: Logging in to, Starting Zones on, and

There are no prerequisite labs for performing this lab.

Task 1 – Assessing the State of Your Lab System

In this task, you assess the state of your lab system.

Table 1-1 Lab System Start States and Instructions

Not at You completed other labs in Perform the steps in the

Lab 1-2 OpenSSO Deployment

Task 2 – Starting the Learning Virtual Machine

Perform the following steps:

Caution – When possible, examples in this course demonstrate security

Task 3 – Bringing the Learning Virtual Machine to the Starting

Perform the following steps:

Preparing an Environment for a Complex OpenSSO Deployment Lab 1-3

6. Run the lab -n command, which brings the learning virtual

Note – In many cases, the lab -n command processes large quantities of

7. Prepare the learning VM zones for doing these lab exercises:

Task 4 – Starting the zone1 Zone

Perform the following steps:

Lab 1-4 OpenSSO Deployment

Task – Navigating Around The Learning VM

Complete the following steps:

Caution – If you skipped ‘‘Preparation’’ on page L1-2, please go back now

3. Change to the /opt/ses/shared/software directory:

Preparing an Environment for a Complex OpenSSO Deployment Lab 1-5

4. List the content in the /opt/ses/shared/software directory:

Note – Four zones are available on the learning VM. The

If you would like to learn how a directory can be shared as a read-only

5. Review the following locations from which software was

Lab 1-6 OpenSSO Deployment

b. Using the browser, navigate to the locations from which

Preparing an Environment for a Complex OpenSSO Deployment Lab 1-7

Lab 1-8 OpenSSO Deployment

Exercise 2: Installing and Configuring Apache Tomcat for

In this exercise, you perform the following tasks:

Preparing an Environment for a Complex OpenSSO Deployment Lab 1-9

Task 1 – Installing Tomcat Software

Complete the following steps:

Lab 1-10 OpenSSO Deployment

Task 2 – Configuring Tomcat Port Numbers

Complete the following steps:

Preparing an Environment for a Complex OpenSSO Deployment Lab 1-11

Task 3 – Modifying Tomcat Start Pages

Complete the following steps:

Note – It is not necessary to remove DOS end-of-line characters from the

3. Using any text editor, edit the start page—the

Lab 1-12 OpenSSO Deployment