v2->v3 upgrade, idp-metadata.xml

[Cantor, Scott]

> I'm able to successfully load the status servlet both via a browser and
> using the status script. The AllowedIPs parameter wasn't automatically
> carried over from the Status servlet in the v2.conf/web.xml into its
> equivalent in v3's access-control.xml's allowedRanges. Perhaps this might
> be noted as a post-upgrade task as well?

Done.

> Before moving on to configuring an external CAS authentication (we'll
> get around to transitioning to the native CAS later), I wanted to
> verify the upgrade with testshib.org. I'm running into problems with
> our metadata though. Testshib rejects it as invalid.

Anybody upgrading their IdP is long past the point where testshib should be involved. Just run an SP or better, use any of your existing ones. If you can't immediately interoperate with real, working SPs, then your upgrade is already off track because you changed something you didn't need to change.

> This is presumably the result of the way I pursued this upgrade, where I
> copied an existing deployment to a new host and upgraded that. This meant
> I had the metadata from the original host. I edited the copied metadata
> to reflect the new hostname in the SSO endpoints.

You can use any host you want. Just don't name it anything differently, change your /etc/hosts file and go to town with it.

> I also took the
> opportunity to follow recommendations to use the same entityID in our
> test and production environments, and thus updated the entityID as well.

Not changing the entityID ever is much more important than any other consideration but you also don't buy very much by leaving the entityID and changing the endpoints or keys either. If you change any of them, you're turning a relatively simple process into a huge undertaking that is basically impossible to test effectively. You've created a new IdP, basically, and you have to now touch potentially every non-Shibboleth/SSP SP you deal with.

> Testshib is not specific as to why the metadata is invalid, but I'm
> supposing it may be due to a mismatch in the x509 certificates?

No, can't be.

-- Scott