On Demand Geode Authentication Expiration and Re-authentication

To be Reviewed By:

Authors:  Jinmei Liao

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: Google Doc 

Related: N/A

Problem

Currently, when a user is authenticated into Geode, the credentials remain active in the server until user logs out or the client's cache is closed. However, in the token-based authentication scenario, credentials can expire when a client is still actively connected to the server, so we need a way to have the server reject further operations from the client when credential expires and notify the client to re-authenticate. 

Anti-Goals

The first cut of the solution is to focus only on client-server connections. Pulse/Gfsh/Rest connections are outside of the scope of this RFC.

Solution

The Solution should have those effects

• The server should reject further operations once the authentication is deemed to have expired.
• The server should notify the client that the operation failed because the credential has expired. 
• The server, once a user expired, should clean the user attributes from the server.
• The client, once received the notification, should gather the new credentials and re-authenticate (only applies to java client for now, and only for the newer version of java clients).
• The client, if multiple operations are in flight, should not flood the authentication server with re-authentication requests.

Server Changes

1. Add a new type of exception, AuthenticationExpiredException, that can be thrown by the SecurityManager authorize method. SecurityManager authorize method is implemented by the third-party. We don't need to care how they determine user expiration. We just need to handle the AuthenticationExpiredExceptionIf it's thrown.
2. The exception will need to bubble all the way back to the client
3. When a client is authenticated, an entry with the client's longID as the key is added to map maintained by the ClientUserAuths. The entry is removed and the related shiro subject is logged out  to prevent resource leaks when client's cache is closed. When an authentication expires, we need to do the same with the current authenticated subject and clean that entry out of the map as well. This logic needs to be added to the code path where the AuthenticationExpiredException is thrown.

Java Client Changes

1. There is logic on the java client to do re-authentication when user attributes somehow "disappeared" from the server, we can piggyback on this logic to handle the AuthenticationExpiredException.
2. For the older versions of the client, it just needs to be notified of the exception, no re-authentication is required on older clients.
3. When credentials expired, if there are multiple operations from the client, we need to do something to prevent the client from sending out multiple re-authentication requests to the authentication server.

Things to verify:

We need to make sure in the following scenarios, the behavior will be acceptable and shouldn't introduce any security leaks:

1. multi-user mode
2. register interests and CQ
3. function execution on servers

Performance Impact

For on-demand re-authentication, credential expiration is discovered by the server, the client gets the notification then initiate re-authentication. Client operations will be interrupted at some period, the client will try re-authenticate only once for this operation again, hopefully the 2nd time, it will succeed.

Backwards Compatibility and Upgrade Path

The exception thrown by the server will be passed down to the older clients. But in order to re-authenticate automatically, users will need to use the newer-version java client.

Prior Art

N/A

FAQ

N/A

Errata

N/A