Skip to main content

SAML Encryption Exception Process

Introduction

Service Providers (SPs) provide a public key to our Identity Provider (IdP) so that the IdP can encrypt its response using that key before sending it to the SP. The traffic between the SP and IdP travels over TLS, but it passes through the user's browser along the way. That is why encryption matters even though TLS is already in use.

What encryption protects against

  1. Exposure of user data in the browser. An unencrypted response is readable by anything with access to the browser session — a malicious or compromised browser extension, injected JavaScript on the SP's login page, a TLS-inspecting proxy, or browser history and cache. Encrypting the response means only the intended SP can read its contents, including the user's identity and any attributes Stanford releases.
  2. The impact of SAML implementation flaws. SAML responses are XML, and XML signature validation has a long and ongoing record of implementation bugs that let an attacker modify a signed response without invalidating the signature — impersonating any user. An encrypted response denies an attacker the plaintext signed material that most of these attacks depend on.

This second risk is not hypothetical, and it is not historical:

Security researchers consistently note that the hardest step in these attacks is obtaining a validly signed SAML assertion in the first place. An encrypted response is what keeps that material out of an attacker's hands.

This is standard practice, not a Stanford requirement

If you are asking your vendor to support encryption, these are the references to point them to:

A vendor that cannot support encrypted assertions is not meeting the baseline interoperability profile that the SAML federation community has published for years.

What you are accepting with an exception

An approved exception remains in effect until revoked. For the life of that exception:

  • Your users' identity and attribute data travel through their browsers unencrypted on every login, readable by anything with access to that browser session.
  • When the next SAML signature-validation flaw is published — and the record above suggests there will be one — your application will be among those exposed and needing urgent vendor patching, rather than among those with a layer of protection already in place.

Applications using SAML should be developed or chosen to 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 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.

  3.  Register your Service Provider Metadata
    • Self-registration: You can register your service in SPDB using temporary (fake) SAML certificates. Once your request is approved, you can update the metadata to remove the temporary certificates.
    • Request assistance: If you're not comfortable registering the service yourself, you can provide the following information in the same service request
      • The SP metadata
      • SP contact email (stanford email)
      • SP owning workgroup
Last modified