v2->v3 upgrade, idp-metadata.xml

[Baron Fujimoto]

On Thu, Jul 07, 2016 at 01:07:31AM +0000, Cantor, Scott wrote:
>
>> 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.

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?

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

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

I'm now confused as to how to best proceed. Is there a resource that
covers this methodology on using a hosts file. 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.
Which /etc/hosts file do you mean, the one on the end user's machine? What
exactly is remapped there?

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

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

Ok, so I guess that rules that out, though now I'm stumped.

-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum