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 >
