External authentication for Django projects

Jan Pazdziora

Senior Principal Software Engineer
Identity Management Engineering, Red Hat

EuroPython24th July 2015

CC BY-SA License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

This text is also available as slides in PDF format.


  • You've developed successful application using Django.
  • It makes use of users, presumably based on django.contrib.auth.
  • Now a large organization plans to deploy the application.

    • All its employees should have access.
    • Plus associates of its partners and suppliers are to use it.
  • Desired workflow:

    • New person joins the organization.
    • They can immediatelly start using the application.
    • Preferrably using single sign-on (SSO).
    • Authorization derived from group membership in the central system.

Problem statement

  • Large organizations have existing identity management solutions.

    • FreeIPA/IdM, Active Directory, LDAP servers, ...
    • With user groups used for access control.
  • Admins will not create nor manage users in the application manually.
  • Organizations use standard authentication mechanisms and setups:

    • Kerberos / GSSAPI
    • Access cards / X.509 / SSL client authentication
    • SAML
  • Organizations often mandate that authentication is done in their verified frontend setup.

Simple setup

  • Assume the application uses django.contrib.auth.

  • With django.contrib.auth.views.login and some custom template.

Authentication in frontend HTTP server

  • We will look at Apache with mod_wsgi but the story is generic.
  • AuthType set up in Apache configuration.
  • It sets REMOTE_USER.
  • Easy answer:

  • Or is it?

Limits of RemoteUserMiddleware

  • It assumes external (Apache) authentication covers all locations/URLs that are to be seen as authenticated by the application.

    • Apache would need to authenticate every request.

      • Or maintain authentication-related sessions.
    • You do not want to renegotiate Kerberos upon every HTTP request.
    • We need Apache authentication on /login URL(s) only.
  • The django.contrib.auth.views.login does not understand when RemoteUserMiddleware has already authenticated the user.

    • It will still show the login form.
    • Even if the user is authenticated for the request.

Authentication on single URL

  • Externally-authenticated login URL should initiate authenticated Django session.
    <Location /login/>
      AuthType GSSAPI
      AuthName "Kerberos Login"
      GssapiCredStore keytab:/etc/http.keytab
      # GssapiLocalName on
      # Require valid-user
      Require pam-account fin-app-prod
    <Location /login/>
      SSLVerifyClient require
    <Location /login/>
      MellonEnable "auth"
  • This way it is easier to fall back to the application-provided login mechanism if needed, making the external authentication optional.

Make it persistent

  • New PersistentRemoteUserMiddleware in Django 1.9.
  • A drop-in replacement for RemoteUserMiddleware:
  • It keeps the user authenticated.

External authentication aware login

  • Wrap django.contrib.auth.views.login with code actively checking request.user.is_authenticated():
    from django.contrib.auth.views import login as auth_login
    # additional imports
    def login(request, template_name='activity/login.html',
        if hasattr(request, 'user') and request.user.is_authenticated():
            redirect_to = request.POST.get(redirect_field_name,
                request.GET.get(redirect_field_name, ''))
            if not is_safe_url(url=redirect_to, host=request.get_host()):
                redirect_to = resolve_url(settings.LOGIN_REDIRECT_URL)
            return HttpResponseRedirect(redirect_to)
        return auth_login(request, template_name = template_name,
            redirect_field_name = redirect_field_name)
  • Have you got idea for better solution?

    • Chime in in

Additional user attributes

  • With external authentication, traditionally only the login name is used, provided in REMOTE_USER.
  • Modern Web applications want to send emails to their users.
  • Using "<username>@<application's domain>" often does not work.
  • Modern Web applications would like to make the UI nice by knowing user's name.
  • And other attributes.
  • Let's introduce REMOTE_USER_<attribute> variables.

Populating REMOTE_USER_<attribute>

  • For SSSD-based installations, mod_lookup_identity can be used:
    <Location /login/>
      LookupUserAttr mail REMOTE_USER_EMAIL
      LookupUserAttr givenname REMOTE_USER_FIRSTNAME
      LookupUserAttr sn REMOTE_USER_LASTNAME
    Note: remapping in ldap_user_extra_attrs could also be used.
  • For SAML, the mod_auth_mellon module can populate the attributes from <saml:AttributeStatement>:
    <Location /login/>
      MellonSetEnvNoPrefix REMOTE_USER_EMAIL email
      MellonSetEnvNoPrefix REMOTE_USER_FIRSTNAME givenname
      MellonSetEnvNoPrefix REMOTE_USER_LASTNAME surname

Consuming attributes in Django

# The real code has a few more checks
class RemoteUserAttrMiddleware(RemoteUserMiddleware):
    def process_request(self, request):
        if hasattr(request, 'user') and request.user.is_authenticated() \
          and user.get_username() == request.META[self.header]:
            stored_backend = load_backend(request.session.get(BACKEND_SESSION_KEY, ''))
            if isinstance(stored_backend, RemoteUserBackend):
                email = request.META.get("REMOTE_USER_EMAIL", None)
                if email is not None:
           = email
                firstname = request.META.get("REMOTE_USER_FIRSTNAME", None)
                if firstname is not None:
                    request.user.first_name = firstname
                lastname = request.META.get("REMOTE_USER_LASTNAME", None)
                if lastname is not None:
                    request.user.last_name = lastname
  • Upon every login, user in Django's auth_user table gets synchronized.

Group-based authorization

  • Many organizations diligently manage user group membership in their central identity management system.
  • They want to be able to assign application-level permissions to groups.
  • And have group memberships propagated without manual edits.
  • Plan:

    • Upon user login, propagate their external group membership into Django groups starting with ext: prefix.
    • Application admins will create ext:-prefixed groups for groups that are relevant for the application and assign permissions to them.
    • Nonprefixed group are available for local group management.


  • For SSSD-based installations, mod_lookup_identity can be used:
    <Location /login/>
      LookupUserGroupIter REMOTE_USER_GROUP
  • The mod_auth_mellon module can populate attributes from SAML response:
    <Location /login/>
      MellonEnvVarsSetCount On
      MellonEnvVarsIndexStart 1
      MellonSetEnvNoPrefix REMOTE_USER_GROUP groups
    Example result:

Consuming external groups

# extending RemoteUserAttrMiddleware
class RemoteUserAttrMiddleware(RemoteUserMiddleware):
    group_prefix = 'ext:'

    def update_user_groups(self, request):
        user = request.user
        ext_group_count = request.META.get("REMOTE_USER_GROUP_N", None)
        current_groups = {}
        for g in user.groups.filter(name__startswith=self.group_prefix):
            current_groups[] = g
        for i in range(1, int(ext_group_count) + 1):
            if request.META.get("REMOTE_USER_GROUP_" + str(i), None):
                g = self.group_prefix + request.META["REMOTE_USER_GROUP_" + str(i)]
                if current_groups.has_key(g):
                    del current_groups[g]
                    g_obj = Group.objects.filter(name=g)
                    if g_obj:
        for g in current_groups.values():
    def process_request(self, request):


  • It is possible to support wild combination of authentication methods, by using authentication frontends.
  • With PersistentRemoteUserMiddleware, isolated login URLs work.
  • The login methods need to be checked and possibly amended to observe the external authentication.
  • Merely login name in REMOTE_USER is often not sufficient.
  • With custom middleware like RemoteUserAttrMiddleware, user attributes and group memberships can stay in sync.
  • When new associate logs in, they can not just do it via SSO, they will have their account and permissions fully set up, automatically.
  • No Python code specific to the authentication methods was written.
  • This is call for comments: do you find the approach useful?