This is an automated email from the ASF dual-hosted git repository.
mmerli pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.wiki.git
The following commit(s) were added to refs/heads/master by this push:
new 0ab241c Created PIP-55: Refresh Authentication Credentials (markdown)
0ab241c is described below
commit 0ab241c82481abccce6f46f5f81947879d11411c
Author: Matteo Merli <[email protected]>
AuthorDate: Tue Jan 14 15:19:07 2020 -0800
Created PIP-55: Refresh Authentication Credentials (markdown)
---
PIP-55:-Refresh-Authentication-Credentials.md | 95 +++++++++++++++++++++++++++
1 file changed, 95 insertions(+)
diff --git a/PIP-55:-Refresh-Authentication-Credentials.md
b/PIP-55:-Refresh-Authentication-Credentials.md
new file mode 100644
index 0000000..945ac4f
--- /dev/null
+++ b/PIP-55:-Refresh-Authentication-Credentials.md
@@ -0,0 +1,95 @@
+
+* **Status**: Proposal
+* **Author**: Matteo Merli
+* **Pull Request**:
+* **Mailing List discussion**:
+* **Release**:
+
+
+## Goals
+
+Enhance the Pulsar Authentication framework to support credentials that
+expire over time and need to be refreshed by forcing clients to
+re-authenticate.
+
+Typical examples are:
+ * TLS certificates with expiry date
+ * JWT with expiry setting
+ * Other token based systems for which the expiration might be retrieved
+ * Handle revocation of credentials by forcing revalidation with time-bound
limits
+
+## Context
+
+Currently, we're validating the authentication credentials when the connection
is
+established and that point we check the expiry times (eg: on TLS certificates
or
+on JWT tokens).
+
+After the initial connection is authenticated, we store the "principal" which
+will be used for authorization though the connection will not be
re-authenticated
+again.
+
+If the token expires while the client is connected, we need to be able to
+force the client to reconnect, in the least intrusive way, and disconnect if
+it's the re-authentication fails.
+
+## Implementation
+
+The implementation is extending the work done to support mutual authentication
+for SASL.
+
+The single `AuthenticationState` interface credentials holder will have 2 more
+methods:
+
+```java
+public interface AuthenticationState {
+ // .....
+
+ /**
+ * If the authentication state is expired, it will force the connection
+ * to be re-authenticated.
+ */
+ default boolean isExpired() {
+ return false;
+ }
+
+ /**
+ * If the authentication state supports refreshing and the credentials are
expired,
+ * the auth provider will call this method of initiate the refresh process.
+ * <p>
+ * The auth state here will return the broker side data that will be used
to send
+ * a challenge to the client.
+ *
+ * @return the {@link AuthData} for the broker challenge to client
+ * @throws AuthenticationException
+ */
+ default AuthData refreshAuthentication() throws AuthenticationException {
+ return null;
+ }
+}
+```
+
+Existing authentication plugins will be unaffected. If a new plugin wants
+to support expiration it will just have to override the `isExpired()` method.
+
+Pulsar broker will make sure to periodically check the expiration status
+for the `AuthenticationState` of every `ServerCnx` object.
+
+A new broker setting will be used to control the frequency of the expiration
+check:
+
+```shell
+# Interval of time for checking for expired authentication credentials
+authenticationRefreshCheckSeconds=60
+```
+
+### Interaction with older clients
+
+Broker will be able to know whether a particular client supports the
+authentication refresh feature.
+
+If a client is not supporting the refreshing of the authentication and the
+credentials are expired, the broker will disconnect it.
+
+This will not be problematic because the client already will need a way to
+pass the new credentials or it will fail anyway at the first time a TCP
+connection with a broker is cut.