Re: [SASL] SASL plan
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
Re: [SASL] SASL plan
Alex Karasulu wrote:
Stefan Zoerner last year hooked up a way to use digested passwords in the
userPassword field I think. I wonder if there could be issues with SASL
and
this mechanism if the password value in the entry is already really a digest
rather than the password itself in plain text. Just wanted to mention a
potential
problem here. I guess you can just check if {SHA1} {MD5} prefixes are
present
in the password value before performing the test. If it is then if the
digest algol
matches then just compare the supplied value with the digest values stored.
You are right, Alex. The feature is described (from a user's point o
view) here:
http://directory.apache.org/apacheds/1.0/31-authentication-options.html
But the server does not digest passwords on his own account, the user
(or his tools) has to calculate the value and transmit it. I still plan
to write a simple interceptor as an example for the docs, which exactly
does this, but this is another story.
Digesting userPassword values in conjunction with SASL DIGEST won't
work, we should clarify this in the documentation.
Greetings from Hamburg,
Stefan
Re: [SASL] SASL plan
Hi Stefan,
Thanks for chimming in with the additional info. It might come in handy for
what Enrique is working on.
Alex
On 3/6/07, Stefan Zoerner [EMAIL PROTECTED] wrote:
Alex Karasulu wrote:
Stefan Zoerner last year hooked up a way to use digested passwords in
the
userPassword field I think. I wonder if there could be issues with SASL
and
this mechanism if the password value in the entry is already really a
digest
rather than the password itself in plain text. Just wanted to mention a
potential
problem here. I guess you can just check if {SHA1} {MD5} prefixes are
present
in the password value before performing the test. If it is then if the
digest algol
matches then just compare the supplied value with the digest values
stored.
You are right, Alex. The feature is described (from a user's point o
view) here:
http://directory.apache.org/apacheds/1.0/31-authentication-options.html
But the server does not digest passwords on his own account, the user
(or his tools) has to calculate the value and transmit it. I still plan
to write a simple interceptor as an example for the docs, which exactly
does this, but this is another story.
Digesting userPassword values in conjunction with SASL DIGEST won't
work, we should clarify this in the documentation.
Greetings from Hamburg,
Stefan
Re: [SASL] SASL plan
On 3/6/07, Alex Karasulu [EMAIL PROTECTED] wrote: ... So basically this handles the client side generation of the digest which is sent to the server rather than the password itself, then the server compares this digest with the digest generated from the userPassword field? No, typically a password is combined with some information shared by the client and server, to prove both sides know the same password, avoiding the need for the password to traverse the network. There are 2-3 request-response pairs here, negotiating session setup and responding to challenges from the server. Stefan Zoerner last year hooked up a way to use digested passwords in the ... If not you can just throw an exception since you cannot generate a digest because the userPassword is not in available to do so. I may be totally off here since I'm twice removed from this code and I may have some misconceptions about how these mechanisms actually work but I just thought I'd mention it here for the record. This is the case. In other LDAP servers you have to explicitly configure the server to store the password plaintext. You can actually extend AbstractServerTestCase or something like that in server-unit. Cool, I'll migrate to that. So, based on feedback from you and Emmanuel, I will: 1) Branch the trunk to add SASL. 2) Assign Alex a subtask to add supportedSASLMechanisms in the branch. 3) Start a page in Confluence. Enrique
Re: [SASL] SASL plan
On 3/6/07, Enrique Rodriguez [EMAIL PROTECTED] wrote: ... So, based on feedback from you and Emmanuel, I will: 1) Branch the trunk to add SASL. 2) Assign Alex a subtask to add supportedSASLMechanisms in the branch. An issue is open: https://issues.apache.org/jira/browse/DIRSERVER-867 3) Start a page in Confluence. I started this page at: http://cwiki.apache.org/confluence/display/DIRxSBOX/SASL+Authentication+to+ApacheDS Enrique
Re: [SASL] SASL plan
Excellent! I'll watch for commits to figure out where your SASL branch is to add the code to return the supportedSASLMechanisms in the RootDSE. Alex On 3/6/07, Enrique Rodriguez [EMAIL PROTECTED] wrote: On 3/6/07, Enrique Rodriguez [EMAIL PROTECTED] wrote: ... So, based on feedback from you and Emmanuel, I will: 1) Branch the trunk to add SASL. 2) Assign Alex a subtask to add supportedSASLMechanisms in the branch. An issue is open: https://issues.apache.org/jira/browse/DIRSERVER-867 3) Start a page in Confluence. I started this page at: http://cwiki.apache.org/confluence/display/DIRxSBOX/SASL+Authentication+to+ApacheDS Enrique
