v2->v3 upgrade, idp-metadata.xml

[Tom Scavo]

On Thu, Jul 7, 2016 at 12:06 AM, Baron Fujimoto <baron at hawaii.edu> wrote:
> On Thu, Jul 07, 2016 at 01:07:31AM +0000, Cantor, Scott wrote:
>>
>>> 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.
>
> 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. I'm
> not trying to introduce a new entityID into the world, just consolidate
> them to conform to best practices. Or is this already a violation of that
> precept?

I think its well worth your effort to align your production and test
IdPs. Before the cutover, the goal is sync test (V3) with production
(V2) as closely as possible (same entityID, same key and certificate,
same metadata sources, same attribute release policy rules, etc.). As
Scott said, this will allow you to test all but your back-channel
endpoints.

After the cutover, abandon the V2 instance and clone the V3 instance.
The latter becomes your leading edge test system. Heck, you can even
configure it for per-entity metadata in the interim.

> The set of SP's that specifically use our test env is pretty
> small, and generally they don't go back to it once their configuration is
> blessed and deployed to production.

Sure, that's okay as long you don't introduce test IdP metadata into
the federation aggregate. If an SP wants to test that way, it needs to
consume test metadata out of band. (Unfortunately, that's all many SPs
are able to do anyway.)

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

The best resources I know of are:

https://spaces.internet2.edu/x/GYtHBQ
https://wiki.shibboleth.net/confluence/x/iwAUAQ

Beyond that, keep sending questions to this list, I guess.

> I'm afraid I'm also not
> clear on what you mean by "don't name it anything differently". Are you
> referring to the hostname of the host with the upgraded idp? In our case,
> it is actually a different host since I copied an existing deployment to
> a new host for this purpose. I didn't upgrade an old v2 host in situ.

That's fine. I believe most upgrades are occurring this way. Create a
new server, with a new IP address and a new DNS name. The latter is
optional but if you intend to pull in SPs for testing, you will
probably need a new DNS name. This will appear in the test metadata
you share with them out of band.

> Which /etc/hosts file do you mean, the one on the end user's machine?

Yes. YOUR laptop.

> What exactly is remapped there?

The production server name is mapped to the IP address of the test system.

> My original plan was to point some SP (e.g. testshib, and subsequently our
> Google test env) at the newly upgraded test IdPv3.

I agree with Scott, this isn't very useful. With the /etc/hosts trick,
you can test your production SP partners with impunity. They won't
know the difference.

Tom