X509 Authn in IDPv3
cantor.2 at osu.edu
Wed Apr 6 12:36:12 EDT 2016
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.
More information about the users