Community Review in progress!
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 (participants@incommon.org).
Recommended Protocol Support for New IdPs
Generally speaking, a good rule-of-thumb for new IdPs is to start simple and add more features and capabilities as the IdP matures and specific needs develop. Experience has shown that seldom used features are often deployed without adequate testing, leading to latent deployment bugs and even security holes.
A basic strategy is to initially declare support for SAML2 only, that is, do not publish SAML1 endpoints in metadata. The protocol flows for SAML2 and SAML1 are distinctly different, so constraining the set of supported protocols can have significant benefits in terms of troubleshooting, maintenance, and reliability. Therefore, unless you have an InCommon SP partner that specifically requires SAML1 (which is not likely), we recommend you avoid SAML1 publishing endpoints in metadata.
Do not publish SAML1 endpoints
The single, most important protocol choice you can make—with positive, long-term consequences—is to not publish SAML1 endpoints in metadata.
An IdP that chooses not to publish SAML1 endpoints in InCommon metadata may still need to interoperate with a legacy SAML1-only SP at some point. That may or may not require SAML1 endpoints in metadata, but if so, endpoints can be added at any time.
Since a typical SAML2 flow operates completely on the front channel, a SAML2 AttributeService
endpoint is seldom needed, and so an IdP that chooses not publish SAML1 endpoints in metadata can avoid attribute query altogether. This results in a significantly simpler entity descriptor, as illustrated in the sample metadata shown at the bottom of this page.
Do not publish a SAML2 AttributeService endpoint
Since SAML2 IdPs almost always push attributes on the front channel, an IdP with a SAML2 AttributeService
endpoint in its metadata is openly inviting redundant attribute queries. Regardless of other protocol choices, IdPs are advised not to publish a SAML2 AttributeService
endpoint in metadata.
The above steps do not completely eliminate the need for SOAP-based endpoints but at least it confines them to a single role descriptor in metadata where they are more easily managed. In any case, none of the SOAP-based endpoints is routine and so a new IdP is well advised not to support SOAP until a particular need arises.
In summary, the following optimizations force all protocol traffic over the front channel, which is easier to troubleshoot, manage, and maintain.
Constrain SAML Web Browser SSO to the front channel
- Do not publish SAML1 endpoints in metadata
- Do not publish a SAML2
AttributeService
endpoint in metadata - Do not publish SOAP-based endpoints in metadata
Later, if an SP partner requires the use of an unsupported protocol, a new endpoint is easily added to metadata. Since all new SPs registered in the Federation today are required to support SAML2 Web Browser SSO on the front channel, you may never need these extra SAML features, however.
Here is sample metadata for an IdP that supports SAML2 only:
<!-- The Example State University (example.edu) --> <md:EntityDescriptor entityID="https://websso.example.edu/idp" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:IDPSSODescriptor errorURL="https://login.example.edu/support.html" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:Extensions> <shibmd:Scope xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" regexp="false">example.edu</shibmd:Scope> <mdui:UIInfo xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"> <mdui:DisplayName xml:lang="en">Example State University Secure Web Login</mdui:DisplayName> <mdui:InformationURL xml:lang="en">https://login.example.edu</mdui:InformationURL> <mdui:Logo height="128" width="128" xml:lang="en">https://login.example.edu/images/IdP_Logo.png</mdui:Logo> </mdui:UIInfo> </md:Extensions> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> MIIDyTCCArGgAwIBAgIJAKivSalalUbnMA0GCSqGSIb... </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.example.edu/idp/saml2/Redirect/SSO"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.example.edu/idp/saml2/POST/SSO"/> </md:IDPSSODescriptor> <md:Organization> <md:OrganizationName xml:lang="en">The Example State University</md:OrganizationName> <md:OrganizationDisplayName xml:lang="en">Example State University</md:OrganizationDisplayName> <md:OrganizationURL xml:lang="en">http://www.example.edu</md:OrganizationURL> </md:Organization> <md:ContactPerson contactType="technical"> <md:GivenName>Technical Services</md:GivenName> <md:EmailAddress>tech-services@example.edu</md:EmailAddress> </md:ContactPerson> <md:ContactPerson contactType="administrative"> <md:GivenName>Administrative Services</md:GivenName> <md:EmailAddress>admin-services@example.edu</md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>