Note that this page has been deprecated. The information it contains is no longer current. |
Depending on your answers to the following questions, your SAML deployment may (or may not) be ready for eduGAIN. Your prompt action may be required.
Here is a brief outline of the roadmap for operationalizing eduGAIN: Phase 0: [DONE] Introduce the MD-RPI schema into production metadata (for more info: Registered By InCommon Category) For more info: Roadmap for Operationalizing eduGAIN |
Contents
Issues labeled with below are MUST DO items by February 15, 2016. |
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
Shibboleth IdP V3 is not a prerequisite for eduGAIN, but if you have to make your IdP ready for eduGAIN anyway, you may as well focus on V3.
For more info: Upgrading to 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
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
As a matter of policy, an IdP deployment that does not support SAML2 Web Browser SSO will not be exported to eduGAIN. For more info: Interfederation Technical Policy
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.
As a matter of policy, an SP deployment that does not support SAML2 Web Browser SSO will not be exported to eduGAIN. For more info: Interfederation Technical Policy
All Shibboleth IdP deployers are strongly advised to allocate at least 1500MB of heap space in the JVM to Protect Against Failed Metadata Processes.
This simple procedure must be done by February 15, 2016. If not, your IdP's metadata refresh process will almost certainly fail. |
A discoverable IdP will be configured such that both of the following are true:
The IdP consumes the metadata of all SPs
The IdP responds to all authentication requests
An IdP that is unable (or unwilling) to do so is advised to self-assert membership in the Hide From Discovery Category.
If your IdP is discoverable, it therefore responds to all authentication requests, and so the next question is: What is your IdP's default attribute release policy? That question remains a local policy issue since InCommon does not mandate attribute release policy. That said, an IdP easily satisfies the basic requirements of discoverability by releasing the following (trivial) attribute bundle to all SPs:
Name Identifier: SAML2 Transient NameID
User Attribute: eduPersonScopedAffiliation
This attribute bundle provides only minimal interoperability, however. For other more interoperable alternatives, see: Default Attribute Release
Review your IdP’s overall attribute release policy in the presence of global metadata. If necessary, reconfigure your IdP's attribute release policy using the Registered By InCommon Category.
If, for some reason, the desired policy has not or can not be configured, log into the Federation Manager and opt out of exporting your IdP metadata to eduGAIN. Do this as a last resort only! |
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 pre-empted by global metadata imported into the InCommon metadata aggregate. Know your metadata sources!
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.
Use of the md:EntitiesDescriptor/@Name="urn:mace:incommon" XML attribute in InCommon metadata is deprecated but the attribute will not be removed from InCommon metadata. It will remain as-is indefinitely. However, your IdP configuration should not rely on it in any way. Eventually you will be forced to ignore this legacy value in InCommon 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
To maximize interoperability with global SPs, support the global Research & Scholarship Category! If your IdP is not ready to support global R&S SPs, at least support R&S SPs registered by InCommon. For more info: Research and Scholarship for IdPs (old)
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
To protect against a key compromise at the IdP, SP deployments are strongly advised to automatically refresh and verify metadata at least daily. |
Deployers are advised to point their pre-productions SP deployments at the preview aggregate (which contains global metadata as of January 15, 2016).
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 above.
If your SP exposes a dynamic discovery interface, normally you will filter IdPs in the Hide From Discovery Category from your discovery interface. Also check to make sure your discovery interface scales to many 100s of IdPs.
If your SP exposes a dynamic discovery interface and you do not export your SP metadata, 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.
If your SP accepts SAML assertions from arbitrary IdPs and you do not export your metadata, 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.
As a matter of policy, an IdP that does not support SAML V2.0 Web Browser SSO will not be exported. (An IdP advertises support for 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
If your IdP is not discoverable, you should self-assert membership in the Hide From Discovery Category.
Remove any unneeded certificates from IdP metadata. Please do your part to keep global metadata file sizes to a minimum.
Publish technical and administrative Contacts in Metadata so that SP partners know how to contact you if necessary.
As a matter of policy, an SP that does not support SAML V2.0 Web Browser SSO will not be exported. (An SP advertises support for 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
Remove any unneeded certificates from SP metadata. Please do your part to keep global metadata file sizes to a minimum.
A global SP is advised to publish Requested Attributes in metadata since some IdPs in other federations only release attributes in the presence of <md:RequestedAttribute>
elements in SP metadata.
InCommon no longer supports SAML1-format <md:RequestedAttribute> elements in SP metadata. Only SAML2-format <md:RequestedAttribute> elements are supported. Consequently, global SPs are advised to advertise support for SAML2 protocols only. |
Publish technical and administrative Contacts in Metadata so that IdP partners know how to contact you if necessary.
Is your service operated for the purposes of supporting research and scholarship interaction, collaboration or management, at least in part? If so, then by all means apply for membership in the Research & Scholarship Category! For more info: Research and Scholarship for SPs
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
As it turns out, about 70 InCommon SPs are known to publish their metadata in other federations. We advise organizations with entity metadata published in multiple federations to begin the process of synchronizing disparate metadata sources so that the metadata are functionally equivalent across federations. Only then can you phase out redundant metadata instances without loss of service.