Russ Allbery <[email protected]> writes:
> 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.
Oh, and I didn't say explicitly, but this would mean that rather than
sending <multifactor-required />, the user information service (for the
case where it would do that now) would send:
<required-factors>
<factor>m</factor>
</required-factors>
--
Russ Allbery <[email protected]>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
