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

In the case of SAML, message-level security (i.e. the XML itself is signed and sometimes encrypted) because the communication involves parties that don't communicate directly. SSL/TLS is for transport-level security, only used between the two parties that are communicating directly and for the duration of this communication only.

Depending on which SAML binding you use, the dialog can look like this (e.g. along the lines of Shibboleth):

• User's browser connects to Service Provider (SP)
• SP gives the user a SAML request, not necessarily visible, but hidden within a form or equivalent.
• User's browser (in a direct connection to the IdP) sends the SAML request to the IdP.
• The user authenticates with it and gets a SAML response back.
• The user's browser sends that SAML response to the SP.

In this scenario, there is no direct SSL/TLS connection between the SP and the IdP, although all 3 parties are involved. (Some variants of this involve a back-end communication between SP and IdP for attributes, but that's a different problem.)

• An SSL/TLS connection wouldn't be sufficient for the IdP to know that the SAML request came from an SP for which it's allowed to authenticate and release attribute, since the connection to the IdP comes from the user's browser, not the SP itself. For this reason, the SP must sign the SAML request message before handing it to the user's browser.
• An SSL/TLS connection wouldn't be sufficient for the SP to know the SAML response came from an IdP it trusts. Again, that's why the SAML response itself is also signed.

What applies to signing also applies to encryption, if the middle party, i.e. the user, isn't meant to see what's in the SAML message and/or if the connection between the user and the SP or IdP isn't over SSL/TLS (usually, it should be over HTTPS).

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

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

Answer 5

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.