RE: SASL LDAP plugin

[Luke Howard <lukeh@PADL.COM>]

>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:

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),
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
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.

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.
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.)

-- Luke

--
Luke Howard | lukehoward.com
PADL Software | www.padl.com