Service Providers (SPs) provide a public key to our Identity Provider (IdP) so that the IdP can encrypt its responses using that key before sending the response to the SP. Even though the traffic between SP and IdP (through the user's browser) is over TLS, there are very good reasons to do this encryption
-
Encrypting the response prevents any other application on the browser from accessing the contents of the response. Normally, this would not be possible, but in the event of a browser flaw, it is useful to have this safeguard.
-
In the event of security exploits, having the response encrypted can mitigate the effects of the exploit.
Number 2 actually happened early in 2018. There was a flaw in an XML parsing library that would allow someone to take a signed response and alter it so make it appear as if a different user had authenticated. In other words, an attacker could pretend to be anyone else. In this case, encrypted responses would have prevented the attack; see also https://shibboleth.net/community/advisories/secadv_20180227.txt
Service Provider metadata submited through Stanford's metadata portal SPDB must include a certificate sutiable for encrypting responses.
Applications using SAML should be developed or chosen that support encrypted responses.
