InCommon metadata support

[Tom Scavo <>]

On Wed, Jan 13, 2016 at 2:26 PM, Kelly, Kyle E 
<>
 wrote:
>
> How difficult is it to
> change the entityID with InCommon when migrating to a new IdP server?

The way to think about this: If you introduce a new entityID, you're
bringing up a completely new IdP. There is no migration to speak of in
that case.

> I was
> recently put in charge of upgrading and migrating to a new server running
> Shibboleth Identity Provider v3. I currently have a working version of
> IdPv3, but the entityID of the new IdP server is different than the
> previous. I am preparing to migrate the InCommon Federation to our new
> server and I’ve noticed that it is recommended to not change the entityID.

I assume you mean this document: https://spaces.internet2.edu/x/GYtHBQ

Depending on where you're at with your "migration," it may still be
possible to use the same entityID as before. If you've already exposed
the new IdP to SP partners, it may be too late.

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

If your software supports SAML2 (which Shib IdP V3 does, of course),
all you have to do is introduce SAML2 endpoints into your published
metadata.

> I am in the process of migrating other service providers to this new IdP
> server. We currently only use one SP (Cayuse) with our InCommon federation.
> Let me know if there is any other information I can provide.

If you have only one SP partner, it doesn't really matter if you
introduce a new entityID since you can easily hand-hold a single
partner.

Tom