Hi Rajini,
Do you consider exposing Subject to AuthCallback as well? It is useful for
users building their own SASL mechanism so that we have control where to
put logon data in subject and how to manipulate in SASL callback
On Fri, 29 Jan 2016 at 18:04 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
>
