Integrated ldap for contrib.auth

[Jeff Anderson]

Currently, the patch for ldap authentication [2507] works, but django still creates the user table in the database and stores password hashes that way.

Example of negative side effects from the current way that things work: We had someone that moved from one group to another in ldap, but he still appeared as a privileged user to django. When his object was created in the mysql database, the is_staff flag was set because of the group he belonged to at creation. I think he would have been switched over the next time he logged in, but it was still annoying to have to make the change in two different places, as he wasn't going to be logging in anytime soon.

The way to resolve this involves a decent amount of design decisions, but I think that the end result would be beneficial.

The obvious solution is to get the User object to be able to use ldap as a backend directly. The User object is a django model, so I'm not 100% sure what the 'right' way would be to change this behavior. Here are my ideas so far:

• The way to have the existing code still used when using the ldap backend I believe would require that django can 1) use ldap as a database type and 2) can handle multiple databases for models.
• One could re-write the whole model using custom field classes that are hard coded to use ldap as a backend. ldap configuration settings would go in settings.py

Some other things to consider:

• Support for the unix-type user objects.
• Support for the samba/active directory type user objects.
• Support for both types-- giving priority to one over the other.
• Support for SASL password fields.

[Thomas Güttler]

You mean ticket #2507 (not the changeset).

[Thomas Güttler]

Like #2507 this feature can live outside of django.