Trusting SAML Meta-Data

We announced the release of PingFederate 5 this month. This release includes support for dynamic federation which our marketing department has called Auto-Connect(tm). One of the more interesting aspects of Auto-Connect is how you establish the trust that allows you to know that the business partner you are federating with is really who they say they are. Andre touched on this a little bit here.

Before Auto-Connect an organization had to establish a cryptographic trust relationship with its partner via the manual, out-of-band exchange of certificates. This means the each organization ends up with a list of partner certificates that anchors the trust relationships – a trust anchor list. The SP only accepts SAML assertions from an IdP if the signature over the SAML assertion can be validated by a certificate in its trust anchor list. The need for this out-of-band exchange of certificates is one of the friction points we are eliminating with Auto-Connect.

An additional issue is that as a company starts to federate with more and more federation partners the number of partner certificates they must manage increases. As we all know, certificates expire and quite often need to be renewed as often as every 12 months. I have been involved in a number of situations where an application failure is the result of an expired certificate. Once an organizations trust anchor list contains 10's and 100's of partner certificates, a different partner certificate will expire weekly or even daily. Organizations are then forced to add people and process to track certificates that are about to expire, reach out to their partners for a new certificate and then test that the new certificate actually works. Ouch. Trust me, I've been there.

One of the benefits of Auto-Connect is that the partner certificates used to sign and validate SAML Assertions are included in the SAML meta-data file. In addition every partner’s SAML meta-data file is dynamically retrieved by the federation server from a well known URL endpoint. The SAML meta-data file includes controls around cache-duration and meta-data validity periods that allow each partner to dynamically control when a partners federation server should re-retrieve meta-data and thus get a new certificate. This may be set to daily, weekly or monthly depending on how often the contents of the meta-data file is expected to change.

The fact that you trust the key in the meta-data and will use it to validate signatures of SAML messages is because you have separately established trust in the meta-data file itself. So obviously this begs the question – How do I trust the meta-data file is my partners meta-data file?

The short answer is that the meta-data file itself must be signed and the X.509 certificate used to validate the signature is itself included in the meta-data file. The keys used to trust the meta-data file are separate and in my view will be X.509 certificates issued by publicly trusted Certificate Authorities. The trust anchor list in each partners federation server will contain root CA certificates rather than individual partner certificates.

In effect we are leveraging dynamic SAML meta-data retrieval to facilitate key distribution. Obviously this is all happening under the covers and the user and the federation administrator see all of this happening transparently.