<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What is the authorization policy in the second half of that sentence you're trying to enforce? Can you just build an interceptor that enforces that after the fact?<br></blockquote><div><br></div><div>I got excited when I first read this suggestion. I immediately thought of installing an additional AuthenticationResult on successful Duo auth; the presence of that artifact in the session would be the enforcement check that prevents circumvention. I just did some recon on that particular implementation, and the obstacle seems to be the requirement for an authentication flow identifier. Since the Duo flow in this case is by definition not an an authentication flow, I don't see how to proceed. Alternatively, I don't see any other convenient session artifact to attach the Duo result to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The closest I can translate what you're after here is an opt-in to require a second factor for specific users for specific services, which apparently can be determined from the attributes. So why not just enforce that before proceeding with the request every time?<br></blockquote><div><br></div><div>That's a suitable problem definition, and a reasonable implementation suggestion. I just need something attached to the IdPSession to set and check, but I haven't found a clear candidate yet.</div><div><br></div><div>M<a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>