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. >> The other problem is that the WebKDC doesn't have any idea what OTP >> type was used. For that matter, the WebLogin server only sort of does; >> it knows which OTP types the user had configured, but there could be >> more than one. Where should the WebAuth system get that information >> from? > I assumed that WebLogin would use each type configured by the WAS > WebAuthRequireInitialFactor. I might be misunderstanding how these > configurations work together. That makes sense, but I'm not sure how to generalize it. Basically, the required factors can be just "m" or just "o" to indicate that anything is fine, and then it's not clear what WebLogin should do. If the WAS asks for a specific "oN" factor, it's more straightforward. 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? > RHEL6 has yajl - though I haven't used it personally it is a dependency > for libvirt and libvirt-client which are some pretty big projects in > RHEL-land. Oh, that looks interesting, thanks. > I'm also finding that we may need to extend the userinfo and validate > callouts in a couple ways. > 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. > For validate, some OTP might require additional interactions: for > example, SecurID might request that the user wait until their current > token generator creates a new token, and re-submit it. It would be > useful to be able to send a message back to weblogin: "Please re-enter > the next token". This could be done with an auth_rejected rather than > auth_failed response. > Perhaps we can re-use userMessage in the requestTokenResponse, but maybe > we (UVM) would be better served by moving all this logic into WebLogin. > It would be interesting to hear about other planned work in this > space. Do you think these are reasonable scenarios for WebAuth to > support? I am, of course, willing to contribute. 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. (We're also doing some work to move some of our user information service code into modules that we can ship with WebAuth to provide a framework for other people who are implementing the same service.) 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). -- Russ Allbery <[email protected]> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
