Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

InCommon Operations will deploy three new metadata aggregates at the following permanent HTTP locations:

The new locations will replace the current HTTP location of production metadata:

Moving forward, all new metadata services will be deployed on vhost md.incommon.org. Legacy vhost wayf.incommonfederation.org will be phased out.

...

Moving forward, all new metadata aggregates will be signed using a new self-signed signing certificate set to expire on December 18, 2037:

In the future, we don't intend to re-sign the new self-signed metadata signing certificate unless it's absolutely necessary.

...

Tip
titleChoose one: production or preview?

An important decision point for each deployment is whether to migrate to the new production metadata aggregate or the preview metadata aggregate. Regardless of whether your deployment is compatible with SHA-2, determine the ultimate goal (production or preview) and plan accordingly. Depending on timing, you may have to temporarily migrate to the fallback metadata aggregate to reach your ultimate goal.

...

Shibboleth IdP deployments in the InCommon Federation are least affected by this implementation plan.

Tip
titleThe Shibboleth IdP is SHA-2 compatible

Being a pure Java implementation, the Shibboleth IdP software will verify an XML signature based on a SHA-2 digest algorithm if the underlying version of Java supports SHA-2. Therefore , all Shibboleth IdP deployments based on Java version 1.4.2 (or later) should migrate to the new production metadata aggregate ASAP (but no later than March 29, 2014).

If you are running Shibboleth IdP version 2.0 (or later), you are almost certainly running Java 1.4.2 (or later). In that case, your software is compatible with SHA-2 and you can migrate to the new production metadata aggregate at your convenience (but no later than March 29, 2014).

There are two modifications you need to make to your IdP’s metadata configuration:

...

Tip
titleThe Shibboleth SP on the Windows platform is SHA-2 compatible

On the Windows platform, the Shibboleth SP software will verify an XML signature based on a SHA-2 digest algorithm. Therefore Windows-based Shibboleth SP deployments should migrate to the new production metadata aggregate (or the preview metadata aggregate) ASAP ( but no later than March 29, 2014).

Since OpenSSL is not bundled with the Shibboleth SP software on a non-Windows platform, SHA-2 compatibility depends on the version of OpenSSL in use by the SP.

...

On Linux, the Shibboleth SP software depends on whatever version of OpenSSL is built into the underlying operating system, and so it is relatively easy to determine the version of OpenSSL in use:

Code Block
languagebash
$ /usr/bin/openssl version
OpenSSL 0.9.8y 5 Feb 2013

...

Bottom line: If your Shibboleth SP deployment depends on OpenSSL version 0.9.8 or later, you should migrate to the new production metadata aggregate (or the preview metadata aggregate); otherwise, you should migrate to the new fallback metadata aggregate. In either case, there are two modifications you need to make to your SP’s metadata configuration:

...

The simpleSAMLphp metarefresh module will refresh and verify metadata automatically. Signature verification depends on the fingerprint of the metadata signing certificate, so the fingerprint configured in the metarefresh module must be updated before migrating simpleSAMLphp to one of the new metadata aggregates.

Warning
titleOld versions of simpleSAMLphp are incompatible with SHA-2

It is known that versions of simpleSAMLphp prior to version 1.11 are not compatible with SHA-2. You will need to upgrade to simpleSAMLphp 1.11 (or later) before migrating to the new production metadata aggregate (or the preview metadata aggregate).

If you're running simpleSAMLphp 1.11 (or later), your software is compatible with SHA-2 and you should migrate to the new production metadata aggregate (or the preview metadata aggregate); otherwise you should migrate to the new fallback metadata aggregate. In either case, there are two configuration changes you need to make to simpleSAMLphp's metarefresh module:

...

The second step is critical for simpleSAMLphp deployments (despite the fact that the new metadata signing certificate contains the same key as the old signing certificate). See the Metadata Consumption wiki page for instructions how to securely obtain the fingerprint of the new metadata signing certificate.

Note
titleDeployments not compatible with SHA-2 should plan to upgrade

If your simpleSAMLphp deployment is not compatible with SHA-2, and you migrate to the new fallback metadata aggregate, start planning now to upgrade your simpleSAMLphp installation and migrate to the new production metadata aggregate (or the preview metadata aggregate) ASAP ( but no later than June 30, 2014).

Note: simpleSAMLphp 1.12 is due to be released in December 2013. You may want to wait for this release since it includes significant improvements to the metarefresh module.

...

Microsoft AD FS 2.0 is not able to consume the InCommon metadata aggregate, so the answer depends on the external process used you use to refresh and verify metadata on behalf of AD FS. Some deployments use a tool called FEMMA, which does not verify the signature on the metadata. In this case the XML signature on the new metadata aggregate will have no adverse effect. An AD FS deployment that uses FEMMA is advised to migrate to the new production metadata aggregate (or the preview metadata aggregate) ASAP ( but no later than March 29, 2014).

Warning
titleFEMMA alone does not provide a secure metadata refresh process

If your AD FS deployment uses FEMMA alone to consume InCommon metadata, it is doing so insecurely. A secure metadata process will verify the signature on the metadata and check the validUntil attribute on the root element of the XML file. FEMMA does neither. See the Metadata Consumption wiki page for more information about the validUntil attribute.

An alternative to FEMMA called pysFEMMA will verify the signature on the metadata, however. Like the Shibboleth SP, an AD FS deployment that uses pysFEMMA will have difficulty migrating to the new metadata aggregate if the underlying crypto library is incompatible with SHA-2. See the AD FS Metadata Config wiki page for more detailed information about FEMMA and pysFEMMA.

...