[Kolab-devel] [issue3283] web client: Document reasons for switching to LDAP auth instead of IMAP auth

[Gunnar Wrobel]

Quoting Thomas Arendsen Hein <kolab-issues at intevation.de>:

>
> New submission from Thomas Arendsen Hein <thomas at intevation.de>:
>
> The Horde web client changed from IMAP to LDAP authentication between server
> 2.2.0 and 2.2.1, the only hint about this I found is:
> kolab/issue2258 (Horde authentication fails)
>
> Usually mail clients authenticate against IMAP and SMTP and the web client
> somehow is a client.
>
> A problem revealed by this change is:
> kolab/issue3282 (web client does not handle missing inbox gracefully)
>
> A good reason to do it is:
> kolab/issue2207 (Make it possible to enable and disable users to be  
> able to use
> the webclient)
>
> But since I do not think that the change was done to solve the first  
> or the last
> issue, it would be good idea to document why the change was done.
> Are there mailing list discussions?
> What CVS commit contained the change?

This is a somewhat complex story. The auth change from IMAP to LDAP  
was in fact not the intended goal but just a side effect. One that I  
didn't mind though.

Horde offers you more than twenty different authentication modules.  
IMAP authentication is among those as well as a Kolab specific  
authentication module. The latter was the module I always used for the  
Horde installation on the Kolab server. It would be no problem to  
change this to the IMAP driver.

The Kolab authentication module traditionally derived from the Horde  
IMAP auth driver and this is what I changed recently to LDAP. The  
reasons for that were manifold and in fact the logical conclusion to a  
series of restructurings in the Horde Kolab modules. I won't go too  
much into detail here.

But let me say that an authentication module that really represents  
the Kolab authentication concept must authenticate against LDAP as  
this holds the user credentials.

And nowadays it is not only Horde using the Kolab auth module but also  
Kolab_FreeBusy as well as Kolab_Filter. This was also one of the  
driving forces behind the restructurings I mentioned above: We had  
four different auth implementations in the old Kolab CVS code. You  
know that the reduction of this type of code duplication is what the  
upstream Kolab_* modules are mainly about.

While I agree that a mail client should auth via IMAP I also see a  
benefit from using the new LDAP based Kolab module. The bug you  
mentioned is among them. There was another one about retrieving user  
information from LDAP and using it for initialization of the web  
client preferences. In addition I consider the whole Kolab session  
approach I now use within Kolab_Server a significant improvement over  
what we had before (mainly for caching reasons which saves us a number  
of LDAP requests).

The negative point (kolab/issue3282) is something I acknowledge as a  
bug but it is not more than that and I don't see it as a blocker to  
changing to LDAP auth. Of course Horde should ensure that the users  
primary storage space is available by using the LDAP credentials. This  
is something that currently does not happen and that needs fixing  
indeed.

I cannot pinpoint a single CVS commit as this has been a succession of  
structural changes. But this one was at least the crucial change from  
IMAP to LDAP:

http://cvs.horde.org/co.php/framework/Auth/Auth/kolab.php?r=1.1.10.18

Enough documentation? I don't think this should go into the wiki but  
correct me if I'm wrong.

Cheers,

Gunnar

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20081202/0b811f7c/attachment.sig>