[Freeipa-devel] LDAP connections and the new ldap backend plugin

[Jason Gerard DeRose]

As I already mentioned, Pavel is working on a new ldap backend plugin
which will live at Backend.ldap2 till it supersedes the current ldap
plugin.

Each time a request is received by the server, a connection is made to
LDAP on behalf of the requesting user, using the user's forwarded
Kerberos credentials.  Currently this connection is an instance of the
ipaserver.ipaldap.IPAdmin class, a subclass of SimpleLDAPObject.

However, after giving it a lot of thought, I don't think we should take
this approach with the new ldap plugin.  The reason is if someone wants
to glue some existing code written against the python-ldap bindings into
an IPA plugin, they likely need access to a raw SimpleLDAPObject
instance.  Our custom SimpleLDAPObject subclass will no doubt break
their code.

Plus, any 3rd-party LDAP code *must* use the connection we create
because we don't expose the Kerberos credentials in request.context
(just the connection we create).  So although 3rd-party LDAP code could
create their own connection to LDAP, they don't have access to the
credentials needed to authenticate to LDAP on behalf of the requesting
user.

So we need the LDAP connection to be a least-common-denominator, a raw
SimpleLDAPObject instance.  The new ldap backend plugin will still be
the preferred way to talk to LDAP, and all our built-in plugins will do
so, but this way the framework is more flexible and easy to integrate
with.  Many potential users will have important home-grow code they need
to continue to use, so if they can easily integrate it with IPA, IPA
becomes a more viable solution for them.  So something like this:


SimpleLDAPObject <=> Backend.ldap2 <=> typical IPA plugins
      \
       \<=> can also glue-in existing code written against python-ldap


Until we transition to the new ldap plugin, we can simply create two
LDAP connections (one SimpleLDAPObject, one IPAdmin) so none of the
current code is broken in the meantime.

What does everyone think?  Does this seem like a good approach?


Cheers,
Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090302/710995f5/attachment.sig>