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 --
smime.p7s
Description: S/MIME Cryptographic Signature
