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.


Certificates_Overview.png

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. IdP <-> SP communication
Direct SAML communication between the IdP and SP can happen in two scenarios as documented below.
Requirements for the IdP and SP certificates:
Both must meet the SWITCHaai requirements for SAML2 metadata embedded certificates.
  • Scenario Authentication Response
    After successful authentication, the IdP answers with a SAML response to the SP's Authenticaiton Request. The IdP signs this response with the key from its IdP certificate.
    In SAML2, the response usually contains an encrypted SAML assertion with the user's attribute values. The IdP encrypts this assertion using the SP's public key from the SP's certificate, so that only the SP is able to decrypt the user's attribue values.
    The IdP posts this response via the users web browser back to the SP.
  • Scenario Backchannel Attribute Request
    This scenario was mostly used in SAML version 1 where the IdP couldn't include an encrypted attribute assertion as explained above. In SAML version 2 the back-channel attribute request is important in the context of a SWITCHtoolbox service that requests attributes from the SWITCHtoolbox server or in SWITCH edu-ID to request affiliation related user attributes from an attribute provider. This communiaction 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.