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

[Rich Graves]

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.