Re: Application user login/management
От | Scott Marlowe |
---|---|
Тема | Re: Application user login/management |
Дата | |
Msg-id | 1096865293.10475.7.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Application user login/management (Michael Glaesemann <grzm@myrealbox.com>) |
Ответы |
Re: Application user login/management
|
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: