Partial authentication (was Re: sefety of passwords for web-service applications)

From: Chris Angelico <rosuav(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Partial authentication (was Re: sefety of passwords for web-service applications)
Date: 2012-11-24 11:37:18
Message-ID: CAPTjJmoSpHF8QiFCXMRnyvz4K-8JTzJqc=fAHxoH_8yON7YoOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Nov 24, 2012 at 8:41 PM, Chris Travers <chris(dot)travers(at)gmail(dot)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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2012-11-24 11:40:15 Re: alter sequence
Previous Message Peter Kroon 2012-11-24 11:32:56 alter sequence