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 <ism...@juma.me.uk> 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 <ism...@juma.me.uk> 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 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 > > > > > > > > > > > > > > >
