...
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.
It's also possible in more unusual cases to set them in the <SSO>, <Logout>, and <NameIDMgmt> elements, allowing for per-protocol behavior. They can also be set in advanced configurations that define individual <SessionInitiator>, <LogoutInitiator>, <md:AssertionConsumerService>, and <md:SingleLogoutService>endpoints. In these cases, they override any values set by application or IdP.
The five possible values are:
conditionaltruefalsefrontback
The default value is usually conditional but is somewhat context-dependent, and defaults to false false (with a caveat) for 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, that metadata flag will typically cause the SP to sign if it can do so.
...
As an example, a SOAP message to https://idp.example.com:8443/idp/profile/SAML/SOAP/AttributeQuery will not be signed, nor its content encrypted, while the same message sent to https://idp.example.com/idp/profile/SAML/SOAP/AttributeQuery will be signed and its content encrypted.
...