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