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 --
smime.p7s
Description: S/MIME Cryptographic Signature
