Hi all,
Despite having a very capable pluggable aaa subsystem built into httpd,
the two main mechanisms for access remain mod_auth_basic and
mod_auth_digest.
Many web applications demand more flexible or user friendly ways to log
into the server, and so every application server out there has developed
its own custom login subsystem to make this happen.
Usually implementing some kind of single signon involves standardising
on a particular brand of application server, with lots of unpleasant
side effects caused by the lockin that results, or a ridiculously heavy
server platform to do a simple login form.
It would be significantly simpler to teach Apache how to do form logins,
and hide each vendor specific application server behind a reverse proxy
that handles the login. The missing piece of course is the module
mod_auth_form to make this happen.
Writing mod_auth_form uncovered an underlying issue - once the user
credentials have been captured from the form, they need to be stored
within a session somewhere that persists across browser requests.
Different application servers have different methods for handling
sessions, each with its own strengths and weaknesses. Some sessions are
stored as Java objects, and can only be shared with other Java based
application servers. Some sessions might be stored in a database, which
then presents a scaling problem.
It became clear that the "session problem" was an issue all on its own,
and that one size definitely does not fit all.
The solution was an Apache module called mod_session, which provides a
simple and generic "session" interface to httpd.
What is a session?
A session is a simple table of key value pairs. The significance of the
key value pairs is up to the user of the session. In the case of
mod_auth_form, it cares about two keys called "user" and "pw".
Where do the sessions get stored?
That's up to further small submodules, which can be chosen by the
administrator depending on their needs.
mod_session_dbd stores sessions within a SQL database. The session is
tracked by a cookie, very similar to a typical Tomcat session. The catch
is that you need a database beefy enough to handle the resulting load,
which may or may not be a problem for the admin, they can decide.
Alternatively, mod_session_cookie stores sessions directly in a cookie
on the browser. No server resources are taken up by sessions, which
makes this very efficient. Obviously privacy is an issue, which is
potentially solved by:
mod_session_crypto encrypts and decrypts the contents of a session
before the session is either written to a SQL database, or sent to the
user in a cookie. Being pluggable, mod_session_crypto can be excluded
from the server where restrictions exist on the use of encryption.
Who can use the session?
Any other Apache or third party modules can use the session interface,
and the hope is that having a standard session raises the chance that
modules may be able to cooperate on how they share data.
mod_auth_form is the first obvious customer. Even CGI programs have a
mechanism to access the session, if allowed by the admin.
So where are the modules?
The mod_session and mod_session_cookie modules are done and documented,
and the plan is commit them shortly to give them a wider audience and
get feedback on them.
The mod_session_crypto module is also done and documented, however I
want to commit that separately so that issues with how the crypto is
handled can be approached as a separate unit.
The mod_session_dbd module is written but not yet completely tested, and
the mod_auth_form module is written, tested, but not yet documented.
This should be completed over the next few days.
Why so many modules?
Breaking the problem down into individual components has made the
session handling significantly simpler to work with and understand. In
addition, the use of crypto has dictated that the crypto portion be
pluggable for those regions where it is required to be excluded.
It is hoped that with a standard session interface, the number of ad-hoc
solutions out there for solving the session problem can be reduced
significantly.
I hope to have the bulk of this committed before Apachecon so that
people can take a look. Will follow up shortly.
Regards,
Graham
--
|