Is your SAML deployment ready for eduGAIN?

Depending on your answers to the following questions, your SAML deployment may be ready for eduGAIN or it may be at-risk. Your action may be required.

IdP Software Issues

Are you running the Shibboleth IdP software?

Shibboleth IdP deployers are strongly advised to allocate at least 1024MB of heap space in the JVM to Protect Against Failed Metadata Processes.

Are you running Shibboleth IdP V2?

Shibboleth IdP V2 deployments earlier than V2.4.5 are susceptible to a logging issue that masks an error message when the JVM runs out of memory. For more info: Protect Against Failed Metadata Processes

Are you running Shibboleth IdP V3?

Shibboleth IdP V3 deployments earlier than V3.2.0 are susceptible to a logging issue that masks an error message when the JVM runs out of memory. For more info: Protect Against Failed Metadata Processes

Are you running the simpleSAMLphp IdP software?

All simpleSAMLphp deployments earlier than 1.13.2 are susceptible to performance issues when processing large metadata files. For more info: Protect Against Failed Metadata Processes

Does your IdP support SAML2 Web Browser SSO?

As a matter of policy, an IdP entity not having a SAML2 SingleSignOnService endpoint that supports the HTTP-Redirect binding will not be exported to eduGAIN. For more info: Interfederation Technical Policy

SP Software Issues

Are you running the simpleSAMLphp SP software?

All simpleSAMLphp deployments earlier than 1.13.2 are susceptible to performance issues when processing large metadata files. For more info: Protect Against Failed Metadata Processes

Also, if you need to filter metadata (see below), install the metarefresh patch contributed to the simpleSAMLphp project by Cirrus Identity.

Does your SP support SAML2 Web Browser SSO?

As a matter of policy, an SP entity not having at least one SAML2 AssertionConsumerService endpoint that supports the HTTP-POST binding will not be exported to eduGAIN. For more info: Interfederation Technical Policy

IdP Configuration Issues

Does your IdP refresh InCommon metadata at least daily?

If your IdP does not automatically refresh InCommon metadata at least daily, self-assert membership in the Hide From Discovery Category. For more info: Metadata Consumption

Does your IdP consume metadata from multiple sources?

If your IdP consumes metadata from multiple sources (which is common), the introduction of global metadata may cause a race condition that results in interoperability issues. For example, suppose a Shibboleth IdP is configured with a chaining MetadataProvider as follows:

<MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider"
                  xmlns="urn:mace:shibboleth:2.0:metadata">

  <!-- Refresh some pre-InCommon metadata aggregate -->
  <MetadataProvider id="preICMD" xsi:type="FileBackedHTTPMetadataProvider"
                    xmlns="urn:mace:shibboleth:2.0:metadata" ...>

      <!-- ... -->
  </MetadataProvider>

  <!-- Refresh the InCommon metadata aggregate -->
  <MetadataProvider id="ICMD" xsi:type="FileBackedHTTPMetadataProvider"
                    xmlns="urn:mace:shibboleth:2.0:metadata"
                    metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml"
                    backingFile="%{idp.home}/metadata/InCommon-metadata.xml">

      <!-- ... -->
  </MetadataProvider>

  <!-- Refresh some post-InCommon metadata aggregate -->
  <MetadataProvider id="postICMD" xsi:type="FileBackedHTTPMetadataProvider"
                    xmlns="urn:mace:shibboleth:2.0:metadata" ...>

      <!-- ... -->
  </MetadataProvider>

</MetadataProvider>

Entity metadata normally refreshed post-InCommon may be short-circuited by global metadata introduced into the InCommon metadata aggregate. Know your metadata sources!

Does your IdP rely on the Name XML attribute in InCommon metadata?

Do not rely on the md:EntitiesDescriptor/@Name="urn:mace:incommon" XML attribute in InCommon metadata. Once we transition to per-entity metadata, such a policy rule will have no effect.

Does your IdP rely on the incommon.org R&S entity attribute value in SP metadata?

Do not rely on the deprecated incommon.org R&S entity attribute value (http://id.incommon.org/category/research-and-scholarship) in SP metadata. This entity attribute value will be removed from SP metadata in the future. For more info: Migrating an IdP to Global Research and Scholarship

Does your IdP support the global Research & Scholarship Category?

To maximize interoperability with global SPs, support the global Research & Scholarship Category! If your IdP is not yet ready to support global R&S SPs, at least support R&S SPs registered by InCommon. For more info: Research and Scholarship for IdPs

Does your IdP have a default attribute release policy?

If your IdP does not automatically release a persistent, non-reassigned identifier to all SPs (including global SPs), self-assert membership in the Hide From Discovery Category. For more info: Default Attribute Release

Is your IdP's attribute release policy configured correctly?

Review your IdP’s attribute release policy in the presence of eduGAIN metadata. If necessary, reconfigure your IdP's attribute release policy using the Registered By InCommon Category.

SP Configuration Issues

Does your SP refresh and verify InCommon metadata at least daily?

If your SP does not refresh and verify InCommon metadata at least daily, your SP may be lacking a proper signing certificate revocation mechanism and therefore blindly trusting signed SAML assertions. For more info: Metadata Consumption

Does your SP consume metadata from multiple sources?

If your SP consumes metadata from multiple sources, the introduction of global metadata may cause a race condition that results in interoperability issues. For more info, see the corresponding IdP configuration issue.

Does your SP expose a dynamic discovery interface?

If your SP exposes a dynamic discovery interface, then you should filter IdPs in the Hide From Discovery Category from your discovery interface.

If your SP exposes a dynamic discovery interface and you do not export your SP metadata, then you should filter global metadata altogether, otherwise some users may have a failed login experience. If necessary, reconfigure your SP using the Registered By InCommon Category.

Does your SP accept SAML assertions from arbitrary IdPs?

If your SP accepts SAML assertions from arbitrary IdPs and you do not export your metadata, then you should filter global metadata altogether, otherwise you may end up giving access to unauthorized users. If necessary, reconfigure your SP using the Registered By InCommon Category.

IdP Metadata Issues

Do you have unneeded certificates in IdP metadata?

Remove any unneeded certificates from IdP metadata. Do your part to keep global metadata file sizes to a minimum.

Does your IdP support SAML V2.0 Web Browser SSO?

As a matter of policy, an IdP that does not support SAML V2.0 Web Browser SSO will not be exported. (An IdP advertises supports SAML V2.0 Web Browser SSO if its metadata contains a SAML2 SingleSignOnService endpoint that supports the HTTP-Redirect binding.) For more info: Interfederation Technical Policy

Is your contact information in IdP metadata current and up-to-date?

Publish technical and administrative Contacts in Metadata so that SP partners know how to contact you.

SP Metadata Issues

Do you have unneeded certificates in SP metadata?

Remove any unneeded certificates from SP metadata. Do your part to keep global metadata file sizes to a minimum.

Does your SP support SAML V2.0 Web Browser SSO?

As a matter of policy, an SP that does not support SAML V2.0 Web Browser SSO will not be exported. (An SP advertises supports SAML V2.0 Web Browser SSO if its metadata contains at least one SAML2 AssertionConsumerService endpoint that supports the HTTP-POST binding.) For more info: Interfederation Technical Policy

Is your contact information in SP metadata current and up-to-date?

Publish technical and administrative Contacts in Metadata so that IdP partners know how to contact you.

Other Issues

Does your organization have more than one IdP registered in metadata?

As a matter of policy, an organization that deploys multiple IdPs with competing DisplayNames must tag all but one of those IdPs with the hide-from-discovery entity attribute. For more info: Hide From Discovery Category