Is your SAML deployment ready for eduGAIN?
Depending on your answers to the following questions, your SAML deployment may be at-risk. Your action may be required.
IdP Software Issues
Are you running the Shibboleth Identity Provider 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 Identity Provider 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 Identity Provider 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 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
SP Software Issues
Are you running the simpleSAMLphp 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.
IdP Configuration Issues
Does your IdP refresh and verify InCommon metadata at least daily?
If not, self-assert membership in the Hide From Discovery Category. See: Metadata Consumption.
Does your IdP consume metadata from multiple sources?
If your IdP consumes metadata from multiple sources (which is typical), 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.
Does your IdP rely on the Name XML attribute in InCommon metadata?
Do not rely on the md:EntitiesDescriptor/@Name XML attribute in InCommon metadata.
Does your IdP have a default attribute release policy?
Does your IdP support the global Research & Scholarship Category?
Does your IdP rely on the incommon.org R&S entity attribute value in SP metadata?
SP Configuration Issues
Does your SP refresh and verify InCommon metadata at least daily?
If not, your SP may be lacking a proper certificate revocation mechanism and therefore blindly trusting signed SAML assertions. See: 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.
Does your SP have a dynamic discovery interface?
If your SP has a dynamic discovery interface and you do not export your SP metadata, then you should filter global metadata at the SP, otherwise some users may have a failed login experience. If necessary, configure your SP using the Registered By InCommon Category.
IdP Metadata Issues
Does your IdP support SAML V2.0 Web Browser SSO?
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.)
SP Metadata Issues
Does your SP support SAML V2.0 Web Browser SSO?
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.)