Subject: Re: Community accounts
From: Magnus Hagander <magnus@hagander.net>
To: Dave Page <dpage@pgadmin.org>
Cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-www@postgresql.org
In-Reply-To: <937d27e10803121227m78ff33fbk865153acdbef5225@mail.gmail.com>
References: <200803122010.51758.peter_e@gmx.net>
	<937d27e10803121227m78ff33fbk865153acdbef5225@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 12 Mar 2008 22:03:37 +0100
Message-Id: <1205355817.5803.6.camel@mha-laptop.clients.sollentuna.se>
Mime-Version: 1.0


On Wed, 2008-03-12 at 19:27 +0000, Dave Page wrote:
> On Wed, Mar 12, 2008 at 7:10 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > Are the "community accounts" (used by the wiki, for example) available to
> > authenticate against from remote services, for example via LDAP?  I might
> > like to use them for the Git service, for example.
> 
> Not yet - the Wiki is the fisrt truly external resource to be
> integrated, and although we did consider LDAP and OpenID, in the end
> we decided that a custom auth plugin for mediawiki using the backend
> database API via SSL connection was the least painful option.
> 
> We could certainly look at LDAP/OpenID more closely though.

Absolutely. The idea is to make it available to all services that could
use them. What options are available for GIT?

LDAP is probably the most complex of available protocols for something
as simple as authentication, but if that's all it can do, we could
certainly look at the possibility.


> > Also, is there a plan for keeping "community" accounts, PgFoundry accounts,
> > and developer.postgresql.org shell accounts the same, lest we create a big
> > mess?
> 
> I'm certainly interested in doing so for pgFoundry if we can figure
> out how given the interaction between the GForge and OS
> authentication. I'm not so wild about the developer shell accounts as
> we've actually only got a handful of those left anyway - and most are
> for the sysadmin team who don't necessarily want centralised
> authentication in case something goes horribly wrong leaving the
> entire domain inaccessible.

+1 on both those.

//Magnus