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
>
