Certificates Overview

In order to sign or encrypt messages, the SAML message exchange uses key pairs with a public and private key. The public key gets configured as X.509 certificate.
This page provides 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 Discovery Service/WAYF server is not shown because it is not directly related to the SAML message exchange and gets 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 must be used. Otherwise, the SAML protected authentication would be 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 user's 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
Requirements for the IdP and SP certificates:
Both must meet the SWITCHaai Certificate Acceptance Policy.
 
The direct SAML communication between the IdP and SP uses one of these two scenarios:
  • Scenario Authentication Response
    After successful authentication, the IdP answers with a SAML response to the SP's Authentication Request. The IdP signs this response with the private key from its key pair. The SP will verify the signature using the IdP's public key from the IdP's 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 attribute values.
    The IdP posts this response via the user's web browser back to the SP.
  • Scenario Backchannel Attribute Request
    This scenario was formerly used in SAML version 1 when the IdP couldn't include an encrypted attribute assertion as explained above.
    However, in SAML version 2, the back-channel attribute request gets only used by SWITCH edu-ID to update linked affiliations for users from a Home Organization that has not yet adopted edu-ID. The edu-ID Service Provider daily requests the affiliation related user attributes from the Attribute Provider component of the Home Organization's Identity Provider. This communication is the only connection where the user's web browser is not involved.
    The SAML Service Provider opens a SOAP connection to the SAML 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 Provider's 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 the private key from its key pair.
    Certificates are validated by the SAML Identity and Service Providers using federation metadata. The configuration of Apache or Tomcat at the Identity Provider should disable certificate validation and outsource it entirely to the SAML Identity Provider software.