On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion <jchamp...@timescale.com> wrote: > > No, that's the opposite, and exactly the point I'm trying to make. In > > that case, the SERVER says what it's willing to accept, and the CLIENT > > decides whether or not to provide that. In your proposal, the client > > tells the server which authentication methods to accept. > > Ah, that's a (the?) sticking point. In my example, the client doesn't > tell the server which methods to accept. The client tells the server > which method the *client* has the ability to use. (Or, implicitly, > which methods it refuses to use.) > > That shouldn't lose any power, security-wise, because the server is > looking for an intersection of the two sets. And the client already > has the power to do that for almost every form of authentication, > except the ambient methods. > > I don't think I necessarily like that option better than SASL-style, > but hopefully that clarifies it somewhat?
Hmm, yeah, I guess that's OK. I still don't love it, though. It feels more solid to me if the proxy can actually block the connections before they even happen, without having to rely on a server interaction to figure out what is permissible. I don't know what you mean by SASL-style, exactly. -- Robert Haas EDB: http://www.enterprisedb.com
