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

Compare with Current View Page History

« Previous Version 4 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

How does this implementation plan affect Shibboleth IdP deployments?

Shibboleth IdP deployments in the InCommon Federation are least affected by this implementation plan. If you are running a supported version of the Shibboleth IdP, you can migrate to the new metadata aggregate at your convenience (but no later than [date TBD]). 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 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 recommended 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?

Unlike the IdP, some Shibboleth SP deployments will have difficulty migrating to the new metadata aggregate. This is because the Shibboleth SP relies on whatever version of OpenSSL is 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 dependent upon 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 metadata aggregate at your convenience (but no later than [date TBD]). 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 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 recommended 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 this fingerprint must be updated to successfully migrate simpleSAMLphp to the new metadata aggregate.

It is not known if simpleSAMLphp can verify an XML signature based on a SHA-2 digest algorithm.

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, so 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 metadata aggregate ASAP (but no later than [date TBD]).

A smart extension of 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