While doing some work on Shibboleth and mod_auth_kerb with Apache 2.4, I
discovered some issues with WebAuthOptional support. The short version is
that it currently doesn't work properly in Apache 2.4 (which, so far as I
know, no one has yet noticed, probably because Apache 2.4 is not yet
widespread). I can put together a solution that's backward-compatible,
but in the long run some configuration changes will create a much cleaner
solution.
For those who haven't used WebAuthOptional, what it does is let you defer
authentication. Unauthenticated users can access the resource and
REMOTE_USER won't be set. If the user authenticates, REMOTE_USER will be
set. This allows dynamic content (such as CGI scripts) to look at
REMOTE_USER on the fly to decide what content to present without having
separate URLs for authenticated and unauthenticated users. It's similar
to Shibboleth's lazy login support.
With Apache 2.2, this is normally configured with:
AuthType WebAuth
WebAuthOptional on
require valid-user
Under the hood, if the user isn't authenticated, mod_webauth returns
success in the authentication hook but doesn't set a user, and Apache 2.2
allows that to satisfy valid-user. (Note that you need some require
directive or the authentication hook will never run and WebAuth has no way
of setting REMOTE_USER if the user actually is authenticated.) This
breaks in Apache 2.4 since the behavior of require valid-user has changed.
It now requires REMOTE_USER (well, request_rec.user) be set.
It turns out that it accepts REMOTE_USER set to the empty string, which
still looks the same as REMOTE_USER not being set to most code that would
test it, so my plan for the next patch release of WebAuth is to set this
value to the empty string for Apache 2.4. However, this is taking
advantage of rather undocumented internals, and I could see Apache
changing in the future to reject the empty string as well.
The way Shibboleth handles this is to introduce a new require directive,
require shibboleth, which enables the module but doesn't apply any actual
access restrictions. (In other words, it grants all access.) This is a
much better solution, since it doesn't rely on undocumented features of
require valid-user. It also fixes the weirdness that unauthenticated
users satisfy require valid-user when optional authentication is enabled,
which could potentially cause security issues if people don't pay close
attention.
My long-term intention, therefore, is to add a new require webauth
directive that behaves like Shibboleth's require shibboleth: it doesn't
set any access controls, just ensures that the module has a chance to run.
I want to then (eventually) drop setting r->user to the empty string,
which will break backward compatibility with people who use require
valid-user with WebAuthOptional, but which will be cleaner.
I'm not yet sure when all this will happen, since I'm actually supposed to
be working on other projects now. :) But I wanted to mention all of this
to let people know about the current situation, and also to see if people
have any other preferences for how this should work.
--
Russ Allbery <ea...@windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
