You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
Version 1
Next »
File(s): conf/relying-party.xml
Format: Native Spring
Overview
The Shibboleth.SSO profile configuration bean enables support for the SAML 1.1 Browser Single Sign-On profile initiated via the legacy Shibboleth request protocol, which is documented in the UnsolicitedSSOConfiguration page.
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.
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.
Authentication
Options common to profiles that perform authentication:
Name | Type | Default | Description |
---|
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. |
forceAuthn | 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 |
proxyCount | Non-Negative Integer | | Limits use of proxying either to service providers downstream or when requesting authentication from identity providers upstream. This will generally depend on whether a particular protocol supports the feature. |
Guidance
The postAuthenticationFlows
property is used to apply special processing to requests, such as attribute release consent, password expiration warnings, authorization checks, or other custom processing.
Examples of postAuthenticationFlows property
Examples of postAuthenticationFlows property
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<!-- Add consent to Shibboleth SSO profile. -->
<bean parent="Shibboleth.SSO" p:postAuthenticationFlows="attribute-release" />
<!-- Add consent, followed by expiring password check, to SAML 2 SSO profile. -->
<bean parent="SAML2.SSO" p:postAuthenticationFlows="#{{'attribute-release', 'expiring-password'}}" />
<!-- Return interceptors from a function bean (not shown). -->
<bean parent="Shibboleth.SSO" p:postAuthenticationFlowsLookupStrategy-ref="InterceptorsFunction" />
</bean>
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 AuthnRequestsSigned
flag to indicate that its requests must be signed.
Alternatively, the disallowedFeatures
property may be set with the SAML2.SSO.FEATURE_AUTHNCONTEXT bean to block use of the SAML 2.0 <RequestedAuthnContext>
feature.
At present, no other authentication profiles support a feature capable of requesting the authentication method.
Examples of defaultAuthenticationMethods property
Examples of defaultAuthenticationMethods property
<!-- NOTE: these example.org constants are examples and are not suitable for real use. -->
<bean id="MFASAML2Principal" parent="shibboleth.SAML2AuthnContextClassRef"
c:_0="http://example.org/ac/classes/mfa" />
<bean id="MFASAML1Principal" parent="shibboleth.SAML1AuthenticationMethod"
c:_0="http://example.org/ac/classes/mfa" />
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<!-- Require MFA with Shibboleth SSO profile. -->
<bean parent="Shibboleth.SSO">
<property name="defaultAuthenticationMethods">
<list>
<ref bean="MFASAML1Principal" />
</list>
</property>
</bean>
<!-- Require MFA with SAML 2 SSO profile. -->
<bean parent="SAML2.SSO" p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT">
<property name="defaultAuthenticationMethods">
<list>
<ref bean="MFASAML2Principal" />
</list>
</property>
</bean>
</bean>
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 |
messageHandler | Function<MessageContext,Exception> | | A function hook allowing modification of SAML messages before signing and transmission, useful for adding extensions |
Guidance
It isn't too common to need any of these options, and they should be changed only with care.
The signing defaults vary by profile, see the notes on the individual profile pages.
SAML Artifact
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 | SAMLArtifactConfiguration | 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.
SAML Assertion
Options common to SAML profiles that create assertions:
Name | Type | Default | Description |
---|
assertionAudiences | Set<String> | | Additional values to populate into audience restriction condition of assertions |
includeConditionsNotBefore | Boolean | true | Whether to include a NotBefore attribute in assertions |
assertionLifetime | Duration | PT5M | Lifetime of assertions |
signAssertions | Boolean | false | Whether to sign assertions |
Guidance
It isn't too common to need any of these options, and they should be changed only with care.
The assertionAudiences
and 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.
The assertionLifetime
setting does not involve control over the session with the relying party, it's only relevant in delegation scenarios and delegation is no longer supported so this is a largely unnecessary setting.
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. Related, the idp.saml.honorWantAssertionsSigned property can be turned off to globally ignore that flag in metadata should you wish to do so.
Profile-Specific
Profile-Specific
Options specific to the Shibboleth / SAML 1.1 SSO profile:
Name | Type | Default | Description |
---|
includeAttributeStatement | Boolean | false | Whether to "push" attributes during SSO |
nameIDFormatPrecedence | List<String> |
| Ordered list of NameIdentifiers Format(s) to select for use, in the event that a relying party does not signal a preference. |
Guidance
The historical default for the Shibboleth profile of SAML 1.1 was to issue only authentication information through the normal channel and rely on a SOAP back-channel to query for attributes, due to the lack of support for XML Encryption in SAML 1.1.
The includeAttributeStatement
setting is useful because of the gradual deprecation of the use of the back-channel and support for attribute queries. With the very limited use of SAML 1.1, it's usually simpler to forgo supporting queries and simply push attributes for the few legacy systems left, relying on the TLS protections between the client and servers to protect the user's data from passive observation.
Note that the value of this setting is ignored when SAML artifacts are used, it's always true in those cases because the data is passed over a back-channel anyway.
Notes
The default value of signResponses
for this profile is "true", and it is unsafe to change this value. If you encounter a relying party that accepts an unsigned response 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.