On Fri, 2007-07-13 at 06:53 -0400, Robert Treat wrote: > > Well if you do the popular technique of doing everything through stored > > procedures (in our case plpgsql functions) then you can have those > > functions check. I don't like that approach myself though. > Right. This approach always seemed "too late" to me, since the user was > already connected at that point. I agree with both of you: I would rather have the client to use its certificate to login to PostgreSQL, like some other database is capable of. However, given that this is not (currently) possible (as far as I know), I have to consider workarounds. And one of those is to have the client use a certificate for the underlying connection, restrict access to the database to stored procedures, and have those stored procedures use sslinfo to obtain the certificate data. On my system, I want different people to access the same database, but I have to make sure they cannot access other peoples data. If I just let them use certificates for the underlying connection, without further checks at the database level, I do not think I can make sure user A doesn't get user B's data, if he/she wants to. My initial design of the system included a front-end on the server to which all clients connect, which would translate/check the queries. I then thought it would be easier if this would all be done by the database server, using stored procedures. Basically, that means I'm changing my front-end from a separate application to a set of stored procedures. Note that, for my case, the set of different queries a client can do is pretty limited, so I can easily write a stored procedure for all queries in the set. If there is some alternative that is easier to implement, please let me know! Koen
