Re: SCRAM authentication, take three

On 03/02/2017 08:50 AM, Michael Paquier wrote:
> Attached is a new patch set. I have combined SASLprep with the rest
> and fixed some conflicts. At the same time when going through NFKC
> this morning I have noticed that the implementation was doing the
> canonical decomposition and reordered the characters using the
> combining classes, but the string recomposition was still missing.
> This is addressed in this patch set, and well as on my dev tree:
> https://github.com/michaelpq/postgres/tree/scram

I've now committed the bulk of these patches. Many thanks to everyone
involved, and especially you, Michael, for your persistence!

There are a bunch of loose ends, like the SASLprep thing. But the core
of this patch has been unchanged for some time now, so it's time to move
ahead.

I left out the new CREATE/ALTER USER ... PASSWORD (... USING '<method>')
syntax, after all. I think that's still a good idea, but it turned out
to be largely orthogonal, and this patch was large enough without it.
Let's discuss that separately, in another thread.

Currently, the AuthenticationSASL protocol message specifies the
mechanism that the client must use, but as future-proofing, it'd
probably be best to redefine that to be a list of mechanisms, and let
the client choose among those. That's not a show-stopper, but would be
good to get that right in version 10, so that clients can prepare for
that, even if we only support one mechanism ATM.

I didn't include the last-minute changes to the way you specify this in
pg_hba.conf. So it's still just "scram". I agree in general that we
should think about how to extend that too, but I think the proposed
syntax was overly verbose for what we actually support right now. Let's
discuss that as a separate thread, as well.

I didn't commit the TAP authentication tests yet. I just didn't have the
energy to review it all in one go - I will revisit that in the next few
days.

- Heikki