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.
The following deployment strategy forces all protocol traffic over the front channel, which is easier to troubleshoot, manage, and maintain.
Recommended Protocol Support for New IdPs
- DO support SAML2 Web Browser SSO on the front channel
- DON’T support back-channel SAML protocols
Later, if an SP partner requires the use of a back-channel SAML protocol, a new endpoint is easily added to metadata. However, 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.
To illustrate the recommendations in terms of metadata, here is sample entity descriptor for an IdP that supports SAML2 Web Browser SSO on the front channel 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>
Note the following protocol-related features of this entity descriptor:
- There is just one role descriptor, given by the
<md:IDPSSODescriptor>element. - The
protocolSupportEnumerationXML attribute indicates SAML2 only. - There are two
SingleSignOnServiceendpoints that support theHTTP-RedirectandHTTP-POSTbindings (both of which are front-channel bindings).
If you compare this metadata to the majority of IdP entity descriptors in InCommon metadata, you’ll notice the following significant differences:
- Most IdP entity descriptors include two role descriptors, given by the
<md:IDPSSODescriptor>and<md:AttributeAuthorityDescriptor>elements. - Each role descriptor contains its own key descriptor, and moreover, the two key descriptors are identical.
- Most IdPs publish one or more back-channel, SOAP-based endpoints, including:
ArtifactResolutionServiceendpointsAttributeServiceendpoints
Clearly the metadata for an IdP that only supports SAML2 on the front channel is much simpler. That simplicity translates into an IdP that is easier to troubleshoot, manage, and maintain.