Re: Proposal: Support custom authentication methods using hooks

Greetings,

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2022-02-28 11:26:06 +0100, Peter Eisentraut wrote:
> > We already have a variety of authentication mechanisms that support central
> > management: LDAP, PAM, Kerberos, Radius.
>
> LDAP, PAM and Radius all require cleartext passwords, so aren't a great
> solution based on the concerns voiced in this thread. IME Kerberos is
> operationally too complicated to really be used, unless it's already part of
> the operating environment.

... which is very, very, very often is, wrt Kerberos.

> > What other mechanisms are people thinking about implementing using these
> > hooks?
>
> The cases I've heard about are about centralizing auth across multiple cloud
> services. Including secret management in some form. E.g. allowing an
> application to auth to postgres, redis and having the secret provided by
> infrastructure, rather than having to hardcode it in config or such.

This sounds a lot like OAUTH or similar, which might be useful to
consider adding if it can be done reasonably.

> I can't see application developers configuring kerberos and I don't think
> LDAP, PAM, Radius are a great answer either, due to the plaintext requirement
> alone? LDAP is pretty clearly dying technology, PAM is fragile complicated C
> stuff that's not portable across OSs. Radius is probably the most realistic,
> but at least as implemented doesn't seem flexible enough (e.g. no access to
> group memberships etc).

Great thing about Kerberos is that, in general, application developers
don't really need to do much to configure it.

> Nor does baking stuff like that in seem realistic to me, it'll presumably be
> too cloud provider specific.

I don't quite buy an argument that hinges on the idea of centralized
auth across multiple cloud services, as suggested above, while also
being too cloud provider specific to be something that could be baked
in, as said here. Maybe I'm misunderstanding. Also a bit concerned
that adding hooks on presumptions about what some cloud provider needs
isn't a good plan.

In general though, I'm certainly more supportive of the idea of adding
support for authentication mechanisms that are standardized and work
across multiple cloud providers and services in general, than about
adding things which are specific to one provider. I don't particularly
care for the idea of adding hooks and then having cloud providers go off
and develop their own proprietary authentication system that aren't
standardized and which don't have public review, which seems like it's
the use-case for adding them. I'm not dead-set against it, but it just
doesn't strike me as a good area to add hooks for folks to use. Better
would be baked in code that follows a well defined and reviewed RFC that
anyone can look at and make sure follows the standard.

Thanks,

Stephen