This second part of Deployment Example: SAML v2 Using Sun OpenSSO Enterprise 8.0 provides the instructions for installing and configuring OpenSSO Enterprise, Sun Java System Directory Server, applicable web containers and policy agents to function as the identity provider. Best results will be obtained by executing the tasks in the exact sequence in which they are presented. This part contains the following chapters:
Chapter 4, Installing Sun Java System Directory Server and Creating Instances for User Data
Chapter 6, Configuring OpenSSO Enterprise Realms for User Authentication
If deviating from the task sequence or details described, refer to the relevant product documentation for information or necessary requirements.
This chapter contains instructions for installing Sun Java™ System Directory Server and creating the instances in which 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:
4.1 Installing and Configuring Directory Server 1 and Directory Server 2
4.2 Enabling Multi-Master Replication of the User Data Instances
4.4 Enabling Secure Communication for the Directory Server User Data Instances
If you have an existing user data store, you can go directly to the instructions in Chapter 5, Deploying and Configuring OpenSSO Enterprise.
This section contains the instructions for installing Directory Server on two different host machines on the identity provider side. Post installation, create the directory instances named idp-users in which the 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 Host Machines
To Create a Base Suffix for the User Data Instance on Directory Server 1
To Create a Base Suffix for the User Data Instance on Directory Server 2
Use this procedure to download the Directory Server Enterprise Edition (EE) 6.3 bits and the required system patches to both the Directory Server 1 host machine (ds1.idp-example.com) and the Directory Server 2 host machine (ds2.idp-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.
Directory Server Enterprise Edition 6.x
6.3
Compress Archive (ZIP)
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.
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.3 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, patch 127112, patch 119964, patch 125379, and patch 119255 are required.
Log into the ds1.idp-example.com host machine as a root user.
Run patchadd to see if the patches are already installed.
See the patchadd man page for more information.
# /usr/sbin/patchadd -p | grep 118855 |
No results are returned which indicates that the patch is not yet installed on the system.
# /usr/sbin/patchadd -p | grep 127112 |
No results are returned which indicates that the patch is not yet installed on the system.
# /usr/sbin/patchadd -p | grep 119964 |
No results are returned which indicates that the patch is not yet installed on the system.
# /usr/sbin/patchadd -p | grep 125379 |
No results are returned which indicates that the patch is not yet installed on the system.
# /usr/sbin/patchadd -p | grep 119255 |
No results are returned which indicates that the patch is not yet installed on the system.
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).
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/DS63 # cd /export/DS63 |
Download the Base Full Install of Directory Server EE 6.3 — Zip Distribution, Multi-Language, (DS/DPS/DE/ISW/DSRK) bits.
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 ds1.idp-example.com host machine.
Repeat this same procedure on the ds2.idp-example.com host machine.
If necessary, use this procedure to patch both the ds1.idp-example.com host machine and the ds2.idp-example.com host machine.
Log in to the ds1.idp-example.com host machine as a root user.
Change into the directory that contains the downloaded patch files.
# cd /export/patches |
Unzip the patch files.
# unzip 118855.zip # unzip 127112.zip # unzip 119964.zip # unzip 125379.zip # unzip 119255.zip |
Install the patches.
# /usr/sbin/patchadd /export/patches/118855 # /usr/sbin/patchadd /export/patches/127112 # /usr/sbin/patchadd /export/patches/119964 # /usr/sbin/patchadd /export/patches/125379 # /usr/sbin/patchadd /export/patches/119255 |
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.
# /usr/sbin/patchadd -p | grep 118855 |
A series of patch numbers are displayed, and the patch 118855 is present.
# /usr/sbin/patchadd -p | grep 127112 |
A series of patch numbers are displayed, and the patch 127112 is present.
# /usr/sbin/patchadd -p | grep 119964 |
A series of patch numbers are displayed, and the patch 119964 is present.
# /usr/sbin/patchadd -p | grep 125379 |
A series of patch numbers are displayed, and the patch 125379 is present.
# /usr/sbin/patchadd -p | grep 119255 |
A series of patch numbers are displayed, and the patch 119255 is present.
Log out of the ds1.idp-example.com host machine.
Repeat this same procedure on the ds2.idp-example.com host machine.
This procedures assumes To Download the Directory Server Bits and Required Patches to the Host Machines and To Patch the Directory Server Host Machines have been completed.
Log in to the ds1.idp-example.com host machine as a root user.
(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/DS63 # ls DSEE.6.1.Solaris10-X86_AMD64-full.tar.gz # gunzip DSEE.6.3.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.
Use this procedure to create a Directory Server instance named idp-users for storing user data. The instance uses port 1489 for LDAP and port 1736 for LDAPS.
This procedure assumes you have just completed To Install Directory Server 1 and are still logged into the ds1.idp-example.com 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 idp-users.
# ./dsadm create -p 1489 -P 1736 /var/opt/mps/idp-users Choose the Directory Manager password: dsmanager Confirm the Directory Manager password: dsmanager use 'dsadm start /var/opt/mps/idp-users' to start the instance |
Run dsadm start to start the instance.
# ./dsadm start /var/opt/mps/idp-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 ds1.idp-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.3 ... |
Use this procedure to create the base suffix in which the user entries will be stored.
This procedure assumes you have just completed To Create a User Data Instance on Directory Server 1 and are still logged into the ds1.idp-example.com 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/idp-users/db/exampleDS dc=company,dc=com |
Provide the appropriate information when prompted.
Certificate "CN=ds1, 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 |
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 idp-users in a command line list of directory instances.
# cd /var/opt/mps # ls idp-users serverroot |
Log out of the ds1.idp-example.com host machine.
This procedures assumes To Download the Directory Server Bits and Required Patches to the Host Machines and To Patch the Directory Server Host Machines have been completed.
Log in to the ds2.idp-example.com host machine as a root user.
(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/DS63 # ls DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz # gunzip DSEE.6.3.Solaris10-X86_AMD64-full.tar.gz |
Untar the resulting .tar file.
# tar xvf DSEE.6.3.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.
Use this procedure to create a Directory Server instance named idp-users for storing user data. The instance uses port 1489 for LDAP and port 1736 for LDAPS.
This procedure assumes you have just completed To Install Directory Server 2 and are still logged into the ds2.idp-example.com 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 idp-users.
# ./dsadm create -p 1489 -P 1736 /var/opt/mps/idp-users Choose the Directory Manager password: dsmanager Confirm the Directory Manager password: dsmanager use 'dsadm start /var/opt/mps/idp-users' to start the instance |
Run dsadm start to start the instance.
# ./dsadm start /var/opt/mps/idp-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 ds2.idp-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.3 ... |
Use this procedure to create the base suffix in which the user entries will be stored.
This procedure assumes you have just completed To Create a User Data Instance on Directory Server 2 and are still logged into the ds2.idp-example.com 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/idp-users/db/exampleDS dc=company,dc=com |
Provide the appropriate information when prompted.
Certificate "CN=ds2, 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 |
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 idp-users in a command line list of directory instances.
# cd /var/opt/mps # ls idp-users serverroot |
Log out of the ds2.idp-example.com host machine.
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 idp1-user and idp2-user 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
To Enable Multi-Master Replication for User Data Instance on Directory Server 2
To Change the Default Replication Manager Password for Each User Data Instance
To Create Replication Agreements for Each User Data Instance
Log in to the ds1.idp-example.com host machine as a root user.
(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 "ds1.idp-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 ds1.idp-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 "ds1.idp-example.com:1489" |
The base suffix of the instance is master(11) indicating that the master was successfully enabled.
Log out of the ds1.idp-example.com host machine.
Log in to the ds2.idp-example.com host machine as a root user.
(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 "ds2.idp-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 ds2.idp-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 "ds2.idp-example.com:1489" |
The base suffix of the instance is master(22) indicating that the master was successfully enabled.
Log out of the ds2.idp-example.com host machine.
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.
Log in to the ds1.idp-example.com host machine as a root user.
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 ds1.idp-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 ds1.idp-example.com host machine.
Log in to the ds2.idp-example.com host machine as a root user.
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 ds2.idp-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 ds2.idp-example.com host machine.
A replication agreement is a set of parameters on a supplier that controls how updates are sent to a given consumer. In this deployment, the agreement simply makes the user data instances aware of each other.
Log in to the ds1.idp-example.com host machine as a root user.
Run dsconf create-repl-agmt to create the replication agreement.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-repl-agmt -h ds1.idp-example.com -p 1489 dc=company,dc=com ds2.idp-example.com:1489 Enter "cn=Directory Manager" password: dsmanager Use "dsconf init-repl-dest dc=company,dc=com ds2.idp-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 ds2.idp-example.com:1489 |
This response indicates that the Directory Server 1 base suffix will be replicated to Directory Server 2.
Log out of the ds1.idp-example.com host machine.
Log in to the ds2.idp-example.com host machine as a root user.
Run dsconf create-repl-agmt to create the replication agreement.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-repl-agmt -h ds2.idp-example.com -p 1489 dc=company,dc=com ds1.idp-example.com:1489 Enter "cn=Directory Manager" password: dsmanager Use "dsconf init-repl-dest dc=company,dc=com ds1.idp-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 ds1.idp-example.com:1489 |
This response indicates that the Directory Server 2 base suffix will be replicated to Directory Server 1.
Log out of the ds2.idp-example.com host machine.
Use this procedure to initialize the user data instance on Directory Server 1. The previously created agreements will allow the data to replicate on Directory Server 2.
Initialization is not required on both instances when configuring for MMR.
Log in to the ds1.idp-example.com host machine as a root user.
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 ds1.idp-example.com -p 1489 dc=company,dc=com ds2.idp-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 ds1.idp-example.com -p 1489 dc=company,dc=com ds2.idp-example.com:1489 Enter "cn=Directory Manager" password: dsmanager Started initialization of "ds2.idp-example.com:1489"; Aug 25, 2008 3:10:01 PM Sent 2 entries. Completed initialization of "ds1.idp-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 ds1.idp-example.com -p 1489 dc=company,dc=com ds2.idp-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 |
This procedure assumes you have just completed To Initialize the Replication Agreements and are still logged into the ds1.idp-example.com host machine as a root user.
Run ldapmodify on the ds1.idp-example.com host machine to create a new directory entry.
# cd /var/opt/mps/serverroot/dsrk6/bin # ./ldapmodify -a -h ds1.idp-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 ds2.idp-example.com 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 |
Run ldapdelete on Directory Server 2 to delete the entry just found.
# ./ldapdelete -h ds2.idp-example.com -p 1489 -D "cn=Directory Manager" -w dsmanager "ou=People,dc=company,dc=com" |
Run ldapsearch on Directory Server 1 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.
This deployment will be used to test SAML v2 communications. Towards this end, modify the LDAP schema used by the Directory Server user data instances on the identity provider side to recognize and store SAML v2 attributes.
Log in to the ds1.idp-example.com host machine as a root user.
Create an LDIF file with the following information and save it as /tmp/saml.ldif.
This file includes SAML v2 LDAP attributes.
dn: CN=schema changetype:modify add:attributeTypes attributeTypes: ( 1.3.6.1.4.1.42.2.27.9.1.500 NAME 'sun-fm-saml2-nameid-infokey' DESC 'SAML 2.0 Name Identifier Information Key' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Sun Java System Access Management' ) attributeTypes: ( 1.3.6.1.4.1.42.2.27.9.1.501 NAME 'sun-fm-saml2-nameid-info' DESC 'SAML 2.0 Name Identifier Information' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Sun Java System Access Management' ) - add:objectClasses objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.200 NAME 'sunFMSAML2NameIdentifier' DESC 'SAML 2.0 name identifier objectclass' SUP top AUXILIARY MAY ( sun-fm-saml2-nameid-infokey $ sun-fm-saml2-nameid-info ) X-ORIGIN 'Sun Java System Access Management' ) |
Run ldapmodify on the ds1.idp-example.com host machine using /tmp/saml.ldif as input.
# cd /var/opt/mps/serverroot/dsrk6/bin # ldapmodify -a -h ds1.idp-example.com -p 1489 -D "cn=Directory Manager" -w dsmanager -f /tmp/saml.ldif modifying entry CN=schema |
Log out of the ds1.idp-example.com host machine.
By default, when an instance of Directory Server is created, 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 idp-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 load balancer. This entails installing a CA root certificate and a server certificate (signed by the CA root certificate) on both Directory Server host machines. Use the following list of procedures as a checklist for completing this task.
To Import a Root Certificate and a Server Certificate to Directory Server 1
To Import a Root Certificate and a Server Certificate to Directory Server 2
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.
Log in to the ds1.idp-example.com host machine as a root user.
Generate a request for a server certificate signed by a CA.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm request-cert -S "CN=ds1.idp-example.com, OU=OpenSSO Enterprise, O=Sun Microsystems, L=Santa Clara ST=California, C=US" -F ascii -o ds1.csr /var/opt/mps/idp-users |
ds1.csr is the certificate request.
Send ds1.csr to the CA of your choice.
The CA issues and returns a certified server certificate named ds1.cer.
Add ds1.cer, the CA-signed server certificate, to the certificate store.
# ./dsadm add-cert /var/opt/mps/idp-users ds1 ds1.cer |
(Optional) Verify that the certificate was successfully added.
# ./dsadm list-certs /var/opt/mps/idp-users |
A list of certificates for the idp-users instance is displayed including the defaultCert and ds1.
Add ca.cer, the root certificate, to the certificate store.
# ./dsadm add-cert --ca /var/opt/mps/idp-users CA-cert ca.cer |
(Optional) Verify that the root certificate was successfully added.
# ./dsadm list-certs -C /var/opt/mps/idp-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 ds1.idp-example.com -p 1489 ssl-rsa-cert-name:ds1 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/idp-users # ./dsadm start /var/opt/mps/idp-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 ds1.idp-example.com -p 1736 -Z -P /var/opt/mps/idp-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 ds1.idp-example.com host machine.
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.
Log in to the ds2.idp-example.com host machine as a root user.
Generate a request for a server certificate signed by a CA.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm request-cert -S "CN=ds2.idp-example.com, OU=OpenSSO Enterprise, O=Sun Microsystems, L=Santa Clara ST=California, C=US" -F ascii -o ds2.csr /var/opt/mps/idp-users |
ds2.csr is the certificate request.
Send ds2.csr to the CA of your choice.
The CA issues and returns a certified server certificate named ds2.cer.
Add ds2.cer, the CA-signed server certificate, to the certificate store.
# ./dsadm add-cert /var/opt/mps/idp-users ds2 ds2.cer |
(Optional) Verify that the certificate was successfully added.
# ./dsadm list-certs /var/opt/mps/idp-users |
A list of certificates for the idp-users instance is displayed including the defaultCert and ds2.
Add ca.cer, the root certificate, to the certificate store.
# ./dsadm add-cert --ca /var/opt/mps/idp-users CA-cert ca.cer |
(Optional) Verify that the root certificate was successfully added.
# ./dsadm list-certs -C /var/opt/mps/idp-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 ds2.idp-example.com -p 1489 ssl-rsa-cert-name:ds2 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/idp-users # ./dsadm start /var/opt/mps/idp-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 ds2.idp-example.com -p 1736 -Z -P /var/opt/mps/idp-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 ds2.idp-example.com host machine.
Load Balancer 1 (lb1.idp-example.com) is configured in front of the Directory Server instances on the identity provider side. 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.
Import the CA root certificate to the Directory Server 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.4 Enabling Secure Communication for the Directory Server User Data Instances. For more information, see 3.3 Obtaining Secure Socket Layer Certificates.
Access https://lb1.idp-example.com, the BIG-IP load balancer login page, in a web browser.
Log in to the load balancer as administrator.
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 CertificateOpenSSL_CA_Cert page is displayed.
Click Return to Certificate Administration on the CertificateOpenSSL_CA_Cert page.
OpenSSL_CA_Cert, the root certificate, is now included in the Certificate ID list.
This procedure assumes that you have just completed To Import the Root Certificate to Directory Server Load Balancer 1 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.
In the left pane, click Pools.
On the Pools tab, click Add.
In the Add Pool dialog, provide the following information:
DirectoryServerIDP-UserData-Pool
Round Robin
Add the IP address and port number of both Directory Server host machines.
User port number 1736.
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.
Click Add on the Virtual Servers tab.
In the Add a Virtual Server dialog box, provide the following information:
Enter the IP address for lb1.idp-example.com.
489
Continue to click Next until you reach the Pool Selection dialog box.
Assign DirectoryServerIDP-UserData-Pool to the virtual server in the Pool Selection dialog box.
Click Done.
Add Monitors
Monitors are required for the load balancer to detect the backend server failures.
In the left frame, click Monitors.
Click the Basic Associations tab.
Add an LDAP monitor for the Directory Server 1 node.
In the Node column, locate the IP address and port number previously entered for Directory Server 1 and select the Add checkbox.
Add an LDAP monitor for the Directory Server 2 node.
In the Node column, locate the IP address and port number previously entered for Directory Server 2 and select the Add checkbox.
At the top of the Node column, in the drop-down list, choose tcp.
Click Apply.
Configure the load balancer 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.
Verify the load balancer configuration with the following sub procedure.
Log in as a root user on each Directory Server host machine.
On each host machine, use the tail command to monitor the Directory Server access log.
# cd /var/opt/mps/idp-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 lb1.idp-example.com -p 489 -Z -P /var/opt/mps/idp-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 |
Make sure the returned entries display in the access log on only one Directory Server host machine.
Run dsadm stop to stop Directory Server 1.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/idp-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 lb1.idp-example.com -p 489 -Z -P /var/opt/mps/idp-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 |
Make sure that the returned entries display in the access log on only Directory Server 2.
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/idp-users |
Stop Directory Server 2.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/idp-users |
Perform the following LDAP search against the Directory Server load balancer from Directory Server 1.
# cd /var/opt/mps/serverroot/dsrk6/bin ./ldapsearch -h lb1.idp-example.com -p 489 -Z -P /var/opt/mps/idp-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 |
Make sure the returned entries display in the access log on only Directory Server 1.
Start Directory Server 2.
# ./dsadm start /var/opt/mps/idp-users |
Log out of both Directory Server host machines and the load balancer console.
Create a user entry in the replicated Directory Server user data instances for idpuser.
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.
Create an LDIF file for the test user and import the file into ds1.idp-example.com. The test user data will then be replicated to ds2.idp-example.com.
Log in to the ds1.idp-example.com host machine as a root user.
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=idpuser,ou=users,dc=company,dc=com uid: idpuser givenName: idp objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetadmin objectClass: inetorgperson objectClass: inetUser sn: user cn: idp user userPassword: idpuser inetUserStatus: Active
Save the file as idp-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 ds1.idp-example.com -p 1489 -D "cn=Directory Manager" -w dsmanager -a -f /tmp/idp-users.ldif adding new entry ou=users,dc=company,dc=com adding new entry ou=Groups,dc=company,dc=com adding new entry uid=idpuser,ou=users,dc=company,dc=com |
Verify that the new users were imported using ldapsearch.
# ./ldapsearch -h ds1.idp-example.com -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" -w dsmanager "uid=idpuser" version: 1 dn: uid=idpuser,ou=users,dc=company,dc=com uid: idpuser givenName: idp objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetadmin objectClass: inetorgperson objectClass: inetUser sn: user cn: idp user userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA== inetUserStatus: Active |
Log out of the ds1.idp-example.com host machine.
(Optional) Verify that the entries were replicated to Directory Server 2 by logging in as a root user to the ds2.idp-example.com host machine and using ldapsearch.
# cd /var/opt/mps/serverroot/dsrk6/bin # ./ldapsearch -h ds2.idp-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=idpuser,ou=users,dc=company,dc=com uid: idpuser givenName: idp objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetadmin objectClass: inetorgperson objectClass: inetUser sn: user cn: idp user userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA== inetUserStatus: Active |
Log out of the ds2.idp-example.com host machine.
This chapter includes instructions on how to deploy and configure two instances of Sun OpenSSO Enterprise 8.0. It begins with the installation of Sun Java™ System Application Server onto each host machine, followed by the deployment and configuration of the OpenSSO Enterprise WAR. This chapter contains the following sections:
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. The final procedures in the installation process is to request and import certificates for secure communications with a soon-to-be-configured load balancer. Use the following list of procedures as a checklist for completing the task.
To Create a Non-Root User on the OpenSSO Enterprise 1 Host Machine
To Install Application Server on the OpenSSO Enterprise 1 Host Machine
To Create a Non-Root User on the OpenSSO Enterprise 2 Host Machine
To Install Application Server on the OpenSSO Enterprise 2 Host Machine
We use roleadd rather than useradd for security reasons; roleadd disables the ability of the user to log in.
On our lab machines, the required Application Server patch is 117461–08. Results for your machine might be different. Read the latest documentation for your web container to determine if you need to install patches and, if so, what they might be. 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 for the OpenSSO Enterprise 1 host machine (osso1.idp-example.com) and the OpenSSO Enterprise 2 host machine (osso2.idp-example.com).
Log in to the osso1.idp-example.com host machine as a root user.
Run patchadd to see if the patch is already installed.
# patchadd -p | grep 117461-08 |
A series of patch numbers are displayed, and patch 117461–08 is present so there is no need to install any patches at this time.
Log out of the osso1.idp-example.com host machine.
Log in to the osso2.idp-example.com host machine as a root user.
Run patchadd to see if the patch is already installed.
# patchadd -p | grep 117461-08 |
A series of patch numbers are displayed, and patch 117461–08 is present so there is no need to install any patches at this time.
Log out of the osso2.idp-example.com host machine.
Log in to the osso1.idp-example.com host machine as a root user.
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 |
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 you have just completed To Create a Non-Root User on the OpenSSO Enterprise 1 Host Machine and are still logged into the osso1.idp-example.com 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.
|
Press Enter to continue. |
|
|
Enter yes. |
|
|
Enter /opt/SUNWappserver91 |
|
|
Enter 1 to create the directory. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the default value. |
|
|
Enter domain1pwd and then re-enter domain1pwd. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the three default values. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the default value and begin the installation process. |
|
|
When installation is complete, an Installation Successful message is displayed: |
|
|
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. |
Creating a non-root domain displays a FileNotFoundException. Please see Appendix G, 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.
Access http://osso1.idp-example.com:8989/login.jsf from a web browser.
Log in to the Application Server console as the ossodomain administrator.
domain2adm
domain2pwd
When the Application Server administration console is displayed, it is verification that the non-root user was able to start the domain server.
Exit the console and close the browser.
Create a request for a server certificate to secure communications between the soon-to-be-configured OpenSSO Enterprise load balancer and ossodomain using the following sub-procedure.
Generate a private/public key pair and reference it with the alias, opensso-idp-1.
opensso-idp-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 opensso-idp-1 -keystore keystore.jks -dname "CN=osso1.idp-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: opensso-idp-1 Creation date: Aug 4, 2008 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=osso1.idp-example.com, OU=OpenSSO, O=Sun Microsystems, L=Santa Clara, ST=California, C=US Issuer: CN=osso1.idp-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 "opensso-idp-1" is a self-signed certificate. |
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 opensso-idp-1 -keypass domain2master -keystore keystore.jks -storepass domain2master file opensso-idp-1.csr |
opensso-idp-1.csr is the server certificate request.
(Optional) Verify that opensso-idp-1.csr was created.
# ls -la opensso-idp-1.csr -rw-r--r-- 1 osso80adm staff 715 Apr 4 15:04 opensso-idp-1.csr |
Send opensso-idp-1.csr to the CA of your choice.
The CA issues and returns a certified certificate named opensso-idp-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 s1as alias) with the server certificate received from the CA.
# keytool -import -file opensso-idp-1.cer -alias opensso-idp-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 "opensso-idp-1" is signed by CA. |
Change the certificate alias from the default s1as to the new opensso-idp-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="opensso-idp-1" client-auth-enabled="false" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
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.
Backup domain.xml before modifying it.
Change to the config directory.
# cd /export/osso80adm/domains/ossodomain/config |
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>.
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 |
Verify that the certificate used for SSL communication is the root CA certificate.
Log out of the osso1.idp-example.com host machine.
Log in to the osso2.idp-example.com host machine as a root user.
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 |
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 you have just completed To Create a Non-Root User on the OpenSSO Enterprise 2 Host Machine and are still logged into the osso2.idp-example.com 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.
|
Press Enter to continue. |
|
|
Enter yes. |
|
|
Enter /opt/SUNWappserver91 |
|
|
Enter 1 to create the directory. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the default value. |
|
|
Enter domain1pwd and then re-enter domain1pwd. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the three default values. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the default value. |
|
|
Press Enter to accept the default value and begin the installation process. |
|
|
When installation is complete, an Installation Successful message is displayed: |
|
|
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. |
The FileNotFoundException is a known issue. Please see Appendix G, 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.
Access http://osso2.idp-example.com:8989/login.jsf from a web browser.
Log in to the Application Server console as the administrator.
domain2adm
domain2pwd
When the Application Server administration console is displayed, it is verification that the non-root user was able to start the domain server.
Exit the console and close the browser.
Create a request for a server certificate to secure communications between the soon-to-be-configured OpenSSO Enterprise load balancer and ossodomain using the following sub-procedure.
Generate a private/public key pair and reference it with the alias, opensso-idp-2.
opensso-idp-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 opensso-idp-2 -keystore keystore.jks -dname "CN=osso2.idp-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: opensso-idp-2 Creation date: Aug 4, 2008 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=osso2.idp-example.com, OU=OpenSSO, O=Sun Microsystems, L=Santa Clara, ST=California, C=US Issuer: CN=osso2.idp-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 "opensso-idp-2" is a self-signed certificate. |
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 opensso-idp-2 -keypass domain2master -keystore keystore.jks -storepass domain2master file opensso-idp-2.csr |
opensso-idp-2.csr is the server certificate request.
(Optional) Verify that opensso-idp-2.csr was created.
# ls -la opensso-idp-2.csr -rw-r--r-- 1 osso80adm staff 715 Apr 4 15:04 opensso-idp-2.csr |
Send opensso-idp-2.csr to the CA of your choice.
The CA issues and returns a certified server certificate named opensso-idp-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 s1as alias) with the server certificate received from the CA.
# keytool -import -file opensso-idp-2.cer -alias opensso-idp-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 "opensso-idp-2" is signed by CA. |
Change the certificate alias from the default s1as to the new opensso-idp-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="opensso-idp-2" client-auth-enabled="false" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
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.
Backup domain.xml before modifying it.
Change to the config directory.
# cd /export/osso80adm/domains/ossodomain/config |
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>.
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 |
Verify that the certificate used for SSL communication is the root CA certificate.
Log out of the /osso2.idp-example.com host machine.
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. 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. |
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 OpenSSO Enterprise Load Balancer 2
To Install the Certificate Authority Root Certificate to OpenSSO Enterprise Load Balancer 2
To Install the Server Certificate to OpenSSO Enterprise Load Balancer 2
To Create an SSL Proxy for SSL Termination at the OpenSSO Enterprise Load Balancer 2
You should already have a root certificate from the CA of your choice. Generate a request for a server certificate to send to the 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.
Log in to the BIG-IP console as administrator.
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.
lb2.idp-example.com
Deployment
lb2.idp-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 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.
You should already have a root certificate from the CA of your choice. Install the CA root certificate on Load Balancer 2 to ensure that a link between it and the CA can be maintained. Use the same root certificate that you imported in 4.4 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.
Log in to the BIG-IP console as administrator.
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.
This procedure assumes you have received the server certificate requested in To Request a Certificate for OpenSSO Enterprise Load Balancer 2 and just completed To Install the Certificate Authority Root Certificate to OpenSSO Enterprise Load Balancer 2.
In the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
The key lb2.idp-example.com is in the Key List.
In the Certificate ID column, click Install for lb2.idp-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 lb2.idp-example.com page, click Return to Certificate Administration Information.
Verify that the Certificate ID indicates lb2.idp-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, in a web browser.
Log in to the BIG-IP console as administrator.
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.
OpenSSO-IDP-Pool
Round Robin
Add the IP addresses and port numbers for both OpenSSO Enterprise host machines.
User port number 1081.
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 a Virtual Server dialog box, provide the following information:
Enter the IP address for lb2.idp-example.com
1082
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the OpenSSO-IDP-Pool Pool.
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.
Configure the load balancer for persistence.
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 osso1.idp-example.com 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.22222.0000; path=/ is displayed. Save the numbered value (in this case, 692589248.22222.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 osso2.idp-example.com 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.33333.0000; path=/ is displayed. Save the numbered value (in this case, 692589248.33333.0000) for use in To Create a Site on OpenSSO Enterprise 1.
Log out of the load balancer console.
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.
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.
Log in to the BIG-IP console as administrator.
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.
Check the SSL and ServerSSL checkbox.
The IP address of Load Balancer 2.
1081
The secure port number
The IP address of Load Balancer 2.
1082
The non-secure port number
Choose Local Virtual Server.
Choose lb2.idp-example.com.
Choose lb2.idp-example.com.
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://lb2.idp-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.
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.
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
To Deploy the OpenSSO Enterprise WAR as OpenSSO Enterprise 1
To Copy the OpenSSO Enterprise WAR to the OpenSSO Enterprise 2 Host Machine
To Deploy the OpenSSO Enterprise WAR File as OpenSSO Enterprise 2
Log in to the osso1.idp-example.com host machine as root user.
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 |
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 |
The opensso.war file is owned by osso80adm.
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 osso1.idp-example.com host machine
On the osso1.idp-example.com 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 osso1.idp-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 osso1.idp-example.com host machine.
This procedure assumes you have completed To Generate an OpenSSO Enterprise WAR on the OpenSSO Enterprise 1 Host Machine.
Log in to the osso2.idp-example.com host machine as root user.
Switch to the non-root user osso80adm.
# su osso80adm |
Change into the osso80adm directory.
# cd /export/osso80adm |
Copy opensso.war from the osso1.idp-example.com 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.
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 osso2.idp-example.com host machine
On the osso2.idp-example.com 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 osso2.idp-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 osso2.idp-example.com host machine.
Access https://osso1.idp-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.
ossoadmin
ossoadmin
Accept the default values in Step 2: Server Settings and click Next
Do the following in Step 3: Configuration Store and click Next
Select Remote Directory in Step 4: User Store Settings, provide the following information and click Next
Check the box.
lb1.idp-example.com
489
dc=company,dc=com
dsmanager
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.
agentuser
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.
amadmin
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.
Log in to the osso1.idp-example.com host machine as the root user.
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 osso1.idp-example.com host machine.
Access https://osso2.idp-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.
ossoadmin
ossoadmin
Accept the default values in Step 2: Server Settings and click Next
Do the following in Step 3: Configuration Store and click Next
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.
amadmin
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.
Log in to the osso2.idp-example.com host machine as the root user.
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 osso2.idp-example.com host machine.
The Platform Service provides centralized configuration management for an OpenSSO Enterprise deployment. In this procedure, you configure the two instances of OpenSSO Enterprise 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.
It is not necessary to repeat this procedure on OpenSSO Enterprise 2.
Access https://osso1.idp-example.com:1081/opensso/console in a web browser.
Log in to the OpenSSO Enterprise console as the administrator.
amadmin
ossoadmin
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.
External
https://lb2.idp-example.com:1081/opensso
A new site called External is displayed in the Sites list.
Click on the https://osso1.idp-example.com:1081/opensso server entry under the Servers list.
The Edit https://osso1.idp-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 osso1.idp-example.com 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 OpenSSO Enterprise Load Balancer 2.
Click Back to Server and Sites.
Click on the https://osso2.idp-example.com:1081/opensso server entry under the Servers list.
The Edit https://osso2.idp-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 osso2.idp-example.com 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 OpenSSO Enterprise Load Balancer 2.
Click Back to Server and Sites.
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 osso1.idp-example.com host machine.
Restart the web container 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 osso2.idp-example.com host machine.
Restart the web container 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.
Access the load balancer at https://lb2.idp-example.com:1081/opensso/UI/Login.
If an error message is displayed indicating that the browser cannot connect to either osso1.idp-example.com or osso2.idp-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 Primary Site URL configured 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.
amadmin
ossoadmin
A successful login occurs when the site configuration is correct.
Log out of the OpenSSO Enterprise console.
Configure OpenSSO Enterprise on the identity provider side to recognize the Directory Server LDAP schema previously modified for SAML v2 attributes.
This procedure assumes you have completed 4.3 Modifying the Directory Server Schema.
Access https://lb2.idp-example.com:1081/opensso/console from a web browser.
Log in to the OpenSSO Enterprise console as the administrator.
amadmin
ossoadmin
The Common Tasks tab is displayed.
Click the Access Control tab and / (Top-level Realm) on the Access Control page.
Click the Data Stores tab.
Under the Data Stores tab, click embedded.
The Generic LDAPv3 page is displayed.
Add the following values to properties on the Generic LDAPv3 page.
Type sunFMSAML2NameIdentifier in the New Value box of the LDAP User Object Class property and click Add.
Add the following values to the LDAP User Attribute property.
Type sun-fm-saml2-nameid-infokey in the New Value box and click Add.
Type sun-fm-saml2-nameid-info in the New Value box and click Add.
Click Save on the Generic LDAPv3 page.
Log out of the OpenSSO Enterprise console.
This chapter contains instructions on configuring OpenSSO Enterprise to use the external user data store (set up in Chapter 4, Installing Sun Java System Directory Server and Creating Instances for User Data) for authentication credentials. 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.
Do not do both.
At this point in the deployment, the 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 modify the configuration details of the top-level realm to include the user data stores schema, allowing OpenSSO Enterprise to recognize users in the external user data store. Use the following list of procedures as a checklist for completing this task.
Access https://osso1.idp-example.com:1081/opensso/console in a web browser.
Log in to the OpenSSO Enterprise console as the administrator.
amadmin
ossoadmin
Click the Access Control tab.
Click / (Top Level Realm), the root realm, under the Access Control tab.
Click the Data Stores tab.
The embedded data store link is displayed.
Click embedded.
The Generic LDAPv3 properties page is displayed.
On the Generic LDAPv3 properties page, set the following attribute values and click Save.
Enter ou.
Enter Groups.
Enter ou.
Enter users.
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.
idpuser is 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.
You should be able to log in successfully as the test user.
Access https://osso1.idp-example.com:1081/opensso/UI/Login in a web browser.
Log in to the OpenSSO Enterprise console as the administrator.
idpuser
idpuser
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 previously 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.
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. Since the external user data store is an instance of Directory Server and not part of the embedded configuration data store, we create a sub realm and modify the configuration details to include the external user data stores schema, allowing OpenSSO Enterprise to recognize users in the Directory Server instances. The sub realm 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 Verify That the Sub Realm Can Access the External User Data Store
To Verify That the Sub Realm Subjects Can Successfully Authenticate
When a sub realm is created it inherits configuration data (including which user data store to access) from the root realm (by default, / (Top Level Realm)) and uses said data to authenticate users. The user data store can be modified per sub realm. In this deployment, we use the inherited Generic LDAPv3 data store.
Access https://osso1.idp-example.com:1081/opensso/console from a web browser.
Log in to the OpenSSO Enterprise console as the administrator.
amadmin
ossoadmin
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.
Enter users.
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.
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.
Click Back to Access Control.
This procedure assumes you have just completed To Change the User Profile Configuration for the Sub Realm and are still logged in to the OpenSSO Enterprise console.
Click users, the sub realm, under the Access Control tab.
Click the Data Stores tab.
The embedded data store link is displayed.
Click embedded.
The Generic LDAPv3 properties page is displayed.
On the Generic LDAPv3 properties page, set the following attribute values and click Save.
Enter ou.
Enter Groups.
Enter ou.
Enter users.
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.
idpuser is displayed under Users (as well as others created during OpenSSO Enterprise configuration).
Log out of the OpenSSO Enterprise console.
This optional procedure is to verify the modifications.
Access https://osso1.idp-example.com:1081/opensso/console from a web browser.
Log in to the OpenSSO Enterprise console as the administrator.
amadmin
ossoadmin
Click on the Access Control tab
Click on the users sub realm.
Click on the Subjects tab.
spuser is displayed under Users.
Log out of the OpenSSO Enterprise console.
Access https://osso1.idp-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 as a test user.
idpuser
idpuser
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.