IdPv3 entityID & SAML 2.0 Questions

[Kelly, Kyle E]

I am new to shibboleth so I am slightly confused by this process. When considering what needed to be done I thought a new server was the better option. We need to upgrade the OS as we are on RedHat 5 with our current IdP and don't typically do in place upgrades for operating systems. We would also prefer to upgrade the version of Tomcat that we are running. If I must do an in place upgrade, how would I go about migrating to newer hardware? Am I married to the hardware we are currently on?

Thanks,

Kyle Kelly
System Software Specialist
Information Technology Services
The University of South Dakota
Vermillion, SD  57069


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, January 21, 2016 9:29 AM
To: Shib Users <users at shibboleth.net>
Subject: USDSPAMALERT: RE: IdPv3 entityID & SAML 2.0 Questions
Importance: Low

> 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

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net