RE: SASL LDAP plugin

[Luke Howard <lukeh@PADL.COM>]

>> 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 principle, I agree. This problem was thrown up by needing to support
OS X's "authAuthority" attribute which acts as a per-user selector between
different authentication services and servers. It's quite a useful
idea, and (as I think I mentioned previously) ties in well with the
auxprop_lookup function you added to slapd, but it's made completely 
unimplementable in the CRAM-MD5/DIGEST-MD5 case due to the mechanism design.

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

Right, so both approaches have merit, and are possible to implement with
the current Cyrus SASL library. It's just our specific requirements for
that appear to make both approaches not work. :-)

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

Well, don't forget that DCE actually had a security registry separate
from the directory, but you could certainly store arbitrary user 
information (I think these were called extended registry attributes)
there. But tying in the security registry with the directory makes a
lot of sense from an administrative point of view, assuming you trust
your directory. This is the direction the DCE of today is going (the
question is whether anyone is listening).

-- Luke

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