Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Christopher Shannon]

Ismael,

I took a closer look at SslTransportLayer and did verify everything will
work for me. SSLSession is already exposed through a public method on
SslTransportLayer through the sslSession() method so that is perfect as I
can access what I need with that.  Mostly I just need the X509 chain out of
the SSLSession for my purposes.  So I went ahead and closed out the JIRA
and moved my KIP to the discarded section now that I verified it will work.

Thanks again for the help.

Chris

On Fri, Feb 24, 2017 at 1:54 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Sounds good, thanks for the feedback. I will move my KIP to the discarded
> section for now as the PrincipalBuilder should be sufficient.  If for some
> reason it is not I can revisit this.
>
> Chris
>
> On Fri, Feb 24, 2017 at 1:37 PM Ismael Juma  wrote:
>
>> Hi Christopher,
>>
>> It is possible to retrieve the certificates already. The Principal
>> returned
>> by TransportLayer.peerPrincipal() is a X500Principal if TLS is being used.
>> We could add a method to make things nicer, potentially, but just wanted
>> you to know that it's possible today.
>>
>> I am in favour of keeping it simple, if possible. :)
>>
>> As Rajini said, KIP-103 means users have a way to set the config on a per
>> listener basis, so it makes sense to allow users to have both SSL client
>> authentication and SASL authentication enabled at the same time if they
>> wish. As long as the default remains that SSL client auth is disabled for
>> SASL_SSL (which I believe is the common case), seems fine to me.
>>
>> Ismael
>>
>> On Fri, Feb 24, 2017 at 6:18 PM, Christopher Shannon <
>> christopher.l.shan...@gmail.com> wrote:
>>
>> > Rajini, If the override can be dropped for SASL_SSL then I have no
>> problem
>> > with doing this as SASL_SSL External (basically just TLS
>> authentication).
>> > If the configurable callback handlers KIP passes then that would effect
>> > this and one of the callback handlers could be an X509 callback handler.
>> >
>> > Ismael, For why the PrincipalBuilder is not good enough...a custom
>> > PrincipalBuilder would work (would just need to expose the peer
>> > certificates through a new getter but that is simple).  The main reason
>> why
>> > I suggested using JAAS is that is the standard way of plugging in
>> > authentication.  In terms of dual authentication, yes I could have one
>> > listener as SSL and one as SASL.  Or I could just use SASL_SSL and
>> > configure two login modules.
>> >
>> > After thinking about it more maybe the simplest approach would be to
>> just
>> > use a custom PrincipalBuilder along with a small PR to expose the peer
>> > certificates from the SSL handshake.  One thing I didn't like about
>> using a
>> > JAAS module for SSL is that then it is a bit weird because someone might
>> > configure a PrincipalBuilder for returning the Principal but usually
>> that
>> > is the JAAS modules jobs.  So perhaps we should keep it simple and just
>> > rely on the existing PrincinpalBuilder interface so things don't get
>> > confusing.  Thoughts? Would I just close/reject the KIP if I decide to
>> go
>> > this route?
>> >
>> > As a side note, I think it would be a good idea to create a Jira and PR
>> > either way to get rid of the override for ssl.client.auth on SASL_SSL
>> as it
>> > would be good to let the user configure that regardless (i can do the
>> > jira/pr)
>> >
>> > On Fri, Feb 24, 2017 at 9:47 AM, Ismael Juma  wrote:
>> >
>> > > Hi Christopher,
>> > >
>> > > Thanks for the KIP. I have two comments:
>> > >
>> > > 1. Can you please explain in the KIP (maybe in the Rejected
>> Alternatives
>> > > section) why a PrincipalBuilder is not good enough for your use case?
>> > This
>> > > is typically what people use to customise authentication for the TLS
>> > case.
>> > >
>> > > 2. You mention that you have a use case where you need dual
>> > authentication
>> > > (username/password and certificate based). Could you not achieve this
>> via
>> > > two separate listeners? username/password could be via a listener
>> > > configured to use SASL and certificate-based could be via a listener
>> > > configured to use TLS.
>> > >
>> > > Ismael
>> > >
>> > > On Tue, Feb 21, 2017 at 8:23 PM, Christopher Shannon <
>> > > christopher.l.shan...@gmail.com> wrote:
>> > >
>> > > > Thanks for the feedback Harsha.
>> > > >
>> > > > Can you clarify what you mean for the use cases for SASL_SSL and
>> X509?
>> > > My
>> > > > proposal is to only have X509 based pluggable authentication for the
>> > SSL
>> > > > channel and not SASL_SSL.  I suppose you could use X509 credentials
>> > with
>> > > > SASL_SSL but the authentication mode would probably need to be SASL
>> > > > EXTERNAL as the authentication is done by the SSL channel where as
>> with
>> > > > Kerberos or PLAINTEXT the user is providing credentials.  That's
>> why I
>> > > > proposed adding it to the SSL channel instead of SASL_SSL.
>> > > >

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Christopher Shannon]

Sounds good, thanks for the feedback. I will move my KIP to the discarded
section for now as the PrincipalBuilder should be sufficient.  If for some
reason it is not I can revisit this.

Chris

On Fri, Feb 24, 2017 at 1:37 PM Ismael Juma  wrote:

> Hi Christopher,
>
> It is possible to retrieve the certificates already. The Principal returned
> by TransportLayer.peerPrincipal() is a X500Principal if TLS is being used.
> We could add a method to make things nicer, potentially, but just wanted
> you to know that it's possible today.
>
> I am in favour of keeping it simple, if possible. :)
>
> As Rajini said, KIP-103 means users have a way to set the config on a per
> listener basis, so it makes sense to allow users to have both SSL client
> authentication and SASL authentication enabled at the same time if they
> wish. As long as the default remains that SSL client auth is disabled for
> SASL_SSL (which I believe is the common case), seems fine to me.
>
> Ismael
>
> On Fri, Feb 24, 2017 at 6:18 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Rajini, If the override can be dropped for SASL_SSL then I have no
> problem
> > with doing this as SASL_SSL External (basically just TLS authentication).
> > If the configurable callback handlers KIP passes then that would effect
> > this and one of the callback handlers could be an X509 callback handler.
> >
> > Ismael, For why the PrincipalBuilder is not good enough...a custom
> > PrincipalBuilder would work (would just need to expose the peer
> > certificates through a new getter but that is simple).  The main reason
> why
> > I suggested using JAAS is that is the standard way of plugging in
> > authentication.  In terms of dual authentication, yes I could have one
> > listener as SSL and one as SASL.  Or I could just use SASL_SSL and
> > configure two login modules.
> >
> > After thinking about it more maybe the simplest approach would be to just
> > use a custom PrincipalBuilder along with a small PR to expose the peer
> > certificates from the SSL handshake.  One thing I didn't like about
> using a
> > JAAS module for SSL is that then it is a bit weird because someone might
> > configure a PrincipalBuilder for returning the Principal but usually that
> > is the JAAS modules jobs.  So perhaps we should keep it simple and just
> > rely on the existing PrincinpalBuilder interface so things don't get
> > confusing.  Thoughts? Would I just close/reject the KIP if I decide to go
> > this route?
> >
> > As a side note, I think it would be a good idea to create a Jira and PR
> > either way to get rid of the override for ssl.client.auth on SASL_SSL as
> it
> > would be good to let the user configure that regardless (i can do the
> > jira/pr)
> >
> > On Fri, Feb 24, 2017 at 9:47 AM, Ismael Juma  wrote:
> >
> > > Hi Christopher,
> > >
> > > Thanks for the KIP. I have two comments:
> > >
> > > 1. Can you please explain in the KIP (maybe in the Rejected
> Alternatives
> > > section) why a PrincipalBuilder is not good enough for your use case?
> > This
> > > is typically what people use to customise authentication for the TLS
> > case.
> > >
> > > 2. You mention that you have a use case where you need dual
> > authentication
> > > (username/password and certificate based). Could you not achieve this
> via
> > > two separate listeners? username/password could be via a listener
> > > configured to use SASL and certificate-based could be via a listener
> > > configured to use TLS.
> > >
> > > Ismael
> > >
> > > On Tue, Feb 21, 2017 at 8:23 PM, Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > >
> > > > Thanks for the feedback Harsha.
> > > >
> > > > Can you clarify what you mean for the use cases for SASL_SSL and
> X509?
> > > My
> > > > proposal is to only have X509 based pluggable authentication for the
> > SSL
> > > > channel and not SASL_SSL.  I suppose you could use X509 credentials
> > with
> > > > SASL_SSL but the authentication mode would probably need to be SASL
> > > > EXTERNAL as the authentication is done by the SSL channel where as
> with
> > > > Kerberos or PLAINTEXT the user is providing credentials.  That's why
> I
> > > > proposed adding it to the SSL channel instead of SASL_SSL.
> > > >
> > > > That being said I guess one option would be to just allow the use of
> a
> > > X509
> > > > callback handler and don't disable client auth when using SASL_SSL.
> > Then
> > > > after login have some way to signal it's EXTERNAL mode so it doesn't
> do
> > > any
> > > > other authentication steps.
> > > >
> > > > I have a use case where I need dual authentication (both
> > > username/password
> > > > and certificate based) and ether one would work as multiple
> > LoginModules
> > > > can be chained together.
> > > >
> > > > Chris
> > > >
> > > > On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani <
> ka...@harsha.io>
> > > > wrote:
> > > >
> > > > > Hi Chris,
> > > > >   Thanks 

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Ismael Juma]

Hi Christopher,

It is possible to retrieve the certificates already. The Principal returned
by TransportLayer.peerPrincipal() is a X500Principal if TLS is being used.
We could add a method to make things nicer, potentially, but just wanted
you to know that it's possible today.

I am in favour of keeping it simple, if possible. :)

As Rajini said, KIP-103 means users have a way to set the config on a per
listener basis, so it makes sense to allow users to have both SSL client
authentication and SASL authentication enabled at the same time if they
wish. As long as the default remains that SSL client auth is disabled for
SASL_SSL (which I believe is the common case), seems fine to me.

Ismael

On Fri, Feb 24, 2017 at 6:18 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Rajini, If the override can be dropped for SASL_SSL then I have no problem
> with doing this as SASL_SSL External (basically just TLS authentication).
> If the configurable callback handlers KIP passes then that would effect
> this and one of the callback handlers could be an X509 callback handler.
>
> Ismael, For why the PrincipalBuilder is not good enough...a custom
> PrincipalBuilder would work (would just need to expose the peer
> certificates through a new getter but that is simple).  The main reason why
> I suggested using JAAS is that is the standard way of plugging in
> authentication.  In terms of dual authentication, yes I could have one
> listener as SSL and one as SASL.  Or I could just use SASL_SSL and
> configure two login modules.
>
> After thinking about it more maybe the simplest approach would be to just
> use a custom PrincipalBuilder along with a small PR to expose the peer
> certificates from the SSL handshake.  One thing I didn't like about using a
> JAAS module for SSL is that then it is a bit weird because someone might
> configure a PrincipalBuilder for returning the Principal but usually that
> is the JAAS modules jobs.  So perhaps we should keep it simple and just
> rely on the existing PrincinpalBuilder interface so things don't get
> confusing.  Thoughts? Would I just close/reject the KIP if I decide to go
> this route?
>
> As a side note, I think it would be a good idea to create a Jira and PR
> either way to get rid of the override for ssl.client.auth on SASL_SSL as it
> would be good to let the user configure that regardless (i can do the
> jira/pr)
>
> On Fri, Feb 24, 2017 at 9:47 AM, Ismael Juma  wrote:
>
> > Hi Christopher,
> >
> > Thanks for the KIP. I have two comments:
> >
> > 1. Can you please explain in the KIP (maybe in the Rejected Alternatives
> > section) why a PrincipalBuilder is not good enough for your use case?
> This
> > is typically what people use to customise authentication for the TLS
> case.
> >
> > 2. You mention that you have a use case where you need dual
> authentication
> > (username/password and certificate based). Could you not achieve this via
> > two separate listeners? username/password could be via a listener
> > configured to use SASL and certificate-based could be via a listener
> > configured to use TLS.
> >
> > Ismael
> >
> > On Tue, Feb 21, 2017 at 8:23 PM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > > Thanks for the feedback Harsha.
> > >
> > > Can you clarify what you mean for the use cases for SASL_SSL and X509?
> > My
> > > proposal is to only have X509 based pluggable authentication for the
> SSL
> > > channel and not SASL_SSL.  I suppose you could use X509 credentials
> with
> > > SASL_SSL but the authentication mode would probably need to be SASL
> > > EXTERNAL as the authentication is done by the SSL channel where as with
> > > Kerberos or PLAINTEXT the user is providing credentials.  That's why I
> > > proposed adding it to the SSL channel instead of SASL_SSL.
> > >
> > > That being said I guess one option would be to just allow the use of a
> > X509
> > > callback handler and don't disable client auth when using SASL_SSL.
> Then
> > > after login have some way to signal it's EXTERNAL mode so it doesn't do
> > any
> > > other authentication steps.
> > >
> > > I have a use case where I need dual authentication (both
> > username/password
> > > and certificate based) and ether one would work as multiple
> LoginModules
> > > can be chained together.
> > >
> > > Chris
> > >
> > > On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
> > > wrote:
> > >
> > > > Hi Chris,
> > > >   Thanks for the KIP. Could you also add details/use-cases
> for
> > > > having X509 certificate based authentication in the context SASL_SSL.
> > > > The reason that we disabled the SSL auth for SASL_SSL is the intent
> > > behind
> > > > using SASL auth over SSL encryption and user  can enforce a
> > > > role based auth and have wire encryption for data transfer. If users
> > just
> > > > want SSL based authentication they have option to do so via SSL.
> > > > I think we are providing too many options 

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Christopher Shannon]

Rajini, If the override can be dropped for SASL_SSL then I have no problem
with doing this as SASL_SSL External (basically just TLS authentication).
If the configurable callback handlers KIP passes then that would effect
this and one of the callback handlers could be an X509 callback handler.

Ismael, For why the PrincipalBuilder is not good enough...a custom
PrincipalBuilder would work (would just need to expose the peer
certificates through a new getter but that is simple).  The main reason why
I suggested using JAAS is that is the standard way of plugging in
authentication.  In terms of dual authentication, yes I could have one
listener as SSL and one as SASL.  Or I could just use SASL_SSL and
configure two login modules.

After thinking about it more maybe the simplest approach would be to just
use a custom PrincipalBuilder along with a small PR to expose the peer
certificates from the SSL handshake.  One thing I didn't like about using a
JAAS module for SSL is that then it is a bit weird because someone might
configure a PrincipalBuilder for returning the Principal but usually that
is the JAAS modules jobs.  So perhaps we should keep it simple and just
rely on the existing PrincinpalBuilder interface so things don't get
confusing.  Thoughts? Would I just close/reject the KIP if I decide to go
this route?

As a side note, I think it would be a good idea to create a Jira and PR
either way to get rid of the override for ssl.client.auth on SASL_SSL as it
would be good to let the user configure that regardless (i can do the
jira/pr)

On Fri, Feb 24, 2017 at 9:47 AM, Ismael Juma  wrote:

> Hi Christopher,
>
> Thanks for the KIP. I have two comments:
>
> 1. Can you please explain in the KIP (maybe in the Rejected Alternatives
> section) why a PrincipalBuilder is not good enough for your use case? This
> is typically what people use to customise authentication for the TLS case.
>
> 2. You mention that you have a use case where you need dual authentication
> (username/password and certificate based). Could you not achieve this via
> two separate listeners? username/password could be via a listener
> configured to use SASL and certificate-based could be via a listener
> configured to use TLS.
>
> Ismael
>
> On Tue, Feb 21, 2017 at 8:23 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > Thanks for the feedback Harsha.
> >
> > Can you clarify what you mean for the use cases for SASL_SSL and X509?
> My
> > proposal is to only have X509 based pluggable authentication for the SSL
> > channel and not SASL_SSL.  I suppose you could use X509 credentials with
> > SASL_SSL but the authentication mode would probably need to be SASL
> > EXTERNAL as the authentication is done by the SSL channel where as with
> > Kerberos or PLAINTEXT the user is providing credentials.  That's why I
> > proposed adding it to the SSL channel instead of SASL_SSL.
> >
> > That being said I guess one option would be to just allow the use of a
> X509
> > callback handler and don't disable client auth when using SASL_SSL.  Then
> > after login have some way to signal it's EXTERNAL mode so it doesn't do
> any
> > other authentication steps.
> >
> > I have a use case where I need dual authentication (both
> username/password
> > and certificate based) and ether one would work as multiple LoginModules
> > can be chained together.
> >
> > Chris
> >
> > On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
> > wrote:
> >
> > > Hi Chris,
> > >   Thanks for the KIP. Could you also add details/use-cases for
> > > having X509 certificate based authentication in the context SASL_SSL.
> > > The reason that we disabled the SSL auth for SASL_SSL is the intent
> > behind
> > > using SASL auth over SSL encryption and user  can enforce a
> > > role based auth and have wire encryption for data transfer. If users
> just
> > > want SSL based authentication they have option to do so via SSL.
> > > I think we are providing too many options of authentication in SASL_SSL
> > > mode and can be bit confusing.
> > >
> > > Thanks,
> > > Harsha
> > >
> > >
> > > On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
> > > christopher.l.shan...@gmail.com> wrote:
> > >
> > > Hi everyone
> > >
> > > I have just created KIP-127 to introduce custom JAAS configuration for
> > the
> > > SSL channel:
> > >
> > > *
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > 127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
> > > <
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > > 127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
> > > >*
> > >
> > > The idea here is to be able to do custom authentication based off of a
> > > user's X509 credentials in addition to the SSL handshake.
> > >
> > > I have created a rough draft of a commit to give an idea of what my
> plan
> > is
> > > which matches the KIP:
> > > https://github.com/cshannon/kafka/tree/KAFKA-4784
> > >
> > > It still 

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Ismael Juma]

Hi Christopher,

Thanks for the KIP. I have two comments:

1. Can you please explain in the KIP (maybe in the Rejected Alternatives
section) why a PrincipalBuilder is not good enough for your use case? This
is typically what people use to customise authentication for the TLS case.

2. You mention that you have a use case where you need dual authentication
(username/password and certificate based). Could you not achieve this via
two separate listeners? username/password could be via a listener
configured to use SASL and certificate-based could be via a listener
configured to use TLS.

Ismael

On Tue, Feb 21, 2017 at 8:23 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Thanks for the feedback Harsha.
>
> Can you clarify what you mean for the use cases for SASL_SSL and X509?  My
> proposal is to only have X509 based pluggable authentication for the SSL
> channel and not SASL_SSL.  I suppose you could use X509 credentials with
> SASL_SSL but the authentication mode would probably need to be SASL
> EXTERNAL as the authentication is done by the SSL channel where as with
> Kerberos or PLAINTEXT the user is providing credentials.  That's why I
> proposed adding it to the SSL channel instead of SASL_SSL.
>
> That being said I guess one option would be to just allow the use of a X509
> callback handler and don't disable client auth when using SASL_SSL.  Then
> after login have some way to signal it's EXTERNAL mode so it doesn't do any
> other authentication steps.
>
> I have a use case where I need dual authentication (both username/password
> and certificate based) and ether one would work as multiple LoginModules
> can be chained together.
>
> Chris
>
> On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
> wrote:
>
> > Hi Chris,
> >   Thanks for the KIP. Could you also add details/use-cases for
> > having X509 certificate based authentication in the context SASL_SSL.
> > The reason that we disabled the SSL auth for SASL_SSL is the intent
> behind
> > using SASL auth over SSL encryption and user  can enforce a
> > role based auth and have wire encryption for data transfer. If users just
> > want SSL based authentication they have option to do so via SSL.
> > I think we are providing too many options of authentication in SASL_SSL
> > mode and can be bit confusing.
> >
> > Thanks,
> > Harsha
> >
> >
> > On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> > Hi everyone
> >
> > I have just created KIP-127 to introduce custom JAAS configuration for
> the
> > SSL channel:
> >
> > *
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
> > <
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
> > >*
> >
> > The idea here is to be able to do custom authentication based off of a
> > user's X509 credentials in addition to the SSL handshake.
> >
> > I have created a rough draft of a commit to give an idea of what my plan
> is
> > which matches the KIP:
> > https://github.com/cshannon/kafka/tree/KAFKA-4784
> >
> > It still needs some work (needs more tests for example) but I wanted to
> get
> > some feedback before I went any farther on this and do a pull request.
> >
> > Thanks,
> > Chris
> >
>

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Rajini Sivaram]

Christopher,

1. We currently disable ssl.client.auth for SASL_SSL. This was done at a
time when a broker that had two listeners SSL and SASL_SSL using
ssl.client.auth=required for SSL and ssl.client.auth=none for SASL_SSL had
no way of specifying two different values for the property. With the
changes under KIP-103, this is no longer a limitation. So we can stop
overriding ssl.client.auth for SASL_SSL.

2. Now you want to do custom authentication for SSL with access to the
client certificates. I think you should consider doing this as a SASL
mechanism - EXTERNAL makes sense as you suggested. Perhaps you would need
changes to login code, but it may be possible to work with just custom
callbacks. KIP-86 (
https://cwiki.apache.org/confluence/display/KAFKA/KIP-86%3A+Configurable+SASL+callback+handlers)
might help, though this has not yet gone through the approval process. It
may need some changes for your specific use case.


On Fri, Feb 24, 2017 at 11:32 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Does anyone else have any comments or suggestions on this?
>
> On Tue, Feb 21, 2017 at 4:05 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > I should mention another reason I went with adding this enhancement to
> the
> > SSL channel instead of SASL_SSL is that as you can see from my sample
> > commit, I had to delay the JAAS LoginManager from getting loaded until
> the
> > authenticate() call in SslServerAuthenticator in order to make sure that
> > the SSL handshake was done because loading the LoginManager does the
> actual
> > login() call and requires the X509 callback handler.
> >
> > The SASL_SSL implementation loads the LoginManager during the configure
> in
> > SaslChannelBuilder which is too early as the X509 credentials won't be
> > available yet without the handshake being completed so this would require
> > some refactoring to get to this to work properly and load at the right
> time.
> >
> > On Tue, Feb 21, 2017 at 3:44 PM, Christopher Shannon <
> > christopher.l.shan...@gmail.com> wrote:
> >
> >> As a follow up to my previous post, EXTERNAL could be added to the list
> >> of mechanisms supported with the existing property:
> sasl.enabled.mechanisms
> >> so I think this could also be achieved with SASL_SSL.  If EXTERNAL is
> used
> >> then it would not disable the client certificate from being required.
> >>
> >> So I can go either way on this, I can update my KIP to allow X509
> >> authentication with SASL_SSL through the EXTERNAL mechanism or keep the
> >> proposal as is for the SSL channel based on what everyone thinks.
> >>
> >> On Tue, Feb 21, 2017 at 3:23 PM, Christopher Shannon <
> >> christopher.l.shan...@gmail.com> wrote:
> >>
> >>> Thanks for the feedback Harsha.
> >>>
> >>> Can you clarify what you mean for the use cases for SASL_SSL and X509?
> >>> My proposal is to only have X509 based pluggable authentication for
> the SSL
> >>> channel and not SASL_SSL.  I suppose you could use X509 credentials
> with
> >>> SASL_SSL but the authentication mode would probably need to be SASL
> >>> EXTERNAL as the authentication is done by the SSL channel where as with
> >>> Kerberos or PLAINTEXT the user is providing credentials.  That's why I
> >>> proposed adding it to the SSL channel instead of SASL_SSL.
> >>>
> >>> That being said I guess one option would be to just allow the use of a
> >>> X509 callback handler and don't disable client auth when using
> SASL_SSL.
> >>> Then after login have some way to signal it's EXTERNAL mode so it
> doesn't
> >>> do any other authentication steps.
> >>>
> >>> I have a use case where I need dual authentication (both
> >>> username/password and certificate based) and ether one would work as
> >>> multiple LoginModules can be chained together.
> >>>
> >>> Chris
> >>>
> >>> On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
> >>> wrote:
> >>>
>  Hi Chris,
>    Thanks for the KIP. Could you also add details/use-cases for
>  having X509 certificate based authentication in the context SASL_SSL.
>  The reason that we disabled the SSL auth for SASL_SSL is the intent
>  behind
>  using SASL auth over SSL encryption and user  can enforce a
>  role based auth and have wire encryption for data transfer. If users
>  just
>  want SSL based authentication they have option to do so via SSL.
>  I think we are providing too many options of authentication in
> SASL_SSL
>  mode and can be bit confusing.
> 
>  Thanks,
>  Harsha
> 
> 
>  On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
>  christopher.l.shan...@gmail.com> wrote:
> 
>  Hi everyone
> 
>  I have just created KIP-127 to introduce custom JAAS configuration for
>  the
>  SSL channel:
> 
>  *
>  https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%3A
>  +Pluggable+JAAS+LoginModule+configuration+for+SSL
>  <
>  

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Christopher Shannon]

Does anyone else have any comments or suggestions on this?

On Tue, Feb 21, 2017 at 4:05 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I should mention another reason I went with adding this enhancement to the
> SSL channel instead of SASL_SSL is that as you can see from my sample
> commit, I had to delay the JAAS LoginManager from getting loaded until the
> authenticate() call in SslServerAuthenticator in order to make sure that
> the SSL handshake was done because loading the LoginManager does the actual
> login() call and requires the X509 callback handler.
>
> The SASL_SSL implementation loads the LoginManager during the configure in
> SaslChannelBuilder which is too early as the X509 credentials won't be
> available yet without the handshake being completed so this would require
> some refactoring to get to this to work properly and load at the right time.
>
> On Tue, Feb 21, 2017 at 3:44 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
>> As a follow up to my previous post, EXTERNAL could be added to the list
>> of mechanisms supported with the existing property: sasl.enabled.mechanisms
>> so I think this could also be achieved with SASL_SSL.  If EXTERNAL is used
>> then it would not disable the client certificate from being required.
>>
>> So I can go either way on this, I can update my KIP to allow X509
>> authentication with SASL_SSL through the EXTERNAL mechanism or keep the
>> proposal as is for the SSL channel based on what everyone thinks.
>>
>> On Tue, Feb 21, 2017 at 3:23 PM, Christopher Shannon <
>> christopher.l.shan...@gmail.com> wrote:
>>
>>> Thanks for the feedback Harsha.
>>>
>>> Can you clarify what you mean for the use cases for SASL_SSL and X509?
>>> My proposal is to only have X509 based pluggable authentication for the SSL
>>> channel and not SASL_SSL.  I suppose you could use X509 credentials with
>>> SASL_SSL but the authentication mode would probably need to be SASL
>>> EXTERNAL as the authentication is done by the SSL channel where as with
>>> Kerberos or PLAINTEXT the user is providing credentials.  That's why I
>>> proposed adding it to the SSL channel instead of SASL_SSL.
>>>
>>> That being said I guess one option would be to just allow the use of a
>>> X509 callback handler and don't disable client auth when using SASL_SSL.
>>> Then after login have some way to signal it's EXTERNAL mode so it doesn't
>>> do any other authentication steps.
>>>
>>> I have a use case where I need dual authentication (both
>>> username/password and certificate based) and ether one would work as
>>> multiple LoginModules can be chained together.
>>>
>>> Chris
>>>
>>> On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
>>> wrote:
>>>
 Hi Chris,
   Thanks for the KIP. Could you also add details/use-cases for
 having X509 certificate based authentication in the context SASL_SSL.
 The reason that we disabled the SSL auth for SASL_SSL is the intent
 behind
 using SASL auth over SSL encryption and user  can enforce a
 role based auth and have wire encryption for data transfer. If users
 just
 want SSL based authentication they have option to do so via SSL.
 I think we are providing too many options of authentication in SASL_SSL
 mode and can be bit confusing.

 Thanks,
 Harsha


 On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
 christopher.l.shan...@gmail.com> wrote:

 Hi everyone

 I have just created KIP-127 to introduce custom JAAS configuration for
 the
 SSL channel:

 *
 https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%3A
 +Pluggable+JAAS+LoginModule+configuration+for+SSL
 <
 https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%3A
 +Pluggable+JAAS+LoginModule+configuration+for+SSL
 >*

 The idea here is to be able to do custom authentication based off of a
 user's X509 credentials in addition to the SSL handshake.

 I have created a rough draft of a commit to give an idea of what my
 plan is
 which matches the KIP:
 https://github.com/cshannon/kafka/tree/KAFKA-4784

 It still needs some work (needs more tests for example) but I wanted to
 get
 some feedback before I went any farther on this and do a pull request.

 Thanks,
 Chris

>>>
>>>
>>
>

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Christopher Shannon]

I should mention another reason I went with adding this enhancement to the
SSL channel instead of SASL_SSL is that as you can see from my sample
commit, I had to delay the JAAS LoginManager from getting loaded until the
authenticate() call in SslServerAuthenticator in order to make sure that
the SSL handshake was done because loading the LoginManager does the actual
login() call and requires the X509 callback handler.

The SASL_SSL implementation loads the LoginManager during the configure in
SaslChannelBuilder which is too early as the X509 credentials won't be
available yet without the handshake being completed so this would require
some refactoring to get to this to work properly and load at the right time.

On Tue, Feb 21, 2017 at 3:44 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> As a follow up to my previous post, EXTERNAL could be added to the list of
> mechanisms supported with the existing property: sasl.enabled.mechanisms
> so I think this could also be achieved with SASL_SSL.  If EXTERNAL is used
> then it would not disable the client certificate from being required.
>
> So I can go either way on this, I can update my KIP to allow X509
> authentication with SASL_SSL through the EXTERNAL mechanism or keep the
> proposal as is for the SSL channel based on what everyone thinks.
>
> On Tue, Feb 21, 2017 at 3:23 PM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
>> Thanks for the feedback Harsha.
>>
>> Can you clarify what you mean for the use cases for SASL_SSL and X509?
>> My proposal is to only have X509 based pluggable authentication for the SSL
>> channel and not SASL_SSL.  I suppose you could use X509 credentials with
>> SASL_SSL but the authentication mode would probably need to be SASL
>> EXTERNAL as the authentication is done by the SSL channel where as with
>> Kerberos or PLAINTEXT the user is providing credentials.  That's why I
>> proposed adding it to the SSL channel instead of SASL_SSL.
>>
>> That being said I guess one option would be to just allow the use of a
>> X509 callback handler and don't disable client auth when using SASL_SSL.
>> Then after login have some way to signal it's EXTERNAL mode so it doesn't
>> do any other authentication steps.
>>
>> I have a use case where I need dual authentication (both
>> username/password and certificate based) and ether one would work as
>> multiple LoginModules can be chained together.
>>
>> Chris
>>
>> On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
>> wrote:
>>
>>> Hi Chris,
>>>   Thanks for the KIP. Could you also add details/use-cases for
>>> having X509 certificate based authentication in the context SASL_SSL.
>>> The reason that we disabled the SSL auth for SASL_SSL is the intent
>>> behind
>>> using SASL auth over SSL encryption and user  can enforce a
>>> role based auth and have wire encryption for data transfer. If users just
>>> want SSL based authentication they have option to do so via SSL.
>>> I think we are providing too many options of authentication in SASL_SSL
>>> mode and can be bit confusing.
>>>
>>> Thanks,
>>> Harsha
>>>
>>>
>>> On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
>>> christopher.l.shan...@gmail.com> wrote:
>>>
>>> Hi everyone
>>>
>>> I have just created KIP-127 to introduce custom JAAS configuration for
>>> the
>>> SSL channel:
>>>
>>> *
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%3A
>>> +Pluggable+JAAS+LoginModule+configuration+for+SSL
>>> <
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%3A
>>> +Pluggable+JAAS+LoginModule+configuration+for+SSL
>>> >*
>>>
>>> The idea here is to be able to do custom authentication based off of a
>>> user's X509 credentials in addition to the SSL handshake.
>>>
>>> I have created a rough draft of a commit to give an idea of what my plan
>>> is
>>> which matches the KIP:
>>> https://github.com/cshannon/kafka/tree/KAFKA-4784
>>>
>>> It still needs some work (needs more tests for example) but I wanted to
>>> get
>>> some feedback before I went any farther on this and do a pull request.
>>>
>>> Thanks,
>>> Chris
>>>
>>
>>
>

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Christopher Shannon]

As a follow up to my previous post, EXTERNAL could be added to the list of
mechanisms supported with the existing property: sasl.enabled.mechanisms so
I think this could also be achieved with SASL_SSL.  If EXTERNAL is used
then it would not disable the client certificate from being required.

So I can go either way on this, I can update my KIP to allow X509
authentication with SASL_SSL through the EXTERNAL mechanism or keep the
proposal as is for the SSL channel based on what everyone thinks.

On Tue, Feb 21, 2017 at 3:23 PM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> Thanks for the feedback Harsha.
>
> Can you clarify what you mean for the use cases for SASL_SSL and X509?  My
> proposal is to only have X509 based pluggable authentication for the SSL
> channel and not SASL_SSL.  I suppose you could use X509 credentials with
> SASL_SSL but the authentication mode would probably need to be SASL
> EXTERNAL as the authentication is done by the SSL channel where as with
> Kerberos or PLAINTEXT the user is providing credentials.  That's why I
> proposed adding it to the SSL channel instead of SASL_SSL.
>
> That being said I guess one option would be to just allow the use of a
> X509 callback handler and don't disable client auth when using SASL_SSL.
> Then after login have some way to signal it's EXTERNAL mode so it doesn't
> do any other authentication steps.
>
> I have a use case where I need dual authentication (both username/password
> and certificate based) and ether one would work as multiple LoginModules
> can be chained together.
>
> Chris
>
> On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
> wrote:
>
>> Hi Chris,
>>   Thanks for the KIP. Could you also add details/use-cases for
>> having X509 certificate based authentication in the context SASL_SSL.
>> The reason that we disabled the SSL auth for SASL_SSL is the intent behind
>> using SASL auth over SSL encryption and user  can enforce a
>> role based auth and have wire encryption for data transfer. If users just
>> want SSL based authentication they have option to do so via SSL.
>> I think we are providing too many options of authentication in SASL_SSL
>> mode and can be bit confusing.
>>
>> Thanks,
>> Harsha
>>
>>
>> On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
>> christopher.l.shan...@gmail.com> wrote:
>>
>> Hi everyone
>>
>> I have just created KIP-127 to introduce custom JAAS configuration for the
>> SSL channel:
>>
>> *
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%
>> 3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
>> <
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%
>> 3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
>> >*
>>
>> The idea here is to be able to do custom authentication based off of a
>> user's X509 credentials in addition to the SSL handshake.
>>
>> I have created a rough draft of a commit to give an idea of what my plan
>> is
>> which matches the KIP:
>> https://github.com/cshannon/kafka/tree/KAFKA-4784
>>
>> It still needs some work (needs more tests for example) but I wanted to
>> get
>> some feedback before I went any farther on this and do a pull request.
>>
>> Thanks,
>> Chris
>>
>
>

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Christopher Shannon]

Thanks for the feedback Harsha.

Can you clarify what you mean for the use cases for SASL_SSL and X509?  My
proposal is to only have X509 based pluggable authentication for the SSL
channel and not SASL_SSL.  I suppose you could use X509 credentials with
SASL_SSL but the authentication mode would probably need to be SASL
EXTERNAL as the authentication is done by the SSL channel where as with
Kerberos or PLAINTEXT the user is providing credentials.  That's why I
proposed adding it to the SSL channel instead of SASL_SSL.

That being said I guess one option would be to just allow the use of a X509
callback handler and don't disable client auth when using SASL_SSL.  Then
after login have some way to signal it's EXTERNAL mode so it doesn't do any
other authentication steps.

I have a use case where I need dual authentication (both username/password
and certificate based) and ether one would work as multiple LoginModules
can be chained together.

Chris

On Tue, Feb 21, 2017 at 3:06 PM, Harsha Chintalapani 
wrote:

> Hi Chris,
>   Thanks for the KIP. Could you also add details/use-cases for
> having X509 certificate based authentication in the context SASL_SSL.
> The reason that we disabled the SSL auth for SASL_SSL is the intent behind
> using SASL auth over SSL encryption and user  can enforce a
> role based auth and have wire encryption for data transfer. If users just
> want SSL based authentication they have option to do so via SSL.
> I think we are providing too many options of authentication in SASL_SSL
> mode and can be bit confusing.
>
> Thanks,
> Harsha
>
>
> On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> Hi everyone
>
> I have just created KIP-127 to introduce custom JAAS configuration for the
> SSL channel:
>
> *
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
> <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
> >*
>
> The idea here is to be able to do custom authentication based off of a
> user's X509 credentials in addition to the SSL handshake.
>
> I have created a rough draft of a commit to give an idea of what my plan is
> which matches the KIP:
> https://github.com/cshannon/kafka/tree/KAFKA-4784
>
> It still needs some work (needs more tests for example) but I wanted to get
> some feedback before I went any farther on this and do a pull request.
>
> Thanks,
> Chris
>

Re: [DISCUSS] KIP-127: Pluggable JAAS LoginModule configuration for SSL

[Harsha Chintalapani]

Hi Chris,
  Thanks for the KIP. Could you also add details/use-cases for
having X509 certificate based authentication in the context SASL_SSL.
The reason that we disabled the SSL auth for SASL_SSL is the intent behind
using SASL auth over SSL encryption and user  can enforce a
role based auth and have wire encryption for data transfer. If users just
want SSL based authentication they have option to do so via SSL.
I think we are providing too many options of authentication in SASL_SSL
mode and can be bit confusing.

Thanks,
Harsha


On Tue, Feb 21, 2017 at 11:23 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

Hi everyone

I have just created KIP-127 to introduce custom JAAS configuration for the
SSL channel:

*
https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
<
https://cwiki.apache.org/confluence/display/KAFKA/KIP-127%3A+Pluggable+JAAS+LoginModule+configuration+for+SSL
>*

The idea here is to be able to do custom authentication based off of a
user's X509 credentials in addition to the SSL handshake.

I have created a rough draft of a commit to give an idea of what my plan is
which matches the KIP:
https://github.com/cshannon/kafka/tree/KAFKA-4784

It still needs some work (needs more tests for example) but I wanted to get
some feedback before I went any farther on this and do a pull request.

Thanks,
Chris