On 05/28/2013 04:04 PM, Amit Langote wrote: > On Tue, May 28, 2013 at 2:32 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: >> On 05/11/2013 03:25 AM, Robert Haas wrote: >>> Not really. We could potentially fix it by extending the wire >>> protocol to allow the server to respond to the client's startup packet >>> with a further challenge, and extend libpq to report that challenge >>> back to the user and allow sending a response. But that would break >>> on-the-wire compatibility, which we haven't done in a good 10 years, >>> and certainly wouldn't be worthwhile just for this. >> We were just talking about "things we'd like to do in wire protocol 4". >> >> Allowing multi-stage authentication has come up repeatedly and should >> perhaps go on that list. The most obvious case being "ident auth failed, >> demand md5". >> > I wonder what you think about continuing to use the already > established connection to the server while you move onto perform > authentication using next method in the list. That's precisely what I'm talking about. It'd be nice to avoid the ugly two-connection approach for SSL too, by allowing STARTTLS or similar within the protocol.
Being able to negotiate connections - client says "peer?", server says "failed, peer id doesn't match postgresql username", client says "md5 <password>?" server says "yup, that's ok" - would be nice. For example, use Kerberos or SSPI where clients are suitably enabled, then fall back to MD5 where Kerberos or SSPI single-sign-on isn't available. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
