Page tree

The Shibboleth 2.x software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP30 and SP3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 do need to treat an IdP specially in one of the following ways, read that section:

Different entityID

The <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 WAYF style <SessionInitiator> is used, but it will work with a DS.

Different cryptography

Add 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 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.

  • No labels