Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: "Gavin" <gavin@16degrees.com.au>
To: <infrastructure-dev@apache.org>
References: <55ef8e0d508559e7567041e44f6c61d5.squirrel@mail.pc-tony.com>
 <492B57AB.3010003@apache.org> <1227608308.9859.1857.camel@urgyen>
Subject: RE: Centralised authentication/authorisation
Date: Tue, 25 Nov 2008 21:01:21 +1000
Message-ID: <F1662BA63CA74608A1FE1272618C7188@developer>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1227608308.9859.1857.camel@urgyen>
Thread-Index: AclO56zIOAppkWK7SPqKIi8//55PZwAA2AmQ


> -----Original Message-----
> From: Upayavira [mailto:uv@odoko.co.uk]
> Sent: Tuesday, 25 November 2008 8:18 PM
> To: infrastructure-dev@apache.org
> Subject: Re: Centralised authentication/authorisation
> 
> On Tue, 2008-11-25 at 01:40 +0000, Tony Stevenson wrote:
> >
> > Tony Stevenson wrote:
> >
> > >
> > > A few people have helped start gathering requirements, and ideas here
> ->
> > >
> > > https://svn.apache.org/repos/asf/infrastructure/trunk/projects/ldap-
> project/
> > >
> >
> > I have just updated these a little.
> >
> >
> > Leading on from this, there are several steps that need to be
> > considered.  This primarily revolves around the schema design, and which
> > product(s) should be considered.
> >
> > Does anyone have any ideas how you think the schema should look? There
> > is an initial document in the SVN repo.
> >
> > What about the concepts of using Kerberos and/or certificated?
> 
> My one thought from browsing the proposed schema is that we have two use
> cases, committers and admins. Personally, at this point in time, I think
> we should be focussing on committers. That is where the scaling issues
> are. Adding Jack Black as root on hermes is a simple one off job that
> doesn't happen too often, so we can stick with our current scheme for
> the time being.
> 
> Providing a centralised authentication scheme for SVN, Jira, Bugzilla,
> Moin and Confluence will be enough work as it is!

Confluence and Jira *shouldn't* be that hard. It already supports LDAP
either directly or via Crowd (Crowd delegates to LDAP/AD).

See :-

http://confluence.atlassian.com/display/DOC/Add+LDAP+Integration

and

http://www.atlassian.com/software/jira/docs/v3.13/ldap.html

However, I'd need to look at these more closely, the Jira LDAP method uses
their osuser method still in the latest Jira release, yet Confluence uses a
different 'atlassian-user' method and marks the 'osuser' method as
deprecated, so a conflict in terms of design I'd like to investigate more,
though I'm sure if each is individually configured wont pose a problem.

Personally, I'd like to see Crowd used for Confluence & Jira and then let
Crowd delegate to LDAP.

I'd go even further than that and suggest we apply for Jira Studio - which
combines Jira/Confluence/Fisheye/Crucible/Crowd (and Subversion) .

http://www.jira.com/tour/

The only ones out of that pack we don't use are Crowd and Crucible, Fisheye
some projects use off site.

Gav...(dons flack jacket)

> 
> Upayavira
>