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 support 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 SP partner that specifically requires SAML1 (which is not likely), we recommend you avoid SAML1 endpoints in metadata altogether.
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 InCommon metadata.
By eliminating the legacy SAML1 protocol, an IdP can avoid attribute query altogether since a typical SAML2 flow operates completely on the front channel. (In fact, an IdP with a SAML2 AttributeService endpoint in its metadata is openly inviting redundant attribute queries.) Indeed, an IdP that supports SAML2 only does not need an <md:AttributeAuthorityDescriptor> element in its metadata, resulting in a significantly simpler entity descriptor.
This does not completely eliminate the need for SOAP-based endpoints but at least it confines them to a single role descriptor where they are more easily managed in metadata. In any case, none of these 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 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
- Do not publish a SAML2
AttributeServiceendpoint - Do not publish SOAP-based endpoints
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>