IdP on Tomcat w/o Apache HTTPD

Rough outline of how to run a Shibboleth IdentityProvider in a stand-alone Tomcat:

Using the Apache Portable Runtime (APR)

See http://tomcat.apache.org/tomcat-5.5-doc/apr.html for information about "Apache Portable Runtime and Tomcat".
This setup roughly means that you will be using Tomcat as a Java Servlet Container with OS-native HTTP connectors based on OpenSSL. This greatly enhances (networking) performance. It should also solve the concerns about using Tomcat standalone with the standard Coyote HTTP connectors based on JSSE since the APR connectors support the setting SSLVerifyClient="optionalNoCA" .
Note that you cannot use the JKS format for any keystore when using the APR since it uses OpenSSL (it is possible to convert from JKS using extkeytool).

• You'll usually need two SSL connectors defined in server.xml , one on port 443 for browser/SSO/authentication and one on port 8443 for SOAP.
• The SOAP connector has to be configured for client certificate authentication. If you don't want the OpenSSL part of the connector to check the offered certificate set SSLVerifyClient to optionalNoCA (highly recommended for Shib v1.3; doesn't work for lower versions). Else you should set SSLVerifyClient to optional or require and a keystore file has to be created containing every possible trust anchor that you will ever encounter when evaluating a ServiceProvider.

Using Tomcat default (so no APR or "native libraries" are installed for Tomcat)

You will be using the default Coyote HTTP connectors that provide SSL based on Java's JSSE.

• You'll usually need two SSL connectors defined in server.xml , one on port 443 for browser/SSO/authentication and one on port 8443 for SOAP.
• The SOAP connector has to be configured for client certificate authentication, usually optional, by setting clientAuth to want .
• A keystore file also has to be created containing every possible trust anchor that you will ever encounter when evaluating a ServiceProvider certificate (trusted CA certificates). The -manageable- truststore of the JVM is used for that purpose if you don't specify one (normally $JRE_HOME/lib/security/cacerts). If you're using self-signed certificates in MetaData, these certificates are themselves trust anchors and must be imported. This file is referenced by the truststoreFile option in the connector. See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html for more on the options available.
• Authentication has to be performed using a method of your choice in front of the SSO handler to ensure that a username is passed to the IdP servlet.

It's the third bullet that creates a problem in some cases. If you can identify the set of CertificateAuthorities that apply to your deployment, and it is a manageable set, then this is reasonable to set up. But if you expect to deal with self-signed certificates that you authorize with MetaData, this option will quickly get annoying to manage, until somebody creates a tool to extract certificates from a MetaData file and create a keystore, at least.

Also note that any time that the contents of the keystore with all the possible trust anchors changes, Tomcat must be restarted.