SSL, certificates and security with Shibboleth

Basic network connections are insecure – traffic between endpoints can be snooped or altered in transit, and neither end of a connection has any reason to believe anything about the other. Shibboleth makes extensive use of public key cryptography to address this where necessary. Doing this typically requires some software, some configuration, and one or more pairs of keys and corresponding digital certificates.

Two different approaches are used:

• data can be signed and/or encrypted, which provides a strong assurance of its integrity and where it came from and/or keeps it secure; or
• HTTP traffic can be layered over SSL (a.k.a. TLS for the purposes of this document) which protects it in transit and allows at least the client, and optionally both the client and the server, to positively identify the other end of the connection.

One thing that makes all this complicated is that public key cryptography is used for several different, independent purposes, each of which may (but need not) use a different key pair, and it's easy to get them confused. A 'Cambridge SP' perspective appears below; there is also a similar description in the Shibboleth wiki (actually about version 1 but still applicable to version 2).

Internal SP to IdP communication

In Shibboleth, IdPs and SPs exchange information either directly via network connections established for the purpose or via messages passed through the user's browser using HTTP redirects. In the former case an SSL protected connection is used with both ends of the connection using their keys to authenticate to the other; in the latter case the sender provides a signature made with its private key which can be verified by the receiver using the sender's certificate.

The software needed to do all this is included with the Internet2 Shibboleth implementation and configured in the shibboleth2.xml file.

In each case, SPs and IdPs need to be able to verify the certificate offered by the other. Certificates signed by 'Global' CAs can be used for this purpose and these are required by some federations (including the UK federation [1]). An alternative is to use 'self signed' certificates and to include each entity's certificate in its metadata (which is needed for other reasons). This is the currently preferred approach and supported by the Ucam federation. The standard install creates a key and self-signed certificate (in the same directory as shibboleth2.xml) called sp-key.pem and sp-cert.pem and configures shibboleth2.xml to use them.

The Raven IdP's certificate is included in the federation metadata (UK or Ucam federations) that the SP is configured to download automatically. The SPs certificate is included the metadata it provides on registration. It is (mainly) the lack of a SP certificate that forces IdPs to describe an unregistered SP as an 'Unknown Service Provider' when asking people for permission to release information to it.

SP to browser communication

Shibboleth does not actually require that communication between the user's browser and the SP be secured, though it is recommended. However if it isn't then both initial authentication and subsequent session management are vulnerable to interception and misuse by third parties. With increasing use of unsecured wireless networks (such as Lapwing and similar) much HTTP traffic is literally being broadcast for anyone to intercept. A particular problem is the resulting lack of security on the cookie used to manage sessions:

"We strongly recommend use of SSL across all of a web site because Shibboleth sessions are ultimately based on HTTP cookies. Stealing cookies is much easier if they travel in the clear. The strongest authentication technology in the world is reduced to a simple cookie. This is all you've got left. Consider why you're bothering to install Shibboleth at all before going further" [2]

Support for this SSL protection must be provided by your web server and is independent of Shibboleth. Configuration, which will be part of normal web server set up, is outside the scope of this document.

Your server will require a private key and corresponding certificate. To avoid worrying warning messages from user's browsers this certificate must be issued by a CA that the browser trusts and in practice this means one of a small number of commercial CAs. Self-signed certificates are not suitable for this purpose, except perhaps as part of very limited testing. In Cambridge, appropriate certificates can be obtained from the Computing Service.

The UK federation requires that at least the special URLs used internally by the SP software (the so-called 'protocol endpoints', typically with URL paths starting /Shibboleth.sso/...) be SSL protected and this therefore makes SSL support mandatory for such SPs. On them it is usual to use the same private key and certificate for this purpose as is used to protect SP to IdP communication.

The Ucam federation does not require SSL support, but strongly recommends it. As well as the inevitable insecurity, not using SSL will result in a warning message each time a user is redirected from Raven back to the SP-protected site.

What is important is to ensure that use of http: or https: urls is consistent with the URLs registered in the SPs metadata. Getting this wrong will lead to 'Invalid assertion consumer service URL' errors when authenticating (see SP Metadata).

Sites that support SSL may want to add the

 redirectToSSL="443"

request mapper property to relevant <RequestMap>, <Host>, <HostRegex>, <Path>, <PathRegex> or <Query> elements within the <RequestMapper> element to automatically force any attempt to access the site over HTTP to the corresponding requests over HTTPS. Note that you can't add this property to the <RequestMapper> itself - adding it doesn't cause an error but it doesn't work either. Alternatively, such sites might want to use the equivalent ShibRedirectToSSL Apache directive or other web server or web application facility). Sites that do this can, and probably should, add

 cookieProps="; path=/; secure"

to the relevant <Sessions> element in shibboleth2.xml to ensure that the session cookie is not exposed over unsecured connections. Note however that setting 'cookieProps' like this without also redirecting all traffic to HTTPS can cause authentication attempts to loop between the SP and the IdP (see "Looping between SP and IdP after setting cookieProps" in Shibboleth FAQs).

Validating metadata

The integrity of metadata files is crucial to the correct operation of Shibboleth services, not least because they carry certificate information on which the security of the system depends. Some, though not all, federations distribute their metadata with a digital signature. This is of no use unless it is actually verified, and doing this requires a copy of a certificate corresponding to the federation key used to create the signature. Federation documentation will explain how to obtain copies of a suitable certificate and how to verify it. For the UK federation, see [3].