Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Tip
titleKeys and Certificates
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!

Endpoints in Metadata

...

All browser-facing endpoints in IdP metadata are non-indexed. 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. It is best to avoid that pain.

Info
titleUse Your Production IdP Endpoints for Testing

Install the Shibboleth IdP V3 software on a new vhost but make sure the web application path is exactly the same as your production IdP. Do not change the endpoint locations in production metadata.

You are now ready to begin testing.

Testing Strategy

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

Tip
titleAvoid back-channel protocols

Except for the back channel, you can fully simulate real transactions against real SPs through simple manipulation of client /etc/hosts files. Back-channel protocols, such as artifact resolution and attribute query, are much more difficult to test. This is one reason why an IdP deployment strategy that forces all protocol traffic over the front channel is highly desirable. Avoid back-channel protocols if you can.

...