Re: Changing MCB assurance level per SP and by "risk" (source IP)

[Rich Graves]

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.

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.

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.
-- 
Rich Graves

----- Reply message -----
From: "David Walker" <dhwprof at gmail.com>
To: <users at shibboleth.net>
Subject: Changing MCB assurance level per SP and by "risk" (source IP)
Date: Sat, Apr 5, 2014 2:49 AM

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140405/390dca09/attachment.html