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
shibboleth2.xml, and you're done.
If you do need to treat an IdP specially in one of the following ways, read that section:
<Application> element contains a
<DefaultRelyingParty> element with individual
<RelyingParty> configuration inside it. The
Name matches the
entityID of an IdP or a federation.
The SP can refer to itself by a special entityID when talking to this IdP if you add an
entityID attribute to the
<RelyingParty> element. This won't work if a
<SessionInitiator> is used, but it will work with a
<RelyingParty> element to the
<Application> configuration with a new
Name matching the
entityID of an IdP or a federation. Make the
keyName="specialKey" refer to a
<CredentialResolver>. You can also change the default
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.