On Feb 27, 2013, at 3:02 PM, Russ Allbery wrote:
> Benjamin Coddington <[email protected]> writes:
>> On Feb 26, 2013, at 9:32 PM, Russ Allbery wrote:
>
>>> The issue, I assume, is that a single user may have multiple OTP
>>> methods configured at the same time? (The code was written assuming
>>> this wouldn't be the case because that's how we ended up implementing
>>> it.)
>
>> That's it, exactly. A single user may be able to use more than one OTP,
>> for example: securid and an SMS loop, and the WAS would specify which
>> should be used with WebAuthRequireInitialFactor.
>
> Ah, okay. Our expectation is that most (if not all) WASes at Stanford
> would just require an m factor and leave it up to the user and the central
> system to decide what type of multifactor was used, but that's somewhat
> specific to our environment.
That's preferable actually - have the userinfo callout service decide for
user Joe and WAS wiki.uvm.edu, enforce o3. I think that the userinfo
response could extend <multifactor-required /> to specify the type, and
constrain this specification to a single type. We would probably use that
instead of configuring every WAS with WebAuthRequireInitialFactor.
> It does sound like we should add a new field to the login token so that
> the WebLogin server can specify what type of OTP the login token
> represents, if it has that information, and then the WebKDC would pass
> that along verbatim to the webkdc-validate call. We just have to figure
> out what to put in there if the WebLogin server doesn't know. Maybe
> nothing, and we just omit that parameter?
I would think that if a WAS asks for just m, o, then the userinfo callout
could either enforce a particular o# with the <multifactor-required />
extension I suggested earlier or WebLogin would use just o -- a generic OTP
type -- and send o with the validate call which a site could implement as
they see fit. We would think about o as our 'default' (weakest?) OTP type,
but and we would know what backend validator to use.
>> For userinfo we'd like to arbitrarily require an OTP and present a
>> message with the reason - for example: if a user wants access to our
>> email system from nigeria, we'd like them to use an OTP and tell them
>> "Because you are logging into email from an unlikely location, please
>> OTP". This looks like the userinfo service would need to be able to
>> send additional information back to weblogin -- a message to display on
>> the first load of the multifactor submission page.
>
> Yup, that sounds like a great idea. Happy to take patches there if you
> have a chance.
OK, so what I'll look at doing is extending the use of userMessage in the
protocol for both callout cases -- userinfo provides a reason for an unusual
OTP requirement ("you're logging in from the West Coast??!"), and validate
requires some OTP-type specific information to be sent back to the user for
a temporary auth failure ("please, revalidate in your native tongue").
> I definitely think these are reasonable things to support. I'm reluctant
> to put all of the logic into WebLogin because I think a lot of the flow
> can be usefully shared between everyone running WebAuth, so I'm trying to
> isolate as much as possible of the site configuration behind the user
> information service abstraction.
I agree with this, and really like the segmentation and design of the user
information service. I'm glad that you're open to modifying it - thanks!
> Our current work is around "remember this device" support by way of adding
> a new persistent cookie that adds additional factors to a successful
> authentication and a mechanism for the webkdc-validate call to create that
> sort of persistent factor. The idea is that we can require users to do a
> multifactor authentication the first time that they use a particular
> browser and then remember that browser (similar to how Google and
> Microsoft support trusted devices for their services).
Great!
Ben
