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
>
