X509 Authn in IDPv3

Mike Wiseman mike.wiseman at utoronto.ca
Wed Apr 6 12:22:47 EDT 2016

> >Yes, I'm leaning towards using 'Tomcat-only' for idp operation mainly for this purpose -
>> handling TLS client authentication which is our principal MFA method. I could use Jetty but
>> am not comfortable/experienced with using it for client auth handling. I also tried
>> httpd/mod_ssl over HTTPS (instead of AJP) to Jetty - had trouble with that.
> You can't do it with HTTP proxying, that would literally mean TLS was broken if you could.

OK, it's been a while since I tried that. Conceptually though, I wouldn't rely on the security functionality of the protocol between httpd and the servlet container ie . AJP is no more secure than HTTP for that purpose. Of course, there is other mandatory configuration needed to secure this - host/port firewalling, running on the same host only, etc.        
> I have examples lying around of using client TLS on the front-channel with Jetty, but it was
> brutally confusing. I have no idea whether Tomcat is easier to do it with, I suspect it's just as
> bad but you happen to know what it looks like.
> The biggest problem they all have is that the implementations and configurations are
> designed by people that understand certificates and PKI about as well as I understand
> particle physics, so it's just....bad. The trust assumptions they make are just embarassingly
> broken.

I don't run client TLS client authn on the /idp handling front channel - not sure what you mean by that. I run it on a back-channel connection dedicated to the X509 handler. 

> But none of this has anything to do with the OP's problem, that's a "that Tomcat is flat
> broken" issue.

I'd be interested to know more about this, for obvious reasons :-) If you are referring to the default set of root certs that the JVM comes with, yes that is a configuration consideration.  


More information about the users mailing list