You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 6
Next »
File(s): conf/relying-party.xml
Format: Native Spring
Overview
The SAML2.ECP profile configuration bean enables support for the SAML 2.0 Enhanced Client/Proxy profile (the mobile / non-browser SSO interface).
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.
Common
Options common to most/all profiles:
Name | Type | Default | Description |
|---|
securityConfiguration | 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.
SAML
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.
Notes
The default value of signResponses for this profile is "true", in keeping with modern best practice. As long as one of the response or assertion are signed, use of the profile is "safe" in terms of authentication integrity, but there are vulnerabilities in XML Encryption that make signing responses advisable when the most common encryption algorithms are used. Some of the backstory around the signing defaults is discussed in this thread.
The default value of encryptAssertions for this profile is "true".
If you encounter a relying party that accepts an unsigned response and assertion that is transmitted via POST (and not artifact), you have identified an insecure implementation and should report the issue immediately while following your local security incident response process.