Forcing MFA for some SPs and not Others
cantor.2 at osu.edu
Fri Aug 13 19:07:53 UTC 2021
On 8/13/21, 2:54 PM, "users on behalf of Mak, Steve" <users-bounces at shibboleth.net on behalf of makst at upenn.edu> wrote:
> Reuse of the Entire authn/MFA Flow Result (When Is a MFA Next Flow Strategy Executed?)
Usually because you want to have policies based on the *user* rather than the service.
Service-based rules are all relatively automatable with the various supportedPrincipals matching that happens automatically and with minimal scripting (that one mfaCtx.isAcceptable() call in the examples).
When the user's identity comes into play, it gets much more complex (which is why you should never do this unless you absolutely have to) and you generally have to set that reuseCondition to false to force the scripting to run every time so you can look up the user's attributes and add that into the logic so it's not short-circuited by the principal/result matching.
You may also typically want to fail closed because attribute lookup is always fragile in comparison to other things. Failure to get data should usually mean the assumption is to require MFA, so a strategy of assuming that to start with (e.g. via a relying party override or metadata or whatever, based on service), and then *clearing* the RequestedPrincipalContext from the tree based on the user's attributes is usually a bit safer, if somewhat counter-intuitive.
More information about the users