Protocol Support for New IdPs

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.

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. This may or may not require SAML1 endpoints in metadata, but in any case, endpoints can be added to metadata at any time.

Since a typical SAML2 flow operates completely on the front channel, a SAML2 AttributeService endpoint is usually not needed. This leads to the following simplification:

Assuming a SAML2 AttributeService endpoint is not published, an IdP that chooses not to publish SAML1 endpoints is able to completely avoid attribute query. This results in a significantly simpler entity descriptor containing a single role descriptor element.

Within that role descriptor, a half dozen endpoint types are defined. In practice, only three of these endpoints are actually used:

• SingleSignOnService endpoint
• SingleLogoutService endpoint
• ArtifactResolutionService endpoint

Of those, only the SingleSignOnService endpoint is strictly required for SAML Web Browser SSO. The others raise significant issues, and should therefore be avoided in new IdP deployments.

In summary, the following optimizations force all protocol traffic over the front channel, which is easier to troubleshoot, manage, and maintain.

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>