Specialized Relying Party Configurations

If you are trying to communicate with a new service provider you are probably in the wrong place, you want to be here.

Before attempting to change relying party configurations be sure you understand the concept of a relying party. Also, note, changing these configuration is an intermediate-level configuration task, is not generally needed in most deployments, and should only by done by deployers with a good understanding of how shibboleth and federated identity management works.

Configuring a Relying Party

The configuration for communicating with relying parties is located in $IDP_HOME/conf/relying-party.xml.

The <AnonymousRelyingParty> and <DefaultRelyingParty> elements requires the following attribute:

provider - the entity ID used by the IdP when responding to this relying party

The <RelyingParty> element requires the following attributes:

id - URI of the entity or group to which this configuration applies
provider - the entity ID used by the IdP when responding to this relying party

All three elements support the following, optional, attributes:

defaultAuthenticationMethod - the authentication method to use for this relying party if it does not request a specific method
defaultSigningCredentialRef - the ID of the credential to use when signing if a specific credential is not identified on the communication profile
nameIDFormatPrecedence - A space delimited, ordered list of name identifier formats. See IdP Name Identifier Selection Process (bottom of page) for how this information is used.

Profile Configuration

Each type of relying party element may have zero or more configured communication profiles. A relying party which attempts to communicate with the IdP using a profile that is not configured is returned an error indicating that the communication is not allowed.

Each profile configuration is identified by a <ProfileConfiguration> element and is a child of the relying party configuration element. The following profile configurations are currently supported:

Shibboleth SSO - Configures the relying party for Shibboleth SSO support: this is the SSO profile used by Shibboleth 1.X
SAML 1 Artifact Resolution - Configures the relying part for SAML 1 Artifact Resolution support
SAML 1 Attribute Query - Configures the relying party for SAML 1 Attribute Query support
SAML 2 SSO - Configures the relying party for SAML 2 SSO support
SAML 2 ECP - Configures the relying party for SAML 2 ECP support
SAML 2 Artifact Resolution - Configures the relying part for SAML 2 Artifact Resolution support.
SAML 2 Attribute Query - Configures the relying party for SAML 2 Attribute Query support
SAML 2 Logout - (V2.4.0+) Configures the relying party for limited support for SAML 2 Logout support

Each profile configuration can also take an optional securityPolicyRef attribute identifying a custom/overridden set of policy rules defined later in the file. This is rarely needed, but allows for per-RP customization of security policy rules.

Example Relying Party Configurations

The following example enables the SAML 1 and SAML 2 profiles for default relying parties.

<DefaultRelyingParty provider="urn:example.org:idp1">
   <ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" />
   <ProfileConfiguration xsi:type="saml:SAML1AttributeQueryProfile" />
   <ProfileConfiguration xsi:type="saml:SAML1ArtifactResolutionProfile" />
   <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" />
   <ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" />
   <ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile" />
</DefaultRelyingParty>

The following example disables communication with any anonymous relying party.

<AnonymousRelyingParty provider="urn:example.org:idp1" />

The following example disables all SAML 1 profiles and SAML 2 artifact support and sets a default authentication mechanism for a specified relying party (or relying party group).

<RelyingParty id="urn:example.org"
              provider="urn:example.org:idp1"
              defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
   <ProfileConfiguration xsi:type="saml:SAML2SSOProfile" />
   <ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" />
</RelyingParty>