Re: [HACKERS] Authentication mechanisms categorization
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: [HACKERS] Authentication mechanisms categorization |
Дата | |
Msg-id | 33100fda-c22c-cef2-eb96-3a9336416142@8kdata.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Authentication mechanisms categorization (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Authentication mechanisms categorization
(Bruce Momjian <bruce@momjian.us>)
|
Список | pgsql-hackers |
On 14/07/17 13:29, Michael Paquier wrote: > 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. Hi Michael. I'm mostly convinced by the power of all the parameters that already exist, given that you added both saslname and saslchannelbinding to the already existing sslmode. That's great, and allows for very fine choosing of the auth method. So it would be great if (non-libpq) driver implementations would expose the same parameter names to the users. I will study this for JDBC. My only fear is that this could become very complicated for the user, and could end up looking like the authentication algorithm lists for SSL, which are very hard to digest for the non expert. To handle list of auth methods spread through three parameters, seem to me going a bit in this direction. A categorization like the one proposed, while maybe difficult to do initially, and maybe to maintain too, is just precisely to take this burden out from the user, and expose a simpler setting for them. Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
В списке pgsql-hackers по дате отправления:
Следующее
От: "Joshua D. Drake"Дата:
Сообщение: [HACKERS] autovacuum can't keep up, bloat just continues to rise