Page Comparison

...

Localtabgroup

Localtab

active	true
title	Beans (V4.0)

The beans defined in authn/mfa-authn-config.xml follow:

Bean ID / Type	Default	Description
shibboleth.authn.MFA.TransitionMap Map<String,MultiFactorAuthenticationTransition>		Static ruleset containing the starting point for MFA execution and the rules to use to decide how to do work
shibboleth.authn.MFA.TransitionMapStrategy Function<ProfileRequestContext,Map<String,MultiFactorAuthenticationTransition>		Optional function bean to return the ruleset to use instead of using a static ruleset
shibboleth.authn.MFA.Transition MultiFactorAuthenticationTransition		Parent bean for defining transition rules in the values of the previous bean's map entries
shibboleth.authn.MFA.validateLoginTransitions Boolean	true	Whether login flows should only be run with regard for forceAuthn/isPassive/nonBrowser (and similar) conditions
shibboleth.authn.MFA.resultMergingStrategy Function<ProfileRequestContext,AuthenticationResult>	described above	Function to run to produce final merged result of MFA login flow during successful completion
shibboleth.authn.MFA.resultCachingPredicate Predicate<ProfileRequestContext>		An optional bean that can be defined to control whether to preserve the authentication result in an IdP session

Localtab

title	Beans (V4.1+)

The beans defined in authn/mfa-authn-config.xml follow:

Bean ID / Type	Default	Description
shibboleth.authn.MFA.TransitionMap Map<String,MultiFactorAuthenticationTransition>		Static ruleset containing the starting point for MFA execution and the rules to use to decide how to do work
shibboleth.authn.MFA.TransitionMapStrategy Function<ProfileRequestContext,Map<String,MultiFactorAuthenticationTransition>		Optional function bean to return the ruleset to use instead of using a static ruleset
shibboleth.authn.MFA.Transition MultiFactorAuthenticationTransition		Parent bean for defining transition rules in the values of the previous bean's map entries
shibboleth.authn.MFA.resultMergingStrategy Function<ProfileRequestContext,AuthenticationResult>	described above	Function to run to produce final merged result of MFA login flow during successful completion
shibboleth.authn.MFA.resultCachingPredicate Predicate<ProfileRequestContext>		An optional bean that can be defined to control whether to preserve the authentication result in an IdP session

Localtab

title	Properties (V4.1+)

Properties specific to this flow defined in authn/authn.properties are:

Name	Default	Description
idp.authn.MFA.validateLoginTransitions	true	Whether login flows should only be run with regard for forceAuthn/isPassive/nonBrowser (and similar) conditions

As a generic flow, the supportedPrincipals property defaults to the following XML:

Code Block

language	xml
collapse	true

<list>
    <bean parent="shibboleth.SAML2AuthnContextClassRef"
        c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol" />
    <bean parent="shibboleth.SAML2AuthnContextClassRef"
        c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
    <bean parent="shibboleth.SAML2AuthnContextClassRef"
        c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:Password" />
    <bean parent="shibboleth.SAML1AuthenticationMethod"
        c:method="urn:oasis:names:tc:SAML:1.0:am:password" />
</list>

In property form, this is expressed as:

Code Block

idp.authn.MFA.supportedPrincipals = \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:Password, \
    saml1/urn:oasis:names:tc:SAML:1.0:am:password

This default is not intended to be applicable to most systems, but matches the behavior of the flow's default/example configuration which accounts for both the IPAddress and Password flows being combined.

Notes

It's been observed, accurately, that the data required to track the use of this feature in the session cache is on the order of 2-3 times as large as just a "simple" authentication result. While it is believed that this remains acceptable with the use of cookies, and certainly with HTML Storage, some storage service implementations such as that for Memcached rely on a less reliable persistence model that may prematurely evict data, so such options may not be a good fit with this feature.

...

Versions Compared

Old Version 8

New Version 9

Key

Notes