<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>I was looking at a similar thing for doing MFA with Symantec VIP. An attribute on the person would flag them as either needing MFA for all unspecified/password flows, or the attribute could also be a list of entityIDs. I couldn't come up with any issues
with looking up the need pre-authentication and then taking action after ldap succeeded, but would very much like feedback as well of why that may not be a good idea.</div>
<div><br>
</div>
<div>Symantec VIP also offers a risk based authentication, where the return from that risk based check could also step them up to MFA.</div>
<div><br>
</div>
<div><br>
</div>
<div>-Bradley</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Marvin Addison <<a href="mailto:marvin.addison@gmail.com">marvin.addison@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>Shib Dev <<a href="mailto:dev@shibboleth.net">dev@shibboleth.net</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, July 1, 2015 at 3:35 PM<br>
<span style="font-weight:bold">To: </span>Shib Dev <<a href="mailto:dev@shibboleth.net">dev@shibboleth.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: Where to put multifactor flows<br>
</div>
<div><br>
</div>
<div>
<div>
<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">
Is it enough that you can already do a special attribute resolution step within the authentication flow?</blockquote>
<div><br>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div>I looked at that, though admittedly not carefully. I ruled it out primarily because it fired before authentication.</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or are you reacting to the requirement to do a password-based login up front to get that to work?<br>
</blockquote>
<div><br>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div>Password authentication must succeed in order for the Duo flow to fire. Hope that answers the question.</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess what I would ask is, what is that you really want it to do from a user PoV? What's supposed to happen in particular cases (session already exists, doesn't exist, etc.)?<br>
</blockquote>
<div><br>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div>I want to prevent the user navigating away from the IdP prior to completion of 2-factor auth and subsequently accessing a service on the existing session. </div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Deferring the session update is probably not a big deal, but I'm also not sure what it buys you. Updating the session just records something that happened, and deferring recording it doesn't really prevent it from having happened</blockquote>
<div><br>
</div>
<div>I hope I can articulate that order matters. Modeled as an interceptor flow, the Duo login form renders _after_ session creation and setting of the browser cookie. That allows bypassing the Duo login, just by clicking away when the Duo login form renders,
and subsequently accessing a service (same or another) on the existing IdP session.</div>
<div> </div>
</div>
</div>
<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">
I definitely feel like something is very wrong if you have to use an interceptor flow to support a login flow.</blockquote>
<div><br>
</div>
<div>Don't disagree, but the attribute resolution machinery seems to naturally come _after_ authentication. It would fit nicely as a login flow if I didn't have to query for user data to signal it; but we are assuming there will always be a need for opting
out on a user basis, and we want to build that from the start.</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd much rather add tools or pieces for login flows to take advantage of than ever have the IdP exit the authn flow without having actually completed auhentication.<br>
</blockquote>
<div><br>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div>Sounds good, but I don't see a good alternative at present. Open to suggestions.</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>M<a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>