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
>
