Shibboleth Developers

["Howard Gilbert" <>]

You should be able to do this for Tomcat by overriding the default
SSLContext object (a static property of the SSLContext class). It is JSSE
built into the Java Runtime that you need to override. Create an SSLContext
with an additional TrustManager in the array of TrustManagers that accepts
all client Certificates.

The SP does this in order to validate the AA Server Certificate in the
Metadata even though it is not in the CACerts. However, the SP can set this
up on a session by session basis, while playing the Server side of the same
trick requires changing behavior statically for the entire JVM. As long as
you don't run a second application in the same Tomcat that (and now it gets
really strange) opens its own SSLServerSocket separate from anything Tomcat
is doing, then this change to the JVM behavior will simply appear as Tomcat
doing what you want.

As has been noted, since the Client Cert is presented in the API, it can be
validated against the Metadata there. So the TrustManager in the IdP doesn't
need to do Trust itself (unlike the SP code), it can simply return and
approve all Client Certificates.

> -----Original Message-----
> > But as you said, mucking with the container is non-portable.  Could
> > you write a filter that sits in front of the IdP and does the same
> > thing to the request that apache is doing now (whatever that is)?
> 
> Nope, because it's the container doing the "bad" thing, namely trying to
> validate the certificate against it's trust store.  Since the trust
> store doesn't have the cert chain(s) in them (they're in the metadata)
> this will fail.