Summary: [apache-modules] Session/Cookie-Based Authentication Library
[cross posting to two mailing lists] So far I've received two recommendations about a C library to help authenticate users based on cookies (and optionally IP/URL/etc.): Reginald De Crombrugghe recommended mod_auth_tkt (one of the libraries which were mentioned in my original question), and Ian Holsman (core developer of Apache httpd) recommended mod_auth_mda. There are many alternatives, but the amazing point that I found out immediately after looking at these two libraries, was that they are a fork of the same base (which was called mod_auth_tkt). Meanwhile, since the fork, both have added features and changes, so I'll have to investigate these changes and adopt the better one. By the way, both support only cookies based sessions. If anybody else has anything to add about the differences between these library, or even about another library which does the work, please speak now or forever hold your peace ;-) (just kidding...) As for the long run, I plan to write my own piece of code, based on libapreq2; I plan to open it, of course. Meanwhile, I want to thank Ian and Reginald for their generous help! -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: Summary: [apache-modules] Session/Cookie-Based Authentication Library
Eli Marmor wrote: As for the long run, I plan to write my own piece of code, based on libapreq2; I plan to open it, of course. Meanwhile, I want to thank Ian and Reginald for their generous help! I've seen lots of people ask for this. It might not be bad idea to make a libapreq2-util code base for things like this that depends on libapreq2. Similiar to the apr, apr-util setup ? I guess that would go in: asf/httpd/apreq-util/trunk ? -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/ Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: Summary: [apache-modules] Session/Cookie-Based Authentication Library
On Sun, 2005-09-25 at 18:45 +0300, Eli Marmor wrote: If anybody else has anything to add about the differences between these library, or even about another library which does the work, please speak now or forever hold your peace ;-) (just kidding...) Only because of the forever hold your peace bit... :-) Yours truly has written mod_spin (and this is therefore a shameless plug), which can also be used for such a purpose in conjunction with one of its applications, spin_auth. For now (as of version 1.0.10), only pages that are mod_spin templates can be authenticated using this code. New development code (unreleased mod_spin 1.1.0) can provide authentication for any URL. The whole thing is based on regular Apache basic authentication, so whatever Apache supports, this supports. One creates a URL that is going to be the authentication point and if the user gets in, this is recorded in the session file (this can be shared between servers if you have a clustered file system like GFS). This authentication can be over SSL/TLS (i.e. to prevent basic authentication being ripped to shreds), although the site can be a plain HTTP site. The cookie is base on mod_unique_id, but it is accompanied by an MD5 digest of itself and a salt (at least 30 characters) defined in the configuration file. The salts can be periodically rotated by an external script to further strengthen the digest. This requires a graceful restart of the server (which can be, of course, done under load - compliments of Apache developer :-). How good/bad and how (in)secure this whole thing is, you will have to judge for yourself, as this is not really a community project, but my own little concoction. The code is licensed under the GPL with exception to link with Apache and libapreq2. -- Bojan
Re: Session/Cookie-Based Authentication Library
Max Kellermann wrote: On 2005/09/22 14:11, Eli Marmor [EMAIL PROTECTED] wrote: By the way: it may be based on libapreq2. And if I come into it, then what about the following idea: to add some authentication functions to libapreq2; In any case, it already does most of the work, including GET/POST parameter manipulation, as well as cookie manipulation. I believe we should not add anything about authentication to libapreq. It is currently a generic request parser, and should stay so. Adding authentication would require to make assumptions about the authentication procedure, which in turn forces users to follow our assumptions. There is no disadvantage in implementing authentication in an additional library. Sorry for being not enough clear: I didn't speak about HTTP authentication, and even not about a library doing the authentication for you. All I spoke was about some convenient routines that may save 80% of the work for people who implement cookies-based or session-based authentication. And I'll add a brief explanation for people who don't control exactly how this authentication works: The username and the password are received from the user by a POST request, optionally encrypted (by SSL, or by JavaScript, etc.). From now on, the programmer marks the session, so following requests will be identified as coming from this specific user. This can be done in two ways: by setting a unique cookie (usually temporary), or by adding a unique hidden arg=val to following requests/responses (sessionization). There must be a special URL/module/whatever for logout. Cookies may be not temporary, so following accesses to the site, will cause the username field of the login form to be initialized with the value from the previous time (of course, this is optional). While it's easy to describe this mechanism, its implementation (without the help of any library) is hard. Implementation based on a library like libapreq2 saves the effort by at least 50%. All I suggested was to add some convenient routines that will ease this effort further. For example, a function to create an encrypted code to be used as the unique cookie or session-id. Or obtaining the code from a request. Or getting the username out of a request struct. Or using the input filter to consume the session-id from the QUERY_STRING (or the POST params) so filters/modules following in the chain will not see it. This extra API is so thin, and will be very easy to code, because most of its work is already done by lower level functions of libapreq2. -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
