Re: Application user login/management

From: Michael Glaesemann <grzm(at)myrealbox(dot)com>
To: "Scott Marlowe" <smarlowe(at)qwest(dot)net>
Cc: pgsql-general(at)postgresql(dot)org, Jason Sheets <jsheets(at)idahoimageworks(dot)com>
Subject: Re: Application user login/management
Date: 2004-10-13 01:54:24
Message-ID: CF09DFE8-1CBA-11D9-B5A7-000A95C88220@myrealbox.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Thank you, both Scott and Jason, for your responses. You both brought
up things I hadn't thought about. I've included snippets of their posts
below.

> On Sun, 2004-10-03 at 22:23, Michael Glaesemann wrote:
>> 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.

On Oct 4, 2004, at 1:48 PM, Scott Marlowe wrote:

> 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.
<snip />
> 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.

>> Method 2: Store username/password information as data in tables,
>> using pgcrypto for authentication

On Oct 4, 2004, at 1:53 PM, Jason Sheets wrote:

> If you are confident that (a.) you will either run the database server
> or (b.) have the authority to require that pgcrypto be installed on
> the database for all installations this may be a good solution. Keep
> in mind you are limited to the encryption types supported by pgcrypto
> and moving to another database solution may be difficult. I also
> can't comment on the availability of pgcrypto on Win32 but with
> PostgreSQL 8 just around the corner the desire might be there to run
> the DB on Windows at some point. libmcrypt is currently available in
> win32 but I've occasionally seen behavior differences with it on win32
> v.s. Unix.
>
> Also keep in mind that if you are not using encrypted database
> connections (using PostgreSQL's built in SSL support or SSH tunneling
> or another technique) you may be sending user's passwords across the
> network in plain text for the database to use. I would either insure
> that all connections will be encrypted or preferably at hash the
> password with at least SHA-1 on the application side and pass that as
> the password to the back-end, SHA-1 is available in almost all
> languages these days; this technique may also remove the requirement
> of using pgcrypto on the back-end.

As with many things, there are tradeoffs. As I'm going to be running
the database server, I think I'm going to push the pgcrypto solution as
far as it will go. Thanks again, to both of you, for your comments.
Much appreciated!

Michael

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Fuhr 2004-10-13 02:09:10 Re: Change primary key in Postgres 7.3?
Previous Message Armen Rizal 2004-10-13 01:44:47 Re: Reusable pl/pgsql samples ?