Shibboleth SP migration plan

[Peter Schober]

* MikeWho <who at me.com> [2015-01-22 17:54]:
> - Install Shibboleth SP (planning on staying on 2.5.3 to minimise change
> risk, not sure if v3 is a better choice. Installing on IIS8 on Windows
> Server 2012, I've only previously installed on IIS6 so there may be some
> issues there.)

There is no SPv3, jfyi. You're confusing this with the all new IDPv3.

> - Copy shibboleth2.xml from current instance (updating site IDs in InProcess
> section is the only required change I'm aware of).
> - Copy sp-key.pem and sp-cert.pem from current instance (this I'm not sure
> about. Can these files - generated with keygen.bat - just be transferred
> from one server to another? If we need to regenerate these, it means a
> re-integration with the IdPs)

Yes, you will need to copy those over, too! Lacking those your SP will
fail to decrypt any encrypted SAML assertions, and yes, you'd have to
redistribute changed metadata (or the changed public key) to all IDPs
and/or federations. Not something you'd do unless you conciously chose
to do that for sensible reasons.

> - Copy attribute map files, IdP metadata files, and edited html templates
> (we've changed nothing else) from current instances.
> 
> Then update the DNS entries for the sites to point to the new data-centre
> addresses and that should be it. Does this look ok? Anything obvious I'm
> missing?

If you're OK with some still connecting to the old site, and some to
the new site (and any inconsistencies that may arise from changing
data at two different sites), then yes.
DNS changes may take time to progagate and even if you set the TTL
very low well in advance some sites may cache old records longer than
they should. Those would keep sending requests to the old IP address.

> For testing, I'm hoping I can just edit a local hosts file on a test
> machine, to point the site/SP domain names to the new datacentre addresses.
> >From what I've read, the IdP doesn't normally communicate directly with the
> SP (is that for Artefact binding? - which we don't use), so hopefully that
> let's us test the new setup in advance of the DNS changeover.

Attribute Queries would also happen between the IDP and SP directly.
If you have SAML1 only IDPs that do not push attributes unencrypted
over the browser (which is a choice they could make) you'll have to
deal with those, too.
And the DNS resolver for the back-channel communication (i.e., at the
IDP) may not be in sync with the DNS resolver the subject uses,
meaning SSO will go to one site (old, or new) and attribute queries
may go to the other (new, or old).

Moving the IP address over would avoid that, but depending on the
address type that's not commonly possible.
-peter