Redis Software release notes 8.0.6-54 (December 2025)

Summary: Single sign-on for the Cluster Manager UI. Error reports for Replica Of migration status. Automatically download and install user-defined modules during bootstrapping.

Overview

[Redis Software version 8.0.6](https://redis.io/downloads/#Redis_Software) is now available! This release includes API enhancements that warranted a new minor version instead of a maintenance release for version 8.0.2. However, you can upgrade from 8.0.2 to 8.0.6 without issue.

Highlights

This version offers:

- Single sign-on for the Cluster Manager UI

- Error reports for Replica Of migration status

- Automatically download and install user-defined modules during bootstrapping

New in this release

New features

#### Single sign-on for the Cluster Manager UI {#sso}

Redis Software now supports IdP-initiated and SP-initiated single sign-on (SSO) with SAML (Security Assertion Markup Language) 2.0 for the Cluster Manager UI.

When SSO is activated:

- Users can sign in to the Redis Software Cluster Manager UI using their identity provider (IdP) instead of usernames and passwords.

- Optionally, you can enforce SSO for the cluster, which means non-admin users can no longer sign in with their previous usernames and passwords and must use SSO instead.

- With just-in-time (JIT) user provisioning, Redis Software automatically creates a user account the first time a new user signs in with SSO.

For more information and setup instructions, see [SAML single sign-on]().

Known limitation: You cannot change the default service provider address using the Cluster Manager UI. You can only change this address using a REST API request.

Enhancements

- Added error report to Replica Of [migration status]() REST API responses.

- Added support for automatically downloading and installing user-defined modules during bootstrap operations. You can now specify `user_defined_modules` in [bootstrap requests]() for `create_cluster`, `join_cluster`, and `recover_cluster` actions. See [Add user-defined modules during bootstrapping]() for details.

- Added `cert` and `private_key` fields to the [CRDB database config object]() for an optional PEM-encoded server certificate for the underlying database instance.

Redis database versions

Redis Software version 8.0.6 includes five Redis database versions: 8.2.1, 8.0.2, 7.4.3, 7.2.7, and 6.2.13.

The [default Redis database version]() is 8.2.

Redis feature sets

Redis Software includes multiple feature sets, compatible with different Redis database versions.

The following table shows which Redis modules are compatible with each Redis database version included in this release.

| Redis database version | Compatible Redis modules |
|------------------------|--------------------------|
| 8.2 | RediSearch 8.2
RedisJSON 8.2
RedisTimeSeries 8.2
RedisBloom 8.2
See [What's new in Redis 8.2]() and [Redis Open Source 8.2 release notes]() |
| 8.0 | RediSearch 8.0
RedisJSON 8.0
RedisTimeSeries 8.0
RedisBloom 8.0
See [What's new in Redis 8.0]() and [Redis Open Source 8.0 release notes]() |
| 7.4 | [RediSearch 2.10]()
[RedisJSON 2.8]()
[RedisTimeSeries 1.12]()
[RedisBloom 2.8]() |
| 7.2 | [RediSearch 2.8]()
[RedisJSON 2.6]()
[RedisTimeSeries 1.10]()
[RedisBloom 2.6]() |
| 6.2 | [RediSearch 2.6]()
[RedisJSON 2.4]()
[RedisTimeSeries 1.8]()
[RedisBloom 2.4]() |

Resolved issues

- RS131972: Fixed an issue where creating an ACL that contains a line break in the Cluster Manager UI could cause shard migration to fail due to ACL errors.

- RS140424: Fixed an issue where configuration changes initiated topology updates even if the topology did not change.

- RS144636: Improved support package generation to collect available database information even when some data collection steps fail.

- RS162503: Fixed an issue where force-removed Active-Active database instances could not be re-added as participating members without purging.

- RS155782: Improved logs and added validation to ensure operations are properly queued and prevent stuck state machines.

- RS167151: Improved reliability of node removal operations by increasing retry attempts for failover and reshard operations.

- RS167280: Fixed an issue where a subset of shards on a restarted node could fail to start due to temporary connection issues.

- RS172813: Improved logging for Active-Active database failover scenarios to provide better visibility into data recovery processes.

- RS173195: Fixed an issue where cluster operations could fail when attempting to communicate with unreachable nodes.

- RS174154: Fixed an issue where EntraID authentication service was not properly enabled despite being configured and running.

- RS174819: Fixed an issue where duplicate syncers could spawn on the same node.

- RS176400: Fixed an issue where Google Cloud Storage backup locations could be set to the incorrect type when configured in the Cluster Manager UI.

- RS165983: Fixed an issue where an incorrect value was printed for `region_name` in the event log.

Version changes

Supported platforms

The following table provides a snapshot of supported platforms as of this Redis Software release. See the [supported platforms reference]() for more details about operating system compatibility.

✅ Supported – The platform is supported for this version of Redis Software and Redis Stack modules.

:warning: Deprecation warning – The platform is still supported for this version of Redis Software, but support will be removed in a future release.

| Redis Software
major versions | 8.0 | 7.22 | 7.8 | 7.4 | 7.2 | 6.4 | 6.2 |
|---------------------------------|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|
| **Release date** | Oct 2025 | May 2025 | Nov 2024 | Feb 2024 | Aug 2023 | Feb 2023 | Aug 2021 |
| [**End-of-life date**]() | Determined after
next major release | Oct 2027 | May 2027 | Nov 2026 | Feb 2026 | Aug 2025 | Feb 2025 |
| **Platforms** | | | | | | | |
| RHEL 9 &
compatible distros[1](#table-note-1) | ✅ | ✅ | ✅ | ✅ | – | – | – |
| RHEL 9
FIPS mode[5](#table-note-5) | ✅ | ✅ | ✅ | – | – | – | – |
| RHEL 8 &
compatible distros[1](#table-note-1) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| RHEL 7 &
compatible distros[1](#table-note-1) | – | – | – | – | :warning: | :warning: | :warning: |
| Ubuntu 22.04[2](#table-note-2) | ✅ | ✅ | ✅ | – | – | – | – |
| Ubuntu 20.04[2](#table-note-2) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | – |
| Ubuntu 18.04[2](#table-note-2) | – | – | – | :warning: | :warning: | :warning: | :warning: |
| Ubuntu 16.04[2](#table-note-2) | – | – | – | – | :warning: | :warning: | :warning: |
| Amazon Linux 2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | – |
| Amazon Linux 1 | – | – | – | – | :warning: | :warning: | :warning: |
| Kubernetes[3](#table-note-3) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Docker[4](#table-note-4) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |

1. The RHEL-compatible distributions CentOS, CentOS Stream, Alma, and Rocky are supported if they have full RHEL compatibility. Oracle Linux running the Red Hat Compatible Kernel (RHCK) is supported, but the Unbreakable Enterprise Kernel (UEK) is not supported.

2. The server version of Ubuntu is recommended for production installations. The desktop version is only recommended for development deployments.

3. See the [Redis Enterprise for Kubernetes documentation]() for details about support per version and Kubernetes distribution.

4. [Docker images]() of Redis Software are certified for development and testing only.

5. Supported only if [FIPS was enabled during RHEL installation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening#proc_installing-the-system-with-fips-mode-enabled_switching-rhel-to-fips-mode) to ensure FIPS compliance.

Downloads

The following table shows the SHA256 checksums for the available packages:

| Package | SHA256 checksum (8.0.6-54 December release) |
|---------|---------------------------------------|
| Ubuntu 20 | 70ef3f95bc8bc16e988e8f5572a3956d2ab3068a7d069ce03578ca2a30431301 |
| Ubuntu 22 (amd64) | 576653f63613be103fcf8e1cd7760f6373bbc12a698ab59a12b452ea8f967fd4 |
| Ubuntu 22 (arm64) | 422635cdf0231a59aa9bb2e27c9fca8a13e1ea145ccd002159e66085d6b271e2 |
| Red Hat Enterprise Linux (RHEL) 8 | fa744961e7075a506b6456a9bb70b19e02b31f172ea6c9ef2154f80dfb5c1dcb |
| Red Hat Enterprise Linux (RHEL) 9 | 9c4c24ee3086ad8d595dc6fea2865b6520f07f8f589c214efae5229040727ac8 |
| Amazon Linux 2 | 8bd6008bc9036b675d57f3995f5a4725e264db86c981f940cada4529b001d3f7 |

Known issues

- RS180550: You cannot set up SSO when the Cluster Manager UI is exposed through an IPv6-based load balancer or gateway.

    As a workaround, use an IPv4-based address for the SSO service base address, or register a DNS name that resolves to the IPv6 address.

- RS155734: Endpoint availability metrics do not work as expected due to a calculation error.

Known limitations

#### Cannot change SP address for SSO in the Cluster Manager UI

You cannot change the default service provider address using the Cluster Manager UI. You can only change this address using a REST API request.

#### Rolling upgrade limitation for clusters with custom or deprecated modules

Due to module handling changes introduced in Redis Software version 8.0, upgrading a cluster that contains custom or deprecated modules, such as RedisGraph and RedisGears v2, can become stuck when adding a new node to the cluster during a rolling upgrade.

#### Module commands limitation during Active-Active database upgrades to Redis 8.0

When upgrading an Active-Active database to Redis version 8.0, you cannot use module commands until all Active-Active database instances have been upgraded. Currently, these commands are not blocked automatically.

#### Redis 8.0 database cannot be created with flash

You cannot create a Redis 8.0 database with flash storage enabled. Create a Redis 8.0 database with RAM-only storage instead, or use Redis 8.2 for flash-enabled (Redis Flex) databases.

#### Cluster Manager UI limitations

The following legacy UI features are not yet available in the new Cluster Manager UI:

- Purge an Active-Active instance.

    Use [`crdb-cli crdb purge-instance`]() instead.

- Search and export the log.

Security

#### Redis Open Source security fixes compatibility

As part of Redis's commitment to security, Redis Software implements the latest [security fixes](https://github.com/redis/redis/releases) available with [Redis Open Source](https://github.com/redis/redis). Redis Software has already included the fixes for the relevant CVEs.

Some CVEs announced for Redis Open Source do not affect Redis Software due to different or additional functionality available in Redis Software that is not available in Redis Open Source.

Redis Software 8.0.6-54 supports Redis Open Source 8.2, 8.0, 7.4, 7.2, and 6.2. Below is the list of Redis Open Source CVEs and other security vulnerabilities fixed by version.

Redis 8.2.x:

- RedisBloom: Restore invalid filter.

- (CVE-2025-62507) A user can run the `XACKDEL` command with multiple IDs and trigger a stack buffer overflow, which can potentially lead to remote code execution.

- The `HGETEX` command can lead to a buffer overflow.

- Integer overflow in `hllPatLen`.

- RedisBloom: Cuckoo filter counter overflow.

- RedisBloom: Invalid Bloom filters can cause arbitrary memory reads and writes.

- RedisBloom: Reachable assert in `TopK_Create`

- RedisBloom: Out-of-bounds access with empty Bloom chains.

- RedisBloom: Division by zero in Cuckoo filter insertion.

- (CVE-2025-46818) An authenticated user may use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user.

- (CVE-2025-46819) An authenticated user may use a specially crafted LUA script to read out-of-bound data or crash the server and lead to subsequent denial of service.

- (CVE-2025-46817) An authenticated user may use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution.

- (CVE-2025-49844) An authenticated user may use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free, and potentially lead to remote code execution.

Redis 8.0.x:

- RedisBloom: Restore invalid filter.

- The `HGETEX` command can lead to a buffer overflow.

- Integer overflow in `hllPatLen`.

- RedisBloom: Cuckoo filter counter overflow.

- RedisBloom: Invalid Bloom filters can cause arbitrary memory reads and writes.

- RedisBloom: Reachable assert in `TopK_Create`

- RedisBloom: Out-of-bounds access with empty Bloom chains.

- RedisBloom: Division by zero in Cuckoo filter insertion.

- (CVE-2025-46818) An authenticated user may use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user.

- (CVE-2025-46819) An authenticated user may use a specially crafted LUA script to read out-of-bound data or crash the server and lead to subsequent denial of service.

- (CVE-2025-46817) An authenticated user may use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution.

- (CVE-2025-49844) An authenticated user may use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free, and potentially lead to remote code execution.

Redis 7.4.x:

- RedisBloom: Restore invalid filter.

- Integer overflow in `hllPatLen`.

- RedisBloom: Cuckoo filter counter overflow.

- RedisBloom: Invalid Bloom filters can cause arbitrary memory reads and writes.

- RedisBloom: Reachable assert in `TopK_Create`

- RedisBloom: Out-of-bounds access with empty Bloom chains.

- RedisBloom: Division by zero in Cuckoo filter insertion.

- (CVE-2025-46818) An authenticated user may use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user.

- (CVE-2025-46819) An authenticated user may use a specially crafted LUA script to read out-of-bound data or crash the server and lead to subsequent denial of service.

- (CVE-2025-46817) An authenticated user may use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution.

- (CVE-2025-49844) An authenticated user may use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free, and potentially lead to remote code execution.

- (CVE-2025-32023) An authenticated user can use a specially crafted string to trigger a stack/heap out-of-bounds write on HyperLogLog operations, which can lead to remote code execution.

- (CVE-2025-21605) An unauthenticated client can cause unlimited growth of output buffers until the server runs out of memory or is terminated, which can lead to denial-of-service.

Redis 7.2.x:

- RedisBloom: Restore invalid filter.

- Integer overflow in `hllPatLen`.

- RedisBloom: Cuckoo filter counter overflow.

- RedisBloom: Invalid Bloom filters can cause arbitrary memory reads and writes.

- RedisBloom: Reachable assert in `TopK_Create`

- RedisBloom: Out-of-bounds access with empty Bloom chains.

- RedisBloom: Division by zero in Cuckoo filter insertion.

- (CVE-2025-46818) An authenticated user may use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user.

- (CVE-2025-46819) An authenticated user may use a specially crafted LUA script to read out-of-bound data or crash the server and lead to subsequent denial of service.

- (CVE-2025-46817) An authenticated user may use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution.

- (CVE-2025-49844) An authenticated user may use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free, and potentially lead to remote code execution.

- (CVE-2025-32023) An authenticated user can use a specially crafted string to trigger a stack/heap out-of-bounds write on HyperLogLog operations, which can lead to remote code execution.

- (CVE-2025-21605) An unauthenticated client can cause unlimited growth of output buffers until the server runs out of memory or is terminated, which can lead to denial-of-service.

- (CVE-2024-31449) An authenticated user may use a specially crafted Lua script to trigger a stack buffer overflow in the bit library, which may potentially lead to remote code execution.

- (CVE-2024-31228) An authenticated user can trigger a denial-of-service by using specially crafted, long string match patterns on supported commands such as `KEYS`, `SCAN`, `PSUBSCRIBE`, `FUNCTION LIST`, `COMMAND LIST`, and ACL definitions. Matching of extremely long patterns may result in unbounded recursion, leading to stack overflow and process crashes.

- (CVE-2023-41056) In some cases, Redis may incorrectly handle resizing of memory buffers, which can result in incorrect accounting of buffer sizes and lead to heap overflow and potential remote code execution.

- (CVE-2023-41053) Redis does not correctly identify keys accessed by `SORT_RO` and, as a result, may grant users executing this command access to keys that are not explicitly authorized by the ACL configuration. (Redis 7.2.1)

Redis 7.0.x:

- (CVE-2024-31449) An authenticated user may use a specially crafted Lua script to trigger a stack buffer overflow in the bit library, which may potentially lead to remote code execution.

- (CVE-2024-31228) An authenticated user can trigger a denial-of-service by using specially crafted, long string match patterns on supported commands such as `KEYS`, `SCAN`, `PSUBSCRIBE`, `FUNCTION LIST`, `COMMAND LIST`, and ACL definitions. Matching of extremely long patterns may result in unbounded recursion, leading to stack overflow and process crashes.

- (CVE-2023-41056) In some cases, Redis may incorrectly handle resizing of memory buffers, which can result in incorrect accounting of buffer sizes and lead to heap overflow and potential remote code execution.

- (CVE-2023-41053) Redis does not correctly identify keys accessed by `SORT_RO` and, as a result, may grant users executing this command access to keys that are not explicitly authorized by the ACL configuration. (Redis 7.0.13)

- (CVE-2023-36824) Extracting key names from a command and a list of arguments may, in some cases, trigger a heap overflow and result in reading random heap memory, heap corruption, and potentially remote code execution. Specifically: using `COMMAND GETKEYS*` and validation of key names in ACL rules. (Redis 7.0.12)

- (CVE-2023-28856) Authenticated users can use the `HINCRBYFLOAT` command to create an invalid hash field that will crash Redis on access. (Redis 7.0.11)

- (CVE-2023-28425) Specially crafted `MSETNX` commands can lead to assertion and denial-of-service. (Redis 7.0.10)

- (CVE-2023-25155) Specially crafted `SRANDMEMBER`, `ZRANDMEMBER`, and `HRANDFIELD` commands can trigger an integer overflow, resulting in a runtime assertion and termination of the Redis server process. (Redis 7.0.9)

- (CVE-2023-22458) Integer overflow in the Redis `HRANDFIELD` and `ZRANDMEMBER` commands can lead to denial-of-service. (Redis 7.0.8)

- (CVE-2022-36021) String matching commands (like `SCAN` or `KEYS`) with a specially crafted pattern to trigger a denial-of-service attack on Redis can cause it to hang and consume 100% CPU time. (Redis 7.0.9)

- (CVE-2022-35977) Integer overflow in the Redis `SETRANGE` and `SORT`/`SORT_RO` commands can drive Redis to OOM panic. (Redis 7.0.8)

- (CVE-2022-35951) Executing an `XAUTOCLAIM` command on a stream key in a specific state, with a specially crafted `COUNT` argument, may cause an integer overflow, a subsequent heap overflow, and potentially lead to remote code execution. The problem affects Redis versions 7.0.0 or newer. (Redis 7.0.5)

- (CVE-2022-31144) A specially crafted `XAUTOCLAIM` command on a stream key in a specific state may result in heap overflow and potentially remote code execution. The problem affects Redis versions 7.0.0 or newer. (Redis 7.0.4)

- (CVE-2022-24834) A specially crafted Lua script executing in Redis can trigger a heap overflow in the cjson and cmsgpack libraries, and result in heap corruption and potentially remote code execution. The problem exists in all versions of Redis with Lua scripting support, starting from 2.6, and affects only authenticated and authorized users. (Redis 7.0.12)

- (CVE-2022-24736) An attacker attempting to load a specially crafted Lua script can cause NULL pointer dereference which will result in a crash of the `redis-server` process. This issue affects all versions of Redis. (Redis 7.0.0)

- (CVE-2022-24735) By exploiting weaknesses in the Lua script execution environment, an attacker with access to Redis can inject Lua code that will execute with the (potentially higher) privileges of another Redis user. (Redis 7.0.0)

Redis 6.2.x:

- RedisBloom: Restore invalid filter.

- Integer overflow in `hllPatLen`.

- RedisBloom: Cuckoo filter counter overflow.

- RedisBloom: Invalid Bloom filters can cause arbitrary memory reads and writes.

- RedisBloom: Reachable assert in `TopK_Create`

- RedisBloom: Out-of-bounds access with empty Bloom chains.

- RedisBloom: Division by zero in Cuckoo filter insertion.

- (CVE-2025-46818) An authenticated user may use a specially crafted Lua script to manipulate different LUA objects and potentially run their own code in the context of another user.

- (CVE-2025-46819) An authenticated user may use a specially crafted LUA script to read out-of-bound data or crash the server and lead to subsequent denial of service.

- (CVE-2025-46817) An authenticated user may use a specially crafted Lua script to cause an integer overflow and potentially lead to remote code execution.

- (CVE-2025-49844) An authenticated user may use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free, and potentially lead to remote code execution.

- (CVE-2025-32023) An authenticated user can use a specially crafted string to trigger a stack/heap out-of-bounds write on HyperLogLog operations, which can lead to remote code execution.

- (CVE-2025-21605) An unauthenticated client can cause unlimited growth of output buffers until the server runs out of memory or is terminated, which can lead to denial-of-service.

- (CVE-2024-31449) An authenticated user may use a specially crafted Lua script to trigger a stack buffer overflow in the bit library, which may potentially lead to remote code execution.

- (CVE-2024-31228) An authenticated user can trigger a denial-of-service by using specially crafted, long string match patterns on supported commands such as `KEYS`, `SCAN`, `PSUBSCRIBE`, `FUNCTION LIST`, `COMMAND LIST`, and ACL definitions. Matching of extremely long patterns may result in unbounded recursion, leading to stack overflow and process crashes.

- (CVE-2023-28856) Authenticated users can use the `HINCRBYFLOAT` command to create an invalid hash field that will crash Redis on access. (Redis 6.2.12)

- (CVE-2023-25155) Specially crafted `SRANDMEMBER`, `ZRANDMEMBER`, and `HRANDFIELD` commands can trigger an integer overflow, resulting in a runtime assertion and termination of the Redis server process. (Redis 6.2.11)

- (CVE-2023-22458) Integer overflow in the Redis `HRANDFIELD` and `ZRANDMEMBER` commands can lead to denial-of-service. (Redis 6.2.9)

- (CVE-2022-36021) String matching commands (like `SCAN` or `KEYS`) with a specially crafted pattern to trigger a denial-of-service attack on Redis can cause it to hang and consume 100% CPU time. (Redis 6.2.11)

- (CVE-2022-35977) Integer overflow in the Redis `SETRANGE` and `SORT`/`SORT_RO` commands can drive Redis to OOM panic. (Redis 6.2.9)

- (CVE-2022-24834) A specially crafted Lua script executing in Redis can trigger a heap overflow in the cjson and cmsgpack libraries, and result in heap corruption and potentially remote code execution. The problem exists in all versions of Redis with Lua scripting support, starting from 2.6, and affects only authenticated and authorized users. (Redis 6.2.13)

- (CVE-2022-24736) An attacker attempting to load a specially crafted Lua script can cause NULL pointer dereference which will result in a crash of the `redis-server` process. This issue affects all versions of Redis. (Redis 6.2.7)

- (CVE-2022-24735) By exploiting weaknesses in the Lua script execution environment, an attacker with access to Redis can inject Lua code that will execute with the (potentially higher) privileges of another Redis user. (Redis 6.2.7)

- (CVE-2021-41099) Integer to heap buffer overflow handling certain string commands and network payloads, when `proto-max-bulk-len` is manually configured to a non-default, very large value. (Redis 6.2.6)

- (CVE-2021-32762) Integer to heap buffer overflow issue in `redis-cli` and `redis-sentinel` parsing large multi-bulk replies on some older and less common platforms. (Redis 6.2.6)

- (CVE-2021-32761) An integer overflow bug in Redis version 2.2 or newer can be exploited using the `BITFIELD` command to corrupt the heap and potentially result with remote code execution. (Redis 6.2.5)

- (CVE-2021-32687) Integer to heap buffer overflow with intsets, when `set-max-intset-entries` is manually configured to a non-default, very large value. (Redis 6.2.6)

- (CVE-2021-32675) Denial Of Service when processing RESP request payloads with a large number of elements on many connections. (Redis 6.2.6)

- (CVE-2021-32672) Random heap reading issue with Lua Debugger. (Redis 6.2.6)

- (CVE-2021-32628) Integer to heap buffer overflow handling ziplist-encoded data types, when configuring a large, non-default value for `hash-max-ziplist-entries`, `hash-max-ziplist-value`, `zset-max-ziplist-entries` or `zset-max-ziplist-value`. (Redis 6.2.6)

- (CVE-2021-32627) Integer to heap buffer overflow issue with streams, when configuring a non-default, large value for `proto-max-bulk-len` and `client-query-buffer-limit`. (Redis 6.2.6)

- (CVE-2021-32626) Specially crafted Lua scripts may result with Heap buffer overflow. (Redis 6.2.6)

- (CVE-2021-32625) An integer overflow bug in Redis version 6.0 or newer can be exploited using the STRALGO LCS command to corrupt the heap and potentially result with remote code execution. This is a result of an incomplete fix by CVE-2021-29477. (Redis 6.2.4)

- (CVE-2021-29478) An integer overflow bug in Redis 6.2 could be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves changing the default set-max-intset-entries configuration value, creating a large set key that consists of integer values and using the COPY command to duplicate it. The integer overflow bug exists in all versions of Redis starting with 2.6, where it could result with a corrupted RDB or DUMP payload, but not exploited through COPY (which did not exist before 6.2). (Redis 6.2.3)

- (CVE-2021-29477) An integer overflow bug in Redis version 6.0 or newer could be exploited using the STRALGO LCS command to corrupt the heap and potentially result in remote code execution. The integer overflow bug exists in all versions of Redis starting with 6.0. (Redis 6.2.3)


Archive

Summary: Describes where to view the archive of Redis Enterprise Software documentation.

Content

Previous versions of Redis Enterprise Software documentation are available on the archived web site:

- [Redis Enterprise Software v7.4 documentation archive](https://docs.redis.com/7.4/rs/)

- [Redis Enterprise Software v7.2 documentation archive](https://docs.redis.com/7.2/rs/)

- [Redis Enterprise Software v6.4 documentation archive](https://docs.redis.com/6.4/rs/)

- [Redis Enterprise Software v6.2 documentation archive](https://docs.redis.com/6.2/rs/)

- [Redis Enterprise Software v6.0 documentation archive](https://docs.redis.com/6.0/rs/)


Create roles with cluster access only

Summary: Create roles with cluster access only.

Overview

Roles with cluster access allow access to the Cluster Management UI and REST API.

Default management roles

Redis Software includes five predefined roles that determine a user's level of access to the Cluster Manager UI and [REST API]().

1. **DB Viewer** - Read database settings
1. **DB Member** - Administer databases
1. **Cluster Viewer** - Read cluster settings
1. **Cluster Member** - Administer the cluster
1. **User Manager** - Administer users
1. **Admin** - Full cluster access
1. **None** - For data access only - cannot access the Cluster Manager UI or use the REST API

For more details about the privileges granted by each of these roles, see [Cluster Manager UI permissions](#cluster-manager-ui-permissions) or [REST API permissions]().

Cluster Manager UI permissions

Here's a summary of the Cluster Manager UI actions permitted by each default management role:

| Action | DB Viewer | DB Member | Cluster Viewer | Cluster Member | Admin | User Manager |
|--------|:---------:|:---------:|:--------------:|:-----------:|:------:|:------:|
| Create, edit, delete users and LDAP mappings | ❌ No | ❌ No | ❌ No | ❌ No | ✅ Yes | ✅ Yes |
| Create support package | ❌ No | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes | ❌ No |
| Edit database configuration | ❌ No | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes | ❌ No |
| Reset slow log | ❌ No | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes | ❌ No |
| View cluster configuration | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| View cluster logs | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes
 | ✅ Yes
 |
| View cluster metrics | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| View database configuration | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| View database metrics | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| View node configuration | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| View node metrics | ❌ No | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
| View Redis database password | ❌ No | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes | ✅ Yes |
| View slow log | ❌ No | ✅ Yes | ❌ No | ✅ Yes | ✅ Yes | ❌ No |
| View and edit cluster settings | ❌ No | ❌ No | ❌ No | ❌ No | ✅ Yes | ❌ No |

Create roles for cluster access {#create-cluster-role}

You can use the [Cluster Manager UI](#create-roles-ui) or the [REST API](#define-roles-rest-api) to create a role that grants cluster access but does not grant access to any databases.

**Cluster Manager UI:**

To create a role that grants cluster access using the Cluster Manager UI:

1. From **Access Control** > **Roles**, you can:

    - Select a role from the list of existing roles to edit it.

    - Click **+ Add role** to create a new role.

1. Enter a descriptive name for the role.

1. Choose a **Management role** to determine cluster management permissions.

1. To prevent database access when using this role, do not add any ACLs.

1. Click **Save**.

**REST API:**

To [create a role]() that grants cluster access using the REST API:

[code example]

You can [assign the new role to users]() to grant cluster access.

POST /v1/roles
{
  "name": "<role-name>",
  "management": "db_viewer | db_member | cluster_viewer | cluster_member | user_manager | admin"
}


Create roles with combined access

Summary: Create roles with both cluster and database access.

Overview

To create a role that grants database access privileges and allows access to the Cluster Management UI and REST API:

1. [Define Redis ACLs](#define-redis-acls) that determine database access privileges.

1. [Create a role with ACLs](#create-role) added and choose a **Management role** other than **None**.

Define Redis ACLs

You can use the [Cluster Manager UI](#define-acls-ui) or the [REST API](#define-acls-rest-api) to define Redis ACL rules that you can assign to roles.

**Cluster Manager UI:**

To define a Redis ACL rule using the Cluster Manager UI:

1. From **Access Control > Roles > Data ACLs**, you can either:

    - Select an existing Redis ACL from the list to edit it.

    - Click **+ Add Redis ACL** to create a new Redis ACL.

1. Enter a descriptive name for the Redis ACL. This will be used to associate the ACL rule with the role.

1. Define the ACL rule. For more information about Redis ACL rules and syntax, see the [Redis ACL overview]().

1. Click **Save**.

**REST API:**

To define a Redis ACL rule using the REST API, use a [create Redis ACL]() request. For more information about Redis ACL rules and syntax, see the [Redis ACL overview]().

Example request:

[code example]

Example response body:

[code example]

To associate the Redis ACL with a role and database, use the `uid` from the response as the `redis_acl_uid` when you add `roles_permissions` to the database.

For multi-key commands on multi-slot keys, the return value is `failure`, but the command runs on the keys that are allowed.

Create roles with ACLs and cluster access {#create-role}

You can create a role that grants database access privileges and allows access to the Cluster Management UI and REST API.

**Cluster Manager UI:**

To define a role for combined access using the Cluster Manager UI:

1. From **Access Control** > **Roles**, you can:

    - Select a role from the list of existing roles to edit it.

    - Click **+ Add role** to create a new role.

1. Enter a descriptive name for the role. This will be used to reference the role when configuring users.

1. Choose a **Management role** other than **None**. For details about permissions granted by each role, see [Cluster Manager UI permissions]() and [REST API permissions]().

1. Click **+ Add ACL**.

1.  Choose a Redis ACL and databases to associate with the role.

1. Click the check mark to confirm.

1. Click **Save**.

**REST API:**

To define a role for combined access using the REST API:

1. Use a [create role]() request:

    [code example]

    Example response body:

    [code example]

    To associate the role with a Redis ACL and database, use the `uid` from the response as the `role_uid` when you add `roles_permissions` to the database.

2. [Update a database's configuration]() to add `roles_permissions` with the role and Redis ACL:

    [code example]

You can [assign the new role to users]() to grant database access and access to the Cluster Manager UI and REST API.

POST /v1/redis_acls
{
  "name": "Test_ACL_1",
  "acl": "+@read +FT.INFO +FT.SEARCH"
}

POST /v1/roles
    {
      "name": "<role-name>",
      "management": "db_viewer | db_member | cluster_viewer | cluster_member | admin"
    }

POST /v1/bdbs/<database-id>
    {
      "roles_permissions":
      [
        {
          "role_uid": <integer>,
          "redis_acl_uid": <integer>
        }
      ]
    }


Create roles with database access only

Summary: Create roles with database access only.

Overview

Roles with database access grant the ability to access and interact with a database's data. Database access privileges are determined by defining [Redis ACLs]() and adding them to roles.

To create a role that grants database access without granting access to the Redis Software Cluster Manager UI and REST API:

1. [Define Redis ACLs](#define-redis-acls) that determine database access privileges.

1. [Create a role with ACLs](#create-roles-with-acls) added and leave the **Management role** as **None**.

Define Redis ACLs

Create roles with ACLs

To create a role that grants database access to users but blocks access to the Redis Software Cluster Manager UI and REST API, set the **Management role** to **None**.

**Cluster Manager UI:**

To define a role for database access using the Cluster Manager UI:

1. From **Access Control** > **Roles**, you can:

    - Select a role from the list of existing roles to edit it.

    - Click **+ Add role** to create a new role.

1. Enter a descriptive name for the role. This will be used to reference the role when configuring users.

1. Leave **Management role** as the default **None**.

1. Click **+ Add ACL**.

1.  Choose a Redis ACL and databases to associate with the role.

1. Click the check mark to confirm.

1. Click **Save**.

**REST API:**

To define a role for database access using the REST API:

1. Use a [create role]() request:

    [code example]

    Example response body:

    [code example]

    To associate the role with a Redis ACL and database, use the `uid` from the response as the `role_uid` when you add `roles_permissions` to the database.

1. [Update a database's configuration]() to add `roles_permissions` with the role and Redis ACL:

    [code example]

You can [assign the new role to users]() to grant database access.

POST /v1/roles
    {
      "name": "<role-name>",
      "management": "none"
    }


Create users

Summary: Create users and assign access control roles.

Prerequisites

Before you create other users:

1. Review the [access control overview]() to learn how to use role-based access control (RBAC) to manage users' cluster access and database access.

1. Create roles you can assign to users. See [Create roles with cluster access only](), [Create roles with database access only](), or [Create roles with combined access]() for instructions.

Add users

To add a user to the cluster:

1. From the **Access Control > Users** tab in the Cluster Manager UI, select **+ Add user**.

    {{<image filename="images/rs/screenshots/access-control/7-22-updates/users-screen.png" alt="The list of existing users on the Access Control > Users screen.">}}

1. Enter the name, email, and password of the new user.

To use [single sign-on (SSO)](), users must have email addresses.

1. Select the **Alerts** the user should receive by email:

    - **Receive alerts for databases** - The alerts that are enabled for the selected databases will be sent to the user. Choose **All databases** or **Customize** to select the individual databases to send alerts for.

    - **Receive cluster alerts** - The alerts that are enabled for the cluster in **Cluster > Alerts Settings** are sent to the user.

1. Click **Add permissions**.

1. Assign a **Role** to the user to grant permissions for cluster management and data access.

1. Click **Save user**.

Assign roles to users

Assign a role, associated with specific databases and access control lists (ACLs), to a user to grant database access:

1. From the **Access Control > Users** tab in the Cluster Manager UI, select an existing user from the list of users.

1. Click the **Edit** button.

1. In the **User roles** section, click **Edit**.

1. Select a role to assign to the user.

1. Click **Done** to close the **Roles** dialog.

1. Click **Save**.

Next steps

Depending on the type of the user's assigned role (cluster management role or data access role), the user can now:

- [Connect to a database]() associated with the role and run limited Redis commands, depending on the role's Redis ACLs.

- Sign in to the Redis Software Cluster Manager UI.

- Make a [REST API]() request.


Access control

Summary: An overview of access control in Redis Software.

Create users

Summary: Create roles with cluster access only.

Create roles with cluster access only

Summary: Create roles with database access only.

Create roles with database access only

Create roles with combined access

Summary: An overview of Redis ACLs, syntax, and ACL command support in Redis Software.

Overview of Redis ACLs in Redis Software

Summary: Manage user account security settings.

Manage user security

Summary: Set password policies.

Set password policies

Summary: Describes how Redis Software integrates LDAP authentication and authorization. Also describes how to enable LDAP for your deployment of Redis Enterprise Software.

LDAP authentication

Summary: Set up single sign-on with SAML for the Redis Software Cluster Manager UI.

SAML single sign-on

Overview

Redis Software lets you use role-based access control (RBAC) to manage users' access privileges. RBAC requires you to do the following:

1. Create roles and define each role's access privileges.

1. Create users and assign roles to them. The assigned role determines the user's access privileges.

Cluster access versus database access

Redis Software allows two separate paths of access:

- **Cluster access** allows performing management-related actions, such as creating databases and viewing statistics.

- **Database access** allows performing data-related actions, like reading and writing data in a database.

You can grant cluster access, database access, or both to each role. These roles let you differentiate between users who can access databases and users who can access cluster management, according to your organization's security needs.

The following diagram shows three different options for roles and users:

- Role A was created with permission to access the cluster and perform management-related actions. Because user A was assigned role A, they can access the cluster but cannot access databases.

- Role B was created with permission to access one or more databases and perform data-related actions. Because user B was assigned role B, they cannot access the cluster but can access databases.

- Role C was created with cluster access and database access permissions. Because user C was assigned role C, they can access the cluster and databases.

Default database access

When you create a database, [default user access]() is enabled automatically.

If you set up role-based access controls for your database and don't require compatibility with versions earlier than Redis 6, you can [deactivate the default user]().

Before you [deactivate default user access](), make sure the role associated with the database is [assigned to a user](). Otherwise, the database will be inaccessible.

More info


Enable role-based LDAP

Summary: Describes how to enable role-based LDAP authentication and authorization using the Cluster Manager UI.

Overview

Redis Software uses a role-based mechanism to enable LDAP authentication and authorization.

When a user attempts to access Redis Software resources using LDAP credentials, the credentials are passed to the LDAP server in a bind request. If the request succeeds, the user’s groups are searched for a group that authorizes access to the original resource.

Role-based LDAP lets you authorize cluster management users (previously known as _external users_) and database users. As with any access control role, you can define the level of access authorized by the role.

Set up LDAP connection

To configure and enable LDAP from the Cluster Manager UI:

1. Go to **Access Control > LDAP > Configuration**.

1. Select **+ Create**.

1. In **Set LDAP**, configure [LDAP server settings](#ldap-server-settings), [bind credentials](#bind-credentials), [authentication query](#authentication-query), and [authorization query](#authorization-query).

1. Select **Save & Enable**.

LDAP server settings

The **LDAP server** settings define the communication settings used for LDAP authentication and authorization. These include:

| _Setting_ | _Description_ |
|:----------|:--------------|
| **Protocol type** | Underlying communication protocol; must be _LDAP_, _LDAPS_, or _STARTTLS_ |
| **Host** | URL of the LDAP server |
| **Port** | LDAP server port number |
| **Trusted CA certificate** |  _(LDAPS or STARTTLS protocols only)_ Certificate for the trusted certificate authority (CA) |

When defining multiple LDAP hosts, the organization tree structure must be identical for all hosts.

Bind credentials

These settings define the credentials for the bind query:

| _Setting_ | _Description_ |
|:----------|:--------------|
| **Distinguished Name** | Example: `cd=admin,dc=example,dc=org` |
| **Password** | Example: `admin1` |
| **Client certificate authentication** |_(LDAPS or STARTTLS protocols only)_ Place checkmark to enable |
| **Client public key** | _(LDAPS or STARTTLS protocols only)_ The client public key for authentication |
| **Client private key** | _(LDAPS or STARTTLS protocols only)_ The client private key for authentication |

Authentication query

These settings define the authentication query:

| _Setting_ | _Description_ |
|:----------|:--------------|
| **Search user by** | Either _Template_ or _Query_ |
| **Template** | _(template search)_ Example: `cn=%u,ou=dev,dc=example,dc=com` |
| **Base** | _(query search)_ Example: `ou=dev,dc=example,dc=com` |
| **Filter** | _(query search)_ Must be enclosed in parentheses. Example: `(cn=%u)` |
| **Scope**  | _(query search)_ Must be _baseObject_, _singleLevel_, or _wholeSubtree_ |

In this example, `%u` is replaced by the username attempting to access the Redis Software resource.

Authorization query

These settings define the group authorization query:

| _Setting_ | _Description_ |
|:----------|:--------------|
| **Search groups by** | Either _Attribute_ or _Query_ |
| **Attribute** | _(attribute search)_ Example: `memberOf` (case-sensitive) |
| **Base** | _(query search)_ Example: `ou=groups,dc=example,dc=com` |
| **Filter** | _(query search)_ Must be enclosed in parentheses. Example: `(members=%D)` |
| **Scope**  | _(query search)_ Must be _baseObject_, _singleLevel_, or _wholeSubtree_ |

In this example, `%D` is replaced by the Distinguished Name of the user attempting to access the Redis Software resource.

Authentication timeout

The **Authentication timeout** setting determines the connection timeout to the LDAP server during user authentication.

By default, the timeout is 5 seconds, which is recommended for most cases.

However, if you enable multi-factor authentication (MFA) for your LDAP server, you might need to increase the timeout to provide enough time for MFA verification. You can set it to any integer in the range of 5-60 seconds.

More info

- Map LDAP groups to [access control roles]()
- Update database ACLs to [authorize LDAP access]()
- Learn more about Redis Software [security and practices]()


LDAP authentication

Enable role-based LDAP

Summary: Describes how to map LDAP authorization groups to Redis Software roles using the Cluster Manager UI.

Map LDAP groups to roles

Summary: Describes how to use the Cluster Manager UI to update database access control lists (ACLs) to authorize access to roles authorizing LDAP user access.

Update database ACLs

Summary: Describes how to migrate existing cluster-based LDAP deployments to role-based LDAP.

Migrate to role-based LDAP

Overview

Redis Software supports [Lightweight Directory Access Protocol](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) (LDAP) authentication and authorization through its [role-based access controls]() (RBAC).  You can use LDAP to authorize access to the Cluster Manager UI and to control database access.

You can configure LDAP roles using the Redis Software Cluster Manager UI or [REST API]().

How it works

Here's how role-based LDAP integration works:

1.  A user signs in with their LDAP credentials.

    Based on the LDAP configuration details, the username is mapped to an LDAP Distinguished Name.

1.  A simple [LDAP bind request](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Bind_(authenticate)) is attempted using the Distinguished Name and the password.  The sign-in fails if the bind fails.

1.  Obtain the user’s LDAP group memberships.

    Using configured LDAP details, obtain a list of the user’s group memberships.

1.  Compare the user’s LDAP group memberships to those mapped to local roles.

1.  Determine if one of the user's groups is authorized to access the target resource.  If so, the user is granted the level of access authorized to the role.

To access the Cluster Manager UI, the user needs to belong to an LDAP group mapped to an administrative role.

For database access, the user needs to belong to an LDAP group mapped to a role listed in the database’s access control list (ACL).  The rights granted to the group determine the user's level of access.

Prerequisites

Before you enable LDAP in Redis Software, you need:

1. The following LDAP details:

    - Server URI, including host, port, and protocol details.
    - Certificate details for secure protocols.
    - Bind credentials, including Distinguished Name, password, and (optionally) client public and private keys for certificate authentication.
    - Authentication query details, whether template or query.
    - Authorization query details, whether attribute or query.
    - The Distinguished Names of LDAP groups you’ll use to authorize access to Redis Software resources.

1. The LDAP groups that correspond to the levels of access you wish to authorize.  Each LDAP group will be mapped to a Redis Software access control role.

1. A Redis Software access control role for each LDAP group. Before you enable LDAP, you need to set up [role-based access controls]() (RBAC).

Enable LDAP

To enable LDAP:

1.  From **Access Control > LDAP** in the Cluster Manager UI, select the **Configuration** tab and [enable LDAP access]().

2.  Map LDAP groups to [access control roles]().

3.  Update database access control lists (ACLs) to [authorize role access]().

If you already have appropriate roles, you can update them to include LDAP groups.

More info

- Enable and configure [role-based LDAP]()
- Map LDAP groups to [access control roles]()
- Update database ACLs to [authorize LDAP access]()
- Learn more about Redis Software [security and practices]()


Map LDAP groups to roles

Overview

Redis Software uses a role-based mechanism to enable LDAP authentication and authorization.

Once LDAP is enabled, you need to map LDAP groups to Redis Software access control roles.

Map LDAP groups to roles

To map LDAP groups to access control roles in the Cluster Manager UI:

1. Select **Access Control > LDAP > Mapping**.

You can map LDAP roles when LDAP configuration is not enabled, but they won't have any effect until you [configure and enable LDAP]().

1.  Select the **+ Add LDAP Mapping** button to create a new mapping and then enter the following details:

    | _Setting_ | _Description_ |
|:----------|:--------------|
| **Name** | A descriptive, unique name for the mapping |
| **Distinguished Name** | The distinguished name of the LDAP group to be mapped.  <br/>Example: `cn=admins,ou=groups,dc=example,dc=com` |
| **Role** | The Redis Software access control role defined for this group |
| **Email** | _(Optional)_ An address to receive alerts|
| **Alerts**  | Selections identifying the desired alerts. |

1.  When finished, select the **Save** button.

Create a mapping for each LDAP group used to authenticate and/or authorize access to Redis Software resources.

The scope of the authorization depends on the access control role:

- If the role authorizes admin management, LDAP users are authorized as cluster management administrators.

- If the role authorizes database access, LDAP users are authorized to use the database to the limits specified in the role.

- To authorize LDAP users to specific databases, update the database access control lists (ACLs) to include the mapped LDAP role.

More info

- Enable and configure [role-based LDAP]()
- Update database ACLs to [authorize LDAP access]()
- Learn more about Redis Software [security and practices]()


Migrate to role-based LDAP

Overview

Redis Software supports LDAP through a [role-based mechanism](), first introduced [in v6.0.20]().

Earlier versions of Redis Software supported a cluster-based mechanism; however, that mechanism was removed in v6.2.12.

If you're using the cluster-based mechanism to enable LDAP authentication, you need to migrate to the role-based mechanism before upgrading to Redis Software v6.2.12 or later.

Migration checklist

This checklist covers the basic process:

1.  Identify accounts per app on the customer end.

1.  Create or identify an LDAP user account on the server that is responsible for LDAP authentication and authorization.

1.  Create or identify an LDAP group that contains the app team members.

1.  Verify or configure the Redis Software ACLs.

1.  Configure each database ACL.

1.  Remove the earlier "external" (LDAP) users from Redis Software.

1.  _(Recommended)_ Update cluster configuration to replace the cluster-based configuration file.

    You can use `rladmin` to update the cluster configuration:

    [code example]

    Here, a blank file replaces the earlier configuration.

1.  Use **Access Control > LDAP > Configuration** to enable role-based LDAP.

1.  Map your LDAP groups to access control roles.

1.  Test application connectivity using the LDAP credentials of an app team member.

1.  _(Recommended)_ Turn off default access for the database to avoid anonymous client connections.

 Because deployments and requirements vary, you’ll likely need to adjust these guidelines.

Test LDAP access

To test your LDAP integration, you can:

- Connect with `redis-cli` and use the [`AUTH` command]() to test LDAP username/password credentials.

- Sign in to the Cluster Manager UI using LDAP credentials authorized for admin access.

- Use [Redis Insight]() to access a database using authorized LDAP credentials.

- Use the [REST API]() to connect using authorized LDAP credentials.

More info

$ touch /tmp/saslauthd_empty.conf
    $ rladmin cluster config saslauthd_ldap_conf \
         /tmp/saslauthd_empty.conf


Update database ACLs

Overview

To grant LDAP users access to a database, assign the mapped access role to the access control list (ACL) for the database.

1.  In the Cluster Manager UI, go to **Databases**, then select the database from the list.

1.  From the **Security** tab, select the **Edit** button.

1.  In the **Access Control List** section, select **+ Add ACL**.

1.  Select the appropriate roles and then save your changes.

If you assign multiple roles to an ACL and a user is authorized by more than one of these roles, their access is determined by the first "matching" rule in the list.

If the first rule gives them read access and the third rule authorizes write access, the user will only be able to read data.

As a result, we recommend ordering roles so that higher access roles appear before roles with more limited access.

More info

- Enable and configure [role-based LDAP]()
- Map LDAP groups to [access control roles]()
- Learn more about Redis Software [security and practices]()


Summary: Update admin credentials for Active-Active databases.

Content

Active-Active databases use administrator credentials to manage operations. When you change the administrator password on clusters with Active-Active databases, you must update the Active-Active database configuration to prevent authentication failures during Active-Active management operations.

Do not perform any management operations on the databases until these steps are complete.

To update the administrator password on a cluster with Active-Active databases:

1. From the user management page, update the administrator user password on the clusters you want to update.

1. Run [`crdb-cli crdb list`]() to find the `CRDB-GUID` that uniquely identifies each Active-Active database and the fully qualified domain names (`FQDN`) of each participating cluster:

    [code example]

    Example output:

    [code example]

1. Update the Active-Active database credentials using the [`crdb-cli crdb update`]() command:

    [code example]

    Replace the following values:

    - `<CRDB-GUID>`: The `CRDB-GUID` from the `crdb-cli crdb list` output

    - `<admin-username>`: The administrator username for the clusters

    - `<REPL-ID-1>` and `<REPL-ID-2>`: The `REPL-ID` for the corresponding FQDNs

    - `<FQDN-1-password>` and `<FQDN-2-password>`: The current administrator passwords for each cluster

CRDB-GUID                             NAME        REPL-ID  FQDN
    4053a0dd-a4a5-4f38-b135-75b7a2dc7331  my-aa-db    1        fqdn1.example.com
    4053a0dd-a4a5-4f38-b135-75b7a2dc7331  my-aa-db    2        fqdn2.example.com

crdb-cli crdb update \
      --crdb-guid <CRDB-GUID> \
      --credentials id=<REPL-ID-1>,username=<admin-username>,password=<FQDN-1-password> \
      --credentials id=<REPL-ID-2>,username=<admin-username>,password=<FQDN-2-password> \
      --force


Set password policies

Summary: Set password policies.

Summary: Enable password complexity rules and configure minimum password length.

Configure password complexity rules

Summary: Configure password expiration to enforce expiration of a user's password after a specified number of days.

Configure password expiration

Summary: Rotate user passwords.

Rotate passwords

Summary: Change the password hashing algorithm for user passwords in a Redis Software cluster.

Change the password hashing algorithm

Content

Redis Software provides several ways to manage the passwords of local accounts, including:

- [Password complexity rules]()

- [Password expiration]()

- [Password rotation]()

You can also manage a user's ability to [sign in]() and control [session timeout]().

To enforce more advanced password policies, we recommend using [LDAP integration]() with an external identity provider, such as Active Directory.

Redis Software securely stores all user passwords using a cryptographic hash function. The default password hashing algorithm is `SHA-256`, but you can [change the password hashing algorithm]() to `PBKDF2` as of Redis Software version 7.8.6-13.


Configure password complexity rules

Overview

Redis Software provides optional password complexity rules that meet common requirements.  When enabled, these rules require the password to have:

- At least 8 characters
- At least one uppercase character
- At least one lowercase character
- At least one number
- At least one special character

These requirements reflect v6.2.12 and later. Earlier versions did not support numbers or special characters as the first or the last character of a password. This restriction was removed in v6.2.12.

In addition, the password:

- Cannot contain the user's email address or the reverse of the email address.
- Cannot have more than three repeating characters.

Password complexity rules apply when a new user account is created and when the password is changed.  Password complexity rules are not applied to accounts authenticated by an external identity provider.

Enable password complexity rules

To enable password complexity rules, use one of the following methods:

- Cluster Manager UI:

    1. Go to **Cluster > Security > Preferences**, then select **Edit**.

    1. In the **Password** section, enable **Complexity rules**.

    1. Select **Save**.

- [Update cluster]() REST API request:

    [code example]

Change minimum password length

When password complexity rules are enabled, passwords must have at least 8 characters by default.

If you change the minimum password length, the new minimum is enforced for new users and when existing users change their passwords.

To change the minimum password length, use one of the following methods:

- Cluster Manager UI:

    1. Go to **Cluster > Security > Preferences**.

    1. Click **Edit**.

    1. In the **Password** section, enable **Complexity rules**.

    1. Set the number of characters for **Minimum password length**.

    1. Click **Save**.

- [Update cluster]() REST API request:

    [code example]

Deactivate password complexity rules

To deactivate password complexity rules, use one of the following methods:

- Cluster Manager UI:

    1. Go to **Cluster > Security > Preferences**, then select **Edit**.

    1. In the **Password** section, turn off **Complexity rules**.

    1. Select **Save**.

- [Update cluster]() REST API request:

    [code example]

PUT https://[host][:port]/v1/cluster
    { "password_complexity": true }

PUT https://[host][:port]/v1/cluster
    { "password_min_length": <integer between 8-256> }

PUT https://[host][:port]/v1/cluster
    { "password_complexity": false }


Configure password expiration

Enable password expiration

Password expiration is calculated from the time the password was last updated, not from when the policy is enabled. Passwords that were set long enough ago to already be expired will immediately be locked out when you enable this policy. Before enabling password expiration, verify all user passwords have been updated recently enough to avoid immediate lockouts.

To enforce an expiration of a user's password after a specified number of days:

- Use the Cluster Manager UI:

    1. Go to **Cluster > Security > Preferences**, then select **Edit**.

    1. In the **Password** section, turn on **Expiration**.

    1. Enter the number of days before passwords expire.

    1. Select **Save**.

- Use the `cluster` endpoint of the REST API

    [code example]

Deactivate password expiration

To deactivate password expiration:

- Use the Cluster Manager UI:

    1. Go to **Cluster > Security > Preferences**, then select **Edit**.

    1. In the **Password** section, turn off **Expiration**.

    1. Select **Save**.

- Use the `cluster` REST API endpoint to set `password_expiration_duration` to `0` (zero).

PUT https://[host][:port]/v1/cluster
    {"password_expiration_duration":<number_of_days>}


Change the password hashing algorithm

Overview

Redis Software securely stores all user passwords using a cryptographic hash function. The default password hashing algorithm is `SHA-256`, but `PBKDF2` is also supported as of Redis Software version 7.8.6-13.

You can change the password hashing algorithm using [`rladmin`]() or the [REST API](). When you change the password hashing algorithm, the cluster rehashes the administrator password and passwords for all users, including default users.

Command-line method

To change the password hashing algorithm from the command line, run [`rladmin cluster change_password_hashing_algorithm`]():

[code example]

REST API method

You can [change the password hashing algorithm]() using a REST API request:

[code example]

rladmin cluster change_password_hashing_algorithm PBKDF2

PATCH /v1/cluster/change_password_hashing_algorithm
{ "algorithm": "PBKDF2" }


Rotate passwords

Summary: Rotate user passwords.

Overview

Redis Software lets you implement password rotation policies using the [REST API]().

You can add a new password for a database user without immediately invalidating the old one to prevent possible authentication errors in production.

Password rotation does not work for the default user. [Add additional users]() to enable password rotation.

Password rotation policies

For user access to the Redis Software Cluster Manager UI,
you can set a [password expiration policy]() to prompt the user to change their password.

However, for database connections that rely on password authentication,
you need to allow for authentication with the existing password while you roll out the new password to your systems.

With the Redis Software REST API, you can add additional passwords to your user account for authentication to the database or the Cluster Manager UI and API.

After the old password is replaced in the database connections, you can delete the old password to finish the password rotation process.

Multiple passwords are only supported using the REST API.
If you reset the password for a user in the Cluster Manager UI,
the new password replaces all other passwords for that user.

The new password cannot already exist as a password for the user and must meet the [password complexity]() requirements, if enabled.

Rotate password

Admins can rotate passwords for any user. If you are not an admin, you can only rotate passwords for your account.

To rotate passwords:

1. Add an additional password to a user's password list with [`POST /v1/users/password`]().

    [code example]

    After you send this request, the user can authenticate with both the old and the new password.

1. Update the password in all database connections that connect with the user account.
1. Delete the original password with [`DELETE /v1/users/password`]():

    [code example]

    If there is only one valid password for a user account, you cannot delete that password.

Replace all passwords

You can replace all existing passwords for your account with a single password that does not match any existing passwords. Admins can reset passwords for any user.
This can be helpful if you suspect that your passwords are compromised and you want to quickly resecure the account.

To replace a user's passwords, use [`PUT /v1/users/password`]().

[code example]

After this request, all of the user's existing passwords are deleted and only the new password is valid.

POST https://<host>:<port>/v1/users/password
    {
      "username": "<target_username>",
      "new_password": "<a_new_password>"
    }

DELETE https://<host>:<port>/v1/users/password
    {
      "username": "<target_username>",
      "old_password": "<existing_password_to_delete>"
    }

PUT https://<host>:<port>/v1/users/password
{
  "username": "<target_username>",
  "new_password": "<a_new_password>"
}


Manage default user

Summary: Manage a database's default user.

Overview

When you [create a database](), default user database access is enabled by default (**Unauthenticated access** is selected). This gives the default user full access to the database and enables compatibility with versions of Redis before Redis 6.

Select **Password-only authentication**, then enter and confirm a default database password to require authentication for connections to the database.

Authenticate as default user

When you configure a password for your database, all connections to the database must authenticate using the [AUTH]() command. See Redis security's [authentication]() section for more information.

[code example]

Change default database password

To change the default user's password:

1. From the database's **Security** tab, select **Edit**.

1. In the **Access Control** section, select **Password-only authentication** as the **Access method**.

1. Enter and re-enter the new password.

1. Select **Save**.

Deactivate default user

If you set up [role-based access control]() with [access control lists]() (ACLs) for your database and don't require backwards compatibility with versions earlier than Redis 6, you can [deactivate the default user]().

- Before you deactivate default user access, make sure the role associated with the database is [assigned to a user](). Otherwise, the database will be inaccessible.

- If you enabled the default database password during the creation of an [Active-Active database](), you should not turn off the default database password because it could prevent the removal of participating database instances.

To deactivate the default user:

1. From the database's **Security** tab, select **Edit**.

1. In the **Access Control** section, select **Using ACL only** as the **Access method**.

1. Choose at least one role and Redis ACL to access the database.

1. Select **Save**.


Manage user security

Summary: Manage user account security settings.

Summary: Manage user login lockout and session timeout.

Manage user login

Summary: Manage a database's default user.

Manage default user

Overview

Redis Software supports the following user account security settings:

- Password complexity
- Password expiration
- User lockouts
- Account inactivity timeout

Manage users and user security


Manage user login

Overview

Redis Software secures user access in a few different ways, including automatically:

- Locking user accounts after a series of authentication failures (invalid passwords)

- Signing sessions out after a period of inactivity

Here, you learn how to configure the relevant settings.

User login lockout

By default, after 5 failed login attempts within 15 minutes, the user account is locked for 30 minutes. You can change the user login lockout settings in the Cluster Manager UI or with [`rladmin`]().

View login lockout settings

You can view the cluster's user login lockout settings from **Cluster > Security > Preferences > Lockout threshold** in the Cluster Manager UI or with [`rladmin info cluster`]():

[code example]

Configure user login lockout

To change the user login lockout settings using the Cluster Manager UI:

1. Go to **Cluster > Security > Preferences**, then select **Edit**.

1. In the **Lockout threshold** section, make sure the checkbox is selected.

1. Configure the following **Lockout threshold** settings:

    1. **Log-in attempts until user is revoked** - The number of failed login attempts allowed before the user account is locked.

    1. **Time between failed login attempts** in seconds, minutes, or hours - The amount of time during which failed login attempts are counted.

    1. For **Unlock method**, select one of the following:

        - **Locked duration** to set how long the user account is locked after excessive failed login attempts.

        - **Only Admin can unlock the user by resetting the password**.

1. Select **Save**.

Change allowed login attempts

To change the number of failed login attempts allowed before the user account is locked, use one of the following methods:

- [Cluster Manager UI](#configure-user-login-lockout)

- [`rladmin tune cluster`]():

    [code example]

    For example, to set the lockout threshold to 10 failed login attempts, run:

    [code example]

    If you set the lockout threshold to 0, it turns off account lockout, and the cluster settings show `login_lockout_threshold: disabled`.

    [code example]

Change time before login attempts reset

To change the amount of time during which failed login attempts are counted, use one of the following methods:

- [Cluster Manager UI](#configure-user-login-lockout)

- [`rladmin tune cluster`]():

    [code example]

    For example, to set the lockout reset to 1 hour, run:

    [code example]

Change login lockout duration

To change the amount of time that the user account is locked after excessive failed login attempts, use one of the following methods:

- [Cluster Manager UI](#configure-user-login-lockout)

- [`rladmin tune cluster`]():

    [code example]

    For example, to set the lockout duration to 1 hour, run:

    [code example]

    If you set the lockout duration to 0, then the account can be unlocked only when an administrator changes the account's password.

    [code example]

    The cluster settings now show `login_lockout_duration: admin-release`.

Unlock locked user accounts

To unlock a locked user account as an admin, use one of the following methods:

**Cluster Manager UI:**

To unlock a user account in the Cluster Manager UI:

1. Go to **Access Control > Users**. Locked users have a "User is locked out" label:

    Users configuration screen in the Cluster Manager UI">

1. Point to the "User is locked out" label, then click **Reset to unlock** when it appears:

1. In the **Reset user password** dialog, enter a new password for the user:

1. Select **Save** to reset the user's password and unlock their account.

**rladmin:**

To unlock a user account or reset a user password with `rladmin`, run the [`rladmin cluster reset_password`]() command:

[code example]

**REST API:**

To unlock a user account or reset a user password with the REST API, use [`PUT /v1/users`]():

[code example]

Turn off login lockout

To turn off user login lockout and allow unlimited login attempts, use one of the following methods:

**Cluster Manager UI:**

To turn off user login lockout using the Cluster Manager UI:

1. Go to **Cluster > Security > Preferences**, then select **Edit**.

1. Clear the **Lockout threshold** checkbox.

1. Select **Save**.

**rladmin:**

To turn off user login lockout using `rladmin`, run the [`rladmin tune cluster`]() command:

[code example]

The cluster settings show `login_lockout_threshold: disabled`.

Configure session timeout

The Redis Software Cluster Manager UI supports session timeouts. By default, users are automatically logged out after 15 minutes of inactivity.

To customize the session timeout, use one of the following methods:

**Cluster Manager UI:**

To configure the session timeout using the Cluster Manager UI:

1. Go to **Cluster > Security > Preferences**, then select **Edit**.

1. For **Session timeout**, select minutes or hours from the list and enter the timeout value.

1. Select **Save**.

**rladmin:**

To configure the session timeout using `rladmin`, run the [`rladmin cluster config`]() command:

[code example]

The `<number_of_min>` is the number of minutes after which sessions will time out.

$ rladmin info cluster | grep login_lockout
    login_lockout_counter_reset_after: 900
    login_lockout_duration: 1800
    login_lockout_threshold: 5

rladmin tune cluster login_lockout_threshold <integer>

rladmin tune cluster login_lockout_threshold 10

rladmin tune cluster login_lockout_threshold 0

rladmin tune cluster login_lockout_counter_reset_after <seconds>

rladmin tune cluster login_lockout_counter_reset_after 3600

rladmin tune cluster login_lockout_duration <login_lockout_duration>

rladmin tune cluster login_lockout_duration 3600

rladmin tune cluster login_lockout_duration 0

rladmin cluster reset_password <user_email>

PUT /v1/users
{"password": "<new_password>"}

rladmin cluster config cm_session_timeout_minutes <number_of_min>


Overview

Redis access control lists (Redis ACLs) allow you to define named permissions for specific Redis commands, keys, and pub/sub channels. You can use defined Redis ACLs for multiple databases and roles.

Predefined Redis ACLs

Redis Software provides one predefined Redis ACL named **Full Access**. This ACL allows all commands on all keys and cannot be edited.

Redis ACL syntax

Redis ACLs are defined by a set of rules where you specify the commands or command categories that are allowed for specific keys.

Commands and categories

Redis ACL rules can allow or block specific [Redis commands]() or [command categories](#command-categories).

- `+` includes commands

- `-` excludes commands

- `+@` includes command categories

- `-@` excludes command categories

The following example allows all `read` commands and the `SET` command:

[code example]

For database versions earlier than Redis 8.2, module commands have several ACL limitations:

- [Redis modules]() do not have command categories.

- Other [command category](#command-categories) ACLs, such as `+@read` and `+@write`, do not include Redis module commands. `+@all` is the only exception because it allows all Redis commands.

- You have to include individual module commands in a Redis ACL rule to allow them.

    For example, the following Redis ACL rule allows read-only commands and the RediSearch commands `FT.INFO` and `FT.SEARCH`:

    [code example]

Key patterns

To define access to specific keys or key patterns, use the following prefixes:

- `~` or `%RW~` allows read and write access to keys.

- `%R~` allows read access to keys.

- `%W~` allows write access to keys.

`%RW~`, `%R~`, and `%W~` are only supported for databases with Redis version 7.2 or later.

The following example allows read and write access to all keys that start with "app1" and read-only access to all keys that start with "app2":

[code example]

Pub/sub channels

The `&` prefix allows access to [pub/sub channels]() (only supported for databases with Redis version 6.2 or later).

To limit access to specific channels, include `resetchannels` before the allowed channels:

[code example]

Selectors

[Selectors](#selectors) let you define multiple sets of rules in a single Redis ACL (only supported for databases with Redis version 7.2 or later). A command is allowed if it matches the base rule or any selector in the Redis ACL.

- `(<rule set>)` creates a new selector.

- `clearselectors` deletes all existing selectors for a user. This action does not delete the base ACL rule.

In the following example, the base rule allows `GET key1` and the selector allows `SET key2`:

[code example]

Default pub/sub permissions

Redis database version 6.2 introduced pub/sub ACL rules that determine which [pub/sub channels]() a user can access.

The configuration option `acl-pubsub-default`, added in Redis Software version 6.4.2, determines the cluster-wide default level of access for all pub/sub channels. Redis Software uses the following pub/sub permissions by default:

- For versions 6.4.2 and 7.2, `acl-pubsub-default` is permissive (`allchannels` or `&*`) by default to accommodate earlier Redis versions.

- In future versions, `acl-pubsub-default` will change to restrictive (`resetchannels`). Restrictive permissions block all pub/sub channels by default, unless explicitly permitted by an ACL rule.

If you use ACLs and pub/sub channels, you should review your databases and ACL settings and plan to transition your cluster to restrictive pub/sub permissions in preparation for future Redis Software releases.

Prepare for restrictive pub/sub permissions

To secure pub/sub channels and prepare your cluster for future Redis Software releases that default to restrictive pub/sub permissions:

1. Upgrade Redis databases:

    - For Redis Software version 6.4.2, upgrade all databases in the cluster to Redis DB version 6.2.

    - For Redis Software version 7.2, upgrade all databases in the cluster to Redis DB version 7.2 or 6.2.

1. Create or update ACLs with permissions for specific channels using the `resetchannels &channel` format.

1. Associate the ACLs with relevant databases.

1. Set default pub/sub permissions (`acl-pubsub-default`) to restrictive. See [Change default pub/sub permissions](#change-default-pubsub-permissions) for details.

1. If any issues occur, you can temporarily change the default pub/sub setting back to permissive. Resolve any problematic ACLs before making pub/sub permissions restrictive again.

When you change the cluster's default pub/sub permissions to restrictive, `&*` is added to the **Full Access** ACL. Before you make this change, consider the following:

- Because pub/sub ACL syntax was added in Redis 6.2, you can't associate the **Full Access** ACL with database versions 6.0 or lower after this change.

- The **Full Access** ACL is not reverted if you change `acl-pubsub-default` to permissive again.

- Every database with the default user enabled uses the **Full Access** ACL.

Change default pub/sub permissions

As of Redis Software version 6.4.2, you can configure `acl_pubsub_default`, which determines the default pub/sub permissions for all databases in the cluster. You can set `acl_pubsub_default` to the following values:

- `resetchannels` is restrictive and blocks access to all channels by default.

- `allchannels` is permissive and allows access to all channels by default.

To make default pub/sub permissions restrictive:

1. [Upgrade all databases]() in the cluster to Redis version 6.2 or later.

1. Set the default to restrictive (`resetchannels`) using one of the following methods:

    **Cluster Manager UI:**

To set the default pub/sub permissions using the Cluster Manager UI:

1. Navigate to **Access Control > Roles > Pub/Sub ACLs** and click **Edit**.

1. Read the warning, then click **Continue**.

1. For **Default permissions for Pub/Sub ACLs**, select **Restrictive**, then **Save**.

**rladmin:**

To set the default pub/sub permissions using `rladmin`, run the [`rladmin tune cluster`]() command:

[code example]

**REST API:**

To set the default pub/sub permissions using the REST API, use an [update cluster policy]() request:

[code example]

ACL command support

Redis Software does not support certain Redis ACL commands. Instead, you can manage access controls from the Cluster Manager UI.

Redis ACLs also have the following differences in Redis Software:

- The `MULTI`, `EXEC`, `DISCARD` commands are always allowed, but ACLs are enforced on `MULTI` subcommands.

- Nested selectors are not supported.

    For example, the following selectors are not valid in Redis Software: <nobr>`+GET ~key1 (+SET (+SET ~key2) ~key3)`</nobr>

- Key and pub/sub patterns do not allow the following characters: `'(', ')'`

- The following password configuration syntax is not supported: `'>', '<', '#!', 'resetpass'`

    To configure passwords in Redis Software, use one of the following methods:

    - [`rladmin cluster reset_password`]():

        [code example]

    - REST API [`PUT /v1/users`]() request and provide `password`

See also

[Redis ACL rules]()

rladmin tune cluster acl_pubsub_default resetchannels

PUT /v1/cluster/policy
{ "acl_pubsub_default": "resetchannels" }

rladmin cluster reset_password <user email>


SAML single sign-on

Overview

Redis Software supports both [IdP-initiated](#idp-initiated-sso) and [SP-initiated](#sp-initiated-sso) [single sign-on (SSO)](https://en.wikipedia.org/wiki/Single_sign-on) with [SAML (Security Assertion Markup Language)](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) for the Cluster Manager UI. Redis Software uses SAML 2.0, which is the latest SAML version and an industry standard.

You cannot use [SCIM (System for Cross-domain Identity Management)](https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management) to provision Redis Software users. However, Redis Software supports just-in-time (JIT) user provisioning, which means Redis Software automatically creates a user account the first time a new user signs in with SSO.

SSO overview

When single sign-on is activated, users can sign in to the Redis Software Cluster Manager UI using their [identity provider (IdP)](https://en.wikipedia.org/wiki/Identity_provider) instead of usernames and passwords. If [SSO is enforced](#enforce-sso), non-admin users can no longer sign in with their previous usernames and passwords and must use SSO instead.

Before users can sign in to the Cluster Manager UI with SSO, the identity provider admin needs to set up these users on the IdP side with matching email addresses.

With just-in-time (JIT) user provisioning, Redis Software automatically creates user accounts for new users assigned to the SAML application in your identity provider when they sign in to the Cluster Manager UI for the first time. For these users, you must configure the `redisRoleMapping` attribute in your identity provider to assign appropriate roles for [role-based access control]() during account creation.

IdP-initiated SSO

With IdP-initiated single sign-on, you can select the Redis Software application after you sign in to your [identity provider (IdP)](https://en.wikipedia.org/wiki/Identity_provider). This redirects you to the Redis Software Cluster Manager UI and signs you in.

SP-initiated SSO

You can also initiate single sign-on from the Redis Software Cluster Manager UI. This process is known as [service provider (SP)](https://en.wikipedia.org/wiki/Service_provider)-initiated single sign-on.

On the Redis Software Cluster Manager UI's sign-in screen, click **Sign in with SSO**.

- If you already have an active SSO session with your identity provider, this signs you in.

- Otherwise, the SSO flow redirects you to your identity provider's sign in screen. Enter your IdP user credentials to sign in. This redirects you back to the Redis Software Cluster Manager UI and automatically signs you in.

Authentication requests expire after 3 minutes.

IdP requirements

You can use any identity provider to integrate with Redis Software as long as it supports the following:

- [SAML](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) 2.0 protocol.

- Signed SAML responses since Redis Software will not accept any unsigned SAML responses.

- HTTP-Redirect binding for SP-initiated SSO.

- HTTP-POST binding for SAML assertions.

Set up SAML SSO

To set up SAML single sign-on for a Redis Software cluster:

1. [Upload the service provider certificate and private key](#upload-sp-certificate).

1. [Download the service provider metadata](#download-sp-metadata).

1. [Set up a SAML app](#set-up-app) to integrate Redis Software with your identity provider.

1. [Download identity provider metadata](#download-idp-metadata).

1. [Configure SAML identity provider in Redis Software](#configure-idp-metadata).

1. [Assign the SAML app to existing users](#assign-saml-app-to-existing-users).

1. [Activate SSO](#activate-sso).

Upload SP certificate

1. Create a service provider certificate for Redis Software. See [Create certificates ]() for instructions.

1. Upload the service provider certificate and key to the Redis Software cluster:

    **Cluster Manager UI:**

1. Sign in to the Redis Software Cluster Manager UI using admin credentials.

1. Go to **Access Control > Single Sign-On**.

    <img src="../../../../../images/rs/screenshots/access-control/sso/sso-before-config.png" alt="The single sign-on configuration screen.">

1. In the **Service Provider (Redis) metadata** section, find **Service-provider's public certificate + private key** and click **Upload**.

1. Enter or upload the private key and certificate for your service provider.

1. Click **Upload** to save.

**REST API:**

To upload a certificate using the REST API, use an [update cluster certificates]() request.

[code example]

Download SP metadata

You need to download the service provider metadata for Redis Software and use it to configure the SAML integration app for your identity provider.

**Cluster Manager UI:**

To download the service provider's metadata using the Cluster Manager UI:

1. Go to **Access Control > Single Sign-On**.

1. In the **Service Provider (Redis) metadata** section, click the following buttons to download the service provider files needed to set up a SAML app:

    1. **Public certificate**

    1. **Metadata file**

    <img src="../../../../../images/rs/screenshots/access-control/sso/sp-metadata-after-cert-upload.png" alt="The service provider Redis metadata section.">

1. Optionally copy the following values for future SAML app setup in the identity provider. You can also find these values in the service provider's metadata file.

    1. **SP entity ID**: `https://<cluster-FQDN>/sp`

    1. **Assertion Consumer Service (ACS)**: `https://<cluster-FQDN>:8443/cluster/sso/saml/acs`

    1. **Single Logout Service**: `https://<cluster-FQDN>:8443/cluster/sso/saml/slo`

**REST API:**

To download the service provider's metadata using the REST API, use a [get SAML service provider metadata]() request.

[code example]

Here's an abridged example of the service provider metadata XML:

[code example]

See [Metadata for the OASIS Security
Assertion Markup Language (SAML)
V2.0](https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf) for more information about the metadata fields.

Redis Software metadata expiration time is equivalent to the SSO service certificate's expiration time. The service provider metadata will only change if the service address used for the Assertion Consumer Service (ACS) and the single logout (SLO) URL is modified.

Set up SAML app {#set-up-app}

Set up a SAML app to integrate Redis Software with your identity provider:

1. Sign in to your identity provider's admin console.

1. Create or add a SAML integration app for the service provider Redis Software. For detailed setup instructions, see your identity provider's documentation.

1. Configure the SAML app with the service provider metadata.

    - Some identity providers let you upload the XML file directly.

    - Others require you to manually configure the service provider app with specific metadata fields, such as:

        | Setting | Value | Description |
        |---------|-------|-------------|
        | Audience URI (SP Entity ID) | `https://<cluster-FQDN>:8443/sp` | Unique URL that identifies the Redis Software service provider.

Copy the **SP entity ID** from the **Access Control > Single Sign-On** page in the Cluster Manager UI or `EntityDescriptor`'s `entityID` in the metadata XML. |
        | Single sign-on URL | `https://<cluster-FQDN>:8443/cluster/sso/saml/acs` | The service provider endpoint where the identity provider sends a SAML assertion that authenticates a user.

Copy the **Assertion Consumer Service (ACS)** from the **Access Control > Single Sign-On** page in the Cluster Manager UI or `AssertionConsumerService`'s `Location` in the metadata XML. |
        | Name ID format | EmailAddress | |
        | Application username | Email | |

1. For the signature certificate, upload the Service Provider (Redis) public certificate.

1. Enable signed requests.

1. Optionally, you can enable single log-out (SLO) to allow users to automatically sign out of the the identity provider when they sign out of the Redis Software Cluster Manager UI. Copy the **Single Logout Service** from the **Access Control > Single Sign-On** page in the Cluster Manager UI (`https://<cluster-FQDN>:8443/cluster/sso/saml/slo`) and configure it in the SAML app.

Redis Software only supports SP-initiated logout, where the user logs out from the Redis Software Cluster Manager UI. IdP-initiated logout requests are not supported.

1. Set up your SAML service provider app so the SAML assertion contains the following attributes:

    | Attribute name (case-sensitive) | Description |
    |-------------------------------------------|-------------|
    | firstName | User's first name |
    | lastName | User's last name |
    | email | User's email address (used as the username in the Redis Software Cluster Manager UI) |
    | redisRoleMapping | String array that includes the role UID for role-based access control in Redis Software. Only used for just-in-time (JIT) user provisioning. If a user already exists in Redis Software, this attribute is ignored and their existing roles are preserved. |

To confirm the identity provider's SAML assertions contain the required attributes, you can use a SAML-tracer web developer tool to inspect them.

1. Set up any additional configuration required by your identity provider to ensure you can configure the `redisRoleMapping` attribute for SAML users.

    If your identity provider lets you configure custom attributes with workflows or group rules, you can set up automation to configure the `redisRoleMapping` field automatically instead of manually.

Download IdP metadata

After you create the SAML app in your identity provider, retrieve the following information:

| Setting | Description |
|---------|-------------|
| Issuer (IdP entity ID) | The unique entity ID for the identity provider |
| IdP server URL | The identity provider's HTTPS URL for SAML SSO |
| Single logout URL | The URL used to sign out of the identity provider and connected apps (optional) |
| Assertion signing certificate | Public SHA-256 certificate used to validate SAML assertions from the identity provider |

You will use this certificate and metadata to configure the identity provider metadata in Redis Software. To find these metadata values, see your identity provider's documentation.

Configure IdP metadata in Redis Software {#configure-idp-metadata}

After you set up the SAML integration app, you need to configure the identity provider metadata in your Redis Software cluster.

**Cluster Manager UI:**

1. Sign in to the Redis Software Cluster Manager UI using admin credentials.

1. Go to **Access Control > Single Sign-On**.

1. In the **Identity Provider metadata** section, click **Edit**.

1. Enter the **Identity Provider metadata** settings.

    <img src="../../../../../images/rs/screenshots/access-control/sso/edit-idp-metadata.png" alt="The identity provider metadata dialog.">

1. Click **Save**.

**REST API:**

1. Upload your SAML app's assertion signing certificate using an [update cluster certificates]() REST API request.

    [code example]

1. Configure the identity provider metadata using an [update SSO configuration]() REST API request.

    [code example]

Assign SAML app to existing users

In the identity provider's admin console:

1. Create user profiles in the identity provider for existing Redis Software users. Make sure each user's email address matches in the identity provider and Redis Software.

You do not need to configure the `redisRoleMapping` attribute for existing Redis Software users. Their current roles will be preserved, and the `redisRoleMapping` attribute is ignored if provided.

2. Assign the new SAML integration app to each user.

See your identity provider's documentation for detailed instructions.

Activate SSO {#activate-sso}

After you finish the required SAML SSO configuration between your identity provider and Redis Software cluster, you can activate SSO.

**Cluster Manager UI:**

To activate single sign-on using the Cluster Manager UI:

1. Go to **Access Control > Single Sign-On**.

1. Click **Activate SSO**.

**REST API:**

To activate single sign-on using the REST API, use an [update SSO configuration]() request.

[code example]

Add new users with JIT provisioning

After single sign-on is activated for Redis Software, you can create new Redis Software users on the identity provider side using just-in-time (JIT) provisioning.

1. In the identity provider's admin console, create a new user profile with a valid email address. See your identity provider's documentation for detailed instructions.

1. Configure the `redisRoleMapping` and assign a Redis Software role UID to the user.

To see a list of available role UIDs in your cluster, use a REST API request to [get all roles]():

[code example]

1. Assign the new SAML integration app to the user.

1. Redis Software will create a new user with the mapped role the first time the new user signs in to the Cluster Manager UI using SSO.

Enforce SSO

If SSO is enforced for the cluster, non-admin users can no longer sign in with their previous usernames and passwords and must use SSO instead.

**Cluster Manager UI:**

To enforce single sign-on using the Cluster Manager UI:

1. Go to **Access Control > Single Sign-On**.

1. Find **Fallback behavior** and click **Edit**.

1. Select **Enforce SSO-only login**.

    <img src="../../../../../images/rs/screenshots/access-control/sso/enforce-sso.png" alt="Enforce SSO-only login is selected.">

1. Click **Save**.

**REST API:**

To enforce single sign-on using the REST API, use an [update SSO configuration]() request.

[code example]

Update configuration {#update-config}

If you change certain metadata or configuration settings after you set up SSO, such as the assertion signing certificate, remember to do the following:

1. [Update the SAML SSO configuration](#configure-idp-metadata) with the new values.

1. [Download the updated service provider metadata](#download-sp) and use it to update the Redis Software service provider app.

Change SP address

If your deployment's default service provider address is not accessible to external identity providers, you can change it to an external hostname.

If you change the service address, the existing SSO integration will break because the metadata file, SP login and logout URLs, and entity ID will change to match the new address. You must update the service provider configuration on the identity provider's side after this change.

To change the service provider address, use an [update SSO configuration]() REST API request:

[code example]

Deactivate SSO

**Cluster Manager UI:**

To deactivate single sign-on using the Cluster Manager UI:

1. Go to **Access Control > Single Sign-On**.

1. Click **Deactivate SSO**.

1. Click **Confirm**.

**REST API:**

To deactivate single sign-on using the REST API, use an [update SSO configuration]() request.

[code example]

PUT https://<host>:<port>/v1/cluster/certificates
{
  "certificates": [
    {
      "name": "<cert_name>",
      "certificate": "sso_service",
      "key": "<key>"
    }
  ]
}

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2025-12-25T20:38:29" cacheDuration="PT2589134S" entityID="https://<cluster-FQDN>:8443/sp" ID="<ID>">
    ...
    <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        ...
        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://<cluster-FQDN>:8443/cluster/sso/saml/slo"/>
        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://<cluster-FQDN>:8443/cluster/sso/saml/acs" index="1"/>
        <md:AttributeConsumingService index="1">
            <md:ServiceName xml:lang="en">Redis Cluster Enterprise - <cluster-FQDN></md:ServiceName>
            <md:ServiceDescription xml:lang="en">Redis Cluster Enterprise SSO</md:ServiceDescription>
            <md:RequestedAttribute Name="firstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="firstName" isRequired="true"/>
            <md:RequestedAttribute Name="lastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="lastName" isRequired="true"/>
            <md:RequestedAttribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="email" isRequired="true"/>
            <md:RequestedAttribute Name="redisRoleMapping" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic" FriendlyName="redisRoleMapping"/>
        </md:AttributeConsumingService>
    </md:SPSSODescriptor>
</md:EntityDescriptor>

PUT https://<host>:<port>/v1/cluster/certificates
    {
      "certificates": [
        {
          "name": "<cert_name>",
          "certificate": "sso_issuer",
          "key": "<key>"
        }
      ]
    }

PUT https://<host>:<port>/v1/cluster/sso
    {
      "protocol": "saml2",
      "issuer": {
        "id": "urn:sso:example:idp",
        "login_url": "https://idp.example.com/sso/saml",
        "logout_url": "https://idp.example.com/sso/slo"
      }
    }

PUT https://<host>:<port>/v1/cluster/sso
{
    "control_plane": true
}

PUT https://<host>:<port>/v1/cluster/sso
{
    "enforce_control_plane": true
}

PUT https://<host>:<port>/v1/cluster/sso
{
  "service": {
    "address": "https://<external-domain>"
  }
}

PUT https://<host>:<port>/v1/cluster/sso
{
    "control_plane": false
}