Can I provision 2 Apache servers with the same <Extensions>?

[Peter Schober]

* Phil Ehrens <pehrens at ligo.caltech.edu> [2016-03-03 19:52]:
> the new hardware (actually a pair of boxes configured for failover)
> will use the hostname "galaxy".
[...]
> > I'd also re-use the same keys (for SAML) from the old server.
> > Then add endpoints for the new host name to the metadata, essentially
> > duplicating the existing ones, but changing the indexes (which must be
> > unique). So far that matches your orignal request.
> 
> We are doing that, but only because it looked right, not because I
> was sure it was the right thing. Thank you for validating it!

I'm still not sure we're on the same page, but as long as you have
options and ways to move forward, that's fine, of course.

Just to reiterate one difference in the approaches:

If the new servers take over the hostname (and entityID and SAML
"trust fabric" keys) of the old system (which I understand you're
saying now) then there's nothing to change wrt Shibboleth and SAML at
all. I outlined before how you would test SAML with the new system
before it moves into its intended place, using a local resolver hack.
(That's the "avoiding change" approach, if you will.)

One /alternative/ to doing that is creating a seperate system on a
seperate hostname (with seperate TLS keys) but keeping the entityID
(and SAML "trust fabric" keys) from the old system, plus duplicating
the published (to IDPs) protocol endpoints, so that the entityID can
be used with boths sets of endpoints at the same time.
(That's the "rolling changes" approach, if you will, as you'll change
the endpoints that IDPs will have to use, but you make that a rolling
change by introducing new endpoints and removing old ones later.
That approach of course assumes IDPs can pull from metadata and change
their settings for this SP automatically, and that they can handle
multiple endpoints for the same binding, which not all implementations
mightbe able to, cough, MS-ADFS, cough.)

To be avoding (visible, to others) changes beat rolling changes, easily.

Those are quite different approaches, and both beat the worst-case
scenario of assigning the new system a new hostname plus a new
entityID, making it a completely different system in all respects,
esp. to IDPs which likely would have to configure attribute release
again for that "other" system.

Anyway, good luck with your system migration project.
-peter