Metadata exchange and trust
Metadata can be said to be where SAML starts. Exchanging metadata between IdP and SP sets up the initial configuration and trust between the two that is later used to authenticate users. For a beginner this can be a quite abstract step, but in this article I will make everything clear.
The Metadata is a XML document contain many things. For example end points to be used to authenticate users, bindings(transportation methods) supported, requirements on signing. Also and very important, public keys and certificates that is used to establish trust. More on trust further down. Full specification of SAML metadata is located here
When a SP decides to start using a IdP for authenticating users, the first thing that is done is to exchange metadata. The SP sends it metadata to the IdP and the IdP send its metadata to the SP.
The exchange can be done in different ways, but two popular is to either send it using email or to expose it on a web page on the SP or IdP service.
Ones exchanged, the SP and IdP both use this metadata in their systems for further communication.
When the SP wants to authenticate a users, it send the user to the end point specified in the IdP metadata, using a binding also specified in the IdP metadata. Ones the IdP has finished authenticating the user it send the user back to the SP, to the end point specified in the SP metadata, using a binding specified in the SP metadata.
How signing of messages is done is also specified in the metadata.
So as you see the metadata is the specification of how the two parties can integrate with another and should contain the data needed to that start working together.
Trust
Trust between the SP and IdP is vitally important for many reasons in SAML. First, the more implicit trust is important to understand.
Ones a SP sets up a integration to a IdP, it leaves all responsibility for authenticating a user to the IdP. The SP just sends a redirect to the user browser and then it goes to the IdP. How authentication then is done is up to the IdP (with some influence from the SP in the authentication request). The next thing that SP sees is the user coming back with a response from the IdP saying who the user is. Because of this it is important for the SP the trust the IdP to correctly authenticate users.
The other trust is the cryptographic trust between SP and IdP. In the exchanged metadata, there is also contained certificated and public keys for each party. Some for singing and some for encryptions. Theses are then used to secure all message transport between SP and IdP.
When the SP send the authentication request to the IdP together with the users. It usually signs it. It does so with its private key for the corresponding key in the metadata. When the IdP received the used and authentication request, it verifies the signature with the public key in the metadata previously sent from the SP.
Same thing, when the IdP responds. IdP signs response with its private key. SP verified with IdP public key in metadata.
This way both parties can cryptographically trust that the message received was from the expected sender.