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