File(s): conf/relying-party.xml
Format: Native Spring
Overview
The SAML2.Logout profile configuration bean enables support for the SAML 2.0 Single Logout profile.
For detailed information on the use of this profile, see LogoutConfiguration.
Configuration
The most typical options used are described in more detail below, but not every obscure option is discussed. See the javadoc for all of the possible configuration options for this profile (note that many of them are inherited from parent classes).
Virtually all the configuration options below can be set via two different properties: a static property that explicitly sets the value to use and a lookup strategy or predicate property that takes a Function or Predicate and returns the value to use. The dynamic property is generally named "propertyNamePredicate" or "propertyNameLookupStrategy" for Boolean- and non-Boolean-valued properties respectively.
The examples shown are not specific to any particular profile configuration.
Options common to most/all profiles:
Name | Type | Default | Description |
|---|---|---|---|
securityConfiguration | Bean named shibboleth.DefaultSecurityConfiguration | An object containing all of the default security-related objects needed for peer authentication and encryption. See SecurityConfiguration for complete details. | |
disallowedFeatures | Integer | 0 | A bitmask of features to disallow, the mask values being specific to individual profiles |
inboundInterceptorFlows | List<String> | Ordered list of profile interceptor flows to run prior to message processing | |
outboundInterceptorFlows | List<String> | Ordered list of profile interceptor flows to run prior to outbound message handling |
Guidance
Modifying the security configuration is usually done to:
specify an alternate signing or decryption key to use
control signing or encryption algorithms (but for metadata you control, it's advisable to control algorithms by using an extension to specify supported algorithms).
The two interceptor lists allow the much less commonly used profile interceptor injection points to be used. This is largely a Java-based way of doing very low-level sorts of “message rewriting” hackery that might otherwise be impossible to pull off. One use case for the inbound side might be picking up non-standard parameters in a SAML request.
Options common to SAML profiles:
Name | Type | Default | Description |
|---|---|---|---|
signResponses | Boolean | varies by profile | Whether to sign responses |
signRequests | Boolean | false | Whether to sign requests |
Guidance
It isn't too common to need any of these options, and they should be changed only with care.
The signResponses default varies by profile, see the notes on the individual profile pages.
Options common to SAML 2.0 profiles:
Name | Type | Default | Description |
|---|---|---|---|
ignoreRequestSignatures | Boolean | false | Whether to skip validation of signatures on requests |
encryptionOptional | Boolean | false | Whether to automatically disable encryption if the relying party does not possess a suitable key |
encryptNameIDs | Boolean | varies by profile | Whether to encrypt NameIDs |
Guidance
The encryption options are generally set correctly for each different profile; see the notes on the individual profile pages.
Note that when the conditions to encrypt various constructs evaluate to true, the IdP will fail the request if it is unable to perform the encryption, for whatever reason. This is overrideable using the encryptionOptional property, which allows the IdP to encrypt if it can but continue otherwise. If you carefully control your metadata sources, which you should do in any case, you should be able to trust that any SP lacking an encryption key is incapable of encryption anyway, making the property safe to enable.
The ignoreRequestSignatures option is an interoperability knob to deal with badly broken or incompetently operated services. Signed requests in some profiles, particularly SSO, are often pointless and are frequently used for no good reason. If the signer's code is broken, or even worse if they manage their key poorly and require constant flag days to update them, this allows the signature to be ignored and potentially the key to be bypassed so their incompetence doesn't impact your operations.
Options common to SAML profiles that may transmit messages via SAML Artifact (a pass by reference instead of value, followed by a callback).
Name | Type | Default | Description |
|---|---|---|---|
artifactConfiguration | Bean named shibboleth.DefaultArtifactConfiguration | Customizes the use of SAML artifacts |
Guidance
You shouldn't really need to modify this, as artifacts are rarely used anymore, and if they are, the default configuration suffices. The main reason you might change it is to switch a SAML 1.1 SSO configuration from Type 1 to Type 2 artifacts, but that's very obscure. If it ever comes up, we will provide an example.
With SAML 2.0, there is a valid case for customizing the configuration on a per-node basis by exposing dedicated resolution endpoints on each node, and making sure a node issues artifacts that will be resolved by that node. This is already exposed for you via the idp.artifact.endpointIndex property.
Options specific to the SAML 2.0 Single Logout profile:
Name | Type | Default | Description |
|---|---|---|---|
qualifiedNameIDFormats | Collection<String> | See below |
Guidance
The qualifiedNameIDFormats option was added to deal with an interoperability issue involving the matching of SAML <NameID> elements between the values issued by the IdP and values received in <LogoutRequest> messages. The two have to "match", and the IdP was imposing a strict rule that required all the various bits of a <NameID> to be equal, which is the conservative approach, but it relies on SPs not modifying the data they receive unnecessarily.
While that's the expected behavior, not all SPs do this correctly, and there are some edge cases in the standard whereby some <NameID> Formats are defined in such a way that the NameQualifier and SPNameQualifier attributes are permitted to "default" to values based on the entityIDs of the IdP and SP at runtime.
The IdP now supports this defaulting during its logout comparisons for the two Formats for which this defaulting is explicitly defined in the standard, namely "persistent" and "transient". The configuration option allows deployers to add additional custom Formats to the set for which this behavior is in effect.
While it is possible to add additional standard Formats to this set, it bears noting that none of them are defined by the standard to be compared in that fashion. They shouldn't even have qualifiers, in fact.
.
Notes
The default values of signRequests and signResponses for this profile make a channel dependent choice. Specifically it signs on the front-channel, and on the back-channel only if TLS isn't used (very unusual) or if the receiving port is 443. It assumes that traffic over 443 will be relying on message-based security measures (but see below), whereas traffic to an alternative TLS port like 8443 will be relying on mutual authentication and thus provide a secure channel.
The default value of encryptNameIDs is also conditional on the same basis.