...
Hopefully you can see how to adapt it for a similar scenario involving your particular strategy. Obviously the attribute name, values, and the specific flows involved will be specific to you.
When appliable, an ActivationConditions may also be used from the script. For instance, to run the second flow only when the client adress is located outside internal network:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<util:map id="shibboleth.authn.MFA.TransitionMap">
<entry key="">
<bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/Flow1" />
</entry>
<entry key="authn/Flow1">
<bean parent="shibboleth.authn.MFA.Transition" p:nextFlowStrategy-ref="checkSecondFactor" />
</entry>
</util:map>
<bean id="InternalNetwork" class="org.opensaml.profile.logic.IPRangePredicate"
p:httpServletRequest-ref="shibboleth.HttpServletRequest"
p:ranges="#{ '192.168.1.0/24' }" />
<bean id="checkSecondFactor" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
p:customObject-ref="InternalNetwork">
<constructor-arg>
<value>
<![CDATA[
if (custom.apply(input)) {
nextFlow = null;
} else {
nextFlow = "authn/Duo";
}
nextFlow;
]]>
</value>
</constructor-arg>
</bean>
|
This is still a relative simple strategy in that it is driven only by successful results at each step, with errors left to fall through back into the IdP.
...