Django - separate authentication backend code from implementation

What is the best way to separate your authentication backend logic from code which is inherently dependent on it?

Here's a common problem: django_auth_ldap does not prepopulate the users table, but rather authenticates against LDAP and adds users to the table as they log in for the first time.

However, say we're writing an app that involves adding members to projects. Users may want to add other users who exist in LDAP but have not logged in before, so you're pretty much required to enter a username in this case and query LDAP and the database to see if that user exists. Again though, if we're writing the app to be reuseable, we'd like the "lookup by username" subroutine to be configurable.

At work we've had two different solutions to the problem which both work fine but they are sort of weird solutions.

• Make it so you can write a get_user_by_username function in settings.py which does whatever lookups you want
• Give a "appname.modelname" path to a proxy model of auth.User you've created which is expected/forced to have a classmethod which does the same things as get_user_by_username

I think the first one is a little cleaner since it doesn't introduce new types, but it's still a weird thing to have in settings.py.

I suggest writing an abstract base class that encapsulates the expected functionality. This acts somewhat like an interface does in programming languages like C# and Java. Then have a django setting that specifies the class to be used for the get_user_by_username provider.

This means that future developers can put their get_user_by_username implementation anywhere they see fit as long as it is implemented in a class derived from the abstract base class and they point to it in settings.