<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 4, 2014 at 3:52 PM, Rich Graves <span dir="ltr"><<a href="mailto:rgraves@carleton.edu" target="_blank">rgraves@carleton.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> The SP needs to send the "assurance" requirement via the AuthnContextClassRef field of the AuthRequest. You can't control on the IdP side "SP X requests must do DUO".<br>
<br>
</div>Yes, that flow is as expected. I just need to figure out how exactly to do that. I will do my homework. I suppose /etc/shibboleth/bindingTemplate.html would be too easy?<br></blockquote><div><br></div><div>It's even easier than that. One of my apps uses the /Login initiator when it wants an elevated session. For instance, app detects that user tries to access a resource that requires silver. We just redirect over to </div>
<div><br></div><div><a href="https://application.host.domain/Shibboleth.sso/Login?authnContextClassRef=http%3A%2F%2Fid.incommon.org%2Fassurance%2Fsilver&target=URL_ENCODED_PROTECTED_RESOURCE">https://application.host.domain/Shibboleth.sso/Login?authnContextClassRef=http%3A%2F%2Fid.incommon.org%2Fassurance%2Fsilver&target=URL_ENCODED_PROTECTED_RESOURCE</a><br>
</div><div><br></div><div>When the user returns, we check to see that <a href="http://id.incommon.org/assurance/silver">http://id.incommon.org/assurance/silver</a> is the current AuthenticationContext. You can also do that via the commands in either the RequestMap or in Apache's config.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> As for your second question, once again, it's on the Service to say "hmm, this user is from Nigeria, I should make them to 2-factor"<br>
<br>
</div>Hmm. I agree that the SP, not something like the IdP's relying-party.xml, should decide if an SP wants step-up authentication. But I think I want one central decision point on "risky" IPs -- and certainly on dodgy globe-trotting behavior. Individual SPs, especially third-party SPs, do not know what my IdP knows about expected user behavior.<br>
<br>
There is already the <idms attributeResolverID> mechanism for forcing a *user* to a higher assurance level regardless of SP. Or is that supposed to be an inclusive set, and I'm abusing it by making it exclusive? It looks like I could make "creative" use of <idms attributeResolverID> pointing to an instrumented database or LDAP server. Go ahead and talk me out of that.<br>
</blockquote><div><br></div><div>I'm "abusing" it the same way you are -- forcing a set of users to a higher assurance. The intent of that though is to be an inclusive set. Now, you may try getting clever with the attribute-resolver & limiting the values returned based on either the EntityID of the SP or the IP address of the user, but I'm not sure how that would play out with the IdPs caching of resolved attributes if the IDMS attribute's values change per authentication. That's more of a question for one of the Devs -- Devs?</div>
<div><br></div><div>Dave</div><div><br></div></div>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div>
</div></div>