The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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

  1. Do not publish SAML1 endpoints in metadata
  2. Do not publish a SAML2 AttributeService endpoint in metadata
  3. 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>
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels