SAML Encryption Exception Process

Introduction

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

1. 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.
2. 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 this Shibboleth Service Provider Security Advisory. A similar issue was found with simpleSAMLphp in late 2019.

Applications using SAML should be developed or chosen that support encrypted responses.

Policy

Stanford's policy is to require SPs to provide a certificate and support encrypted responses. This is enforced in the SPDB by rejecting any SP metadata that does not contain a certificate suitable for encryption.

Exceptions

If you are using an SP that is having problems with encrypted responses, your first step is to contact those managing the SP and find out if there is some way to use encrypted responses. If you still need to go ahead with unencrypted responses you must go through an exception process. The group implementing the exception process may charge for time and materials depending on the complexity and effort involved.

The Exception Process

1. File a service request providing the following information:
   • The entityID of the Service Provider
   • Contact information for the Service Provider's technical support
   • Reason why the Service Provider cannot support encrypted responses
   • Number of people at Stanford who will be using application
   • Purpose of the application
   • Name and email of the Service Provider's Stanford technical contact
   • Name and email of the manager of the Stanford team responsible for this application
2. Have the manager of the Stanford team responsible for this application send an e-mail to saml-team@lists.stanford.edu including all the information in section #1 and agreeing to this text:

   We are aware that by not encrypting the Identity Provider's SAML response there is an increased risk both of exposing the response's data and future security issues exploiting the unencrypted response, and that we accept this increased risk.