Could we support separate SASL mechanisms via separate ports? This was the main reason we separated the ports in first place, to avoid adding protocol negotiation protocol and allow the server to expect the correct packets when they arrive to the correct listener. It will be nice if new additions could use existing design and code.
On Sun, Jan 31, 2016 at 6:48 AM, Rajini Sivaram < rajinisiva...@googlemail.com> wrote: > Harsha/Gwen, > > Thank you both for reviewing the KIP. SASL mechanism negotiation was added > specifically to support multiple SASL mechanisms within a broker. This was > brought up at the last KIP meeting and the consensus was that it would be > useful to support this. It would become harder to add multiple mechanism > support later on after support for other mechanisms are added in this KIP. > > I may have misunderstood Harsha's suggestion. This would use a > configuration option to specify one mechanism on the client-side and (one > or more?) mechanisms on the server-side. The server still needs to know the > mechanism that the client is using if it supports multiple mechanisms. And > this requires a message from the client to the server to send the mechanism > to the server. Since 0.9.0.0 servers expect to see GSSAPI tokens as soon as > the connection is established, the additional exchange is required to > ensure interoperability with 0.9.0.0. Since an exchange is necessary > anyway, sending the server mechanisms to the client seemed to make sense. > The current GSSAPI->GSSAPI flow remains exactly as it is now and is not > impacted by this KIP. Please let me know if I have missed something. > > The PR for Kafka-3149 (https://github.com/apache/kafka/pull/812) contains > the changes described in this KIP. It doesn't have tests for the new > features, just the code changes to help with the review. > > > > On Sun, Jan 31, 2016 at 12:11 AM, Gwen Shapira <g...@confluent.io> wrote: > > > I want to second Harsha's approach. Configuration is usually much easier > to > > configure and troubleshoot than protocol-negotiation-protocols, which > we've > > been doing our best to generally avoid in Kafka due to operational > > complexity. > > > > Gwen > > > > On Sat, Jan 30, 2016 at 3:32 AM, Harsha <ka...@harsha.io> wrote: > > > > > Rajini, > > > Whats the need for server returning acceptable mechs as > > > network package. Why not drive it through the JAAS file > > > itself. I don't see handshake any different than what it is > > > now and only login will change and it can be configured based > > > on the JAAS file. > > > > > > -Harsha > > > > > > On Fri, Jan 29, 2016, at 02:34 AM, Rajini Sivaram wrote: > > > > Ismael, > > > > > > > > The first packet from the client is deliberately empty to distinguish > > > > between non-negotiating GSSAPI packet and a negotiation packet. If > this > > > > packet contained mechanisms, then the code in the broker to > distinguish > > > > this from a GSSAPI packet would be a bit messy. I was thinking that > the > > > > client needs to wait for server response anyway before it can select > > > > a mechanism and start the actual SASL auth process. And once the > > > > client gets the server response, it would send the selected mechanism > > > > followed immediately by the first packet of the SASL auth. So perhaps > > the > > > > overhead is not that bad. Did you have a different flow in mind? > > > > > > > > On Fri, Jan 29, 2016 at 10:12 AM, Ismael Juma <ism...@juma.me.uk> > > wrote: > > > > > > > > > Thanks Rajini. One question: would it make sense for the client to > > > > > optimistically suggest its preferred SASL mechanism (or maybe > > > mechanisms) > > > > > to avoid a roundtrip? > > > > > > > > > > Ismael > > > > > > > > > > On Fri, Jan 29, 2016 at 10:04 AM, Rajini Sivaram < > > > > > rajinisiva...@googlemail.com> wrote: > > > > > > > > > > > Following on from the KIP meeting on Tuesday, I have updated the > > KIP > > > > > with a > > > > > > flow for negotiation of mechanisms to support multiple SASL > > > mechanisms > > > > > > within a broker. I have also added a configurable Login interface > > to > > > > > > support custom mechanisms which require ticket refresh - > requested > > > by Tao > > > > > > Xiao. > > > > > > > > > > > > I will work on updating the PR in KAFKA-3149 over the next few > days > > > since > > > > > > it will be useful for review. > > > > > > > > > > > > All comments and suggestions are welcome. > > > > > > > > > > > > > > > > > > On Thu, Jan 28, 2016 at 2:35 PM, tao xiao <xiaotao...@gmail.com> > > > wrote: > > > > > > > > > > > > > Sounds like a good approach to add provider in login module. > > Would > > > love > > > > > > to > > > > > > > see updates in the PR to reflect the changes in Login and > > > > > > > AuthCallbackHandler. > > > > > > > > > > > > > > On Thu, 28 Jan 2016 at 19:31 Rajini Sivaram < > > > > > > rajinisiva...@googlemail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Tao, > > > > > > > > > > > > > > > > We currently add the security provider in a static > initializer > > > in our > > > > > > > login > > > > > > > > module. This ensures that the security provider is always > > > installed > > > > > > > before > > > > > > > > Kafka creates SaslServer/SaslClient. As you say, it is also > > > possible > > > > > to > > > > > > > > insert code into your application to add security provider > > before > > > > > Kafka > > > > > > > > clients are created. Since you can also configure the JDK to > > add > > > new > > > > > > > > security providers, I am not sure if there is value in adding > > > more > > > > > > > > configuration in Kafka to add security providers. > > > > > > > > > > > > > > > > On Thu, Jan 28, 2016 at 2:25 AM, tao xiao < > > xiaotao...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > The callback works for me as long as it has access to > Subject > > > and > > > > > > > mechs. > > > > > > > > > The other thing is how we can inject the customized > security > > > > > provider > > > > > > > via > > > > > > > > > Security.addProvider()? If I want to implement my own SASL > > > mech I > > > > > > need > > > > > > > to > > > > > > > > > call the addProvider() before SASL.create so that my own > > > > > > implementation > > > > > > > > of > > > > > > > > > SASLClient/Sever can be returned. Any thoughts on this? we > > can > > > > > either > > > > > > > let > > > > > > > > > users inject the provider in their logic code before > > creating a > > > > > > > > > producer/consumer or Kafka does it for users > > > > > > > > > > > > > > > > > > On Thu, 28 Jan 2016 at 03:36 Rajini Sivaram < > > > > > > > > rajinisiva...@googlemail.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Tao, > > > > > > > > > > > > > > > > > > > > *javax.security.auth.callback.**CallbackHandler *is the > > > standard > > > > > > way > > > > > > > in > > > > > > > > > > which SASL clients and server obtain additional mechanism > > > > > specific > > > > > > > > > > input. *AuthCallbackHandler > > > > > > > > > > *simply extends this interface to propagate configuration > > > > > > > properties. I > > > > > > > > > was > > > > > > > > > > going to provide SASL mechanism and Subject to the > callback > > > > > > handlers > > > > > > > as > > > > > > > > > > well since the default handlers use these. > > > > > > > > > > > > > > > > > > > > Your SaslServer/SaslClient implementation can obtain the > > > Subject > > > > > > > using > > > > > > > > > > *Subject.getSubject(**AccessController.getContext(). *But > > it > > > will > > > > > > be > > > > > > > > good > > > > > > > > > > to know if callback handlers would work for you - apart > > from > > > > > > standard > > > > > > > > > > callbacks like PasswordCallback, you can define your own > > > > > callbacks > > > > > > > too > > > > > > > > if > > > > > > > > > > you require. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 27, 2016 at 3:59 PM, tao xiao < > > > xiaotao...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Thanks Rajini. The other thing in my mind is that we > > should > > > > > find > > > > > > a > > > > > > > > way > > > > > > > > > to > > > > > > > > > > > expose subject to SASL so that other mechanisms are > able > > > to use > > > > > > the > > > > > > > > > > > principal and credentials stored in subject to do > > > > > authentication. > > > > > > > > > > > > > > > > > > > > > > I am thinking to have below interface that can be > > extended > > > by > > > > > > users > > > > > > > > to > > > > > > > > > > > build the SASL client/server instead of having an > > > AuthCallback. > > > > > > > With > > > > > > > > > this > > > > > > > > > > > interface users are able to add their own security > > provider > > > > > > before > > > > > > > > > > > client/server is returned by SASL. Any thoughts? > > > > > > > > > > > > > > > > > > > > > > Interface SaslClientBuilder { > > > > > > > > > > > > > > > > > > > > > > SaslClient build(mechs, subject, host, otherparams) > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > Interface SaslServerBuilder { > > > > > > > > > > > SaslServer build(mechs, subject, host, otherparams) > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > On Wed, 27 Jan 2016 at 18:54 Rajini Sivaram < > > > > > > > > > > rajinisiva...@googlemail.com> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Tao, > > > > > > > > > > > > > > > > > > > > > > > > Thank you for the explanation. I couldn't find a > > standard > > > > > Java > > > > > > > > > > interface > > > > > > > > > > > > that would be suitable, so will define one based on > > your > > > > > > > > requirement > > > > > > > > > > and > > > > > > > > > > > > update the KIP. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > Rajini > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 27, 2016 at 2:12 AM, tao xiao < > > > > > > xiaotao...@gmail.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rajini, > > > > > > > > > > > > > > > > > > > > > > > > > > One requirement I have is to refresh the login > token > > > every > > > > > X > > > > > > > > hours. > > > > > > > > > > > Like > > > > > > > > > > > > > what the Kerberos login does I need to have a > > > background > > > > > > thread > > > > > > > > > that > > > > > > > > > > > > > refreshes the token periodically. > > > > > > > > > > > > > > > > > > > > > > > > > > I understand most of the login logic would be > simple > > > but it > > > > > > is > > > > > > > > good > > > > > > > > > > > that > > > > > > > > > > > > we > > > > > > > > > > > > > can expose the logic login to users and let them > > decide > > > > > what > > > > > > > they > > > > > > > > > > want > > > > > > > > > > > to > > > > > > > > > > > > > do. And we can have a fallback login component that > > is > > > used > > > > > > if > > > > > > > > > users > > > > > > > > > > > dont > > > > > > > > > > > > > specify it. > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 26 Jan 2016 at 20:07 Rajini Sivaram < > > > > > > > > > > > > rajinisiva...@googlemail.com> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tao, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you for the review. The changes I had in > mind > > > are > > > > > in > > > > > > > the > > > > > > > > PR > > > > > > > > > > > > > > https://github.com/apache/kafka/pull/812. Login > > for > > > > > > > > non-Kerberos > > > > > > > > > > > > > protocols > > > > > > > > > > > > > > contains very little logic. I was expecting that > > > combined > > > > > > > with > > > > > > > > a > > > > > > > > > > > custom > > > > > > > > > > > > > > login module specified in JAAS configuration, > this > > > would > > > > > > give > > > > > > > > > > > > sufficient > > > > > > > > > > > > > > flexibility. Is there a specific usecase you have > > in > > > mind > > > > > > > where > > > > > > > > > you > > > > > > > > > > > > need > > > > > > > > > > > > > to > > > > > > > > > > > > > > customize the Login code? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rajini > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 26, 2016 at 11:15 AM, tao xiao < > > > > > > > > xiaotao...@gmail.com > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rajini, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it makes sense to change LoginManager > or > > > Login > > > > > to > > > > > > > an > > > > > > > > > > > > interface > > > > > > > > > > > > > > > which users can extend to provide their own > logic > > > of > > > > > > login > > > > > > > > > > > otherwise > > > > > > > > > > > > it > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > hard for users to implement a custom SASL > > > mechanism but > > > > > > > have > > > > > > > > no > > > > > > > > > > > > control > > > > > > > > > > > > > > > over login > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 26 Jan 2016 at 18:45 Ismael Juma < > > > > > > > ism...@juma.me.uk> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Rajini, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the KIP. As stated in the KIP, it > > > does not > > > > > > > > address > > > > > > > > > > > > > "Support > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > multiple SASL mechanisms within a broker". > > Maybe > > > we > > > > > > > should > > > > > > > > > also > > > > > > > > > > > > > mention > > > > > > > > > > > > > > > > this in the "Rejected Alternatives" section > > with > > > the > > > > > > > > > > reasoning. I > > > > > > > > > > > > > think > > > > > > > > > > > > > > > > it's particularly relevant to understand if > > it's > > > not > > > > > > > being > > > > > > > > > > > proposed > > > > > > > > > > > > > > > because > > > > > > > > > > > > > > > > we don't think it's useful or due to the > > > additional > > > > > > > > > > > implementation > > > > > > > > > > > > > > > > complexity (it's probably a combination). If > we > > > think > > > > > > > this > > > > > > > > > > could > > > > > > > > > > > be > > > > > > > > > > > > > > > useful > > > > > > > > > > > > > > > > in the future, it would also be worth > thinking > > > about > > > > > > how > > > > > > > it > > > > > > > > > is > > > > > > > > > > > > > affected > > > > > > > > > > > > > > > if > > > > > > > > > > > > > > > > we do KIP-43 first (ie will it be easier, > > harder, > > > > > etc.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Ismael > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 25, 2016 at 9:55 PM, Rajini > > Sivaram < > > > > > > > > > > > > > > > > rajinisiva...@googlemail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have just created KIP-43 to extend the > SASL > > > > > > > > > implementation > > > > > > > > > > in > > > > > > > > > > > > > Kafka > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > support new SASL mechanisms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-43%3A+Kafka+SASL+enhancements > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Comments and suggestions are appreciated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rajini > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Rajini > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Regards, > > > > > > > > > > > > > > > > Rajini > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > > > > > > > Rajini > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > > > > > Rajini > > > > > > > > > -- > Regards, > > Rajini >
