Integrate Geode's redis API with the security manager

To be Reviewed By: 8/31/2021

Authors: Dan Smith

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: GEODE-9542, GEODE-9544, GEODE-9546, GEODE-9547

Problem

The Redis API for Geode currently supports authentication with a single password that is configured using the Geode property compatible-with-redis-password. This is not ideal for security. The password is stored on the server, it cannot be rotated without restarting the server, etc. All other Geode authentication goes through the security-manager. Redis authentication should happen through the security-manager as well. When a security-manager is configured only users that are authorized to access the Redis API should be allowed to use it.

The in progress proposal On Demand Geode Authentication Expiration and Re-authentication allows a user's security-manager to expire or de-authorize an authenticated principal. We would like to support at least the basic de-authorization feature with the Redis API. Therefore Redis commands will also need to call the authorization method on the security-manager for each operation to allow the security-manager an opportunity to reject them.

Anti-Goals

• We are not trying to implement fine-grained authorization for Redis at this time - meaning we do not intend to have different permissions for different Redis commands. For now, all Redis commands will require the same basic permissions.
• We are not supporting the full scope of on-demand re-authentication for Redis. We are not in control of the behavior of the Redis client. If a user wants to allow authenticated principals to expire and require re-authentication, it will be their responsibility to figure out how to get the client to re-authenticate itself. 

Solution

1. We will remove the property compatible-with-redis-password. This is an experimental property so there is no need to maintain it for backwards compatibility.
2. With older versions of Redis the AUTH command only supports a password and not a username. To continue to support clients that do not send a username we will introduce a new geode property - compatible-with-redis-username. This will be the default username if no username is passed with the AUTH command.
3. If a security-manager is configured Redis clients will receive a NOAUTH response if they try to perform operations without calling AUTH. This is the same behavior we have today if the compatible-with-redis-password is not set.
4. When a user issues the AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the user (security-username property) and the user-provided password (security-password property) and properly handle the AuthenticationFailedException. If the AUTH command was called without a user the value of compatible-with-redis-username should be used. The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls.
5. When the server receives a Redis command on a connection with an associated principal, we will call the authorize method on the security-manager with that principal and the ResourcePermission DATA:WRITE:REDIS_DATA. This is the equivalent of granting a Geode user write access to the REDIS_DATA region.

Performance Impact

Adding authorization calls to each Redis command may impact the performance of the commands if the user's security-manager is slow. However, authorization is also done for every Geode operation so users should implement the authorize method as efficiently as possible.

Another concern is that Geode clients only authenticate once per server, even if the client makes many connections to the server. A Redis client will have to authenticate once for each connection. This may create additional work for the user's security-manager.

Backwards Compatibility and Upgrade Path

The Redis API is still experimental. This change is not backwards compatible, but neither are many of the other Redis changes coming in 1.15.