Hi Graham, On Sat, Apr 12, 2008 at 12:47 PM, Graham Leggett <[EMAIL PROTECTED]> wrote: > Emmanuel Lecharny wrote: <snip/>> > 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.
This has been mentionned during the BoF. > > 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. SSL is absolutly a must, if we are to access to the LDAP server directly. However, I would be more restrictive : I would not allow access to the server but to someone already logged via SSH on, say, people.apache.org. The main issue is DOS attacks... So one solution would be to define an intermediat elayer (for instance, a web site, or web-services), becaue they can be protected much more efficiently than ADS itself. > > Access via client certificates only? Well, this is something we should consider. > > 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. Damn,I should read forward before answering :) Anyways, that is good to see that we are really on the same page here ! > > 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. Yep > > 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. This is where the Use-Case descriptions are needed : they will exhibit the data we will manipulate, plus the workflow we have to follow. > > 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. Yes. We also mentionned JIRA's and Confluence's users, who may not be committers. > > 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? This has to be discussed, but we first have to analyze what data we really need to handle. And there are a lot of them, in different files and different formats ! > > Something I have been working on in httpd-land for a while is the problem of > effective single sign-on with applications. yeah... Again, has been mentionned during the BoF (I'm starting to think that my abstract was a little bit too abstracted ...) > > 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. We may use some internal mechanism to handle this case. To be further analyzed. > > 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. Yes. And some more can exist that we are not aware of. We have to start small, and grow like a snowball, I think. Thanks Graham ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
