...
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 decrypt the subject of a SAML logout request but Shibboleth SPs (and most other implementations) don't do encrypt this by default.
| Tip |
|---|
We strongly advise against use of non-transient NameID values in all SAML deployments in all cases to minimize or outright avoid any need for IdP decryption. SAML Attributes are a better choice for communicating information about subjects, and transient NameIDs can be used for SAML logout purposes without imposing requirements for encryption to protect the appearance of PII in web server logs. |
While it 's been was a common practice in the past for the Shibboleth SP to generate a single key pair for both signing and encryption, the IdP installer generates a separate key pair for each, again for "best practice" reasons. It is particularly advisable to separate out the encryption key pair at the IdP because it has very different security properties. Compromising a decryption key allows data to be exposed (but not forged) in relatively rare cases while compromising the other keys is fatal to the security of the entire system.
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.
Unless upgrading After upgrades 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 upgrade from V2 defers the timing of having such a key pair and some adjustments would have to be have been 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.
...
This is a secret key that should be regular updated, though this is not absolutely essential. A simple command-line tool is provided to update the keystore and version files and maintain older key versions as required.
...
Like the IdP, most SPs will operate as a secure web application by supporting TLS on port 443 for browser access. This key and certificate has no relevance to the operation of the SP or IdP. The certificate should not be advertised in the SP's metadata unless it's being used for one of the other purposes below (which is generally a bad idea, but not precluded).
Many commercial vendors mistakenly do this, and all of them are going to regret that decision should certificate lifetime limits continue to trend downward.
SP Signing and Back-Channel TLS Keys and Certificates
...