OpenSSO Secure Token Server – 4

This blog is the final in a series that will describe how to deploy OpenSSO to protect Oracle WebLogic resources by configuring it as a Secure Token Server.

Part 1 is available here, part 2 is available here and part 3 is available here

Modify the WSS Configuration Files

The following steps describe how to configure OpenSSO WSS Agents.

  • Download and unzip the openssowssagents.zip file. This file contains OpenSSO Web Services Security Agents, based on JAX-WS Handlers.
  • Expand the zip file.
  • Copy the resources/keystore.jks, resources/.keypass, and resources/.storepass files to a convenient directory.  This directory is represented by @KEYSTORE_LOCATION@ in the <wssagents_unzip_location>/config/AMConfig.properties file.
  • Update AMConfig.properties for StockService as follows:

##### Following properties need to be updated for OpenSSO WSS Agents #####

com.iplanet.services.debug.directory=C:/Documents and Settings/Administrator/StockService/Debug

com.iplanet.am.naming.url=http://ws-provider.ltes.com:80/opensso/namingservice

com.iplanet.am.server.protocol=http

com.iplanet.am.server.host=ws-provider.ltes.com

com.iplanet.am.server.port=80

com.iplanet.am.services.deploymentDescriptor=/opensso

com.sun.identity.loginurl=http://ws-provider.ltes.com:80/opensso/UI/Login

com.sun.identity.saml.xmlsig.keystore=C:/Sun/Middleware/user_projects/domains/wss/resources/service.jks

com.sun.identity.saml.xmlsig.storepass=C:/Sun/Middleware/user_projects/domains/wss/resources/.storepass

com.sun.identity.saml.xmlsig.keypass=C:/Sun/Middleware/user_projects/domains/wss/resources/.keypass

com.sun.identity.saml.xmlsig.certalias=service

com.sun.identity.liberty.ws.trustedca.certaliases=cacert:Self-CA

com.sun.identity.wss.wsc.providername=

com.iplanet.am.cookie.encode=true

/*

* Security Credentials to read the configuration data

*/

com.sun.identity.agents.app.username=agentAuth

com.iplanet.am.service.password=changeit

com.iplanet.am.service.secret=

##### End of properties for OpenSSO WSS Agents #####

  • Update AMConfig.properties for StockClient as follows:

##### Following properties need to be updated for OpenSSO WSS Agents #####

com.iplanet.services.debug.directory=C:/Documents and Settings/Administrator/StockClient/Debug

com.iplanet.am.naming.url=http://ws-provider.ltes.com:80/opensso/namingservice

com.iplanet.am.server.protocol=http

com.iplanet.am.server.host=ws-provider.ltes.com

com.iplanet.am.server.port=80

com.iplanet.am.services.deploymentDescriptor=/opensso

com.sun.identity.loginurl=http://ws-provider.ltes.com:80/opensso/UI/Login

com.sun.identity.saml.xmlsig.keystore=C:/Sun/Middleware/user_projects/domains/wsc/resources/client.jks

com.sun.identity.saml.xmlsig.storepass=C:/Sun/Middleware/user_projects/domains/wsc/resources/.storepass

com.sun.identity.saml.xmlsig.keypass=C:/Sun/Middleware/user_projects/domains/wsc/resources/.keypass

com.sun.identity.saml.xmlsig.certalias=client

com.sun.identity.liberty.ws.trustedca.certaliases=cacert: Self-CA

com.sun.identity.wss.wsc.providername=

com.iplanet.am.cookie.encode=true

/*

* Security Credentails to read the configuration data

*/

com.sun.identity.agents.app.username=agentAuth

com.iplanet.am.service.password=changeit

com.iplanet.am.service.secret=

##### End of properties for OpenSSO WSS Agents #####

Modify the StockService Application

  • Expand the unsecured StockService.war file that was created previously using the following command:

jar -xvf StockService.war

  • Create a lib directory under the WEB-INF directory if lib does not exist already then, copy all <wssagents_unzip_location>/lib/*.jar files to the WEB-INF/lib directory.
  • Copy the <wssagents_unzip_location>/config/AMConfig.properties file to the WEB-INF/classes directory.
  • Merge the <wssagents_unzip_location>/config/server_handlers.xml file into the existing configuration file WEB-INF/classes/com/sun/stockquote.

The files must be merged so that the following handler is the first handler in the handler chain:

<handler>

<handler-name>

ServerHandler

</handler-name>

<handler-class>

com.sun.identity.wssagents.jaxws.server.ServerHandler

</handler-class>

</handler>

  • Build the secured StockService application into the StockService.war file with the following command:

jar -cvf StockService.war *

  • Deploy the StockService.war file to the WebLogic container.
  • Access the web service WSDL with the following URL:

http://ws-provider.ltes.com:7001/StockService/StockService?wsdl

Modify the StockClient Application

  • Expand the unsecured StockClient.war file that was created previously using the following command:

jar -xvf StockClient.war

  • Create a lib directory under the WEB-INF directory if lib does not exist already. Then, copy all <wssagents_unzip_location>/lib/*.jar files to the WEB-INF/lib directory.
  • Copy the previously updated AMConfig.properties file into the WEB-INF/classes directory.
  • Merge the <wssagents_unzip_location>/config/server_handlers.xml file into the existing configuration file WEB-INF/classes/server_handlers.xml.

The following handler must be the first handler in the handler chain:

<handler>

<handler-name>

ClientHandler

</handler-name>

<handler-class>

com.sun.identity.wssagents.jaxws.client.ClientHandler

</handler-class>

</handler>

  • Add the following client filter to the WEB-INF/web.xml file.

<filter>

<filter-name>

LoginFilter

</filter-name>

<filter-class>

com.sun.identity.wssagents.jaxws.client.ClientFilter

</filter-class>

</filter>

<filter-mapping>

<filter-name>

LoginFilter

</filter-name>

<url-pattern>

/*

</url-pattern>

</filter-mapping>

  • Build the secured StockClient application into the StockClient.war file with the following command:

jar -cvf StockClient.war *

  • Deploy the StockClient.war file to the WebLogic.
  • Access the web service client with a URL of the following form:

http://ws-client.ltes.com:8001/StockClient

  • The URL redirects to the OpenSSO Authentication service UI for end-user authentication to the default authentication module, as shown in the following figure:

  • After successfully authenticating to the OpenSSO server, the browser is redirected the StockClient application page.

  • Click GetQuote to display the web service response from the StockService application.
Advertisements

OpenSSO Secure Token Server – 3

This blog is the third in a series that will describe how to deploy OpenSSO to protect Oracle WebLogic resources by configuring it as a Secure Token Server.

Part 1 is available here and part 2 is available here.

Update the Web Service Provider Profile

The following steps describe how to create the Web Service Provider profile.

  • Click Web Service Provider. Under Agent click WSP.

  • Select all Security Mechanisms and set Preserve Security Headers in Message to true.

  • Click the checkboxes for Is Request Signature Verified, Is Response Signed.

  • Enter the Web Service End Point URL:

http://ws-provider.ltes.com:7001/StockService/StockService

  • Enter the key aliases, keystore location and password.

  • Save the changes.

Update the Agent Authenticator Profile

This Agent Authenticator (agentAuth) acts as the application user. It authenticates WSS agents to the OpenSSO server through the OpenSSO client SDK in order to retrieve agent profiles or configurations from the OpenSSO server. To do its job, agentAuth requires permission to read the configuration information of the newly created WSC and WSP agent profiles.

Set the agentAuth read permission as follows:

  • Select the Agent Authenticator tab.

  • Under Agent, click agentAuth to edit it.
  • Under the heading Agent Profiles allowed ensure that WSC and WSP are selected.
  • Save the changes and log out of OpenSSO.

Edit the Security Token Service Configuration Parameters

Log onto OpenSSO and navigate to Configuration -> Global -> Security Token Service.

Make the following changes:

  • In the Token Issuance Attributes section change the issuer to Self-CA and the Certificate Alias Name to opensso

  • In the Key Store section change the Private Key Alias and the Public Key Alias of Web Service (WS-Trust) Client to opensso.

  • In the Token Validation Attributes section change the Trusted Issuers to cacert:Self-CA.

Change the Cookie c66Encode Flag

The c66Encode flag resolves a problem whereby some application servers return the wrong cookie id if certain characters are used in the id.  C66Encoding ensures that those characters are not used in the cookie id.

Follow these steps to turn c66Encoding on.

  • Log onto the OpenSSO console and navigate to Configuration -> Servers and Sites.
  • Click the Default Servers Settings button.
  • Select the Advanced tab.
  • Change the value of com.iplanet.am.cookie.c66Encode to true

  • Save the changes
  • Restart the OpenSSO web container

OpenSSO Secure Token Server – 2

This blog is the second in a series that will describe how to deploy OpenSSO to protect Oracle WebLogic resources by configuring it as a Secure Token Server.

Part 1 is available here.

Configure the WebLogic Trust Keystores

Ensure that the WebLogic containers are using the keystore and trusted certificate stores crea:ted previously.  In Windows this can be done by editing the create service command file as follows

  • Edit the createSvc.cmd file to include the following JAVA_OPTIONS parameters for the web service container and save as createWSPSvc.cmd:
    set JAVA_OPTIONS=-Djavax.net.ssl.trustStore=C:\Sun\Middleware\user_projects\domains\wss\resources\cacerts
    -Djavax.net.ssl.keyStore=C:\Sun\Middleware\user_projects\domains\wss\resources\server.jks
    -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.keyStorePassword=changeit
  • Repeat for the web service client and OpenSSO containers.
  • Run the commands to create the services.
    For example:
    echo off
    SETLOCAL
    set DOMAIN_NAME=wsp
    set USERDOMAIN_HOME=C:\Sun\Middleware\user_projects\domains\wss
    set SERVER_NAME=AdminServer
    set PRODUCTION_MODE=false
    set JAVA_VENDOR=Sun
    set JAVA_HOME=C:\Sun\Middleware\jdk160_24
    set MEM_ARGS=-Xms256m -Xmx512m
    set JAVA_OPTIONS=
    -Djavax.net.ssl.trustStore=C:\Sun\Middleware\user_projects\domains\wsp\resources\cacerts
    -Djavax.net.ssl.keyStore=C:\Sun\Middleware\user_projects\domains\wsp\resources\server.jks
    -Djavax.net.ssl.trustStorePassword=changeit -Djavax.net.ssl.keyStorePassword=changeit
    call “C:\Sun\Middleware\wlserver_10.3\server\bin\installSvc.cmd”
    ENDLOCAL

Configure OpenSSO Web Service Profiles

Web Services Client http://ws-client.ltes.com:8001
Web Services Provider
http://ws-provider.ltes.com:7001
OpenSSO Server
http://opensso.ltes.com
This deployment uses the default WSC and WSP profiles shipped with OpenSSO.

  • Access the OpenSSO Console by entering the following URL:
    http://opensso.ltes.com/opensso
  • Log in to the OpenSSO Console as amadmin.
  • Go to Access Control -> Default realm -> Agents, as shown below:

Update the Web Service Client Profile

  • Select the Web Service Client tab:

  • In the Agent panel select WSC.
  • Click the WSC profile to edit it.
  • In the Security section select the STSSecurity as the Security Mechanism, SecurityTokenService as the STS Configuration and set Preserve Security Headers in Message as true.

  • Check Is Request Signed Enabled and Is Response Signature Verified in the Signing and Encryption section then uncheck all signing values except Body.

  • Enter the key aliases, keystore location and password

  • Save the changes.

OpenSSO – Secure Token Server

I think that the demise of OpenSSO has been greatly over exaggerated. There are positions open for people with OpenSSO skills and there are many forums with people asking for help in solving OpenSSO/OpenAM problems.

One question that comes up regularly is how to configure OpenSSO as a Secure Token Server.

This blog is the first in a series that will describe how to deploy OpenSSO to protect Oracle WebLogic resources by configuring it as a Secure Token Server.

A Secure Token Server is a third-party broker that allows a Web Service client to authenticate and receive a security token which is then sent to a Web Service Provider. The Web Service Provider validates the token and verifies that it came from a trusted secure token server.  It then uses the token to make authentication and authorization decisions.

Create and Deploy the SSL Certificates

This deployment uses self-signed certificates. The following instructions describe how to create and install them using OpenSSL and keytool.

  1. Create root certificate.
  2. Create the trusted certificates store
  3. Create key and signing requests.
  4. Sign the requests.
  5. Create the keystores.
  6. Add the public certificates to the keystores.

It is assumed that openssl.cfg has already been created.

Create the root certificate

openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config openssl.cnf

Create the trusted certificates store

openssl x509 -outform DER -in cacert.pem -out cacert.cert
keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias cacert -file cacert.cert

Create a Key and Signing Request

Client

openssl req -new -nodes -out clientReq.pem -keyout private/clientKey.pem -config openssl.cnf

Server

openssl req -new -nodes -out serverReq.pem -keyout private/serverKey.pem -config openssl.cnf

OpenSSO

openssl req -new -nodes -out openssoReq.pem -keyout private/openssoKey.pem -config openssl.cnf

Sign the Requests

Client

openssl ca -out clientCert.pem -config openssl.cnf -infiles clientReq.pem

Server

openssl ca -out serverCert.pem -config openssl.cnf -infiles serverReq.pem

OpenSSO

openssl ca -out openssoCert.pem -config openssl.cnf -infiles openssoReq.pem

Create the Keystores

The following instructions use the ImportKey class to import the keys into the Java keystore.

Client

  • Convert both, the key and the certificate into DER format
    openssl pkcs8 -topk8 -nocrypt -in private\clientKey.pem -inform PEM -out clientKey.der -outform DER
    openssl x509 -in clientCert.pem -inform PEM -out clientCert.der -outform DER
  • Import the files into the JKS
    java ImportKey clientKey.der clientCert.der
  • Copy and rename the keystore
    copy “\<home directory>\keystore.ImportKey client.jks
  • Change keystore password:
    keytool -keystore client.jks -storepasswd
  • Change certificate password:
    keytool -keypasswd -alias importkey -keypass importkey -new changeit -keystore client.jks
  • Change the alias
    keytool -keystore client.jks -storepass changeit -changealias -alias importkey -keypass changeit -destalias client
  • Check the Keystore Contents
    keytool -list -v -keystore client.jks

Server

  • Convert both, the key and the certificate into DER format
    openssl pkcs8 -topk8 -nocrypt -in private\serverKey.pem -inform PEM -out serverKey.der -outform DER
    openssl x509 -in serverCert.pem -inform PEM -out serverCert.der -outform DER
  • Import the files into the JKS
    java ImportKey serverKey.der serverCert.der
  • Copy and rename the keystore
    copy \<home directory>\keystore.ImportKey server.jks
  • Change keystore password:
    keytool -keystore server.jks -storepasswd
  • Change certificate password:
    keytool -keypasswd -alias importkey -keypass importkey -new changeit -keystore server.jks
  • Change the alias
    keytool -keystore server.jks -storepass changeit -changealias -alias importkey -keypass changeit -destalias server
  • Check the Keystore Contents
    keytool -list -v -keystore server.jks

OpenSSO

  • Convert both, the key and the certificate into DER format
    openssl pkcs8 -topk8 -nocrypt -in private\openssoKey.pem -inform PEM -out openssoKey.der -outform DER
    openssl x509 -in openssoCert.pem -inform PEM -out openssoCert.der -outform DER
  • Import the files into the JKS
    java ImportKey openssoKey.der openssoCert.der
  • Copy and rename the keystore
    copy \<home directory>\keystore.ImportKey opensso.jks
  • Change keystore password:
    keytool -keystore opensso.jks -storepasswd
  • Change certificate password:
    keytool -keypasswd -alias importkey -keypass importkey -new changeit -keystore opensso.jks
  • Change the alias
    keytool -keystore opensso.jks -storepass changeit -changealias -alias importkey -keypass changeit -destalias opensso
  • Check the Keystore Contents
    keytool -list -v -keystore opensso.jks

Add the Public Certificates to the KeyStores

Server

  • Add the Client Public Certificate
    keytool -importcert -alias client -trustcacerts -keystore server.jks -storepass changeit -file clientCert.der
  • Add the OpenSSO Public Certificate
    keytool -importcert -alias opensso -trustcacerts -keystore server.jks -storepass changeit -file openssoCert.der
  • Check the contents of the Keystore
    keytool -list -v -keystore server.jks
    Client
  • Add the Server Public Certificate
    keytool -importcert -alias server -trustcacerts -keystore client.jks -storepass changeit -file serverCert.der
  • Add the OpenSSO Public Certificate
    keytool -importcert -alias opensso -trustcacerts -keystore client.jks -storepass changeit -file openssoCert.der
  • Check the contents of the Keystore
    keytool -list -v -keystore client.jks

OpenSSO

  • Add the Client Public Certificate
    keytool -importcert -alias client -trustcacerts -keystore opensso.jks -storepass changeit -file clientCert.der
  • Add the Server Public Certificate
    keytool -importcert -alias server -trustcacerts -keystore opensso.jks -storepass changeit -file serverCert.der
  • Check the contents of the Keystore
    keytool -list -v -keystore opensso.jks

That’s it for now.  I’ll post the next installment next week.

Arsenal

I think that Arsene Wenger has bought well so far in this transfer window but he has to get a more disciplined and defensive minded midfielder in to replace Alex Song.  With two weeks of the transfer window remaining I’ve decided not to give my opinion on the team until it closes.

OpenSSO – HA Across Data Centers Configuration 2

This is the final installment of the discussion about deploying OpenSSO in a high availability configuration across two data centers.

In the previous installment OpenSSO was configured as two separate sites one for each data center.

Configuration with a Single Logical Grouping of OpenSSO Servers

The load balancer in each data center is configured to connect to both the local and remote OpenSSO servers.

They are configured to communicate with their local OpenSSO servers by default and route requests to the remote servers if both local OpenSSO instances are down. Session stickiness settings are configured in both load balancers across all OpenSSO servers in both data centers.

The main benefit of adopting this configuration is to reduce the amount of back channel server-to-server communications. Since all load balancers can connect to any OpenSSO server in both data centers it’s not necessary to route traffic via an OpenSSO server during fail-over as is the case with the previous configuration.


The OpenSSO configuration to implement this solution is:

Use Cases

The following use cases describe what happens during fail-over with this configuration.

These use cases assume that the user session is initially created on Svr1 via LB1 and that fail-over occurs when ClientA tries to validate the user session later on.

Case 1: LB1 is up, Svr1 is down and Svr2 is up

  1. The session validation user request goes to Svr2 via LB1.
  2. Svr2 detects the host server for this particular session (Svr1) is down and selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on one of the three running OpenSSO instances Svr2, Svr3 or Svr4.
  3. If the backup server is Svr2:
    1. The user session is recovered on Svr2. The session stickiness cookie is now set to Svr2.
    2. All subsequent requests for this session will be routed to Svr2 via LB1.
  4. If the backup server is Svr3:
    1. The request is forwarded to Svr3.
    2. The user session is recovered on Svr3. The session stickiness cookie is now set to Svr3.
    3. All subsequent requests for this session will be routed to Svr3 via LB1.
  5. If the backup server is Svr4:
    1. The request is forwarded to Svr4.
    2. The user session is recovered on Svr4. The session stickiness cookie is now set to Svr4.
    3. All subsequent requests for this session will be routed to Svr4 via LB1.

Case 2: LB1 is up, both Svr1 and Svr2 are down

  1. Because LB1 is connected to all of the four OpenSSO servers it can forward the request to either Svr3 or Svr4.
  2. Svr3 receives the request.
    1. Svr3 detects the primary server hosting this session (Svr1) is down.
    2. Svr3 selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on either Svr3 or Svr4.
    3. If the backup server is Svr3:
      1. The user session is recovered on Svr3. The session stickiness cookie is now set to Svr3.
      2. All subsequent requests for this session will be routed to Svr3 via LB1.
    4. If the backup server is Svr4:
      1. The request is forwarded to Svr4.
      2. The user session is recovered on Svr4. The session stickiness cookie is now set to Svr4.
      3. All subsequent requests for this session will be routed to Svr4 via LB1.
  3. Svr4 receives the request.
    1. Svr4 detects the primary server hosting this session (Svr1) is down.
    2. Svr4 selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on either Svr3 or Svr4.
    3. If the backup server is Svr3:
      1. The request is forwarded to Svr3.
      2. The user session is recovered on Svr3. The session stickiness cookie is now set to Svr3.
      3. All subsequent requests for this session will be routed to Svr3 via LB1.
    4. If the backup server is Svr4:
      1. The user session is recovered on Svr4. The session stickiness cookie is now set to Svr4.
      2. All subsequent requests for this session will be routed to Svr4 via LB1.

Case 3: LB1 is down and Svr1 is down

  1. The Site Monitor in the Client SDK detects LB1 is unreachable so the session validation request is forwarded to LB2.
  2. LB2 checks the session stickiness routing cookie and tries to send the request to Svr1. But since Svr1 is down either Svr3 or Svr4 receives the request.
  3. Svr3 detects the primary server hosting this session (Svr1) is down.
  4. Svr3 selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on one of the three running OpenSSO instances Svr2, Svr3 or Svr4.
  5. If the backup server is Svr2,
    1. The request is forwarded to Svr2.
    2. The user session is recovered on Svr2. The session stickiness cookie is now set to Svr2.
    3. All subsequent requests for this session will be routed to Svr2 by LB2.
  6. If the backup server is Svr3:
    1. The user session is recovered on Svr3. The session stickiness cookie is now set to Svr3.
    2. All subsequent requests for this session will be routed to Svr3 via LB2.
  7. If the backup server is Svr4:
    1. The request is forwarded to Svr4.
    2. The user session is recovered on Svr4. The session stickiness cookie is now set to Svr4.
    3. All subsequent requests for this session will be routed to Svr4 via LB2.

Case 4: LB1 is down and Svr1 is up

  1. The Site Monitor in the Client SDK detects LB1 is unreachable so the session validation request is forwarded to LB2.
  2. LB2 checks the session stickiness routing cookie and sends the request to Svr1.
  3. All subsequent requests for this session will be routed to Svr1 via LB2.

Finally

OpenSSO out-of-the-box provides service fail-over to address the requirement of infrastructure redundancy within data centers and session fail-over to achieve state redundancy within each deployment site. In most cases these HA product features are sufficient. However, there are sometimes requirements for cross-site session fail-over. Although this feature was not added to OpenSSO before the Oracle purchase of Sun MicroSystems the product itself can be configured to meet this requirement with a special OpenSSO Site configuration as described in these posts.

The potential performance impact with both presented solutions depends on the network bandwidth in the WAN environment.  This is because a large number of cross-site communications is expected to occur between the data centers.

OpenSSO – HA Across Data Centers Configuration 1

This is the second part of the discussion about deploying OpenSSO in a high availability configuration across two data centers.

Although, I’ve not tested these configurations with OpenAM I believe they should work.

Configuration with Two Groups of OpenSSO Servers

The environment consists of two independent data centers, each of them having two OpenSSO instances deployed in an HA configuration behind a load balancer.

This configuration limits the load-balancer in each data center to connect only to the OpenSSO servers in the same geographical site. This avoids having to make the local load-balancer aware of the other OpenSSO servers in the remote data center and simplifies the deployment. However, in the case of a fail-over, this configuration increases the possibility of back channel communication between the OpenSSO servers in the two data centers.

The OpenSSO configuration to implement this solution is:

Use Cases

The following use cases describe what happens during fail-over with this configuration.

These use cases assume that the user session is initially created on Svr1 via LB1 and the fail-over occurs when ClientA tries to validate the user session later on.

Case 1: LB1 is up, Svr1 is down and Svr2 is up

  1. The session validation user request goes to Svr2 via LB1.
  2. Svr2 detects the host server for this particular session (Svr1) is down and selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on one of the three running OpenSSO instances Svr2, Svr3 or Svr4.
  3. If the backup server is Svr2,
    1. The user session is recovered on Svr2. The session stickiness cookie is now set to Svr2.
    2. All subsequent requests for this session will go to Svr2 via LB1.
  4. If the backup server is Svr3,
    1. The user session is recovered on Svr3. The session stickiness cookie is now set to Svr3.
    2. All subsequent requests for this session will first land on Svr2 via LB1 and then get forwarded to Svr3.
  5. If the backup server is Svr4,
    1. The user session is recovered on Svr4. The session stickiness cookie is now set to Svr4.
    2. All subsequent requests for this session will first land on Svr2 via LB1 and then get forwarded to Svr4.

Case 2: LB1 is up and both Svr1 and Svr2 are down

  1. The Site Monitor in the Client SDK detects that no OpenSSO servers behind LB1 are available so the session validation request is forwarded to LB2.
  2. Either Svr3 or Svr4 receives the request.
  3. If Svr3 receives the request:
    1. Svr3 detects the primary server hosting this session (Svr1) is down.
    2. Svr3 selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on either Svr3 or Svr4.
    3. If the backup server is Svr3:
      1. The user session is recovered on Svr3.
      2. All subsequent requests for this session will go to Svr3 via LB2.
    4. If the backup server is Svr4,
      1. The request is forwarded to Svr4.
      2. The user session is recovered on Svr4.
      3. All subsequent requests for this session will go to Svr4 via LB2.
  4. If Svr4 receives the request:
    1. Svr4 detects the primary server hosting this session (Svr1) is down.
    2. Svr4 selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on either Svr3 or Svr4.
    3. If the backup server is Svr3:
      1. The request is forwarded to Svr3.
      2. The user session is recovered on Svr3.
      3. All subsequent requests for this session will go to Svr3 via LB2.
    4. If the backup server is Svr4:
      1. The user session is recovered on Svr4.
      2. All subsequent requests for this session will go to Svr4 via LB2.

Case 3: LB1 is down and Svr1 is down

  1. The Site Monitor in the Client SDK detects LB1 is unreachable so the session validation request is forwarded to LB2.
  2. Either Svr3 or Svr4 receives the request.
  3. If Svr3 receives the request:
    1. Svr3 detects the primary server hosting this session (Svr1) is down.
    2. Svr3 selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on one of the three running OpenSSO instances Svr2, Svr3 or Svr4.
    3. If the backup server is Svr2:
      1. The request is forwarded to Svr2.
      2. The user session is recovered on Svr2.
      3. All subsequent requests for this session will first land on Svr3 via LB2 and then get forwarded to Svr2.
    4. If the backup server is Svr3:
      1. The user session is recovered on Svr3.
      2. All subsequent requests for this session will go to Svr3 via LB2.
    5. If the backup server is Svr4:
      1. The user session is recovered on Svr4.
      2. All subsequent requests for this session will go to Svr4 via LB2.
  4. If Svr4 receives the request:
    1. Svr4 detects the primary server hosting this session (Svr1) is down.
    2. Svr4 selects the backup OpenSSO server to serve the request . Based on the OpenSSO IRR logic the user session could be recovered on one of the three running OpenSSO instances Svr2, Svr3 or Svr4.
    3. If the backup server is Svr2:
      1. The request is forwarded to Svr2.
      2. The user session is recovered on Svr2.
      3. All subsequent requests for this session will first land on Svr4 via LB2 and then get forwarded to Svr2.
    4. If the backup server is Svr3:
      1. The user session is recovered on Svr3.
      2. All subsequent requests for this session will go to Svr3 via LB2.
    5. If the backup server is Svr4:
      1. The user session is recovered on Svr4.
      2. All subsequent requests for this session will go to Svr4 via LB2.

Case 4: LB1 is down and Svr1 is up

  1. The Site Monitor in the Client SDK detects that LB1 is unreachable so the session validation request is forwarded to LB2.
  2. Either Svr3 or Svr4 receives the request.
  3. Svr3/Svr4 detects the primary server hosting this session (Svr1) is up.
  4. Svr3/Svr4 then forwards the request to Svr1 for session validation.
  5. All subsequent requests for this session will first land on Svr3/Svr4 via LB2 and then get forwarded to Svr1.

The OpenSSO IRR logic will also identify when the primary server hosting the user session is back in service and resume routing traffic to it.

OpenSSO – High Availability Across Data Centers

The definition of high availability varies depending on the context but in general it covers infrastructure and state redundancy.  Both of which are provided in OpenSSO.

A customer required OpenSSO to be deployed to provide high availability between two data centers with the following high-level requirements:

  • There were two data centers established in different geographical locations each with more than one OpenSSO instance installed and configured.  A load balancer serving as the sole entry point to the data center was deployed in front of the OpenSSO servers to achieve high availability and fail-over.
  • Client applications using the OpenSSO Client SDK were configured to talk to the nearest data center for user authentication and session validation.  However, it was also required that the OpenSSO Client SDK be capable of routing the user requests to the remote data centers in case the primary data center was down. This was accomplished via the Site Monitoring logic implemented in OpenSSO.
  • The processing of new authentication requests after a failure had to be guaranteed (Infrastructure Redundancy).
  • If the user was already authenticated, the fail-over logic built into OpenSSO had to guarantee that the session state be retained even though the primary data center or the primary OpenSSO server hosting the user session was down (State Redundancy).
  • Fail-over from the primary data center to the backup data center for user authentication and session validation had to be transparent to the end users.

In order to meet the requirements described above network connectivity between data centers had to be allowed for the message broker and for the back channel communication between the OpenSSO servers located in the data centers.  In addition, because of the potential performance impact of the proposed solutions,  it was important that there was good network bandwidth between the data centers.

It is important to note that with either solution there would be a lot of cross-site communications whether or not fail-over occurred.  This was because session fail-over was to be configured across both data centers and so every session write would result in a message call to the remote Berkeley Database component.

The next two posts will describe the proposed solutions.