Ismael, I took a closer look at SslTransportLayer and did verify everything will work for me. SSLSession is already exposed through a public method on SslTransportLayer through the sslSession() method so that is perfect as I can access what I need with that. Mostly I just need the X509 chain out of the SSLSession for my purposes. So I went ahead and closed out the JIRA and moved my KIP to the discarded section now that I verified it will work.
Thanks again for the help. Chris On Fri, Feb 24, 2017 at 1:54 PM, Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > 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 >> > > > > >> > > > >> > > >> > >> >
