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

[David Walker]

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


On 04/04/2014 06:59 PM, Rich Graves wrote:
> Tom Scavo wrote:
>>> I think I want one central decision point on "risky" IPs -- and
>>> certainly on dodgy globe-trotting behavior. Individual SPs,
> [...]
>> of "previous session"). That's because my IP address indicates to
>> Google that my geographical location has changed drastically.
> Yeah, that's what I meant by "dodgy globe-trotting behavior."
>
>> Unfortunately, there are too many IdPs and not all of them do the
>> Right Thing, so an SP that cares will protect itself in any case. The
>> same is true of 2FA itself. An SP that requires strong authentication
>> won't wait for all of its IdP partners to deploy 2FA.
> Well, the Rich Graves who manages the internal SPs does plan to wait
> for the Rich Graves who manages his IdP to deploy 2FA. And he'd rather
> implement the geolocation logic only once.
>
> Looks like this is not how y'all intended it to be done. That's fine.
> If the big R1's aren't doing this in their Shib IdP's (or maybe they
> are, but at another layer, like the Cosign or PubCookie or WebAuth
> system that they've placed in front of Shib), then this little liberal
> arts college isn't going to go off on its own.
>
> I think I have another strategy that meets most of my perceived need:
>
> Instantiate *two* DuoLoginSubmodule beans with different integration
> keys. This allows me to define different policies at the DuoSecurity
> end rather than in the IdP itself. So my levels of assurance (not
> using the bronze/silver terminology until we actually go down that
> route) are:
>
> Level1: username/password only.
> Level2: Duo opt-in -- policy at the DuoSecurity.com end set to "Allow
>   Access" (Previously enrolled users are challenged, Unenrolled users
>   pass through without two-factor authentication), offer a "Remember
>   this device" checkbox that sets a long-lived browser cookie, and
>   define "Trusted networks" so that certain IP address space is exempt.
> Level3: Force Duo -- policy set to "Require Enrollment," no "Remember
>   this device," no "Trusted networks."
>
> I would set the default to Level2. The only thing this strategy doesn't
> let me do is to trigger 2FA enrollment based on suspicious source IP
> address alone. But I probably don't really want that, because a) it's
> not very user-friendly and b) the bad guy could just enroll their own
> device anyway.
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net