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

Compare with Current View Page History

« Previous Version 14 Next »

Phase 1 Implementation Plan Frequently Asked Questions

In September 2013, the Metadata Distribution Working Group submitted its Phase 1 Recommendations to the InCommon Technical Advisory Committee. This FAQ anticipates questions and concerns regarding a Phase 1 Implementation Plan that is currently taking shape.

General Questions

Why are you changing the HTTP location of InCommon metadata?

Questions about SAML Software

How does this implementation plan affect Shibboleth IdP deployments?

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

The 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. Therefore Shibboleth IdP deployments should migrate to the new production metadata aggregate ASAP (but no later than March 29, 2014).

If you are running a supported version of the Shibboleth IdP, 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:

  1. The metadataURL XML attribute on the <MetadataProvider> element should point to the HTTP location of the new production metadata aggregate.
  2. Securely download and install a copy of the new metadata signing certificate.

Actually, the second step is optional (since the new signing certificate contains the same key as the old signing certificate) but it is a recommended practice nonetheless. See the Metadata Consumption wiki page for instructions how to securely obtain a copy of the new metadata signing certificate.

How does this implementation plan affect Shibboleth SP deployments?

Shibboleth SP version 2.0 (or later) supports SHA-2 but whether or not it can deliver that support depends on the version of OpenSSL installed. Since OpenSSL is bundled with the Shibboleth SP software on the Windows platform, SHA-2 support on Windows is guaranteed.

The 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 ASAP (but no later than March 29, 2014).

If you're running the Shibboleth SP software on a non-Windows platform, the software depends on the version of OpenSSL built into the underlying operating system. If Shibboleth is installed on top of an unsupported OS platform, it is likely you are running an old version of OpenSSL that doesn’t support SHA-2. For instance, RHEL 4 was built with OpenSSL version 0.9.7, which is known to be incompatible with SHA-2. In this case, you have no choice but to upgrade to a supported OS platform.

Old versions of OpenSSL are incompatible with SHA-2

If your deployment depends on an old version of the OpenSSL crypto library, it may be unable to verify the signature on the new metadata aggregate. For instance, versions of OpenSSL prior to 0.9.8 are known to be incompatible with SHA-2 and therefore any platform that depends on OpenSSL 0.9.7 (or earlier) will not be able to verify an XML signature that uses a SHA-2 digest algorithm.

Assuming the Shibboleth SP is installed on a system with OpenSSL version 0.9.8 or later, 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 SP’s metadata configuration:

  1. The url XML attribute on the <MetadataProvider> element should point to the HTTP location of the new production metadata aggregate.
  2. Securely download and install a copy of the new metadata signing certificate.

Actually, the second step is optional (since the new signing certificate contains the same key as the old signing certificate) but it is a recommended practice nonetheless. See the Metadata Consumption wiki page for instructions how to securely obtain a copy of the new metadata signing certificate.

How does this implementation plan affect simpleSAMLphp deployments?

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

Old versions of simpleSAMLphp are incompatible with SHA-2

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

If you're running simpleSAMLphp 1.11 (or later), 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 configuration changes you need to make to simpleSAMLphp's metarefresh module:

  1. The src array element should point to the HTTP location of the new production metadata aggregate.
  2. The validateFingerprint array element must reflect the fingerprint of the new signing certificate.

The second step is critical for simpleSAMLphp deployments (despite the fact that the new 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.

How does this implementation plan affect Microsoft AD FS 2.0 deployments?

Microsoft AD FS 2.0 is not able to consume the InCommon metadata aggregate, so the answer depends on the external process used 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 ASAP (but no later than March 29, 2014).

FEMMA 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. See the Metadata Consumption wiki page for more information.

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 pysFEMMA.

How does this implementation plan affect deployments based on commercial products other than Microsoft AD FS 2.0?

AFAIK, no commercial product is able to consume the InCommon metadata aggregate, so the answer is more-or-less the same as it is for Microsoft AD FS 2.0: it depends on the tool chain used to refresh and verify metadata.

  • No labels