| --- |
| title: Implementing Authentication Expiry |
| --- |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| 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 |
| |
| ``` pre |
| 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: |
| |
| * multi-user client mode |
| * event-dispatching (CQ and registered interest) |
| |
| ## <a id="authentication_expiry_considerations"></a>Authentication Expiry Considerations |
| |
| The common cycle for authentication and authorization is the following: |
| |
| ```pre |
| 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. |