...
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.
| Table of Contents |
|---|
Controlling Signing and Encryption
The signing and encryption settings are typically set in the <ApplicationDefaults>, <ApplicationOverride>, and <RelyingParty> elements and allow for per-application, per-IdP behavior.
...
The default value is usually conditional but is somewhat context-dependent, and defaults to false (with a caveat) for SAML 2.0 SSO initiation. The caveat with SAML 2.0 authentication is that omitting the setting defaults to a softer false that really means "don't sign unless the IdP's metadata includes the WantAuthnRequestsSigned flag and the SP can do so". Unless explicitly disabled, the that metadata flag will typically cause the SP to sign if it can do so.
...
The "true" and "false" settings 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, but is usually front-channel.
The "conditional" setting is a new tool to allow allows for more automated decision-making based on the profile/protocol, channel, and characteristics of the communication path. Generally, conditional implies "true" for front-channel messages except for SSO, and it implies "false" for back-channel messages unless the back-channel endpoint does not support TLS or runs on the default TLS port.
...
The intent of this algorithm is to effect an automatic transition to use of message signing and encryption when back-channel communication takes place over the default TLS port, eliminating the need for browser-facing ports to support client TLS, making IdP setup and load balancing simpler. The algorithm can always be overridden in individual situations, but the default behavior automates a general move from an older paradigm to a newer one with hopefully little work by deployers apart from simply maintaining current software.
This approach mirrors a similar algorithm used by the Shibboleth V3 IdP software, though SOAP communication from it is much more rare.
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 unless the encryption was triggered through the use of the "conditional" setting. The most common source of failure in either case is the inability to locate a key, but in the case of encryption, that key belongs to the peer, and is generally obtained from SAML metadata.
The rationale behind proceeding in a conditional encryption case is that ultimately the data encrypted belongs to the peer, and if it can't be bothered to support encryption, then it doesn't get encryption.
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 "conditional", requiring the server's TLS certificate to be trusted (generally through metadata) in the cases in which signing and encryption would not be used by default.
...