[Date Prev][Date Next]
RE: SASL LDAP plugin
> -----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
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
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
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
Symas: Premier OpenSource Development and Support