Benjamin Coddington <[email protected]> writes:
> On Feb 27, 2013, at 4:29 PM, Russ Allbery wrote:
>> Hm, yes, we could add <factor> as an optional element in the
>> <multifactor-required>, which specifies the factor the user needs to
>> use. Although at that point why not just limit the configured
>> <factors> returned by the user information service? All the code is
>> already in place to handle that.
> Hm.. yes -- so instead of <factors> being the list of all the factors a
> user is capable of using, it would be the list of factors that WebLogin
> should enforce for this user/WAS combo, if we decide to enforce them.
> What happens if a WAS wants o3, but userinfo only sends along o2 because
> it was configured to subset the factors for this user/WAS combo? If
> <factors> are the full list of capable factors, then we wouldn't have to
> worry about userinfo sending along only a subset, or having to modify
> the userinfo configuration if a WAS decides to require a different
> factor.
> An additional corner-case: if <factors> is the complete list of
> user-capable factors, a WAS requires o2, and userinfo requires o3.
> Would WebLogin need to loop through the factor types? Display both
> forms at once?
> I think we could live with this working either way -- I didn't realize
> that <factors> might be a subset.
The more I think about it, though, the more I think that overloading the
meaning of <factors> is a bad idea.
Here's another idea: what if we replace the simple <multifactor-required>
flag element with a <required-factors> element, and then change the WebKDC
to require the union of the factors required by the WAS and the factors
required by the user information service? In other words, for a user with
both o2 and o3 factors available but who should have to use o3, the user
information service would send something like:
<authdata user="user">
<factors>
<factor>p</factor>
<factor>m</factor>
<factor>o</factor>
<factor>o2</factor>
<factor>o3</factor>
</factors>
<required-factors>
<factor>o3</factor>
</required-factors>
</authdata>
Then, the WebKDC will take the union with the initial_factors in the
request token and either reject the login as impossible (if the union of
required factors cannot be satisfied fully by the configured factors) or
send that along to the WebLogin server in the <multifactorRequired>
element.
For the communication from the WebLogin server to the WebKDC, the easiest
thing to do would be to add an otp_type field to the login token and then
pass that along to the validate call as an additional parameter.
Then, the logic in the WebLogin server would look at all the required
factors and the factors that the user has available and decide what login
forms to present. Some of this is probably going to have to be
site-specific and therefore should happen in the page template, which
means that we should provide some way for the page template to communicate
back to the script, via a form field, what the OTP type is if the form
knows. So, in other words, the submission form for (at Stanford) an SMS
OTP code would contain a hidden otp-type field that contains "o2" and the
WebLogin server would use that to build the login token.
In general, the login form logic is going to want to filter out all the
generic factors (m and o) and look for what specific factor was required
and present the corresponding form.
In the case where the userinfo service requires o2 and the WAS requires
o3, I think right now we give up. What should happen, eventually, is a
generalization of the multi-step login process: we keep presenting login
form after login form until we've accumulated all of the factors that we
want. But it's going to require some thinking to figure out how to
express that in the WebLogin flow, and I think it's an edge case for the
time being.
--
Russ Allbery <[email protected]>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
