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 >>>> >>> >>> >> >
