DuoOIDC passwordless event handling question
Mak, Steven
makst at upenn.edu
Thu Mar 12 15:44:32 UTC 2026
So I think I realize now that I misunderstood the video on the Duo Passwordless page. What I think the video demonstrates is a user enrolling in Passwordless with TouchID (allows platform auth only) and then trying to complete the passwordless flow with a roaming auth which results in a RequestUnsupported. This has nothing to do with PPT at all.
So now that I know that, I believe the video is not relevant to the problem I'm seeing.
But I did come up with the start of a solution for anyone else trying to figure this out.
I added this entry key to my DuoOIDC flow:
<entry key="proceed" value-ref="checkPPT"/>
Then I defined a simple script that runs at the very end of the MFA flow:
<bean id="checkPPT" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">
<constructor-arg>
<value>
<![CDATA[
nextFlow = "proceed"
authContext = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext")
mfaContext = authContext.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext")
if (!mfaContext.isAcceptable()) {
nextFlow = "authn/Password"
}
nextFlow
]]>
</value>
</constructor-arg>
</bean>
This will prompt the user for username/password at the end if the SP requested PPT, but proceeds if everything passes.
Thanks for all the responses so far.
- Steve
From: users <users-bounces at shibboleth.net> on behalf of Scott Cantor via users <users at shibboleth.net>
Date: Wednesday, March 11, 2026 at 5:43 PM
To: Shib Users <users at shibboleth.net>
Cc: Scott Cantor <scott at restingparrotsoftware.com>
Subject: Re: DuoOIDC passwordless event handling question
> On Mar 11, 2026, at 4:47 PM, Steven Premeau via users <users at shibboleth.net> wrote:
>
> That said, the exit status of the DuoPlugin will only be based on the Duo authentication. If you wanted (or needed) to check some additional items after that Authentication stage completes and before things are finalized, you would need to define another step linked to the "proceed" event.
That's what I meant, the MFA flow won't "guard" it. If you tell it to run a flow, it doesn't care if that flow is or isn't "suitable", it just does it. If the result ultimately isn't what's needed, the failure happens at the very end.
> I'll defer to Scotts answer on whether it's better to remove the requirement from the SP or try to deal with it on the IDP....
Well, as a matter of the standard, you don't have a choice. You can fix the SP or lie. PPT is obviously not what the passwordless flow is doing.
You don't have the leeway to say "but it's better", unless the SP specifies "better" or "minimum" as an operator and not "exact".
If I were planning to violate the standard, though, I wouldn't lie, I'd add PPT to the list of "ignored" AuthnContext classes. By doing that, the IdP will treat it like "unspecified" and simply not even acknowledge that there was a request made with anything specific.
The response is therefore non-compliant, but a broken SP ain't gonna notice.
But that is all or nothing, it's a global setting.
-- Scott
--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!IBzWLUs!SAVrrEoomvlSn0_0GNoZUgXw4OP4E2xhoV0JZSfNvyk8J17T68yMonXSkqXctSQzJFDhPnTLHmaOv_Me$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260312/ac0c7bc2/attachment.htm>
More information about the users
mailing list