Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

WebAuth 4.0.0 planning

Russ Allbery eagle at windlord.stanford.edu
Tue Jun 14 18:38:17 PDT 2011


Hello everyone,

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
this version.

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
   page flow.

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

I've written up two posts about the protocol changes required for
multifactor support.  If you are interested in the details, please review:

https://mailman.stanford.edu/pipermail/webauth-info/2011-May/000728.html
https://mailman.stanford.edu/pipermail/webauth-info/2011-June/000737.html

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

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:

    http://git.eyrie.org/?p=kerberos/webauth.git

-- 
Russ Allbery <eagle at windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University



More information about the webauth-info mailing list