Advice: "The Right" authentication method

[Matthew Seaman]

On Thu, Sep 23, 2004 at 11:53:40AM +0100, Andy Holyer wrote:
> I'm working on writing the "Control Panel" scripts which subscribers to 
> our ISP will use to set up their eMail accounts and web space.
> 
> Here's the Server spec:
> 
> FreeBSD-Current;
> Perl 5.6.1, no problem installing any needed modules;
> Apache 2;
> I'm keeping ordinary customers off the machine, so I run Postfix and 
> Cyus and use sasl2 for customer passwords. I'd like to use these ID to 
> arrange access to the control panel system.
> 
> I'm stuck at the very start of my design process. I have two tasks to 
> do:
> 
> Verify that users have supplied the correct password; and let the perl 
> scripts know who that visitor is, so that we can select the correct 
> accounts to show.
> 
> Do I use SASL directly? or LDAP? or do I implement an Apache module to 
> handle access and let Apache do the work?
> 
> I want to do "The right thing" - that is, the most general and correct 
> thing possible, I've got years of experience in perl scripting, but at 
> the moment I wandering around in a twisty litte maze of standards, all 
> different.
> 
> Clue, please?

You're basically writing a web application.  For which you need access
control.  You've got two choices: either use the HTTP basic or HTTP
digest auth mechanisms built into HTTP, and supported by Apache, or
(and this is by far the most popular choice) write your own
authentication mechanism as part of your application[1].

The second choice gives you a lot more flexibility about how you
customise things and how you make the login screen look, which is
probably why it's more popular.  You can also arrange things to avoid
sending passwords across the net in cleartext if you're cunning
enough.

However you do it, the authentication process is essentially that the
client sends you two pieces of information: their username (ie. who
they claim to be) and some form of secret.  The secret is usually a
password, but it can be something more complicated like an Opie
one-time password or whatever.  Then in your application you compare
the secret to your stored version of it, and if they match you believe
that the client is who they say they are and that they should have
access.  Of course, you don't want to keep the secret values lying
around in plain text: the standard Unix response to all that is to
generate a password hash using DES or MD5 to store, and to try and
recreate that hash using the password supplied by the user.

That's where SASL comes in: instead of having to code up all that
stuff your self, SASL is a library of authentication methods that you
can just plug into your application.

Yes, you will need some sort of user account database -- often
implemented using a RDBMS, but could with little extra effort be made
to operate against an LDAP or RADIUS server.  Or whatever the database
type you're already using for your Postfix+Cyrus setup.

There are several examples of doing this sort of thing within the
ports system -- most are written in PHP, but check out devel/bugzilla
and www/rt3 for perl based examples.

	Cheers,

	Matthew

[1] Actually, if you were using mod_perl you could write your own
authentication and authorization handlers that would get called by
apache during the normal page serving transaction, effectively giving
you the best of both worlds.  But that requires you to be an expert
mod_perl programmer and to have a lot of experience at writing web
applications.  Save that sort of thing for version 2.0...

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20040923/5a8e45c3/attachment.bin