ShibbolethSSOConfiguration

Common

Options common to most/all profiles:

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

Authentication

Options common to profiles that perform authentication:

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.

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

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

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.

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

SAML

Options common to SAML profiles:

Guidance

It isn't too common to need any of these options, and they should be changed only with care.

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

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.

Artifact

Options common to SAML profiles that may transmit messages via SAML Artifact (a pass by reference instead of value, followed by a callback).

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 Shibboleth / SAML 1.1 SSO profile:

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 back-chanel to query for attributes, due to the lack of support for XML Encryption in SAML 1.1.

This a very commonly modified setting 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.