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

« Previous Version 2 Next »

The SP supports various profiles during which it will generate and send messages to other systems, and there are settings to control the use of digital signatures, encryption, and how they interact with the use of TLS in SOAP exchanges.

Relative to an IdP, there are fewer scenarios in which it typically becomes necessary to worry about these settings. Usually you can accept the defaults and things will work most of the time. The settings are provided for handling more unusual situations.

Version 2.6+


Version 2.5 and Earlier

Prior to Version 2.6, the signing and encryption settings can be used in the <ApplicationDefaults><ApplicationOverride>, and <RelyingParty> elements and allow for per-application, per-IdP behavior.

The four possible values are:

  • true
  • false
  • front
  • back

and the default setting is false.

The "true" and "false" settings obviously explicitly turn signing and encryption on or off unilaterally. The "front" and "back" settings explicitly turn them on based on whether the message is being sent through the client or directly to the peer. The "front channel" applies to cases like Browser SSO requests, while the "back channel" applies to queries. Logout can happen over either channel.


Failure while signing or encrypting is usually handled differently. When signing fails, it's common for the message to be sent unsigned. When encryption fails, the message isn't sent. The most common source of failure in either case is the inability to locate a key, but in the case of encryption, that key beongs to the peer, and is generally obtained from SAML metadata.

Transport Authentication

An additional setting (requireTransportAuth) exists to control whether to allow for a back-channel peer to authenticate itself to the SP using a message signature, or whether the TLS connection must be authenticated. It defaults to "true", requiring the server's TLS certificate to be trusted (generally through metadata). Prior to V2.6, this setting has to be explicitly turned off to allow for signature-based communication in both directions, which is the main reason why the back channel has traditionally only worked when a separate port and certificate are deployed by the peer.

  • No labels