<div dir="ltr"><div><div>2016-10-19 15:35 GMT+02:00 Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I didn't bother asking, but usually that means they're using separate accounts.</blockquote></div><div> </div><div>Not necessarily. In my scenario, different locations require different authentication methods to require different level of authentication, but the account could be the same.</div></div><div><br></div><div>2016-10-19 19:08 GMT+02:00 Eric Goodman <span dir="ltr"><<a href="mailto:Eric.Goodman@ucop.edu" target="_blank">Eric.Goodman@ucop.edu</a><wbr>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Another potential use case which is probably infrequent in Shib deployments, but seems to be generally on an uptick in other areas is implementing least privilege/privilege escalation management. If done during the IdP authentication, the authentication process could allow you to specify the roles that you need for your access; in such a case reauthing at the IdP could end up returning different attributes depending on how you specify your need.</blockquote></div><div><br></div><div>Yes, basically this. For instance, a /user location could require a user-pwd authn because it only allows to check data, whereas an /updateInfo (or /admin) location may require otp as it allows to edit and data.</div><div>In my case, currently the returned attribute set may be the same, and I'm doing access control by checking the authentication method.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-19 19:14 GMT+02:00 Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Another potential use case which is probably infrequent in Shib<br>
> deployments, but seems to be generally on an uptick in other areas is<br>
> implementing least privilege/privilege escalation management. If done<br>
> during the IdP authentication, the authentication process could allow you to<br>
> specify the roles that you need for your access; in such a case reauthing at<br>
> the IdP could end up returning different attributes depending on how you<br>
> specify your need.<br>
<br>
</span>Haven't seen that so much as just step-up, requesting either a new login as presence proof or adding the second factor for specific functions. That obviously also fits within the OP's scenario, at least in theory. Getting that in place out of the box was the main focus of the 3.3 work.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>