LDAP authentication backend
Peter Sagerson
I'm the author of Contrib-09/#11526[1], an LDAP authentication
backend. I haven't posted about it before and I saw some questions in
the voting sheet, so I thought I'd try to address them here.
My motivation for writing the backend is simply that I'm managing a
server with a variety of services and I wanted to unify
authentication. Of the five types of services I'm juggling--Drupal,
DokuWiki, Trac, miscellaneous private scripts via Apache, and a Django
app--only Django lacked robust LDAP authentication.[2] I noted that
#2507[3] had been marked as accepted, pending an acceptable diff and
that said diff did not appear forthcoming, so I decided to write a
comprehensive solution and submit it for version 1.2.
Some of the voting feedback was wondering whether this implementation
was sufficiently generic, or if LDAP deployments varied so much that
it was futile to try to include support in Django. However, as I
mentioned above, many applications contain generic LDAP authentication
solutions (I'll also add Cyrus SASL, Moin, and Joomla to the list, off
the top of my head). My solution is actually rather more generic than
any others I've seen, primarily because it's written for a framework,
so it's designed with Python hooks to modify and extend its behavior.
The trickiest part of LDAP interoperability is managing groups, as
there isn't a single standard mechanism for grouping users. Most
libraries have a somewhat awkward solution for handling different
group types; since this implementation is for a framework, we have the
luxury of providing a subclassing API to allow powerful customization.
In practice, though, most grouping is handled by a small number of
common mechanisms. This is of course reinforced by the fact that
Apache, Cyrus SASL, and other crucial clients only support a limited
set. I've provided implementations for the standard mechanisms that
I'm aware of and additional mechanisms are very easy to add, either in
the core, in individual projects, or by third-party extensions.
Having said all of that, I will point out that this is a piece of
functionality that can live quite happily outside of Django core. If
it is not accepted into contrib.auth, this seems like the most
compelling reason. I know this consideration comes up frequently,
although having looked through the submission guidelines, I didn't see
any kind of policy statement regarding what sorts of things are
appropriate for the core project and what should exist as a third-
party package. Perhaps I overlooked it.
So the bottom line is that in addition to using this myself, I will
gladly maintain it as an external package on PyPI if that's the best
place for it. However, I offer it to the Django core project should
you wish to incorporate this functionality.
Thanks,
Peter
[1] http://code.djangoproject.com/ticket/11526
[2] Okay, it's a little generous to call Drupal's module robust, but
it's getting there.
[3] http://code.djangoproject.com/ticket/2507