directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: ApacheDS for ASF
Date Sat, 12 Apr 2008 10:47:37 GMT
Emmanuel Lecharny wrote:

> Just a quick heads up for Graham, mainly :
> 
> we have had a BoF last thursday where we discussed about using ADS to 
> manage the ASF. To make a long story short, we agreed on a few things :
> - we have to install ADS on the zone Graham created
> - we must first try to manage our own users (ADS users)
> - we have to define complete and validated uses-cases for what we want 
> to do
> - to avoid f*cking up access to the ASF servers for our users, we must 
> be sure that we keep the current text file updated
> - we might start with access to Confluence, as it's not a critical 
> component
> - some sites like Jim's page 
> (http://people.apache.org/~jim/committers.html) or 
> http://people.apache.org/committers.html might also be seen as perfect 
> target for initial experimentations

One recurring theme that has come up on the infra lists when this has 
been discussed in the past is a concern that an insufficiently secure 
LDAP server could "leak" private data out to the wider world.

As a result, before we stick any "real" data into the server, we need to 
secure it to the point where the server is "production ready". What this 
means depends on the capabilities of ADS server:

SSL? I would say this would be a minimum requirement, we could probably 
use our own cert for now as this is for our consumption, rather than 
consumption of the wider world, but this may change.

Access via client certificates only?

One option is to keep the server truly private initially (ie on 
localhost), accessible initially via ssh port forwarding. This way we 
can prevent any "surprised people" on the infra list, and ensure privacy 
concerns are addressed before "opening up" the server to a wider world.

Once this is done, the next job (I would imagine) would be to 
automatically populate / synchronise the data based on the contents of 
members.txt, etc, as you've described above.

This brings a discussion as to where the "authoritative" source of data 
lies. Right now today that authoritative source is svn, and I also 
imagine people would want this to stay that way for some time. As a 
result, our first task would be to synchronise LDAP with the various 
members.txt (etc) files. This would need a bit of shell scripting, 
probably tied into the svn server so the synchronise is triggered on commit.

The LDAP server doesn't have to be limited to just member and/or 
committer data, it could (and probably should) contain login details for 
virtually anybody. The members.txt file could "supplement" existing data 
in LDAP with extra details about that person.

This brings a potential ASF schema into the picture.

objectclass: asfMember
objectclass: asfCommitter
...

How would these schemas be defined, and how would they change over time?

Something I have been working on in httpd-land for a while is the 
problem of effective single sign-on with applications.

Bugzilla for example might want you to log in with your email address, 
while something like Moveable Type might want you to log in with your 
username.

Rather than expecting people to log in twice, httpd is capable of 
allowing a user to log in with their email address, but provide (say) 
their username to the backend instead without either the user or the 
backend application being aware of it.

This is obviously a thought for down the line, but it does give an idea 
of what is possible.

Regards,
Graham
--

Mime
View raw message