Stop, before proceeding please read this page about Tomcat support for Client Certificate Authentication. |
Rough outline of how to run a Shibboleth IdentityProvider in a stand-alone Tomcat:
This section should be ignored for the time being, as it does not work due to this bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=37869</strong> |
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).
server.xml
, one on port 443 for browser/SSO/authentication and one on port 8443 for SOAP.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.You will be using the default Coyote HTTP connectors that provide SSL based on Java's JSSE.
server.xml
, one on port 443 for browser/SSO/authentication and one on port 8443 for SOAP.clientAuth
to want
.$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.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.