The past week I’ve been experimenting with LDAP mostly. I set up a clone of ldap1.gentoo.org (with fake data of course) at my home server, and gave a Cfengine patch to Robin, pending for review, in order to have the testing LDAP service to vulture (the soc.dev box). I also set up my git repo, and split the settings.py file in many files, under a settings/ dir. This is how the transifex guys and my mentor Matt do it, and this approach allows us to put the config files even in /etc for example.
My major goal was to finish the LDAP backend part, either by using an existing library or writing it from scratch. Finally, after taking a look at many libraries and implementations, I wrote my own. More specifically, what the Django LDAP authentication backend does is to override the default Django DB authentication backend. When a user logs in, the backend checks if the user exists in the LDAP server. In order to do the search, the OpenLDAP server has to provide either an account to do that (an “anonymous” account with minimal privileges, just to do those kinds of ldap queries) or allow anonymous searches. In case the account is being used, it has to be declared in the settings file. I took it one step further from what the other backends did actually: in a common ldap configuration, all users are under OU=users or something. I intend to split it though to OU=users and OU=developers, thus I allowed the backend to search in multiple organizational units, by converting the variable to a python list. If the query sends a result (meaning the user is found), then it tries to bind with the credentials provided in the login form. If it suceeds, then the user data (apart from the password) are transfered to the django db, where they are going to be used for the rest of the session. Django actually has only email, real name and username in its accounts, but it gives the opportunity to extend those by creating a profile. That is technically an extra table in the db, with the ability to add custom fields, really handy.
The major problem that I’ve faced with all those ldap backends was that they all asked for an admin account, and they performed all changes with that account. That is acceptable for user creations but not for all the other cases. If a user wants to change his data, he should be able to do it with his regular account. Another problem emerged here though. OpenLDAP asks for the password before every action and one solution was to do it that way. Bcooksley had another idea though, to create a second 50char password, which will stay only for one session, and will be destroyed using itself at the end. I liked that idea very much, as asking the password is not too user friendly in my opinion, and the web frontend looses its purpose. For important changes though the password will be required (that includes uploading a new SSH/GPG key, or resetting the password).
The LDAP backend is now working, which is really cool, I didn’t expect it to be done so fast. My next step is to write some tests and documentation, for which I’ll use sphinx. Also, I plan to continue working on the ldap web frontend, by finishing the login/signup systems, and the user settings page, and then start messing with the UI.
