Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

File(s): conf/relying-party.xml
Format: Native Spring

Overview

The SAML2.SSO profile configuration bean enables support for the SAML 2.0 Browser Single Sign-On profile (the most common profile used today with Shibboleth). This includes support for "unsolicited" or "IdP-initiated" SSO via the request format documented here.

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.

 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

additionalAudiencesForAssertion

Collection<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

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 additionalAuduencesForAssertion 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.

The 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. Related, the idp.saml.honorWantAssertionsSigned property can be turned off to globally ignore that flag in metadata should you wish to do so.

 SAML 2.0
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

encryptAssertions

Boolean

varies by profile

Whether to encrypt assertions

encryptNameIDs

Boolean

varies by profile

Whether to encrypt NameIDs

encryptAttributes

Boolean

false

Whether to encrypt attributes

proxyCount

Non-negative Integer


Controls the insertion of a proxy count into a <saml2:Scoping> element (when issuing SAML 2 AuthnRequests to an IdP) and into a <saml2:ProxyRestiction> element (when issuing SAML 2 assertions)

proxyAudiences

Set<String>


Controls the insertion of audiences into a <saml2:ProxyRestiction> element when issuing SAML 2 assertions

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.

The proxy settings are used to apply constraints to upstream and downstream proxying in accordance with the SAML 2 standard. You will generally find that most non-Shibboleth implementations ignore the resulting content, in violation of the standard, but they're provided as a means of documenting your intent primarily in service of audit requirements.

 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.

 Profile-Specific
Options specific to the SAML 2.0 Browser SSO profile:

Name / Type

Default

Description

maximumSPSessionLifetime

Duration

0

If non-zero, attempts to limit length of session with SP via SessionNotOnOrAfter attribute

skipEndpointValidationWhenSigned

Boolean

false

Whether to skip validation of response location via metadata if the request was signed

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.

ignoreScoping

Boolean

false

Whether to ignore <saml2:Scoping> elements within an SP's AuthnRequest

checkAddress

Boolean

true

Whether to enforce consistency between the client's address and the value within an inbound assertion's <saml2:SubjectLocality> element

proxiedAuthnInstant

Boolean

true

Whether to pass through a proxied AuthnInstant value from an inbound assertion when issuing new assertions based on it (the alternative is to insert a fresh timestamp)

suppressAuthenticatingAuthority 4.2

Boolean

false

Whether to prevent the insertion of <AuthenticationAuthority> elements(s) in the event of proxying

maximumTimeSinceAuthn

Duration


Limits the allowable time to accept a proxied authentication assertion based on its AuthnInstant, this is principally used to cross-check use of the ForceAuthn flag

authnContextComparison

"exact", "minimum", "maximum", "better"

see below

Controls the comparison operator used when including <saml2p:RequestedAuthnContext> elements in proxied AuthnRequests

authnContextTranslationStrategy

Function<AuthnContext,Collection<Principal>

see below

Controls bidirectional translation of <saml2:AuthnContext> content when issuing requests and generating assertions to allow for remapping of values across the proxy boundary

authnContextTranslationStrategyEx 4.2

Function<ProfileRequestContext,Collection<Principal>


More advanced support for populating <saml2:AuthnContext> content based on arbitrary request state (e.g. use of SAML Attributes from a proxied IdP)

Guidance

The 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.

Examples of nameIDFormatPrecedence property
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">

	<!--
	Both constants below evaluate to the string "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
	and are interchangeable, they're just illustrations of different ways to reference the same string.
	-->

	<!-- Use "unspecified" NameIdentifier with Shibboleth SSO profile. -->
	<bean parent="Shibboleth.SSO">
		<property name="nameIDFormatPrecedence">
			<list>
				<util:constant static-field="org.opensaml.saml.saml1.core.NameIdentifier.UNSPECIFIED" />
			</list>
		</property>
	</bean>

	<!-- Use "unspecified" NameID with SAML 2 SSO profile. -->
	<bean parent="SAML2.SSO">
		<property name="nameIDFormatPrecedence">
			<list>
				<util:constant static-field="org.opensaml.saml.saml2.core.NameIDType.UNSPECIFIED" />
			</list>
		</property>
	</bean>

	<!-- Return formats from a function bean (not shown). -->
	<bean parent="Shibboleth.SSO" p:nameIDFormatPrecedenceLookupStrategy-ref="FormatsFunction" />

</bean>

The 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.

The ignoreScoping setting is provided to work around interoperability issues with broken SPs.

Several other new settings are used when proxying and provide various kinds of policy controls familiar to SP operators, as well as new features to support remapping of potentially non-interoperable AuthnContext values. By default, the IdP operates in a fairly automatic fashion when proxying, such that any <saml2p:RequestedAuthnContext> element from an SP will be echoed essentially as-is to any upstream Identity Provider, and the data found in the incoming assertion will be echoed as-is back downstream. Since proxying is often used to firewall against interoperability problems and crosswalk between different communities of practice, functions can be plugged in to perform more flexible mapping of values, and some pre-existing machinery is in place to support this declaratively, as described in the AuthenticationConfiguration page. An additional hook was added in V4.1 that allows a similar function to be injected but with access to the entire request state to do more advanced things.

There are also a variety of settings related to delegation that are not shown above but can be found in the relevant API documentation.

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.

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.

The default value of encryptAssertions for this profile is "true".

The default value of signRequests for this profile is "false", and normally comes into play only for signing <saml:AuthnRequest> messages when proxying. Signing can also be triggered via the proxied IdP's WantAuthnRequestsSigned flag in metadata, which in turn can be globally ignored via the idp.saml.honorWantAuthnRequestsSigned property.

  • No labels