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
