X509 Authn in IDPv3

[Cantor, Scott]

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