ProfileConfiguration-Authentication

Options common to profiles that perform authentication:

Name	Type	Default	Description

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

<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

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