Storing session state in an external Redis session repository

This article describes how to store Airlock IAM session state in a Redis session repository.

Airlock IAM heavily relies on session state stored server-side. Most requests processed by Airlock IAM must be able to access the up-to-date session state. If multiple IAM instances are active, how session information is stored and that it can be shared among the IAM instances is relevant.

As of IAM 8.1, the feature is available for the Loginapp and Adminapp. More modules will be supported in future releases (see tables below).

What is Redis?

Redis is a fast and proven open-source data storage solution that can be used as a distributed cache.

• There are two places to store session state:
• In the local memory of the IAM instance. This is the default.
• In an external Redis session repository. How to set this up is described in this article.

Storing session state in an external session repository has many advantages and is especially useful in active-active setups, mostly in cloud environments such as Kubernetes. The challenge in such environments is typically maintaining a session state for short-lived containers and non-session-sticky load balancing.

• Advantages of storing session state in Redis:
• Load balancing does not need to be session-sticky.
• Allows horizontal scaling.
• Better support cloud-native environments (short-lived IAM containers).
• No session loss in failover situations.
• Basis for future upgrades at runtime (rolling updates).

• Disadvantages of storing session state in Redis:
• Requires Redis session repository (not part of Airlock IAM).
• Small negative impact on performance (due to communication with Redis).

Storing session state in Redis is thought for production environments with a separately managed IAM configuration. The Config Editor does not work in active-active setups and it is therefore not possible to configure a cluster of active IAM instances using the Config Editor running in these instances.

0. Instead, do the following:
1. Manage the configuration for the IAM cluster in a separate IAM instance (e.g. single-instance IAM setup for configuration).
2. Store the resulting IAM configuration XML file.
3. Make the configuration available to the IAM instances that are part of the cluster.

We recommend using Configuration variables or Configuration environments to manage configuration for different stages.

• If using a shared instance folder for multiple active instances, consider the following:
• Most files in the instance directory are read-only, but not all.
• Ensure that multiple active IAM instances do not overwrite files from each other. This is especially true for:
• .activated-configs (each IAM instance writes the configuration it activates)
• log files
• generated reports (e.g. password letters)
• Where possible, adapt the configuration so files written by IAM instances are placed outside the shared instance folder.

Note that not all IAM features and modules support this feature. Check the limitations section below for further details.

0. To enable the feature, proceed as follows:
1. Go to:
   MAIN SETTINGS

If not using MAIN SETTINGS, the feature can be directly configured in the affected IAM modules (e.g. Loginapp, Adminapp).

2. In property State Repository, add and edit the Redis State Repository plugin.
3. Configure the connection to Redis (Redis URI, Username, Password). You may use the Testlet (the yellow flash) to test the connection.
4. Configure TLS Settings and Performance Tuning properties as required.

Important security advisory

In Airlock IAM 8.1, session information in Redis is not encrypted.

Since session information includes sensitive information, it is essential that the connection to Redis is protected and only legitimate service accounts have access to the data in Redis.

• Configure Redis and the Redis State Repository plugin such that:
• Data in transit between IAM and Redis is encrypted using sensible TLS settings.
• Ensure IAM can verify that it connects to the correct Redis endpoint (verify server hostname with meaningful server certificate).
• Ensure that legitimate systems and administrators know the username and password used to access Redis.
• To further secure the connection, consider using client certificates.

Note that it is planned for IAM 8.2 to encrypt session information in Redis.

• Other configuration options to consider when using the Redis State Repository:
• If using many active IAM instances in parallel:
• Note that connection pools 3rd-party systems (e.g. DB connections) are created per instance. This may result in more connections than the 3rd-party system can handle.
• Consider reconfiguring the connection pools depending on the number of IAM instances.
• If accepting SSO tickets in authentication flows or using User representation:
• It is highly recommended to store accepted SSO tickets in the IAM database (instead of the memory).
• Note that Accepted SSO tickets stored in memory are not stored in the Redis session repository.
• Review the session timeout settings in the Loginapp and Adminapp modules (Session Idle Timeout and Session Lifetime in the Advanced Settings property group).

Storing session states in Redis is not supported for all IAM features. The following tables show what features can be used with Redis and what is planned to be supported in future IAM releases.

The Loginapp is supported with the following exceptions:

The Adminapp is supported with the following exceptions:

• Internal Links
• Configuration environments
• Using environment variables in the IAM configuration
• Airlock IAM instances directory
• SSO ticket authentication in the Loginapp REST API
• User representation – representee configuration in the Loginapp REST API

• External Links
• https://redis.com