<div dir="ltr"><div><div><div>Hi Scott,<br><br>I forgot to send an update but the issue was fixed after upgrading tomcat to v8; x509 authn works like a charm. Thanks for the support and guidance. <br>Just sharing some info in case someone else stumbles across the same issue:<br><br>Does not work: Apache is 2.4.7 (mod_jk) -> Tomcat 7.0.52 -> Shib IdP v3.2.0<br></div>Works: Apache is 2.4.7 (mod_jk) -> Tomcat 8.0.33 -> Shib IdP v3.2.0<br><br></div>Regards,<br></div>Pradeep<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 9:36 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4/6/16, 12:22 PM, "users on behalf of Mike Wiseman" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:mike.wiseman@utoronto.ca">mike.wiseman@utoronto.ca</a>> wrote:<br>
<br>
<br>
><br>
>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.<br>
<br>
</span>It's not a security issue. AJP is a pure tunnelling mechanism to forward a request intact, and it preserves the data required to populate Java request attributes by design, and HTTP proxying doesn't.<br>
<span class=""><br>
>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.<br>
<br>
</span>That isn't typical. Most people use the regular browser port for this and that's certainly how it was assumed to be used.<br>
<span class=""><br>
>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.<br>
<br>
</span>It has to do with the idea that the trust store of the *server* bears any relationship to the certificates one might be expecting a client to present, or that you can even assume anything about those certificates to begin with. They may not even be signed by a CA, so the idea that you can tell the client what certificate to present based on a list of issues is silly.<br>
<br>
There's just an inherent bias in these implementations toward the X.509 PKI model, and not a well-thought out set of biases at that.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>