Hi Ron, Thanks for the KIP.
What is the frequency at which you envision bearer tokens changing at? Did you consider the alternate solution of terminating connections when the bearer token changed? best, Colin On Tue, Aug 28, 2018, at 07:28, Ron Dagostino wrote: > Hi everyone. I created KIP 368: Allow SASL Connections to Periodically > Re-Authenticate > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-368%3A+Allow+SASL+Connections+to+Periodically+Re-Authenticate> > ( > https://cwiki.apache.org/confluence/display/KAFKA/KIP-368%3A+Allow+SASL+Connections+to+Periodically+Re-Authenticate). > The motivation for this KIP is as follows: > > The adoption of KIP-255: OAuth Authentication via SASL/OAUTHBEARER > <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75968876> > in > release 2.0.0 creates the possibility of using information in the bearer > token to make authorization decisions. Unfortunately, however, Kafka > connections are long-lived, so there is no ability to change the bearer > token associated with a particular connection. Allowing SASL > connections > to periodically re-authenticate would resolve this. In addition to this > motivation there are two others that are security-related. First, to > eliminate access to Kafka for connected clients, the current requirement > is > to remove all authorizations (i.e. remove all ACLs). This is necessary > because of the long-lived nature of the connections. It is > operationally > simpler to shut off access at the point of authentication, and with the > release of KIP-86: Configurable SASL Callback Handlers > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-86%3A+Configurable+SASL+callback+handlers> > it > is going to become more and more likely that installations will > authenticate users against external directories (e.g. via LDAP). The > ability to stop Kafka access by simply disabling an account in an LDAP > directory (for example) is desirable. The second motivating factor for > re-authentication related to security is that the use of short-lived > tokens > is a common OAuth security recommendation, but issuing a short-lived > token > to a Kafka client (or a broker when OAUTHBEARER is the inter-broker > protocol) currently has no benefit because once a client is connected to > a > broker the client is never challenged again and the connection may > remain > intact beyond the token expiration time (and may remain intact > indefinitely > under perfect circumstances). This KIP proposes adding the ability for > clients (and brokers when OAUTHBEARER is the inter-broker protocol) to > re-authenticate their connections to brokers and have the new bearer > token > appear on their session rather than the old one. > > The description of this KIP is actually quite straightforward from a > functionality perspective; from an implementation perspective, though, the > KIP is not so straightforward, so it includes a pull request with a > proposed implementation. See https://github.com/apache/kafka/pull/5582. > > Ron
