Versions Compared

Old Version 11

changes.mady.by.user Rod Widdowson

Saved on

compared with

New Version Current

changes.mady.by.user Rod Widdowson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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
Expand
titleExamples of postAuthenticationFlows property
Code Block
languagexml
<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
Expand
titleExamples of defaultAuthenticationMethods property
Code Block
languagexml
<!-- 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>