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.
- Certificate acceptance policy
- How to replace an old certificate for Identity Providers (certificate rollover)
- How to replace an old certificate for Service Providers (certificate rollover)
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 connection normally is only needed when the old SAML 1 protocol is used. The connection is the only connection where the user's web browser is not involved.
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 both authenticate themselves to the other party. The Identity Providers identity is checked validating the web server's X.509 certificate via TLS. The Service Provider either uses X.509 client authentication via TLS or it signs the attribute request with its X.509 private key.
Certificates are validated by Shibboleth using federation metadata. The configuration of Apache or Tomcat at the Identity Provider should disable certificate validation and outsource it entirely to Shibboleth.
The SP's and IdP's certificate must both meet the FEDURUS certificate requirements.