The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.
WhyModJK
Many people repeatedly insist on trying to run the Shibboleth IdentityProvider, which is in Java, in a stand-alone Tomcat environment. The response to this has traditionally been, and continues to be, that this is unsupported. This topic attempts to explain the reason for this. It may be helpful to first review the KeysAndCertificates topic to understand some of the issues.
Shibboleth ServiceProviders traditionally have relied on client certificate authentication over TLS/SSL to authenticate SOAP requests they issue to IdentityProviders, and for performance reasons this will probably continue to be the dominant method even as other techniques like signing become better supported.
In order for IdentityProviders to have a high degree of control over how the client certificate is evaluated, the ideal situation is for the TLS/SSL server implementation to essentially negotiate for and accept the certificate, but otherwise ignore it and pass it to the server application (in this case Shibboleth) for further processing. This is what enables Shibboleth to support the use of self-signed certificates using MetaData, as well as PKI operations that depend on the ServiceProvider's membership in particular federations.
Unfortunately, there are no widely used web server platforms that support this approach today. Not one. PKI is fundamentally flawed because of a lack of software that provides flexibility.
As the reader can guess, the reason we only support the Apache/jk front-end is that mod_ssl comes closest to this ideal. It supports an SSLVerifyClient setting called optional_no_ca that is very close to this goal. Not exactly. It enforces some restrictions such as client chain length that must be worked around using the SSLVerifyDepth setting, when certificate chains have to be supported. But aside from this, it is largely effective at delegating the job to Shibboleth, which in turn reduces the number of strange error messages that can arise.
Why is Tomcat alone unsuitable? Well, it may not be, but it depends on a very detailed understanding of your deployment choices, and most people are simply not able to understand the issues when first installing the software. Therefore, we take the safe choice and insist that people deploy a perfectly stable and much faster web server that is available on (and often included with) just about every platform.
After reading that, if you still want to try it, read the TomcatAlone topic.