...

The IdP also makes use of cryptography in ways that you'll need to understand in at least a rudimentary way because the security of everything you do with the IdP depends upon it.

Java Container Considerations

...

By default, most Java containers are provided with some kind of HTTP connector/listener on ports 8080 and 8443. This is because non-Windows operating systems restrict processes from binding to ports under 1024 unless they run as root. Some newer systems have more advanced policy control over this.

...

Using Apache as the web server is possible, though discouraged, with two conditions:

• You typically want to be using an AJP-based proxy connector to your Java container, because only AJP allows the client certificate to be passed into the Java server so the IdP can evaluate it. Failing this, you will have to ensure that any requests are made with signed messages.

• You must set the option SSLVerifyClient optional_no_ca in your back-channel virtual host configuration.

The latter works, but is subject to certain limitations that will cause problems for some SPs because even when this option is used, the Apache module still applies some restrictions on the client certificate that are not strictly required by the IdP itself. So this will limit the interoperability of your deployment.

...

There are a number of different keys and certificates used by the IdP, each for a specific purpose. Most are holdovers from earlier versions (which is noted where appropriate) but a couple of the use cases are new and therefore introduce some different scenarios to be aware of.

Your IdP Keys and Certificates

...

As always, you have to install a private key and certificate on the server to enable TLS to encrypt the traffic from clients (and nominally, but in reality just a fiction, to authenticate the server to the browser client). This is generally going to require a commercially-issued certificate rooted in a CA all browsers will trust. Make sure that you can change this key and certificate any time you care to or need to.

This is not a change from V2 or V3.

...

The main key underlying most IdPs is the digital signing key. This is a private key used to sign SAML messages.

The installer (when not upgrading an older installation) will generate a private signing key and a long-lived, self-signed certificate containing the public key. The certificate is just a convenient container for the public key. In Shibboleth, or any compliant SAML system, the content of the certificate other than the key is totally ignored.

The certificate is communicated via a <md:KeyDescriptor use="signing"> element in SAML metadata. The use XML attribute is important, as will be made clear below.

In a new install of V4 or an upgrade from V3 or laterUnless upgrading from V2, the generated signing key pair will be prefixed idp-signing (the names can be overridden if desired via the idp.properties file).

...

The older practice of using the same key for both digital signing and back-channel TLS is obviously permitted but is discouraged to limit key usage to specific purposes, which is a more secure practice. In particular, there are many more known attacks in recent years that have compromised TLS server keys than on keys used "behind the scenes".

In a new install, or upgrade of a V3+ install, Unless upgrading from V2, the generated back-channel key pair will be prefixed idp-backchannel but the files are not explicitly referenced by the IdP configuration because they are meant for use by the container to configure its back-channel TLS connector/listener.

In V2, the back-channel key pair was also not part of the configuration but conventionally was the same as the signing key pair. An upgraded install of to V3 did not generate a new key pair and was generally assumed to be reusing the existing back-channel configuration choices.

...

A third key pair, new to V3 and subsequent versions of the IdP, supports inbound XML Encryption. The private key is used to decrypt data encrypted under the public key. The latter is bound to a certificate that is communicated via a <md:KeyDescriptor use="encryption"> element in SAML metadata.There

The primary value of an encryption key to an IdP is when operating as a proxy (i.e., acting as an SP), so the key is used to decrypt encrypted Assertions issued to it.

Outside of proxying, there are only a few scenarios in which SPs are likely to need to encrypt data transmitted to the IdP and none of them are common or essential. The most likely use case would be to encrypt the subject of a SAML logout request but Shibboleth SPs (and most other implementations) don't do this by default.

...

Note that advertising a certificate in metadata with no use XML attribute is an indication that the same private key is used for both signing and decryption. After an upgrade, you may have older IdP metadata needing correction that mistakenly indicates this.

In a new install, or upgrade of a V3+ install, Unless upgrading from V2, the generated encryption key pair will be prefixed idp-encryption (the names can be overridden if desired via the idp.properties file).

In V2, this functionality did not exist and so no allowance for this existed in the configuration. An upgraded install of V3 deferred upgrade from V2 defers the timing of having such a key pair and some adjustments had would have to be made at some point later on. An upgrade using a clean install, and using the generated key pair, requires adjusting your IdP's metadata shared with every SP to reflect the use of a separate key pair for this function, as noted above. Doing this while publishing metadata containing a certificate in metadata with no use XML attribute will cause problems.

...

Some SPs may have private keys and certificates used for one or more of the following:

• Signing SAML requests (or, in a few cases such as Single Logout, SAML responses)

• Client or server authentication of back-channel SAML requests or responses (SOAP primarily)

Signing-only certificates are communicated via a <md:KeyDescriptor use="signing"> element in SP metadata. When configured in the usual fashion, the IdP will completely ignore the content of the certificate other than the public key, but in a back-channel scenario the web server may or may not ignore the certificate's content depending on the software and configuration involved (discussed above).

...

While an SP may advertise any number of encryption certificates in its metadata, the IdP will pick only one to encrypt with, and it is generally non-deterministic at times which one is used. This means an SP cannot put different keys on different servers as part of a cluster of servers (the IdP won't know which one to pick), and it complicates changing the encryption key because the SP must be able to support decrypting data with both the old and new keys at once (Shibboleth can, but not every implementation can).

Metadata Signing Keys and Certificates

A final type of key you may encounter is one used to digitally sign SAML metadata. Shibboleth differs from most SAML implementations in that it favors the use of third-party sources of metadata (informally termed "federations") to vouch for the information supplied, much like a traditional certificate authority signs certificates. The public key certificate used to verify a signed metadata file is essentially a trust anchor, like a CA root certificate.

...