Shibboleth Developers

[Walter Hoehn <>]

There are a couple of historical reasons for our previous  
recommendations that folks front-end tomcat with apache.

1) Efficiency.  Load testing indicated that apache had a MUCH higher  
saturation point when handling SSL.  I have not tested this for a  
couple of releases of the JVM and this information could be stale.   
It would be nice to know.

2) It used to be the case with apache 1.x that one could run the SSO  
and AA endpoints on a single vhost and use SSL re-negotiation to  
force the client authentication for the AA path alone.  This meant  
that all shibboleth endpoints could be run on the standard ports.   
Apache 2 does not support this configuration.

3)  Logging.  IMO apache does a better job.  For many, this may not  
be enough of a reason to go through the pain of setting up mod_jk.  ;-)

So, all of our historical reasons may be a wash, but there is a new  
twist.  The 1.3 IdP validates SSL clients against the SAML2 metadata  
and it is advantageous to be able to configure the web-server to not  
do the validation.  I'm not %100 sure(I haven't dug into this code in  
a long time), but I don't think that tomcat can do this.  Aside from  
the extra pkix validation required, the fallout is that  
configurations using tomcat would probably need have a process for  
taking the union of all anchors from the metadata and stuffing them  
into tomcat's trust store.

-Walter


On Jun 2, 2005, at 9:19 AM, Jim Fox wrote:

> > 3) Because of the change noted in the previous point, we believe  
> > it should be possible to use the new IdP WITHOUT apache, and using  
> > just Tomcat. We have not had the time to investigate this.  
> > However,if someone does identify how to do this, please post a  
> > description.
>
> We have setup tomcat-only IdPs using both 1.2 and 1.3.  The apache
> front-end is, as far as I know, to allow site webiso integration
> and crypto efficiency. I wasn't aware that it was ever an actual
> requirement.