As Ismael has said, we do not have a requirement to support multiple protocols in a broker. But I agree with Jun's observation that some companies might want to support a different authentication mechanism for internal users or partners. For instance, we do use two different authentication mechanisms, it just so happens that we are able to use certificate-based authentication for internal users, and hence don't require multiple SASL mechanisms in a broker.
As Tao has pointed out, mechanism negotiation is a common usage pattern. Many existing protocols that support SASL do already use this pattern. AMQP ( http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#type-sasl-mechanisms), which, as a messaging protocol maybe closer to Kafka in use cases than Zookeeper, is an example. Other examples where the client negotiates or sends SASL mechanism to server include ACAP that is used as an example in the SASL RFCs, POP3, LDAP, SMTP etc. This is not to say that Kafka shouldn't use a different type of mechanism selection that fits better with the existing Kafka design. Just that negotiation is a common pattern and since we typically turn on javax.net.debug to debug TLS negotiation issues, having to use Kafka logging to debug SASL negotiation issues is not that dissimilar. On Tue, Feb 2, 2016 at 6:12 AM, tao xiao <xiaotao...@gmail.com> wrote: > I am the author of KIP-44. I hope my use case will add some values to this > discussion. The reason I raised KIP44 is that I want to be able to > implement a custom security protocol that can fulfill the need of my > company. As pointed out by Ismael KIP-43 now supports a pluggable way to > inject custom security provider to SASL I think it is enough to cover the > use case I have and address the concerns raised in KIP-44. > > For multiple security protocols support simultaneously it is not needed in > my use case and I don't foresee it is needed in the future but as i said > this is my use case only there may be other use cases that need it. But if > we want to support it in the future I prefer to get it right at the first > place given the fact that security protocol is an ENUM and if we stick to > that implementation it is very hard to extend in the future when we decide > multiple security protocols is needed. > > Protocol negotiation is a very common usage pattern in security domain. As > suggested in Java SASL doc > > http://docs.oracle.com/javase/7/docs/technotes/guides/security/sasl/sasl-refguide.html > client > first sends out a packet to server and server responds with a list of > mechanisms it supports. This is very similar to SSL/TLS negotiation. > > On Tue, 2 Feb 2016 at 06:39 Ismael Juma <ism...@juma.me.uk> wrote: > > > On Mon, Feb 1, 2016 at 7:04 PM, Gwen Shapira <g...@confluent.io> wrote: > > > > > Looking at "existing solutions", it looks like Zookeeper allows > plugging > > in > > > any SASL mechanism, but the server will only support one mechanism at a > > > time. > > > > > > > This was the original proposal from Rajini as that is enough for their > > needs. > > > > > > > If this is good enough for our use-case (do we actually need to support > > > multiple mechanisms at once?), it will simplify life a lot for us ( > > > > https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zookeeper+and+SASL > > ) > > > > > > > The current thinking is that it would be useful to support multiple SASL > > mechanisms simultaneously. In the KIP meeting, Jun mentioned that > companies > > sometimes support additional authentication mechanisms for partners, for > > example. It does make things more complex, as you say, so we need to be > > sure the complexity is worth it. > > > > Two more points: > > > > 1. It has been suggested that custom security protocol support is needed > by > > some (KIP-44). Rajini enhanced KIP-43 so that a SASL mechanism with a > > custom provider can be used for this purpose instead. Given this, it > seems > > a bit inconsistent and restrictive not to allow multiple SASL mechanisms > > simultaneously (we do allow SSL and SASL authentication simultaneously, > > after all). > > > > 2. The other option would be to support a single SASL mechanism > > simultaneously to start with and then extend this to multiple mechanisms > > simultaneously later (if and when needed). It seems like it would be > harder > > to support the latter in the future if we go down this route, but maybe > > there are ways around this. > > > > Thoughts? > > > > Ismael > > > -- Regards, Rajini
