Looking at using LDAP to ease the pain of maintaining user accounts across
many tens of PostgreSQL servers ...
As documented, LDAP solves a few of the problems we have -- since everyone
will be in LDAP, we can use LDAP's password complexity rules and password
expiration to handle those security requirements, and (of course) when
someone changes their password, they don't have to remember to change it
on every server ... these are big wins.
But it doesn't help with the headache of creating the accounts on all the
servers, or dropping them as part of employee termination procedures, or
doing security audits, or changing permissions on multiple servers when
an employee gets a promotion, etc.
What would help with those challenges, is if PostgreSQL didn't need to have
a mapping of LDAP -> PostgreSQL account. Instead, something where PostgreSQL
checked some LDAP attribute(s) for a list of database roles and used those
to determine what access to allow.
For example:
* In LDAP, have a user wmoran
- That user has an attribute like "databaseRoles=analyst,beancounter"
* In PostgreSQL, there is no user called wmoran
* In PostgreSQL, there are roles called analyst and beancounter
* Table permissions are GRANTed to analyst and/or beancounter as appropriate
Thus, when I go to log in as wmoran, LDAP checks my password, then informs
PostgreSQL to allow me in with specified roles, and I can do operations
granted to those roles.
Obviously, that's not how it works now ... my question is why not? Is it just
a matter of nobody's gotten to it yet, or are there issues that make such
an implementation difficult/troublesome/impossible? If it's possible, does
anyone have any concept of how hard it would be to implement?
--
Bill Moran <wmoran@potentialtech.com>
