On Sun, 2004-10-03 at 22:23, Michael Glaesemann wrote:
> Hello all,
>
> Recently I've been thinking about different methods of managing users
> that log into a PostgreSQL-backed application. The users I'm thinking
> of are not necessarily DBAs: they're application users that really
> shouldn't even be aware that they are being served by the world's most
> advanced open source database server. I appreciate any thoughts or
> feedback people may have, as I'm trying to decide which is the most
> appropriate way to move forward.
The method I worked with was similar to your method 3, of maintaining
the info in tables, but more complex, and easier to handle for large
numbers of users.
We built an OpenLDAP server and wrote some scripts to maintain that and
allow for group editing. This structure existed completely outside of
the either the database or application. Then, apache handled all the
authentication through ldap authentication. The application was give
standard libs / includes that allowed for pushing a username up against
any group, etc... So that all the yes / no of being allowed somewhere or
allowed to do something was kept in the LDAP database.
This allowed us to allow owners of given groups to edit them by
themselves, i.e. the Director of Marketing could both add other junior
admins to the marketing groups, and could edit members of all the
marketing groups. Note that these groups / authentication are then
accessible to all other applications in the company that are LDAP
aware. And there's a lot of stuff that can work with LDAP and / or
apache/http auth against LDAP authentication.
This allows you to scale your authentication and group management
independently of any scaling issues with your application servers.
Since single master / multi slave OpenLDAP is a pretty easy thing to
implement, the only applications that need to access the master can be
set to the ldap editing applications (group editor, update scripts,
etc...) while standard old authentication can be pointed at one or more
slaves.
