On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> What about auth_protocol then? It seems to me that it could be
> useful
> to have the restriction on AUTH_REQ_MD5 as well.
auth_protocol does sound like a good name. I'm not sure what you mean
regarding MD5 though.
> This makes it sound like there is a linear hierarchy among all those
> protocols, which is true in this case, but if the list of supported
> protocols is extended in the future it may be not.
We already have that concept to a lesser extent, with the md5
authentication method also permitting scram-sha-256.
Also note that the server chooses what kind of authentication request
to send, which imposes a hierarchy of password < md5 < sasl. Within the
sasl authentication request the server can advertise multiple supported
mechanisms, though, so there doesn't need to be a hierarchy among sasl
mechanisms.
> I think that this should have TAP tests in src/test/authentication/
> so
> as we make sure of the semantics. For the channel-binding part, the
> logic path for the test would be src/test/ssl.
Will do.
> Another thing that was discussed on the topic would be to allow a
> list
> of authorized protocols instead. I personally don't think that we
> need to go necessarily this way, but it could make the integration of
> things line scram-sha-256,scram-sha-256-plus easier to integrate in
> application flows.
That sounds good, but there are a lot of possibilities and I can't
quite decide which way to go.
We could expose it as an SASL option like:
saslmode = {disable|prefer|require-scram-sha-256|require-scram-sha-
256-plus}
But that doesn't allow for multiple acceptable mechanisms, which could
make migration a pain. We try to use a comma-list like:
saslmode = {disable|prefer|require}
saslmech = all | {scram-hash-256|scram-hash-256-plus}[,...]
Or we could over-engineer it to do something like:
saslmode = {disable|prefer|require}
saslmech = all | {scram|future_mech}[,...]
scramhash = all | {sha-256|future_hash}[,...]
scram_channel_binding = {disable|prefer|require}
(Aside: is the channel binding only a SCRAM concept, or also a SASL
concept?)
Also, working with libpq I found myself wondering why everything is
based on strings instead of enums or some other structure. Do you know
why it's done that way?
Regards,
Jeff Davis