Re: "Optional ident" authentication - Mailing list pgsql-hackers
From | Jeroen T. Vermeulen |
---|---|
Subject | Re: "Optional ident" authentication |
Date | |
Msg-id | 24668.125.24.223.209.1164874673.squirrel@webmail.xs4all.nl Whole thread Raw |
In response to | Re: "Optional ident" authentication (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On Tue, November 28, 2006 22:21, Tom Lane wrote: > "Florian G. Pflug" <fgp@phlo.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
pgsql-hackers by date: