v2->v3 upgrade, idp-metadata.xml

[Cantor, Scott]

> Hmm, well I suppose I was trying to take this stepwise. Our v2 instance
> used the Unicon shib-cas-authn2 plugin and an external CAS service. It
> looks like there's a shib-cas-authn3 for IdPv3. So I wanted to verify that
> we had a working IdP before tackling that. I don't think the
> shib-cas-authn2 config was carried over as part of the upgrade?

How your IdP authenticates is really the least important piece in getting an upgrade moving, as long as you can cook something up in place that will produce the appropriate usernames. That would let you defer the CAS part until last, which is advisable anyway since authentication is really the one and only significant piece of V3 that's just too different to directly translate from V2.

> Our situation is that we have a production IdP, and test IdP with their
> own entityIds, respectively. They were originally set up this way years
> ago before I knew any better. Now that I'm aware of the recommendation
> that the same entityID should be used for test and production, I'm trying
> to bring up this new test instance so that it uses our prod entityID.

That's fine. Just don't change anything else. Keys and endpoints should all stay the same, and so any existing SP should "just work" (modulo the backchannel).

> I'm now confused as to how to best proceed. Is there a resource that
> covers this methodology on using a hosts file.

Using /etc/hosts is documented many places. I'm telling you to lie to your client so that it contacts your V3 IdP when you are redirected by some SP to the endpoints you have today by remapping that name locally to your new server's IP address.

> I'm afraid I'm also not
> clear on what you mean by "don't name it anything differently".

Don't change the endpoints. Don't change your metadata. Don't try and change what URLs your IdP is supposed to respond on. What it's physically called doesn't matter. Most/many people have all this behind some CNAME alias anyway, either for load balancing or whatever.
 
> Which /etc/hosts file do you mean, the one on the end user's machine?

And you're the end user, yes.

Basically, if you reach a point where you're saying "oh, I need to get the SP to do something", ask on the list and we can explain where you went off course.

Peter's point is correct: you certainly *can* change all this stuff relatively safely if you keep the entityID the same. It works. But it's much harder to test ahead of time without running new SPs yourself, and it means you're running both in parallel for a virtually unbounded period of time.

-- Scott