On 10/4/07, Toni Mueller <..hidden..> wrote:
I strongly suggest using the following authentication scheme, after
having battled non-cooperation between several authentication methods
for a while in a different context:
You have a username/password combination set for the application that
the application uses to request eg. authentication data from the
database. Alternatively, you leap and implement OpenID, which "solves"
all other problems for you.
There are a few real reasons for going with PostgreSQL native accounts. These include:
1) Ability to use any authentication system PostgreSQL can connect to (Kerberos, LDAP, PAM, etc. It shouldn't be too hard to write a PAM module for OpenID also...). If you want to authenticate users against NT4/Samba servers, you can do that. If you want to authenticate against Active Directory, you can do that.
2) Security and permissions apply regardless of how a user connects to the db.
Now, when the user is on the login screen, you grab his username and
password, hash, and compare with what's in the database. OR, you use
that data to authenticate to the database (should have pretty much the
same effect). If authentication succeeds, you open a session and set a
cookie to the user. Doing that session+cookie stuff has its own
pitfalls, but I've not yet been able to combine eg. 2x "HTTP Basic
Auth" or 1x "HTTP Basic Auth" + 1x "HTTP Digest Auth" (eg. when working
through a so-called SSL-VPN).
There is a major difficulty here. You can't use the database to enforce the user's permissions in this case in a robust).
What you can do, however, is to modify the cookie on every request, so
stealing a cookie would not necessarily grant immediate access (it
would be invalid once the user has clicked another link). The big
drawback to modifying the cookie on every request is that this disables
working with several tabs open at the same time. OTOH, SSL should be
mandatory anyway and make cookie-stealing almost a non-issue.
1.2 modifies the cookie on every request which causes some issues with tabs (
i.e. 2 documents cannot load at the same time). 1.3 is going to require authentication information and a session cookie for every request but the session cookie will be static.
_javascript_ should IMO be out of the question, however, and only be used
for pure convenience functions. Accessibility should be a core
requirement.
_javascript_ in this case is used to provide an alternate login screen to those browsers which can use AJAX. If _javascript_ doesn't exist, the login becomes a 2-step process (select your company, ok now provide username/password).
The big issue I am runnng into is that Firefox and presumably other browsers prompt for HTTP Auth credentials when the XMLHttpRequest object receives a 401. I am working on a solution to that at the moment. (I am trying to do something with minimal misuse of the standars.)