Re: "Optional ident" authentication

Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> Tom Lane wrote:
>>> You can accomplish that with
>>>
>>> local sameuser all ident sameuser
>>> local all all pam
>
>> You put "sameuser" in the database column instead of the "user" column -
>> was the intentional? I've just tried this with "sameuser" in the user
>> column, and it didn't work for me.
>
> You're right, I was confusing the database-column feature with what's
> involved here. There isn't really any way for "sameuser" to work in the
> user column, since that would require a way to identify the user's
> non-database username, which is exactly the province of the auth method.
> So never mind :-(.
>
> But I still question whether Jeroen's got any real use case that can't
> be handled the other way, viz

While I agree that the original proposal was a bit hackish, I'd love
to be able to specifiy "First try this auth method, and fall back to
another if the first didn't succeed".

I, for example, have a large ldap directory that contains one posixAccount
entry for each of my customers. Postgres on my database server authenticates
against that directory via pam, and my webservers are set up to run each
customers cgi-scripts under his own account. To make things easier
for customers, the webserver is running gidentd, and my database server uses
ident authentication for connections from the webserver. Thus you only need
to specify the database name and the hostname of my db server in cgi-scripts -
no need for passwords (or usernames).

Now, sometimes a customers cgi-scripts needs to be able to connect to another
customers database. Currently, I need to change pg_hba.conf to let him do that.
If I could chain authentication methods, I could just tell my customers they need
a password to connect to a foreign database, but don't one one to connect to their
own database.

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.

If there is a chance that a patch like that would be accepted I could try to
modify Jeroen's patch to support that - but I have very little free time at
the moment, so it might take me a while to get it done...

greetings, Florian Pflug