Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0

Part II Building the Environment

This second part of Deployment Example: Single Sign-On, Load Balancing and Failover Using Sun OpenSSO Enterprise 8.0 provides the instructions for installing and configuring the deployment and its components. Best results will be obtained by executing the tasks in the exact sequence in which they are presented. This part contains the following chapters:

Caution –

If deviating from the task sequence or details described, refer to the relevant product documentation for information or necessary requirements.

Chapter 4 Installing Sun Java System Directory Server and Creating Instances for Sun OpenSSO Enterprise User Data

This chapter contains instructions for installing Sun Java™ System Directory Server and creating the instances in which Sun OpenSSO Enterprise user data will be stored. Additionally, the procedure for enabling multi-master replication between the two instances and the procedure for configuring the user data load balancer are included. This chapter contains the following sections:

Note –

If you have an existing user data store, you can go directly to the instructions in Chapter 5, Deploying and Configuring OpenSSO Enterprise followed by Chapter 6, Configuring OpenSSO Enterprise Realms for User Authentication.

4.1 Installing and Configuring Directory Server 1 and Directory Server 2

This section contains the instructions for installing Directory Server on two different host machines and creating the directory instances named am-users in which the OpenSSO Enterprise user data will be stored. Use the following list of procedures as a checklist for completing the task.

To Download the Directory Server Bits and Required Patches to the Directory Server Host Machines

Use this procedure to download the Directory Server Enterprise Edition (EE) 6.1 bits and the required system patches to both the Directory Server 1 host machine (ds-1.example.com) and the Directory Server 2 host machine (ds-2.example.com).

Access http://www.sun.com/software/products/directory_srvr_ee/get.jsp from a web browser and click Download Now.

Provide the following information in the Select product configuration section and click View Downloads.

Step 1: Select Component

Directory Server Enterprise Edition

Step 2: Select Version

6.1

Step 3: Select Delivery Type

Compress Archive (ZIP)

Step 4: Select Platform

Choose the platform you are using.

The Selection Results page will be displayed with links to the download sites for the Directory Server bits and required patches.

Note –
The patch numbers generated for download on the Selection Results page are based on your input. Check the most recent Directory Server Enterprise Edition 6.1 Release Notes to determine if you need to install other patches based on your machine's architecture and operating system. In this deployment, the Release Notes indicate that based on the hardware and operating system being used, patch 118855–36, patch 119964–08, and patch 122033–05 are required.

Log into the ds–1 host machine as a root user.

Run patchadd to see if the patches are already installed.

See the patchadd man page for more information.
# patchadd -p | grep 118855–36
No results are returned which indicates that the patch is not yet installed on the system.
# patchadd -p | grep 119964–08
No results are returned which indicates that the patch is not yet installed on the system.
# patchadd -p | grep 122033–05
No results are returned which indicates that the patch is not yet installed on the system.

Note –
If these patches are already installed on your machine, proceed to step 7.

Make a directory for the patch downloads and change into it.
# mkdir /export/patches # cd /export/patches

Download the patches.

You can click on the patch links from the Selection Results page or search for patches directly at http://sunsolve.sun.com. If searching directly, navigate to the PatchFinder page and enter the patch number. For each patch you are downloading, click the HTTP link beside the heading Download Signed Patch (xxx bytes).

Note –
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files. In this step, ZIP files are downloaded.

Make a directory for the Directory Server download and change into it.
# mkdir /export/DS61 # cd /export/DS61

Download the Base Full Install of Directory Server EE 6.1 — Zip Distribution, Multi-Language, (DS/DPS/DE/ISW/DSRK) bits.

Note –
No Directory Server Administration Console is installed with these bits. This deployment example uses the command line to configure the software.

Log out of the ds–1 host machine.

Repeat this same procedure on the ds–2 host machine.

To Patch the Directory Server Host Machines

If necessary, use this procedure to patch both the ds–1 host machine and the ds–2 host machine.

Change into the directory that contains the downloaded patch files.
# cd /export/patches

Unzip the patch files.

# unzip 118855–36.zip
# unzip 119964-08.zip
# unzip 122033-05.zip

Install the patches.
# patchadd /export/patches/118855-36 # patchadd /export/patches/119964-08 # patchadd /export/patches/122033-05
Tip –
You can use the -M option to install all patches at once. See the patchadd man page for more information.

Reboot your machine, if requested.

After installation is complete, verify that each patch was added successfully.
# patchadd -p | grep 118855–36
A series of patch numbers are displayed, and the patch 118855–36 is present.
# patchadd -p | grep 119964-08
A series of patch numbers are displayed, and the patch 119964-08 is present.
# patchadd -p | grep 122033-05
A series of patch numbers are displayed, and the patch 122033-05 is present.

Log out of the ds–1 host machine.

Repeat this same procedure on the ds–2 host machine.

To Install Directory Server 1

Before You Begin

This procedures assumes To Download the Directory Server Bits and Required Patches to the Directory Server Host Machines and To Patch the Directory Server Host Machines have been completed.

(Optional) Resolve the following issues, if necessary.
- The LD_LIBRARY_PATH environment variable should not be set to the default setting. Change the value to empty as in the following example:
  # setenv LD_LIBRARY_PATH
- The JAVA_HOME environment variable should be set appropriately for your system architecture as in the following example:
  # setenv JAVA_HOME /usr/jdk/jdk1.5.0_09

Unzip the Directory Server ZIP file.

# cd /export/DS61
# ls

DSEE.6.1.Solaris10-X86_AMD64-full.tar.gz

# gunzip DSEE.6.1.Solaris10-X86_AMD64-full.tar.gz

Untar the resulting .tar file.
# tar xvf DSEE.6.1.Solaris10-X86_AMD64-full.tar
The DSEE_ZIP_Distribution directory is the result of the decompression.

Change into DSEE_ZIP_Distribution and run dsee_deploy install to install Directory Server.
# cd DSEE_ZIP_Distribution # ./dsee_deploy install -i /var/opt/mps/serverroot
The Licensing Agreement is displayed. At each Type return to continue prompt, press Return to continue.

When Do you accept the license terms? is displayed, enter yes to continue.

Once you accept the license terms, the Directory Server binaries will be installed in the /var/opt/mps/serverroot/ds6 directory.

To Create an OpenSSO Enterprise User Data Instance on Directory Server 1

Use this procedure to create a Directory Server instance named am-users for storing user data. The instance uses port 1489 for LDAP and port 1736 for LDAPS. It will be populated with user data in 4.5 Importing Test Users.

Before You Begin

This procedure assumes you have just completed To Install Directory Server 1 and are still logged into the ds—1 host machine as a root user.

Change to the bin directory.
# cd /var/opt/mps/serverroot/ds6/bin

Run dsadm create to create a user data instance called am-users.

# ./dsadm create -p 1489 -P 1736 /var/opt/mps/am-users

Choose the Directory Manager password: dsmanager

Confirm the Directory Manager password: dsmanager

use 'dsadm start /var/opt/mps/am-users' to start the instance

Run dsadm start to start the instance.

# ./dsadm start /var/opt/mps/am-users

Server started: pid=5810

Run netstat to verify that the new instance is up and running on both ports.

# netstat -an | grep 1736

.1736		*.*		0		0  65536		0 LISTEN
.1736		*.*		0		0  65536		0 LISTEN

# netstat -an | grep 1489

.1489		*.*		0		0  65536		0 LISTEN
.1489		*.*		0		0  65536		0 LISTEN

Run ldapsearch to verify that you can read the root Directory Server entry of the new instance.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -h ds-1.example.com 
-p 1489 -b "" -s base "(objectclass=*)"

version: 1
dn:
objectClass: top
...
supportedLDAPVersion: 3
vendorname: Sun Microsystems, Inc.
vendorVersion: Sun-Java(tm)-System-Directory/6.1
...

To Create a Base Suffix for the User Data Instance on Directory Server 1

Use this procedure to create the base suffix in which the user entries will be stored.

Before You Begin

This procedure assumes you have just completed To Create an OpenSSO Enterprise User Data Instance on Directory Server 1 and are still logged into the ds-1 host machine as a root user.

Run dsconf create-suffix to create a base suffix.

# ./dsconf create-suffix -p 1489 -B dbExample 
-L /var/opt/mps/am-users/db/exampleDS dc=company,dc=com

Provide the appropriate information when prompted.

Certificate "CN=ds-1, CN=1736, CN=directory Server, O=Sun Microsystems" 
presented by the server is not trusted.

Type "Y" to accept, "y" to accept just once, "n" to refuse, "d" for more details: Y

Enter "cn=Directory Manager" password: dsmanager

Tip –

When you enter an uppercase Y, you are not asked for the certificate again in the next steps.

Run dsconf list-suffixes to verify that the base suffix was successfully created.
# ./dsconf list-suffixes -p 1489 Enter "cn=Directory Manager" password: dsmanager dc=company,dc=com
If the base suffix was successfully created, dc=company,dc=com is returned. You can also see am-users in a command line list of directory instances.
# cd /var/opt/mps # ls am-users serverroot

Log out of the ds–1 host machine.

To Install Directory Server 2

Before You Begin

This procedures assumes To Download the Directory Server Bits and Required Patches to the Directory Server Host Machines and To Patch the Directory Server Host Machines have been completed.

(Optional) Resolve the following issues, if necessary.
- The LD_LIBRARY_PATH environment variable should not be set to the default setting. Change the value to empty as in the following example:
  # setenv LD_LIBRARY_PATH
- The JAVA_HOME environment variable should be set appropriately for your system architecture as in the following example:
  # setenv JAVA_HOME /usr/jdk/jdk1.5.0_09

Unzip the Directory Server ZIP file.

# cd /export/DS61
# ls

DSEE.6.1.Solaris10-X86_AMD64-full.tar.gz

# gunzip DSEE.6.1.Solaris10-X86_AMD64-full.tar.gz

Untar the resulting .tar file.
# tar xvf DSEE.6.1.Solaris10-X86_AMD64-full.tar
The DSEE_ZIP_Distribution directory is the result of the decompression.

Change into DSEE_ZIP_Distribution and run dsee_deploy install to install Directory Server.
# cd DSEE_ZIP_Distribution # ./dsee_deploy install -i /var/opt/mps/serverroot
The Licensing Agreement is displayed. At each Type return to continue prompt, press Return to continue.

When Do you accept the license terms? is displayed, enter yes to continue.

Once you accept the license terms, the Directory Server binaries will be installed in the /var/opt/mps/serverroot/ds6 directory.

To Create an OpenSSO Enterprise User Data Instance on Directory Server 2

Before You Begin

This procedure assumes you have just completed To Install Directory Server 2 and are still logged into the ds—2 host machine as a root user.

Change to the bin directory.
# cd /var/opt/mps/serverroot/ds6/bin

Run dsadm create to create a user data instance called am-users.

# ./dsadm create -p 1489 -P 1736 /var/opt/mps/am-users

Choose the Directory Manager password: dsmanager

Confirm the Directory Manager password: dsmanager

use 'dsadm start /var/opt/mps/am-users' to start the instance

Run dsadm start to start the instance.

# ./dsadm start /var/opt/mps/am-users

Server started: pid=5810

Run netstat to verify that the new instance is up and running on both ports.

# netstat -an | grep 1736

.1736		*.*		0		0  65536		0 LISTEN
.1736		*.*		0		0  65536		0 LISTEN

# netstat -an | grep 1489

.1489		*.*		0		0  65536		0 LISTEN
.1489		*.*		0		0  65536		0 LISTEN

Run ldapsearch to verify that you can read the root Directory Server entry of the new instance.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -h ds-2.example.com 
-p 1489 -b "" -s base "(objectclass=*)"

version: 1
dn:
objectClass: top
...
supportedLDAPVersion: 3
vendorname: Sun Microsystems, Inc.
vendorVersion: Sun-Java(tm)-System-Directory/6.1
...

To Create a Base Suffix for the User Data Instance on Directory Server 2

Use this procedure to create the base suffix in which the user entries will be stored.

Before You Begin

This procedure assumes you have just completed To Create an OpenSSO Enterprise User Data Instance on Directory Server 2 and are still logged into the ds-2 host machine as a root user.

Run dsconf create-suffix to create a base suffix.

# ./dsconf create-suffix -p 1489 -B dbExample 
-L /var/opt/mps/am-users/db/exampleDS dc=company,dc=com

Provide the appropriate information when prompted.

Certificate "CN=ds-2, CN=1736, CN=directory Server, O=Sun Microsystems" 
presented by the server is not trusted.

Type "Y" to accept, "y" to accept just once, "n" to refuse, "d" for more details: Y

Enter "cn=Directory Manager" password: dsmanager

Tip –

When you enter an uppercase Y, you are not asked for the certificate again in the next steps.

Run dsconf list-suffixes to verify that the base suffix was successfully created.
# ./dsconf list-suffixes -p 1489 Enter "cn=Directory Manager" password: dsmanager dc=company,dc=com
If the base suffix was successfully created, dc=company,dc=com is returned. You can also see am-users in a command line list of directory instances.
# cd /var/opt/mps # ls am-users serverroot

Log out of the ds–2 host machine.

4.2 Enabling Multi-Master Replication of the User Data Instances

This section contains the instructions to enable multi-master replication (MMR) between two Directory Server instances, each configured as a master. This includes creating replication agreements between the masters and initializing the second directory master with the data and schema from the first directory master. The previously created am-users user data instances will serve as the two master instances. Use the following list of procedures as a checklist for completing the task.

To Enable Multi-Master Replication for User Data Instance on Directory Server 1

(Optional) Run dsconf list-suffixes to verify that the user data instance is not already enabled for replication.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsconf list-suffixes -p 1489 -v

Enter "cn=Directory Manager" password: dsmanager
...
dc=company,dc=com 	1		not-replicated		N/A		N/A		29	0

The "list-suffixes" operation succeeded on "ds-1.example.com:1489"

The base suffix of the user data instance is not replicated.

Run dsconf enable-repl to enable replication of the user data instance.

# ./dsconf enable-repl -h ds-1.example.com -p 1489 
-d 11 master dc=company,dc=com

Enter "cn=Directory Manager" password: dsmanager

Use "dsconf create-repl-agmt" to create replication agreements on
"dc=company,dc=com".

The -d option takes as input a randomly chosen identifier to represent the Directory Server 1 user data instance; in this case, 11 master indicates that the user data instance is a master and not a replica. The base suffix is specified as dc=company,dc=com.

Run dsconf list-suffixes again to verify that the instance is now enabled for replication.

# ./dsconf list-suffixes -p 1489 -v

Enter "cn=Directory Manager" password: dsmanager
...
dc=company,dc=com 	1		master(11)		N/A		N/A		29	0

The "list-suffixes" operation succeeded on 
"ds-1.example.com:1489"

The base suffix of the instance is master(11) indicating that the master was successfully enabled.

Log out of the ds–1 host machine.

To Enable Multi-Master Replication for User Data Instance on Directory Server 2

(Optional) Run dsconf list-suffixes to verify that the user data instance is not already enabled for replication.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsconf list-suffixes -p 1489 -v

Enter "cn=Directory Manager" password: dsmanager
...
dc=company,dc=com 	1		not-replicated		N/A		N/A		29	0

The "list-suffixes" operation succeeded on "ds-2.example.com:1489"

The base suffix of the user data instance is not replicated.

Run dsconf enable-repl to enable replication of the user data instance.

# ./dsconf enable-repl -h ds-2.example.com -p 1489 
-d 22 master dc=company,dc=com

Enter "cn=Directory Manager" password: dsmanager

Use "dsconf create-repl-agmt" to create replication agreements on
"dc=company,dc=com".

The -d option takes as input a randomly chosen identifier to represent the Directory Server 2 user data instance; in this case, 22 master indicates that the user data instance is a master and not a replica. The base suffix is specified as dc=company,dc=com.

Run dsconf list-suffixes again to verify that the instance is now enabled for replication.

# ./dsconf list-suffixes -p 1489 -v

Enter "cn=Directory Manager" password: dsmanager
...
dc=company,dc=com 	1		master(22)		N/A		N/A		29		0

The "list-suffixes" operation succeeded on 
"ds-2.example.com:1489"

The base suffix of the instance is master(22) indicating that the master was successfully enabled.

Log out of the ds–2 host machine.

To Change the Default Replication Manager Password for Each User Data Instance

The replication manager is the user that data suppliers use to bind to the consumer server when sending replication updates. (In MMR the consumer server refers to whichever master happens to be the consumer for a particular operation.) It is recommended to change the default password created during the process of enabling replication.

Create a temporary file that contains the new replication manager password.

This file will be read once, and the password stored for future use.
# cd /var/opt/mps/serverroot/ds6/bin # echo replmanager > pwd.txt

Verify that the file was successfully created.
# cat pwd.txt replmanager

Run dsconf set-server-prop to set the replication manager password using pwd.txt as input.

# ./dsconf set-server-prop -h ds-1.example.com -p 1489 
def-repl-manager-pwd-file:pwd.txt

Enter "cn=Directory Manager" password: dsmanager

Remove the pwd.txt file.

Log out of the ds–1 host machine.

Create a temporary file that contains the new replication manager password.

This file will be read once, and the password stored for future use.
# cd /var/opt/mps/serverroot/ds6/bin # echo replmanager > pwd.txt

Verify that the file was successfully created.
# cat pwd.txt replmanager

Run dsconf set-server-prop to set the replication manager password using pwd.txt as input.

# ./dsconf set-server-prop -h ds-2.example.com -p 1489 
def-repl-manager-pwd-file:pwd.txt

Enter "cn=Directory Manager" password: dsmanager

Remove the pwd.txt file.

Log out of the ds–2 host machine.

To Create Replication Agreements for Each User Data Instance

A replication agreement is a set of parameters on a supplier that controls how updates are sent to a given consumer. In this deployment, we are simply making the user data instances aware of each other.

Run dsconf create-repl-agmt to create the replication agreement.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsconf create-repl-agmt -h ds-1.example.com 
 -p 1489 dc=company,dc=com ds-2.example.com:1489

Enter "cn=Directory Manager" password: dsmanager

Use "dsconf init-repl-dest dc=company,dc=com ds-2.example.com:1489" 
to start replication of "dc=company,dc=com" data.

Run dsconf list-repl-agmts to verify that the replication agreement was successfully created.
# ./dsconf list-repl-agmts -p 1489 Enter "cn=Directory Manager" password: dsmanager dc=company,dc=com ds-2.example.com:1489
This response indicates that the Directory Server 1 base suffix will be replicated to Directory Server 2.

Log out of the ds–1 host machine.

Run dsconf create-repl-agmt to create the replication agreement.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsconf create-repl-agmt -h ds-2.example.com -p 1489 
dc=company,dc=com ds-1.example.com:1489

Enter "cn=Directory Manager" password: dsmanager

Use "dsconf init-repl-dest dc=company,dc=com ds-1.example.com:1489" 
to start replication of "dc=company,dc=com" data.

Run dsconf list-repl-agmts to verify that the replication agreement was successfully created.
# ./dsconf list-repl-agmts -p 1489 Enter "cn=Directory Manager" password: dsmanager dc=company,dc=com ds-1.example.com:1489
This response indicates that the Directory Server 2 base suffix will be replicated to Directory Server 1.

Log out of the ds–2 host machine.

To Initialize the Replication Agreements

Use this procedure to initialize the user data instance on Directory Server 1. The previously created agreements will replicate the data to Directory Server 2.

Note –

Initialization is not required on both instances when configuring for MMR.

Run dsconf show-repl-agmt-status to verify that the replication agreements are not yet initialized.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsconf show-repl-agmt-status -h ds-1.example.com 
 -p 1489 dc=company,dc=com ds-2.example.com:1489

Enter "cn=Directory Manager" password: dsmanager

Configuration Status 		: OK
Authentication Status		: OK
Initialization Status		: NOT OK

Status:						: Dest. Not Initialized

Run dsconf init-repl-dest to initialize the replication agreements.

# ./dsconf init-repl-dest -h ds-1.example.com 
 -p 1489 dc=company,dc=com ds-2.example.com:1489

Enter "cn=Directory Manager" password: dsmanager

Started initialization of "ds-2.example.com:1489"; Aug 25, 2008 3:10:01 PM
Sent 2 entries.
Completed initialization of "ds-2.example.com:1489"; Aug 25, 2008 3:10:04 PM

Run dsconf show-repl-agmt-status again to verify that the replication agreements are now initialized.

# ./dsconf show-repl-agmt-status -h ds-1.example.com 
 -p 1489 dc=company,dc=com ds-2.example.com:1489

Enter "cn=Directory Manager" password: dsmanager

Configuration Status 		: OK
Authentication Status		: OK
Initialization Status		: OK

Status:						: Enabled
Last Update Date				:  Aug 25, 2008 3:10:08 PM

To Verify Successful User Data Replication

Before You Begin

This procedure assumes you have just completed To Initialize the Replication Agreements and are still logged into the ds–1 host machine as a root user.

Run ldapmodify on the ds-1 host machine to create a new directory entry.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapmodify -a -h ds-1.example.com -p 1489 
 -D cn=admin,cn=Administrators,cn=config -w dsmanager

dn: ou=People,dc=company,dc=com
objectclass: top
objectclass: organizationalUnit
ou: People
description: Container for user entries

Hit ENTER to indicate end of input.

adding new entry ou=People,dc=company,dc=com

Hit Control C to terminate the command.

^C

This step creates a new organizational unit on Directory Server 1.

After the entry is created, log in to the ds–2 host machine as a root user.

Run ldapsearch on Directory Server 2 to verify that the directory entry was successfully replicated.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -b "dc=company,dc=com" -p 1489 
-D "cn=Directory Manager" -w dsmanager 
"objectclass=organizationalUnit"

version: 1
dn: ou=People,dc=company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People
description Container for user entries

Now run ldapdelete on Directory Server 2 to delete the entry just created.

# ./ldapdelete -h ds-2.example.com -p 1489 
 -D "cn=Directory Manager" -w dsmanager 
"ou=People,dc=company,dc=com"

Now, as a root user on Directory Server 1, run ldapsearch to verify that the entry was deleted.
# ./ldapsearch -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" -w dsmanager "objectclass=organizationalUnit"
The search will return no results as the delete was successfully replicated.

Log out of both Directory Server host machines.

4.3 Enabling Secure Communication for the Directory Server User Data Instances

By default, when an instance of Directory Server is created (in this case, am-users), its SSL port is secured with a self-signed certificate named defaultCert. A self-signed certificate contains a public and private key; the public key is signed by the private key. The am-users instances, though, need to use a server certificate signed by a certificate authority (CA) to allow for secure communication between the instances and the soon-to-be-installed user data load balancer. This entails installing the server certificate signed by the CA and the root certificate confirming the signature of the CA on both Directory Server host machines. Use the following list of procedures as a checklist for completing this task.

To Install a Root Certificate and a Server Certificate on Directory Server 1

Before You Begin

You should already have a root certificate from the CA of your choice. Send server certificate requests to the same CA. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

Generate a request for a server certificate signed by a CA.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsadm request-cert -S "CN=ds-1.example.com, 
OU=OpenSSO Enterprise, O=Sun Microsystems, L=Santa Clara 
 ST=California, C=US" -F ascii -o ds-1.csr /var/opt/mps/am-users

ds-1.csr is the certificate request.

Send ds-1.csr to the CA of your choice.

The CA issues and returns a certified server certificate named ds-1.cer.

Add ds-1.cer, the CA-signed server certificate, to the certificate store.
# ./dsadm add-cert /var/opt/mps/am-users ds-1 ds-1.cer

(Optional) Verify that the certificate was successfully added.
# ./dsadm list-certs /var/opt/mps/am-users
A list of certificates for the am-users instance is displayed including the defaultCert and ds-1.

Add ca.cer, the root certificate, to the certificate store.

# ./dsadm add-cert --ca /var/opt/mps/am-users CA-cert ca.cer

(Optional) Verify that the root certificate was successfully added.

# ./dsadm list-certs -C /var/opt/mps/am-users | grep CA-cert

CA-cert
2007/09/20 11:41  2010/06/17 11:41  n  
E=nobody@nowhere.com,CN=openssltestca,OU=am,
O=sun,L=santa clara,ST=california,C=us  Same as issuer

Configure the Directory Server instance to use the imported certificates.

# ./dsconf set-server-prop -h ds-1.example.com 
-p 1489 ssl-rsa-cert-name:ds-1

Enter "cn=Directory Manager" password: dsmanager

Before setting SSL configuration, export Directory Server data.

Do you want to continue [y/n] ?  y

Directory Server must be restarted for changes to take effect.

Restart the Directory Server instance.

# ./dsadm stop /var/opt/mps/am-users
# ./dsadm start /var/opt/mps/am-users

Server started: pid=5472

Run ldapsearch on Directory Server 1 to verify that the directory entries can be accessed through the secure port.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -h ds-1.example.com -p 1736 
-Z -P /var/opt/mps/am-users/alias slapd-cert8.db 
-b "" -s base "(objectclass=*)"

version: 1
dn:
objectClass:top
namingContexts: dc=company,dc=com
supportedExtension: 2.16.840.1.113730.3.5.7
:
supportedSSLCiphers: SSL-CK_RC4_128_EXPORT40_WITH_MD5
supportedSSLCiphers: SSL-CK_RC2_128_CBC_EXPORT40_WITH_MD5

This confirms that the Directory Server instance can be accessed through the secure port.

Log out of the ds–1 host machine.

To Install a Root Certificate and a Server Certificate on Directory Server 2

Before You Begin

You should already have a root certificate from the CA of your choice. Send any server certificate requests to the same CA. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

Generate a request for a server certificate signed by a CA.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsadm request-cert -S "CN=ds-2.example.com, 
OU=OpenSSO Enterprise, O=Sun Microsystems, L=Santa Clara 
 ST=California, C=US" -F ascii -o ds-2.csr /var/opt/mps/am-users

ds-2.csr is the certificate request.

Send ds-2.csr to the CA of your choice.

The CA issues and returns a certified server certificate named ds-2.cer.

Add ds-2.cer, the CA-signed server certificate, to the certificate store.
# ./dsadm add-cert /var/opt/mps/am-users ds-2 ds-2.cer

(Optional) Verify that the certificate was successfully added.
# ./dsadm list-certs /var/opt/mps/am-users
A list of certificates for the am-users instance is displayed including the defaultCert and ds-2.

Add ca.cer, the root certificate, to the certificate store.

# ./dsadm add-cert --ca /var/opt/mps/am-users CA-cert ca.cer

(Optional) Verify that the root certificate was successfully added.

# ./dsadm list-certs -C /var/opt/mps/am-users | grep CA-cert

CA-cert
2007/09/20 11:41  2010/06/17 11:41  n  
E=nobody@nowhere.com,CN=openssltestca,OU=am,
O=sun,L=santa clara,ST=california,C=us  Same as issuer

Configure the Directory Server instance to use the imported certificates.

# ./dsconf set-server-prop -h ds-2.example.com 
-p 1489 ssl-rsa-cert-name:ds-2

Enter "cn=Directory Manager" password: dsmanager

Before setting SSL configuration, export Directory Server data.

Do you want to continue [y/n] ?  y

Directory Server must be restarted for changes to take effect.

Restart the Directory Server instance.

# ./dsadm stop /var/opt/mps/am-users
# ./dsadm start /var/opt/mps/am-users

Server started: pid=5472

Run ldapsearch on Directory Server 2 to verify that the directory entries can be accessed through the secure port.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -h ds-2.example.com -p 1736 
-Z -P /var/opt/mps/am-users/alias slapd-cert8.db 
-b "" -s base "(objectclass=*)"

version: 1
dn:
objectClass:top
namingContexts: dc=company,dc=com
supportedExtension: 2.16.840.1.113730.3.5.7
:
supportedSSLCiphers: SSL-CK_RC4_128_EXPORT40_WITH_MD5
supportedSSLCiphers: SSL-CK_RC2_128_CBC_EXPORT40_WITH_MD5

This confirms that the Directory Server instance can be accessed through the secure port.

Log out of the ds–2 host machine.

4.4 Configuring Load Balancer 1 for the User Data Instances

Load Balancer 1 is configured in front of the Directory Server user data instances. This section assumes that you have already installed the load balancer. Before beginning, note the following:

The load balancer hardware and software used in the lab facility for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.
Contact your network administrator to obtain an available virtual IP address for the load balancer you want to configure.
Know the IP address of the load balancer hardware, the URL for the load balancer login page, and a username and password for logging in to the load balancer application.
Get the IP addresses for Directory Server 1 and Directory Server 2 by running the following command on each host machine:
# ifconfig -a

Use the following list of procedures as a checklist for completing the task.

To Request a Certificate for the User Data Load Balancer

Generate a request for a server certificate to send to a CA. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

In the left pane, click Proxies.

Click the Cert-Admin tab.

On the SSL Certificate Administration page, click Generate New Key Pair/Certificate Request.

In the Create Certificate Request page, provide the following information.

Key Identifier:

lb-1.example.com

Organizational Unit Name:

Deployment

Domain Name:

lb-1.example.com

Challenge Password:

password

Retype Password:

password

Click Generate Key Pair/Certificate Request.

On the SSL Certificate Request page, the request is generated in the Certificate Request field.

Save the text contained in the Certificate Request field to a file named lb-1.csr.

Log out of the console and close the browser.

Send lb-1.csr to the CA of your choice.

The CA issues and returns a certified server certificate named lb-1.cer.

To Import the Root Certificate to the User Data Load Balancer

Import the CA root certificate on Load Balancer 1 to ensure that a link between Load Balancer 1 can be maintained with the CA. Use the same root certificate that you imported in 4.3 Enabling Secure Communication for the Directory Server User Data Instances. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

Before You Begin

You should already have a root certificate from the CA of your choice.

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

Click Proxies.

Click the Cert-Admin tab.

Click Import.

In the Import Type field, choose Certificate and click Continue.

Click Browse in the Certificate File field on the Install SSL Certificate page.

Choose Browser in the Choose File dialog box.

Navigate to ca.cer and click Open.

Enter OpenSSL_CA_cert in the Certificate Identifier field.

Click Install Certificate.

The Certificate OpenSSL_CA_Cert page is displayed.

Click Return to Certificate Administration on the Certificate OpenSSL_CA_Cert page.

OpenSSL_CA_Cert, the root certificate, is now included in the Certificate ID list.

To Install the Server Certificate to the User Data Load Balancer

Before You Begin

This procedure assumes you have received the server certificate requested in To Request a Certificate for the User Data Load Balancer, just completed To Import the Root Certificate to the User Data Load Balancer, and are still logged into the load balancer console.

In the BIG-IP load balancer console, click Proxies.

Click the Cert-Admin tab.

The key lb-1.example.com is in the Key List.

In the Certificate ID column, click Install for lb-1.example.com.

In the Certificate File field, click Browse.

In the Choose File dialog, navigate to lb-1.cer, the server certificate, and click Open.

Click Install Certificate.

On the Certificate lb-1.example.com page, click Return to Certificate Administration Information.

Verify that the Certificate ID indicates lb-1.example.com on the SSL Certificate Administration page.

Log out of the load balancer console.

To Configure the User Data Load Balancer 1

Before You Begin

This procedure assumes that you have just completed To Import the Root Certificate to the User Data Load Balancer and are still logged into the load balancer console.

Click Configure your BIG-IP (R) using the Configuration Utility.

Create a Pool.

A pool contains all the backend server instances.
1. In the left pane, click Pools.
2. On the Pools tab, click Add.
3. In the Add Pool dialog, provide the following information:
  
  Pool Name
  
  DirectoryServer-UserData-Pool
  
  Load Balancing Method
  
  Round Robin
  
  Resources
  
  Add the IP address and port number of both Directory Server host machines: ds-1:1736 and ds-2:1736.
4. Click Done.

Add a Virtual Server.

The virtual server presents an address to the outside world and, when users attempt to connect, it would forward the connection to the most appropriate real server.

Tip –
If you encounter JavaScript^TM errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer.
1. In the left frame, click Virtual Servers.
2. Click Add on the Virtual Servers tab.
3. In the Add a Virtual Server dialog box, provide the following information:
  
  Address
  
  Enter the IP address for lb-1.example.com
  
  Service
  
  490
4. Continue to click Next until you reach the Pool Selection dialog box.
5. Assign DirectoryServer-UserData-Pool to the virtual server in the Pool Selection dialog box.
6. Click Done.

Add Monitors

Monitors are required for the load balancer to detect the backend server failures.
1. In the left frame, click Monitors.
2. Click the Basic Associations tab.
3. Add an LDAP monitor for the Directory Server 1 node.
  
  In the Node column, locate the IP address and port number, ds-1:1736, and select the Add checkbox.
4. Add an LDAP monitor for the Directory Server 2 node.
  
  In the Node column, locate the IP address and port number, ds–2:1736, and select the Add checkbox.
5. At the top of the Node column, in the drop-down list, choose tcp.
6. Click Apply.

Configure the load balancer for persistence.

The user data load balancer is configured for simple persistence. With simple persistence, all requests sent within a specified interval are processed by the same Directory Server instance, ensuring complete replication of entries. For example, when a request requires information to be written to Directory Server 1, that information must also be replicated to Directory Server 2. As the replication takes time to complete, if a related request is directed by the load balancer to Directory Server 2 during the replication process itself, the request may fail as the entry might only be partially created. When properly configured, simple persistence ensures that both requests are routed to Directory Server 1 and processed in consecutive order; the first request is finished before the second request begins processing. Simple persistence ensures that within the specified interval, no errors or delays occur due to replication time or redirects when retrieving data. Simple persistence tracks connections based only on the client IP address.
1. In the left frame, click Pools.
2. Click the name of the pool you want to configure.
  
  In this example, DirectoryServer-UserData-Pool.
3. Click the Persistence tab.
4. Under Persistence Type, select Simple.
5. Enter 300 seconds for the Timeout interval.
6. Click Apply.

Verify the Directory Server load balancer configuration.

On each host machine, use the tail command to monitor the Directory Server access log.

# cd /var/opt/mps/am-users/logs
# tail -f access

You should see connections to the load balancer IP address opening and closing. For example:

[12/July/2008:13:10:20-0700] conn=69755 op=-1 msgId=-1 - closed 
[12/July/2008:13:10:25-0700] conn=69756 op=-1 msgId=-1 
- fd=27 slot=27 LDAP connection from IP_address to IP_address
[12/July/2008:13:10:25-0700] conn=69756 op=0 msgId=0 
- RESULT err=80 tag=120 nentries=0 etime=0 
[12/July/2008:13:10:25-0700] conn=69756 op=-1 msgId=-1 
- closing from IP_address

Execute the following LDAP search against the Directory Server load balancer from Directory Server 1.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -h lb-1.example.com -p 490 -Z 
-P /var/opt/mps/am-users/alias/slapd-cert8.db
-b "dc=company,dc=com" -D "cn=directory manager" 
-w dsmanager "(objectclass=*)"

version: 1
dn: dc=company,dc=com
dc: company
objectClass: top
objectClass: domain

The ldapsearch operation should return entries. Make sure they display in the access log on only one Directory Server.

Run dsadm stop to stop Directory Server 1.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsadm stop /var/opt/mps/am-users

Perform the (same) LDAP search against the Directory Server load balancer from Directory Server 2.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -h lb-1.example.com -p 490 -Z 
-P /var/opt/mps/am-users/alias/slapd-cert8.db
-b "dc=company,dc=com" -D "cn=directory manager" 
-w dsmanager "(objectclass=*)"

version: 1
dn: dc=company,dc=com
dc: company
objectClass: top
objectClass: domain

The ldapsearch operation should return entries. Verify that the entries display in the access log on only Directory Server 2.

Note –

You may encounter the following error message:

ldap_simple_bind: Cant' connect to the LDAP 
server — Connection refused

This means that the load balancer may not fully detect that Directory Server 1 is stopped. In this case, you may have started the search too soon based on the polling interval setting. For example, if the polling interval is set to 10 seconds, you should wait ten seconds to start the search. You can reset the timeout properties to a lower value using the load balancer console.

Click the Monitors tab.
Click the tcp monitor name.
In the Interval field, set the value to 5.

This tells the load balancer to poll the server every 5 seconds.
In the Timeout field, set the value to 16.
Click Apply and repeat the LDAP search.

See your load balancer documentation for more information on the timeout property.

Start Directory Server 1.
# ./dsadm start /var/opt/mps/am-users

Stop Directory Server 2.

# cd /var/opt/mps/serverroot/ds6/bin
# ./dsadm stop /var/opt/mps/am-users

Perform the following LDAP search against the Directory Server load balancer from Directory Server 1 to confirm that the request is forwarded to the running Directory Server 1.

# cd /var/opt/mps/serverroot/dsrk6/bin
 ./ldapsearch -h lb-1.example.com -p 490 -Z 
-P /var/opt/mps/am-users/alias/slapd-cert8.db
-b "dc=company,dc=com" -D "cn=directory manager" 
-w dsmanager "(objectclass=*)"

version: 1
dn: dc=company,dc=com
dc: company
objectClass: top
objectClass: domain

The ldapsearch operation should return entries. Make sure the entries display in the access log on only Directory Server 1.

Start Directory Server 2.
# ./dsadm start /var/opt/mps/am-users

Log out of both Directory Server host machines and the load balancer console.

To Create an SSL Proxy for SSL Termination at the User Data Load Balancer 1

SSL communication is terminated at Load Balancer 1. The request is then re-encrypted and securely forwarded to the SSL port of the Directory Server user data instance. Load Balancer 1 also encrypts the responses it receives back from the user data instance, and sends these encrypted responses back to the client. Towards this end create an SSL proxy for SSL termination and regeneration.

Before You Begin

You should have a root certificate issued by a recognized CA.

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

In the left pane, click Proxies.

Under the Proxies tab, click Add.

In the Add Proxy dialog, provide the following information.

Proxy Type:

Check the SSL and ServerSSL checkbox.

Proxy Address:

The IP address of Load Balancer 1.

Proxy Service:

489

The secure port number

Destination Address:

The IP address of Load Balancer 1.

Destination Service:

490

The non-secure port number

Destination Target:

Choose Local Virtual Server.

SSL Certificate:

Choose lb-1.example.com.

SSL Key:

Choose lb-1.example.com.

Enable ARP:

Check this checkbox.

Click Next.

On the page starting with “Insert HTTP Header String,” change to Rewrite Redirects and choose Matching.

Click Next.

On the page starting with “Client Cipher List String”, accept the defaults.

Click Next.

On the page starting with “Server Chain File,” change to Server Trusted CA's File and select “OpenSSL_CA_Cert.crt” from the drop-down list.

Click Done.

The new proxy server is added to the Proxy Server list.

Log out of the load balancer console.

4.5 Importing Test Users

Create user entries in the replicated Directory Server user data instances for the following users:

testuser1
testuser2

These users will be used to verify that the policy agent is configured and working properly. Additionally, the Groups container will be used for the same purpose.

Note –

If you are using an existing user data store, create the appropriate users in it and move on to Chapter 6, Configuring OpenSSO Enterprise Realms for User Authentication.

Use the following procedure, To Import Test User Data into the Replicated Directory Server Instances, to create an LDIF file for the test users and import the file into ds–1. The test users will then be replicated to ds–2.

To Import Test User Data into the Replicated Directory Server Instances

Create an LDIF file with the following entries.

dn: ou=users,dc=company,dc=com
objectclass: top
objectclass: organizationalUnit
ou: users
description: Container for user entries

dn: ou=Groups,dc=company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Groups
description: Container for group entries

dn: uid=testuser1,ou=users,dc=company,dc=com
uid: testuser1
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetadmin
objectClass: inetorgperson
objectClass: inetUser
sn: User1
cn: Test User1
userPassword: password
inetUserStatus: Active

dn: uid=testuser2,ou=users,dc=company,dc=com
uid: testuser2
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: User2
cn: Test User2
userPassword: password
inetUserStatus: Active

Save the file as am-users.ldif in the /tmp directory.

Import the LDIF file into Directory Server 1 using ldapmodify.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapmodify -h ds-1.example.com -p 1489 
 -D "cn=Directory Manager" -w dsmanager 
 -a -f /tmp/am-users.ldif

adding new entry ou=users,dc=company,dc=com

adding new entry ou=Groups,dc=company,dc=com

adding new entry uid=testuser1,ou=users,dc=company,dc=com

adding new entry uid=testuser2,ou=users,dc=company,dc=com

Verify that the new users were imported using ldapsearch.

# ./ldapsearch -h ds-1.example.com
 -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager"
 -w dsmanager "uid=test*"

version: 1
dn: uid=testuser1,ou=users,dc=company,dc=com
uid: testuser1
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetadmin
objectClass: inetorgperson
objectClass: inetUser
sn: User1
cn: Test User1
userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA==
inetUserStatus: Active

dn: uid=testuser2,ou=users,dc=company,dc=com
uid: testuser2
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: User2
cn: Test User2
userPassword: {SSHA}aLNFCQ1qw78KpJeloVZJAAa5QSAPf/9c2mxCQQ==
inetUserStatus: Active

Log out of the ds–1 host machine.

(Optional) Verify that the entries were replicated to Directory Server 2 by logging in as a root user to the ds–2 host machine and using ldapsearch.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -h ds-2.example.com
 -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager"
 -w dsmanager ""

version: 1
dn: dc=company,dc=com
objectClass: top
objectClass: domain
dc: company

dn: ou=users,dc=company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: users
description: Container for user entries

dn: ou=Groups,dc=company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Groups
description: Container for group entries

dn: uid=testuser1,ou=users,dc=company,dc=com
uid: testuser1
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetadmin
objectClass: inetorgperson
objectClass: inetUser
sn: User1
cn: Test User1
inetUserStatus: Active
userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA==

dn: uid=testuser2,ou=users,dc=company,dc=com
uid: testuser2
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: User2
cn: Test User2
inetUserStatus: Active
userPassword: {SSHA}aLNFCQ1qw78KpJeloVZJAAa5QSAPf/9c2mxCQQ==

Log out of the ds–2 host machine.

Chapter 5 Deploying and Configuring OpenSSO Enterprise

This chapter contains instructions on how to deploy and configure two instances of Sun OpenSSO Enterprise 8.0. Post installation procedures are also included. It begins with the installation of an instance of Sun Java™ System Application Server (on each host machine) into which the OpenSSO Enterprise WAR will be deployed and contains the following sections:

5.1 Installing the Application Server Web Containers

In this section, we create a non-root user with the roleadd command in the Solaris Operating Environment on each OpenSSO Enterprise host machine and install Sun Java System Application Server 9.1 Update 1 using the non-root user. Use the following list of procedures as a checklist for completing the task.

Note –

We use roleadd rather than useradd for security reasons; roleadd disables the ability of the user to log in.

To Create a Non-Root User on the OpenSSO Enterprise 1 Host Machine

Create a new user with roleadd.

# roleadd -s /sbin/sh -m -g staff -d /export/osso80adm osso80adm

(Optional) Verify that the user was created.

# cat /etc/passwd

root:x:0:0:Super-User:/:/sbin/sh
daemon:x:1:1::/:
...
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
osso80adm:x:223830:10::/export/osso80adm:/sbin/sh

(Optional) Verify that the user's directory was created.

# cd /export/osso80adm
# ls

local.cshrc    local.profile    local.login

Create a password for the non-root user.
# passwd osso80adm New Password: nonroot1pwd Re-ener new Pasword: nonroot1pwd passwd: password successfully changed for osso80adm
Caution –
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.

To Install Application Server on the OpenSSO Enterprise 1 Host Machine

Before You Begin

This procedure assumes you have just completed To Create a Non-Root User on the OpenSSO Enterprise 1 Host Machine and are still logged into the osso–1 host machine as a root user.

Create a directory into which the Application Server bits can be downloaded and change into it.
# mkdir /export/AS91 # cd /export/AS91

Download the Sun Java System Application Server 9.1 Update 1 binary from the Sun Microsystems Product Download page to the /export/AS91 directory.

Grant the downloaded binary execute permission using the chmod command.
# chmod +x sjsas-9_1_01-solaris-sparc.bin

Install the software.

# ./sjsas-9_1_01-solaris-sparc.bin -console

When prompted, provide the following information.

You are running the installation program 
for the Sun Java System Application Server. This 
program asks you to supply configuration preference
settings that it uses to install the server.

This installation program consists of one or 
more selections that provide you with information
and let you enter preferences that determine
how Sun Java System Application Server is 
installed and configured. 

When you are presented with the following
question, the installation process pauses to 
allow you to read the information that has 
been presented When you are ready to continue, 
press Enter.

Press Enter to continue.

Have you read, and do you accept, all of 
the terms of the preceding Software License 
Agreement [no] {"<" goes back, "!" exits}?

Enter yes.

Installation Directory [/opt/SUNWappserver]
{"<" goes back, "!" exits}

Enter /opt/SUNWappserver91

The specified directory "/opt/SUNWappserver91"
does not exist. Do you want to create it now or 
choose another directory?

1. Create Directory
2. Choose New.

Enter the number corresponding to your choice [1] 
{"<" goes back, "!" exits}

Enter 1 to create the directory.

The Sun Java System Application Server
requires a Java 2 SDK. Please provide the path to
a Java 2 SDK 5.0 or greater. [/usr/jdk/instances/jdk1.5.0] 
{"<" goes back, "!" exits}

Press Enter to accept the default value.

Supply the admin user's password and override
any of the other initial configuration settings as 
necessary.

Admin User [admin] {"<" goes back, "!" exits}

Press Enter to accept the default value.

Admin User's Password (8 chars minimum):
Re-enter Password:

Enter domain1pwd and then re-enter domain1pwd.

Do you want to store admin user name and 
password in .asadminpass file in user's home
directory [yes] {"<" goes back, "!" exits}?

Press Enter to accept the default value.

Admin Port [4848] {"<" goes back, "!" exits}
HTTP Port [8080] {"<" goes back, "!" exits}
HTTPS Port [8181] {"<" goes back, "!" exits}

Press Enter to accept the three default values.

Do you want to enable Updatecenter client 
[yes] {"<" goes back, "!" exits}?

Press Enter to accept the default value.

Do you want to upgrade from previous 
Applicatin Server version [no] 
{"<" goes back, "!" exits}?

Press Enter to accept the default value.

The following items for the product Sun Java 
System Application Server will be installed:

Product: Sun Java System Application Server
Location: /opt/SUNWappserver91
Space Required: 161.61 MB
-------------------------------------------
Sun Java System message Queue 4.1
Application Server
Startup

Ready To Install

1. Install Now
2. Start Over
3. Exit Installation

What would you like to do [1] 
{"<" goes back, "!" exits}?

Press Enter to accept the default value and begin the installation process.

- Installing Sun Java System Application 
Server

|-1%-----25%-----50%-----75%-----100%|

 - Installation Successful.

When installation is complete, an Installation Successful message is displayed:

Next Steps:

1. Access the About Application Server 9.1 welcome 
page at:
 file:///opt/SUNWappserver91/docs/about.html

2. Start the Application Server by executing:
  /opt/SUNWappserver91/bin/asadmin 
  start-domain domain1

3. Start the Admin Console:
  http://host-machine.domain:4848

Please press Enter/Return key to exit the 
installation program. {"!" exits}

Press Enter to exit the installation program.

Create a second Application Server domain for the non-root user.

The default domain created during the installation process is owned by root. We create a new domain for the non-root user osso80adm into which we will deploy OpenSSO Enterprise.

# cd /opt/SUNWappserver91/bin
# su osso80adm
# ./asadmin create-domain 
--domaindir /export/osso80adm/domains 
--adminport 8989 --user domain2adm --instanceport 1080 
--domainproperties http.ssl.port=1081 ossodomain

 Please enter the admin password>

domain2pwd

Please enter the admin password again>

domain2pwd

Please enter the master password 

  [Enter to accept the default]:>

domain2master

Please enter the master password again 

  [Enter to accept the default]:>

domain2master

Using port 8989 for Admin.
Using port 1080 for HTTP Instance.
Using default port 7676 for JMS.
Using default port 3700 for IIOP.
Using port 1081 for HTTP_SSL.
Using default port 3820 for IIOP_SSL.
Using default port 3920 for IIOP_MUTUALAUTH.
Using default port 8686 for JMX_ADMIN.
Domain being created with profile:developer, as specified 
  by variable AS_ADMIN_PROFILE in configuration file.
Security Store uses: JKS
2008-08-24 18:21:15.907 GMT Thread[main,5,main] 
java.io.FileNotFoundException:
derby.log (Permission denied)
-------------------------------------------------
2008-03-24 18:21:16.216 GMT:
Booting Derby version The Apache Software Foundation 
- Apache Derby - 10.2.2.1 -
(538595): instance c013800d-0118-e205-d50b-00000c0c0770 
on database directory
/export/osso80adm/domains/ossodomain/lib/databases/ejbtimer

  Database Class Loader started - derby.database.classpath=''
  Domain ossodomain created.

Note –

Creating a non-root domain displays a FileNotFoundException. Please see Appendix F, Known Issues and Limitations.

Verify that the non-root user domain was created with the correct permissions using the following sub-procedure.

Change to the ossodomain directory.

# cd /export/osso80adm/domains/ossodomain

List the contents of the directory.

# ls -la

total 30
drwxr-xr-x  15 osso80adm staff   512 Mar 20 14:12 .
drwxr-xr-x   3 osso80adm staff   512 Mar 20 14:12 ..
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 addons
drwxr-xr-x   6 osso80adm staff   512 Mar 20 14:12 applications
drwxr-xr-x   3 osso80adm staff   512 Mar 20 14:12 autodeploy
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 bin
drwx------   3 osso80adm staff  1024 Mar 26 13:27 config
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 docroot
drwxr-xr-x   6 osso80adm staff   512 Mar 26 13:34 generated
drwxr-xr-x   3 osso80adm staff   512 Mar 20 14:12 imq
drwxr-xr-x   5 osso80adm staff   512 Mar 20 14:16 java-web-start
drwxr-xr-x   8 osso80adm staff   512 Mar 20 14:16 jbi
drwxr-xr-x   6 osso80adm staff   512 Mar 20 14:12 lib
drwxr-xr-x   2 osso80adm staff   512 Mar 26 13:26 logs
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 session-store

The files and directories are owned by osso80adm.

Start ossodomain, the non-root user domain, using the following sub-procedure.

Switch to the non-root user.
# su osso80adm

Change to the bin directory.

# cd /export/osso80adm/domains/ossodomain/bin

Start ossodomain.

# ./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Verify that ossodomain has started with the following sub-procedure.
1. Access http://osso-1.example.com:8989/login.jsf from a web browser.
2. Log in to the Application Server console as the ossodomain administrator.
  
  Username
  
  domain2adm
  
  Password
  
  domain2pwd
  
  When the Application Server administration console is displayed, it is verification that the non-root user was able to start the domain server.
3. Exit the console and close the browser.

Create a request for a server certificate to secure communications between the soon-to-be-configured Load Balancer 2 and ossodomain using the following sub-procedure.

Generate a private/public key pair and reference it with the alias, osso-1.

osso-1 will be used in a later step to retrieve the public key which is contained in a self-signed certificate.

# cd /export/osso80adm/domains/ossodomain/config
# keytool -genkey -noprompt -keyalg rsa -keypass domain2master -alias osso-1
 -keystore keystore.jks -dname "CN=osso-1.example.com, OU=OpenSSO, 
O=Sun Microsystems, L=Santa Clara, ST=California, C=US" -storepass domain2master

Verify that the key pair was successfully created and stored in the certificate store.

# keytool -list -v -keystore keystore.jks -storepass domain2master

 Alias name: osso-1
 Creation date: Aug 4, 2008
 Entry type: keyEntry
 Certificate chain length: 1
 Certificate[1]:
 Owner: CN=osso-1.example.com, OU=OpenSSO, O=Sun Microsystems,
L=Santa Clara, ST=California, C=US
 Issuer: CN=osso-1.example.com, OU=OpenSSO, O=Sun Microsystems,
L=Santa Clara, ST=California, C=US
 Serial number: 47f6a587
 Valid from: Fri Aug 04 15:02:47 PDT 2008 until: Thu Nov 03 15:02:47 PDT 2008
 Certificate fingerprints:
  MD5:  62:0E:5E:EB:8A:73:B2:F9:08:83:05:C5:DC:07:3C:E1
  SHA1: D4:9C:BA:25:4C:B5:71:20:CF:F3:18:46:AF:2E:7F:71:2A:4B:BD:B3

The certificate indicated by the alias "osso-1" is a self-signed certificate.

Note –

The output of this command may list more than one certificate based on the entries in the keystore.

Generate a server certificate request.

# keytool -certreq -alias osso-1 -keypass domain2master 
-keystore keystore.jks -storepass domain2master file osso-1.csr

osso-1.csr is the server certificate request.

(Optional) Verify that osso-1.csr was created.

# ls -la osso-1.csr

 -rw-r--r--   1 osso80adm staff        715 Apr  4 15:04 osso-1.csr

Send osso-1.csr to the CA of your choice.

The CA issues and returns a certified certificate named osso-1.cer.

Import ca.cer, the CA root certificate.

The root certificate must be imported into two keystores (keystore.jks and cacerts.jks) with Application Server.

# keytool -import -trustcacerts -alias OpenSSLTestCA 
-file ca.cer -keystore keystore.jks -storepass domain2master

Owner: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:41:51 PDT 2007 until: Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
  MD5:  78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
  SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:A3:20:8C:BA

Trust this certificate? [no]: Yes

Certificate was added to keystore

# keytool -import -trustcacerts -alias OpenSSLTestCA 
-file ca.cer -keystore cacerts.jks -storepass domain2master

Owner: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:41:51 PDT 2007 until: Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
  MD5:  78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
  SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:A3:20:8C:BA

Trust this certificate? [no]: Yes

Certificate was added to keystore

Replace the self-signed public key certificate (associated with the osso-1 alias) with the server certificate received from the CA.

# keytool -import -file osso-1.cer -alias osso-1 
-keystore keystore.jks -storepass domain2master

Certificate reply was installed in keystore

(Optional) Verify that the self-signed public key certificate has been overwritten by the server certificate received from the CA.

# keytool -list -v -keystore keystore.jks 
-storepass domain2master

The certificate indicated by the alias "osso-1" is signed by CA.

Change the certificate alias from the default s1as to the new osso-1 in the domain.xml file for the ossodomain domain.

The Application Server configuration file is domain.xml.

<http-listener acceptor-threads="1" address="0.0.0.0" 
blocking-enabled="false" default-virtual-server="server" enabled="true" 
family="inet" id="http-listener-2" port="1081" security-enabled="true" 
server-name="" xpowered-by="true">
<ssl cert-nickname="osso-1" client-auth-enabled="false" ssl2-enabled="false"
ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>

Tip –

Backup domain.xml before modifying it.

Modify the JVM options in your web container's configuration file using the following sub-procedure.

OpenSSO Enterprise is deployed with an embedded configuration data store (if desired). In order for the configuration data store to be created successfully, the following JVM options should be modified in the web container's configuration file. We will be modifying domain.xml again for this example.

Tip –
Backup domain.xml before modifying it.
1. Change to the config directory.
  # cd /export/osso80adm/domains/ossodomain/config
2. Open domain.xml in a text editor and make the following changes:
  - Replace <jvm-options>-client</jvm-options> with <jvm-options>-server</jvm-options>.
  - Replace <jvm-options>-Xmx512m</jvm-options> with <jvm-options>-Xmx1024m</jvm-options>.
3. Save the file and close it.

Restart the ossodomain domain.

# cd /export/osso80adm/domains/ossodomain/bin
# ./stopserv

Server was successfully stopped.

./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Note –

The second Application Server domain is only running as a non-root user and not sharing the domain administrator credentials used to start the server with the non-root user.

Verify that the certificate used for SSL communication is the root CA certificate.
1. Access https://osso-1.example.com:1081/index.html from a web browser.
2. View the details of the certificate in the security warning to ensure that it is Issued by “OpenSSLTestCA”.
  
  After inspecting and accepting the certificate, you should see the default index.html page.
3. Close the browser.

Log out of the osso-1 host machine.

To Create a Non-Root User on the OpenSSO Enterprise 2 Host Machine

Create a new user with roleadd.

# roleadd -s /sbin/sh -m -g staff -d /export/osso80adm osso80adm

(Optional) Verify that the user was created.

# cat /etc/passwd

root:x:0:0:Super-User:/:/sbin/sh
daemon:x:1:1::/:
...
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
osso80adm:x:223830:10::/export/osso80adm:/sbin/sh

(Optional) Verify that the user's directory was created.

# cd /export/osso80adm
# ls

local.cshrc    local.profile    local.login

Create a password for the non-root user.
# passwd osso80adm New Password: nonroot2pwd Re-ener new Pasword: nonroot2pwd passwd: password successfully changed for osso80adm
Caution –
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.

To Install Application Server on the OpenSSO Enterprise 2 Host Machine

Before You Begin

This procedure assumes you have just completed To Create a Non-Root User on the OpenSSO Enterprise 2 Host Machine and are still logged into the osso–2 host machine as a root user.

Create a directory into which the Application Server bits can be downloaded and change into it.
# mkdir /export/AS91 # cd /export/AS91

Download the Sun Java System Application Server 9.1 Update 1 binary from the Sun Microsystems Product Download page to the /export/AS91 directory.

Grant the downloaded binary execute permission using the chmod command.
# chmod +x sjsas-9_1_01-solaris-sparc.bin

Install the software.

# ./sjsas-9_1_01-solaris-sparc.bin -console

When prompted, provide the following information.

You are running the installation program 
for the Sun Java System Application Server. This 
program asks you to supply configuration preference
settings that it uses to install the server.

This installation program consists of one or 
more selections that provide you with information
and let you enter preferences that determine
how Sun Java System Application Server is 
installed and configured. 

When you are presented with the following
question, the installation process pauses to 
allow you to read the information that has 
been presented When you are ready to continue, 
press Enter.

Press Enter to continue.

Have you read, and do you accept, all of 
the terms of the preceding Software License 
Agreement [no] {"<" goes back, "!" exits}?

Enter yes.

Installation Directory [/opt/SUNWappserver]
{"<" goes back, "!" exits}

Enter /opt/SUNWappserver91

The specified directory "/opt/SUNWappserver91"
does not exist. Do you want to create it now or 
choose another directory?

1. Create Directory
2. Choose New.

Enter the number corresponding to your choice [1] 
{"<" goes back, "!" exits}

Enter 1 to create the directory.

The Sun Java System Application Server
requires a Java 2 SDK. Please provide the path to
a Java 2 SDK 5.0 or greater. [/usr/jdk/instances/jdk1.5.0] 
{"<" goes back, "!" exits}

Press Enter to accept the default value.

Supply the admin user's password and override
any of the other initial configuration settings as 
necessary.

Admin User [admin] {"<" goes back, "!" exits}

Press Enter to accept the default value.

Admin User's Password (8 chars minimum):
Re-enter Password:

Enter domain1pwd and then re-enter domain1pwd.

Do you want to store admin user name and 
password in .asadminpass file in user's home
directory [yes] {"<" goes back, "!" exits}?

Press Enter to accept the default value.

Admin Port [4848] {"<" goes back, "!" exits}
HTTP Port [8080] {"<" goes back, "!" exits}
HTTPS Port [8181] {"<" goes back, "!" exits}

Press Enter to accept the three default values.

Do you want to enable Updatecenter client 
[yes] {"<" goes back, "!" exits}?

Press Enter to accept the default value.

Do you want to upgrade from previous 
Applicatin Server version [no] 
{"<" goes back, "!" exits}?

Press Enter to accept the default value.

The following items for the product Sun Java 
System Application Server will be installed:

Product: Sun Java System Application Server
Location: /opt/SUNWappserver91
Space Required: 161.61 MB
-------------------------------------------
Sun Java System message Queue 4.1
Application Server
Startup

Ready To Install

1. Install Now
2. Start Over
3. Exit Installation

What would you like to do [1] 
{"<" goes back, "!" exits}?

Press Enter to accept the default value and begin the installation process.

- Installing Sun Java System Application 
Server

|-1%-----25%-----50%-----75%-----100%|

 - Installation Successful.

When installation is complete, an Installation Successful message is displayed:

Next Steps:

1. Access the About Application Server 9.1 welcome 
page at:
 file:///opt/SUNWappserver91/docs/about.html

2. Start the Application Server by executing:
  /opt/SUNWappserver91/bin/asadmin 
  start-domain domain1

3. Start the Admin Console:
  http://host-machine.domain:4848

Please press Enter/Return key to exit the 
installation program. {"!" exits}

Press Enter to exit the installation program.

Create a second Application Server domain for the non-root user.

The default domain created during the installation process is owned by root. We create a new domain for the non-root user osso80adm into which we will deploy OpenSSO Enterprise.

# cd /opt/SUNWappserver91/bin
# su osso80adm
# ./asadmin create-domain 
--domaindir /export/osso80adm/domains 
--adminport 8989 --user domain2adm --instanceport 1080 
--domainproperties http.ssl.port=1081 ossodomain

 Please enter the admin password>

domain2pwd

Please enter the admin password again>

domain2pwd

Please enter the master password 

  [Enter to accept the default]:>

domain2master

Please enter the master password again 

  [Enter to accept the default]:>

domain2master

Using port 8989 for Admin.
Using port 1080 for HTTP Instance.
Using default port 7676 for JMS.
Using default port 3700 for IIOP.
Using port 1081 for HTTP_SSL.
Using default port 3820 for IIOP_SSL.
Using default port 3920 for IIOP_MUTUALAUTH.
Using default port 8686 for JMX_ADMIN.
Domain being created with profile:developer, as specified 
  by variable AS_ADMIN_PROFILE in configuration file.
Security Store uses: JKS
2008-08-24 18:21:15.907 GMT Thread[main,5,main] 
java.io.FileNotFoundException:
derby.log (Permission denied)
-------------------------------------------------
2008-03-24 18:21:16.216 GMT:
Booting Derby version The Apache Software Foundation 
- Apache Derby - 10.2.2.1 -
(538595): instance c013800d-0118-e205-d50b-00000c0c0770 
on database directory
/export/osso80adm/domains/ossodomain/lib/databases/ejbtimer

  Database Class Loader started - derby.database.classpath=''
  Domain ossodomain created.

Note –

The FileNotFoundException is a known issue. Please see Appendix F, Known Issues and Limitations.

Verify that the non-root user domain was created with the correct permissions using the following sub-procedure.

Change to the ossodomain directory.

# cd /export/osso80admin/domains/ossodomain

List the contents of the directory.

# ls -la

total 30
drwxr-xr-x  15 osso80adm staff   512 Mar 20 14:12 .
drwxr-xr-x   3 osso80adm staff   512 Mar 20 14:12 ..
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 addons
drwxr-xr-x   6 osso80adm staff   512 Mar 20 14:12 applications
drwxr-xr-x   3 osso80adm staff   512 Mar 20 14:12 autodeploy
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 bin
drwx------   3 osso80adm staff  1024 Mar 26 13:27 config
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 docroot
drwxr-xr-x   6 osso80adm staff   512 Mar 26 13:34 generated
drwxr-xr-x   3 osso80adm staff   512 Mar 20 14:12 imq
drwxr-xr-x   5 osso80adm staff   512 Mar 20 14:16 java-web-start
drwxr-xr-x   8 osso80adm staff   512 Mar 20 14:16 jbi
drwxr-xr-x   6 osso80adm staff   512 Mar 20 14:12 lib
drwxr-xr-x   2 osso80adm staff   512 Mar 26 13:26 logs
drwxr-xr-x   2 osso80adm staff   512 Mar 20 14:12 session-store

The files and directories are owned by osso80adm.

Start ossodomain, the non-root user domain, using the following sub-procedure.

Switch to the non-root user.
# su osso80adm

Change to the bin directory.

# cd /export/osso80adm/domains/ossodomain/bin

Start ossodomain.

# ./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Verify that ossodomain has started with the following sub-procedure.
1. Access http://osso-2.example.com:8989/login.jsf from a web browser.
2. Log in to the Application Server console as the administrator.
  
  Username
  
  domain2adm
  
  Password
  
  domain2pwd
  
  When the Application Server administration console is displayed, it is verification that the non-root user was able to start the domain server.
3. Exit the console and close the browser.

Create a request for a server certificate to secure communications between the soon-to-be-configured Load Balancer 2 and ossodomain using the following sub-procedure.

Generate a private/public key pair and reference it with the alias, osso-2.

osso-2 will be used in a later step to retrieve the public key which is contained in a self-signed certificate.

# cd /export/osso80adm/domains/ossodomain/config
# keytool -genkey -noprompt -keyalg rsa -keypass domain2master -alias osso-2
 -keystore keystore.jks -dname "CN=osso-2.example.com, OU=OpenSSO, 
O=Sun Microsystems, L=Santa Clara, ST=California, C=US" -storepass domain2master

Verify that the key pair was successfully created and stored in the certificate store.

# keytool -list -v -keystore keystore.jks -storepass domain2master

 Alias name: osso-2
 Creation date: Aug 4, 2008
 Entry type: keyEntry
 Certificate chain length: 1
 Certificate[1]:
 Owner: CN=osso-2.example.com, OU=OpenSSO, O=Sun Microsystems,
L=Santa Clara, ST=California, C=US
 Issuer: CN=osso-2.example.com, OU=OpenSSO, O=Sun Microsystems,
L=Santa Clara, ST=California, C=US
 Serial number: 47f6a587
 Valid from: Fri Aug 04 15:02:47 PDT 2008 until: Thu Nov 03 15:02:47 PDT 2008
 Certificate fingerprints:
  MD5:  62:0E:5E:EB:8A:73:B2:F9:08:83:05:C5:DC:07:3C:E1
  SHA1: D4:9C:BA:25:4C:B5:71:20:CF:F3:18:46:AF:2E:7F:71:2A:4B:BD:B3

The certificate indicated by the alias "osso-2" is a self-signed certificate.

Note –

The output of this command may list more than one certificate based on the entries in the keystore.

Generate a server certificate request.

# keytool -certreq -alias osso-2 -keypass domain2master 
-keystore keystore.jks -storepass domain2master file osso-2.csr

osso-2.csr is the server certificate request.

(Optional) Verify that osso-2.csr was created.

# ls -la osso-2.csr

 -rw-r--r--   1 osso80adm staff        715 Apr  4 15:04 osso-2.csr

Send osso-2.csr to the CA of your choice.

The CA issues and returns a certified server certificate named osso-2.cer.

Import ca.cer, the CA root certificate, into the certificate store.

The root certificate must be imported into two keystores (keystore.jks and cacerts.jks) with Application Server.

# keytool -import -trustcacerts -alias OpenSSLTestCA 
-file ca.cer -keystore keystore.jks -storepass domain2master

Owner: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:41:51 PDT 2007 until: Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
  MD5:  78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
  SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:A3:20:8C:BA

Trust this certificate? [no]: Yes

Certificate was added to keystore

# keytool -import -trustcacerts -alias OpenSSLTestCA 
-file ca.cer -keystore cacerts.jks -storepass domain2master

Owner: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, OU=am, 
  O=sun, L=santa clara, ST=california, C=us
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:41:51 PDT 2007 until: Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
  MD5:  78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
  SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:A3:20:8C:BA

Trust this certificate? [no]: Yes

Certificate was added to keystore

Replace the self-signed public key certificate (associated with the osso-2 alias) with the server certificate received from the CA.

# keytool -import -file osso-2.cer -alias osso-2 
-keystore keystore.jks -storepass domain2master

Certificate reply was installed in keystore

(Optional) Verify that the self-signed public key certificate has been overwritten by the server certificate received from the CA.

# keytool -list -v -keystore keystore.jks 
-storepass domain2master

The certificate indicated by the alias "osso-2" is signed by CA.

Change the certificate alias from the default s1as to the new osso-2 in the domain.xml file for the ossodomain domain.

The Application Server configuration file is domain.xml.

<http-listener acceptor-threads="1" address="0.0.0.0" 
blocking-enabled="false" default-virtual-server="server" enabled="true" 
family="inet" id="http-listener-2" port="1081" security-enabled="true" 
server-name="" xpowered-by="true">
<ssl cert-nickname="osso-2" client-auth-enabled="false" ssl2-enabled="false"
ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>

Tip –

Backup domain.xml before modifying it.

Modify the JVM options in your web container's configuration file using the following sub-procedure.

OpenSSO Enterprise is deployed with an embedded configuration data store (if desired). In order for the configuration data store to be created successfully, the following JVM options should be modified in the web container's configuration file. We will be modifying domain.xml again for this example.

Tip –
Backup domain.xml before modifying it.
1. Change to the config directory.
  # cd /export/osso80adm/domains/ossodomain/config
2. Open domain.xml in a text editor and make the following changes:
  - Replace <jvm-options>-client</jvm-options> with <jvm-options>-server</jvm-options>.
  - Replace <jvm-options>-Xmx512m</jvm-options> with <jvm-options>-Xmx1024m</jvm-options>.
3. Save the file and close it.

Restart the ossodomain domain.

# cd /export/osso80adm/domains/ossodomain/bin
# ./stopserv

Server was successfully stopped.

./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Note –

The second Application Server domain is only running as a non-root user and not sharing the domain administrator credentials used to start the server with the non-root user.

Verify that the certificate used for SSL communication is the root CA certificate.
1. Access https://osso-2.example.com:1081/index.html from a web browser.
2. View the details of the certificate in the security warning to ensure that it is Issued by “OpenSSLTestCA”.
  
  After inspecting and accepting the certificate, you should see the default index.html page.
3. Close the browser.

Log out of the osso-2 host machine.

5.2 Configuring Load Balancer 2 for OpenSSO Enterprise

The two instances of OpenSSO Enterprise are fronted by one load balancer (Load Balancer 2). Users will access OpenSSO Enterprise through the secure port 1081. Users external to the company will access the Distributed Authentication User Interface which, in turn, routes the request through the secure port 1081.

Load Balancer 2 sends the user and agent requests to the server where the session originated. Secure Sockets Layer (SSL) is terminated and regenerated before a request is forwarded to the OpenSSO Enterprise servers to allow the load balancer to inspect the traffic for proper routing. Load Balancer 2 is capable of the following types of load balancing:

Cookie-based	The load balancer makes decisions based on client's cookies. The load balancer looks at the request and detects the presence of a cookie by a specific name. If the cookie is detected in the request, the load balancer routes the request to the specific server to which the cookie has been assigned. If the cookie is not detected in the request, the load balancer balances client requests among the available servers.
IP-based	This is similar to cookie-based load balancing, but the decision is based on the IP address of the client. The load balancer sends all requests from a specific IP address to the same server.
TCP	The load balancer mainstreams session affinity. This means that all requests related to a TCP session, are forwarded to the same server. In this deployment example, Load Balancer 2 forwards all requests from a single client to exactly the same server. When the session is started and maintained by one client, session affinity is guaranteed. This type of load-balancing is applicable to the TCP-based protocols.

Note –

In this Deployment Example, we use BIG-IP and it's supported passive-cookie mechanism to address session persistence with the backend OpenSSO Enterprise servers. The intent is to enable persistence of requests to the backend servers depending upon the value of amlbcookie, the OpenSSO Enterprise cookie. Stickiness can then be maintained for all OpenSSO Enterprise related requests from browsers or agents. Different load balancers might support different mechanisms to achieve session persistence. It is the responsibility of the end users to determine and map this functionality to their own choice of load balancer.

This section assumes that you have already installed a load balancer. Before you begin, note the following:

The load balancer hardware and software used in the lab facility for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.
Contact your network administrator to obtain an available virtual IP address for the load balancer you want to configure.
Know the IP address of the load balancer hardware, the URL for the load balancer login page, and a username and password for logging in to the load balancer application.
Get the IP addresses for OpenSSO Enterprise 1 and OpenSSO Enterprise 2 by running the following command on each host machine:
# ifconfig -a

Use the following list of procedures as a checklist for completing the task.

To Request a Certificate for the OpenSSO Enterprise Load Balancer

Generate a request for a server certificate to send to a CA. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

In the left pane, click Proxies.

Click the Cert-Admin tab.

On the SSL Certificate Administration page, click Generate New Key Pair/Certificate Request.

In the Create Certificate Request page, provide the following information.

Key Identifier:

lb-2.example.com

Organizational Unit Name:

Deployment

Domain Name:

lb-2.example.com

Challenge Password:

password

Retype Password:

password

Click Generate Key Pair/Certificate Request.

On the SSL Certificate Request page, the request is generated in the Certificate Request field.

Save the text contained in the Certificate Request field to a file named lb-2.csr.

Log out of the console and close the browser.

Send lb-2.csr to the CA of your choice.

The CA issues and returns a certified server certificate named lb-2.cer.

To Install a CA Root Certificate to the OpenSSO Enterprise Load Balancer

Install the CA root certificate on Load Balancer 2 to ensure that a link between the Load Balancer 2 can be maintained with the CA. Use the same root certificate that you imported in 4.3 Enabling Secure Communication for the Directory Server User Data Instances. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

In the BIG-IP load balancer console, click Proxies.

Click the Cert-Admin tab.

Click Import.

In the Import Type field, choose Certificate, and click Continue.

Click Browse in the Certificate File field on the Install SSL Certificate page.

In the Choose File dialog, choose Browser.

Navigate to ca.cer and click Open.

In the Certificate Identifier field, enter OpenSSL_CA_cert.

Click Install Certificate.

On the Certificate OpenSSL_CA_Cert page, click Return to Certificate Administration.

The root certificate named OpenSSL_CA_Cert is now included in the Certificate ID list.

To Install the Server Certificate to the OpenSSO Enterprise Load Balancer

Before You Begin

This procedure assumes you have received the server certificate requested in To Request a Certificate for the OpenSSO Enterprise Load Balancer and just completed To Install a CA Root Certificate to the OpenSSO Enterprise Load Balancer.

In the BIG-IP load balancer console, click Proxies.

Click the Cert-Admin tab.

The key lb-2.example.com is in the Key List.

In the Certificate ID column, click Install for lb-2.example.com.

In the Certificate File field, click Browse.

In the Choose File dialog, navigate to lb-2.cer, the server certificate, and click Open.

Click Install Certificate.

On the Certificate lb-2.example.com page, click Return to Certificate Administration Information.

Verify that the Certificate ID indicates lb-2.example.com on the SSL Certificate Administration page.

Log out of the load balancer console.

To Configure the OpenSSO Enterprise Load Balancer

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

Create a Pool.

A pool contains all the backend server instances.
1. In the left pane, click Pools.
2. On the Pools tab, click Add.
3. In the Add Pool dialog, provide the following information.
  
  Pool Name
  
  OSSO-Pool
  
  Load Balancing Method
  
  Round Robin
  
  Resources
  
  Add the IP addresses and port numbers for the OpenSSO Enterprise servers: osso-1:1081 and osso-2:1081.
4. Click Done.

Add a Virtual Server.

The virtual server presents an address to the outside world and, when users attempt to connect, it would forward the connection to the most appropriate real server.

Note –
If you encounter JavaScript^TM errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer.
1. In the left frame, click Virtual Servers.
2. On the Virtual Servers tab, click Add.
3. In the Add a Virtual Server dialog box, provide the following information:
  
  Address
  
  Enter the IP address for lb-2.example.com
  
  Service
  
  1082
4. Continue to click Next until you reach the Pool Selection dialog box.
5. In the Pool Selection dialog box, assign the OSSO-Pool Pool.
6. Click Done.

Add Monitors.

OpenSSO Enterprise comes with a JSP file named isAlive.jsp that can be contacted to determine if the server is down. Since we have not yet deployed OpenSSO Enterprise, isAlive.jsp cannot be used. In the following sub procedure, create a custom monitor that periodically accesses the Application server instance(s). If desired, the monitor can be changed later to use isAlive.jsp.
1. Click the Monitors tab
2. Click the Basic Associations tab
3. Find the IP address for osso-1:1081 and osso-2:1081.
4. Mark the Add checkbox for OSSO-1 and OSSO-2.
5. At the top of the Node column, choose the tcp monitor.
6. Click Apply.

Configure the load balancer for persistence.
1. In the left pane, click Pools.
2. Click the name of the pool you want to configure; in this case, OSSO-Pool.
3. Click the Persistence tab.
4. Under Persistence Type, select Passive HTTP Cookie.
5. Under Cookie Name, enter amlbcookie.
6. Click Apply.

In the left pane, click BIGpipe.

In the BIGpipe command window, type the following:
makecookie ip-address:port
ip-address is the IP address of the OSSO-1 host machine and port is the same machine's port number; in this case, 1081.

Press Enter to execute the command.

Something similar to Set-Cookie: BIGipServer[poolname]=692589248.36895.0000; path=/ is displayed. Save the numbered value (in this case, 692589248.36895.0000) for use in To Create a Site on OpenSSO Enterprise 1.

In the left pane, click BIGpipe again.

In the BIGpipe command window, type the following:
makecookie ip-address:port
ip-address is the IP address of the OSSO-2 host machine and port is the same machine's port number; in this case, 1081.

Press Enter to execute the command.

Something similar to Set-Cookie: BIGipServer[poolname]=692589248.12345.0000; path=/ is displayed. Save the numbered value (in this case, 692589248.12345.0000) for use in To Create a Site on OpenSSO Enterprise 1.

Log out of the load balancer console.

To Create an SSL Proxy for SSL Termination at the OpenSSO Enterprise Load Balancer

SSL communication is terminated at Load Balancer 2. The request is then re-encrypted and securely forwarded to OpenSSO Enterprise. When clients send an SSL-encrypted request to Load Balancer 2, it decrypts the request and re-encrypts it before sending it on to the OpenSSO Enterprise SSL port. Load Balancer 2 also encrypts the responses it receives back from OpenSSO Enterprise, and sends these encrypted responses back to the client. Towards this end create an SSL proxy for SSL termination and regeneration.

Before You Begin

You should have a root certificate issued by a recognized CA.

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

In the left pane, click Proxies.

Under the Proxies tab, click Add.

In the Add Proxy dialog, provide the following information.

Proxy Type:

Check the SSL and ServerSSL checkbox.

Proxy Address:

The IP address of Load Balancer 2.

Proxy Service:

1081

The secure port number

Destination Address:

The IP address of Load Balancer 2.

Destination Service:

1082

The non-secure port number

Destination Target:

Choose Local Virtual Server.

SSL Certificate:

Choose lb-2.example.com.

SSL Key:

Choose lb-2.example.com.

Enable ARP:

Check this checkbox.

Click Next.

On the page starting with “Insert HTTP Header String,” change to Rewrite Redirects and choose Matching.

Click Next.

On the page starting with “Client Cipher List String”, accept the defaults.

Click Next.

On the page starting with “Server Chain File,” change to Server Trusted CA's File, select “OpenSSL_CA_Cert.crt” from the drop-down list.

Click Done.

The new proxy server is added to the Proxy Server list.

Log out of the load balancer console.

Access https://lb-2.example.com:1081/index.html from a web browser.

If the Application Server index page is displayed, you can access it using the new proxy server port number and the load balancer is configured properly.

Tip –
A message may be displayed indicating that the browser doesn't recognize the certificate issuer. If this happens, install the CA root certificate in the browser so that the browser recognizes the certificate issuer. See your browser's online help system for information on installing a root CA certificate.

Close the browser.

5.3 Deploying and Configuring OpenSSO Enterprise 1 and OpenSSO Enterprise 2

An OpenSSO Enterprise WAR will be deployed in the installed Application Server containers on both the OpenSSO Enterprise host machines. Additionally, you will configure the deployed applications. Use the following list of procedures as a checklist for completing the tasks.

To Generate an OpenSSO Enterprise WAR on the OpenSSO Enterprise 1 Host Machine

As a root user, log in to the osso–1 host machine.

Create a directory into which the OpenSSO Enterprise ZIP file can be downloaded and change into it.
# mkdir /export/OSSO_BITS # cd /export/OSSO_BITS

Download the OpenSSO Enterprise ZIP file from http://www.sun.com/download/.

Unzip the downloaded file.

# unzip opensso_enterprise_80.zip
# cd /export/OSSO_BITS/opensso
# ls -al

total 66
        drwxr-xr-x  14 root     root         512 Jul 21 20:54 .
        drwxr-xr-x   3 root     root         512 Aug  5 16:49 ..
        -rw-r--r--   1 root     root         959 Jul 21 20:22 README
        drwxr-xr-x   6 root     root         512 Jul 21 20:58 deployable-war
        drwxr-xr-x   2 root     root         512 Jul 21 20:54 docs
        drwxr-xr-x   2 root     root         512 Jul 21 20:54 fedlet
        drwxr-xr-x   3 root     root         512 Jul 21 20:22 integrations
        drwxr-xr-x   2 root     root         512 Jul 21 20:54 ldif
        drwxr-xr-x   4 root     root         512 Jul 21 20:54 libraries
        -rw-r--r--   1 root     root       17003 Jul 21 20:22 license.txt
        drwxr-xr-x   2 root     root         512 Jul 21 20:54 migration
        drwxr-xr-x   2 root     root         512 Jul 21 20:54 patches
        drwxr-xr-x   2 root     root         512 Jul 21 20:54 samples
        drwxr-xr-x   3 root     root         512 Jul 21 20:58 tools
        drwxr-xr-x   8 root     root         512 Jul 21 20:32 upgrade
        drwxr-xr-x   2 root     root        2048 Jul 21 20:22 xml

Switch to the non-root user.
# su osso80adm

Create a staging area in the non-root user directory into which the WAR will be exploded.
# cd /export/osso80adm # mkdir osso-staging
Tip –
In the staging area, after exploding the WAR, you can modify the WAR contents to suit your needs, generate a new WAR, and deploy it on any number of remote host computers. Whenever you need to make changes to the WAR, you maintain the changes in this one staging area, and redeploy the modified WAR as many times as you want, on as many host machines as you need.

Explode the WAR file.

# cd osso-staging
# jar xvf /export/OSSO_BITS/opensso/deployable-war/opensso.war

Make the following modifications to the bootstrap.properties file.

By default, during the WAR deployment, OpenSSO Enterprise creates a bootstrap file in the user's home directory. The bootstrap.properties file points to the directory where all the OpenSSO Enterprise configurations will be created. With these modifications, OpenSSO Enterprise will create the bootstrap file in the directory you specify; in this case, /export/osso80adm/config. bootstrap.properties is located in /export/osso80adm/osso-staging/WEB-INF/classes.
- Uncomment the line that reads #configuration.dir=.
- Add the following value to the configuration.dir= property so it reads as follows.
  configuration.dir=/export/osso80adm/config

Regenerate the WAR.
# cd /export/osso80adm/osso-staging # jar cvf ../opensso.war *
A new WAR file is created, including the modified bootstrap.properties.

Verify that the new WAR was created in the proper location and with the appropriate permissions.

# cd /export/osso80adm
# ls -al

total 130552
drwxr-xr-x   7 osso80adm staff        512 Aug 5 13:44 .
drwxr-xr-x  12 root      sys          512 Aug 5 11:11 ..
-rw-------   1 osso80adm staff        779 Aug 5 14:56 .asadmintruststore
drwx------   2 osso80adm staff        512 Aug 5 14:44 .gconf
drwx------   2 osso80adm staff        512 Aug 5 14:44 .gconfd
-rw-r--r--   1 osso80adm staff        144 Aug 5 17:02 .profile
drwx------   3 osso80adm staff        512 Aug 5 11:20 .sunw
drwxr-xr-x   3 osso80adm staff        512 Aug 5 14:55 domains
drwxr-xr-x  21 osso80adm staff       1024 Aug 5 13:43 osso-staging
-rw-r--r--   1 osso80adm staff   68884903 Aug 5 13:45 opensso.war
-rw-r--r--   1 osso80adm staff        136 Aug 5 17:02 local.cshrc
-rw-r--r--   1 osso80adm staff        157 Aug 5 17:02 local.login
-rw-r--r--   1 osso80adm staff        174 Aug 5 17:02 local.profile

Note –

The opensso.war file is owned by osso80adm.

To Deploy the OpenSSO Enterprise WAR as OpenSSO Enterprise 1

Before You Begin

This procedure assumes you have just completed To Generate an OpenSSO Enterprise WAR on the OpenSSO Enterprise 1 Host Machine and are still logged into the osso–1 host machine

On the osso–1 host machine, switch to the non-root user osso80adm.
# su osso80adm

Start the ossodomain domain.

# cd /export/osso80adm/domains/ossodomain/bin
# ./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Run asadm deploy to deploy the OpenSSO Enterprise WAR.

# cd /opt/SUNWappserver91/bin
# ./asadm deploy --user domain2adm --host osso-1.example.com 
--port=8989 --contextroot opensso --name opensso --target server 
/export/osso80adm/opensso.war

Please enter the admin password> domain2pwd

Command deploy executed successfully.

List the contents of the j2ee-modules directory to verify that the WAR file was successfully deployed.

# cd /export/osso80adm/domains/ossodomain/applications/j2ee-modules
# ls -al

total 6
drwxr-xr-x   3 osso80adm staff      512 Aug 5 14:01 .
drwxr-xr-x   6 osso80adm staff      512 Aug 5 14:55 ..
drwxr-xr-x  21 osso80adm staff     1024 Aug 5 14:01 opensso

opensso exists in the directory and is owned by the non-root user osso80adm.

Log out of the osso–1 host machine.

To Copy the OpenSSO Enterprise WAR to the OpenSSO Enterprise 2 Host Machine

Before You Begin

This procedure assumes you have completed To Generate an OpenSSO Enterprise WAR on the OpenSSO Enterprise 1 Host Machine.

As a root user, log in to the osso–2 host machine.

Switch to the non-root user osso80adm.
# su osso80adm

Change into the osso80adm directory.
# cd /export/osso80adm

Copy opensso.war from the osso–1 host machine to the osso80adm directory.

Verify that the WAR file was copied into the proper location and with the appropriate permissions.

# ls -al

total 130552
drwxr-xr-x   6 osso80adm staff        512 Aug 5 14:14 .
drwxr-xr-x   8 root      sys          512 Aug 5 10:54 ..
-rw-r--r--   1 osso80adm staff         70 Aug 5 14:13 .asadminpass
-rw-------   1 osso80adm staff        778 Aug 5 14:12 .asadmintruststore
drwx------   2 osso80adm staff        512 Aug 5 13:15 .gconf
drwx------   2 osso80adm staff        512 Aug 5 13:26 .gconfd
-rw-r--r--   1 osso80adm staff        144 Aug 5 15:00 .profile
drwx------   3 osso80adm staff        512 Aug 5 15:26 .sunw
drwxr-xr-x   3 osso80adm staff        512 Aug 5 14:12 domains
-rw-r--r--   1 osso80adm staff   68884903 Aug 5 14:14 opensso.war
-rw-r--r--   1 osso80adm staff        136 Aug 5 15:00 local.cshrc
-rw-r--r--   1 osso80adm staff        157 Aug 5 15:00 local.login
-rw-r--r--   1 osso80adm staff        174 Aug 5 15:00 local.profile

opensso.war is owned by osso80adm.

To Deploy the OpenSSO Enterprise WAR File as OpenSSO Enterprise 2

Before You Begin

This procedure assumes you have just completed To Copy the OpenSSO Enterprise WAR to the OpenSSO Enterprise 2 Host Machine and are still logged into the osso–2 host machine

On the osso–2 host machine, switch to the non-root user osso80adm.
# su osso80adm

Start the ossodomain domain.

# cd /export/osso8/domains/ossodomain/bin
# ./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Run asadm deploy to deploy the OpenSSO Enterprise WAR file.

# cd /opt/SUNWappserver91/bin
# ./asadm deploy --user domain2adm --host osso-2.example.com 
--port=8989 --contextroot opensso --name opensso --target server 
/export/osso80adm/opensso.war

Please enter the admin password> domain2pwd

Command deploy executed successfully.

List the contents of the j2ee-modules directory to verify that the WAR file was successfully deployed.

# cd /export/osso80adm/domains/ossodomain/applications/j2ee-modules
# ls -al

total 6
drwxr-xr-x   3 osso80adm staff      512 Aug 5 14:01 .
drwxr-xr-x   6 osso80adm staff      512 Aug 5 14:55 ..
drwxr-xr-x  21 osso80adm staff     1024 Aug 5 14:01 opensso

opensso exists in the directory and is owned by the non-root user osso80adm.

Log out of the osso–2 host machine.

To Configure OpenSSO Enterprise 1

Access https://osso-1.example.com:1081/opensso from a web browser.

The OpenSSO Enterprise Configurator page is displayed for first time access.

Select Create New Configuration under Custom Configuration on the Configurator page.

The OpenSSO Enterprise Custom Configuration Wizard is displayed.

Provide the following information for the Default User [amAdmin] in Step 1: General and click Next.

Password

ossoadmin

Confirm

ossoadmin

Accept the default values in Step 2: Server Settings and click Next

Do the following in Step 3: Configuration Store and click Next
1. Select First Instance.
2. Select Embedded (Open DS) as the configuration data store.
3. Accept the default values for the Port, Encryption Key, and Root Suffix fields.

Select Remote Directory in Step 4: User Store Settings, provide the following information and click Next

SSL Enabled

Check the box.

Directory Name

lb-1.example.com

Port

489

Root Suffix

dc=company,dc=com

Password

dsmanager

Store Type

Select Generic LDAP.

Select No in Step 5: Site Configuration and click Next.

Provide the following information for the Default Agent User [amldapuser] in Step 6: Default Agent User and click Next.

Password

agentuser

Confirm

agentuser

Click Create Configuration on the Summary page.

The Configuration Complete page is displayed after configuration is completed.

Click Proceed to Login on the Configuration Complete page.

Log in to the OpenSSO Enterprise console as the administrator.

User Name:

amadmin

Password:

ossoadmin

If authentication succeeds and the OpenSSO Enterprise console is displayed, OpenSSO Enterprise has successfully accessed the embedded configuration data store.

(Optional) To verify that the config directory and the supporting bootstrap directory have been created with the proper permissions, do the following.

As a root user, log in to the osso–1 host machine.

Examine the file system.

# cd /export/osso80adm
# ls -al

total 130556
drwxr-xr-x   8 osso80adm staff        512 Aug  6 19:32 .
drwxr-xr-x  14 root      sys          512 Aug  6 09:07 ..
-rw-r--r--   1 osso80adm staff         70 Mar 27 14:01 .asadminpass
-rw-------   1 osso80adm staff       1527 Aug  6 18:27 .asadmintruststore
drwx------   2 osso80adm staff        512 Mar 26 14:44 .gconf
drwx------   2 osso80adm staff        512 Mar 26 14:44 .gconfd
-rw-r--r--   1 osso80adm staff       1436 Apr  2 14:34 .keystore
-rw-r--r--   1 osso80adm staff        144 Mar 11 17:02 .profile
drwx------   3 osso80adm staff        512 Mar 24 11:20 .sunw
drwxr-xr-x   4 osso80adm staff        512 Aug  6 19:34 config
drwxr-xr-x   4 osso80adm staff        512 Aug  6 18:26 domains
drwxr-xr-x  21 osso80adm staff       1024 Aug  6 19:15 osso-staging
-rw-r--r--   1 osso80adm staff   68884903 Aug  6 19:17 opensso.war
-rw-r--r--   1 osso80adm staff        136 Mar 11 17:02 local.cshrc
-rw-r--r--   1 osso80adm staff        157 Mar 11 17:02 local.login
-rw-r--r--   1 osso80adm staff        174 Mar 11 17:02 local.profile

The config directory was created and is owned by non-root user osso80adm.

Log out of the osso–1 host machine.

To Configure OpenSSO Enterprise 2

Access https://osso-2.example.com:1081/opensso from a web browser.

The OpenSSO Enterprise Configurator page is displayed for first time access.

Select Create New Configuration under Custom Configuration on the Configurator page.

The OpenSSO Enterprise Custom Configuration Wizard is displayed.

Provide the following information for the Default User [amAdmin] in Step 1: General and click Next.

Password

ossoadmin

Confirm

ossoadmin

Accept the default values in Step 2: Server Settings and click Next

Do the following in Step 3: Configuration Store and click Next
1. Select Add to Existing Deployment as the configuration data store.
2. Server URL: https://osso-1.example.com:1081/opensso
3. Accept the default values for the ports.

Select No in Step 5: Site Configuration and click Next.

Click Create Configuration on the Summary page.

The Configuration Complete page is displayed after configuration is completed.

Click Proceed to Login on the Configuration Complete page.

Log in to the OpenSSO Enterprise console as the administrator.

User Name:

amadmin

Password:

ossoadmin

If authentication succeeds and the OpenSSO Enterprise console is displayed, OpenSSO Enterprise has successfully accessed the embedded configuration data store.

(Optional) To verify that the config directory and the supporting bootstrap directory have been created with the proper permissions, do the following.

As a root user, log in to the osso–2 host machine.

Examine the file system.

# cd /export/osso80adm
# ls -al

total 130556
drwxr-xr-x   8 osso80adm staff        512 Aug  6 19:32 .
drwxr-xr-x  14 root      sys          512 Aug  6 09:07 ..
-rw-r--r--   1 osso80adm staff         70 Mar 27 14:01 .asadminpass
-rw-------   1 osso80adm staff       1527 Aug  6 18:27 .asadmintruststore
drwx------   2 osso80adm staff        512 Mar 26 14:44 .gconf
drwx------   2 osso80adm staff        512 Mar 26 14:44 .gconfd
-rw-r--r--   1 osso80adm staff       1436 Apr  2 14:34 .keystore
-rw-r--r--   1 osso80adm staff        144 Mar 11 17:02 .profile
drwx------   3 osso80adm staff        512 Mar 24 11:20 .sunw
drwxr-xr-x   4 osso80adm staff        512 Aug  6 19:34 config
drwxr-xr-x   4 osso80adm staff        512 Aug  6 18:26 domains
drwxr-xr-x  21 osso80adm staff       1024 Aug  6 19:15 osso-staging
-rw-r--r--   1 osso80adm staff   68884903 Aug  6 19:17 opensso.war
-rw-r--r--   1 osso80adm staff        136 Mar 11 17:02 local.cshrc
-rw-r--r--   1 osso80adm staff        157 Mar 11 17:02 local.login
-rw-r--r--   1 osso80adm staff        174 Mar 11 17:02 local.profile

The config directory was created and is owned by non-root user osso80adm.

Log out of the osso–2 host machine.

5.4 Configuring the OpenSSO Enterprise Platform Service

The Platform Service provides centralized configuration management for an OpenSSO Enterprise deployment. In this procedure, you configure the two OpenSSO Enterprise servers to work as a single unit. Once configured as a site, all client requests go through the configured load balancer. Use the following list of procedures as a checklist for completing this task.

To Create a Site on OpenSSO Enterprise 1

It is not necessary to repeat this procedure on OpenSSO Enterprise 2.

Access https://osso-1.example.com:1081/opensso/console in a web browser.

Under the Configuration tab, click Servers and Sites.

The Servers and Sites page is displayed.

Click New under Sites.

The New Site properties page is displayed.

Enter the following values for the load balancer and click OK.

Name

External

Primary URL

https://lb-2.example.com:1081/opensso

A new site called External is displayed in the Sites list.

Click on the https://osso-1.example.com:1081/opensso server entry under the Servers list.

The Edit https://osso-1.example.com:1081/opensso page is displayed.

Assign External from the Parent Site drop down list and click Save.

Click the Advanced tab.

Enter the number generated for the OSSO-1 host machine as the value of the com.iplanet.am.lbcookie.value property and click Save.

The number was generated using the makecookie command in To Configure the OpenSSO Enterprise Load Balancer.

Click Back to Server and Sites.

Click on the https://osso-2.example.com:1081/opensso server entry under the Servers list.

The Edit https://osso-2.example.com:1081/opensso page is displayed.

Assign External from the Parent Site drop down list and click Save.

Click the Advanced tab.

Enter the number generated for the OSSO-2 host machine as the value of the com.iplanet.am.lbcookie.value property and click Save.

The number was generated using the makecookie command in To Configure the OpenSSO Enterprise Load Balancer.

Click Back to Server and Sites.

Note –
You should see External under the Site Name column for both servers.

Log out of the OpenSSO Enterprise console.

As a root user, log in to the osso–1 host machine.

Restart OpenSSO Enterprise for the changes to take effect.

# su osso80adm
# cd /export/osso80adm/domains/ossodomain/bin
# ./stopserv; ./startserv

Server was successfully stopped.

admin username:  domain2adm

admin password:  domain2pwd

master password: domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

As a root user, log in to the osso–2 host machine.

Restart OpenSSO Enterprise for the changes to take effect.

# su osso80adm
# cd /export/osso80adm/domains/ossodomain/bin
# ./stopserv; ./startserv

Server was successfully stopped.

admin username:  domain2adm

admin password:  domain2pwd

master password: domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Log out of both OpenSSO Enterprise host machines.

To Verify that the OpenSSO Enterprise Site was Configured Properly

Access the load balancer at https://lb-2.example.com:1081/opensso/UI/Login.

If an error message is displayed indicating that the browser cannot connect to either osso-1.example.com or osso-2.example.com, the site configuration is not correct. If the site configuration is correct, all browser interactions will occur as expected.

When the OpenSSO Enterprise login page is displayed, verify that the browser URL still contains the secure Site URL for the load balancer.

If it does not contain the Site URL, the site configuration is incorrect. If the site configuration is correct, all browser interactions will occur through the secure Site URL.

Log in to the OpenSSO Enterprise console as the administrator.

User Name:

amadmin

Password:

ossoadmin

A successful login occurs when the site configuration is correct.

Log out of the OpenSSO Enterprise console.

Chapter 6 Configuring OpenSSO Enterprise Realms for User Authentication

This chapter contains instructions on configuring OpenSSO Enterprise,to use an external user data store for authentication. (The external user data store and test users were set up in Chapter 4, Installing Sun Java System Directory Server and Creating Instances for Sun OpenSSO Enterprise User Data). This is done by modifying the top-level realm or, alternately, configuring a sub realm for the external users and creating an authentication chain. Choose either of the sections listed to configure OpenSSO Enterprise for user authentication.

Caution –

Do not do both procedures.

6.1 Modifying the Top-Level Realm for Test Users

At this point in the deployment, the OpenSSO Enterprise root realm (by default, / (Top Level Realm)) is configured to authenticate special OpenSSO Enterprise accounts (for example, amadmin and agents) against the embedded configuration data store. Since the external user data store is an instance of Directory Server (and not part of the embedded configuration data store), we now modify the external user data store configuration details using the OpenSSO Enterprise console to map the user data stores schema to the test user entries previously imported. Use the following list of procedures as a checklist for completing this task.

To Modify the Top-Level Realm for User Authentication

Access https://osso-1.example.com:1081/opensso/console in a web browser.

Click the Access Control tab.

Click / (Top Level Realm), the root realm, under the Access Control tab.

Click the Data Stores tab.

The GenericLDAPv3 data store link is displayed.

Click GenericLDAPv3.

On the GenericLDAPv3 data store properties page, set the following attribute values and click Save.

LDAP People Container Naming Attribute

Enter ou.

LDAP Groups Container Value

Enter Groups.

LDAP Groups Container Naming Attribute

Enter ou.

LDAP People Container Value

Enter users.

Note –
If this field is empty, the search for user entries will start from the root suffix.

Click Back to Data Stores.

(Optional) Click the Subjects tab to verify that the test users are now displayed.

testuser1 and testuser2 are displayed under Users (as well as others created during OpenSSO Enterprise configuration.

Click the Authentication tab.

Click the Advanced Properties link under General.

The Core Realm Attributes page is displayed.

Change the value of User Profile to Ignored.

This new value specifies that a user profile is not required by the Authentication Service in order to issue a token after successful authentication. This modification is specific to this deployment example because the OpenSSO Enterprise schema and the Directory Server schema have not been mapped.

Click Save.

Click Back to Authentication.

Click Back to Access Control.

Log out of the OpenSSO Enterprise console.

To Verify that a User Can Successfully Authenticate

You should be able to log in successfully as a test user.

Access https://osso-1.example.com:1081/opensso/UI/Login in a web browser.

Log in to the OpenSSO Enterprise console as the administrator.

User Name:

testuser1

Password:

password

You should be able to log in successfully and see a page with a message that reads You're logged in. Since the User Profile attribute was set to Ignored, the user's profile is not displayed after a successful login. If the login is not successful, watch the Directory Server access log to troubleshoot the problem.

6.2 Creating and Configuring a Sub Realm for Test Users

At this point in the deployment, / (Top Level Realm), the root realm, is configured to authenticate special OpenSSO Enterprise accounts (for example, amadmin and agents) against the embedded configuration data store. Create a sub realm to authenticate external users against the Directory Server user data store instances. This creates a demarcation between OpenSSO Enterprise configuration and administrative data and the user data. Use the following list of procedures as a checklist for completing this task.

To Create a Sub Realm

When a sub realm is created it inherits configuration data (including which user data store) from / (Top Level Realm) (the default root realm) and uses it to authenticate users. The user data store can be modified per sub realm. In this deployment, we use the inherited GenericLDAPv3 data store.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Click the Access Control tab.

Click New to create a new realm.

The New Realm page is displayed.

Set the following attribute values on the New Realm page.

Name

Enter users.

Realm/DNS Aliases

Enter users in the New Value field and click Add.

Click OK.

The users realm is listed as a sub realm of / (Top Level Realm), the root realm.

To Change the User Profile Configuration for the Sub Realm

Before You Begin

This procedure assumes you have just completed To Create a Sub Realm and are still logged in to the OpenSSO Enterprise console.

Under the Access Control tab, click the users realm.

Click the Authentication tab.

Click the Advanced Properties link under General.

The Core Realm Attributes page is displayed.

Change the value of User Profile to Ignored.

This new value specifies that a user profile is not required by the Authentication Service in order to issue a token after successful authentication.

Click Save.

Log out of the OpenSSO Enterprise console.

To Modify the Sub Realm for User Authentication

Access https://osso-1.example.com:1081/opensso/console in a web browser.

Click the Access Control tab.

Click users, the sub realm, under the Access Control tab.

Click the Data Stores tab.

The GenericLDAPv3 data store link is displayed.

Click GenericLDAPv3.

On the GenericLDAPv3 data store properties page, set the following attribute values and click Save.

LDAP People Container Naming Attribute

Enter ou.

LDAP Groups Container Value

Enter Groups.

LDAP Groups Container Naming Attribute

Enter ou.

LDAP People Container Value

Enter users.

Note –
If this field is empty, the search for user entries will start from the root suffix.

Click Back to Data Stores.

(Optional) Click the Subjects tab to verify that the test users are now displayed.

testuser1 and testuser2 are displayed under Users (as well as others created during OpenSSO Enterprise configuration).

Log out of the OpenSSO Enterprise console.

To Verify That the Sub Realm Can Access the External User Data Store

This optional procedure is to verify the modifications made in To Create a Sub Realm and To Change the User Profile Configuration for the Sub Realm.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Click on the Access Control tab

Click on the users sub realm.

Click on the Subjects tab.

testuser1 and testuser2 are displayed under Users.

Log out of the OpenSSO Enterprise console.

To Verify That the Sub Realm Subjects Can Successfully Authenticate

Access https://osso-1.example.com:1081/opensso/UI/Login?realm=users from a web browser.

The parameter realm=users specifies the realm to use for authentication. At this point, a user can log in against Directory Server only if the realm parameter is defined in the URL.

Log in to OpenSSO Enterprise with a user name and password from the am-users directory.

User Name

testuser1

Password

password

You should be able to log in successfully and see a page with a message that reads You're logged in. Since the User Profile attribute was set to Ignored, the user's profile is not displayed after a successful login. If the login is not successful, watch the Directory Server access log to troubleshoot the problem.

Chapter 7 Installing and Configuring the Distributed Authentication User Interface

OpenSSO Enterprise provides a remote authentication interface to enable secure authentication. Deploying the Distributed Authentication User Interface to one or more web containers within a non-secure layer eliminates the exposure of service URLs to the end user. This chapter contains the procedures to install and configure the Distributed Authentication User Interface in the following sections.

7.1 Installing the Distributed Authentication User Interface Web Containers

In this section, we will create a non-root user on the two machines that will host the Distributed Authentication User Interface and install Sun Java System Web Server using the non-root user. Use the following list of procedures as a checklist for completing the task.

To Create a Non-Root User on the Distributed Authentication User Interface 1 Host Machine

Create the non-root user using the roleadd command in the Solaris Operating Environment on the Distributed Authentication User Interface 1 (da-1) host machine.

As a root user, log in to the da-1 host machine.

Use roleadd to create a new user.

# roleadd -s /sbin/sh -m -g staff -d /export/da80adm da80adm

(Optional) Verify that the user was created.

# cat /etc/passwd

root:x:0:0:Super-User:/:/sbin/sh
daemon:x:1:1::/:
...
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
da80adm:x:223830:10::/export/da80adm:/sbin/sh

(Optional) Verify that the user's directory was created.

# cd /export/da80adm
# ls

local.cshrc    local.profile    local.login

(Optional) Create a password for the non-root user.
# passwd da80adm New Password: da80a6m Re-ener new Pasword: da80a6m passwd: password successfully changed for da80adm
Note –
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.

To Install the Web Server for Distributed Authentication User Interface 1

Before You Begin

This procedure assumes that you have just completed To Create a Non-Root User on the Distributed Authentication User Interface 1 Host Machine and are still logged in as the root user.
Read the Web Server 7.0 Release Notes to determine the latest patches you might need to install.

On the da-1 host machine, install required patches if necessary.

In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 117461–08, patch 119963–08, and patch 120011–14 are required.
1. Run patchadd to see if the patches are already installed.
  # patchadd -p | grep 117461–08
  A list of patch numbers is displayed. This machine is already patched with 117461–08.
  # patchadd -p | grep 119963-08
  No results are returned which indicates that the patch is not yet installed on the system.
  # patchadd -p | grep 120011-14
  No results are returned which indicates that the patch is not yet installed on the system.
2. Make a directory for downloading the patches you need and change into it.
  # mkdir /export/patches # cd /export/patches
3. Download the patches.
  
  You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
  
  Note –
  Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
4. Unzip the patch files.
  # unzip 119963-08.zip # unzip 120011-14.zip
5. Run patchadd to install the patches.
  # patchadd /export/patches/119963-08 # patchadd /export/patches/120011-14
  Tip –
  You can use the -M option to install all patches at once. See the patchadd man page for more information.
6. After installation is complete, run patchadd to verify that each patch was added successfully.
  # patchadd -p | grep 119963-08
  A series of patch numbers is displayed, and the patch 119963-08 is present.
  # patchadd -p | grep 120011-14
  A series of patch numbers is displayed, and the patch 120011–14 is present.

Create a directory into which you can download the Web Server bits and change into it.
# mkdir /export/WS7 # cd /export/WS7

Download the Sun Java System Web Server 7.0 Update 2 software from http://www.sun.com/download/products.xml?id=45ad781d.

Follow the instructions on the Sun Microsystems Product Downloads web site for downloading the software.

Unpack the software package.

# gunzip sjsws-7_0u2-solaris-sparc.tar.gz
# tar xvf sjsws-7_0u2-solaris-sparc.tar

Run setup.
# cd /export/WS7 # ./setup --console

When prompted, provide the following information.

You will be asked to specify 
preferences that determine how Sun Java 
System Web Server 7.0U2 is installed 
and configured.
...
The installation program pauses as questions 
are presented so you can read the 
information and make your choice.  
When you are ready to continue, press Enter
(Return on some keyboards).

Press Enter.

Continue to press Enter when prompted.

Have you read the Software License 
Agreement and do you accept all terms [no] 
{"<" goes back, "!" exits}?

Enter yes.

Sun Java System Web Server 7.0 
Installation Directory [/sun/webserver7] 
{"<" goes back, "!" exits}

Enter /opt/SUNWwbsvr

Specified directory /opt/SUNWwbsvr 
does not exist. Create Directory? [Yes/No]
{"<" goes back, "!" exits}

Enter yes.

Select Type of Installation

1. Express
2. Custom
3. Exit

What would you like to do? [1]
{"<" goes back, "!" exits}

Enter 2.

Component Selection

1. Server Core
2. Server Core 64-bit Binaries
3. Administration Command Line Interface
4. Sample Applications
5. Language Pack

Enter the comma-separated list [1,2,3,4,5] 
{"<" goes back, "!" exits}

Enter 1,3,5.

Java Configuration

Sun Java System Web Server 7.0 requires 
Java SE Development Kit (JDK). Provide the 
path to a JDK 1.5.0_12 or greater. 

1. Install Java SE Development Kit (JDK) 
   1.5.0_12
2. Reuse existing Java SE Development Kit 
   (JDK) 1.5.0_12 or greater
3. Exit

What would you like to do? [1] 
{"<" goes back, "!" exits}

Enter 1.

Administrative Options

1. Create an Administration Server and a 
   Web Server Instance
2. Create an Administration Node

Enter your option. [1] 
{"<" goes back, "!" exits}

Enter 1.

Create SMF services for server 
instances [yes/no] 
{"<" goes back, "!" exits}

Enter no.

Host Name [da-1.example.com] 
{"<" goes back, "!" exits}

Accept the default value.

SSL Port [8989] 
{"<" goes back, "!" exits}

Accept the default value.

Create a non-SSL Port? [yes/no] 
{"<" goes back, "!" exits}

Enter no.

Runtime User ID [root] 
{"<" goes back, "!" exits}

Enter da80adm.

Administrator User Name [admin]
{"<" goes back, "!" exits}

Accept the default value.

Administrator Password:

Enter web4dmin.

Retype Password:

Enter web4dmin.

Server Name [da-1.example.com] 
{"<" goes back, "!" exits}

Accept the default value.

HTTP Port [8080] 
{"<" goes back, "!" exits}

Enter 1080.

Document Root Directory [/opt/SUNWwbsvr/
https-da-1.example.com/docs] 
{"<" goes back, "!" exits}

Accept the default value.

Start Administration Server 
[yes/no] {"<" goes back, "!" exits}

Enter no.

Ready To Install 

1. Install Now
2. Start Over
3. Exit Installation 

What would you like to do?

Enter 1.

When installation is complete, the following message is displayed:

Installation Successful.

(Optional) To verify that Web Server was installed with the non-root user, examine the file permissions.

# cd /opt/SUNWwbsvr/admin-server
# ls -al

total 16
drwxr-xr-x   8 root     root         512 Jul 19 10:36 .
drwxr-xr-x  11 da80adm  staff        512 Jul 19 10:36 ..
drwxr-xr-x   2 root     root         512 Jul 19 10:36 bin
drwx------   2 da80adm  staff        512 Jul 19 10:36 config
drwx------   3 da80adm  staff        512 Jul 19 11:09 config-store
drwx------   3 da80adm  staff        512 Jul 19 10:40 generated
drwxr-xr-x   2 da80adm  staff        512 Jul 19 10:40 logs
drwx------   2 da80adm  staff        512 Jul 19 10:36 sessions

The appropriate files and directories are owned by da80adm.

Start the Web Server administration server.

# su da80adm
# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

(Optional) Verify that the non-root user was able to start Web Server.
1. Access https://da-1.example.com:8989 from a web browser.
2. Log in to the Web Server console as the administrator.
  
  User Name:
  
  admin
  
  Password:
  
  web4dmin
  
  The Web Server administration console opens.
3. Log out of the console and close the browser.

Log out of the da–1 host machine.

To Create a Non-Root User on the Distributed Authentication User Interface 2 Host Machine

Create the non-root user using the roleadd command in the Solaris Operating Environment on the Distributed Authentication User Interface 2 (da-2) host machine.

As a root user, log in to the da-2 host machine.

Use roleadd to create a new user.

# roleadd -s /sbin/sh -m -g staff -d /export/da80adm da80adm

(Optional) Verify that the user was created.

# cat /etc/passwd

root:x:0:0:Super-User:/:/sbin/sh
daemon:x:1:1::/:
...
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
da80adm:x:227627:10::/export/da80adm:/sbin/sh

(Optional) Verify that the user's directory was created.

# cd /export/da80adm
# ls

local.cshrc    local.profile    local.login

(Optional) Create a password for the non-root user.
# passwd da80adm New Password: da80a6m Re-ener new Pasword: da80a6m passwd: password successfully changed for da80adm
Note –
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.

To Install Sun Java System Web Server for Distributed Authentication User Interface 2

Before You Begin

This procedure assumes that you have just completed To Create a Non-Root User on the Distributed Authentication User Interface 2 Host Machine and are still logged in as the root user.
Read the Web Server 7.0 Release Notes to determine the latest patches you might need to install.

On the da-2 host machine, install required patches if necessary.

In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 117461–08, patch 119963–08, and patch 120011–14 are required.
1. Run patchadd to see if the patches are already installed.
  # patchadd -p | grep 117461–08
  A list of patch numbers is displayed. This machine is already patched with 117461–08.
  # patchadd -p | grep 119963-08
  No results are returned which indicates that the patch is not yet installed on the system.
  # patchadd -p | grep 120011-14
  No results are returned which indicates that the patch is not yet installed on the system.
2. Make a directory for downloading the patches you need and change into it.
  # mkdir /export/patches # cd /export/patches
3. Download the patches.
  
  You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
  
  Note –
  Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
4. Unzip the patch files.
  # unzip 119963-08.zip # unzip 120011-14.zip
5. Run patchadd to install the patches.
  # patchadd /export/patches/119963-08 # patchadd /export/patches/120011-14
  Tip –
  You can use the -M option to install all patches at once. See the patchadd man page for more information.
6. After installation is complete, run patchadd to verify that each patch was added successfully.
  # patchadd -p | grep 119963-08
  A series of patch numbers is displayed, and the patch 119963-08 is present.
  # patchadd -p | grep 120011-14
  A series of patch numbers is displayed, and the patch 120011–14 is present.

Create a directory into which you can download the Web Server bits and change into it.
# mkdir /export/WS7 # cd /export/WS7

Download the Sun Java System Web Server 7.0 Update 2 software from http://www.sun.com/download/products.xml?id=45ad781d.

Follow the instructions on the Sun Microsystems Product Downloads web site for downloading the software.

Unpack the software package.

# gunzip sjsws-7_0u2-solaris-sparc.tar.gz
# tar xvf sjsws-7_0u2-solaris-sparc.tar

Run setup.
# cd /export/WS7 # ./setup --console

When prompted, provide the following information.

You will be asked to specify 
preferences that determine how Sun Java 
System Web Server 7.0U2 is installed 
and configured.
...
The installation program pauses as questions 
are presented so you can read the 
information and make your choice.  
When you are ready to continue, press Enter
(Return on some keyboards).

Press Enter.

Continue to press Enter when prompted.

Have you read the Software License 
Agreement and do you accept all terms [no] 
{"<" goes back, "!" exits}?

Enter yes.

Sun Java System Web Server 7.0 
Installation Directory [/sun/webserver7] 
{"<" goes back, "!" exits}

Enter /opt/SUNWwbsvr

Specified directory /opt/SUNWwbsvr 
does not exist. Create Directory? [Yes/No]
{"<" goes back, "!" exits}

Enter yes.

Select Type of Installation

1. Express
2. Custom
3. Exit

What would you like to do? [1]
{"<" goes back, "!" exits}

Enter 2.

Component Selection

1. Server Core
2. Server Core 64-bit Binaries
3. Administration Command Line Interface
4. Sample Applications
5. Language Pack

Enter the comma-separated list [1,2,3,4,5] 
{"<" goes back, "!" exits}

Enter 1,3,5.

Java Configuration

Sun Java System Web Server 7.0 requires 
Java SE Development Kit (JDK). Provide the 
path to a JDK 1.5.0_12 or greater. 

1. Install Java SE Development Kit (JDK) 
   1.5.0_12
2. Reuse existing Java SE Development Kit 
   (JDK) 1.5.0_12 or greater
3. Exit

What would you like to do? [1] 
{"<" goes back, "!" exits}

Enter 1.

Administrative Options

1. Create an Administration Server and a 
   Web Server Instance
2. Create an Administration Node

Enter your option. [1] 
{"<" goes back, "!" exits}

Enter 1.

Create SMF services for server 
instances [yes/no] 
{"<" goes back, "!" exits}

Enter no.

Host Name [da-2.example.com] 
{"<" goes back, "!" exits}

Accept the default value.

SSL Port [8989] 
{"<" goes back, "!" exits}

Accept the default value.

Create a non-SSL Port? [yes/no] 
{"<" goes back, "!" exits}

Enter no.

Runtime User ID [root] 
{"<" goes back, "!" exits}

Enter da80adm.

Administrator User Name [admin]
{"<" goes back, "!" exits}

Accept the default value.

Administrator Password:

Enter web4dmin.

Retype Password:

Enter web4dmin.

Server Name [da-2.example.com] 
{"<" goes back, "!" exits}

Accept the default value.

HTTP Port [8080] 
{"<" goes back, "!" exits}

Enter 1080.

Document Root Directory [/opt/SUNWwbsvr/
https-da-2.example.com/docs] 
{"<" goes back, "!" exits}

Accept the default value.

Start Administration Server 
[yes/no] {"<" goes back, "!" exits}

Enter no.

Ready To Install 

1. Install Now
2. Start Over
3. Exit Installation 

What would you like to do?

Enter 1.

When installation is complete, the following message is displayed:

Installation Successful.

(Optional) To verify that Web Server was installed with the non-root user, examine the file permissions.

# cd /opt/SUNWwbsvr/admin-server
# ls -al

total 16
drwxr-xr-x   8 root     root         512 Jul 19 10:36 .
drwxr-xr-x  11 da80adm  staff        512 Jul 19 10:36 ..
drwxr-xr-x   2 root     root         512 Jul 19 10:36 bin
drwx------   2 da80adm  staff        512 Jul 19 10:36 config
drwx------   3 da80adm  staff        512 Jul 19 11:09 config-store
drwx------   3 da80adm  staff        512 Jul 19 10:40 generated
drwxr-xr-x   2 da80adm  staff        512 Jul 19 10:40 logs
drwx------   2 da80adm  staff        512 Jul 19 10:36 sessions

The appropriate files and directories are owned by da80adm.

Start the Web Server administration server.

# su da80adm
# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

(Optional) Verify that the non-root user was able to start Web Server.
1. Access https://da-2.example.com:8989 from a web browser.
2. Log in to the Web Server console as the administrator.
  
  User Name:
  
  admin
  
  Password:
  
  web4dmin
  
  The Web Server administration console opens.
3. Log out of the console and close the browser.

Log out of the da–2 host machine.

7.2 Enabling Secure Communications Between the Web Server Instances and the Load Balancer

When a Web Server instance is created, it contains a default http-listener port. In the following sections, certificates are requested and installed, and a new http-listener port is created and enabled for secure communication with the OpenSSO Enterprise Load Balancer 3.

To Request and Install a Server Certificate and a Root Certificate for Web Server 1

The wadm command line interface, bundled with the Web Server, is used to import the root and server certificates into the Web Server certificate store.

Before You Begin

Copy the same root certificate imported in 4.3 Enabling Secure Communication for the Directory Server User Data Instances to the da-1 host machine. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

As a root user, log in to the da–1 host machine.

Start the Web Server Administration Server.

# su da80adm
# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

Create a temporary file that contains the administration password.

This file will be used for certificate request generation and certificate installation
# cd /export/da80adm # cat > admin.pwd wadm_password=web4dmin Hit Control D to terminate the command. ^D

Generate a certificate signing request.

# cd /opt/SUNWwbsvr/bin
# ./wadm create-cert-request --user=admin 
--password-file=/export/da80adm/admin.pwd --host=da-1.example.com 
--port=8989 --key-type=rsa --org="Sun Microsystems" 
--org-unit="Sun Distributed Authentication" 
--locality="Santa Clara" --state=California --country=US 
--config=da-1.example.com --token=internal
--server-name=da-1.example.com

Copy the output into a file named da-1.csr and send the request to the CA of your choice.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIB2DCCAUECAQAwgZcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRQwEgYDVQQHEwtTYW50YSBDbGFyYTEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVt
czEnMCUGA1UECxMeU3VuIERpc3RyaWJ1dGVkIEF1dGhlbnRpY2F0aW9uMRkwFwYD
VQQDExBkYS0xLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDGdeNgE00/6o3nrG38yatMhnrJeUVR86Pj5rBk282DQQfVenuWt0hL8Y6q9KvT
JQRoeclWMl94ZErdtNY0qKqXZBxhC0CCtiAvNHJAg8zErGTOADs6ptmXkzVRGBXE
b7zLOGlROnK9xAw0wms/aFsbA/Mb0zMI5PDztRAf5A8fIQIDAQABoAAwDQYJKoZI
hvcNAQEFBQADgYEAqap+9N/T+pzzAZL+EiG3rciKcG+Ij94Yk+3q0hMj3d3xer8Q
1shLAy4za9qHvOnT8M7hpKY6lpw4Y4N+w3eIgfDc3aCnz1Aot5Na4alWJZ81SUAZ
Fl6fD7CX7KMtF6Agfpi5OV+NdOiBL6tQ7F7G70c3pYV5MnQvYf5dnuiZEkQ=
-----END NEW CERTIFICATE REQUEST-----

The CA issues and returns a certified server certificate named da-1.cer.

Install da-1.cer, the server certificate.

# ./wadm install-cert --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-1.example.com --port=8989 
--token=internal --cert-type=server 
--nickname=da-1 da-1.cer

CLI201 Command 'install-cert' ran successfully

(Optional) Verify that the server certificate was properly installed.

# ./wadm list-certs --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-1.example.com --token=internal 
--cert-type=server

da-1

The output indicates that the server certificate was properly installed.

Install ca.cer, the root certificate.

# ./wadm install-cert --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-1.example.com --port=8989 
--token=internal --cert-type=ca 
--nickname=OpenSSLTestCA ca.cer

CLI201 Command 'install-cert' ran successfully

(Optional) Verify that the root certificate was properly installed.

# ./wadm list-certs --user=admin 
--password-file=/export/da80adm/admin.pwd 
--token=internal --cert-type=ca 
--config=da-1.example.com | grep -i open

openSSLTestCA - sun

The output indicates that the root certificate was properly installed.

To Create an SSL Enabled HTTP Listener Port on Web Server 1

The wadm command line interface, bundled with the Web Server, is used in this procedure.

Before You Begin

This procedure assumes that you have just completed To Request and Install a Server Certificate and a Root Certificate for Web Server 1 and are still logged in as the non-root user.

Create an SSL enabled HTTP listener port on Web Server 1.

# ./wadm create-http-listener --user=admin 
--password-file=/export/da80adm/admin.pwd 
--host=da-1.example.com --port=8989 
--listener-port=1443 --config=da-1.example.com 
--server-name=da-1.example.com 
--default-virtual-server-name=da-1.example.com 
http-listener-2

CLI201 Command 'create-http-listener' ran successfully

(Optional) Verify that the listener was created.

# ./wadm get-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-1.example.com 
--http-listener=http-listener-2

tls=true
client-auth-timeout=60
client-auth=false
enabled=false
ssl2=false
max-client-auth-data=1048576
tls-rollback-detection=true
ssl3=true

The output indicates that the listener was properly created.

Enable SSL for the newly created HTTP listener port.

# ./wadm set-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-1.example.com 
--http-listener=http-listener-2
enabled=true

CLI201 Command 'set-ssl-prop' ran successfully

Associate the HTTP listener port with the nickname of the certificate.

# ./wadm set-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-1.example.com 
--http-listener=http-listener-2
server-cert-nickname=da-1

CLI201 Command 'set-ssl-prop' ran successfully

(Optional) Verify that SSL is enabled on the listener port and is configured with an associated server certificate.

# ./wadm get-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-1.example.com 
--http-listener=http-listener-2

tls=true
server-cert-nickname=da-1
client-auth-timeout=60
client-auth=false
enabled=true
ssl2=false
max-client-auth-data=1048576
tls-rollback-detection=true
ssl3=true

The output indicates that SSL is enabled and da-1 is the associated certificate nickname.

Deploy the modified configuration.

# ./wadm deploy-config --user=admin 
--password-file=/export/da80adm/admin.pwd 
--host=da-1.example.com port=8989
da-1.example.com

CLI201 Command 'deploy-config' ran successfully

Restart the Web Server instance.

# cd /opt/SUNWwbsvr/https-da-1.example.com/bin
# ./stopserv ; ./startserv

server has been shutdown

Sun Java System Web Server 7.0U2 B12/09/2007 09:02
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12]
from [Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://da-1.example.com:1080 ready to
accept requests
info: HTTP3072: http-listener-2: https://da-1.example.com:1443 ready to
accept requests
info: CORE3274: successful server startup

The output indicates that http-listener-2 is SSL is enabled and ready to accept requests.

Remove the temporary administration password file.
# cd /export/da80adm # rm admin.pwd

(Optional) Access https://da-1.example.com:1443 from a web browser to verify that the secure port can be invoked.

Tip –
A message may be displayed indicating that the browser doesn't recognize the certificate issuer. If this happens, install the CA root certificate in the browser so that the browser recognizes the certificate issuer. See your browser's online help system for information on installing a root CA certificate.

To Request and Install a Server Certificate and a Root Certificate for Web Server 2

The wadm command line interface, bundled with the Web Server, is used to import the root and server certificates into the Web Server certificate store.

Before You Begin

As a root user, log in to the da–2 host machine.

Start the Web Server Administration Server.

# su da80adm
# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

Create a temporary file that contains the administration password.

This file will be used for certificate request generation and certificate installation
# cd /export/da80adm # cat > admin.pwd wadm_password=web4dmin Hit Control D to terminate the command. ^D

Generate a certificate signing request.

# cd /opt/SUNWwbsvr/bin
# ./wadm create-cert-request --user=admin 
--password-file=/export/da80adm/admin.pwd --host=da-2.example.com 
--port=8989 --key-type=rsa --org="Sun Microsystems" 
--org-unit="Sun Distributed Authentication" 
--locality="Santa Clara" --state=California --country=US 
--config=da-2.example.com --token=internal
--server-name=da-2.example.com

Copy the output into a file named da-2.csr and send the request to the CA of your choice.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIB2DCCAUECAQAwgZcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRQwEgYDVQQHEwtTYW50YSBDbGFyYTEZMBcGA1UEChMQU3VuIE1pY3Jvc3lzdGVt
czEnMCUGA1UECxMeU3VuIERpc3RyaWJ1dGVkIEF1dGhlbnRpY2F0aW9uMRkwFwYD
VQQDExBkYS0xLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDGdeNgE00/6o3nrG38yatMhnrJeUVR86Pj5rBk282DQQfVenuWt0hL8Y6q9KvT
JQRoeclWMl94ZErdtNY0qKqXZBxhC0CCtiAvNHJAg8zErGTOADs6ptmXkzVRGBXE
b7zLOGlROnK9xAw0wms/aFsbA/Mb0zMI5PDztRAf5A8fIQIDAQABoAAwDQYJKoZI
hvcNAQEFBQADgYEAqap+9N/T+pzzAZL+EiG3rciKcG+Ij94Yk+3q0hMj3d3xer8Q
1shLAy4za9qHvOnT8M7hpKY6lpw4Y4N+w3eIgfDc3aCnz1Aot5Na4alWJZ81SUAZ
Fl6fD7CX7KMtF6Agfpi5OV+NdOiBL6tQ7F7G70c3pYV5MnQvYf5dnuiZEkQ=
-----END NEW CERTIFICATE REQUEST-----

The CA issues and returns a certified server certificate named da-2.cer.

Install da-2.cer, the server certificate.

# ./wadm install-cert --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-2.example.com --port=8989 
--token=internal --cert-type=server 
--nickname=da-2 da-2.cer

CLI201 Command 'install-cert' ran successfully

(Optional) Verify that the server certificate was properly installed.

# ./wadm list-certs --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-2.example.com --token=internal 
--cert-type=server

da-2

The output indicates that the server certificate was properly installed.

Install ca.cer, the root certificate.

# ./wadm install-cert --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-2.example.com --port=8989 
--token=internal --cert-type=ca 
--nickname=OpenSSLTestCA ca.cer

CLI201 Command 'install-cert' ran successfully

(Optional) Verify that the certificate was properly installed.

# ./wadm list-certs --user=admin 
--password-file=/export/da80adm/admin.pwd
 --token=internal --cert-type=ca 
--config=da-2.example.com | grep -i open

openSSLTestCA - sun

The output indicates that the root certificate was properly installed.

To Create an SSL Enabled HTTP Listener Port on Web Server 2

The wadm command line interface, bundled with the Web Server, is used in this procedure.

Before You Begin

This procedure assumes that you have just completed To Request and Install a Server Certificate and a Root Certificate for Web Server 2 and are still logged in as the non-root user.

Create an SSL enabled HTTP listener port on Web Server 2.

# ./wadm create-http-listener --user=admin 
--password-file=/export/da80adm/admin.pwd 
--host=da-2.example.com --port=8989 
--listener-port=1443 --config=da-2.example.com 
--server-name=da-2.example.com 
--default-virtual-server-name=da-2.example.com 
http-listener-2

CLI201 Command 'create-http-listener' ran successfully

(Optional) Verify that the listener was created.

# ./wadm get-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-2.example.com 
--http-listener=http-listener-2

tls=true
client-auth-timeout=60
client-auth=false
enabled=false
ssl2=false
max-client-auth-data=1048576
tls-rollback-detection=true
ssl3=true

The output indicates that the listener was properly created.

Enable SSL for the newly created HTTP listener port.

# ./wadm set-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-2.example.com 
--http-listener=http-listener-2
enabled=true

CLI201 Command 'set-ssl-prop' ran successfully

Associate the HTTP listener port with the nickname of the certificate.

# ./wadm set-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-2.example.com 
--http-listener=http-listener-2
server-cert-nickname=da-2

CLI201 Command 'set-ssl-prop' ran successfully

(Optional) Verify that SSL is enabled on the listener port and is associated with the server certificate.

# ./wadm get-ssl-prop --user=admin 
--password-file=/export/da80adm/admin.pwd 
--config=da-2.example.com 
--http-listener=http-listener-2

tls=true
server-cert-nickname=da-2
client-auth-timeout=60
client-auth=false
enabled=true
ssl2=false
max-client-auth-data=1048576
tls-rollback-detection=true
ssl3=true

The output indicates that SSL is enabled and da-2 is the associated certificate nickname.

Deploy the modified configuration.

# ./wadm deploy-config --user=admin 
--password-file=/export/da80adm/admin.pwd 
--host=da-2.example.com port=8989
da-2.example.com

CLI201 Command 'deploy-config' ran successfully

Restart the Web Server instance.

# cd /opt/SUNWwbsvr/https-da-2.example.com/bin
# ./stopserv ; ./startserv

server has been shutdown

Sun Java System Web Server 7.0U2 B12/09/2008 09:02
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12]
from [Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://da-2.example.com:1080 ready to
accept requests
info: HTTP3072: http-listener-2: https://da-2.example.com:1443 ready to
accept requests
info: CORE3274: successful server startup

The output indicates that http-listener-2 is SSL is enabled and ready to accept requests.

Remove the temporary administration password file.
# cd /export/da80adm # rm admin.pwd

(Optional) Access https://da-2.example.com:1443 from a web browser to verify that the secure port can be invoked.

Tip –
A message may be displayed indicating that the browser doesn't recognize the certificate issuer. If this happens, install the CA root certificate in the browser so that the browser recognizes the certificate issuer. See your browser's online help system for information on installing a root CA certificate.

To Import the Root Certificate to the Web Server 1 JDK Certificate Store

Before You Begin

Copy ca.cer, the same CA root certificate used in 4.3 Enabling Secure Communication for the Directory Server User Data Instances, to the JDK certificate store in the /export/WS7 directory on the da–1 host machine.

As a root user, log into the da–1 host machine.

Import ca.cer into cacerts, the certificate store.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import 
-trustcacerts -alias OpenSSLTestCA -file /export/WS7/ca.cer 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts 
-storepass changeit

Owner: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, 
OU=am, O=sun, L=santa clara, ST=california, C=us
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, 
OU=am, O=sun, L=santa clara, ST=california, C=us
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:41:51 PDT 2008 until: 
 Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
 MD5:  78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
 SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:
  A3:20:8C:BA

Trust this certificate? [no]: yes

Certificate was added to keystore

(Optional) Verify that the root certificate was successfully imported.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts 
-storepass changeit | grep -i open

openssltestca, Jul 1, 2008, trustedCertEntry

Restart the Web Server instance.

# su da80adm
# cd /opt/SUNWwbsvr/https-da-1.example.com/bin
# ./stopserv ; ./startserv

server has been shutdown

Sun Java System Web Server 7.0U2 B12/09/2008 09:02
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12]
from [Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://da-1.example.com:1080 ready to
accept requests
info: HTTP3072: http-listener-2: https://da-1.example.com:1443 ready to
accept requests
info: CORE3274: successful server startup

Log out of the da-1 host machine.

To Import the Root Certificate to the Web Server 2 JDK Certificate Store

Before You Begin

As a root user, log into the da–2 host machine.

Import ca.cer into cacerts, the certificate store.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import 
-trustcacerts -alias OpenSSLTestCA -file /export/WS7/ca.cer 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts 
-storepass changeit

Owner: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, 
OU=am, O=sun, L=santa clara, ST=california, C=us
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=openssltestca, 
OU=am, O=sun, L=santa clara, ST=california, C=us
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:41:51 PDT 2008 until: 
 Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
 MD5:  78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
 SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:
  A3:20:8C:BA

Trust this certificate? [no]: yes

Certificate was added to keystore

(Optional) Verify that the root certificate was successfully imported.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts 
-storepass changeit | grep -i open

openssltestca, Jul 1, 2008, trustedCertEntry

Restart the Web Server instance.

# su da80adm
# cd /opt/SUNWwbsvr/https-da-2.example.com/bin
# ./stopserv ; ./startserv

server has been shutdown

Sun Java System Web Server 7.0U2 B12/09/2008 09:02
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12]
from [Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://da-2.example.com:1080 ready to
accept requests
info: HTTP3072: http-listener-2: https://da-2.example.com:1443 ready to
accept requests
info: CORE3274: successful server startup

Log out of the da-2 host machine.

7.3 Configuring the Distributed Authentication User Interface Load Balancer

The Distributed Authentication User Interface Load Balancer 3 sends the user and agent requests to the OpenSSO Enterprise server where the session originated. Secure Sockets Layer (SSL) is terminated and regenerated before a request is forwarded to the Distributed Authentication User Interface servers to allow the load balancer to inspect the traffic for proper routing. Load Balancer 3 is capable of the following types of load balancing:

Cookie-based	The load balancer makes decisions based on client's cookies. The load balancer looks at the request and detects the presence of a cookie by a specific name. If the cookie is detected in the request, the load balancer routes the request to the specific server to which the cookie has been assigned. If the cookie is not detected in the request, the load balancer balances client requests among the available servers.
IP-based	This is similar to cookie-based load balancing, but the decision is based on the IP address of the client. The load balancer sends all requests from a specific IP address to the same server.
TCP	The load balancer mainstreams session affinity. This means that all requests related to a TCP session, are forwarded to the same server. In this deployment example, Load Balancer 3 forwards all requests from a single client to exactly the same server. When the session is started and maintained by one client, session affinity is guaranteed. This type of load-balancing is applicable to the TCP-based protocols.

Note –

This section assumes that you have already installed a load balancer. Before you begin, note the following:

The load balancer hardware and software used in the lab facility for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.
Contact your network administrator to obtain an available virtual IP address for the load balancer you want to configure.
Know the IP address of the load balancer hardware, the URL for the load balancer login page, and a username and password for logging in to the load balancer application.
Get the IP addresses for Distributed Authentication User Interface 1 and Distributed Authentication User Interface 2 by running the following command on each host machine:
# ifconfig -a

Use the following list of procedures as a checklist for completing the task.

To Request a Certificate for the Distributed Authentication User Interface Load Balancer

Generate a certificate signing request to send to a CA.

Access https://is-f5.example.com, the BIG-IP load balancer login page, from a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

In the left pane of the console, click Proxies.

Click the Cert-Admin tab.

On the SSL Certificate Administration page, click Generate New Key Pair/Certificate Request.

On the Create Certificate Request page, provide the following information:

Key Identifier:

lb-3.example.com

Organizational Unit Name:

Deployment

Domain Name:

lb-3.example.com

Challenge Password:

password

Retype Password:

password

Click Generate Key Pair/Certificate Request.

On the SSL Certificate Request page, the request is generated in the Certificate Request field.

Save the text contained in the Certificate Request field to a text file named lb-3.csr.

Log out of the console and close the browser.

Send lb-3.csr to the CA of your choice.

To Import a Root Certificate to the Distributed Authentication User Interface Load Balancer

The CA root certificate proves that the particular CA did, in fact, issue a particular certificate. For this purpose, import the root certificate of the CA that issued the Load Balancer 3 server certificate into the Load Balancer 3 certificate store.

Before You Begin

You should already have a root certificate from the CA of your choice. Send server certificate requests to the same CA. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.

Access https://is-f5.example.com, the Big IP load balancer login page, from a web browser.

In the left pane of the console, click Proxies.

Click the Cert-Admin tab.

Click Import.

In the Import Type field, choose Certificate, and click Continue.

Click Browse in the Certificate File field on the Install SSL Certificate page.

In the Choose File dialog, choose Browser.

Navigate to the file that contains the CA root certificate and click Open.

In the Certificate Identifier field, enter OpenSSL_CA_cert.

Click Install Certificate.

On the Certificate OpenSSL_CA_Cert page, click Return to Certificate Administration.

The root certificate OpenSSL_CA_Cert is now included in the Certificate ID list.

To Import a Certificate to the Distributed Authentication User Interface Load Balancer

Before You Begin

This procedure assumes you have received a certificate from a CA, just completed To Import a Root Certificate to the Distributed Authentication User Interface Load Balancer, and are still logged into the load balancer console.

In the BIG-IP load balancer console, click Proxies.

Click the Cert-Admin tab.

The key lb-3.example.com is in the Key List. This was generated in To Request a Certificate for the Distributed Authentication User Interface Load Balancer.

In the Certificate ID column, click the Install button for lb-3.example.com.

In the Certificate File field, click Browse.

In the Choose File dialog, navigate to the file that contains the certificate text sent to you by the CA and click Open.

Click Install Certificate.

On the Certificate lb-3.example.com page, click Return to Certificate Administration Information.

Verify that the Certificate ID indicates lb-3.example.com on the SSL Certificate Administration page.

Log out of the load balancer console.

To Configure the Distributed Authentication User Interface Load Balancer

Access https://is-f5.example.com, the Big IP load balancer login page, from a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

Create a Pool.

A pool contains all the backend server instances.
1. In the left pane, click Pools.
2. On the Pools tab, click Add.
3. In the Add Pool dialog, provide the following information:
  
  Pool Name
  
  AuthenticationUI-Pool
  
  Load Balancing Method
  
  Round Robin
  
  Resources
  
  Add the IP address and port number of both Distributed Authentication User Interface host machines: da-1:1443 and da-2:1443.
4. Click Done.

Add a Virtual Server.

The virtual server presents an address to the outside world and, when users attempt to connect, it would forward the connection to the most appropriate real server.

Tip –
If you encounter JavaScript^TM errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer.
1. In the left frame, Click Virtual Servers.
2. On the Virtual Servers tab, click Add.
3. In the Add Virtual Server wizard, enter the virtual server IP address and port number.
  
  Address
  
  Enter the IP address for lb-3.example.com
  
  Service
  
  9443
4. Continue to click Next until you reach the Pool Selection dialog box.
5. In the Pool Selection dialog box, assign the AuthenticationUI-Pool Pool.
6. Click Done.

Add Monitors.

Monitors are required for the load balancer to detect backend server failures.
1. In the left frame, click Monitors.
2. Click the Basic Associations tab.
3. Add a TCP monitor to each Web Server node.
  
  In the Node list, locate the IP address and port number for da-1:1443 and da-2:1443, and select the Add checkbox.
4. Click Apply.

Configure the load balancer for persistence.
1. In the left frame, click Pools.
2. Click the AuthenticationUI-Pool link.
3. Click the Persistence tab.
4. Under Persistence Type, select Passive HTTP Cookie.
5. Under Cookie Name, enter DistAuthLBCookie.
6. Click Apply.

In the left frame, click BIGpipe.

In the BIGpipe command window, type makecookie IP-address:port.

IP-address is the IP address of the da-1 host machine and port is the same machine's port number; in this case, 1443.

Press Enter to execute the command.

Something similar to Set-Cookie: BIGipServer[poolname]=4131721920.41733.0000; path=/ is displayed. Save the numbered value (in this case, 4131721920.41733.0000) for use in To Configure Load Balancer Cookies for the Distributed Authentication User Interface.

In the left frame, click BIGpipe again.

In the BIGpipe command window, type makecookie IP-address:port.

IP-address is the IP address of the da-2 host machine and port is the same machine's port number; in this case, 1443.

Press Enter to execute the command.

Something similar to Set-Cookie: BIGipServer[poolname]=4148499136.41733.0000; path=/ is displayed. Save the numbered value (in this case, 4148499136.41733.0000) for use in To Configure Load Balancer Cookies for the Distributed Authentication User Interface.

Log out of the load balancer console.

To Configure a Proxy for SSL Termination at the Distributed Authentication User Interface Load Balancer

Secure communication is terminated and regenerated at the load balancer before forwarding a request to the Distributed Authentication User Interface.

Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.

Click Configure your BIG-IP using the Configuration Utility.

In the left pane, click Proxies.

Under the Proxies tab, click Add.

In the Add Proxy dialog, provide the following information:

Proxy Type:

Check SSL and ServerSSL.

Proxy Address:

The IP address of Load Balancer 3.

Proxy Service:

1443

The secure port number

Destination Address:

The IP address of Load Balancer 3.

Destination Service:

9443

The secure port number

Destination Target:

Choose Local Virtual Server.

SSL Certificate:

Choose lb-3.example.com.

SSL Key:

Choose lb-3.example.com.

Enable ARP:

Check this box.

Click Next.

The Insert HTTP Header String page is displayed.

Choose Matching for Rewrite Redirects.

Click Next.

The Client Cipher List String page is displayed.

Accept the defaults and click Next.

The Server Chain File page is displayed.

Select OpenSSL_CA_Cert.crt from the drop-down list.

Click Done.

The new proxy server is now added to the Proxy Server list.

Log out of the load balancer console.

Access https://lb-3.example.com:1443/index.html from a web browser to verify the configuration.

Tip –
A message may be displayed indicating that the browser doesn't recognize the certificate issuer. If this happens, install the CA root certificate in the browser so that the browser recognizes the certificate issuer. See your browser's online help system for information on installing a root CA certificate.

Close the browser.

7.4 Creating an Agent Profile with Custom User for the Distributed Authentication User Interface

Before installing and configuring the Distributed Authentication User Interface, create an agent profile with the OpenSSO Enterprise console. This agent profile allows OpenSSO Enterprise to store authentication and configuration information regarding the Distributed Authentication User Interface. The agent profile will be stored in the configuration data store.

Note –

Although the Distributed Authentication User Interface is not an agent, it acts on behalf of OpenSSO Enterprise and therefore must have its own agent profile. This agent profile will be used by the Distributed Authentication User Interface to authenticate itself to OpenSSO Enterprise.

Use the following list of procedures as a checklist for completing this task.

To Create an Agent Profile with Custom User for the Distributed Authentication User Interface

The creation of the agent profile also creates a custom user that allows the Distributed Authentication User Interface to log into the OpenSSO Enterprise server. authuiadmin is the custom user created.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the 2.2 Agent tab.

Click New to create a new agent profile.

The New Agent properties page is displayed.

Type the following values and click Create.

Name

authuiadmin

Password

authuiadmin

Password (confirm)

authuiadmin

authuiadmin is displayed in the list of Agent names.

Log out of the console.

To Verify that `authuiadmin` Was Created in Directory Server

This is an optional, verification step.

Run ldapsearch to verify that the authuiadmin entry was successfully created.

# cd /var/opt/mps/serverroot/dsrk6/bin
# ./ldapsearch -b "dc=opensso,dc=java,dc=net" -h osso-1.example.com 
-p 50389 -D "cn=Directory Manager" -w dsmanager "ou=authuiadmin"

version: 1
dn: ou=authuiadmin,ou=default,ou=OrganizationConfig,
ou=1.0,ou=AgentService,ou=services,dc=opensso,dc=java,dc=net
objectClass: top
objectClass: sunServiceComponent
sunserviceID: 2.2_Agent
ou: authuiadmin
sunKeyValue: userpassword=AQICrLO+CuXkZFllnTO/ISfA5UjKea1
 yVhgLpDj5QtqeiR/gWRF6w45Blh+hBjQfly7u
sunKeyValue: sunIdentityServerDeviceStatus=Active
sunKeyValue: sunIdentityServerDeviceKeyValue=
sunKeyValue: description=
sunsmspriority: 0

Log out of the OpenSSO Enterprise host machine.

Access https://osso-1.example.com:1081/opensso/UI/Login from a web browser.

Log in to the OpenSSO Enterprise console as the agent user.

User Name:

authuiadmin

Password:

authuiadmin

A successful login indicates that the Distributed Authentication User Interface will be successful in authentication during the configuration process.

Log out of the OpenSSO Enterprise console.

7.5 Generating and Deploying the Distributed Authentication User Interface WAR

Use the following list of procedures as a checklist to create and deploy the Distributed Authentication User Interface WAR on both host machines.

To Generate the Distributed Authentication User Interface WAR

Create a WAR named ossodistauth.war that will be used to deploy the Distributed Authentication User Interface.

As a root user, log in to the osso–1 host machine.

Create a directory to serve as the staging area for the WAR.

# cd /export/OSSO_BITS/opensso
# mkdir war-staging
# cd war-staging

Extract the contents of opensso.war into the war-staging directory.

# jar xvf /export/OSSO_BITS/opensso/deployable-war/opensso.war

Generate the WAR using the Distributed Authentication User Interface file list.

osso-distauth.list is included with the OpenSSO Enterprise download.
# jar cvf /export/OSSO_BITS/opensso/deployable-war/ossodistauth.war @/export/OSSO_BITS/opensso/deployable-war/osso-distauth.list

Update the generated WAR with additional files in the /opensso/deployable-war/distauth directory of the unzipped download.

See the README for more information.
# cd /export/OSSO_BITS/opensso/deployable-war/distauth # jar uvf /export/OSSO_BITS/opensso/deployable-war/ossodistauth.war
The WAR is updated and ready to be used to deploy the Distributed Authentication User Interface.

Log out of the osso–1 host machine.

To Deploy the Generated WAR as Distributed Authentication User Interface 1

Before You Begin

This procedure assumes you have completed To Generate the Distributed Authentication User Interface WAR.

As a root user, log in to the da–1 host machine.

Switch to the non-root user.
# su da80adm

Change to the directory into which ossodistauth.war will be copied.
# cd /export/da80adm

Copy ossodistauth.war from the osso–1 host machine.

# ftp osso-1.example.com

Connected to osso-1.example.com
220 osso-1.example.com FTP server ready.

Name (osso-1.example.com:username):username

Password: password
     ...
Using binary mode to transfer files

ftp> cd /export/OSSO_BITS/opensso/deployable-war

CWD command successful

ftp> mget ossodistauth.war

mget ossodistauth.war? y

200 PORT command successful

ftp> bye

Verify that ossodistauth.war was successfully copied and is owned by the non-root user.

# ls -al

total 17630
drwxr-xr-x   3 da80adm  staff        512 Jun 30 15:20 .
drwxr-xr-x   6 root     sys          512 May 13 11:22 ..
-rw-r--r--   1 da80adm  staff        144 May 13 11:22 .profile
drwx------   3 da80adm  staff        512 May 13 14:55 .sunw
-rw-r--r--   1 da80adm  staff   10017728 Jun 30 15:20 ossodistauth.war
-rw-r--r--   1 da80adm  staff        136 May 13 11:22 local.cshrc
-rw-r--r--   1 da80adm  staff        157 May 13 11:22 local.login
-rw-r--r--   1 da80adm  staff        174 May 13 11:22 local.profile

Start the Web Server Administration Server.

# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

Add the Distributed Authentication User Interface WAR using the wadm command line interface.

# cd /opt/SUNWwbsvr/bin
# ./wadm add-webapp --user=admin 
--host=da-1.example.com --port=8989
--config=da-1.example.com --vs=da-1.example.com
--uri=/distAuth
/export/da80adm/ossodistauth.war

Please enter admin-user-password: web4dmin

Do you trust the above certificate? [y|n] y

CLI201 Command 'add-webapp' ran successfully

Deploy the Distributed Authentication User Interface WAR using the wadm command line interface.

# ./wadm deploy-config --user=admin 
--host=da-1.example.com --port=8989
da-1.example.com

Please enter admin-user-password: web4dmin

CLI201 Command 'deploy-config' ran successfully

Verify that the distAuth web application has been deployed.

# cd /opt/SUNWwbsvr/https-da-1.example.com/web-app/da-1.example.com
# ls -al

total 6
drwxr-xr-x   4 da80adm  staff        512 Jun 30 15:40 .
drwxr-xr-x   3 da80adm  staff        512 Jun 30 15:40 ..
drwxr-xr-x   6 da80adm  staff        512 Jun 30 15:40 distAuth

Restart the Web Server instance.

# cd /opt/SUNWwbsvr/https-da-1.example.com/bin
# ./stopserv; ./startserv

server has been shutdown
Sun Java System Web Server 7.0U2 B12/09/2008 09:02
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12]
from [Sun Microsystems Inc.]
info: WEB0100: Loading web module in virtual server [da-1.example.com]
at [/distAuth]
info: HTTP3072: http-listener-1: http://da-1.example.com:1080 ready to
accept requests
info: HTTP3072: http-listener-2: https://da-1.example.com:1443 ready to
accept requests
info: CORE3274: successful server startup

The output indicates that the distAuth web application has been successfully loaded.

To Configure Distributed Authentication User Interface 1

Access http://da-1.example.com:1080/distAuth from a web browser.

The Configurator page is displayed the first time the Distributed Authentication User Interface is accessed.

Provide the following configuration information and click Configure.

Server Protocol	`https`
Server Host	`lb-2.example.com`
Server Port	`1081`
Server Deployment URI	`opensso`
`distAuth` Server Protocol	`http`
`distAuth` Server Host	`da-1.example.com`
`distAuth` Server Port	`1080`
`distAuth` Server Deployment URI	`/distAuth`
`distAuth` Server Cookie Name	`AMDistAuthCookie`
Debug Directory	`/export/da80adm/Debug`
Debug level	`error`
Encryption Key	Accept the default value.
Application User Name	`authuiadmin`
Application User Password	`authuiadmin`
Confirm Application User Password	`authuiadmin`

These values will configure the Distributed Authentication User Interface web application to communicate with OpenSSO Enterprise through Load Balancer 2. You see the following message after a successful configuration.

DistAuth application is successfully configured.
AMDistAuthConfig.properties created at /export/da80adm/AMDistAuthConfig.properties

Click here to go to login page.

Access http://da-1.example.com:1080/distAuth/UI/Login?goto=http://da-1.example.com:1080 from a web browser.

Log in to the Distributed Authentication User Interface as testuser1.

Username

testuser1

Password

password

After successful authentication, you should be redirected to the index page for the Web Server instance in which the Distributed Authentication User Interface is deployed. This confirms that the Distributed Authentication User Interface has authenticated to OpenSSO Enterprise using the load balancer's secure channel.

Caution –
You may click the login link after configuration of the Distributed Authentication User Interface. If you do and provide valid administrator credentials you will get an error page indicating that the requested object does not exist on this server. This is because the success login URL configured on OpenSSO Enterprise is a relative URL.

To Deploy the Generated WAR as Distributed Authentication User Interface 2

Before You Begin

This procedure assumes you have completed To Generate the Distributed Authentication User Interface WAR.

As a root user, log in to the da–2 host machine.

Switch to the non-root user.
# su da80adm

Change to the directory into which ossodistauth.war will be copied.
# cd /export/da80adm

Copy ossodistauth.war from the osso–1 host machine.

# ftp osso-1.example.com

Connected to osso-1.example.com
220 osso-1.example.com FTP server ready.

Name (osso-1.example.com:username):username

Password: password
     ...
Using binary mode to transfer files

ftp> cd /export/OSSO_BITS/opensso/deployable-war

CWD command successful

ftp> mget ossodistauth.war

mget ossodistauth.war? y

200 PORT command successful

ftp> bye

Verify that ossodistauth.war was successfully copied and is owned by the non-root user.

# ls -al

total 17630
drwxr-xr-x   3 da80adm  staff        512 Jun 30 15:20 .
drwxr-xr-x   6 root     sys          512 May 13 11:22 ..
-rw-r--r--   1 da80adm  staff        144 May 13 11:22 .profile
drwx------   3 da80adm  staff        512 May 13 14:55 .sunw
-rw-r--r--   1 da80adm  staff   10017728 Jun 30 15:20 ossodistauth.war
-rw-r--r--   1 da80adm  staff        136 May 13 11:22 local.cshrc
-rw-r--r--   1 da80adm  staff        157 May 13 11:22 local.login
-rw-r--r--   1 da80adm  staff        174 May 13 11:22 local.profile

Start the Web Server Administration Server.

# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

Add the Distributed Authentication User Interface WAR using the wadm command line interface.

# cd /opt/SUNWwbsvr/bin
# ./wadm add-webapp --user=admin 
--host=da-2.example.com --port=8989
--config=da-2.example.com --vs=da-2.example.com
--uri=/distAuth
/export/da80adm/ossodistauth.war

Please enter admin-user-password: web4dmin

Do you trust the above certificate? [y|n] y

CLI201 Command 'add-webapp' ran successfully

Deploy the Distributed Authentication User Interface WAR using the wadm command line interface.

# ./wadm deploy-config --user=admin 
--host=da-2.example.com --port=8989
da-2.example.com

Please enter admin-user-password: web4dmin

CLI201 Command 'deploy-config' ran successfully

Verify that the distAuth web application has been deployed.

# cd /opt/SUNWwbsvr/https-da-2.example.com/web-app/da-2.example.com
# ls -al

total 6
drwxr-xr-x   4 da80adm  staff        512 Jun 30 15:40 .
drwxr-xr-x   3 da80adm  staff        512 Jun 30 15:40 ..
drwxr-xr-x   6 da80adm  staff        512 Jun 30 15:40 distAuth

Restart the Web Server instance.

# cd /opt/SUNWwbsvr/https-da-2.example.com/bin
# ./stopserv; ./startserv

server has been shutdown
Sun Java System Web Server 7.0U2 B12/09/2008 09:02
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12]
from [Sun Microsystems Inc.]
info: WEB0100: Loading web module in virtual server [da-2.example.com]
at [/distAuth]
info: HTTP3072: http-listener-1: http://da-2.example.com:1080 ready to
accept requests
info: HTTP3072: http-listener-2: https://da-2.example.com:1443 ready to
accept requests
info: CORE3274: successful server startup

The output indicates that the distAuth web application has been successfully loaded.

To Configure Distributed Authentication User Interface 2

Access http://da-2.example.com:1080/distAuth from a web browser.

The Configurator page is displayed the first time the Distributed Authentication User Interface is accessed.

Provide the following configuration information and click Configure.

Server Protocol	`https`
Server Host	`lb-2.example.com`
Server Port	`1081`
Server Deployment URI	`opensso`
`distAuth` Server Protocol	`http`
`distAuth` Server Host	`da-2.example.com`
`distAuth` Server Port	`1080`
`distAuth` Server Deployment URI	`/distAuth`
`distAuth` Server Cookie Name	`AMDistAuthCookie`
Debug Directory	`/export/da80adm/Debug`
Debug level	`error`
Encryption Key	Accept the default value.
Application User Name	`authuiadmin`
Application User Password	`authuiadmin`
Confirm Application User Password	`authuiadmin`

DistAuth application is successfully configured.
AMDistAuthConfig.properties created at /export/da80adm/AMDistAuthConfig.properties

Click here to go to login page.

Access http://da-2.example.com:1080/distAuth/UI/Login?goto=http://da-2.example.com:1080 from a web browser.

Log in to the Distributed Authentication User Interface as testuser1.

Username

testuser1

Password

password

After successful authentication, you should be redirected to the index page for the Web Server instance in which the Distributed Authentication User Interface is deployed. This confirms that the Distributed Authentication User Interface has authenticated to OpenSSO Enterprise using the load balancer's secure channel.

Caution –
You may click the login link after configuration of the Distributed Authentication User Interface. If you do and provide valid administrator credentials you will get an error page indicating that the requested object does not exist on this server. This is because the success login URL configured on OpenSSO Enterprise is a relative URL.

To Configure Load Balancer Cookies for the Distributed Authentication User Interface

Access to the Distributed Authentication User Interface is through Load Balancer 3. In order to maintain server affinity, the Distributed Authentication User Interface needs to specify sticky cookies. Towards this end, AMDistAuthConfig.properties is modified on both Distributed Authentication User Interface host machines.

As a root user, log in to the da–1 host machine.

Switch to the non-root user.
# su da80adm

Change to the non-root user directory.
# cd /export/da80adm

Modify AMDistAuthConfig.properties as follows.
- Uncomment the last two lines at the end of the file.
- Set the following property values:
  - com.iplanet.am.lbcookie.name=DistAuthLBCookie
  - com.iplanet.am.lbcookie.value=4131721920.41733.0000
Note –
Use the same cookie name for the value of the com.iplanet.am.lbcookie.name property that was specified for load balancer persistence in To Configure the Distributed Authentication User Interface Load Balancer. Failure to do so might cause the OpenSSO Enterprise login page to go into a loop since stickiness could not be maintained based on the cookie name.

Save the file and close it.

Restart the Web Server instance.

# cd /opt/SUNWwbsvr/https-da-1.example.com/bin
# ./stopserv; ./startserv

Log out of the da–1 host machine.

As a root user, log in to the da–2 host machine.

Switch to the non-root user.
# su da80adm

Change to the non-root user directory.
# cd /export/da80adm

Modify AMDistAuthConfig.properties as follows.
- Uncomment the last two lines at the end of the file.
- Set the following property values:
  - com.iplanet.am.lbcookie.name=DistAuthLBCookie
  - com.iplanet.am.lbcookie.value=4148499136.41733.0000
Note –
Use the same cookie name for the value of the com.iplanet.am.lbcookie.name property that was specified for load balancer persistence in To Configure the Distributed Authentication User Interface Load Balancer. Failure to do so might cause the OpenSSO Enterprise login page to go into a loop since stickiness could not be maintained based on the cookie name.

Save the file and close it.

Restart the Web Server instance.

# cd /opt/SUNWwbsvr/https-da-2.example.com/bin
# ./stopserv; ./startserv

Log out of the da–2 host machine.

To Verify That Authentication Using the Distributed Authentication User Interface Load Balancer is Successful

Access the load balancer's secure port at https://lb-3.example.com:1443/distAuth/UI/Login?goto=https://lb-3.example.com:1443 from a web browser.

Log in to the OpenSSO Enterprise console as testuser1.

Username

testuser1

Password

password

After successful login, you should be redirected to the index page for one of the Web Server instances in which the Distributed Authentication User Interface is deployed. If the load balancer configuration is incorrect, the OpenSSO Enterprise login page would not have been displayed in the previous step.

Chapter 8 Configuring the Protected Resource Host Machines

Each machine on which the protected resources will be hosted contain two installed web containers (one Sun Java™ System Web Server and one BEA WebLogic Server application server) and the appropriate policy agent for each (a web policy agent and a J2EE policy agent, respectively). The policy agents are configured to access Load Balancer 2. This chapter contains the following sections:

8.1 Configuring the Protected Resource Host Machines with a J2EE Policy Agent

We will install BEA WebLogic Server and a J2EE policy agent on the Protected Resource 1 host machine (pr-1) and on the Protected Resource 2 host machine (pr-2). The policy agents are then configured to access Load Balancer 2. Use the following list of procedures as a checklist for completing the task.

8.1.1 Installing and Configuring the J2EE Container and J2EE Policy Agent on Protected Resource 1

Download the BEA WebLogic Server bits to the pr-1 host machine and install the application server. Additionally, download, install and configure the appropriate J2EE policy agent. Use the following list of procedures as a checklist for completing this task.

To Install BEA WebLogic Server as J2EE Container 1 on Protected Resource 1

BEA WebLogic Server is the application server used as the J2EE container on Protected Resource 1.

As a root user, log into the pr-1 host machine.

Ensure that your system is properly patched.

Refer to the BEA web site to make sure that your system has the recommended patches.

Create a directory into which you can download the WebLogic Server bits and change into it.
# mkdir /export/BEAWL10 # cd /export/BEAWL10

Download the WebLogic Server bits from http://commerce.bea.com/.

For this deployment, we download the Solaris version.

# ls -al

total 294548
drwxr-xr-x   2 root     root         512 Aug  7 13:23 .
drwxr-xr-x   3 root     sys          512 Aug  7 13:16 ..
-rw-r--r--   1 root     root     656834948 Aug  7 13:24 server100_solaris32.bin

Run the installer.
# ./server100_solaris32.bin

When prompted, do the following:

The Welcome screen is displayed.

Click Next.

Accept the License agreement

Select Yes and click Next.

Create a new BEA Home

Type /usr/local/bea and click Next.

Select "Custom"

Click Next.

Deselect the following:
- Workshop for WebLogic Platform

Click Next.

Choose Product Installation Directories

Type /usr/local/bea/weblogic10 and click Next.

Installation Complete

Deselect Run Quickstart and click Done.

Verify that the application was correctly installed.

# cd /usr/local/bea
# ls -al

total 90
drwxr-xr-x   7 root     root         512 Jul 15 11:59 .
drwxr-xr-x   4 root     root         512 Jul 15 11:58 ..
-rwxr-xr-x   1 root     root         826 Jul 15 11:59 UpdateLicense.sh
-rw-r--r--   1 root     root          14 Jul 15 11:59 beahomelist
drwxr-xr-x   6 root     root         512 Jul 15 11:59 jdk150_06
-rw-r--r--   1 root     root       12447 Jul 15 11:59 license.bea
drwxr-xr-x   2 root     root         512 Jul 15 11:59 logs
drwxr-xr-x   6 root     root        6656 Jul 15 11:58 modules
-rw-r--r--   1 root     root       15194 Jul 15 11:59 registry.dat
-rw-r--r--   1 root     root        1077 Jul 15 11:59 registry.xml
drwxr-xr-x   4 root     root         512 Jul 15 12:01 utils
drwxr-xr-x  10 root     root         512 Jul 15 11:59 weblogic10

To Configure BEA WebLogic Server as J2EE Container 1 on Protected Resource 1

After installing the bits, WebLogic Server must be configured.

Before You Begin

This procedure assumes you have just completed To Install BEA WebLogic Server as J2EE Container 1 on Protected Resource 1 and are still logged into the host machine as the root user.

Run the WebLogic Server configuration script.

# cd /usr/local/bea/weblogic10/common/bin
# ./config.sh

When prompted, do the following:

Select "Create a new Weblogic domain"

Click Next.

Select "Generate a domain configured automatically 
to support the following BEA products:"

Click Next.

Configure Administrator Username and Password

Enter the following and click Next.

Username: weblogic
Password: bea10admin
Confirm Password: bea10admin

Select "Prduction Mode" and "BEA Supplied JDK's" 
(Sun SDK 1.5.0_06@/usr/local/bea/jdk150_06)

Click Next.

Customize Environment and Services Settings

Select yes and click Next.

Configure the Administration Server

Accept the default values and click Next.

Configure Managed Servers

Select Add, enter the following values, and click Next.

Name: ApplicationServer-1
Listen Port: 1081

Configure Clusters

Accept the default values and click Next.

Configure Machines

Select the Unix Machine tab, then select Add, type pr-1 and click Next.

Assign Servers to Machines

From the left panel select AdminServer and ApplicationServer-1. From the right panel select pr-1. Click --> and then click Next.

Review WebLogic Domain

Click Next.

Create WebLogic Domain

Add the following and click Create.

Domain name: pr-1
Domain Location: /usr/local/bea/user_projects/domains (default)

Creating Domain

Click Done.

Start the WebLogic administration server.
# cd /usr/local/bea/user_projects/domains/pr-1 # ./startWebLogic.sh
When prompted, type the following credentials.

Username

weblogic

Password

bea10admin

Run the netstat command to verify that the port is open and listening.
# netstat -an | grep 7001 XXX.XX.XX.101.7001 *.* 0 0 49152 0 LISTEN XXX.X.X.1.7001 *.* 0 0 49152 0 LISTEN
Note –
You can also access the administration console by pointing a web browser to http://pr-1.example.com:7001/console.

Change to the AdminServer directory.

# cd /usr/local/bea/user_projects/domains/pr-1/servers/AdminServer

Create a security directory and change into it.
# mkdir security # cd security

Create a boot.properties file for the WebLogic Server administration server administrator credentials.

The administration server administrative user and password are stored in boot.properties. Application Server 1 uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=bea10admin Hit Control D to terminate the command ^D

Restart WebLogic to encrypt the username and password in boot.properties.

# cd /usr/local/bea/user_projects/domains/pr-1/bin
# ./stopWebLogic.sh
# ./startWebLogic.sh

Start the managed servers.

# cd /usr/local/bea/user_projects/domains/pr-1/bin
# ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001

You will be prompted for the administrative user credentials.

Username: weblogic
Password: bea10admin

Change to the ApplicationServer-1 directory.

# cd /usr/local/bea/user_projects/domains/pr-1/
  servers/ApplicationServer-1

Create a security directory and change into it.
# mkdir security # cd security

Create a boot.properties file for the WebLogic Server managed server administrator credentials.

The managed server administrative user and password are stored in boot.properties. The Application Server 1 managed server uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=bea10admin Hit Control D to terminate the command ^D

Restart the managed server.

# cd /usr/local/bea/user_projects/domains/ 
  pr-1/bin
# ./stopManagedWebLogic.sh ApplicationServer-1 
   t3://localhost:7001
# ./startManagedWebLogic.sh ApplicationServer-1 
   t3://localhost:7001

Run the netstat command to verify that the port is open and listening.

# netstat -an | grep 1081

XXX.XX.XX.101.1081     *.*                0      0 49152      0 LISTEN
XXX.X.X.1.1081         *.*                0      0 49152      0 LISTEN

Access http://pr-1.example.com:7001/console from a web browser.

Click servers under Domain Structure —>Environment.

On the Summary of Servers page, verify that both AdminServer (admin) and ApplicationServer-1 are running and OK.

Log out of the console.

Log out of the pr–1 host machine.

To Import the Certificate Authority Root Certificate into Application Server 1

The Certificate Authority (CA) root certificate enables the J2EE policy agent to trust the certificate from the OpenSSO Enterprise Load Balancer 2, and to establish trust with the certificate chain that is formed from the CA to the certificate.

Before You Begin

Copy the same CA root certificate used in To Install a CA Root Certificate to the OpenSSO Enterprise Load Balancer to the /export/software directory on the pr-1 host machine.

As a root user, log into the pr–1 host machine.

Change to the directory where cacerts, the certificate store is located.
# cd /usr/local/bea/jdk150_06/jre/lib/security.
Tip –
Backup cacerts before modifying it.

Import ca.cer, the CA root certificate.

# /usr/local/bea/jdk150_06/bin/keytool -import -trustcacerts 
  -alias OpenSSLTestCA -file /export/software/ca.cer 
  -keystore /usr/local/bea/jdk150_06/jre/lib/security/cacerts -storepass changeit

Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Serial number: 97dba0aa26db6386
Valid from: Tue Apr 18 07:66:19 PDT 2006 until: Tue Jan 13 06:55:19
PST 2009
Certificate fingerprints:
MD5: 9f:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06
SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:26:64:36:80:E4:70
Trust this certificate: [no] yes

Certificate was added to keystore.

Verify that ca.cer was successfully imported.

# /usr/local/bea/jdk150_06/bin/keytool -list 
  -keystore /usr/local/bea/jdk150_06/jre/lib/security/cacerts 
  -storepass changeit | grep -i openssl

OpenSSLTestCA, Sep 15, 2008, trustedCertEntry,

Log out of the pr–1 host machine.

To Install the J2EE Policy Agent 1 on Application Server 1

Before You Begin

Set JAVA_HOME to /usr/local/bea/jdk150_06.

As a root user, log into the pr-1 host machine.

Stop the WebLogic Server 1 administration server and the WebLogic Server 1 managed instance.

# cd /usr/local/bea/user_projects/domains/pr-1/bin
# ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001
# ./stopWebLogic.sh

Create a directory into which you will download the J2EE Policy Agent bits and change into it.
# mkdir /export/J2EEPA1 # cd /export/J2EEPA1

Create a text file that contains a password for the Agent Profile created during installation.

The J2EE Policy Agent installer requires this.
# cat > agent.pwd j2eeagent1 Hit Control D to terminate the command ^D

Create a text file that contains the Agent Administrator password.

This text file should contain the password of the OpenSSO Enterprise administrator (by default, amadmin).
# cat > agentadm.pwd ossoadmin Hit Control D to terminate the command ^D

Download the J2EE policy agent bits for WebLogic Server from http://www.sun.com/download/index.jsp.

# ls -al

total 18824
drwxr-xr-x   2 root     root         512 Jul 17 16:02 .
drwxr-xr-x   8 root     root         512 Jul 17 15:58 ..
-rw-r--r--   1 root     root          11 Jul 17 15:59 agent.pwd
-rw-r--r--   1 root     root           9 Jul 17 16:01 agentadm.pwd
-rw-r--r--   1 root     root     9623704 Jul 17 16:02 weblogic_v10_agent_3.zip

Unpack the J2EE policy agent bits.
# unzip weblogic_v10_agent_3.zip

Run the J2EE policy agent installer.

# cd /export/J2EEPA1/j2ee_agents/weblogic_v10_agent/bin
# chmod 755 agentadmin
# ./agentadmin --custom-install

When prompted, provide the following information.

The following information is to configure the J2EE Policy Agent against the OpenSSO Enterprise secure port.

Please read the following License Agreement carefully:

Press Enter to continue. Continue to press Enter until you reach the end of the License Agreement and the installer's Welcome page is displayed.

Enter startup script location.

Enter /usr/local/bea/user_projects/domains/pr-1/bin/startwebLogic.sh

Enter the WebLogic Server instance 
name: [AdminServer]

Enter the name of the WebLogic Server instance secured by the agent ApplicationServer-1

Enter the WebLogic home directory: 
[/usr/local/bea/wlserver_10.0]

Enter /usr/local/bea/weblogic10.

OpenSSO Enterprise 
URL

Enter the URL where OpenSSO Enterprise is running (including the URI): https://lb-2.example.com:1081/opensso

Is the agent being deployed on a Portal domain [false]

Accept the default value.

Agent URL:

Enter the URL where the policy agent is running (including the URI): http://pr-1.example.com:1081/agentapp

Enter the Encryption Key 
[+Yr3K4K1/lWFe4H17SBHMNIUzLNRut7H]:

Accept the default value.

Enter the Agent Profile Name:

j2eeagent-1

Enter the path to the password file:

Enter the path to a file that contains the password to be used for identifying the policy agent: /export/J2EEPA1/agent.pwd.

Note –

A warning message is displayed regarding the existence of the agent profile.

This Agent Profile does not exist in 
OpenSSO Enterprise. 
Will it be created by the installer? (Agent 
Administrator name and password are required) 
[true]:

Accept the default value to create the Agent Profile during installation.

Enter the Agent Administrator's name:

Enter amadmin

Enter the path to the password file 
that contains the password of Agent Administrator:

Enter /export/J2EEPA1/agentadm.pwd

-----------------------------------------------
SUMMARY OF YOUR RESPONSES
-----------------------------------------------
Startup script location :
  /usr/local/bea/user_projects/domains/
  pr-1/bin/startWebLogic.sh
WebLogic Server instance name : 
  ApplicationServer-1
WebLogic home directory : 
  /usr/local/bea/weblogic10
OpenSSO Server URL : 
  https://lb-2.example.com:1081/opensso
Agent Installed on Portal domain : false
Agent URL : 
  http://pr-1.example.com:1081/agentapp
Encryption Key : 
  +Yr3K4K1/lWFe4H17SBHMNIUzLNRut7H
Agent Profile name : j2eeagent-1
Agent Profile Password file name : 
  /export/J2EEPA1/agent.pwd
Agent Profile will be created right now 
  by agent installer : true
Agent Administrator : amadmin
Agent Administrator's password file 
  name : /export/J2EEPA1/agentadm.pwd

Verify your settings and decide from 
the choices below:
1. Continue with Installation
2. Back to the last interaction
3. Start Over
4. Exit
Please make your selection [1]:

Accept the default value.

---------------------------------------------
SUMMARY OF AGENT INSTALLATION
-----------------------------
Agent instance name: Agent_001
Agent Bootstrap file location:
/export/J2EEPA1/j2ee_agents/
  weblogic_v10_agent/Agent_001/
  config/FAMAgentBootstrap.properties
Agent Configuration file location
/export/J2EEPA1/j2ee_agents/
  weblogic_v10_agent/Agent_001/
  config/FAMAgentConfiguration.properties
Agent Audit directory location:
/export/J2EEPA1/j2ee_agents/
  weblogic_v10_agent/Agent_001/logs/audit
Agent Debug directory location:
/export/J2EEPA1/j2ee_agents/
  weblogic_v10_agent/Agent_001/logs/debug

Install log file location:
/export/J2EEPA1/j2ee_agents/
  weblogic_v10_agent/installer-logs
  /audit/custom.log

Accept the default value.

When the installer is finished, a new file is in the bin directory called setAgentEnv_ApplicationServer-1.sh.

Modify the startup script setDomainEnv.sh to reference setAgentEnv_ApplicationServer-1.sh with the following sub procedure.

Tip –
Backup setDomainEnv.sh before you modify it.
1. Change to the bin directory.
  # cd /usr/local/bea/user_projects/domains/pr-1/bin
2. Insert the following line at the end of setDomainEnv.sh.
  . /usr/local/bea/user_projects/domains/pr-1/ bin/setAgentEnv_ApplicationServer-1.sh
3. Save setDomainEnv.sh and close the file.

Change permissions for setAgentEnv_ApplicationServer-1.sh.
# chmod 755 setAgentEnv_ApplicationServer-1.sh

Start the WebLogic Server administration server and managed instance.

# ./startWebLogic.sh &
# ./startManagedWebLogic.sh ApplicationSever-1 t3://localhost:7001

Watch for startup errors.

Verify that the J2EE Policy Agent 1 was successfully created on the server using the following sub procedure.
1. Access https://osso-1.example.com:1081/opensso/console from a web browser.
2. Log in to the OpenSSO Enterprise console as the administrator.
  
  User Name:
  
  amadmin
  
  Password:
  
  ossoadmin
3. Under the Access Control tab, click / (Top Level Realm).
4. Click the Agents tab.
5. Click the J2EE tab.
  
  j2eeagent-1 is displayed under the Agent table.
6. Click j2eeagent-1.
  
  The j2eeagent-1 properties page is displayed.
7. Log out of the OpenSSO Enterprise console and close the browser.

Remove the password files.

# cd /export/J2EEPA1
# rm agent.pwd
# rm agentadm.pwd

Log out of the pr-1 host machine.

To Deploy the J2EE Policy Agent 1 Application

The agent application is a housekeeping application bundled with the binaries and used by the agent for notifications and other internal functionality. This application must be deployed to the agent-protected web container using the same URI that was supplied during the agent installation process. For example, during the installation process, if you entered /agentapp as the deployment URI for the agent application, use that same context path in this procedure.

Access http://pr-1.example.com:7001/console from a web browser.

Under Domain Structure, click Deployments.

On the Summary of Deployments page, in the Change Center, click Lock & Edit.

Under Deployments, click Install.

On the Install Application Assistant page, click the pr-1.example.com link.

In the field named Location: pr-1.example.com, click the root directory.

Navigate to /export/J2EEPA1/j2ee_agents/weblogic_v10_agent/etc, the application directory.

Select agentapp.war and click Next.

In the Install Application Assistant page, choose Install this deployment as an application and click Next.

In the list of Servers, mark the checkbox for ApplicationServer-1 and click Next.

In the Optional Settings page, click Next.

Click Finish.

On the Settings for agentapp page, click Save.

In the Change Center, click Activate Changes.

To Start the J2EE Policy Agent 1 Application

Before You Begin

This procedure assumes that you have just completed To Deploy the J2EE Policy Agent 1 Application and are still logged in to the WebLogic Server console as the administrator.

In the WebLogic Server console, on the Settings for agentapp page, click Deployments.

On the Summary of Deployments page, mark the agentapp checkbox and click Start > Servicing all requests.

On the Start Application Assistant page, click Yes.

Tip –
If you encounter a JavaScript^TM error, start the WebLogic Server instance and perform the steps again.

To Set Up the J2EE Policy Agent 1 Authentication Provider

Before You Begin

This procedure assumes that you have just completed To Start the J2EE Policy Agent 1 Application and are still logged in to the WebLogic Server console as the administrator.

In the WebLogic Server console, on the Summary of Deployments page, under Domain Structure, click Security Realms.

On the Summary of Security Realms page, click Lock & Edit.

Click the myrealm link.

On the Settings for myrealm page, click the Providers tab.

Under Authentication Providers, click New.

On the Create a New Authentication Provider page, provide the following information and click OK.

Name:

Agent-1

Type:

Select AgentAuthenticator from the drop down list.

Agent-1 is now included in the list of Authentication Providers.

In the list of Authentication Providers, click Agent-1.

In the Settings for Authentication Providers page, verify that the Control Flag is set to OPTIONAL.

In the navigation tree near the top of the page, click Providers.

In the list of Authentication Providers, click DefaultAuthenticator.

In the Settings for DefaultAuthenticator page, set the Control Flag to OPTIONAL and click Save.

In the navigation tree near the top of the page, click Providers again.

In the Change Center, click Activate Changes.

If indicated by the console, restart the servers with the following sub procedure.

Log out of the WebLogic Server console.

As a root user, log into the pr–1 host machine.

Restart the administration server and the managed instance.

# cd /usr/local/bea/user_projects/domains/pr-1/bin
# ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001
# ./stopWebLogic.sh
# ./startWebLogic.sh
# ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001

Log out of the pr–1 host machine.

To Deploy the J2EE Policy Agent 1 Sample Application

Access Application Server 1 at http://pr-1.example.com:7001/console.

On the Change Center, click Lock & Edit.

Under Domain Structure, click Deployments.

Under Deployments, click Install.

On the Install Application Assistant page, click the pr-1.example.com link.

In the list for Location: pr-1.example.com, click the root directory.

Navigate to the application directory (/export/J2EEPA1/j2ee_agents/weblogic_v10_agent/sampleapp/dist), select agentsample.ear and click Next.

In the Install Application Assistant page, choose Install this deployment as an application and click Next.

In the list of Servers, mark the checkbox for ApplicationServer-1 and click Next.

On the Optional Settings page, click Next to accept the default settings.

On the Review Your Choices page, click Finish.

The Target Summary section indicates that the module agentsample will be installed on the target ApplicationServer-1.

On the Settings for agentsample page, click Save.

On the Settings for agentsample page, click Activate Changes.

Under Domain Structure, click Deployments.

In the Deployments list, mark the checkbox for agentsample and click Start > Servicing All Requests.

On the Start Application Assistant page, click Yes.

The state of the deployment changes from Prepared to Active.

Log out of the Application Server 1 console.

To Modify the J2EE Policy Agent 1 Configuration

The J2EE policy agent can operate in local or centralized mode. The centralized option was selected during the custom installation of the agent. Centralized agent configuration stores agent configuration data in a data store managed by OpenSSO Enterprise. In this deployment, J2EE policy agents are configured in centralized mode meaning that any configuration changes must be made using the OpenSSO Enterprise server. For more information, see Centralized Agent Configuration in Sun OpenSSO Enterprise 8.0 Technical Overview.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the J2EE tab.

j2eeagent-1 is displayed under the Agent table.

Click j2eeagent-1.

The j2eeagent-1 properties page is displayed.

Click the Miscellaneous tab.

The Miscellaneous properties page is displayed.

Provide the user name of the Application Server administrator in the Bypass Principal List and click Add.

Enter weblogic to ensure that the administrator will be authenticated against WebLogic itself and not OpenSSO Enterprise.

Click Save.

Exit the console and close the browser.

8.1.2 Installing and Configuring the J2EE Container and J2EE Policy Agent on Protected Resource 2

Download the BEA WebLogic Server bits to the pr-2 host machine and install the application server. Additionally, download, install and configure the appropriate J2EE policy agent. Use the following list of procedures as a checklist for completing this task.

To Install BEA WebLogic Server as J2EE Container 2 on Protected Resource 2

BEA WebLogic Server is the application server used as the J2EE container on Protected Resource 2.

As a root user, log into the pr-2 host machine.

Ensure that your system is properly patched.

Refer to the BEA web site to make sure that your system has the recommended patches.

Create a directory into which you can download the WebLogic Server bits and change into it.
# mkdir /export/BEAWL10 # cd /export/BEAWL10

Download the WebLogic Server bits from http://commerce.bea.com/.

For this deployment, we download the Solaris version.

# ls -al

total 294548
drwxr-xr-x   2 root     root         512 Aug  7 13:23 .
drwxr-xr-x   3 root     sys          512 Aug  7 13:16 ..
-rw-r--r--   1 root     root     656834948 Aug  7 13:24 server100_solaris32.bin

Run the installer.
# ./server100_solaris32.bin

When prompted, do the following:

The Welcome screen is displayed.

Click Next.

Accept the License agreement

Select Yes and click Next.

Create a new BEA Home

Type /usr/local/bea and click Next.

Select "Custom"

Click Next.

Deselect the following:
- Workshop for WebLogic Platform

Click Next.

Choose Product Installation Directories

Type /usr/local/bea/weblogic10 and click Next.

Installation Complete

Deselect Run Quickstart and click Done.

Verify that the application was correctly installed.

# cd /usr/local/bea
# ls -al

total 90
drwxr-xr-x   7 root     root         512 Jul 15 11:59 .
drwxr-xr-x   4 root     root         512 Jul 15 11:58 ..
-rwxr-xr-x   1 root     root         826 Jul 15 11:59 UpdateLicense.sh
-rw-r--r--   1 root     root          14 Jul 15 11:59 beahomelist
drwxr-xr-x   6 root     root         512 Jul 15 11:59 jdk150_06
-rw-r--r--   1 root     root       12447 Jul 15 11:59 license.bea
drwxr-xr-x   2 root     root         512 Jul 15 11:59 logs
drwxr-xr-x   6 root     root        6656 Jul 15 11:58 modules
-rw-r--r--   1 root     root       15194 Jul 15 11:59 registry.dat
-rw-r--r--   1 root     root        1077 Jul 15 11:59 registry.xml
drwxr-xr-x   4 root     root         512 Jul 15 12:01 utils
drwxr-xr-x  10 root     root         512 Jul 15 11:59 weblogic10

To Configure BEA WebLogic Server as J2EE Container 2 on Protected Resource 2

After installing the bits, WebLogic Server must be configured.

Before You Begin

This procedure assumes you have just completed To Install BEA WebLogic Server as J2EE Container 2 on Protected Resource 2 and are still logged into the host machine as the root user.

Run the WebLogic Server configuration script.

# cd /usr/local/bea/weblogic10/common/bin
# ./config.sh

When prompted, do the following:

Select "Create a new Weblogic domain"

Click Next.

Select "Generate a domain configured automatically 
to support the following BEA products:"

Click Next.

Configure Administrator Username and Password

Enter the following and click Next.

Username: weblogic
Password: bea10admin
Confirm Password: bea10admin

Select "Prduction Mode" and "BEA Supplied JDK's" 
(Sun SDK 1.5.0_06@/usr/local/bea/jdk150_06)

Click Next.

Customize Environment and Services Settings

Select yes and click Next.

Configure the Administration Server

Accept the default values and click Next.

Configure Managed Servers

Select Add, enter the following values, and click Next.

Name: ApplicationServer-2
Listen Port: 1081

Configure Clusters

Accept the default values and click Next.

Configure Machines

Select the Unix Machine tab, then select Add, type pr-2 and click Next.

Assign Servers to Machines

From the left panel select AdminServer and ApplicationServer-2. From the right panel select pr-2. Click --> and then click Next.

Review WebLogic Domain

Click Next.

Create WebLogic Domain

Add the following and click Create.

Domain name: pr-2
Domain Location: /usr/local/bea/user_projects/domains (default)

Creating Domain

Click Done.

Start the WebLogic administration server.
# cd /usr/local/bea/user_projects/domains/pr-2 # ./startWebLogic.sh
When prompted, type the following credentials.

Username

weblogic

Password

bea10admin

Run the netstat command to verify that the port is open and listening.
# netstat -an | grep 7001 XXX.XX.XX.101.7001 *.* 0 0 49152 0 LISTEN XXX.X.X.1.7001 *.* 0 0 49152 0 LISTEN
Note –
You can also access the administration console by pointing a web browser to http://pr-2.example.com:7001/console.

Change to the AdminServer directory.

# cd /usr/local/bea/user_projects/domains/pr-2/servers/AdminServer

Create a security directory and change into it.
# mkdir security # cd security

Create a boot.properties file for the WebLogic Server administration server administrator credentials.

The administration server administrative user and password are stored in boot.properties. Application Server 2 uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=bea10admin Hit Control D to terminate the command ^D

Restart WebLogic to encrypt the username and password in boot.properties.

# cd /usr/local/bea/user_projects/domains/pr-2/bin
# ./stopWebLogic.sh
# ./startWebLogic.sh

Start the managed servers.

# cd /usr/local/bea/user_projects/domains/pr-2/bin
# ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001

You will be prompted for the administrative user credentials.

Username: weblogic
Password: bea10admin

Change to the ApplicationServer-2 directory.

# cd /usr/local/bea/user_projects/domains/pr-2/
  servers/ApplicationServer-2

Create a security directory and change into it.
# mkdir security # cd security

Create a boot.properties file for the WebLogic Server managed server administrator credentials.

The managed server administrative user and password are stored in boot.properties. The Application Server 2 managed server uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=bea10admin Hit Control D to terminate the command ^D

Restart the managed server.

# cd /usr/local/bea/user_projects/domains/ 
  pr-2/bin
# ./stopManagedWebLogic.sh ApplicationServer-2 
   t3://localhost:7001
# ./startManagedWebLogic.sh ApplicationServer-2 
   t3://localhost:7001

Run the netstat command to verify that the port is open and listening.

# netstat -an | grep 1081

XXX.XX.XX.101.1081     *.*                0      0 49152      0 LISTEN
XXX.X.X.1.1081         *.*                0      0 49152      0 LISTEN

Access http://pr-2.example.com:7001/console from a web browser.

Click servers under Domain Structure —>Environment.

On the Summary of Servers page, verify that both AdminServer (admin) and ApplicationServer-2 are running and OK.

Log out of the console.

Log out of the pr–2 host machine.

To Import the Certificate Authority Root Certificate into Application Server 2

The CA root certificate enables the J2EE policy agent to trust the certificate from the OpenSSO Enterprise Load Balancer 2, and to establish trust with the certificate chain that is formed from the CA to the certificate.

Before You Begin

Copy the same CA root certificate used in To Install a CA Root Certificate to the OpenSSO Enterprise Load Balancer to the /export/software directory on the pr-2 host machine.

As a root user, log into the pr–2 host machine.

Change to the directory where the cacerts certificate store is located.
# cd /usr/local/bea/jdk150_06/jre/lib/security.
Tip –
Backup cacerts before modifying it.

Import ca.cer, the CA root certificate.

# /usr/local/bea/jdk150_06/bin/keytool -import -trustcacerts 
  -alias OpenSSLTestCA -file /export/software/ca.cer 
  -keystore /usr/local/bea/jdk150_06/jre/lib/security/cacerts -storepass changeit

Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Serial number: 97dba0aa26db6386
Valid from: Tue Apr 18 07:66:19 PDT 2006 until: Tue Jan 13 06:55:19
PST 2009
Certificate fingerprints:
MD5: 9f:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06
SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:26:64:36:80:E4:70
Trust this certificate: [no] yes

Certificate was added to keystore.

Verify that ca.cer was successfully imported.

# /usr/local/bea/jdk150_06/bin/keytool -list 
  -keystore /usr/local/bea/jdk150_06/jre/lib/security/cacerts 
  -storepass changeit | grep -i openssl

OpenSSLTestCA, Sep 15, 2008, trustedCertEntry,

Log out of the pr–2 host machine.

To Install the J2EE Policy Agent 2 on Application Server 2

Before You Begin

Set JAVA_HOME to /usr/local/bea/jdk150_06.

As a root user, log into the pr-2 host machine.

Stop the WebLogic Server 2 administration server and the WebLogic Server 2 managed server.

# cd /usr/local/bea/user_projects/domains/pr-2/bin
# ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001
# ./stopWebLogic.sh

Create a directory into which you will download the J2EE policy agent bits and change into it.
# mkdir /export/J2EEPA2 # cd /export/J2EEPA2

Create a text file that contains a password for the Agent Profile created during installation.

The J2EE Policy Agent installer requires this.
# cat > agent.pwd j2eeagent2 Hit Control D to terminate the command ^D

Create a text file that contains the Agent Administrator password.

This text file should contain the password of the OpenSSO Enterprise administrator (by default, amadmin).
# cat > agentadm.pwd ossoadmin Hit Control D to terminate the command ^D

Download the J2EE policy agent bits for WebLogic Server from http://www.sun.com/download/index.jsp.

# ls -al

total 18824
drwxr-xr-x   2 root     root         512 Jul 17 16:02 .
drwxr-xr-x   8 root     root         512 Jul 17 15:58 ..
-rw-r--r--   1 root     root          11 Jul 17 15:59 agent.pwd
-rw-r--r--   1 root     root           9 Jul 17 16:01 agentadm.pwd
-rw-r--r--   1 root     root     9623704 Jul 17 16:02 weblogic_v10_agent_3.zip

Unpack the J2EE policy agent bits.
# unzip weblogic_v10_agent_3.zip

Run the J2EE policy agent installer.

# cd /export/J2EEPA2/j2ee_agents/weblogic_v10_agent/bin
# chmod 755 agentadmin
# ./agentadmin --custom-install

When prompted, provide the following information.

The following information is to configure the J2EE Policy Agent against the OpenSSO Enterprise secure port.

Please read the following License Agreement carefully:

Press Enter to continue. Continue to press Enter until you reach the end of the License Agreement and the installer's Welcome page is displayed.

Enter startup script location.

Enter /usr/local/bea/user_projects/domains/pr-2/bin/startwebLogic.sh

Enter the WebLogic Server instance 
name: [AdminServer]

Enter the name of the WebLogic Server instance secured by the agent ApplicationServer-2

Enter the WebLogic home directory: 
[/usr/local/bea/wlserver_10.0]

Enter /usr/local/bea/weblogic10.

OpenSSO Enterprise 
URL

Enter the URL where OpenSSO Enterprise is running (including the URI): https://lb-2.example.com:1081/opensso

Is the agent being deployed on a Portal domain [false]

Accept the default value.

Agent URL:

Enter the URL where the policy agent is running (including the URI): http://pr-2.example.com:1081/agentapp

Enter the Encryption Key 
[+Yr3K4K1/lWFe4H17SBHMNIUzLNRut7H]:

Accept the default value.

Enter the Agent Profile Name:

j2eeagent-2

Enter the path to the password file:

Enter the path to a file that contains the password to be used for identifying the policy agent: /export/J2EEPA2/agent.pwd.

Note –

A warning message is displayed regarding the existence of the agent profile.

This Agent Profile does not exist in 
OpenSSO Enterprise. 
Will it be created by the installer? (Agent 
Administrator name and password are required) 
[true]:

Accept the default value to create the Agent Profile during installation.

Enter the Agent Administrator's name:

Enter amadmin

Enter the path to the password file 
that contains the password of Agent Administrator:

Enter /export/J2EEPA2/agentadm.pwd

-----------------------------------------------
SUMMARY OF YOUR RESPONSES
-----------------------------------------------
Startup script location :
  /usr/local/bea/user_projects/domains/
  pr-2/bin/startWebLogic.sh
WebLogic Server instance name : 
  ApplicationServer-2
WebLogic home directory : 
  /usr/local/bea/weblogic10
OpenSSO Server  URL : 
  https://lb-2.example.com:1081/opensso
Agent Installed on Portal domain : false
Agent URL : 
  http://pr-2.example.com:1081/agentapp
Encryption Key : 
  +Yr3K4K1/lWFe4H17SBHMNIUzLNRut7H
Agent Profile name : j2eeagent-2
Agent Profile Password file name : 
  /export/J2EEPA2/agent.pwd
Agent Profile will be created right now 
  by agent installer : true
Agent Administrator : amadmin
Agent Administrator's password file 
  name : /export/J2EEPA2/agentadm.pwd

Verify your settings and decide from 
the choices below:
1. Continue with Installation
2. Back to the last interaction
3. Start Over
4. Exit
Please make your selection [1]:

Accept the default value.

-----------------------------------------------
SUMMARY OF AGENT INSTALLATION
-----------------------------
Agent instance name: Agent_001
Agent Bootstrap file location:
/export/J2EEPA2/j2ee_agents/
  weblogic_v10_agent/Agent_001/
  config/FAMAgentBootstrap.properties
Agent Configuration file location
/export/J2EEPA2/j2ee_agents/
  weblogic_v10_agent/Agent_001/
  config/FAMAgentConfiguration.properties
Agent Audit directory location:
/export/J2EEPA2/j2ee_agents/
  weblogic_v10_agent/Agent_001/logs/audit
Agent Debug directory location:
/export/J2EEPA2/j2ee_agents/
  weblogic_v10_agent/Agent_001/logs/debug

Install log file location:
/export/J2EEPA2/j2ee_agents/
  weblogic_v10_agent/installer-logs
  /audit/custom.log

Accept the default value.

When the installer is finished, a new file is in the bin directory called setAgentEnv_ApplicationServer-2.sh.

Modify the startup script setDomainEnv.sh to reference setAgentEnv_ApplicationServer-2.sh using the following sub procedure.

Tip –
Backup setDomainEnv.sh before you modify it.
1. Change to the bin directory.
  # cd /usr/local/bea/user_projects/domains/pr-2/bin
2. Insert the following line at the end of setDomainEnv.sh.
  . /usr/local/bea/user_projects/domains/pr-2/ bin/setAgentEnv_ApplicationServer-2.sh
3. Save setDomainEnv.sh and close the file.

Change permissions for setAgentEnv_ApplicationServer-2.sh.
# chmod 755 setAgentEnv_ApplicationServer-2.sh

Start the WebLogic Server administration server and managed instance.

# ./startWebLogic.sh &
# ./startManagedWebLogic.sh ApplicationSever-2 t3://localhost:7001

Watch for startup errors.

Verify that the J2EE Policy Agent 2 was successfully created on the server using the following sub-procedure.
1. Access https://osso-1.example.com:1081/opensso/console from a web browser.
2. Log in to the OpenSSO Enterprise console as the administrator.
  
  User Name:
  
  amadmin
  
  Password:
  
  ossoadmin
3. Under the Access Control tab, click / (Top Level Realm).
4. Click the Agents tab.
5. Click the J2EE tab.
  
  j2eeagent-2 is displayed under the Agent table.
6. Click j2eeagent-2.
  
  The j2eeagent-2 properties page is displayed.
7. Log out of the OpenSSO Enterprise console and close the browser.

Remove the password files.

# cd /export/J2EEPA2
# rm agent.pwd
# rm agentadm.pwd

Log out of the pr-2 host machine.

To Deploy the J2EE Policy Agent 2 Application

Access http://pr-2.example.com:7001/console from a web browser.

Under Domain Structure, click Deployments.

On the Summary of Deployments page, in the Change Center, click Lock & Edit.

Under Deployments, click Install.

On the Install Application Assistant page, click the pr-2.example.com link.

In the field named Location: pr-2.example.com, click the root directory.

Navigate to /export/J2EEPA2/j2ee_agents/weblogic_v10_agent/etc, the application directory.

Select agentapp.war and click Next.

In the Install Application Assistant page, choose Install this deployment as an application and click Next.

In the list of Servers, mark the checkbox for ApplicationServer-2 and click Next.

In the Optional Settings page, click Next.

Click Finish.

On the Settings for agentapp page, click Save.

In the Change Center, click Activate Changes.

To Start the J2EE Policy Agent 2 Application

Before You Begin

This procedure assumes that you have just completed To Deploy the J2EE Policy Agent 2 Application and are still logged in to the WebLogic Server console as the administrator.

In the WebLogic Server console, on the Settings for agentapp page, click Deployments.

On the Summary of Deployments page, mark the agentapp checkbox and click Start > Servicing all requests.

On the Start Application Assistant page, click Yes.

Tip –
If you encounter a JavaScript error, start the WebLogic Server instance and perform the steps again.

To Set Up the J2EE Policy Agent 2 Authentication Provider

Before You Begin

This procedure assumes that you have just completed To Start the J2EE Policy Agent 2 Application and are still logged in to the WebLogic Server console as the administrator.

In the WebLogic Server console, on the Summary of Deployments page, under Domain Structure, click Security Realms.

On the Summary of Security Realms page, click Lock & Edit.

Click the myrealm link.

On the Settings for myrealm page, click the Providers tab.

Under Authentication Providers, click New.

On the Create a New Authentication Provider page, provide the following information and click OK.

Name:

Agent-2

Type:

Select AgentAuthenticator from the drop down list.

Agent-2 is now included in the list of Authentication Providers.

In the list of Authentication Providers, click Agent-2.

In the Settings for Authentication Providers page, verify that the Control Flag is set to OPTIONAL.

In the navigation tree near the top of the page, click Providers.

In the list of Authentication Providers, click DefaultAuthenticator.

In the Settings for DefaultAuthenticator page, set the Control Flag to OPTIONAL and click Save.

In the navigation tree near the top of the page, click Providers again.

In the Change Center, click Activate Changes.

If indicated by the console, restart the servers.

Log out of the WebLogic Server console.

As a root user, log into the pr–2 host machine.

Restart the administration server and the managed instance.

# cd /usr/local/bea/user_projects/domains/pr-2/bin
# ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001
# ./stopWebLogic.sh
# ./startWebLogic.sh
# ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001

Log out of the pr–2 host machine.

To Deploy the J2EE Policy Agent 2 Sample Application

Access Application Server 2 at http://pr-2.example.com:7001/console.

On the Change Center, click Lock & Edit.

Under Domain Structure, click Deployments.

Under Deployments, click Install.

On the Install Application Assistant page, click the pr-2.example.com link.

In the list for Location: pr-2.example.com, click the root directory.

Navigate to the application directory (/export/J2EEPA2/j2ee_agents/weblogic_v10_agent/sampleapp/dist), select agentsample.ear and click Next.

In the Install Application Assistant page, choose Install this deployment as an application and click Next.

In the list of Servers, mark the checkbox for ApplicationServer-2 and click Next.

On the Optional Settings page, click Next to accept the default settings.

On the Review Your Choices page, click Finish.

The Target Summary section indicates that the module agentsample will be installed on the target ApplicationServer-2.

On the Settings for agentsample page, click Save.

On the Settings for agentsample page, click Activate Changes.

Under Domain Structure, click Deployments.

In the Deployments list, mark the checkbox for agentsample and click Start > Servicing All Requests.

On the Start Application Assistant page, click Yes.

The state of the deployment changes from Prepared to Active.

Log out of the Application Server 2 console.

To Modify the J2EE Policy Agent 2 Configuration

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the J2EE tab.

j2eeagent-2 is displayed under the Agent table.

Click j2eeagent-2.

The j2eeagent-2 properties page is displayed.

Click the Miscellaneous tab.

The Miscellaneous properties page is displayed.

Provide the user name of the Application Server administrator in the Bypass Principal List and click Add.

Enter weblogic to ensure that the administrator will be authenticated against WebLogic itself and not OpenSSO Enterprise.

Click Save.

Exit the console and close the browser.

8.1.3 Creating Groups Using the OpenSSO Enterprise Console

A group represents a collection of users with a common function, feature or interest. The groups created with this procedure will be replicated to OpenSSO Enterprise 2 and used in 8.1.4 Setting Up a Test for the J2EE Policy Agent 1 and 8.1.5 Setting Up a Test for the J2EE Policy Agent 2.

To Create Manager and Employee Groups with OpenSSO Enterprise

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Subjects tab.

Click the Group tab.

The Group page is displayed.

Create a manager group using the following sub procedure.
1. Click New on the Group page.
  
  The New Group properties page is displayed.
2. Enter Manager-Group as the ID and click OK.
  
  The Group page is displayed.
3. Click Manager-Group in the list.
4. Click the User tab.
  
  The test users are displayed.
5. Select Test User 1 from the list and click Add.
6. Click Save.
7. Click Back to Subjects.

Create an employee group using the following sub procedure.
1. Click New on the Group page.
  
  The New Group properties page is displayed.
2. Enter Employee-Group as the ID and click OK.
  
  The Group page is displayed.
3. Click Employee-Group in the list.
4. Click the User tab.
  
  The test users are displayed.
5. Select Test User 2 from the list and click Add.
6. Click Save.
7. Click Back to Subjects.

Log out of the OpenSSO Enterprise console.

8.1.4 Setting Up a Test for the J2EE Policy Agent 1

The BEA Policy Agent comes with a sample application that was deployed in To Deploy the J2EE Policy Agent 1 Sample Application and To Deploy the J2EE Policy Agent 2 Sample Application. The application was created to help test policies and will be used for that purpose in this section. Use the following list as a checklist for this task.

Note –

For more information on the sample application, see readme.txt in the /export/J2EEPA1/j2ee_agents/weblogic_v10_agent/sampleapp directory.

To Create a Test Policy in the OpenSSO Enterprise Root Realm

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Policies tab.

The Policies page is displayed.

Click New Policy.

Enter URL Policy for Application Server-1 in the Name field.

Under Rules, click New.

On the resulting page, select URL Policy Agent (with Resource Name) and click Next.

On the resulting page, provide the following information and click Finish.

Name:

agentsample

Resource Name:

http://pr-1.example.com:1081/agentsample/*

Note –
Make sure the hostname is typed in lowercase.

GET

Mark this check box and verify that Allow is selected.

POST

Mark this check box and verify that Allow is selected.

The rule agentsample is now added to the list of Rules.

Under Subjects, click New.

On the resulting page, select Access Manager Identity Subject and click Next.

On the resulting page, provide the following information and click Search.

Name:

agentsampleGroup

Filter:

Select Group.

Manager-Group and Employee-Group are displayed in the Available list.

Select Manager-Group and Employee-Group and click Add.

Manager-Group and Employee-Group are displayed in the Selected list.

Click Finish.

Click OK.

The new policy is displayed in the list of policies.

Click Back to Access Control.

Log out of the OpenSSO Enterprise console.

To Configure OpenSSO Enterprise Properties for the J2EE Policy Agent 1 Sample Application

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the J2EE tab.

j2eeagent-1 is displayed under the Agent table.

Click j2eeagent-1.

The j2eeagent-1 properties page is displayed.

Click the Application tab.

The Application properties page is displayed.

Provide the following information.

Login Form URI:

Enter the following and click Add.

/agentsample/authentication/login.html

Not Enforced URI Processing:

Enter each of the following and click Add.

/agentsample/public/*

/agentsample/images/*

/agentsample/styles/*

/agentsample/index.html

/agentsample

Resource Access Denied URI:

Enter each of the following and click Add.

Map Key: agentsample

Corresponding Map Value: /agentsample/authentication/accessdenied.html

Click Save.

The j2eeagent-1 properties page is displayed.

Map the attributes from the OpenSSO Enterprise embedded data store to those used by the Application Server with the following sub procedure.
1. From the j2eeagent-1 properties page, click Back to Main Page.
2. Click the Subjects tab.
3. Click the Group tab.
4. Click Employee-Group in the list of Groups.
5. Copy and save id=Employee-Group,ou=group,dc=opensso,dc=java,dc=net, the value of the Universal ID attribute.
6. Click Back to Subjects.
  
  You are returned to the Group tab.
7. Click Manager-Group in the list of Groups.
8. Copy and save id=Manager-Group,ou=group,dc=opensso,dc=java,dc=net, the value of the Universal ID attribute.
9. Click Back to Subjects.
10. Click the Agents tab.
11. Click the J2EE tab.
  
  j2eeagent-1 is displayed under the Agent table.
12. Click j2eeagent-1.
  
  The j2eeagent-1 properties page is displayed.
13. Click the Application tab.
  
  The Application properties page is displayed.
14. Provide the identifiers previously saved as the manager and employee map keys and corresponding map values for Privileged Attribute Mapping and click Save.
  Map Key: [id=Manager-Group,ou=group,dc=opensso,dc=java,dc=net] Corresponding Map Value: am_manager_role
  Map Key: [id=Employee-Group,ou=group,dc=opensso,dc=java,dc=net] Corresponding Map Value: am_employee_role

Log out of the OpenSSO Enterprise console.

To Verify that J2EE Policy Agent 1 is Configured Properly

Use these steps to access the agent sample application and test policies against it.

Access http://pr-1.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.

The Sample Application welcome page is displayed.

Click the J2EE Declarative Security link.

On the resulting page, click Invoke the Protected Servlet.

You are redirected to the OpenSSO Enterprise login page.

Log in to OpenSSO Enterprise as testuser1.

Username

testuser1

Password

password

If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, the first part of the test has succeeded and authentication is working as expected.

Click the J2EE Declarative Security link again.

On the resulting page, click Invoke the Protected Servlet.

If the Success Invocation message is displayed, the second part of the test has succeeded as the sample policy for the manager role has been enforced as expected.

Click the J2EE Declarative Security link to return.

On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.

If the Failed Invocation message is displayed, the third part of the test has succeeded as the sample policy for the employee role has been enforced as expected.

Close the browser.

In a new browser session, access http://pr-1.example.com:1081/agentsample/index.html, the sample application URL, again.

The Sample Application welcome page is displayed.

Click the J2EE Declarative Security link.

On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.

You are redirected to the OpenSSO Enterprise login page.

Log in to OpenSSO Enterprise as testuser2.

Username

testuser2

Password

password

Note –
The Failed Invocation message is displayed. This is a known issue.

Click the J2EE Declarative Security link.

On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.

The Successful Invocation message is displayed as the sample policy for the employee role has been enforced as expected.

Click the J2EE Declarative Security link to return.

On the resulting page, click Invoke the Protected Servlet.

If the Access to Requested Resource Denied message is displayed, this part of the test has succeeded as the sample policy for the manager role has been enforced as expected.

Close the browser.

8.1.5 Setting Up a Test for the J2EE Policy Agent 2

Note –

For more information on the sample application, see readme.txt in the /export/J2EEPA2/j2ee_agents/weblogic_v10_agent/sampleapp directory.

To Create a Test Policy in the OpenSSO Enterprise Root Realm

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Policies tab.

The Policies page is displayed.

Click New Policy.

Enter URL Policy for Application Server-2 in the Name field.

Under Rules, click New.

On the resulting page, select URL Policy Agent (with Resource Name) and click Next.

On the resulting page, provide the following information and click Finish.

Name:

agentsample

Resource Name:

http://pr-2.example.com:1081/agentsample/*

Note –
Make sure the hostname is typed in lowercase.

GET

Mark this check box and verify that Allow is selected.

POST

Mark this check box and verify that Allow is selected.

The rule agentsample is now added to the list of Rules.

Under Subjects, click New.

On the resulting page, select Access Manager Identity Subject and click Next.

On the resulting page, provide the following information and click Search.

Name:

agentsampleGroup

Filter:

Select Group.

Manager-Group and Employee-Group are displayed in the Available list.

Select Manager-Group and Employee-Group and click Add.

Manager-Group and Employee-Group are displayed in the Selected list.

Click Finish.

Click OK.

The new policy is displayed in the list of policies.

Click Back to Access Control.

Log out of the OpenSSO Enterprise console.

To Configure OpenSSO Enterprise Properties for the J2EE Policy Agent 2 Sample Application

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the J2EE tab.

j2eeagent-2 is displayed under the Agent table.

Click j2eeagent-2.

The j2eeagent-2 properties page is displayed.

Click the Application tab.

The Application properties page is displayed.

Provide the following information.

Login Form URI:

Enter the following and click Add.

/agentsample/authentication/login.html

Not Enforced URI Processing:

Enter each of the following and click Add.

/agentsample/public/*

/agentsample/images/*

/agentsample/styles/*

/agentsample/index.html

/agentsample

Resource Access Denied URI:

Enter each of the following and click Add.

Map Key: agentsample

Corresponding Map Value: /agentsample/authentication/accessdenied.html

Click Save.

The j2eeagent-2 properties page is displayed.

Map the attributes from the OpenSSO Enterprise embedded data store to those used by the Application Server with the following sub procedure.
1. From the j2eeagent-2 properties page, click Back to Main Page.
2. Click the Subjects tab.
3. Click the Group tab.
4. Click Employee-Group in the list of Groups.
5. Copy and save id=Employee-Group,ou=group,dc=opensso,dc=java,dc=net, the value of the Universal ID attribute.
6. Click Back to Subjects.
  
  You are returned to the Group tab.
7. Click Manager-Group in the list of Groups.
8. Copy and save id=Manager-Group,ou=group,dc=opensso,dc=java,dc=net, the value of the Universal ID attribute.
9. Click Back to Subjects.
10. Click the Agents tab.
11. Click the J2EE tab.
  
  j2eeagent-2 is displayed under the Agent table.
12. Click j2eeagent-2.
  
  The j2eeagent-2 properties page is displayed.
13. Click the Application tab.
  
  The Application properties page is displayed.
14. Provide the identifiers previously saved as the manager and employee map keys and corresponding map values for Privileged Attribute Mapping and click Save.
  Map Key: [id=Manager-Group,ou=group,dc=opensso,dc=java,dc=net] Corresponding Map Value: am_manager_role
  Map Key: [id=Employee-Group,ou=group,dc=opensso,dc=java,dc=net] Corresponding Map Value: am_employee_role

Log out of the OpenSSO Enterprise console.

To Verify that J2EE Policy Agent 2 is Configured Properly

Use these steps to access the agent sample application and test policies against it.

Access http://pr-2.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.

The Sample Application welcome page is displayed.

Click the J2EE Declarative Security link.

On the resulting page, click Invoke the Protected Servlet.

You are redirected to the OpenSSO Enterprise login page.

Log in to OpenSSO Enterprise as testuser1.

Username

testuser1

Password

password

If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, the first part of the test has succeeded and authentication is working as expected.

Click the J2EE Declarative Security link again.

On the resulting page, click Invoke the Protected Servlet.

If the Success Invocation message is displayed, the second part of the test has succeeded as the sample policy for the manager role has been enforced as expected.

Click the J2EE Declarative Security link to return.

On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.

If the Failed Invocation message is displayed, the third part of the test has succeeded as the sample policy for the employee role has been enforced as expected.

Close the browser.

In a new browser session, access http://pr-2.example.com:1081/agentsample/index.html, the sample application URL, again.

The Sample Application welcome page is displayed.

Click the J2EE Declarative Security link.

On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.

You are redirected to the OpenSSO Enterprise login page.

Log in to OpenSSO Enterprise as testuser2.

Username

testuser2

Password

password

Note –
The Failed Invocation message is displayed. This is a known issue.

Click the J2EE Declarative Security link.

On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.

The Successful Invocation message is displayed as the sample policy for the employee role has been enforced as expected.

Click the J2EE Declarative Security link to return.

On the resulting page, click Invoke the Protected Servlet.

If the Access to Requested Resource Denied message is displayed, this part of the test has succeeded as the sample policy for the manager role has been enforced as expected.

Close the browser.

8.1.6 Configuring the J2EE Policy Agents to Access the Distributed Authentication User Interface

Configure the J2EE policy agent to point to the secure port of the Distributed Authentication User Interface Load Balancer 3. Use the following list as a checklist to complete this task.

To Configure the J2EE Policy Agent 1 to Access the Distributed Authentication User Interface

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the J2EE tab.

j2eeagent-1 is displayed under the Agent table.

Click j2eeagent-1.

The j2eeagent-1 properties page is displayed.

Click the OpenSSO Services tab.

The Services properties page is displayed.

Make the following changes to the OpenSSO Login URL property value and click Save.
- Select https://lb-2.example.com:1081/opensso/UI/Login and click Remove.
- Enter https://lb-3.example.com:1443/distAuth/UI/Login and click Add.

Log out of the OpenSSO Enterprise console.

Verify that the agent is configured properly using the following sub procedure.
1. Access http://pr-1.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.
  
  The Sample Application Welcome page is displayed.
2. Click the J2EE Declarative Security link.
3. On the resulting page, click Invoke the Protected Servlet.
  
  You are redirected to the Distributed Authentication User Interface at https://lb-3.example.com:1443/distAuth/UI/Login.
4. (Optional) Double-click the gold lock in the lower left corner of the browser.
  
  In the Properties page, you see the certificate for lb-3.example.com.
5. Log in to OpenSSO Enterprise as testuser1.
  
  Username
  
  testuser1
  
  Password
  
  password
  
  If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, user authentication worked through the Distributed Authentication User Interface and the agent is configured properly.
6. Close the browser.

To Configure the J2EE Policy Agent 2 to Access the Distributed Authentication User Interface

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the J2EE tab.

j2eeagent-2 is displayed under the Agent table.

Click j2eeagent-2.

The j2eeagent-2 properties page is displayed.

Click the OpenSSO Services tab.

The Services properties page is displayed.

Make the following changes to the OpenSSO Login URL value and click Save.
- Select https://lb-2.example.com:1081/opensso/UI/Login and click Remove.
- Enter https://lb-3.example.com:1443/distAuth/UI/Login and click Add.

Log out of the OpenSSO Enterprise console.

Verify that the agent is configured properly using the following sub procedure.
1. Access http://pr-2.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.
  
  The Sample Application Welcome page is displayed.
2. Click the J2EE Declarative Security link.
3. On the resulting page, click Invoke the Protected Servlet.
  
  You are redirected to the Distributed Authentication User Interface at https://lb-3.example.com:1443/distAuth/UI/Login.
4. (Optional) Double-click the gold lock in the lower left corner of the browser.
  
  In the Properties page, you see the certificate for lb-3.example.com.
5. Log in to OpenSSO Enterprise as testuser1.
  
  Username
  
  testuser1
  
  Password
  
  password
  
  If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, user authentication worked through the Distributed Authentication User Interface and the agent is configured properly.
6. Close the browser.

8.2 Configuring the Protected Resource Host Machines with a Web Policy Agent

We will install Sun Java System Web Server and a Web policy agent on the Protected Resource 1 host machine (pr-1) and on the Protected Resource 2 host machine (pr-2). The policy agents are then configured to access Load Balancer 2. Use the following list of procedures as a checklist for completing the task.

8.2.1 Installing and Configuring the Web Container and Web Policy Agent on Protected Resource 1

Download the Sun Java System Web Server bits to the pr-1 host machine and install it. Additionally, download, install and configure the appropriate web policy agent. Use the following list of procedures as a checklist for completing the task.

To Install and Configure Sun Java System Web Server as Web Container 1 on Protected Resource 1

Sun Java System Web Server is the web container used on the pr-1 host machine.

Before You Begin

Read the latest version of the Web Server 7.0 Release Notes to determine if you need to install patches on your host machine. In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 119963–08, patch 120011–14, and patch 117461–08 are required.

As a root user, log into the pr-1 host machine.

Install the required patches if necessary.

Patch results for your machines might be different.
1. Run patchadd to see if the patch is installed.
  # patchadd -p | grep 117461–08
  A list of patch numbers is displayed. On our lab machine, the required patch 117461–08 is present so there is no need to install it.
  # patchadd -p | grep 119963–08
  No results are returned which indicates that the patch is not yet installed on the system.
  # patchadd -p | grep 120011-14
  No results are returned which indicates that the patch is not yet installed on the system.
2. Make a directory for downloading the patch you need and change into it.
  # mkdir /export/patches # cd /export/patches
3. Download the patches.
  
  You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
  
  Note –
  Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
4. Unzip the patch file.
  # unzip 119963–08.zip # unzip 120011–14.zip
5. Run patchadd to install the patches.
  # patchadd /export/patches/119963–08 # patchadd /export/patches/120011–14
6. After installation is complete, run patchadd to verify that the patch was added successfully.
  # patchadd -p | grep 119963–08
  In this example, a series of patch numbers are displayed, and the patch 119963–08 is present.
  # patchadd -p | grep 120011-14
  In this example, a series of patch numbers are displayed, and the patch 120011–14 is present.

Create a directory into which you can download the Web Server bits and change into it.
# mkdir /export/WS7 # cd /export/WS7

Download the Sun Java System Web Server 7.0 Update 3 software from http://www.sun.com/download/products.xml?id=45ad781d.

Follow the instructions on the Sun Microsystems Product Downloads web site for downloading the software.

Unpack the Web Server package.

# gunzip sjsws-7_0u3-solaris-sparc.tar.gz
# tar xvf sjsws-7_0u3-solaris-sparc.tar

Run setup.
# cd /export/WS7 # ./setup --console

When prompted, provide the following information.

Welcome to the Sun Java System Web 
Server 7.0u3 installation wizard.
...
You will be asked to specify preferences that 
determine how Sun Java System Web Server 7.0U3 
is installed and configured. 

The installation program pauses as questions 
are presented so you can read the 
information and make your choice. When you 
are ready to continue, press Enter. 
(Return on some keyboards.)

Press Enter. Continue to press Enter when prompted.

Have you read the Software License 
Agreement and do you accept all terms 
[no] {"," goes back, "!" exits}?

Enter yes.

Sun Java System Web Server 7.0 
Installation Directory [/sun/webserver7] 
{"," goes back, "!" exits} :

Enter /opt/SUNWwbsvr

Specified directory /opt/SUNWwbsvr 
does not exist. Create Directory? [Yes/No]
[yes] {"," goes back, "!" exits}

Enter yes.

Select Type of Installation

1. Express
2. Custom
3. Exit

What would you like to do? [1]
{"," goes back, "!" exits}

Enter 2.

Component Selection

1. Server Core
2. Server Core 64-biy Binaries
3. Administration Command Line Interface
4. Sample Applications
5. Language Pack

Enter the comma-separated list [1,2,3,4,5] 
{"," goes back, "!" exits}

Enter 1,3,5.

Java Configuration

Sun Java System Web Server 7.0 requires Java 
Se Development Kit (JDK). Provide the path 
to a JDK 1.5.0_15 or greater.

1. Install Java SE Development Kit (JDK) 1.5.0_15
2. Reuse existing Java SE Development Kit 
   (JDK) 1.5.0_15
3. Exit

What would you like to do? [1] 
{"," goes back, "!" exits}

Enter 1.

Administrative Options

1. Create an Administration Server and a 
   Web Server Instance
2. Create an Administration Node

Enter your option. [1]
{"," goes back, "!" exits}

Enter 1.

Create SMF services for server instances 
[yes/no] [no] {"," goes back, "!" exits}

Accept the default value.

Host Name [pr-1.example.com] 
{"," goes back, "!" exits}

Accept the default value.

SSL Port [8989] 
{"," goes back, "!" exits}

Accept the default value.

Create a non-SSL Port? [yes/no] [no] 
{"," goes back, "!" exits}

Enter no.

Runtime User ID [root] 
{"," goes back, "!" exits}

Accept the default value (for the administration server).

Administrator User Name [admin]
{"," goes back, "!" exits}

Accept the default value.

Administrator Password:

Enter web4dmin.

Retype Password:

Enter web4dmin.

Server Name [pr-1.example.com] 
{"," goes back, "!" exits}

Accept the default value.

Http Port [8080] 
{"," goes back, "!" exits}

Enter 1080.

Runtime User ID [webserverd] 
{"," goes back, "!" exits}

Enter root (for the instance).

Document Root Directory [/opt/SUNWwbsvr/
https-pr-1.example.com/docs] 
{"," goes back, "!" exits}

Accept the default value.

Start Administration Server [yes/no] 
[yes] {"," goes back, "!" exits}

Enter no.

Ready To Install

1. Install Now
2. Start Over
3. Exit Installation

What would you like to do [1] 
{"," goes back, "!" exits}?

Enter1.

When installation is complete, the following message is displayed:

Installation Successful.

Start the Web Server administration server.

# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

Run netstat to verify that the port is open and listening.

# netstat -an | grep 8989

*.8989               *.*                0      0 49152      0 LISTEN

(Optional) Login to the Web Server administration console at https://pr-1.example.com:8989 as the administrator.

Username

admin

Password

web4dmin

You should see the Web Server administration console.

(Optional) Log out of the Web Server console and close the browser.

Start the Protected Resource 1 Web Server instance.

# cd /opt/SUNWwbsvr/https-pr-1.example.com/bin
# ./startserv

Sun Java System Web Server 7.0U3 B06/16/2008 12:00
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_15] from
[Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://pr-1.example.com:1080 ready to
accept requests
info: CORE3274: successful server startup

Run netstat to verify that the port is open and listening.

# netstat -an | grep 1080

*.1080               *.*                0      0 49152      0 LISTEN

(Optional) Access the Protected Resource 1 instance at http://pr-1.example.com:1080 using a web browser.

You should see the default Web Server index page.

Log out of the pr–1 host machine.

To Import the Certificate Authority Root Certificate into Web Server 1

The Certificate Authority (CA) root certificate enables the web policy agent to trust the certificate from the OpenSSO Enterprise Load Balancer 2, and to trust the certificate chain that is formed from the CA to the server certificate.

Before You Begin

Copy the same CA root certificate used in To Install a CA Root Certificate to the OpenSSO Enterprise Load Balancer to the pr-1 host machine. In this example, the file is /export/software/ca.cer.
Backup cacerts before modifying it.

As a root user, log into the pr-1 host machine.

Import the CA root certificate into cacerts, the certificate store.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import -trustcacerts 
-alias OpenSSLTestCA -file /export/software/ca.cer 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit

Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:14:51 PDT 2008 18 07:66:19 PDT 2006 
until: Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
MD5: 78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:A3:20:8C:BA

Trust this certificate: [no] yes

Certificate was added to keystore.

Verify that the CA root certificate was imported.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts 
-storepass changeit | grep -i open

openSSLTestCA, Sep 20, 2008, trustedCertEntry,

Log out of the pr-1 host machine.

To Install and Configure Web Policy Agent 1 on Protected Resource 1

Before You Begin

The JAVA_HOME environment variable should be set to /opt/SUNWwbsvr/jdk/jre.

As a root user, log into the pr–1 host machine.

Create a directory into which you can download the Web Server agent bits and change into it.
# mkdir /export/WebPA1 # cd /export/WebPA1

Create a text file that contains the Agent Profile password.

The Web Policy Agent installer requires this for installation.
# cat > agent.pwd webagent1 Hit Control D to terminate the command ^D

Create a text file that contains the Agent Administrator password.

This text file should contain the OpenSSO Enterprise administrator (by default, amadmin) password. The Web policy agent installer requires this to create the agent profile on the server.
# cat > agentadm.pwd ossoadmin Hit Control D to terminate the command ^D

Download the web policy agent for Web Server from http://www.sun.com/download/.

# ls -al

total 7512
drwxr-xr-x   2 root     root         512 Jul 24 14:48 .
drwxr-xr-x  11 root     root         512 Jul 24 14:41 ..
-rw-r--r--   1 root     root          10 Jul 24 14:42 agent.pwd
-rw-r--r--   1 root     root           9 Jul 24 14:42 agentadm.pwd
-rw-r--r--   1 root     root     3826794 Jul 24 14:48 sjsws_v70_SunOS_sparc_agent_3.zip

Unzip the downloaded file.

# unzip sjsws_v70_SunOS_sparc_agent_3.zip

Run the agent installer.

# cd /export/WebPA1/web_agents/sjsws_agent/bin
# ./agentadmin --custom-install

When prompted, do the following.

Please read the following License 
Agreement carefully:

Press Enter and continue to press Enter until you have reached the end of the License Agreement.

Do you completely agree with all the terms and 
conditions of this License Agreement (yes/no): [no]:

Type yes and press Enter.

Enter the Sun Java System Web Server Config 
Directory Path [/var/opt/SUNWwbsvr7/
  https-pr-1.example.com/config]:

Type /opt/SUNWwbsvr/https-pr-1.example.com/config and press Enter.

Enter the OpenSSO Enterprise URL 
including the deployment URI 
(http://opensso.sample.com:58080/opensso)

Type https://lb-2.example.com:1081/opensso and press Enter.

Enter the Agent URL: 
(http://agent1.sample.com:1234)

Type http://pr-1.example.com:1080 and press Enter.

Enter the Encryption Key[WSpf7aqc3AFIGvf2mCqvNBOsf44cDrf3].

Accept the default value.

Enter the Agent profile name 
[UrlAccessAgent]:

Type webagent-1 and press Enter.

Enter the path to a file that contains the 
password to be used for identifying the Agent.

Type /export/WebPA1/agent.pwd and press Enter.

Note –

A warning message is displayed regarding the existence of the agent profile.

This Agent Profile does not exist in 
OpenSSO Enterprise, will 
it be created by the installer? (Agent 
Administror's name and password are required) 
[true)

Press Enter to accept the default and have the installer create the Agent Profile.

Enter the Agent Administrator's 
name:

Type amadmin and press Enter.

Enter the path to the password file 
that contains the password of the Agent 
Administrator.

Type /export/WebPA1/agentadm.pwd and press Enter.

-----------------------------------------
SUMMARY OF YOUR RESPONSES
-----------------------------------------------

Sun Java System Web Server Config Directory :
 /opt/SUNWwbsvr/https-pr-1.example.com/config
OpenSSO Server URL :
 https://lb-2.example.com:1081/opensso
Agent URL : http://pr-1.example.com:1080
Encryption Key :
 WSpf7aqc3AFIGvf2mCqvNBOsf44cDrf3
Agent Profile name : webagent-1
Agent Profile Password file name :
 /export/WebPA1/agent.pwd
Agent Profile will be created right now by 
 agent installer : true
Agent Administrator : amadmin
Agent Administrator's password file name :
 /export/WebPA1/agentadm.pwd

Verify your settings above and decide from 
the choices below.

  1. Continue with Installation
  2. Back to the last interaction
  3. Start Over
  4. Exit

Please make your selection [1]:

Type 1 and press Enter.

Restart the Web Server 1 instance.

# cd /opt/SUNWwbsvr/https-pr-1.example.com/bin 
# ./stopserv; ./startserv 

server has been shutdown
Sun Java System Web Server 7.0U3 B06/16/2008 12:00
info: CORE3016: daemon is running as super-user
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_15]
from [Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://pr-1.example.com:1080 ready to
accept requests
info: CORE3274: successful server startup

Use the following sub-procedure to verify that the Web Policy Agent 1 was successfully created.
1. Access https://osso-1.example.com:1081/opensso/console from a web browser.
2. Log in to the OpenSSO Enterprise console as the administrator.
  
  User Name:
  
  amadmin
  
  Password:
  
  ossoadmin
3. Under the Access Control tab, click / (Top Level Realm).
4. Click the Agents tab.
  
  By default, the Web tab is displayed. You should see webagent-1 under the Agent table.
5. Click webagent-1.
  
  The webagent-1 properties page is displayed.
6. Log out of the console and close the browser.

Remove the password files.

# cd /export/WebPA1
# rm agent.pwd
# rm agentadm.pwd

Log out of the pr-2 host machine.

To Configure Policy for Web Policy Agent 1 on Protected Resource 1

Use the OpenSSO Enterprise console to configure policy for Web Policy Agent 1 that will be used to verify that the agent is working properly.

Note –

You will add additional policies later when we add a load balancer in front of the Protected Resource 1 host machine.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Policies tab.

Click New Policy.

Enter URL Policy for Protected Resource 1 in the Name field.

Under Rules, click New.

The Rules properties page is displayed.

Select URL Policy Agent (with resource name) and click Next.

Provide the following information on the resulting page and click Finish.

Name:

URL Rule for Protected Resource 1

Resource Name:

http://pr-1.example.com:1080/*

GET

Mark this check box and verify that Allow is selected.

POST

Mark this check box and verify that Allow is selected.

The rule URL Rule for Protected Resource 1 is added to the list of Rules.

Under Subjects, click New.

The Subjects properties page is displayed.

Select Access Manager Identity Subject and click Next.

On the resulting page, provide the following information and click Search.

Name:

Test Subject

Filter:

Choose User and click Search to display a list of available users.

Available:

From the available users, select testuser1 and click Add.

Click Finish.

Click OK.

The new policy is included in the list of Policies.

Click Back to Access Control.

Log out of the console.

To Verify that Web Policy Agent 1 is Working Properly

Access http://pr-1.example.com:1080/index.html from a web browser.

Log in to OpenSSO Enterprise as testuser1.

Username

testuser1

Password

password

You should see the default index page for Web Server 1 as testuser1 was configured in the test policy to be allowed to access Protected Resource 1.

Log out and close the browser.

Once again, access http://pr-1.example.com:1080/index.html from a web browser.

Tip –
If you are not redirected to the OpenSSO Enterprise login page for authentication, clear your browser's cache and cookies and try again.

Log in to OpenSSO Enterprise as testuser2.

Username

testuser2

Password

password

You should see the message, You're not authorized to view this page, (or Your client is not allowed to access the requested object) as testuser2 was not included in the test policy that allows access to Protected Resource 1.

8.2.2 Installing Web Server and a Web Policy Agent on Protected Resource 2

Download the Sun Java System Web Server bits to the pr-2 host machine and install it. Additionally, download, install and configure the appropriate web policy agent. Use the following list of procedures as a checklist for completing the task.

To Install Web Server as Web Container 2 on Protected Resource 2

Sun Java System Web Server is the web container used on the pr-2 host machine.

Before You Begin

Read the latest version of the Web Server 7.0 Release Notes to determine if you need to install patches on the host machine. In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 119963–08, patch 120011–14, and patch 117461–08 are required.

As a root user, log into the pr-2 host machine.

Install the required patches if necessary.

Patch results for your machines might be different.
1. Run patchadd to see if the patch is installed.
  # patchadd -p | grep 117461–08
  A list of patch numbers is displayed. On our lab machine, the required patch 117461–08 is present so there is no need to install it.
  # patchadd -p | grep 119963–08
  No results are returned which indicates that the patch is not yet installed on the system.
  # patchadd -p | grep 120011-14
  No results are returned which indicates that the patch is not yet installed on the system.
2. Make a directory for downloading the patch you need and change into it.
  # mkdir /export/patches # cd /export/patches
3. Download the patches.
  
  You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
  
  Note –
  Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
4. Unzip the patch file.
  # unzip 119963–08.zip # unzip 120011–14.zip
5. Run patchadd to install the patches.
  # patchadd /export/patches/119963–08 # patchadd /export/patches/120011–14
6. After installation is complete, run patchadd to verify that the patch was added successfully.
  # patchadd -p | grep 119963–08
  In this example, a series of patch numbers are displayed, and the patch 119963–08 is present.
  # patchadd -p | grep 120011-14
  In this example, a series of patch numbers are displayed, and the patch 120011–14 is present.

Create a directory into which you can download the Web Server bits and change into it.
# mkdir /export/WS7 # cd /export/WS7

Download the Sun Java System Web Server 7.0 Update 3 software from http://www.sun.com/download/products.xml?id=45ad781d.

Follow the instructions on the Sun Microsystems Product Downloads web site for downloading the software.

Unpack the Web Server package.

# gunzip sjsws-7_0u3-solaris-sparc.tar.gz
# tar xvf sjsws-7_0u3-solaris-sparc.tar

Run setup.
# cd /export/WS7 # ./setup --console

When prompted, provide the following information.

Welcome to the Sun Java System Web 
Server 7.0u3 installation wizard.
...
You will be asked to specify preferences that 
determine how Sun Java System Web Server 7.0U3 
is installed and configured. 

The installation program pauses as questions 
are presented so you can read the 
information and make your choice. When you 
are ready to continue, press Enter. 
(Return on some keyboards.)

Press Enter. Continue to press Enter when prompted.

Have you read the Software License 
Agreement and do you accept all terms 
[no] {"," goes back, "!" exits}?

Enter yes.

Sun Java System Web Server 7.0 
Installation Directory [/sun/webserver7] 
{"," goes back, "!" exits} :

Enter /opt/SUNWwbsvr

Specified directory /opt/SUNWwbsvr 
does not exist. Create Directory? [Yes/No]
[yes] {"," goes back, "!" exits}

Enter yes.

Select Type of Installation

1. Express
2. Custom
3. Exit

What would you like to do? [1]
{"," goes back, "!" exits}

Enter 2.

Component Selection

1. Server Core
2. Server Core 64-biy Binaries
3. Administration Command Line Interface
4. Sample Applications
5. Language Pack

Enter the comma-separated list [1,2,3,4,5] 
{"," goes back, "!" exits}

Enter 1,3,5.

Java Configuration

Sun Java System Web Server 7.0 requires Java 
Se Development Kit (JDK). Provide the path 
to a JDK 1.5.0_15 or greater.

1. Install Java SE Development Kit (JDK) 1.5.0_15
2. Reuse existing Java SE Development Kit 
   (JDK) 1.5.0_15
3. Exit

What would you like to do? [1] 
{"," goes back, "!" exits}

Enter 1.

Administrative Options

1. Create an Administration Server and a 
   Web Server Instance
2. Create an Administration Node

Enter your option. [1]
{"," goes back, "!" exits}

Enter 1.

Create SMF services for server instances 
[yes/no] [no] {"," goes back, "!" exits}

Accept the default value.

Host Name [pr-2.example.com] 
{"," goes back, "!" exits}

Accept the default value.

SSL Port [8989] 
{"," goes back, "!" exits}

Accept the default value.

Create a non-SSL Port? [yes/no] [no] 
{"," goes back, "!" exits}

Enter no.

Runtime User ID [root] 
{"," goes back, "!" exits}

Accept the default value (for the administration server).

Administrator User Name [admin]
{"," goes back, "!" exits}

Accept the default value.

Administrator Password:

Enter web4dmin.

Retype Password:

Enter web4dmin.

Server Name [pr-2.example.com] 
{"," goes back, "!" exits}

Accept the default value.

Http Port [8080] 
{"," goes back, "!" exits}

Enter 1080.

Runtime User ID [webserverd] 
{"," goes back, "!" exits}

Enter root (for the instance).

Document Root Directory [/opt/SUNWwbsvr/
https-pr-2.example.com/docs] 
{"," goes back, "!" exits}

Accept the default value.

Start Administration Server [yes/no] 
[yes] {"," goes back, "!" exits}

Enter no.

Ready To Install

1. Install Now
2. Start Over
3. Exit Installation

What would you like to do [1] 
{"," goes back, "!" exits}?

Enter1.

When installation is complete, the following message is displayed:

Installation Successful.

Start the Web Server administration server.

# cd /opt/SUNWwbsvr/admin-server/bin
# ./startserv

Run netstat to verify that the port is open and listening.

# netstat -an | grep 8989

*.8989               *.*                0      0 49152      0 LISTEN

(Optional) Login to the Web Server administration console at https://pr-2.example.com:8989 as the administrator.

Username

admin

Password

web4dmin

You should see the Web Server administration console.

(Optional) Log out of the Web Server console and close the browser.

Start the Protected Resource 2 Web Server instance.

# cd /opt/SUNWwbsvr/https-pr-2.example.com/bin
# ./startserv

Sun Java System Web Server 7.0U3 B06/16/2008 12:00
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_15] from
[Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://pr-2.example.com:1080 ready to
accept requests
info: CORE3274: successful server startup

Run netstat to verify that the port is open and listening.

# netstat -an | grep 1080

*.1080               *.*                0      0 49152      0 LISTEN

(Optional) Access the Protected Resource 2 instance at http://pr-2.example.com:1080 using a web browser.

You should see the default Web Server index page.

Log out of the pr–2 host machine.

To Import the Certificate Authority Root Certificate into Web Server 2

The web policy agent on Protected Resource 2 connects to OpenSSO Enterprise through Load Balancer 2. The load balancer is SSL-enabled, so the agent must be able to trust the load balancer SSL certificate to establish the SSL connection. For this reason, import the root certificate of the Certificate Authority (CA) that issued the Load Balancer 2 SSL server certificate into the policy agent certificate store.

Before You Begin

Copy the same CA root certificate used in To Install a CA Root Certificate to the OpenSSO Enterprise Load Balancer to the pr-2 host machine. In this example, the file is /export/software/ca.cer.
Backup cacerts before modifying it.

As a root user, log into the pr-2 host machine.

Import ca.cer, the CA root certificate, into cacerts, the certificate store.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import -trustcacerts 
-alias OpenSSLTestCA -file /export/software/ca.cer 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit

Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun,
O=Sun,L=Santa Clara, ST=California C=US
Serial number: f59cd13935f5f498
Valid from: Thu Sep 20 11:14:51 PDT 2008 18 07:66:19 PDT 2006 
until: Thu Jun 17 11:41:51 PDT 2010
Certificate fingerprints:
MD5: 78:7D:F0:04:8A:5B:5D:63:F5:EC:5B:21:14:9C:8A:B9
SHA1: A4:27:8A:B0:45:7A:EE:16:31:DC:E5:32:46:61:9E:B8:A3:20:8C:BA

Trust this certificate: [no] yes

Certificate was added to keystore.

Verify that ca.cer was imported.

# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list 
-keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts 
-storepass changeit | grep -i open

openSSLTestCA, Sep 20, 2008, trustedCertEntry,

Log out of the pr-2 host machine.

To Install and Configure Web Policy Agent 2 on Protected Resource 2

Before You Begin

The JAVA_HOME environment variable should be set to /opt/SUNWwbsvr/jdk/jre.

As a root user, log into the pr–2 host machine.

Create a directory into which you can download the Web Server agent bits and change into it.
# mkdir /export/WebPA2 # cd /export/WebPA2

Create a text file that contains the Agent Profile password.

The Web Policy Agent installer requires this for installation.
# cat > agent.pwd webagent2 Hit Control D to terminate the command ^D

Create a text file that contains the Agent Administrator password.

This text file should contain the OpenSSO Enterprise administrator (by default, amadmin) password. The Web Policy Agent installer requires this to create the agent profile on the server.
# cat > agentadm.pwd ossoadmin Hit Control D to terminate the command ^D

Download the web policy agent for Web Server from http://www.sun.com/download/.

# ls -al

total 7512
drwxr-xr-x   2 root     root         512 Jul 24 14:48 .
drwxr-xr-x  11 root     root         512 Jul 24 14:41 ..
-rw-r--r--   1 root     root          10 Jul 24 14:42 agent.pwd
-rw-r--r--   1 root     root           9 Jul 24 14:42 agentadm.pwd
-rw-r--r--   1 root     root     3826794 Jul 24 14:48 sjsws_v70_SunOS_sparc_agent_3.zip

Unzip the downloaded file.

# unzip sjsws_v70_SunOS_sparc_agent_3.zip

Run the agent installer.

# cd /export/WebPA2/web_agents/sjsws_agent/bin
# ./agentadmin --custom-install

When prompted, do the following.

Please read the following License 
Agreement carefully:

Press Enter and continue to press Enter until you have reached the end of the License Agreement.

Do you completely agree with all the terms and 
conditions of this License Agreement (yes/no): [no]:

Type yes and press Enter.

Enter the Sun Java System Web Server Config 
Directory Path [/var/opt/SUNWwbsvr7/
  https-pr-2.example.com/config]:

Type /opt/SUNWwbsvr/https-pr-2.example.com/config and press Enter.

Enter the OpenSSO Enterprise URL 
including the deployment URI 
(http://opensso.sample.com:58080/opensso)

Type https://lb-2.example.com:1081/opensso and press Enter.

Enter the Agent URL: 
(http://agent2.sample.com:1234)

Type http://pr-2.example.com:1080 and press Enter.

Enter the Encryption Key [WSpf7aqc3AFIGvf2mCqvNBOsf44cDrf3].

Accept the default value.

Enter the Agent profile name 
[UrlAccessAgent]:

Type webagent-2 and press Enter.

Enter the path to a file that contains the 
password to be used for identifying the Agent.

Type /export/WebPA2/agent.pwd and press Enter.

Note –

A warning message is displayed regarding the existence of the agent profile.

This Agent Profile does not exist in 
OpenSSO Enterprise, will 
it be created by the installer? (Agent 
Administror's name and password are required) 
[true)

Press Enter to accept the default and have the installer create the Agent Profile.

Enter the Agent Administrator's 
name:

Type amadmin and press Enter.

Enter the path to the password file 
that contains the password of the Agent 
Administrator.

Type /export/WebPA2/agentadm.pwd and press Enter.

-----------------------------------------
SUMMARY OF YOUR RESPONSES
-----------------------------------------------

Sun Java System Web Server Config Directory :
 /opt/SUNWwbsvr/https-pr-2.example.com/config
OpenSSO Server URL :
 https://lb-2.example.com:1081/opensso
Agent URL : http://pr-2.example.com:1080
Encryption Key :
 WSpf7aqc3AFIGvf2mCqvNBOsf44cDrf3
Agent Profile name : webagent-2
Agent Profile Password file name :
 /export/WebPA2/agent.pwd
Agent Profile will be created right now by 
 agent installer : true
Agent Administrator : amadmin
Agent Administrator's password file name :
 /export/WebPA2/agentadm.pwd

Verify your settings above and decide from 
the choices below.

  1. Continue with Installation
  2. Back to the last interaction
  3. Start Over
  4. Exit

Please make your selection [1]:

Type 1 and press Enter.

Restart the Web Server 2 instance.

# cd /opt/SUNWwbsvr/https-pr-2.example.com/bin 
# ./stopserv; ./startserv 

server has been shutdown
Sun Java System Web Server 7.0U3 B06/16/2008 12:00
info: CORE3016: daemon is running as super-user
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_15]
from [Sun Microsystems Inc.]
info: HTTP3072: http-listener-1: http://pr-2.example.com:1080 ready to
accept requests
info: CORE3274: successful server startup

Use the following sub-procedure to verify that the Web Policy Agent 2 was successfully created.
1. Access https://osso-1.example.com:1081/opensso/console from a web browser.
2. Log in to the OpenSSO Enterprise console as the administrator.
  
  User Name:
  
  amadmin
  
  Password:
  
  ossoadmin
3. Under the Access Control tab, click / (Top Level Realm).
4. Click the Agents tab.
  
  By default, the Web tab is displayed. You should see webagent-2 under the Agent table.
5. Click webagent-2.
  
  The webagent-2 properties page is displayed.
6. Log out of the console and close the browser.

Remove the password files.

# cd /export/WebPA2
# rm agent.pwd
# rm agentadm.pwd

Log out of the pr-2 host machine.

To Configure Policy for Web Policy Agent 2 on Protected Resource 2

Use the OpenSSO Enterprise console to configure policy for Web Policy Agent 2 that will be used to verify that the agent is working properly.

Note –

You will add additional policies later when we add a load balancer in front of the Protected Resource 2 host machine.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Policies tab.

Click New Policy.

Enter URL Policy for Protected Resource 2 in the Name field.

Under Rules, click New.

The Rules properties page is displayed.

Select URL Policy Agent (with resource name) and click Next.

Provide the following information on the resulting page and click Finish.

Name:

URL Rule for Protected Resource 2

Resource Name:

http://pr-2.example.com:1080/*

GET

Mark this check box and verify that Allow is selected.

POST

Mark this check box and verify that Allow is selected.

The rule URL Rule for Protected Resource 2 is added to the list of Rules.

Under Subjects, click New.

The Subjects properties page is displayed.

Select Access Manager Identity Subject and click Next.

On the resulting page, provide the following information and click Search.

Name:

Test Subject

Filter:

Choose User and click Search to display a list of available users.

Available:

From the available users, select testuser1 and click Add.

Click Finish.

Click OK.

The new policy is included in the list of Policies.

Click Back to Access Control.

Log out of the console.

To Verify that Web Policy Agent 2 is Working Properly

Access http://pr-2.example.com:1080/index.html from a web browser.

Log in to OpenSSO Enterprise as testuser1.

Username

testuser1

Password

password

You should see the default index page for Web Server 2 as testuser1 was configured in the test policy to be allowed to access Protected Resource 2.

Log out and close the browser.

Once again, access http://pr-2.example.com:1080/index.html from a web browser.

Tip –
If you are not redirected to the OpenSSO Enterprise login page for authentication, clear your browser's cache and cookies and try again.

Log in to OpenSSO Enterprise as testuser2.

Username

testuser2

Password

password

You should see the message, You're not authorized to view this page, (or Your client is not allowed to access the requested object) as testuser2 was not included in the test policy that allows access to Protected Resource 2.

8.2.3 Configuring the Web Policy Agents to Access the Distributed Authentication User Interface

Configure the web policy agents to point to the secure port of the Distributed Authentication User Interface Load Balancer 3. Use the following list of procedures as a checklist to complete the task.

To Configure the Web Policy Agent 1 to Access the Distributed Authentication User Interface

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the Web tab.

webagent-1 is displayed under the Agent table.

Click webagent-1.

The webagent-1 properties page is displayed.

Click the OpenSSO Services tab.

The Services properties page is displayed.

Make the following changes to the OpenSSO Login URL value and click Save.
- Select https://lb-2.example.com:1081/opensso/UI/Login and click Remove.
- Enter https://lb-3.example.com:1443/distAuth/UI/Login and click Add.

Log out of the OpenSSO Enterprise console.

Verify that the agent is configured properly using the following sub procedure.
1. Access http://pr-1.example.com:1080/index.html from a web browser.
  
  You are redirected to the Distributed Authentication User Interface at https://lb-3.example.com:1443/distAuth/UI/Login.
2. (Optional) Double-click the gold lock in the lower left corner of the browser.
  
  In the Properties page, you see the certificate for lb-3.example.com.
3. Log in to OpenSSO Enterprise as testuser1.
  
  Username
  
  testuser1
  
  Password
  
  password
  
  The default index page for Web Server 1 is displayed as testuser1 is defined in the test policy as having permission to access Protected Resource 1.
4. Close the browser.

To Configure the Web Policy Agent 2 to Access the Distributed Authentication User Interface

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the Web tab.

webagent-2 is displayed under the Agent table.

Click webagent-2.

The webagent-2 properties page is displayed.

Click the OpenSSO Services tab.

The Services properties page is displayed.

Make the following changes to the OpenSSO Login URL value and click Save.
- Select [0]=https://lb-2.example.com:1081/opensso/UI/Login and click Remove.
- Enter [0]=https://lb-3.example.com:1443/distAuth/UI/Login and click Add.

Log out of the OpenSSO Enterprise console.

Verify that the agent is configured properly using the following sub procedure.
1. Access http://pr-2.example.com:1080/index.html from a web browser.
  
  You are redirected to the Distributed Authentication User Interface at https://lb-3.example.com:1443/distAuth/UI/Login.
2. (Optional) Double-click the gold lock in the lower left corner of the browser.
  
  In the Properties page, you see the certificate for lb-3.example.com.
3. Log in to OpenSSO Enterprise as testuser1.
  
  Username
  
  testuser1
  
  Password
  
  password
  
  The default index page for Web Server 2 is displayed as testuser1 is defined in the test policy as having permission to access Protected Resource 2.
4. Close the browser.

Chapter 9 Setting Up Load Balancers for the Policy Agents

Two load balancers are configured for the policy agents in this deployment example. Load Balancer 4 balances traffic passing through the web policy agents. Load Balancer 5 balances traffic passing through the J2EE policy agents. Both load balancers are configured for simple persistence. Simple persistence guarantees that requests from the same user session will always be sent to the same policy agent that initially validated the user session and evaluated the applicable policies. This chapter contains the following sections.

9.1 Configuring the Web Policy Agents Load Balancer

Load Balancer 4 handles traffic for the web policy agents, and is configured for simple persistence.

Note –

From a performance perspective, each policy agent validates user sessions and evaluates applicable policies. The results of those actions are cached by the policy agent that performed them. If simple persistence is not set, each agent builds its own cache, effectively doubling the workload on the OpenSSO Enterprise servers, and cutting overall system capacity. The problem will become more acute as the number of policy agents increases. In situations where each web policy agent instance is protecting identical resources, some form of load balancer persistence is highly recommended for these reasons. Although the actual type of persistence may vary when a different load balancer is used, it should achieve the goal of sending requests from the same user session to the same policy agent.

Note –

When firewalls are configured, Load Balancer 4 can be located in a less secure zone.

Use the following list of procedures as a checklist for configuring the web policy agents' load balancer:

To Configure the Web Policy Agents Load Balancer

Before You Begin

The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.

Access https://is-f5.example.com, the Big IP load balancer login page, from a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

Create a Pool.

A pool contains all the backend server instances.
1. In the left pane, click Pools.
2. On the Pools tab, click Add.
3. In the Add Pool dialog, provide the following information:
  
  Pool Name
  
  WebAgent-Pool
  
  Load Balancing Method
  
  Round Robin
  
  Resources
  
  Add the IP address and port number of both Protected Resource host machines: pr-1:1080 and pr-2:1080.
4. Click Done.

Add a Virtual Server.

The virtual server presents an address to the outside world and, when users attempt to connect, it would forward the connection to the most appropriate real server.

Tip –
If you encounter JavaScript^TM errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer.
1. In the left frame, click Virtual Servers.
2. On the Virtual Servers tab, click Add.
3. In the Add a Virtual Server dialog box, provide the following information:
  
  Address
  
  Enter the IP address for lb-4.example.com
  
  Service
  
  90
4. Continue to click Next until you reach the Pool Selection dialog box.
5. In the Pool Selection dialog box, assign the WebAgent-Pool Pool.
6. Click Done.

Add Monitors.

Monitors are required for the load balancer to detect the backend server failures.
1. In the left frame, click Monitors.
2. Click Add.
  
  In the Add Monitor dialog provide the following information:
  
  Name:
  
  WebAgent-http
  
  Inherits From:
  
  Choose http.
3. Click Next.
4. On the resulting Configure Basic Properties page, click Next.
5. In the Send String field under Configure ECV HTTP Monitor, enter GET /monitor.html and click Next.
6. On the Destination Address and Service (Alias) page, click Done.
  
  The monitor just added is in the list of monitors under the Monitors tab.
7. Click the Basic Associations tab.
8. Mark the Add checkbox next to the IP addresses for pr-1:1080 and pr-2:1080.
9. At the top of the Node column, choose the monitor that you just added, WebAgent-http.
10. Click Apply.

Configure the load balancer for simple persistence.

All requests sent within a specified interval from the same user are routed to the same agent. This significantly reduces the number of agent requests sent to OpenSSO Enterprise for validation thus reducing the load on the servers.

Note –
Simple persistence tracks connections based on the client IP address only, returning a client to the same node to which it connected previously.
1. In the left frame, click Pools.
2. Click the WebAgent-Pool link.
3. Click the Persistence tab.
4. Under Persistence Type, select the Simple.
5. Set the timeout interval.
  
  In the Timeout field, enter 300 seconds.
6. Click Apply.

Log out of the console.

To Create a Monitoring File on Each Host Machine for Load Balancer 4

In order to configure the web policy agents to point to Load Balancer 4, create a file to be used by Load Balancer 4 for monitoring and modify the web agent properties — adding Load Balancer 4 as the virtual host. Instructions on how to create a monitoring file are in the following procedure. Instructions on how to modify the web agent properties are in To Add Load Balancer 4 as a Virtual Host by Modifying the Web Policy Agent Properties.

Note –

We can alternately use the default Web Server index.html rather than create monitor.html but in this deployment, index.html is used to represent the resource protected by the web policy agent.

As a root user, log in to the pr–1 host machine.

Change to the config directory.

# cd /opt/SUNWwbsvr/https-pr-1.example.com/docs

Create a monitor.html file to be used by the load balancer.

# cat > monitor.html

<HTML>
</HTML>

Hit Control D to terminate the command

^D

Run the tail command.
# cd /opt/SUNWwbsvr/https-pr-1.example.com/logs # tail -f access
If you see frequent entries similar to the one below, the custom monitor is configured properly.
IP_address - - [30/Jul/2008:13:59:48 -0700] "GET /monitor.html" 200 15
Tip –
If you do not see "GET /monitor.html", troubleshoot the load balancer configuration.

Log out of the pr–1 host machine.

As a root user, log in to the pr–2 host machine.

Change to the config directory.

# cd /opt/SUNWwbsvr/https-pr-2.example.com/docs

Create a monitor.html file to be used by the load balancer.

# cat > monitor.html

<HTML>
</HTML>

Hit Control D to terminate the command

^D

Run the tail command.
# cd /opt/SUNWwbsvr/https-pr-2.example.com/logs # tail -f access
If you see frequent entries similar to the one below, the custom monitor is configured properly.
IP_address - - [30/Jul/2008:13:59:48 -0700] "GET /monitor.html" 200 15
Tip –
If you do not see "GET /monitor.html", troubleshoot the load balancer configuration.

Log out of the pr–2 host machine.

To Add Load Balancer 4 as a Virtual Host by Modifying the Web Policy Agent Properties

Before You Begin

This procedure assumes you have completed To Create a Monitoring File on Each Host Machine for Load Balancer 4.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the Web tab.

webagent-1 and webagent-2 is displayed under the Agent table.

Click webagent-1

The Global tab is displayed.

Enter a value for the FQDN Virtual Host Map and click Add.

The value is the name of the host machine in which Load Balancer 4 is installed.

Map Key

valid

Corresponding Map Value

lb-4.example.com

Click Save.

Click the Application tab.

The Application properties page is displayed.

On the resulting page, provide values for Not Enforced URL Processing.

Enter each of the following and click Add.
http://lb-4.example.com:90/monitor.html http://pr-1.example.com:1080/monitor.html

Click Save.

Click Back to Main Page.

Click webagent-2

The Global tab is displayed.

Enter a value for the FQDN Virtual Host Map and click Add.

The value is the name of the host machine in which Load Balancer 4 is installed.

Map Key

valid.

Corresponding Map Value

lb-4.example.com

Click Save.

Click the Application tab.

The Application properties page is displayed.

On the resulting page, provide values for Not Enforced URL Processing.

Enter each of the following and click Add.
http://lb-4.example.com:90/monitor.html http://pr-2.example.com:1080/monitor.html

Click Save.

Click Back to Main Page.

Log out of the OpenSSO Enterprise console and close the browser.

To Configure Policy for the Web Policy Agents

Use the OpenSSO Enterprise console to configure policy for the web policy agents. The policies you create here are used in To Verify the Web Policy Agents Load Balancer Configuration is Working Properly.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Policies tab.

Click New Policy.

The New Policy page is displayed.

On the New Policy page, enter URL Policy for LoadBalancer-4 in the Name field.

Click New under Rules.

The New Rules page is displayed.

On the New Rules page, accept the default URL Policy Agent (with resource name) and click Next.

On the resulting page, provide the following information.

Name:

Rule for LoadBalancer-4.

Resource Name:

http://lb-4.example.com:90/*

GET

Mark this checkbox and verify that Allow is selected.

POST

Mark this checkbox and verify that Allow is selected.

Click Finish.

The New Policy page is displayed again.

On the New Policy page, click New under Subjects.

The New Subjects page is displayed.

On the New Subjects page, verify that Access Manager Identity Subject is selected and click Next.

On the resulting page, provide the following information.

Name

Subject for LoadBalancer-4.

Filter

From the drop-down list, select User and click Search. The search returns a list of available users.

Available

From the generated User list, select testuser1 and click Add. testuser1 is displayed in the Selected List.

Click Finish.

The New Policy page is displayed again.

On the New Policy page, click OK.

The completed policy is now included in the list of Policies.

Log out of the OpenSSO Enterprise console and close the browser.

To Verify the Web Policy Agents Load Balancer Configuration is Working Properly

Access http://lb-4.example.com:90/index.html, the OpenSSO Enterprise load balancer, from a web browser.

Log in to OpenSSO Enterprise as testuser1.

Username

testuser1

Password

password

If the default Web Server index.html page is displayed, the load balancer is configured properly.

Close the browser.

Access the OpenSSO Enterprise load balancer at http://lb-4.example.com:90/index.html from a web browser again.

Tip –
If not redirected to the OpenSSO Enterprise login page for authentication, clear your browser's cache and cookies and try again.

Log in to OpenSSO Enterprise as testuser2.

Username

testuser2

Password

password

You should see the message You're not authorized to view this page or Your client is not allowed to access the requested object as testuser2 was not included in the test policy.

9.2 Configuring the J2EE Policy Agents Load Balancer

To Configure the J2EE Policy Agents Load Balancer

Before You Begin

Access https://is-f5.example.com, the Big IP load balancer login page, from a web browser.

Click Configure your BIG-IP (R) using the Configuration Utility.

Create a Pool.

A pool contains all the backend server instances.
1. In the left pane, click Pools.
2. On the Pools tab, click Add.
3. In the Add Pool dialog, provide the following information:
  
  Pool Name
  
  J2EEAgent-Pool
  
  Load Balancing Method
  
  Round Robin
  
  Resources
  
  Add the Application Server IP addresses and port numbers: pr-1:1081 and pr-2:1081.
4. Click Done.
5. In the List of Pools, click J2EEAgent-Pool.
6. Click the Persistence tab and provide the following information:
  
  Persistence Type:
  
  Choose Active Http Cookie
  
  Note –
  Active Http Cookie persistence uses an HTTP cookie stored on a client computer to allow the client to reconnect to the same server previously visited.
  
  Method:
  
  Choose Insert
7. Click Apply.

Add a Virtual Server.

The virtual server presents an address to the outside world and, when users attempt to connect, it would forward the connection to the most appropriate real server.

Note –
If you encounter JavaScript errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer for this step.
1. In the left frame, click Virtual Servers.
2. On the Virtual Servers tab, click Add.
3. In the Add a Virtual Server dialog box, provide the following information:
  
  Address
  
  Enter the IP address for lb-5.example.com
  
  Services Port
  
  91
4. Continue to click Next until you reach the Pool Selection dialog box.
5. In the Pool Selection dialog box, assign the J2EEAgent-Pool pool.
6. Click Done.

Add Monitors.

Monitors are required for the load balancer to detect the backend server failures.
1. Click Monitors in the left frame.
2. Click the Basic Associations tab.
3. Mark the Add checkbox for the IP address for pr–1:1081 and pr–2:1081.
4. At the top of the Node column, select tcp.
5. Click Apply.

Log out of the load balancer console.

To Add Load Balancer 5 as a Virtual Host by Modifying the J2EE Policy Agent Properties

In order to configure the J2EE policy agents to point to Load Balancer 5, modify the J2EE agent properties — adding Load Balancer 5 as the virtual host.

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Under the Access Control tab, click / (Top Level Realm).

Click the Agents tab.

Click the J2EE tab.

j2eeagent-1 and j2eeagent-2 are displayed under the Agent table.

Click j2eeagent-1

The Global tab is displayed.

Enter a key and value for the FQDN Virtual Host Map and click Add.

The key and the value is the name of the host machine in which Load Balancer 5 is installed.

Map Key

lb-5.example.com.

Corresponding Map Value

lb-5.example.com

Click Save.

Click Back to Main Page.

Click j2eeagent-2

The Global tab is displayed.

Enter a key and value for the FQDN Virtual Host Map and click Add.

The key and the value is the name of the host machine in which Load Balancer 5 is installed.

Map Key

lb-5.example.com.

Corresponding Map Value

lb-5.example.com

Click Save.

Click Back to Main Page.

To Configure Policy for the J2EE Policy Agents

The policies you create here are used in To Verify the J2EE Policy Agent Load Balancer Configuration is Working Properly.

Before You Begin

This procedure assumes that you have just completed To Add Load Balancer 5 as a Virtual Host by Modifying the J2EE Policy Agent Properties and are still logged into the OpenSSO Enterprise console.

Under the Access Control tab, click / (Top Level Realm).

Click the Policies tab.

Click New Policy.

The New Policy page is displayed.

On the New Policy page, enter URL Policy for LoadBalancer-5 in the Name field.

Click New under Rules.

The New Rules page is displayed.

On the New Rules page, accept the default URL Policy Agent (with resource name) and click Next.

On the resulting page, provide the following information.

Name:

Rule for LoadBalancer-5.

Resource Name:

http://lb-5.example.com:91/*

GET

Mark this checkbox and verify that Allow is selected.

POST

Mark this checkbox and verify that Allow is selected.

Click Finish.

On the New Policy page again, under Subjects, click New.

On the resulting page, verify that Access Manager Identity Subject is selected, and click Next.

On the resulting page, provide the following information:

Name:

LoadBalancer-5_Groups

Filter:

In the drop-down list, select Group and click Search.

The search returns a list of available groups.

Select Employee-Group and Manager-Group and click Add.

The Employee-Group and Manager-Group groups are in the Selected List.

Click Finish.

On the resulting page, click OK.

The created policy is displayed in the list of Policies.

Log out of the OpenSSO Enterprise console and close the browser.

To Verify the J2EE Policy Agent Load Balancer Configuration is Working Properly

Access http://lb-5.example.com:91/agentsample/index.html from a web browser.

The Sample Application welcome page is displayed.

Click the J2EE Declarative Security link.

On the resulting page click Invoke the Protected Servlet.

The policy agent redirects to the OpenSSO Enterprise login page.

Log in to OpenSSO Enterprise as testuser1.

Username

testuser1

Password

password

If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, this first part of the test succeeded and authentication is working as expected.

Click the J2EE Declarative Security link to return.

On the resulting page, click Invoke the Protected Servlet.

If the Successful Invocation message is displayed, this second part of the test has succeeded and the sample policy for the employee role has been enforced as expected.

Close the browser.

Open a new browser and access http://lb-5.example.com:91/agentsample/index.html.

The Sample Application welcome page is displayed.

Click the J2EE Declarative Security link.

On the resulting page click Invoke the Protected Servlet.

The policy agent redirects to the OpenSSO Enterprise login page.

Log in to OpenSSO Enterprise as testuser2.

Username

testuser2

Password

password

If the Access to Requested Resource Denied message is displayed, this third part of the test succeeded and the sample policy for the manager role has been enforced as expected.

Click the J2EE Declarative Security link to return.

On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.

If the Successful Invocation message is displayed, the sample policy for the employee role has been enforced as expected.

Close the browser.

Chapter 10 Implementing Session Failover

Sun OpenSSO Enterprise provides a web container-independent session failover feature that uses Sun Java™ System Message Queue, a messaging middleware product that enables distributed applications to communicate and exchange data by sending and receiving messages. OpenSSO Enterprise uses Message Queue as a communications broker, and the BerkeleyDB by Sleepycat Software, Inc. for backend session store databases. This chapter contains the following sections:

10.1 Session Failover Architecture

When session failover is implemented for OpenSSO Enterprise, session information is replicated in two backend session store databases. This ensures that if one OpenSSO Enterprise server fails or stops, the information stored in the backend session databases can be used to keep the user continuously authenticated. If session failover is not implemented and the OpenSSO Enterprise server in which a user's session was created fails, the user will have to reauthenticate to perform an operation that requires a session token.

Note –

For more information about OpenSSO Enterprise and session failover, see Chapter 7, Implementing OpenSSO Enterprise Session Failover, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

10.2 Installing the Session Failover Components

Install the OpenSSO Enterprise session failover components on the mq-1 host machine and the mq-2 host machine. Use the following list of procedures as a checklist for completing the task.

To Install Session Failover Components on Message Queue 1

As a root user, log in to the mq–1 host machine.

Create a directory into which the Message Queue and Berkeley Database bits can be downloaded and change into it.
# mkdir /export/SFO # cd /export/SFO

Copy ssoSessionTools.zip from the osso–1 host machine to the mq–1 host machine.

ssoSessionTools.zip is included in the opensso_enterprise_80.zip file downloaded in To Generate an OpenSSO Enterprise WAR on the OpenSSO Enterprise 1 Host Machine under the tools directory.

Unzip ssoSessionTools.zip.

# cd /export/SFO
# unzip ssoSessionTools.zip -d ssoSessionTools

Modify the permissions on the setup script and run it to initialize the session failover tools.
# cd /export/SFO/ssoSessionTools # chmod +x setup # ./setup

When prompted, enter opensso as the Directory to install the scripts (example: opensso).

Note –
The directory location should be relative to the current directory.

When the script is finished, the following messages are displayed:
The scripts are properly setup under directory /export/SFO/ssoSessionTools/opensso JMQ is properly setup under directory /export/SFO/ssoSessionTools/jmq

Change to the bin directory.

# cd /export/SFO/ssoSessionTools/jmq/mq/bin

Run the imqbrokerd command to create a new broker instance named msgqbroker.
# ./imqbrokerd -name msgqbroker -port 7777 &

Run netstat to verify that the new Message Queue broker instance is up and running.
# netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN

Add a new user named msgquser.

This user will connect to the Message Queue broker instance on servers where Message Queue is installed. This user will be used only for session failover purposes, and does not assume the privileges of the guest user. It is a good practice to create a custom user for such purposes, and not to rely on the known user accounts or default user accounts to help prevent brute force or DOS attacks.
# ./imqusermgr add -u msgquser -g admin -p m5gqu5er -i msgqbroker User repository for broker instance: msgqbroker User msgquser successfully added.

Disable the guest user.

This step ensures that the guest user will not be able to access the OpenSSO Enterprise server.

# ./imqusermgr update -u guest -a false -i msgqbroker

User repository for broker instance: msgqbroker

Are you sure you want to update user guest? (y/n) y

User guest successfully updated.

Modify the amsfo.conf file.

amsfo.conf has parameters that are consumed by the OpenSSO Enterprise session failover startup script, amsfo.
1. Change to the lib directory.
  # cd /export/SFO/ssoSessionTools/opensso/config/lib
  Tip –
  Backup amsfo.conf before you modify it.
2. Set the following properties:
  CLUSTER_LIST=mq-1.example.com:7777,mq-2.example.com:7777 BROKER_INSTANCE_NAME=msgqbroker USER_NAME=msgquser BROKER_PORT=7777
  Note –
  The port used for BROKER_PORT should be the same as the one used in the value of the CLUSTER_LIST.
3. Save the file and close it.

Generate an encrypted password in a .password file with the following sub procedure.
1. Change to the bin directory.
  # cd /export/SFO/ssoSessionTools/opensso/bin
2. Run amsfopassword.
  
  This command generates an encrypted password, creates a new file named .password, and stores the encrypted password in the new file.
  
  Caution –
  amsfopassword creates the .password file in a default location based on where the scripts were installed. If a different location is used, the PASSWORDFILE property in amsfo.conf should be changed accordingly.
  # ./amsfopassword -e m5gqu5er -f /export/SFO/ssoSessionTools/opensso/.password os.name=SunOS SUCCESSFUL
3. (Optional) View the encrypted password for verification.
  # more /export/SFO/ssoSessionTools/opensso/.password M27OGb6U4ufRu+oWAzBdWw==

(Optional) Modify the amsessiondb script if necessary.

The amsessiondb script (located in the /export/SFO/ssoSessionTools/opensso/bin directory) starts the Berkeley Database client, creates the database, and sets specific database values. It is called when the amsfo script is run for the first time. The amsessiondb script contains variables that specify default paths and directories. If any of the following components are not installed in their default directories, edit the amsessiondb script to set the variables to the correct locations.
JAVA_HOME=/usr/jdk/entsys-j2se IMQ_JAR_PATH=/export/SFO/ssoSessionTools/jmq/mq/lib JMS_JAR_PATH=/export/SFO/ssoSessionTools/jmq/mq/lib AM_HOME=/export/SFO/ssoSessionTools
Tip –
Backup amsessiondb before you modify it.

Restart the session failover components with the following sub procedure.
1. Change to the bin directory.
  # cd /export/SFO/ssoSessionTools/jmq/mq/bin
2. Stop the Message Queue instance using the product's command line interface.
  
  See the Message Queue documentation for more information.
3. Run the netstat command to verify that the mq-1 broker instance is stopped.
  # netstat -an | grep 7777
  If netstat returns no result, the mq-1 broker instance is stopped.
  
  Tip –
  If the mq-1 broker instance is not stopped, kill the process using the following procedure.
  1. Get the Java process IDs.
    # ps -ef | grep java
  2. Kill the Java process IDs that were returned.
    # kill -9 #### ####
  3. Run netstat again.
4. Restart the mq-1 broker instance.
  # cd /export/SFO/ssoSessionTools/opensso/bin # ./amfso start
5. Run the netstat command to verify that the Message Queue port is open and listening.
  # netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN

Log out of the mq-1 host machine.

To Install Session Failover Components on Message Queue 2

As a root user, log in to the mq–2 host machine.

Create a directory into which the Message Queue and Berkeley Database bits can be downloaded and change into it.
# mkdir /export/SFO # cd /export/SFO

Copy ssoSessionTools.zip from the osso–1 host machine to the mq–2 host machine.

Note –
ssoSessionTools.zip is included in the opensso_enterprise_80.zip file downloaded in To Generate an OpenSSO Enterprise WAR on the OpenSSO Enterprise 1 Host Machine under the tools directory.

Unzip ssoSessionTools.zip.

# cd /export/SFO
# unzip ssoSessionTools.zip -d ssoSessionTools

Modify the permissions on the setup script and run it to initialize the session failover tools.
# cd /export/SFO/ssoSessionTools # chmod +x setup # ./setup

When prompted, enter opensso as the Directory to install the scripts (example: opensso).

Note –
The directory location should be relative to the current directory.

When the script is finished, the following messages are displayed:
The scripts are properly setup under directory /export/SFO/ssoSessionTools/opensso JMQ is properly setup under directory /export/SFO/ssoSessionTools/jmq

Change to the bin directory.

# cd /export/SFO/ssoSessionTools/jmq/mq/bin

Run the imqbrokerd command to create a new broker instance named msgqbroker.
# ./imqbrokerd -name msgqbroker -port 7777 &

Run netstat to verify that the new Message Queue broker instance is up and running.
# netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN

Add a new user named msgquser.

This user will connect to the Message Queue broker instance on servers where Message Queue is installed. This user will be used only for session failover purposes, and does not assume the privileges of the guest user. It is a good practice to create a custom user for such purposes, and not to rely on the known user accounts or default user accounts to help prevent brute force or DOS attacks.
# ./imqusermgr add -u msgquser -g admin -p m5gqu5er -i msgqbroker User repository for broker instance: msgqbroker User msgquser successfully added.

Disable the guest user.

This step ensures that the guest user will not be able to access the OpenSSO Enterprise server.

# ./imqusermgr update -u guest -a false -i msgqbroker

User repository for broker instance: msgqbroker

Are you sure you want to update user guest? (y/n) y

User guest successfully updated.

Modify the amsfo.conf file with the following sub procedure.

amsfo.conf has parameters that are consumed by the OpenSSO Enterprise session failover startup script, amsfo.
1. Change to the lib directory.
  # cd /export/SFO/ssoSessionTools/opensso/config/lib
  Tip –
  Backup amsfo.conf before you modify it.
2. Set the following properties:
  CLUSTER_LIST=mq-1.example.com:7777,mq-2.example.com:7777 BROKER_INSTANCE_NAME=msgqbroker USER_NAME=msgquser BROKER_PORT=7777
  Note –
  The port used for BROKER_PORT should be the same as the one used in the value of the CLUSTER_LIST.
3. Save the file and close it.

Generate an encrypted password in a .password file with the following sub procedure.
1. Change to the bin directory.
  # cd /export/SFO/ssoSessionTools/opensso/bin
2. Run amsfopassword.
  
  This command generates an encrypted password, creates a new file named .password, and stores the encrypted password in the new file.
  
  Caution –
  amsfopassword creates the .password file in a default location based on where the scripts were installed. If a different location is used, the PASSWORDFILE property in amsfo.conf should be changed accordingly.
  # ./amsfopassword -e m5gqu5er -f /export/SFO/ssoSessionTools/opensso/.password os.name=SunOS SUCCESSFUL
3. (Optional) View the encrypted password for verification.
  # more /export/SFO/ssoSessionTools/opensso/.password M27OGb6U4ufRu+oWAzBdWw==

(Optional) Modify the amsessiondb script if necessary.

The amsessiondb script (located in the /export/SFO/ssoSessionTools/opensso/bin directory) starts the Berkeley Database client, creates the database, and sets specific database values. It is called when the amsfo script is run for the first time. The amsessiondb script contains variables that specify default paths and directories. If any of the following components are not installed in their default directories, edit the amsessiondb script to set the variables to the correct locations.
JAVA_HOME=/usr/jdk/entsys-j2se IMQ_JAR_PATH=/export/SFO/ssoSessionTools/jmq/mq/lib JMS_JAR_PATH=/export/SFO/ssoSessionTools/jmq/mq/lib AM_HOME=/export/SFO/ssoSessionTools
Tip –
Backup amsessiondb before you modify it.

Restart the session failover components.
1. Change to the bin directory.
  # cd /export/SFO/ssoSessionTools/jmq/mq/bin
2. Stop the Message Queue instance using the product's command line interface.
  
  See the Message Queue documentation for more information.
3. Run the netstat command to verify that the mq-2 broker instance is stopped.
  # netstat -an | grep 7777
  If netstat returns no result, the mq-2 broker instance is stopped.
  
  Tip –
  If the mq-2 broker instance is not stopped, kill the process using the following procedure.
  1. Get the Java process IDs.
    # ps -ef | grep java
  2. Kill the Java process IDs that were returned.
    # kill -9 #### ####
  3. Run netstat again.
4. Restart the mq-2 broker instance.
  # cd /export/SFO/ssoSessionTools/opensso/bin # ./amfso start
5. Run the netstat command to verify that the Message Queue port is open and listening.
  # netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN

Log out of the mq-2 host machine.

10.3 Configuring and Verifying Session Failover

Use the following list of procedures as a checklist for completing this task.

To Configure OpenSSO Enterprise for Session Failover

Access https://osso-1.example.com:1081/opensso/console from a web browser.

Click the Configuration tab.

Under Global properties, click Session.

Under Secondary Configuration Instance, click New.

In the Add Sub Configuration page, provide the following information.

Name

Select External

Session Store User

Enter msgquser

Session Store Password

Enter m5gqu5er

Session Store Password (confirm)

Enter m5gqu5er

Maximum Wait Time

Keep the default value of 5000.

Database URL

Enter mq-1.example.com:7777,mq-2.example.com:7777.

This is the Message Queue broker address list. Enter multiple values using a comma and no space.

Click Add.

Click Save.

Log out of the OpenSSO Enterprise console.

Restart the Application Server 1 instance with the following sub procedure.

As a root user, log in to the osso–1 host machine.

Switch to the non-root user and change to the bin directory.

# su osso80adm
# cd /export/osso80adm/domains/ossodomain/bin

Restart the Application Server 1 instance.

# ./stopserv; ./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Log out of the osso–1 host machine.

Restart the Application Server 2 instance with the following sub procedure.

As a root user, log in to the osso–2 host machine.

Switch to the non-root user and change to the bin directory.

# su osso80adm
# cd /export/osso80adm/domains/ossodomain/bin

Restart the Application Server 2 instance.

# ./stopserv; ./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

Log out of the osso-2 host machine.

To Verify That the Administrator Session Fails Over

Before You Begin

Both OpenSSO Enterprise 1 and OpenSSO Enterprise 2 should be up and running before you begin this verification procedure.

As a root user, log in to the osso–2 host machine.

Change to the bin directory.

# cd /export/osso80adm/domains/ossodomain/bin

Stop OpenSSO Enterprise 2.
# ./stopserv

Access https://lb-2.example.com:1081/opensso/console from a web browser.
1. Log in to the OpenSSO Enterprise console as the administrator.
  
  Username
  
  amadmin
  
  Password
  
  ossoadmin
2. Click the Sessions tab.
3. In the View field, select osso-1.example.com:1081 from the drop down list.
  
  Verify that only amadmin exists in the Sessions table.
4. In the View field, select osso-2.example.com:1081 from the drop down list.
  
  You will see an error message indicating the server is down.
5. Leave this browser window 1 open.

Start OpenSSO Enterprise 2.

# ./startserv

admin username:domain2adm

admin password:domain2pwd

master password:domain2master

Redirecting output to /export/osso80adm/domains/ossodomain/logs/server.log

As a root user, log in to the osso-1 host machine.

Change to the bin directory.

# cd /export/osso80adm/domains/ossodomain/bin

Stop OpenSSO Enterprise 1.
# ./stopserv

Going back to the OpenSSO Enterprise console in browser window 1, under the Sessions tab, select osso-1.example.com:1081 from the View drop down list.

You will see an error message indicating the server is down.

Now select osso-2.example.com:1081 from the View drop down list.

Verify that only amadmin exists in the Sessions table. This indicates that although OpenSSO Enterprise 1 was stopped, the OpenSSO Enterprise Load Balancer 2 directed the request to OpenSSO Enterprise 2 and a session for amadmin was successfully created by OpenSSO Enterprise 2. If session failover was not enabled, it would have resulted in a login page.

To Verify that the User Session Fails Over

Before You Begin

This procedure assumes that you have just completed To Verify That the Administrator Session Fails Over.

Access https://lb-2.example.com:1081/opensso/UI/Login from a second browser window.

Log in to the OpenSSO Enterprise console as testuser1.

Username

testuser1

Password

password

A page with a message that reads You're logged in is displayed. Since the User Profile attribute was set to Ignored, the user's profile is not displayed following a successful login. Because OpenSSO Enterprise 1 was stopped, the user session is created in OpenSSO Enterprise 2.

Leave browser window 2 open.

Using browser window 1, click the Sessions tab.

In the View field, select osso-2.example.com:1081 from the drop down list.

Verify that amadmin and testuser1 exist in the Sessions table.

On the osso–1 host machine, change to the bin directory.
# cd /export/osso80adm/domains/ossodomain/bin

Start OpenSSO Enterprise 1.
# ./startserv
Both OpenSSO Enterprise 1 and OpenSSO Enterprise 2 are up and running.

On the osso–2 host machine, change to the bin directory.
# cd /export/osso80adm/domains/ossodomain/bin

Stop OpenSSO Enterprise 2.
# ./stopserv

Using browser window 1, click the Sessions tab and do the following sub procedure.
1. In the View field, select osso-1.example.com:1081.
  
  Verify that amadmin and testuser1 exist in the Sessions table. This indicates that the session successfully failed over to OpenSSO Enterprise 1.
  
  Tip –
  If testuser1 is not displayed, refresh the browser window 2 page.
2. In the View field, select osso-2.example.com:1081
  
  You will see an error message indicating the server is down.

Log out of the consoles and the host machines.