[ https://issues.apache.org/jira/browse/KAFKA-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ismael Juma updated KAFKA-7352: ------------------------------- Fix Version/s: (was: 2.1.0) 2.2.0 > KIP-368: Allow SASL Connections to Periodically Re-Authenticate > --------------------------------------------------------------- > > Key: KAFKA-7352 > URL: https://issues.apache.org/jira/browse/KAFKA-7352 > Project: Kafka > Issue Type: Improvement > Components: clients, core > Reporter: Ron Dagostino > Assignee: Ron Dagostino > Priority: Major > Labels: kip > Fix For: 2.2.0 > > > KIP-368: Allow SASL Connections to Periodically Re-Authenticate > The adoption of KIP-255: OAuth Authentication via SASL/OAUTHBEARER 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 > 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 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. -- This message was sent by Atlassian JIRA (v7.6.3#76005)