Page History

...

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

Problem

The Redis API for geode Geode currently supports authentication only 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 and authorization goes through the security-manager when it is configured. 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 users to write a security-manager that can to expire or de-authorize an authenticated user and require new authenticationprincipal. 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.

...

We are not trying to implement fine-grained authorization for Redis as this 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, rather than having different permissions for each command type or data structure.

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 will 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 an 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-user 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 principleprincipal, we will call the authorize method on the security-manager with that principle principal and the ResourcePermission DATA:WRITE:REDIS_DATA. This is the equivalent of granting a Geode user write access to the REDIS region.

...

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 be expected to 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 connects connections to the server. A Redis client will have to authenticate once for each connection. This may create additional work for the users security-manager.

Backwards Compatibility and Upgrade Path

...