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
7.2 Enabling Secure Communications Between the Web Server Instances and the Load Balancer
7.3 Configuring the Distributed Authentication User Interface Load Balancer
7.4 Creating an Agent Profile with Custom User for the Distributed Authentication User Interface
7.5 Generating and Deploying the Distributed Authentication User Interface WAR
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
To Install the Web Server for Distributed Authentication User Interface 1
To Create a Non-Root User on the Distributed Authentication User Interface 2 Host Machine
To Install Sun Java System Web Server for Distributed Authentication User Interface 2
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 |
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.
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.
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.
Make a directory for downloading the patches you need and change into it.
# mkdir /export/patches # cd /export/patches |
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.
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
Unzip the patch files.
# unzip 119963-08.zip # unzip 120011-14.zip |
Run patchadd to install the patches.
# patchadd /export/patches/119963-08 # patchadd /export/patches/120011-14 |
You can use the -M option to install all patches at once. See the patchadd man page for more information.
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.
|
Press Enter. Continue to press Enter when prompted. |
|
|
Enter yes. |
|
|
Enter /opt/SUNWwbsvr |
|
|
Enter yes. |
|
|
Enter 2. |
|
|
Enter 1,3,5. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Enter no. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter no. |
|
|
Enter da80adm. |
|
|
Accept the default value. |
|
|
Enter web4dmin. |
|
|
Enter web4dmin. |
|
|
Accept the default value. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Enter no. |
|
|
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.
Log out of the da–1 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 |
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.
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.
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.
Make a directory for downloading the patches you need and change into it.
# mkdir /export/patches # cd /export/patches |
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.
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
Unzip the patch files.
# unzip 119963-08.zip # unzip 120011-14.zip |
Run patchadd to install the patches.
# patchadd /export/patches/119963-08 # patchadd /export/patches/120011-14 |
You can use the -M option to install all patches at once. See the patchadd man page for more information.
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.
|
Press Enter. Continue to press Enter when prompted. |
|
|
Enter yes. |
|
|
Enter /opt/SUNWwbsvr |
|
|
Enter yes. |
|
|
Enter 2. |
|
|
Enter 1,3,5. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Enter no. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter no. |
|
|
Enter da80adm. |
|
|
Accept the default value. |
|
|
Enter web4dmin. |
|
|
Enter web4dmin. |
|
|
Accept the default value. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Enter no. |
|
|
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.
Log out of the da–2 host machine.
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
To Request and Install a Server Certificate and a Root Certificate for Web Server 2
To Import the Root Certificate to the Web Server 1 JDK Certificate Store
To Import the Root Certificate to the Web Server 2 JDK Certificate Store
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.
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.
The wadm command line interface, bundled with the Web Server, is used in this procedure.
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.
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.
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.
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–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.
The wadm command line interface, bundled with the Web Server, is used in this procedure.
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.
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.
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.
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–2 host machine.
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.
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. |
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 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
To Import a Root Certificate to the Distributed Authentication User Interface Load Balancer
To Import a Certificate to the Distributed Authentication User Interface Load Balancer
To Configure 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.
Log in to the BIG-IP console using the following information.
username
password
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:
lb-3.example.com
Deployment
lb-3.example.com
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.
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.
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.
Log in using the following information:
username
password
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.
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.
Access https://is-f5.example.com, the Big IP load balancer login page, from a web browser.
Log in using the following information.
username
password
Click Configure your BIG-IP (R) using the Configuration Utility.
Create a Pool.
A pool contains all the backend server instances.
In the left pane, click Pools.
On the Pools tab, click Add.
In the Add Pool dialog, provide the following information:
AuthenticationUI-Pool
Round Robin
Add the IP address and port number of both Distributed Authentication User Interface host machines: da-1:1443 and da-2:1443.
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.
If you encounter JavaScriptTM errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click Add.
In the Add Virtual Server wizard, enter the virtual server IP address and port number.
Enter the IP address for lb-3.example.com
9443
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the AuthenticationUI-Pool Pool.
Click Done.
Add Monitors.
Monitors are required for the load balancer to detect backend server failures.
Configure the load balancer for persistence.
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.
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.
Log in using the following information:
username
password
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:
Check SSL and ServerSSL.
The IP address of Load Balancer 3.
1443
The secure port number
The IP address of Load Balancer 3.
9443
The secure port number
Choose Local Virtual Server.
Choose lb-3.example.com.
Choose lb-3.example.com.
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.
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.
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.
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.
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.
Log in to the OpenSSO Enterprise console as the administrator.
amadmin
ossoadmin
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.
authuiadmin
authuiadmin
authuiadmin
authuiadmin is displayed in the list of Agent names.
Log out of the console.
This is an optional, verification step.
Log in to either of the OpenSSO Enterprise host machines.
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.
authuiadmin
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.
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
To Deploy the Generated WAR as Distributed Authentication User Interface 1
To Deploy the Generated WAR as Distributed Authentication User Interface 2
To Configure Load Balancer Cookies for the Distributed Authentication User Interface
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.
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.
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.
testuser1
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.
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.
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.
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 |
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-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.
testuser1
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.
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.
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 |
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 |
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.
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.
testuser1
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.