...
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 way.
| Tipwarning | ||
|---|---|---|
| ||
If your IdP supports a computed version of eduPersonTargetedID, don't forget to migrate the secret salt to the new V3 platform. Failure to do so will cause different values of eduPersonTargetedID to be generated, which will break interoperability with SP partners. See the FAQ below for more info. |
Entity ID in Metadata
The most important piece of advice we can give is: do not introduce a new entityID.
...
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 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.
| Tip | ||
|---|---|---|
| ||
| Read the Security and Networking topic in the Shibboleth wiki, especially the section on "Keys and Certificates." The Shibboleth IdP installer will generate three pairs of keys and certificates for you automatically but if you copy your production signing key and certificate to the test machine (which is highly RECOMMENDED), you won't need any of them! |
...