On Feb 27, 2013, at 5:11 PM, Russ Allbery wrote: > 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.
This is excellent, and is the best adaptation for what we're trying to do. Are you thinking this is work you'd like to do, or shall I submit patches for your review? I am happy to work on this as well. Ben
