X509 Authn in IDPv3

[Pradeep Jamble]

Hi Scott,

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.
Just sharing some info in case someone else stumbles across the same issue:

Does not work: Apache is 2.4.7 (mod_jk) -> Tomcat 7.0.52 -> Shib IdP v3.2.0
Works: Apache is 2.4.7 (mod_jk) -> Tomcat 8.0.33 -> Shib IdP v3.2.0

Regards,
Pradeep

On Wed, Apr 6, 2016 at 9:36 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 4/6/16, 12:22 PM, "users on behalf of Mike Wiseman" <
> users-bounces at shibboleth.net on behalf of mike.wiseman at utoronto.ca> wrote:
>
>
> >
> >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.
>
> 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.
>
> >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.
>
> That isn't typical. Most people use the regular browser port for this and
> that's certainly how it was assumed to be used.
>
> >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.
>
> 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.
>
> 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.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160427/26093785/attachment-0001.html>