Page History

To be Reviewed By:

Authors:  Jinmei Liao/Dan Smith/Jacob Barrett/Joris Melchior

Status: Draft | Discussion | Active | Dropped | Superseded

Superseds: N/A 

...

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.
4. For event driven operations, such as CQ and registered interests, we will need to check if the credential has expired when dispatching the event. 
   1. Just before sending an event to the client, call SecurityManager.authorize  (in MessageDispatcher.runDispatcher or thereabouts).
   2. If an AuthenticationExpiredException is thrown, catch it, and if the client is the new version client, send some sort of AuthorizationExpired token to the client. If the client is old, close the connection.
   3. After sending an AuthorizationExpired token, wait for a re-authorization request. Maybe only for some period of time before going back to 1 and trying again with the same event.

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.
4. For event driven clients (CQ/registered interests clients):
   1. handle the AuthorizationExpired token when it is received from the server by re-authenticating (in CacheClientUpdater.processMessages or thereabouts).
   2. For older the clients, connection to the server will be lost after credential expired.

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
   1. Make sure in this mode, expiring one user doesn't interrupt the other user's connections. 
2. register interests and CQ
   1. In these cases, when the user making the CQ and registered interests has expired, no further data will be sent back to the user unless re-authenticated.
3. function execution on servers
   1. we will need to verify that when user expires, function executions on all servers will be stopped and re-authenticated.
4. WAN
   1. WAN automatically re-authenticate itself since the gateway-sender uses a client to send messages. We should verify that re-authentication happens and no messages are lost.

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.

...