Re: WIP: SCRAM authentication - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: WIP: SCRAM authentication
Date
Msg-id 20150809210557.GI3685@tamriel.snowman.net
Whole thread Raw
In response to Re: WIP: SCRAM authentication  (Sehrope Sarkuni <sehrope@jackdb.com>)
Responses Re: WIP: SCRAM authentication  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
* Sehrope Sarkuni (sehrope@jackdb.com) wrote:
> It'd be nice if the new auth mechanism supports multiple passwords in the
> same format as well (not just one per format).
>
> That way you could have two different passwords for a user that are active
> at the same time. This would simplify rolling database credentials as it
> wouldn't have to be done all at once. You could add the new credentials,
> update your app servers one by one, then disable the old ones.
>
> A lot of systems that use API keys let you see the last time a particular
> set of keys was used. This helps answer the "Is this going to break
> something if I disable it?" question. Having a last used at timestamp for
> each auth mechanism (per user) would be useful.

Excellent points and +1 to all of these ideas from me.

> I'm not sure how updates should work when connecting to a read-only slave
> though. It would need some way of letting the master know that user X
> connected using credentials Y.

That wouldn't be all that hard to add to the protocol..

What would be nice also would be to include slave connections in
pg_stat_activity, so you could figure out what transaction on what slave
is causing your master to bloat...  And then if we could send signals
from the master to those processes, it'd be even nicer..
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Precedence of standard comparison operators
Next
From: Tom Lane
Date:
Subject: Re: Precedence of standard comparison operators