Shibboleth Developers

["Alistair Young" <>]

May I join PKI Users Anonymous too! I'm fed up messing with Tomcat to try
to extract a client cert from an application. It's just not happening
according to the Tomcat docs.

We wanted to do essentially the same as your good selves. Tell the
container to get lost and just give the application the client cert and
the application will do the validation. Nice easy install, no trust stores
and the AA etc can decide who to trust when it gets attribute requests.

Perhaps I'm not understanding the problem enough (probably) but would it
help if the SP signed SAML Requests? Then it's client cert ends up in the
SAML request and can be extracted by the AA and validated. TLS can still
handle the wire, though it too could be binned if message-level encryption
was used.

As someone else said, client-cert auth is hardly ever used - no wonder!
Why not forget container specifics and shunt the certs up a level to the
message itself?

Java 6 is apparently going to support XML sig and encryption natively so
someone else is obviously thinking about all this too.

Alistair


-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

> 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
>