Authentication expiry is supported only with client connections. The use of expirable credentials is most common when used in combination with token-based authentication and authorization. Authentication expiry makes it possible for cluster administrators to limit the life span of client connections within the cluster.
Client connections are notified of expiry by AuthenticationExpiredException
, which is thrown in the implementations of SecurityManager.authenticate
or SecurityManager.authorize
.
Upon receiving the AuthenticationExpiredException, clients will make one automatic attempt to gather new credentials and reconnect (AuthInitialize.getCredentials()). Upon receiving a second AuthenticationExpiredException
the exception is thrown back to the user to handle. There are some differences in behavior between older and newer clients.
Support for Automatic Reconnect
Client version | single user ops | multi user ops | single user CQ/RI | multi user CQ/RI |
---|---|---|---|---|
Geode 1.15 and later | Y | Y | Y | N |
older than Geode 1.15 | Y | Y | N | N |
Y = supported
N = not supported
Clients older than version 1.15 will also be able to do an automatic reconnect unless the connection is one of the following types where the exception will always be propagated up the chain:
The common cycle for authentication and authorization is the following:
AuthInitialize.getCredentials(...) -> SecurityManager.authenticate(...) -> SecurityManager.authorize(...)
In case of the use of an external token provider we assume that this token provider will be asked for a token in the AuthInitialize.getCredentials()
call. A token provider can return existing tokens (which are about to expire) for a given user, so it is recommended that implementers of the AuthInitialize
and SecurityManager
interfaces take imminent timeout and token refresh in consideration to avoid receiving multiple unintended AuthenticationExpiredException
s in a row and having to deal with the propagation of these exceptions.