Morning all,
I've just been reading over the process of upgrading our service offering from Old-and-busted Shib1.3 IdP to a New-Hotness Shib2.x and couldn't quite see the point of the cross-over period where you have your old IdP configured to answer queries on the Shib2 endpoints.
Having read http://www.ukfederation.org.uk/content/Documents/RollingIdPUpgrade and liking the sound of option (b):
{{{
* Install a Shibboleth 2.x IdP.
* Give it the same entityID as the old one.
* Change the federation metadata to refer to the new IdP.
* Fix anything about the new IdP that doesn't work.
This conserves the entityID but has this disadvantage: until the metadata has propagated to a given SP, that SP will not be able to communicate with the new IdP.
}}}
What I don't understand is why, in the overview of the Edina migration, they went to the trouble of configuring the old IdP to listen on the Shib2 endpoints for a while. Could someone enlighten me?
I am assuming, perhaps wrongly, that once the Metadata change request has been pushed out to the XML file, SPs who have updated will be sending users to the new IdP while stragglers will still be using the old one. Are there gotchas with this besides users possibly getting confused? Our AuthN is managed elsewhere so the user barely sees our current IdP page and, I presume, this will be the same on the new one too.
One more question -- the eduPersonTargettedId (the magic salted unique value) -- does the new IdP support the same EntityID+Salt algorithm? We're not currently storing the values that come out of there and are relying on EntityID+Username+Salt not changing (which, at the moment, they won't).
Thanks :-)
--
Matthew Slowe <[log in to unmask]> | Tel: +44 (0)1227 824265
Development Team, Information Services | Fax: +44 (0)1227 824078
University of Kent, Canterbury, Kent | Web: http://www.kent.ac.uk/
|