www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gavin" <ga...@16degrees.com.au>
Subject RE: Centralised authentication/authorisation
Date Tue, 25 Nov 2008 11:01:21 GMT


> -----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
> 



Mime
View raw message