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