Format: Native Spring / Deprecated Custom Schema
Legacy V2 File(s): conf/relying-party.xml
The SAML2.ECP profile configuration bean enables support for the SAML 2.0 Enhanced Client/Proxy profile (the mobile / non-browser SSO interface).
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:
|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 3.3||Integer||0||A bitmask of features to disallow, the mask values being specific to individual profiles|
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).
Options common to profiles that perform authentication:
|postAuthenticationFlows||List<String>||Ordered list of profile interceptor flows to run after successful authentication|
|defaultAuthenticationMethods||List<Principal>||Ordered list of Java Principals to be used to select appropriate login flow(s) to attempt, in the event that a relying party does not signal a preference. See AuthenticationFlowSelection.|
|nameIDFormatPrecedence||List<String>||Ordered list of NameID Format(s) to select for use, in the event that a relying party does not signal a preference. This is nominally SAML-specific but may be adapted for use with other supported protocols as circumstances warrant.|
|forceAuthn 3.4||Boolean||false||Disallows use (or reuse) of authentication results and login flows that don't provide a real-time proof of user presence in the login process|
postAuthenticationFlows property is used to apply special processing to requests, such as attribute release consent, password expiration warnings, authorization checks, or other custom processing.
With the increased use of multi-factor authentication, it is more common to find RPs that can specify authentication requirements, but there are still many cases, particular with commercial services, in which it becomes necessary to force the use of specific login methods. This can be achieved using the
defaultAuthenticationMethods property by specifying one or more corresponding Principals to trigger the use of stronger methods.
Note that you must also prevent a malicious actor from overriding this preference for a SAML 2.0 SP by manufacturing a request, via one of two means:
- For a SAML 2.0 SP that can sign its requests, its metadata can be modified with the
AuthnRequestsSignedflag to indicate that its requests must be signed.
- Alternatively, the
disallowedFeaturesproperty may be set with the SAML2.SSO.FEATURE_AUTHNCONTEXT bean to block use of the SAML 2.0
At present, no other authentication profiles support a feature capable of requesting the authentication method.
nameIDFormatPrecedence property is a common way of controlling the type of SAML NameIdentifier / NameID included in a response, a common requirement of many commercial services. It is in fact the only way to force the use of the ill-advised "
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" Format, which it must be noted is very rarely needed, despite frequent mis-documentation to the contrary.
In most cases, it is better to control the Format selected by including a
<NameIDFormat> element in the SP's metadata. In the event that you don't control the metadata, you can inject the required element by applying a metadata filter.
Options common to SAML profiles:
|additionalAudiencesForAssertion||Collection<String>||Additional values to populate into audience restriction condition of assertions|
|includeConditionsNotBefore||Boolean||true||Whether to include a |
|assertionLifetime||Duration||PT5M||Lifetime of assertions|
|signAssertions||Predicate<ProfileRequestContext>||false||Whether to sign assertions|
|signResponses||Predicate<ProfileRequestContext>||varies by profile||Whether to sign responses|
|signRequests||Predicate<ProfileRequestContext>||false||Whether to sign requests|
It isn't too common to need any of these options, and they should be changed only with care.
includeConditionsNotBefore settings provide ways to work around bugs in other systems. You should never use these settings without obtaining a commitment from the other system's owner to fix their bugs.
assertionLifetime setting does not involve control over the session with the relying party, it's only relevant in delegation scenarios.
The signing options have a complex history, which is one reason they are not themselves just boolean-valued. We provide Spring support so you can just set them to "true" or false" as though they are, but they also directly support the more dynamic approach of deriving the value with a bean.
signResponses default varies by profile, see the notes on the individual profile pages.
If you need to enable the
signAssertions option, and you control the SP's metadata, you should generally add the
WantAssertionsSigned flag to it in place of using this option.
Options common to SAML 2.0 profiles:
The encryption options are generally set correctly for each different profile; see the notes on the individual profile pages. We provide Spring support so you can just set them to "true" or "false" as though they are boolean-valued, but they also directly support the more dynamic approach of deriving the value with a bean.
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.
Options common to SAML profiles that may transmit messages via SAML Artifact (a pass by reference instead of value, followed by a callback).
|artifactConfiguration||SAMLArtifactConfiguration||Bean named shibboleth.DefaultArtifactConfiguration||Customizes the use of SAML artifacts|
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 Browser SSO profile:
|maximumSPSessionLifetime||Duration||0||If non-zero, attempts to limit length of session with SP via |
|skipEndpointValidationWhenSigned||Boolean||false||Whether to skip validation of response location via metadata if the request was signed|
skipEndpointValidationWhenSigned option is attractive in many enterprise scenarios if you prefer to maintain some degree of security but avoid registration of metadata containing every individual SP endpoint, which adds a lot of overhead in massively vhosted-environments.
It can also add a degree of insulation from SP changes, but in practice systems that are likely to change endpoint locations but don't support metadata-based change control are likely to misunderstand the need to keep entityIDs stable also.
There are a variety of settings related to delegation that are not shown above but can be found in the relevant API documentation.
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.