Benjamin Coddington <[email protected]> writes: > We're looking at several distinct OTP types for user/WAS combinations, > and I found that the webkdc-validate remctl command does not pass the > OTP type along. It looks like we can get around it by prefixing the OTP > itself with the type. Is there a better way to inform the > webkdc-validate logic of the OTP type to validate?
> I'll defer just sending patches along until told to send them this > time. :) 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.) 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? BTW, we've pretty much decided that the right long-term fix is to switch to JSON for the input for the webkdc-userinfo and webkdc-validate calls (and probably for the output eventually too), but the problem I have there is that JSON C libraries are a bit scarce. There's an APR JSON C library that I want to use, but it's not packaged even for Debian yet, which means that adding it as a prerequisite is going to be a bit of a hardship. So I haven't changed anything yet. > Lastly, the excellent documentation on > http://webauth.stanford.edu/install-multifactor.html needs a minor > update for the webkdc-userinfo remctl command parameters, which is > missing the WAS as the 5th param. Thanks, fixed. Of course, I fixed it by updating to the latest copy of the documentation, which means that it now documents a sixth option that the latest release doesn't send. Coming soon.... :) -- Russ Allbery <[email protected]> Technical Lead, ITS Infrastructure Delivery Group, Stanford University
