RE: SASL LDAP plugin

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Luke Howard [mailto:lukeh@PADL.COM]

> >Right. Proxying the bind itself is a possibility, but that means e.g.
> >providing an LDAP-specific implementation of the CRAM-MD5 or
> DIGEST-MD5 SASL
> >plugins. Way too messy.
>
> Actually, if you accept that LDAP is a general purpose
> authentication protocol
> (not taking a position on that), it's not necessarily as messy as
> you might
> otherwise think. But, moreover, it's not _possible_, at least
> with CRAM-MD5
> and DIGEST-MD5, unless you're willing to funnel every SASL bind
> to a single
> authentication server. I was planning on implementing something
> similar for
> OS X (where there is a general purpose authentication server which appears
> to be based on SASL POP authentication) but not being able to arbitrate on
> the user name tharted it it.

I had briefly considered this but didn't carry the thinking out as far as
you seem to have gone. But yes, we still have the problem of directing the
binds to the right server, and it still doesn't answer the question of how
to retrieve any other auxiliary attributes that a SASL-enabled server might
want. I don't have any objection to funneling every SASL login into a single
server. That's actually the desired goal, as I see it:

   [--------- server 1 ----------------------]
    SMTP\
    IMAP-->--SASL-->ldapi-->slapd-->back-ldap - - (TLS?) - -> auth server
slapd
    POP3/
    etc.

(Of course, "auth server" can be replicated as needed...)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support