IdPv3 entityID & SAML 2.0 Questions

[Kelly, Kyle E]

This makes more sense. I have been copying the version 2 config to my new server and making hostname changes in the conf files. I will set it up as if it has the same hostname and perform the DNS change at the time of the switch over. 

Would it be best to start by installing IdPv2 on the new server or can I just copy to contents of "/opt/shibboleth-idp" from my current IdP server?

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 10:39 AM
To: Shib Users <users at shibboleth.net>
Subject: USDSPAMALERT: RE: IdPv3 entityID & SAML 2.0 Questions
Importance: Low

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

A new server isn't the point, the issue is how you do the switch.

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

How would you upgrade other software? You wouldn't change the location of your LDAP service, you'd test the new system and then change DNS to point to it.

Same thing here. The new system should be completely interchangeable with the old system, and can be tested using /etc/hosts *with the exception of the backchannel*. That's more a function of understanding the issues, what can break, and utimately taking the leap.

It is not tenable to do what you're doing. You cannot change an entityID or key without effectively starting from scratch, and your upgrade will take months. The SAML 2 migration is much more like that. You are effectively making a change that impacts, and may require changes by, other organizations. That can't be rushed. It's very different from a functionally equivalent swap to new software.

-- Scott

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