[Melbourne-pm] Web auth meth

Scott Penrose scottp at dd.com.au
Mon Sep 15 19:52:17 PDT 2008


On 16/09/2008, at 12:10 PM, Toby Corkindale wrote:
> Also, are you happy with writing code (or using code) that is  
> shackled to Apache and mod_perl? What if you need to scale up, and  
> run it on lighttpd, IIS, litespeed, nginx, zeus, etc?

No. Don't do that :-)

Think of the mod_perl specific code just as triggers. This is the same  
for writing mod_perl applications. You build your code so that it can  
run independently. And test the same way. Then write the wrapper for  
it in mod_perl. You can do the same for CGI, and then you can (in  
theory) for all other servers.

The argument that says - "Do it yourself in your own code so it is  
portable" does not stand up for two reasons:

* If that argument was true, then you should also write your own web  
server and database and operating system. When do you stop.
* Just because you want to make it portable does not mean you couple  
it into the rest of your code.

But you are talking here about portability - writing authentication  
modules separately makes them not only more portable (well you can do  
anything, you can make it less or more or dependt, or coupled - really  
where you put it doesn't effect that much), but more importantly  
reusable.

You decided tomorrow that what this product needs is job tracking and  
wiki - and you work out that "Trac" is really the best tool for the  
job. You install it and realise - oohh Python - how am I going to  
authenticate?

You now have four choices:

1. You already used/wrote apache module - you have nothing to do.
2. You authenticate in perl and hack Trac to accept the same cookie  
and database
3. You have the user log into the two systems separately
4. You don't have a joined database and you have to register separately.

I am sick of going to places like zimbra.com where I have to have  
separate login & passwords for each of their Wiki (Media wiki), Job  
tracker (Bugzilla), and Form (PHP Forums).

> I don't think this really applies to Apache-based authentication any  
> differently than to non-apache-based auth though. I mean, just  
> because Apache authentication is only available on Apache, and has  
> to be tested using a more convoluted means, doesn't mean it's more  
> secure than if you put effort into testing your other authentication.

Sorry I didn't mean to imply that. What I am talking about is  
separation of code. 99% of the PHP code I have to implement uses their  
own authentication system, built into the script. If one script misses  
that important line at the start "check_auth();" - it goes through un- 
authenticated (a bug I have many times fixed while integrating php  
applications).

You can of course use auth modules in frameworks like Catalyst. These  
are more secure than doing it in your own application, but you are  
still running it in the same process, memory space etc - it is really  
better to do authentication before that.

One final thing before summary - one of my integration tasks I had to  
do involved a Java application on Tomcat. I had to provide it  
authentication (single sign on to the existing products) and modify  
the output (filter) - both were easy thanks to doing it in mod_perl.

Summary:
* Separate security - completely from your code. Your code can't even  
execute unless security passes
* Separate authentication from your application to allow you to mix  
applications. Don't keep re-inventing the wheel by writing yet another  
job tracking system just so you can use your authentication.
* Write reusable and testable code - the authentication module should  
be potentially reusable by other bits of code, even in other languages.
* Avoid binding yourself to a system or language. If you write your  
code to be portable (e.g. Perl on Windows & Linux & Mac) you find that  
your code style and reliability improves. If you build your system  
(eg. authentication) to depend on perl - that makes it hard when you  
want to incorporate a good PHP, or Python module.

Scott


More information about the Melbourne-pm mailing list