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+
TBD
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:
truefalsefrontback
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.
Failures
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.