This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list.
The term endpoint refers to a URL location in metadata that is explicitly declared to support a particular SAML protocol, binding, or profile. At runtime, an entity 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.
This page and its child pages provide guidance to deployers of SAML software in the InCommon Federation:
In general, the recommendations found on these 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 entity'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 SAML V2.0 authentication requests most often do so using HTTP-Redirect. 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 do, so check your documentation for details.
In a perfect world, all entities would support SAML V2.0, in which case SOAP-based attribute query and artifact resolution become unnecessary. This would dramatically simplify the deployment of SAML in the Federation.
General Requirements
At the transport level, all protocol endpoints SHOULD be protected with SSL/TLS. In particular, browser-facing endpoints at the IdP MUST be protected with SSL/TLS to preserve the confidentiality of secrets and other sensitive information in transit.
At the message level, all entities SHOULD support SAML V2.0 Web Browser SSO (whereas support for SAML V1.1 Web Browser SSO is OPTIONAL). In the InCommon Federation, IdPs are strongly encouraged to support SAML V2.0 Web Browser SSO so that SPs have choices with respect to protocol. IdPs that wish to interoperate with the widest range of service providers will support SAML V1.1 Web Browser SSO as well.
Finally, it is recommended that all endpoint locations include a hostname that is rooted in the primary DNS domain of the organization responsible for the entity. If submitted metadata does not meet this basic requirement, a manual vetting process will be triggered.
See the child pages for specific guidelines and recommendations regarding other profiles, bindings, and protocols.