Re: [HACKERS] Authentication mechanisms categorization

On Fri, Jul 14, 2017 at 12:16 PM, Álvaro Hernández Tortosa
<aht@8kdata.com> wrote:
>     If the parameter authmethod would rather be "authmethods", i.e., a list,
> I think it would be significantly more flexible.

Yes, but the handling of a list becomes messier if there are some
other connection parameters that are dependent on the authentication
method. Say if a list made of scram-sha-256 and scram-sha-3 as methods
is sent, and a parameter named saslchannel lists scram-sha-256-plus is
used, this becomes unusable with scram-sha-3. Using individual names
for a parameter makes interactions with other parameters easier to
handle and less bug-prone. That's also by experience more flexible for
the application.

>     I agree with a list of methods and all the values already existing for
> sslmode, this might be more than enough, specially if the channel binding
> SCRAM mechanisms would get a different authmethod than their non-channel
> binding partners (like scram-sha-256-plus). This makes the list argument for
> the authmethods, in my opinion, stronger.

For the channel binding patch, I have actually implemented saslname to
enforce the name of the SASL mechanism name to use (SCRAM-SHA-256 or
its -PLUS) as well as saslchannelbinding to enforce the channel
binding type. That's very handy, and at the end I saw that having a
list does not add much value in a feature that should be as simple as
possible as the client will use one match at the end for
authentication, and let the client know if it failed or succeeded (yes
I hate sslmode=prefer which does up to two attempts at once). But
that's as far as my opinion stands.

It is not possible to know the future, but we cannot discard as well
the fact that a future authentication method, say hoge could as well
support scram-sha-256, in which case cases like that using a list
"authmethods=hoge,sasl authmechanisms=scram-sha-256" would mean that
scram-sha-256 needs to be enforced for both things, but the dependency
handling makes things unnecessary complicated in libpq. My argument
here is crazy though.
--
Michael