PIP 55 Refresh Authentication Credentials
Hi, Would PIP 55 propose how the client side plugin can implement a credential/token refresh mechanism? The use case would be the client proactively refresh the bearer token before disconnected due to expiration by the broker. I am thinking some additions to Authentication/AuthenticationDataProvider interface that the client can registered with a callback either time based trigger or failure retrigger. Ming Kafkaesque.io
Re: PIP-55: Refresh Authentication Credentials
The main issue is how the changes in that PR interact with mutual authentication system like SASL/Kerberos which were already introduced in 2.4. The renew/renewed mechanism would have to work with auth-challenges and responses. Instead, I have changes that are built on top of that AuthState abstraction and do not require 1 timer per connection. Matteo -- Matteo Merli On Wed, Jan 15, 2020 at 10:22 AM Rajan Dhabalia wrote: > > Hi, > > We have the same ask and we had created PR to address the issue last year > with the PR: https://github.com/apache/pulsar/pull/3705 > > Thanks, > Rajan > > On Tue, Jan 14, 2020 at 3:21 PM Matteo Merli wrote: > > > > > https://github.com/apache/pulsar/wiki/PIP-55%3A-Refresh-Authentication-Credentials > > > > - > > > > ## 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. > > * > > * 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. > > > > -- > > Matteo Merli > > > >
Re: PIP-55: Refresh Authentication Credentials
Hi, We have the same ask and we had created PR to address the issue last year with the PR: https://github.com/apache/pulsar/pull/3705 Thanks, Rajan On Tue, Jan 14, 2020 at 3:21 PM Matteo Merli wrote: > > https://github.com/apache/pulsar/wiki/PIP-55%3A-Refresh-Authentication-Credentials > > - > > ## 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. > * > * 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. > > -- > Matteo Merli > >
PIP-55: Refresh Authentication Credentials
https://github.com/apache/pulsar/wiki/PIP-55%3A-Refresh-Authentication-Credentials - ## 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. * * 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. -- Matteo Merli