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 <ka...@harsha.io> > >>> 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 > >>>> > >>> > >>> > >> > > >
