Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2022-03-17 12:10:51 +0100, Peter Eisentraut wrote: > > Looking at the existing authentication methods > > > > # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256", > > # "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert". > > > > how many of these could have been implemented using a plugin mechanism that > > was designed before the new method was considered? Probably not many. > > trust, reject, md5, password, ident, peer, pam, ldap, radius look trivially > possible. I think sspi is doable as well, but I don't know it well enough to > be confident. gss without transport encryption could have as well, I > think. Even scram-sha-256 looks possible, although that'd have been a good bit > harder. Where do you see the problems?
I agree with Peter and don't feel like the above actually answered the question in any fashion. The question wasn't "which auth methods could be implemented using these new set of hooks?" but rather- which could have been implemented using a plugin mechanism that was designed *before* the new method was considered? The answer to that is 'basically none'. There even existed a plugin mechanism (PAM) before many of them, and they weren't able implemented using it. That's entirely the point- while this might be an interesting way to redesign what we have now, should we feel that's useful to do (I don't and think it would be an actively bad thing for the project to try and do...) there's no reason to believe that it'll actually be useful for the *next* auth method that comes along. > Only stuff tying into transport encryption is clearly not doable via the > proposed API, but that's hardly the fault of an authentication API? This is absolutely the wrong way to look at it. The authentication methods that are coming along today are designed to tie into the transport encryption because that's *needed* to avoid MITM attacks. I'd much rather we generally avoid including ones that don't support that and we certainly shouldn't be trying to build a generic system which explicitly doesn't support it. Thanks, Stephen
signature.asc
Description: PGP signature
