Distributed Session Storage
In most production environments, it is expected that multiple replicas of the IBM Security Verify Access OIDC Provider (ISVAOP) service will be deployed to meet High Availability requirements. Given that several OpenID Connect and OAuth flows may involve multiple steps, such as authentication, consent and MFA, the short-lived session information that identifies the authorization request must be stored in a manner that it is accessible at each step.
Session refers to short lived context information stored during runtime flow. For example, the code generated during authorization code grant flow is stored in the session cache.
ISVAOP can be configured to use a Redis service to store such short-lived session information that is accessible from multiple ISVAOP instances. Sessions may also be stored in the Runtime Database.
The configuration for session_cache is in the storage.yml.
Redis
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.
It is an independent and external service which can act as a centralized session repository for an ISVAOP environment. Services in the environment can use the Redis server to provide failover for user sessions.
The Redis session cache provides the following benefits:
- Manages sessions across multiple ISVAOP instances;
- Resolves session inactivity and session lifetime timeout consistency issues in a replicated environment;
- Provides secure failover among different ISVAOP instances;
- Provides performance and high availability protection to the server environment in the event of hardware or software failure;
- Allows administrators to view and modify remote ISVAOP sessions using standard Redis tools.
Redis Failover
High availability in Redis is achieved by replicating from the master instance to the replicas.
A master Redis server can have multiple Redis servers as replicas, preferably deployed on different nodes. When the master is unavailable, one of the replicas can be promoted to become the new master and continue to serve data with little or no interruption.
Given the simplicity of Redis, there are many standard high-availability tools available that can monitor and manage a master-replica configuration. However, the most common HA solution that comes bundled with Redis is the Redis Sentinel. Redis Sentinels run as a set of separate processes that in combination monitor Redis master-replica sets and provide automatic failover and reconfiguration.
Configuration for Redis
The Redis session cache is enabled, and configured, using the storage.yml
runtime_db: mypq # Configuration of runtime database. Points to the database server connection.
session_cache:
type: redis # Specifies the type of session cache, in-memory, redis, or db.
cfg: redis-standalone # Specifies the configuration of the `redis` cache, for `redis` type only. Points to `redis` server connection
server_connections: # Server connections
- name: mypq # Connection name
...
- name: ldap_staging # Connection name
...
- name: redis-standalone # Connection name
type: redis # Connection type
deployment: # Redis deployment information. for `redis` type only
model: standalone # Deployment model. standalone or sentinel
# master: master # Master node information. For `sentinel` model only
hosts: # List of host information (IP and port)
- hostname: redis # Server's hostname
hostport: 6390 # Server's host port
credential: # Credential information to connect to the host.
username: isva # Specifies the username to access the server
password: 'OBF:oUqHV/2VlAeWb1D7uAdfQysti3vh44p5/rpCDR35gn4=' #
# Specifies the password for the redis server connection. It is recommended to obfuscate this.
ssl:
certificate: # The SSL connection certificate array.
- ks:redis_keys # The SSL keystore to be used for SSL connections. ks: indicates keystore.
mutual_auth:
key: ks:rt_profile_keys/redis # When mutual TLS is needed, specify the keystore and label that contains the client's private key.
certificate: ks:rt_profile_keys/redis # When mutual TLS is needed, specify the keystore and label of the client's leaf certificate.
ca: # The mutual_auth connection certificate array.
- ks:rt_profile_keys/ca # When mutual TLS is needed, specify the keystore and label of the client's CA certificate.
disable_hostname_verification: false # The SSL connection validates the hostname.
- Learn how to generate the keys and certificates in the Key Management topic.
- Learn how to obfuscate the password using Secrets
Configuration to use Runtime Database
- Session cache
typepoint to db, and theruntime_dbis used to store sessions.
runtime_db: hvdb # Configuration of runtime database. Points to the database server connection.
session_cache:
type: db # Specifies the type of session cache, in-memory, redis, or db.
server_connections: # Server connections
- name: hvdb # Connection name
type: postgresql # Connection type, `redis`, `ldap`, `postgresql`
database_name: verify-access # Specifies the database name. For database types only.
hosts: # List of host information (IP and port)
- hostname: pentest-isva-postgresql # Server's hostname
hostport: 5432 # Server's host port
credential: # Credential information to connect to the server
username: postgres # Specifies the username to access the server.
password: "OBF:U2FsdGVkX1+BPKsUsh0oGSsNNr1HSsAQWwPLB30MyDs="
# Specifies the password to access the server. It is recommended to obfuscate this.
ssl:
certificate:
- ks:isvaop_keys/postgres
disable_hostname_verification: true # Aged timeout, in seconds.
Updated over 1 year ago