Overview

This page specifies the requirements, and steps for clustered deployment of Ubisecure SSO. The scope of the document includes the overall deployment architecture, installation of reverse proxy, Installation of Ubisecure applications and LDAP.

Goals

The pursued goals affect the choice of clustering algorithms and deployment architecture. The possible goals, and recommended solutions for clustering each component of the Ubisecure SSO are the following:

High Availability
The system remains available despite a failing node. Improved availability is achieved using supported active/passive, High Availability clustering.
Scalability and High Availability
The system remains available despite a failing node, and can be scaled to serve more clients in a time unit. Improved performance is achieved using active/active clustering for SSO Server and Redis Cluster in-memory database cluster for storing session data.

Prerequisites

Competence in the following technologies is required for deploying a Ubisecure SSO cluster:

Application server clustering (included Tomcat Server)
Directory server clustering and replication (OpenLDAP for Linux / ADLDS for Windows)
Reverse proxy (Environment specific, not provided by Ubisecure)
Redis, in-memory data structure store (Not provided by Ubisecure)

High Level Architecture Overview, Recommended Clustering Setups

SSO High availability cluster

Diagram below describes the basic SSO high avalability cluster.

High availability is achieved by installing two SSO instances in active/passive cluster, so that there is one active SSO node, and another passive SSO node.

Note that Ubilogin Directory is replicated between two LDAP instances, but both SSO's use their own Ubilogin Directory. Optionally Ubilogin Directory services can be installed also into their own nodes.

Reverse proxy is configured to use primarily SSO1, and SSO2 only when SSO1 is not available.

SSO Scalability and High availability cluster

Diagram below describes the basic SSO scalability and high availability setup.

Scalability and high availability is achieved by installing two or more SSO instances, a Ubilogin Directory instances, and a Redis cluster that is used to store session related data. Reverse proxy is configured to even the load on the SSO instances.

If only two SSO instances are installed, the Ubilogin Directory instances can be installed in SSO nodes. If more than two SSO instances are installed, it's recommended to install a separate Ubilogin Directory cluster with two nodes.

Components

Reverse Proxy

Reverse proxy is used to take care of high availability and load balancing (in scalability setup only). Installed into a separate server node.

Ubisecure SSO server

SSO server instance running on Tomcat.

Ubilogin Directory

Stores the configurations, user and session data (SSO can be configured to use Redis backed session storage to improve performance.

Redis

Redis is a open source in-memory database project. https://redis.io/

SSO can be configured to use Redis backed session storage to improve performance.

Cluster Installation

Overview

An overview of deploying Ubisecure SSO cluster is described in the following steps:

Install Ubilogin Directory (ADLDS or OpenLDAP) in both nodes
Configure Ubilogin Directory replication
Configure all the Ubisecure SSO applications on the first node.
1. Install everything as instructed in the single node installation instructions, but do not run the last step (do not start SSO/Tomcat)
Copy the Ubisecure SSO configurations from the first node to the other node.
Install and configure the reverse proxy
Only on scalability setup: Install and configure Redis cluster, configure SSO to use Redis backed session storage
Start SSO in both nodes
Start reverse proxy

Cluster can be installed into windows or linux platforms

Installation steps

Browser not supported