Shibboleth Developers

[Chad La Joie <>]

Okay, so after looking at this issue I'm proposing the following approach.

1. We create a server socket factory that produces sockets that does not
do the client cert path validation, and instead just accepts it (the
container will put the cert in the right place).  This is the JSSE
blessed way of doing this.

2. For non-Tomcat systems we document for people how to configure the
JVM to use this socket factory when creating sockets to handle HTTPS
connections.  This entails either putting one line in one file, or
having the IdP set the appropriate property at startup.  This has the
draw back of vastly weakening (essentially nullifying) the security
gotten via client-cert auth, and we'll document this extensively with
500pt red blinky text.  The upshot is that hardly any apps out there use
client-cert auth.

3. For Tomcat systems we create a custom connector the extends the
current HTTPS connector and provide a switch for turning cert path
validation on and off.  If it's turned off we use our custom socket
factory, if it's turned on we use the normal one.  This has the benefit
of limiting the scope of this change, but it does have it's drawbacks
too.  First, it's obviously Tomcat specific (not a big deal since I
think literally everyone deploys Shib in Tomcat currently).  Second, and
more importantly, is that because connectors are not tied to a
particular host or context definition in the Tomcat server config this
connector would apply to all apps deployed in Tomcat.  Again, probably
not a big deal since most apps don't use client-cert auth, and if they
do want to they can just define another connector, but we should
document this too.

Does this sound like a reasonable approach?

Chad La Joie wrote:
> I was doing some more thinking about certificate validation in Tomcat on
> my way home today, and I had some more questions.
> 
> During the Shib call today we said that the current 1.3 Apache/Tomcat
> set up takes a client cert and basically passes it to the IdP and the
> IdP now does all the trust verification (unless I misunderstood
> something).  And we said that this would be the preferred operation in a
> Tomcat only environment so that people didn't have to mess with trust
> stores.  And currently, without messing with the trust store (copying
> the certs from the metadata file into the trust store) a request will
> fail, if it's using client-cert auth.
> 
> Here's my question though, if we just pass the client-cert auth
> employing request on, with the SSL info in the appropriate headers, for
> the IdP to verify are we weakening the security that people expect from
> the client-cert authentication?  Also, are the headers that we're
> placing this data in defined in a standard (HTTPS standard perhaps)?
> 
> All that said, I think, from my initial look at the Tomcat code, it
> should be relatively easy now to change the JSSE socket used for
> handling the SSL connection, which means it should be easy to make
> Tomcat do what we want it to.
> 
> My only concern with all this is portability to other containers.

-- 
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124