Configure an SP to use multiple Relying Parties

There are generally few steps required to allow an SP to interact with multiple relying parties. The amount of modification necessary depends on how much will vary in the treatment of each provider.

In the base case, everything is the same, and the introduction of a new IdP to the metadata an SP uses will allow the SP to automatically receive and trust assertions from that IdP. If some aspect of the SP's behavior will need to change, please read the relevant section.

Different providerId's

It's difficult to configure an SP to use multiple providerId's for the same resource. This is because the SP potentially doesn't know which IdP it will be interacting with before the initial authentication response arrives, so it has no way to select the right providerId in the outbound authentication request.

This means the only way to use multiple providerId's is to give the SP some other information to key providerId selection on. In practice, this is best done using different URL trees. Each URL tree can be assigned a different <Application> and you can stick the right providerId on that <Application> element. Then, you need to make sure the users are accessing the right URL tree as well. That can be particularly challenging.

Avoid using multiple providerId's for a single application if possible. Given that the providerId and application are the primary unit of policy, this should be feasible in most circumstances.

Different Credentials

The default credentials an SP will use are referenced by the <CredentialUse> element's attributes. If you want to use different credentials for a particular relying party, add a <RelyingParty> element such as the following:

<CredentialUse TLS="sp.testshib.org" Signing="sp.testshib.org">
    <RelyingParty Name="https://idp.example.org/shibboleth" TLS="examplekey" Signing="examplekey"/>
</CredentialUse>

The default key/cert pair is sp.testshib.org, but when dealing with idp.example.org, different credentials will be used. These each match additional <FileResolver> or <KeyResolver> elements.

<CredentialsProvider type="edu.internet2.middleware.shibboleth.common.Credentials">
    <Credentials xmlns="urn:mace:shibboleth:credentials:1.0">
        <FileResolver Id="sp.testshib.org">
            <Key>
                <Path>/etc/shibboleth/testshib.key</Path>
            </Key>
            <Certificate>
                <Path>/etc/shibboleth/testshib.crt</Path>
            </Certificate>
        </FileResolver>
        <FileResolver Id="examplekey">
            <Key>
                <Path>/etc/shibboleth/sp-example.key</Path>
            </Key>
            <Certificate>
                <Path>/etc/shibboleth/sp-example.crt</Path>
            </Certificate>
        </FileResolver>
    </Credentials>
</CredentialsProvider>

Different Metadata

Simply add multiple <MetadataProvider> elements to load each metadata file. If you want a particular provider to only be trusted by a specific <Application>, add the <MetadataProvider> there rather than to the main <Applications> element.

<MetadataProvider
    type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
    uri="/etc/shibboleth/example-metadata.xml"/>

Different Attribute Acceptance

If your AAP doesn't use specialized <SiteRule> instructions, then your new relying party's attributes will be treated like any other provider you interact with. However, if you need specialized instructions, use the <SiteRule> configuration.

Browser not supported