[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working on a security best practices document



Hi Luke;

On Thu, Feb 4, 2010 at 10:14 AM, Luke <..hidden..> wrote:
After reading your [Chris's] explanation to Michael about the way auth is
handled in 1.3, something occurred to me.

In the current system, the application itself handles all authentication.
It deals with the DBM directly on behalf of all users.

In the new system, you are offloading authentication to the web server,
and are therefore limited to the auth and encryption schemes offered by
Apache et al?

Actually offloading authentication to the database, since it then also enforces permissions.

I was not following the discussion very closely until the last couple
of messages; apologies.

So what exactly is the sequence of authentication, SSL aside?

1) 401 error
2)  Browser sends authentication information
3)  Apache sends raw auth information to LSMB
4)  LSMB decodes auth info
5)  LSMB logs into db with auth info provided by browser.  On unsuccessful login, sends 401 error.
6)  LSMB retrieves user configuration info etc.  On lack of info, throws an application error.
 
Stages 1 + 2 are usually automated via _javascript_.  If JS is turned off, you get an http auth prompt.

I will note re SSL, that I may not want SSL, etc., in an (Open)VPN based
environment.  Not that it would be too detromental to use, but it is an
unnecessary layer with pre-established P2P tunneling.

Or require end-to-end ipsec with the web server, or require any of a number of other things.....  However, these are (generally) more blunt than SSL which tends to protect individual ports, not the entire TCP/IP infrastructure connecting to the web server.

I personally don't like SSL much, but it is the standard way of protecting web apps.....

Best Wishes,
Chris Travers