Sorry, just ignore previous email. I saw the newly defined interface of the
callback in the KIP which has considered this matter.
On Fri, 29 Jan 2016 at 18:08 tao xiao <xiaotao...@gmail.com> wrote:
> 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
>>
>
