*`authenticationRefreshCheckSeconds`* hey! I woul...
# general
d
authenticationRefreshCheckSeconds
hey! I would like to confirm behaviour of this broker config. I am using pulsar 2.11.2, without a pulsar proxy. • When using JWT auth, this config "works". That is, the broker will challenge the auth of a connected client if the JWT that was used to auth becomes expired. • When using mTLS auth, this config does not appear to have any affect (i.e. a cert with a ~1m expiry allows a client stay connected >1m+++). ◦ Comparing AuthenticationProviderToken.java to AuthenticationProviderTls.java it seems obvious that this logic is simply not implemented for mTLS (and the latter has an AuthenticationState impl. Ref) ◦ When i try and auth with an expired cert - this fails, as expected. But the validation is handled by JDK classes (e.g.
PKIXValidator
) - which again makes me think that pulsar is not checking the cert expiry post successful auth. So just to confirm that for mTLS, this config has no affect? Also, if folks agree this is a gap, ill raise a ticket in github.. (?) Furthermore - the only docs (official or otherwise) I can find on this config state: "The broker supports learning whether a particular client supports authentication refreshing. If a client supports authentication refreshing and the credential is expired, the authentication provider calls the
refreshAuthentication
method to initiate the refreshing process. If a client does not support authentication refreshing and the credential is expired, the broker disconnects the client." -
but as per my mTLS testing, neither outcome occurs - and my client can stay connected with a cert that has long since expired after the initial connection/auth. Thanks