From dev-return-16329-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Mar 06 09:22:58 2007 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 39173 invoked from network); 6 Mar 2007 09:22:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Mar 2007 09:22:57 -0000 Received: (qmail 27434 invoked by uid 500); 6 Mar 2007 09:23:05 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 27400 invoked by uid 500); 6 Mar 2007 09:23:05 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 27389 invoked by uid 99); 6 Mar 2007 09:23:05 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Mar 2007 01:23:05 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: 212.27.42.35 is neither permitted nor denied by domain of elecharny@gmail.com) Received: from [212.27.42.35] (HELO smtp5-g19.free.fr) (212.27.42.35) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Mar 2007 01:22:56 -0800 Received: from [192.168.0.1] (vol75-3-82-66-216-176.fbx.proxad.net [82.66.216.176]) by smtp5-g19.free.fr (Postfix) with ESMTP id 206E47D8D for ; Tue, 6 Mar 2007 10:22:35 +0100 (CET) Message-ID: <45ED32DA.3060703@gmail.com> Date: Tue, 06 Mar 2007 10:22:34 +0100 From: Emmanuel Lecharny User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: fr, en MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [SASL] SASL plan References: <568753d90703051935v5f6bcfc8jf8f7eb779f54a9bd@mail.gmail.com> In-Reply-To: <568753d90703051935v5f6bcfc8jf8f7eb779f54a9bd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Enrique Rodriguez a écrit : > I have SASL working; that is to say, the DIGEST-MD5, CRAM-MD5, and > GSSAPI mechanisms. Great ! This is one excellent news ! > The integration tests just completed (27 minutes > on a POS box). New SASL integration tests are also complete. I used > the JDK's JNDI client to test a variety of positive and negative > scenarios. Also, I tested manually with the ldap-clients CLI tools, > eg ldapsearch. > > I need to wrap up a few loose ends: > 1) My integration tests require a running server. I just haven't > gotten around to figuring out how it's done elsewhere in ApacheDS. > I'll get on that next. I think the best solution would be to look at server-unit tests, where an embedded ADS is launched, so you don't have to launch the server before. > 2) I need to add javadocs. > 3) I triplicated a lot of code to make each mechanism work, so > there's one big round of refactoring due to tighten things up. What about pushing the code in a branch so that we can help without breaking the serve r(we are currently in the process to close a 1.5.0 version) ? Not that we really care to break the server, but we want to tag this one, before adding new features. Let say that SASL can be introduced in 1.5.1 (FYI, 1.5.0 is expected in the next two weeks, and it's pretty much about fixing some bugs) > > The BindHandler is totally replaced. The execution path for the > Simple mechanism is unchanged and integration tests pass so I don't > think this is a major change. Outside of the LDAP PP, a SaslFilter > needs to get added to the filter chains in ServerContextFactory. The > 'server-sasl' module can be deleted. It would be very appreciated if you can add a 'big-picture' somwhere in confluence. The new site is now directly linked to confluence, and in the 1.5.0 page, you can add this page somewhere in http://directory.apache.org/apacheds/1.5/apacheds-v15-advanced-users-guide.html (the little light grey icone on the upper right side of the main frame is used to edit the page) > > Most config is hardcoded, but I put it all in one class. From there, > we can work it into the server.xml. > > Also, none of the advanced regex's we talked about is done. The deal > with authentication is that: > CRAM-MD5: looks for 'uid' under a base DN. > DIGEST-MD5: looks for 'uid' under a base DN. Realm must match realms > advertised by the LDAP server, but there is no multi-realm support > yet. > GSSAPI: looks for a krb5PrincipalName under a base DN. Also no > multi-realm support yet. > > The ease of configuring GSSAPI/Kerberos really stands out. Principal > configuration (user, service, krbtgt) can all occur on LDIF load, > which is really cool. The implication, besides not relying, > server-side, on external config files, is that you also don't need to > export a service principal key from the directory, like you do with > standalone LDAP servers. > > One last thing, the JDK's JNDI client checks the RootDSE for > 'supportedSASLMechanisms', so we need to add that as the intersection > of configured mechanisms from the server.xml and the supported > mechanisms and return that from the DefaultPartitionNexus. hmmm... My bet is that it would be better to configure such things using ADS itself. We are now trying to figure out a way to store all the configuration into the server as Ldap entries, instead of having a giant server.xml file. This is a work in progress, but certainly a way to go. > > I could use some guidance on how to proceed. Mostly I'm wondering if > it's worth branching or not. IMHO, yes. As your great work is pretty much parrallel (except for BindHandler), branching won't harm. > Only the BindHandler in the > protocol-ldap module is affected, but we haven't started in on any > regex processing or moving authentication to actual Authenticators. > > Enrique Thanks Enrique, we were expecting this SASL for a very long time, this is such a feature which make ADS a better server ! Emmanuel