On Thu, 09 Aug 2001, Marco Colombo spewed into the ether:
<snip>
> This is a completely different issue. David Wright is proposing to
> *remove* SASL from Cyrus IMAPd in favor of a PAM-only solution, and
> I was answering to him. I don't want SASL to be removed from IMAPd,
Nor do I. SASL does fine for what it is supposed to do, and I don't
believe in fixing what works.
<snip>
> You're asking for the opposite: to remove PAM from SASL (for LDAP auth,
> of course) and implement a direct SASL -> LDAP solution. As I said,
> a complete different issue.
I'm asking for a IMAPD -> LDAP solution, not IMAPD -> SASL -> LDAP
<snip>
> SASL provides support for many machs. Some of them require cleartext
> passwords to be available to the server. Where those mechs get the
> passwords from is a mere implementation detail from the SASL engine
> standpoint. sasldb is one easy way for mechs to get the passwords.
So what I need is to add support to SASL according to you. But If I
wish to bypass SASL for some reason, does it not mak e sense for the
application to allow me to do what I need to do?
<snip>
> LDAP API doesn't offer anything of what the SASL API does, and of
> course the converse is also true. So you can't compare the two, as the
> provide *completely* different services to the application. Otherwise
> please explain me why OpenLDAP itself uses SASL.
The LDAP API provides a convenient way of accessing sasldb over the
network.
> SASL already offers "good support for multiple authentication methods".
> So good that even the OpenLDAP developers (as many others) chose to use
> it to fulfill thier "multiple authentication methods" needs.
Yes. I have nothing against SASL. What I need is a way to get access to
authorization data from a source of my choice, bypassing the local sasl
database/local sasl mechanisms.
Devdas Bhagat
--
If A = B and B = C, then A = C, except where void or prohibited by law.
-- Roy Santoro
