www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Centralised authentication/authorisation
Date Thu, 27 Nov 2008 10:22:04 GMT
On 27/11/2008, Upayavira <uv@odoko.co.uk> wrote:
> On Thu, 2008-11-20 at 17:54 +0000, Tony Stevenson wrote:
>  > For some time now I been making some tongue in cheek comments stating that
>  > the ASF should look at using some form of centralised authentication
>  > and/or authorisation.
>  >
>  > We, the infra team, currently manage the access to services such as:
>  >
>  > * Subversion
>  > * Shell access to people.apache.org
>  > * Bugzilla
>  > * Confluence
>  > * JIRA
>  > * cwiki
>  >
>  > This means that folks who have access to any or all of these systems will
>  > have an individual accounts for each service.  This seems daft with over
>  > 2000 committers now, with this number rising each week this will become
>  > more difficult to reliably sustain.
>  >
>  > So what I want to do now, is formally propose that we consider deploying the
>  > services of LDAP directory services.  This can be used for not only
>  > centralised authentication/authorisation but also for:
>  >
>  > * Storing copies of committers public keys.
>  > * Storing a copy of users' associated ICLA
>  > * Contact information at least for all members, but possibly committers too.
>  >
>  > A few people have helped start gathering requirements, and ideas here ->
>  >
>  > https://svn.eu.apache.org/repos/asf/infrastructure/trunk/projects/ldap-project/
>  >
>  > That folder is currently available for all committers to look over.  But
>  > not write too.
>  >
>  > The current docs are by no means complete, and I am looking for other
>  > folks to help me get them to a state so that we can present the idea and
>  > kick the project off. There are some technical requirements that are
>  > non-negotiable, for instance:
>  >
>  > * Multi site master (For HA)
>  > * Intra site replication (To maintain said HA)
>  > * No direct internet access to LDAP (obvious, but, security)
>  >
>  > There are some other ideas in the documentation in subversion, like karma
>  > attribution amongst others.
>  >
>  > Clearly most of the wish list items will require a custom user schema to
>  > be used to store the relevant information.
>  >
>  > I am happy to run with this, but I am looking for input from folks willing
>  > to either help and/or get involved.
>
>
> The biggest issue that I do not yet see resolved is that of username
>  namespaces.

+1

>  Currently, we have a 'committer' namespace, names are allocated, by
>  root, based upon requests from the new committer, when their Apache
>  account is created.

And this namespace must map to names that are valid as login names.

>  If we go to an LDAP setup that covers non-committers too, then we have
>  to expand our namespace handing to cover names that non-committers might
>  choose.
>
>  And, we need to work out a way to handle the transition from
>  non-committer to committer, in the (likely) case that that involves a
>  change in username.
>
>  Otherwise, we could get folks snapping up all the best names in the
>  @apache.org namespace in the hope that they may one day become a
>  committer, rather than having a name selected for them at the point at
>  which their account is created.

How about insisting that the free-for-all LDAP entries (Bugzilla, JIRA
etc) use a valid e-mail address as the unique account id (e.g. by
requiring a confirmation e-mail)?

Until a user is a committer, they will not be able to use an @a.o address.

When a user accepts the invitation to become a committer, they would
be asked to set up an LDAP entry with the e-mail address that they
used in the ICLA (if they have not done so already).

This would be used as part of the login validation process. [If their
e-mail address on the CLA has changed since it was submitted, then
they would have to send in another.]

There would need to be some way to relate account ids to each other.

>  In comparison to this, setting up LDAP itself seems easy :-)
>
>
>  Upayavira

Mime
View raw message