Page History

...

If you are still running Shibboleth IdP V2, now is the time to start you should be actively planning your upgrade path to Shibboleth IdP V3 or alternative solutions. In preparation for an upgrade, IdP operators in the InCommon Federation should download and install a pre-production instance of Shibboleth IdP V3 as soon as possible.

At any given time, the appropriate version to use will vary but will always be the latest version available from the project.

A Your test deployment of Shibboleth IdP V3 should mimic your production deployment of V2. Be sure to point your test IdP at the InCommon Preview Aggregate, one of three Metadata Aggregates in the metadata pipeline.

...

Know who your SP partners are. In particular, know which SP partners automatically refresh metadata and which don't. SPs that do not automatically refresh metadata make your job more difficult. If you don't know about a partner, it's likely they're relying on your published metadata and so they won't present a significant problem to your migration anyway. It's usually the partners that for which you had to manually load metadata yourself that need special care.

...

The basic strategy is quite simple: Use production metadata for testing purposes. In particular, do not introduce a second entity descriptor into InCommon metadata. Such an entity descriptor can not cannot have the same entityID as your production IdP, so by definition that entity descriptor describes a completely new IdP. You generally can't test your existing relationships and integrations with a new IdP. Indeed, you don't want a new IdP, you want to upgrade the one you have.

Install Shib IdP V3 on a new physical host (or virtual machine) using the same web path as your production IdP (assuming that path is not going to change). This will allow you to configure Shib IdP V3 to have the same protocol endpoints as your production IdP once your upgrade is complete.

Generally speaking, configure the new V3 instance to be identical to your production IdP (same entityID, same SAML signing key and certificate, same endpoints, same metadata sources, same attribute release policy rules, etc.). The two systems should be identical in every wayin every way.

In most cases, this is best accomplished by copying your old configuration to the new host as though you were deploying V2 there, and then using the IdP's upgrade support to install the new version on top of the old. This will maintain files that can be maintained to the greatest extent practical.

...

If you are unable to use the production signing key and certificate on the test system, then you'll have to generate a new signing key for testing purposes. ( The Shibboleth install (but not upgrade) process will do this for you automatically. ) This new signing key must be kept no less secure than your production signing key. The certificate corresponding to this new signing key may be added to the IdP's entity descriptor in metadata so that there are two certificates in metadata, one for the production IdP and one for the test IdP. See the FAQ below for more info.

Endpoints in Metadata

All browser-facing endpoints in IdP metadata are non-indexednon-indexed (this is a SAML term, but it simply means that more than one of the exact same type and character can't be used). Consequently, there may be at most one SingleSignOnService endpoint per HTTP binding. (The same is true of SingleLogoutService endpoints.) At best, adding a second browser-facing endpoint with a redundant binding to metadata serves no purpose.

Changing an endpoint in metadata is even more problematic. While it is possible to migrate to new endpoint locations (see the FAQ below), it is not something to be taken lightly. Depending on your SP partners, it may take months to safely perform such a migration, much like changing a key. It is best to avoid that pain.

...

Assuming your test IdP and your production IdP share the same path (on different hosts), your best testing strategy is to map the DNS name of the production IdP to the IP address of the test IdP using /etc/hosts on a client/browser machine. Using either SP-initiated or IdP-initiated SSO, systematically test selected partner SPs using the client machine. If the entityID and the signing credentials are both unchanged, any problems that occur are a sign of configuration differences that can be investigated and fixed before the cutover occurs.

...

In general, if your SAML signing key is compromised, you should immediately generate a new key pair and introduce the resulting signing certificate into metadata. Yes, this will cause an outage but that's what happens inevitable when your signing key is compromised. Consequently, you should protect your signing key at all costs.

...

Implementations of eduPersonTargetedID by the Shibboleth software are either stored in a database or computed on the fly. If your IdP supports a computed version of eduPersonTargetedID, either use the documented upgrade process, or don't forget to migrate the secret salt to the V3 platform. Failure to do so will cause different values of eduPersonTargetedID to be generated, which will break interoperability with SP partners.

...

SAML2 Persistent NameID is equivalent an alternative syntax to the eduPersonTargetedID SAML Attribute, so the question is the same in both cases: Is it stored or computed? If it's computed, you must upgrade properly, or migrate the secret salt, to maintain interoperability.

...

No, as long as you don't change your IdP entityID, the Research & Scholarship (R&S) entity attribute will remain in your metadata. You should use the upgrade process, or faithfully reproduce the relevant attribute release policy rules in Shib IdP V3 of course, but beyond that there is nothing further you need to do.

...