Add Additional Servers to Metadata
A single SAML entityID can be used for many different servers, both physical and virtual. The Shibboleth SP requires that each virtual host have its own SAML endpoints listed in the metadata.
If you've followed the instructions on Creating a Metadata File for your Shibboleth SP, you've pulled the autogenerated metadata from your server as a starting point. You can use the same technique to get the endpoints for additional virtual hosts (just use the new hostname instead of the first), or you can just copy and paste the existing URLs and update them to point at the new host.
Endpoints are the URLs that Shibboleth uses to tell the browser where to go to perform some function, such as logging in to an IdP, providing login information to an SP, or requesting logout. They are listed in metadata with element names like AssertionConsumerService, SSOLoginService, or ArtifactResolutionService.
The most important endpoint for an SP is the AssertionConsumerService, which tells the IdP where to send the browser to provide the authentication and attribute assertions about the user's login. There may be a number of ACS elements in an SP's metadata if it supports a number of bindings (e.g. multiple versions of the SAML protocol). The usual binding is the SAML 2.0 HTTP POST binding, which can be identified in the metadata file as:
This is the crucial element that needs to be added for each new server you want to support in your metadata.
So, suppose you have metadata that contains a line like this:
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.umn.edu/Shibboleth.sso/SAML2/POST" index="0"/>
If you wanted to add a new vhost for www.altname.umn.edu to this metadata, you'd add an additional element:
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.altname.umn.edu/Shibboleth.sso/SAML2/POST" index="1"/>
The Location has been updated with the new virtual host name. The index has also been updated so it remains unique within the entity. If you are only using the UMN IdP, you don't really need to worry about the index values, as they are not used. For completeness, you should also add the other types of endpoints and bindings as well, updating the Location and index fields.
You should add new endpoints alongside the existing endpoints. The order of the endpoints doesn't matter, but they need to be in the same section of the metadata file (inside the SSODescriptor element, after the KeyDescriptor element).
Once you've got all your new endpoints included, send the updated file to firstname.lastname@example.org and ask us to replace your existing metadata. After it has been updated on the IdP, you can try it out and verify that it works.