Re: "Optional ident" authentication

On Tue, November 28, 2006 22:21, Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> I believe it would be sufficient to add an additional column to
>> pg_hba.conf
>> called "On Failure". The value could either be "Continue" or "Abort",
>> with
>> the default being "Abort" to match the current behaviour.
>
> Then you get into the problem that it has to work for *all* auth
> methods, which in general it will not, because the client probably isn't
> prepared for multiple auth challenges. Jeroen's kluge avoids that by
> only working for an auth method that doesn't involve a client challenge.

...Or more precisely, by specifying that interactive auth methods
shouldn't ever fall through. I think ident is fundamentally different
from all the other auth methods, and frankly I think the real problem is
that it doesn't quite fit in as one.

Adding an "on failure" field to the config file isn't perfect either,
IMHO, because it only works for failures. With ident, it might also make
sense to stack auth methods in a restrictive way: "this particular login
must be allowed by this ident map *and* authenticate through LDAP as
usual."

I think HBA configuration would work better if more arguments were
possible on the *matching* side of pg_hba.conf, alongside "database" and
"user." Things are already ugly because "ssl" didn't quite fit in there:
that looks like it should've been an optional argument in matching
connections to HBA rules.

If we had optional matching arguments, I think ident would be a matching
option by nature--not an authentication method at all. The existing
"ident sameuser" would be shorthand for a "trust" rule matching on the
ident map, followed by a "reject" rule for the same connections but
without the ident argument. If you left out the "reject," you'd have the
"ident sameuser" behaviour but with fallback to regular authentication.

You could also have separate authentication methods based on what the
system wants for a particular user, without requiring any coupling to
databases or roles. Most of that job should probably be left to PAM where
available, but it just so happens that "ident" does a job that PAM isn't
able to.

But I'll admit that all of that is making things a bit complex and
therefore error-prone.

> The example you cited is easily implemented without any new features,
> anyway, using "samegroup":
>
> local all samegroup ident sameuser
> local all all md5
>
> where users are made members of the group/role named after the database
> they are allowed to log into without a password.

Nice one--at least that way you're not tying database names to user names
(on a side note, I see that "samegroup" is obsolescent--it's "samerole"
now). But AFAICS it still doesn't allow you to fall back to interactive
authentication for "cross-identity" logins: those will just fail even if
you would want the user on the other end to be able to log in, assuming he
knows the password. Yes, you've shown that you can simulate that with the
existing HBA format but I wouldn't want to maintain a configuration like
that!

Jeroen