Certificates Overview
In order to sign or encrypt messages, Shibboleth uses common X.509 certificates as they are used for SSL-enabled web servers. On the other hand there are often also certificates used for the web server.
This page gives an overview about all the involved certificates, their requirements and what they are used for.
| Quick Links |
|
|
The image above shows all relevant connections when a user wants to access a Resource. The connection to the WAYF server is not shown because it is not directly related to Shibboleth and is skipped in some cases.
- 1. Resource Request
- This HTTP connection is between the user's web browser and the web server of the Resource. To protect the Resource and its session handling properly, https should be used. Otherwise, Shibboleth protected authentication is an overkill.
Requirements for web server certificate: Web browser access to the web server shall be protected by https. For that, the web server should use a 'pop-up-free' certificate from a well-known CA.
The certificate is validated by the user's web browser, which contains a list of pre-installed root CA certificates for validation. - 2. Authentication Request
- The HTTP connection is between the user's web browser and the web server of the Home Organization. To protect the users credentials properly and to enable the user to identify the server, https must be used.
Requirements for web server certificate: Web browser access to the web server must be protected by https. It is recommended to use an Extended Validation certificate (EV-SSL), or at least a 'pop-up-free' certificate from a well-known CA.
The certificate is validated by the user's web browser, which contains a list of pre-installed root CA certificates for validation. - 3. Attribute Request
- This is the only connection where the user's web browser is not involved. The attribute request generally only takes place when SAML1 is used, which implies that either Service or Identity Provider uses Shibboleth 1.x.
The Shibboleth Service Provider opens a SOAP connection to the Shibboleth Identity Provider to retrieve the user's attributes. The Identity Provider as well as the Service Provider must provide their certificate to the other party (the Service Provider is doing client authentication).
Requirements for Shibboleth certificates: It must be one of the accepted certificates for the corresponding federation. Self-signed certificates that are not issued by a well-known CA are allowed as well but require a special approval procedure for enhanced security.
Certificates are validated by Shibboleth using federation metadata. The configuration of Apache or Tomcat at the Identity Provider should disable client authentication and thus outsource certificate validation entirely to Shibboleth.
How exactly the attribute request in 3 is done in an Apache/IIS + mod_jk + Tomcat or a Tomcat-only setup for a certificate that is not embedded in metadata, can be seen on the following graphics.
Click on image to see a large version