Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

...

  1. Add a new type of exception that can be thrown by the SecurityManager "authorize" method: AuthenticationExpiredException 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 AuthenticationExpiredException If 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 are is logic on the java client to do re-authentication when user attribute attributes somehow "disappeared" from the server, we can piggyback on this logic to handle the AuthenticationExpiredException.
  2. For the older version versions of the client, it just need 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.

...