Search Mailing List Archives
WebAuth 4.0.0 planning
eagle at windlord.stanford.edu
Tue Jun 14 18:38:17 PDT 2011
The next release of WebAuth, which we're expecting to finish by the end of
this summer, will be 4.0.0. This is a general notice of what we expect to
be the major changes, so that sites running WebAuth can prepare, and also
an invitation to review the design and changes that we're working on for
The WebAuth protocol in version 4.0.0 will be fully backward-compatible
with earlier versions. You will be able to use a new mod_webauth with an
old WebKDC and WebLogin server, and a new WebKDC and WebLogin server with
old mod_webauth clients. However, there will be new features available
when both sides have been upgraded.
The primary change in this version will be support for multifactor
authentication. This will come in several pieces:
1. Support for expressing, via the WebAuth protocol, the factors used for
initial and session authentication and the site-defined level of
assurance for this login. This information will then be available to
WebAuth-protected sites in environment variables.
2. Support for requiring specific factors or multifactor authentication to
access a WebAuth-protected resoure, or requiring a minimum level of
assurance. This can be used to force an already-authenticated user to
authenticate with a higher level of assurance or an additional factor.
3. New support inside the WebLogin server for multifactor authentication
4. Support for requesting "random" multifactor authentication for a
particular WebAuth-protected site, where users will have some chance of
being challenged to do multifactor authentication each time they visit.
5. Support for middleware-forced multifactor authentication for a
particular user or login.
Multifactor authentication will, in most cases, require external
middleware to handle the user configuration piece and to validate the
additional factor. We plan on releasing the middleware that we'll be
using at Stanford, which uses OATH as the second factor, MySQL as the user
setting database, and remctl as the middleware protocol as a separate open
source project. We're trying to design the middleware protocol so that
other sites can implement their own version relatively easily. The
initial implementation in 4.0.0 will require remctl, but we're trying to
design it so that we can drop in a parallel RESTful web service
I've written up two posts about the protocol changes required for
multifactor support. If you are interested in the details, please review:
Additional features that will be in 4.0.0:
1. Support for querying middleware for whether the user has any recent
suspicious logins and support in the WebLogin server for displaying
those logins if any are seen.
2. The templating language for the WebLogin screens will change from
HTML::Template to Template Toolkit. The conversion of your templates
should be fairly straightforward, and Template Toolkit has additional
functionality that we have been wanting to do more complex user
interface work inside the page templates. Some work will be required
when upgrading your WebLogin server to update your templates.
3. The WebAuth Perl module will be somewhat more object-oriented in its
interface to the C WebAuth library.
4. The WebLogin code will be extensively refactored into something closer
to a standard MVC model instead of the current ad hoc structure, which
will hopefully make it easier to maintain and adapt to local needs.
There are also some additional features that we're hoping to include soon,
but which may not be complete for WebAuth 4.0.0. We do, however, expect
them to appear in subsequent releases on a fairly quick basis:
1. Support in the WebLogin server and page templates for indicating that
the current login is on a public system and therefore no single sign-on
cookie should be created.
2. Support for prompting the user for, and validating, answers to
additional personal fact questions if a middleware call indicates that
something about their login looks suspicious.
Additional work on the LDAP authorization module, including support for
real LDAP groups, will probably not be included in this release, but is on
the list of things we will be working on after we finish the work detailed
above. Other things that are in our pending work queue and which we
expect to appear sometime in 2012:
1. Support for a replay cache on the WebLogin server to protect against
certain types of attacks when someone logs on via an unprotected public
2. Support for rate limiting of failed WebLogin logins.
3. A web services interface to the WebLogin / WebKDC so that WebAuth can
be used to authenticate web services calls.
If you have any questions or feedback about this general plan, please
raise them on the webauth-info at lists.stanford.edu mailing list. You can
follow WebAuth development via the public Git repository at:
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
More information about the webauth-info