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.
> 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.
> 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.
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.
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.
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.
Ben
