Verify SAML Response is from a Trusted Source

Question

I'm in the process of making changes to my site so that we can be a SAML 2.0 Service Provider. We will be doing IdP initiated SAML with Out-of-Band account federation.

My question is this: Given a SAML response that is posted to the target page on my site, how do I verify that the response was generated by a trusted source?

I can validate the signature that is embedded in the response, but... couldn't anyone just sign an response and start posting it at my site, attempting to validate users? I assume there is something in the signature that I can extract and match against a list of trusted Identity Providers? But couldn't an attacker just spoof that?

Answer 1

The signature should validate against a key. You should have a corresponding key for any entity that you are exchanging data with. Unauthorized entities will not have keys, and the keyspace of any widely-accepted good cryptography protocol will make brute-forcing impossible.

From the wording of your question, I think you may wish to read up on the concept of digital signatures.

Answer 2

As @Jeff Ferland said, you need to trust the key from the remote party.

This is exactly why Shibboleth federations are designed for, for example. If you look at a typical Shibboleth SP configuration example, it will regularly pull a metadata file that will pull the certificates of the IdPs that are part of the federation. You need to verify that you trust that list usually (it can be signed by the federation certificate, or made available from a trusted HTTPS server). Then you need to verify that the SAML response you get is issued by one of the IdPs in that federation.

Note that this is only one way of getting a list of trusted certificates. You could do it more manually if you know in advance which IdPs you're willing to trust. You will always have to configure at least one "entry point" more or less manually (by this, I mean either some IdP certificate you know you trust, out of bands, or a federation's CA certificate): this is same problem as any PKI, including how you trust websites in your browser.

The real difficulty in this sort of environment isn't really technical, rather, it's the administrative part whereby you negotiate with your partners which certificates you want to trust (and which attributes may be exchanged).