Yes, I understand that. However, because the current configuration only allows a single callback and a single login module, I need to supply a class that supports callbacks or logins for every single mechanism that I need to support. I question whether this is applicable in real-world scenario where a user may need to support mechanisms that were written by different vendors and where a single class that implements all the necessary modules or callsbacks is very unlikely to exist.
I agree that supporting a list of classes and dynamically using the correct callbacks and modules based on configuration is complex, but I don't think this feature is useful enough without it. Gwen On Tue, Mar 8, 2016 at 2:40 AM, Rajini Sivaram <rajinisiva...@googlemail.com> wrote: > Gwen, > > Sorry if this is not clear in the KIP. The goal of the KIP is to enable new > mechanisms to be added without any changes to Apache Kafka. The > configuration proposed by the KIP is based on the configurability of the > Java SASL API and what it would take to add a new mechanism similar to > Kerberos/PLAIN/Digest-MD5 and the requirements that Tao raised for custom > authentication. > > The PR includes a test for Digest-MD5 which is not included in Kafka, but > is tested using the configuration options that allow new mechanisms to be > added. > > If you want to add a more complex mechanism which requires integration with > some external authentication libraries for login or callback handlers, you > can do that by configuring your own callback handler and login > implementation. The login class allows you to add additional threads (for > instance for token refresh), while the callback handler extends the > standard Java CallbackHandler interface, enabling you to override any of > the default callbacks in Kafka to provide your own behaviour. If you want > to add your own login modules, SASL server or SASL client implementation > for a mechanism that is not supported in your JDK, you can do that by > adding new Java security modules, using the built-in pluggability of Java > security. > > And finally, if you want to enable multiple mechanisms in your Kafka > brokers, you can specify a callback handler class that either provides the > handlers for all the mechanisms (as the PR does for Kerberos and PLAIN) or > a delegator that calls different callback handlers based on the mechanism. > And for login, you provide a single or a compound class that provides any > additional login logic for all the login modules that you have specified > for KafkaServer. > > Hope that helps. > > > On Tue, Mar 8, 2016 at 1:17 AM, Gwen Shapira <g...@confluent.io> wrote: > >> Can you explain the process for a adding a new mechanism based on current >> KIP? >> >> My thought is that if it requires modifying Apache Kafka code, it is >> not pluggable enough. >> >> On Mon, Mar 7, 2016 at 4:04 PM, Rajini Sivaram >> <rajinisiva...@googlemail.com> wrote: >> > Gwen, >> > >> > In cases where you want completely different callbacks for different >> > mechanisms, I was thinking that the choice would be between a map of >> > classes (mechanism -> callbackHandler class) or a delegator class that >> > chooses the appropriate callback handler class based on mechanism. I >> chose >> > the latter since it makes it easier to configure in Kafka. Since we >> create >> > a callback handler for each channel and configure it with the >> > client-selected mechanism, it is straightforward to have one wrapper >> class >> > that delegates to the right mechanism-specific class to handle callbacks. >> > In many cases, a single class may be sufficient (the PR uses a single >> > callback class for Kerberos and PLAIN). I do see your point about the >> > flexibility that multiple classes would provide, but since you need to be >> > able to associate the callback with a mechanism for this to be useful, I >> am >> > not sure if just a list would add value. >> > >> > Login class is slightly different since the proposal is to use a single >> > login context with multiple login modules to handle multiple mechanisms. >> In >> > this case, you want to perform login for all the mechanisms that are >> > enabled. And you want to call loginContext.login() only once. Again, you >> > can delegate to multiple classes if you wish to add some complex >> > mechanism-specific logic, but a single login class makes the mapping to a >> > single login context and the login cache more obvious (the PR has a test >> > that includes Kerberos and PLAIN). >> > >> > Thoughts? >> > >> > On Mon, Mar 7, 2016 at 9:57 PM, Gwen Shapira <g...@confluent.io> wrote: >> > >> >> Hi, >> >> >> >> Before I can vote on this KIP, I have two additional questions / >> >> comments on the new configuration: >> >> >> >> 1. sasl.callback.handler.class - it looks like we want a single class >> >> that implements all mechanisms. I think this will make it difficult to >> >> extend since the only way I can add a mechanism will be by >> >> implementing every single existing mechanism (otherwise customers will >> >> need to choose between new and existing when selecting which class to >> >> use). If Microsoft releases a proprietary "AD Mechanism" and Oracle >> >> releases "OID mechanism", there will be no class that implements both. >> >> Can we make it a list of classes instead? I realize this complicates >> >> the code a bit (some kind of factory will be required to choose the >> >> right class to use), but important IMO. >> >> 2. similar for sasl.login.class - if I have a class for Kerberos (with >> >> refresh thread) and a class for "plain", we need to be able to load >> >> both. >> >> >> >> Gwen >> >> >> >> On Wed, Mar 2, 2016 at 12:30 AM, Rajini Sivaram >> >> <rajinisiva...@googlemail.com> wrote: >> >> > Jun, >> >> > >> >> > Thanks, I have added a note to the KIP. I will add a comment in the >> >> > implementation and also add a unit test to ensure that conflicts are >> >> > avoided when version number is modified. >> >> > >> >> > On Tue, Mar 1, 2016 at 5:43 PM, Jun Rao <j...@confluent.io> wrote: >> >> > >> >> >> Rajini, >> >> >> >> >> >> Thanks for the explanation. For 1, this implies that we have to be >> >> careful >> >> >> with changing the 2-byte version in the future to avoid conflict. >> Could >> >> you >> >> >> document this in the KIP and also in the implementation? >> >> >> >> >> >> Jun >> >> >> >> >> >> On Tue, Mar 1, 2016 at 2:47 AM, Rajini Sivaram < >> >> >> rajinisiva...@googlemail.com >> >> >> > wrote: >> >> >> >> >> >> > Jun, >> >> >> > >> >> >> > Thank you for the review. >> >> >> > >> >> >> > >> >> >> > 1. With GSSAPI, the first context establishment packet starts >> with >> >> the >> >> >> > byte 0x60 (tag for APPLICATION-0) followed by a variable-length >> >> >> encoded >> >> >> > size, followed by various tags and contents. And the packet also >> >> >> > contains a >> >> >> > checksum. This is completely different from the mechanism packet >> >> from >> >> >> > Kafka >> >> >> > clients which start with a two-byte version set to zero >> currently, >> >> >> > followed >> >> >> > by just a String mechanism. >> >> >> > 2. Agreed, I have removed the version from the server response >> in >> >> the >> >> >> > KIP. Thanks. >> >> >> > >> >> >> > >> >> >> > On Tue, Mar 1, 2016 at 2:33 AM, Jun Rao <j...@confluent.io> wrote: >> >> >> > >> >> >> > > Rajini, >> >> >> > > >> >> >> > > Thanks for the updates. Just a couple of minor comments. >> >> >> > > >> >> >> > > 1. With the default GSSAPI, what's the first packet that the >> client >> >> >> sends >> >> >> > > to the server? Is that completely different from the packet >> format >> >> that >> >> >> > we >> >> >> > > will use for non-GSSAPI mechanisms? >> >> >> > > >> >> >> > > 2. In the server response, it doesn't seem that we need to >> include >> >> the >> >> >> > > version since the client knows the version of the request that it >> >> >> sends. >> >> >> > > >> >> >> > > Jun >> >> >> > > >> >> >> > > On Mon, Feb 29, 2016 at 10:14 AM, Rajini Sivaram < >> >> >> > > rajinisiva...@googlemail.com> wrote: >> >> >> > > >> >> >> > > > Harsha, >> >> >> > > > >> >> >> > > > Thank you for the review. I will wait another day to see if >> there >> >> is >> >> >> > more >> >> >> > > > feedback and then start a voting thread. >> >> >> > > > >> >> >> > > > Rajini >> >> >> > > > >> >> >> > > > On Mon, Feb 29, 2016 at 2:51 PM, Harsha <ka...@harsha.io> >> wrote: >> >> >> > > > >> >> >> > > > > Rajini, >> >> >> > > > > Thanks for the changes to the KIP. It looks >> good >> >> to >> >> >> > me. I >> >> >> > > > > think we can move to voting. >> >> >> > > > > Thanks, >> >> >> > > > > Harsha >> >> >> > > > > >> >> >> > > > > On Mon, Feb 29, 2016, at 12:43 AM, Rajini Sivaram wrote: >> >> >> > > > > > I have added some more detail to the KIP based on the >> >> discussion >> >> >> in >> >> >> > > the >> >> >> > > > > > last KIP meeting to simplify support for multiple >> mechanisms. >> >> >> Have >> >> >> > > also >> >> >> > > > > > changed the property names to reflect this. >> >> >> > > > > > >> >> >> > > > > > Also updated the PR in >> >> >> > > > https://issues.apache.org/jira/browse/KAFKA-3149 >> >> >> > > > > > to >> >> >> > > > > > reflect the KIP. >> >> >> > > > > > >> >> >> > > > > > Any feedback is appreciated. >> >> >> > > > > > >> >> >> > > > > > >> >> >> > > > > > On Tue, Feb 23, 2016 at 9:36 PM, Rajini Sivaram < >> >> >> > > > > > rajinisiva...@googlemail.com> wrote: >> >> >> > > > > > >> >> >> > > > > > > I have updated the KIP based on the discussion in the KIP >> >> >> meeting >> >> >> > > > > today. >> >> >> > > > > > > >> >> >> > > > > > > Comments and feedback are welcome. >> >> >> > > > > > > >> >> >> > > > > > > On Wed, Feb 3, 2016 at 7:20 PM, Rajini Sivaram < >> >> >> > > > > > > rajinisiva...@googlemail.com> wrote: >> >> >> > > > > > > >> >> >> > > > > > >> Hi Harsha, >> >> >> > > > > > >> >> >> >> > > > > > >> Thank you for the review. Can you clarify - I think you >> are >> >> >> > saying >> >> >> > > > > that >> >> >> > > > > > >> the client should send its mechanism over the wire to >> the >> >> >> > server. >> >> >> > > Is >> >> >> > > > > that >> >> >> > > > > > >> correct? The exchange is slightly different in the KIP >> >> (the PR >> >> >> > > > > matches the >> >> >> > > > > > >> KIP) from the one you described to enable >> interoperability >> >> >> with >> >> >> > > > > 0.9.0.0. >> >> >> > > > > > >> >> >> >> > > > > > >> >> >> >> > > > > > >> On Wed, Feb 3, 2016 at 1:56 PM, Harsha <m...@harsha.io> >> >> >> wrote: >> >> >> > > > > > >> >> >> >> > > > > > >>> Rajini, >> >> >> > > > > > >>> I looked at the PR you have. I think its >> better >> >> >> with >> >> >> > > > your >> >> >> > > > > > >>> earlier approach rather than extending the >> >> >> protocol. >> >> >> > > > > > >>> What I was thinking initially is, Broker has a config >> >> option >> >> >> of >> >> >> > > say >> >> >> > > > > > >>> sasl.mechanism = GSSAPI, PLAIN >> >> >> > > > > > >>> and the client can have similar config of >> >> >> sasl.mechanism=PLAIN. >> >> >> > > > > Client >> >> >> > > > > > >>> can send its sasl mechanism before the handshake starts >> >> and >> >> >> if >> >> >> > > the >> >> >> > > > > > >>> broker accepts that particular mechanism than it can go >> >> ahead >> >> >> > > with >> >> >> > > > > > >>> handshake otherwise return a error saying that the >> >> mechanism >> >> >> > not >> >> >> > > > > > >>> allowed. >> >> >> > > > > > >>> >> >> >> > > > > > >>> Thanks, >> >> >> > > > > > >>> Harsha >> >> >> > > > > > >>> >> >> >> > > > > > >>> On Wed, Feb 3, 2016, at 04:58 AM, Rajini Sivaram wrote: >> >> >> > > > > > >>> > A slightly different approach for supporting >> different >> >> SASL >> >> >> > > > > mechanisms >> >> >> > > > > > >>> > within a broker is to allow the same "*security >> >> protocol*" >> >> >> to >> >> >> > > be >> >> >> > > > > used >> >> >> > > > > > >>> on >> >> >> > > > > > >>> > different ports with different configuration >> options. An >> >> >> > > > advantage >> >> >> > > > > of >> >> >> > > > > > >>> > this >> >> >> > > > > > >>> > approach is that it extends the configurability of >> not >> >> just >> >> >> > > SASL, >> >> >> > > > > but >> >> >> > > > > > >>> any >> >> >> > > > > > >>> > protocol. For instance, it would enable the use of >> SSL >> >> with >> >> >> > > > mutual >> >> >> > > > > > >>> client >> >> >> > > > > > >>> > authentication on one port or different certificate >> >> chains >> >> >> on >> >> >> > > > > another. >> >> >> > > > > > >>> > And >> >> >> > > > > > >>> > it avoids the need for SASL mechanism negotiation. >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > Kafka would have the same "*security protocols" >> >> *defined as >> >> >> > > > today, >> >> >> > > > > but >> >> >> > > > > > >>> > with >> >> >> > > > > > >>> > (a single) configurable SASL mechanism. To have >> >> different >> >> >> > > > > > >>> configurations >> >> >> > > > > > >>> > of >> >> >> > > > > > >>> > a protocol within a broker, users can define new >> >> protocol >> >> >> > names >> >> >> > > > > which >> >> >> > > > > > >>> are >> >> >> > > > > > >>> > configured versions of existing protocols, perhaps >> using >> >> >> just >> >> >> > > > > > >>> > configuration >> >> >> > > > > > >>> > entries and no additional code. >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > For example: >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > A single mechanism broker would be configured as: >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > listeners=SASL_SSL://:9092 >> >> >> > > > > > >>> > sasl.mechanism=GSSAPI >> >> >> > > > > > >>> > sasl.kerberos.class.name=kafka >> >> >> > > > > > >>> > ... >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > And a multi-mechanism broker would be configured as: >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > listeners=gssapi://:9092,plain://:9093,custom://:9094 >> >> >> > > > > > >>> > gssapi.security.protocol=SASL_SSL >> >> >> > > > > > >>> > gssapi.sasl.mechanism=GSSAPI >> >> >> > > > > > >>> > gssapi.sasl.kerberos.class.name=kafka >> >> >> > > > > > >>> > ... >> >> >> > > > > > >>> > plain.security.protocol=SASL_SSL >> >> >> > > > > > >>> > plain.sasl.mechanism=PLAIN >> >> >> > > > > > >>> > .. >> >> >> > > > > > >>> > custom.security.protocol=SASL_PLAINTEXT >> >> >> > > > > > >>> > custom.sasl.mechanism=CUSTOM >> >> >> > > > > > >>> > >> >> >> > > custom.sasl.callback.handler.class=example.CustomCallbackHandler >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > This is still a big change because it affects the >> >> currently >> >> >> > > fixed >> >> >> > > > > > >>> > enumeration of security protocol definitions, but one >> >> that >> >> >> is >> >> >> > > > > perhaps >> >> >> > > > > > >>> > more >> >> >> > > > > > >>> > flexible than defining every new SASL mechanism as a >> new >> >> >> > > security >> >> >> > > > > > >>> > protocol. >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > Thoughts? >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > On Tue, Feb 2, 2016 at 12:20 PM, Rajini Sivaram < >> >> >> > > > > > >>> > rajinisiva...@googlemail.com> wrote: >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > > 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 >> >> >> > > > > > >>> > > >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > -- >> >> >> > > > > > >>> > Regards, >> >> >> > > > > > >>> > >> >> >> > > > > > >>> > Rajini >> >> >> > > > > > >>> >> >> >> > > > > > >> >> >> >> > > > > > >> >> >> >> > > > > > >> >> >> >> > > > > > >> -- >> >> >> > > > > > >> Regards, >> >> >> > > > > > >> >> >> >> > > > > > >> Rajini >> >> >> > > > > > >> >> >> >> > > > > > > >> >> >> > > > > > > >> >> >> > > > > > > >> >> >> > > > > > > -- >> >> >> > > > > > > Regards, >> >> >> > > > > > > >> >> >> > > > > > > Rajini >> >> >> > > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> >> > > > > > -- >> >> >> > > > > > Regards, >> >> >> > > > > > >> >> >> > > > > > Rajini >> >> >> > > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > -- >> >> >> > > > Regards, >> >> >> > > > >> >> >> > > > Rajini >> >> >> > > > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Regards, >> >> >> > >> >> >> > Rajini >> >> >> > >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Regards, >> >> > >> >> > Rajini >> >> >> > >> > >> > >> > -- >> > Regards, >> > >> > Rajini >> > > > > -- > Regards, > > Rajini
