Introduction

From redis.io

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability via Redis Sentinel and automatic partitioning with Redis Cluster.

This article and related sub-articles cover the topic of using Redis as a session storage for Ubisecure Identity Server, namely Ubisecure SSO as Ubisecure CustomerID does not use Redis at the moment. This document is relevant when planning a high-performance deployment of Ubisecure Identity Server.

For configuration and installation, please refer to

• How to install and configure Redis for Identity Server

References and links

Terminology

Addressing linear scalability with Redis

As mentioned, Ubisecure Identity Server can be deployed to high-availability or high-performance environments. When the anticipated maximum load of incoming authentication requests (logins) will exceed the advised capacity of a High-Availability environment then a High-Performance deployment model should be considered.

Currently the rough estimation of transactions per deployment type is as follows

High Availability deployment is meant for systems where failure of a component does not cause a service break. High Performance deployment model guarantees higher rate of login transactions as frequent write-intensive operations are performed on Redis instead of Ubilogin Directory. In this deployment model, Ubisecure SSO can serve requests using multiple instances, each being in active state. 

Failure tolerance

Replica election process

In a multi-node Redis deployment, failure tolerance is achieved through multi-master / multi-replica deployment where replicas take over primary nodes when those go down.

The replica election process is roughly as follows

• A replica election starts when a primary node is in failed state.
• A replica whose primary node is down starts the election.
  • In case of multi-replica setup, any of the replicas can start the election.
• Primary nodes participate to the election and vote for a replica to be promoted as primary.
• When a specific replica receives votes from majority of primary nodes it wins the election.

More detailed replica election process is described in the Redis Cluster specification.

Reference Architecture

The following diagram depicts Ubisecure's Reference Architecture for high performance deployments with Redis.

In this deployment model, Ubisecure SSO instances operate in active mode, serving incoming requests from external clients, through a proxy or a set of proxies. It is suggested that Ubilogin Directory instances reside close to SSO instances to minimize latency as LDAP still acts as a configuration storage. 

The deployment units should reside close to each other to minimize latency and issues in the case of network partitioning.

Proxies

Depending on the deployment model, the system is accessed through proxies or load balancers. Depending on the High-Availability requirements there can be many instances. This is out of the scope of this document but the general assumption is that the proxy layer can delegate traffic to all SSO instances that are active in the system.

SSO instances

Each of the SSO instances are able to process incoming requests in this deployment model. The reference architecture consists of two active instances but for linear scalability, the number of instances is not limited. However, the general suggestion is to start small and increase when there is a need to process more incoming requests. 

In this deployment model, LDAP acts mostly as a configuration storage. It must also be noted that LDAP instances must replicate the data as the data that is read from LDAP contains:

• Configurations for application integrations
• Configurations for authentication methods
• Authorization policies
• SSO Management and API users and groups
• Access and Refresh Tokens
• Persistent IDs

Redis cluster

Redis acts a Single-Sign-On session storage.

In order for a Redis cluster to be operational and failure tolerant, at least six Redis instances are needed. This means three primary instances and one replica for each. When increasing the number of primary instances, it is suggested to use an uneven number in order for the replica election process to be effective. As mentioned above, the election process only works if the majority of primary instances are available.

Instances can reside in the same physical or virtual execution environments as long as a replica for a particular primary instance is not in the same server. Redis cluster fails to operate if one of the primary instances and its replicas is unavailable. 

The data that is stored in Redis:

• Single-Sign-On sessions
• Access tokens
• Refresh Tokens (for caching)
• Persistent IDs (for caching)

Considerations

Disaster recovery

If disaster recovery is crucial requirement in the deployments where Ubisecure SSO is deployed in high-performance mode, it is suggested to avoid forming a Redis cluster across multiple data centers. This could introduce unnecessary latencies and unpredictability that has not been tested by Ubisecure. Also, in order for the replica election process to work, there must be uneven number of primary instances deployed. Having the same sized Redis clusters in two different data centers would mean that if one data center goes down, the replica election process would not work.

Instead, the two data centers should have their own Redis clusters and the other data center should act as a standby system. In case of failover, the end-users experience a loss of their SSO session and are required to authenticate again.

Migration session storage from LDAP to Redis

When migrating an existing deployment to use Redis as a session storage, it means that existing Single-Sign-On sessions are lost and users will be prompted to authenticate again.