Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The basic unit for defining the other half of exchanges with the ! IdP is the relying party. A relying party can be comprised of an entire federation, a single enterprise, or even one application, and is treated the same way by the identity provider. Any specifications made regarding a relying party will be applied for all transactions to which it applies on a closest-match basis. This allows for more specific definitions for individual relying parties within a broader relying party, e.g. one service provider in a federation.

The RelyingParty element is used to specify one or more relying parties that this ! IdP must recognize. This includes any federations the ! IdP is a member of, any SP's that have established bilateral agreements with the ! IdP, or any other trust structure that ! IdP must be aware of. It allows the ! IdP to vary its use of names and credentials on a transactional basis to accommodate different relying parties.

The ! IdP performs validation against federation metadata to ensure that a particular relying party cannot construct requests that cause another SP's relying party information to be used.

...

Federations are collections of ! IdP's and SP's that agree to exchange information according to a set of rules with a list of acceptible root certificate authorities, often utilizing a common set of attributes. Membership in a federation does not limit bi-lateral agreements with other sites inside or outside the federation, although the political and mechanical framework of the federation can make these interactions easier.

...

This configuration element supplies metadata to the ! IdP to identify relying parties in transactions. It may appear as many times as necessary.

...

Additionally, it is frequently necessary to define differential use of credentials or other behaviour using RelyingParty elements. The use of different name types is the most critical change, but other changes may be made. These can be used to point to all members the entire federation by using the federation's URI: for example,

Code Block
&lt;RelyingParty<RelyingParty name=&quot;"urn:mace:inqueue&quot;" signingCredential=&quot;foo&quot;&gt;
	&lt;NameID"foo">
	<NameID nameMapping=&quot;crypto&quot;/&gt;
&lt;/RelyingParty&gt;"crypto"/>
</RelyingParty>

These settings may be over-ridden on an individual site basis. The closest match for any given URI is used.

...