*Re-authentication vs disconnection:* In a vast number of secure Kafka deployments, SASL_SSL is the security protocol (this is the recommended config for OAUTHBEARER). If we require disconnections on token expiry, we would need new connections to be established with an expensive SSL handshake. This adds load on the broker and will result in a latency spike. For OAUTHBEARER in particular, when tokens are used to make authorisation decisions, we want to be a able to support short-lived tokens where token lifetime (granting authorisation) is small. To make this usable in practice, I believe we need to support re-authentication of existing connections.
*Also explicitly out-of-scope for this proposal is the ability for brokers to close connections that continue to use expired credentials. This ability is a natural next step, but it will be addressed via a separate KIP if/when this one is adopted.* Perhaps we could do this the other way round? I don't think we would ever want to close connections on the client-side to support expired credentials because that doesn't add any security guarantees. But we do require the ability for brokers to close connections in order to enforce credential expiry. Disconnection on the broker-side may be sufficient for some deployments and could be useful on its own. It would also be the easier implementation. So maybe that could be the first step? *The implementation is designed in such a way that it does not preclude adding support for re-authentication of other SASL mechanism (e.g. PLAIN, SCRAM-related, and GSSAPI), but doing so is explicitly out-of-scope for this proposal. * Isn't re-authentication driven by ExpiringCredential? We don't need to support re-authentication by default for the other mechanisms in this KIP, but any mechanism could enable this by adding a custom login callback handler to provide an ExpiringCredential? For disconnection as well as re-authentication, it will be good if we can specify exactly how it can be implemented for each of the SASL mechanisms, even if we actually implement it only for OAUTHBEARER. On Wed, Sep 5, 2018 at 2:43 AM, Colin McCabe <cmcc...@apache.org> wrote: > 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 > > > >
