Why use an x.509 certificate to encrypt xml? Why not just transmit over https?

Question

Don't know much about encryption...

Say I'm preparing a SAML request to submit to an identity provider. Why would I need to apply an x.509 certificate to this request? Is transmission over SSL alone not secure enough?

Answer 1

Yes - SSL is enough - but SSL is only point-to-point. You cannot secure your connection using SSL if there are a few intermediaries in the way between your source and your target machine.

In that case, e.g. when transmitting over the internet, you must safeguard the actual message, instead of the transport-level. That's why you need to encrypt the XML (or at least parts of it).

Marc

Answer 2

Most likely because they want to authenticate you (the client). HTTPS can be used for client authentication, but it rarely is in practice.

Answer 3

All that HTTPS will do is encrypt the communication between two points and prevent eavesdroppers -- it won't confirm who it was that sent the message. Neither will it assure secure communication if your message is then forwarded.

If you sign your request with the X.509 certificate you can be assured the decryptor has the shared secret contained in certificate. In other words, you can be assured the message can only be decrypted by the organisation you want it to be decrypted by.

In your case, the X.509 encryption requirement means that you should be assured that the identity provider is the only organisation that will receive your request.

A useful Wikipedia primer is here.

Answer 4

In practice, you could use HTTPS (SSL/TLS) to protect your SAML message. But you would want to use two-way SSL certificate verification/validation, meaning your client would need to verify the server's X.509 certificate and the server would need to be configured to perform client authentication, which would require it to check an X.509 certificate that the client presents. So, the client would need its own certificate anyway.

SSL/TLS is not really designed for this...it was/is designed to protect web traffic from being seen while in transport and for the client to be able to tell what server they are talking to and sending sensitive information to (it was really designed for e-commerce where the client (user buying something) knows who they are sending their credit card information to). In the case of SAML, the whole point is for the parties to know that the information they are exchanging has not been altered in transport and that each is talking to who they think they are. Using certificates to sign/encrypt that message itself accomplishes that.