Magnus,
* Magnus Hagander (magnus@hagander.net) wrote:
> I thought of another issue with this. My "grand plan" includes being
> able to do username mapping (per pg_ident.conf) for other authentication
> methods than ident. Specifically this would be interesting for all
> external methods, like gssapi/sspi/kerberos/ldap. I was originally
> planning to allow each row in pg_hba to specify it's own pg_ident.conf
> if necessary (so you could map LDAP and GSSAPI differently, for example,
> or map two different kerberos realms differently). To be able to load
> these, the postmaster would need to know about them, which means it'd
> have to parse that data out anyway.
I certainly like the concept of having them be in seperate files.
> The other way to do that is to simply say that all external mapping will
> use pg_ident.conf, and the only thing you can specify on a per-row basis
> is "use map: yes or no". This decreases the flexibility, but would not
> require the postmaster to do the parsing.
I don't think it makes sense to have multiple different auth types using
the same mappings... For Kerberos, as an example, we should support
user@REALM as an option for the mapping, but that might not make sense
for LDAP, which might have cn=User,ou=people,dc=example,dc=com, and
neither of those really make sense for ident. Mashing all of those
together would make each auth type supporting the mapping have to search
through the list trying to make sense of some mappings and throwing away
others, just ugly all around..
> What do people think about these? I know Stephen for example really want
> that feature so - would that restriction make it a lot less useful for you?
If we really wanted to keep it to a single *file*, then I think there
should be a way to key rows in the pg_hba.conf to sets-of-rows in the
mapping file. eg: have an option of 'mapkey=xyz' in pg_hba, and then
'xyz' as the first column of the mapping file, with it being repeated
across rows to form that mapping table.
It wouldn't be very easy/clean to do that w/o breaking the existing
structure of pg_ident though, which makes me feel like using seperate
files is probably the way to go.
Thanks,
Stephen