IdPv3 entityID & SAML 2.0 Questions

[Cantor, Scott]

> I am in the beginning stages of migrating from IdPv2 to IdPv3. I have already
> installed and configured a functioning IdP version 3 server and have migrated
> Google Apps authentication to this server.

That's already a problem. You've created a second IdP instead of upgrading the original one and now you have a problem. What you should do is stop, move Google Apps back to the old one, and upgrade in place by emulating the old server, same entityID, same keys, etc. Plan for a switch all at once, and test in the interim using /etc/hosts changes. You can do that with a high degree of confidence that the tested system will work.

> 1.       How would I go about configuring the new IdP server with same
> entityID of our current IdPv2 server?

The entityID is a property in idp.properties. You may be overthinking that step.

> 2.       How do I verify that my SAML protocol endpoints have not changed?

The default endpoints (the paths) are identical in V3 and V2. The hostname should not change, you should change DNS when you go live.

> 3.       How do I ensure that the new metadata will support SAML 2.0? I
> believe our current InCommon federation is one of a handful that does not
> support SAML 2.0.

Then you have much more work to do, but I wouldn't combine these moves. Moving from SAML 1 to 2 is a major change that can break services if those services are themselves misconfigured. I would maintain your InCommon presence as SAML 1 only while you get the software upgraded, and only after you have the upgrade done, plan for the SAML 2 migration as a discrete activity.

-- Scott