RE: SASL LDAP plugin

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

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

> It's a tricky problem. The proxy SASL bind approach seems reasonably
> easy to implement with Cyrus SASL, except for the fact that you'll need to
> move the "real" plugins out of the way (the non-proxy server can specify
> a _sasl_getpath() callback to return the path to the real
> implementations),

We could simply introduce a new secprop flag that only the LDAP plugin
supports. Then in the SASL-enabled server's SASL config file we set this
secprop flag, so that it will only advertise our LDAP mechanism to its SASL
clients. No muss with plugin paths...

> and that you can't read any auxiliary properties until the user is
> authenticated, which is a problem if you wanted to use one of those
> properties to determine an authentication policy. It doesn't really matter

I think that's not a terrible problem. Really, if you're going to the
trouble
of setting up a centralized authentication service, you probably want the
policy to be set at the serving end, not the client end.

> in this case whether the canonical authentication server speaks LDAP,
> IMAP, or whatever. It also has the additional advantage that the secrets
> never leave the authentication server, which some people seem to like.

Certainly that's a nice advantage for a security protocol.

> OTOH, if you buy all-services-running-as-root-trust-each-other argument,
> and you don't need to have a distributed network of authentication servers
> (the benefit of which is somewhat muted by not being able to make per-user
> selection of those servers, at least with the mechanisms in question),
> having an auxprop plugin that provides access to the secret and any other
> useful properties over, say, ldapi:/// sounds like a much simpler
> solution.

Indeed. One authenticating server can fan out to others if needed, since the
mapping function can perform internal searches, and you can configure the
search target to be a back-ldap backend.

> In our case (OS X), such an auxprop plugin doesn't exist, and it
> is unlikely
> that it will ever exist due to design attributes in the authentication
> server (see the last sentence of the previous paragraph).

> If only it were simpler. (Well, we could all just use Kerberos. I suppose
> that opens another bag of worms.)

I actually like Kerberos with an LDAP-backed KDC. It's a bit like
re-implementing DCE slowly, but what the heck, it works.

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