Talk to a new IdP
The amount of configuration the SP needs to talk to a new IdP depends on how much special treatment that IdP will require compared to your defaults. The base case is very simple: add the IdP's metadata to a metadata file referenced by a <MetadataProvider> from shibboleth2.xml, and you're done.
If you're using a single IdP, then you need to ensure its entityID is set in the <SSO> element to route requests to it.
If you do need to treat an IdP specially in one of the following ways, read that section:
Different entityID
Add a <RelyingParty> element to the <Application> configuration with a new Name matching the entityID of the IdP or a federation. The SP will name itself by a specified entityID attribute when it talks to the relying party Name.
This won't work if a legacy WAYF discovery approach is used, but it will work with a modern DS.
Different cryptography
Add a <RelyingParty> element to the <Application> configuration with a new Name matching the entityID of the IdP or a federation. Make the keyName="specialKey" refer to a <CredentialResolver>. You can also change the default encryption and signing settings, or the use of TLS to authenticate to other providers, but this is rarely required.
Special Attribute Rules
To enact special attribute rules for a this IdP, add specific rules to attribute-policy.xml. No <RelyingParty> settings are necessary.