<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head></head><body><div style="font-size: 12pt; font-family: Calibri,sans-serif;"><div>Yes, I will do that too, but the first hit would always be free; i.e., they would get at least one login to webmail from country N and one login to Elsevier from country C without challenge.</div><div><br></div><div>The webmail SP already defends itself with rate limiting, looking for suspicious changes to preferences, etc. Elsevier can look after itself. I'm worried about things like ERP and Google Apps where we do not control what happens post-signon and a lot of damage could be done in one session.</div><div><br></div><div>Currently, we have such a log-scraper on webmail only, and the actions it takes include flushing sessions, inducing a 30-minute password lockout in AD, and assigning a ticket to a human. "Losing their certification" for single-factor auth could be a more effective and user-friendly approach.</div><div>-- </div><div>Rich Graves</div><br><div id="htc_header">----- Reply message -----<br>From: "David Walker" <dhwprof@gmail.com><br>To: <users@shibboleth.net><br>Subject: Changing MCB assurance level per SP and by "risk" (source IP)<br>Date: Sat, Apr 5, 2014 2:49 AM</div></div><br><pre style="word-wrap: break-word; white-space: pre-wrap;">Another way to think about this is that users lose their certifications
for certain authentication contexts (assurance profiles) when they do
dodgy things. This could be done outside of Shib and the MCB with a
process that monitors the logs and manipulates users' lists of available
authentication contexts, but the MCB would honor it. A service could
then be provided to regain those contexts, based on, say, a 2FA
authentication context that the user never loses.
David
</pre></body></html>