Using shibboleth to create SP metadata file on development server machine

[Peter Schober]

Arthur,
I think you're making this a lot more complicated than it needs to be.
Other than the entityID values (which you configure with whatever name
you want the system to have, on whatever server/system you want) the
SP software doesn't even need to know anything about the host name it
runs on or it should answer with. At least assuming Apache httpd this
is all configured with httpd's ServerName directive (which in turn
again can be set to anything you want and is fully independent of the
physical maschine name or any DNS records).

I.e., configure the non-prod system to be identical to prod except for
the IP address (d'oh) and test with the hosts-file override (as you're
doing). When things work that way they work.
Then migrate prod's IP address to the non-prod system (my preferred
method because you don't even have to change DNS then, which also
means you can switch back in a second when something went wrong) or
change DNS to let the prod name point the until-now-non-prod system's
IP address. Done. I'm probabably missing something?

As for "using shibboleth to create an SP metadata file": SAML 2.0
Metadata is XML so it's just text, plain or not so plain. And the prod
and non-prod systems should only differ in a few key points:
* Their name (entityID)
* Their key(s)
* Their protocol endpoint URLs (esp. AssertionConsumerService)

So besides getting metadata from the SP's metadata generation endpoint
you might as well just change the few key my hand to be what it needs
to be. *But* *why* there would be anymetadata changes required at all?
The then-prod system (now non-prod, AFAIU) would then still be called
the way the now-prod system is (prod's current entityID).
I.e., your aim should be to make whatever changes to switch services
and servers but the metadata describing the SP should remain unchanged.
(At least I'm not seeing any reason in your post why the SP should
appear any different to a SAML IDP after the system change.)

-peter

* Goldberg, Arthur P via users <users at shibboleth.net> [2022-08-03 17:28]:
> I am upgrading the software on a production system. Two software installations and machines are involved: release 1 of x running on VM prod at x.mssm.edu, and release 2 of x running on VM dev at dev.mssm.edu.
> 
> On Tues Aug 9 we plan DNS changes which will map VM dev’s IP addresses to x.mssm.edu (and map VM prod’s IP addresses to another domain name). Before then, I need to configure and test release 2 of x running on a machine with domain name x.mssm.edu. I’m doing this by altering my local /etc/hosts file to map the IP address of VM dev to x.mssm.edu.
> 
> To configure release 2 of x on VM dev to run at x.mssm.edu we need to configure a new SAML single sign-on that connects x on VM dev running at x.mssm.edu to the SAML IdP in our Azure Active Directory service.
> 
> To configure that I’m using shibboleth to create an SP metadata file for release 2 of x on VM dev running at x.mssm.edu. I’m doing that by running release 2 of x with its web server configured to run at x.mssm.edu and accessing https://x.mssm.edu/Shibboleth.sso/Metadata in my browser to create and download a metadata description of the SP. However, this metadata file has an entityID in the EntityDescriptor that uses the dev.mssm.edu domain name for VM dev which is running release 2 of x. (All other domain names in the metadata file are x.mssm.edu.) I’m concerned that this entityID will be treated as a fatal metadata error when VM dev is at x.mssm.edu.
> 
> Do you have a recommended approach for handling this situation? Only one idea comes to mind: Alter the /etc/hosts file on VM dev to map its IP address to x.mssm.edu and then create the SP metadata file.