...
The term endpoint refers to a URL location in entity metadata that is explicitly declared to support a particular SAML protocol, binding, and/or profile. At runtime, an entity a relying party routinely checks endpoints in metadata to minimize the possibility of spoofing or phishing. Thus the accuracy of endpoint URLs in metadata is crucial, contributing to the overall security of the SAML exchange.
...
In general, the recommendations found on these pages (and their child pages) will maximize interoperability among Federation participants. In practice, a deployer supports those bindings and protocols that meet the particular needs of their federation partners. It's important, however, that deployers include endpoints in metadata that accurately reflect the entitydeployment's software configuration, otherwise runtime errors will occur.
Message Flows
In the InCommon Federation, SPs that issue SAML V1.1 authentication requests use the Shibboleth 1.x AuthnRequest Protocol. The IdP typically returns the response using SAML V1.1 Browser/POST, but because SAML V1.1 does not support message-level encryption, IdPs usually do not include attributes in the response. Instead the SP subsequently queries the IdP for attributes using the SAML V1.1 SOAP binding.
Similarly, SPs that issue Usually an SP issues a SAML V2.0 authentication requests most often do so request using the HTTP-Redirect binding. The IdP typically returns the response using SAML V2.0 HTTP-POST. Since message-level encryption was introduced in Version 2.0 of SAML Web Browser SSO, the IdP usually includes attributes and encrypts the assertion in the POSTed response. Thus the SP need not query for attributes in the usual SAML V2.0 flow.
Other exchanges are possible of course. One alternative is for the IdP to return a so-called artifact to the SP in lieu of the actual assertion. The SP then turns around and issues an artifact resolution request to the IdP via SOAP. Both SAML V1.1 and V2.0 support this type of artifact resolution, but not all implementations doNot all implementations support artifact resolution, so check your documentation for details.
In a perfect world, all entities deployments would support browser-facing SAML V2.0, in which case SOAP-based attribute query and artifact resolution become mostly unnecessary. This would dramatically simplify the deployment of SAML in the Federation.
...