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