Permissions =========== Groups are useful for more than just populating the user's ``is_*`` fields. :class:`~django_auth_ldap.backend.LDAPBackend` would not be complete without some way to turn a user's LDAP group memberships into Django model permissions. In fact, there are two ways to do this. Ultimately, both mechanisms need some way to map LDAP groups to Django groups. Implementations of :class:`~django_auth_ldap.config.LDAPGroupType` will have an algorithm for deriving the Django group name from the LDAP group. Clients that need to modify this behavior can subclass the :class:`~django_auth_ldap.config.LDAPGroupType` class. All of the built-in implementations take a ``name_attr`` argument to ``__init__``, which specifies the LDAP attribute from which to take the Django group name. By default, the ``cn`` attribute is used. Using Groups Directly --------------------- The least invasive way to map group permissions is to set :setting:`AUTH_LDAP_FIND_GROUP_PERMS` to ``True``. :class:`~django_auth_ldap.backend.LDAPBackend` will then find all of the LDAP groups that a user belongs to, map them to Django groups, and load the permissions for those groups. You will need to create the Django groups and associate permissions yourself, generally through the admin interface. To minimize traffic to the LDAP server, :class:`~django_auth_ldap.backend.LDAPBackend` can make use of Django's cache framework to keep a copy of a user's LDAP group memberships. To enable this feature, set :setting:`AUTH_LDAP_CACHE_TIMEOUT`, which determines the timeout of cache entries in seconds. .. code-block:: python AUTH_LDAP_CACHE_TIMEOUT = 3600 Group Mirroring --------------- The second way to turn LDAP group memberships into permissions is to mirror the groups themselves. This approach has some important disadvantages and should be avoided if possible. For one thing, membership will only be updated when the user authenticates, which may be especially inappropriate for sites with long session timeouts. If :setting:`AUTH_LDAP_MIRROR_GROUPS` is ``True``, then every time a user logs in, :class:`~django_auth_ldap.backend.LDAPBackend` will update the database with the user's LDAP groups. Any group that doesn't exist will be created and the user's Django group membership will be updated to exactly match their LDAP group membership. If the LDAP server has nested groups, the Django database will end up with a flattened representation. For group mirroring to have any effect, you of course need :class:`~django.contrib.auth.backends.ModelBackend` installed as an authentication backend. By default, we assume that LDAP is the sole authority on group membership; if you remove a user from a group in LDAP, they will be removed from the corresponding Django group the next time they log in. It is also possible to have django-auth-ldap ignore some Django groups, presumably because they are managed manually or through some other mechanism. If :setting:`AUTH_LDAP_MIRROR_GROUPS` is a list of group names, we will manage these groups and no others. If :setting:`AUTH_LDAP_MIRROR_GROUPS_EXCEPT` is a list of group names, we will manage all groups except those named; :setting:`AUTH_LDAP_MIRROR_GROUPS` is ignored in this case. Non-LDAP Users -------------- :class:`~django_auth_ldap.backend.LDAPBackend` has one more feature pertaining to permissions, which is the ability to handle authorization for users that it did not authenticate. For example, you might be using :class:`~django.contrib.auth.backends.RemoteUserBackend` to map externally authenticated users to Django users. By setting :setting:`AUTH_LDAP_AUTHORIZE_ALL_USERS`, :class:`~django_auth_ldap.backend.LDAPBackend` will map these users to LDAP users in the normal way in order to provide authorization information. Note that this does *not* work with :setting:`AUTH_LDAP_MIRROR_GROUPS`; group mirroring is a feature of authentication, not authorization.