Page History

...

The in progress proposal On Demand Geode Authentication Expiration and Re-authentication allows a users 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 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-user 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 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 connections to the server. A Redis client will have to authenticate once for each connection. This may create additional work for the users user's security-manager.

Backwards Compatibility and Upgrade Path

...