[
https://issues.apache.org/jira/browse/KAFKA-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajini Sivaram resolved KAFKA-7352.
-----------------------------------
Resolution: Fixed
Reviewer: Rajini Sivaram
> 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)
