On Tue, Sep 4, 2018, at 17:43, Ron Dagostino wrote: > 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.
Thanks. That's helpful to give me a sense of what the performance impact might be. > > <<<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? Yes, this is what I'm thinking about. We could also terminate the connection on the server, if that is more convenient. > 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). What information should we gather so that we can 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. Thanks, that's good background information. Can someone chime in with the reasoning behind this? My best guess is that terminating connections might cause a temporary increase in latency as they are re-established. In any case, we should figure out what the reasoning is so that we can make a decision. It seems worthwhile including this as a "rejected alternative," at least. thanks, Colin > > 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 > >
