SAML assertion encryption and using same key for encryption as signing

Question

I am working with a company that has product that supports SAML based authentication. We do not facilitate for just in time federation and only accept the user identifier in assertion responses (the user must already exist in the system).

If we are signing the response, what would be my justification for wanting to encrypt this non confidential data?

Customer's argument is its just good to do, and that all of their other providers facilitate for this by just using the same key to encrypt and for signing (and that all of their other service providers allow this). This sets off massive red flags for me for everything I have ever been taught on the basics of cryptography.

Firstly, the whole point of supplying a public key for signing is that anyone can own the key to check it, wouldn't this mean an identity provider would use the same private key for every service provider for signing? Therefore using the same key for encryption would void the trust boundary between every service provider using that identity provider? Am I misunderstanding this?

Secondly, if the Identity provider supplies the metadata with the encryption key, wouldn't it be a public key they are supplying to the service provider. Shouldn't the party on the receiving end of the encrypted message (aka the service provider) have the private key, not the public key? What am I missing?

Thanks,

Answer 1

Encrypting the SAML assertion is optional. Whether or not it's encrypted, you still have privacy through the transport layer security.

Scenarios where encrypting the SAML assertion should be considered include: the SAML assertion contains particularly sensitive user information; SAML SSO is occurring in a sensitive environment.

Your understanding regarding public vs private keys is correct. The service provider supplies their encryption public key to the identity provider.

The identity provider encrypts the SAML assertion with the service provider's public key.

Only the custodian of the corresponding private key (ie the service provider) can decrypt the SAML assertion.

Regardless of whether or not the SAML assertion is encrypted, the identity provider should sign either the SAML assertion or the SAML response that envelopes the SAML assertion.

The identity provider signs the SAML assertion or response using its own private key.

The service provider verifies the signature using the corresponding public key of the identity provider.

The only other consideration is with SP-initiated SSO the SAML authn request often is signed.

In this case the service provider signs the authn request with its private key and the identity provider verifies the signature using the corresponding public key.

The service provider has the option of using the same or different keys for signature generation and SAML assertion decryption.

One advantage of using the same key for signature generation and decryption is that there's one less certificate to distribute and manage.

The golden rule in all of this is that no party should ever divulge their private key to another party.