[GitHub] [geode] jinmeiliao commented on a change in pull request #7248: GEODE-9933: documentation for authorization expiry

[GitBox <gi...@apache.org>]

jinmeiliao commented on a change in pull request #7248:
URL: https://github.com/apache/geode/pull/7248#discussion_r786983353



##########
File path: geode-docs/managing/security/implementing_authentication_expiry.html.md.erb
##########
@@ -0,0 +1,55 @@
+---
+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 makes it possible for cluster administrators to limit the life span of client
+and peer connections within the cluster. The use of expirable credentials is most common when used in
+combination with token based authentication and authorization.
+
+Client connections are notified of expiry through the throwing of an `AuthenticationExpiredException`
+which is thrown in the implementations of `SecurityManager.authenticate` or `SecurityManager.authorize`.
+
+Clients starting with version 1.15 will do one automatic attempt to reconnect. Upon receiving a
+second `AuthenticationExpiredException` the exception will be propagated up the chain for the user to
+handle.
+
+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:

Review comment:
       I think this is misleading. Older client with multi-user auth will still work in regular user operations like put/get etc. 
   
   Probably a diagram would explain this better
   ```
                          single user ops  |    single user CQ/RI  |  multi user ops  |  multi user CQ/RI
   1.15 and later                          |                       |                  |         X
   previous                                |             X         |                  |         X
   ```

##########
File path: geode-docs/managing/security/implementing_authentication_expiry.html.md.erb
##########
@@ -0,0 +1,55 @@
+---
+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 makes it possible for cluster administrators to limit the life span of client
+and peer connections within the cluster. The use of expirable credentials is most common when used in
+combination with token based authentication and authorization.
+
+Client connections are notified of expiry through the throwing of an `AuthenticationExpiredException`
+which is thrown in the implementations of `SecurityManager.authenticate` or `SecurityManager.authorize`.
+
+Clients starting with version 1.15 will do one automatic attempt to reconnect. Upon receiving a
+second `AuthenticationExpiredException` the exception will be propagated up the chain for the user to
+handle.
+
+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)
+
+## <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(...)
+```
+
+Where `AuthInitialize.getCredentials()` provides the `security properties` for `SecurityManager.authenticate()` which
+in turn provides the `principal object` for `SecurityManager.authorize()`.
+
+In case of the use of an external token provider we assume that this token provider will be asked for

Review comment:
       Emphasize that there would be time gap between the call of `getCredential` and `authorize`




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@geode.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org