On 05/28/2013 04:04 PM, Amit Langote wrote:
> On Tue, May 28, 2013 at 2:32 PM, Craig Ringer <craig@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
