Hi Colin. Different organizations will rely on different token lifetimes, but anything shorter than an hour feels like it would be pretty aggressive. An hour or more will probably be most common.
<<<alternate solution of terminating connections when the bearer token changed I may be mistaken, but I think you are suggesting here that we forcibly kill connections from the client side whenever the background Login refresh thread refreshes the token (which it currently does so that the client can continue to make new connections). Am I correct? If that is what you are referring to, my sense is that it would be a very crude way of dealing with the issue that would probably lead to dissatisfaction in some sense (though I can't be sure). I do know that when I implemented SASL/OAUTHBEARER it was communicated that leaving existing connections intact -- as is done for GSSAPI -- was the appropriate path forward. Ron On Tue, Sep 4, 2018 at 8:31 PM Colin McCabe <cmcc...@apache.org> wrote: > 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 >
