SEO

Hi,

I´m envolved in developping a website that will function as a frontend for
psql 8.1 cluster.
We use a number of frontend technologies, and we want to keep the
authentication in the backend. Not a system where the frontend queries a
table to verify username password, sets the priviliges on the front end and
logs in as a superuser on the backend. So we need to have username and
password ready at a lot of moments, too many for a user to type it in all
the time.

Since we´re on a very tight time schema, we don´t want to implemt LDAP just
yet, since it will complicate things (even) more. Especially synchronising
user (role) changes between PostgreSQL and the LDAP server seems tricky,
since the database cluster stills keeps its pg_authid tables (right?).
So as a temporary compromise, we decided to store the username and password
in a cookie on the client PC, which is of course a serious weakness.

Can anyone give me some advise on how to do this a better way, without
consuming too much time, or is this the best thing to do in such a
situation?

On Wed, Oct 25, 2006 at 03:49:54PM +0200, Willy-Bas Loos wrote:
> So as a temporary compromise, we decided to store the username and password
> in a cookie on the client PC, which is of course a serious weakness.
>
> Can anyone give me some advise on how to do this a better way, without
> consuming too much time, or is this the best thing to do in such a
> situation?

The usual workaround I'm familiar with is to set a hash of some sort
that is the user, password, and some salt. Then you authenticate
against that hash in your application, so that you never actually
send these values, nor store them anywhere except the database.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

I think that´s not exactly what i´m looking for.

Just to make sure that i understand what you´re proposing (please correctme
if i´m wrong):
I´ll write a function that will create a hash of username, password and, say
'now'::timestamp and store it in a cookie and in a separate table somewhere
on the cluster, if authentication is succesfull.
Then, upon every need for authorisation, the frontend will log into the
database as a highly priviliged user (or allready be logged in), and compare
the hashed values. If they are equal, it will allow certain actions.
After some time, i´ll trigger to delete the hash from the database.
I could still store the user name on the back end, and retreive it with the
provided hash, so that i know what actions to allow. I would then fake
postgreSQL´s authentication by querying the rights and roles for this user.

The problem is that the frontend would in fact have to be some major user
that regulates all authorisation, and the password for it would have to be
stored on the webserver.

What i am looking for is this:
Every time the user / frontend asks for certain data (or actions), he will
or will not receive those, because of the rights granted to him. These
granted rights and roles will be determined by the regular postgres
functionality (and some views).
The frontend does have a low priviliged username and password stored in it,
just to access the web-content.

WBL


On 10/25/06, Andrew Sullivan <ajs@crankycanuck.ca> wrote:
>
> The usual workaround I'm familiar with is to set a hash of some sort
> that is the user, password, and some salt. Then you authenticate
> against that hash in your application, so that you never actually
> send these values, nor store them anywhere except the database.
>

On Thu, Oct 26, 2006 at 12:27:49AM +0200, Willy-Bas Loos wrote:
> or will not receive those, because of the rights granted to him. These
> granted rights and roles will be determined by the regular postgres
> functionality (and some views).

Ah, that's a different matter. My suggestion is "don't do that".
I tried to do it once, years ago, and regretted it deeply. Of
course, my code was awful, and yours might be better. But in my
view, that's a security problem just waiting to happen. You're
better off to have one user in your application that does the
authentication for you. You can use Kerberos or something to
authenticate it; much easier to lock down one such user carefully,
that comes only from boxes under your control, than to secure many
users' accounts.

If you want to do it this way, I sure wouldn't use cookies to store
the password. I think you're asking for a compromise that way.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

> My suggestion is "don't do that".
> I tried to do it once, years ago, and regretted it deeply.

Do you mean "don´t try to fake postgres´ authorisation" (which i don´t want
to),
or "don´t set up your webservice so that users will recieve data according
to their own rights in the database, where each frontend user equals a
database user" (which i do want to)?

WBL