On Sat, Nov 24, 2012 at 8:41 PM, Chris Travers <chris.travers@gmail.com> wrote:
> 2) PostgreSQL allows you to move this authentication to a secondary service
> like Kerberos, LDAP, or anything PAM supported. This means that if you want
> to you can use a dedicated password store for the passwords which is not
> accessible inside your database at all.
Drawing a side point from this comment.
We have some pieces of information that are global and public (basic
configs and stuff), some that are private to one particular client's
login, and some that are admin-only. Ideally, I'd like to have them
all stored in one PG database, because some of them interact (eg
there'll be joins involving the current client's info in table X and
the public info in table Y). Currently, we're doing the same as the
OP, with application-defined security based on a table of hashed
passwords. Is there a way to arrange security such that this can be
done efficiently? There are quite a few cases when public information
is needed and a client's login isn't yet available, and I'd rather not
have to connect using a public-only login, then disconnect and
reconnect when we have the user's credentials.
ChrisA
