Feedback requested on how I integrated AWS ALB (w/OIDC) into MediaCMS

[alfred-stokespace]

First off let me thank @mgogoulos and everyone else that has contributed to this project. I've found it very compelling option in this space.

Some caveats; I'm not much of a Python programmer and not terribly familiar with Django. The code I'm going to post could use polishing, especially around configurability and error handling.

I did however figure out how to get an AWS ALB w/SSL termination and OIDC support to sit in front of Mediacms and have that tie in with the user tables. Also! I preserved API support, I'll explain how that works later...

For my ALB I had AWS managing the SSL certificate, standard stuff. In my environment I used an Azure IDP and configured the ALB with valid cliend id, secret and all the endpoints and such. Then this doc from AWS helped https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#user-claims-encoding

The behavior for the code below is that a user that passes the auth challenges of OIDC at the ALB level is allowed to pass requests back to the MediaCMS nginx instance and along with those requests are standard headers containing JWT details. So the strategy I took was to figure out what parts of Django I had to extend in order to grab the headers, validate the jwt against AWS's public key and then pull anything I needed out of the jwt payload and populate it in the user object table that Mediacms already supports.
That part about populating the user is going to be very domain specific. For me the simple population found below is appropriate.
After first population (which has the hard validation) I just use the standard is_authenticated capabilities of Django and do simple confirmation that the user looks valid and then allow them to load the user object.
Now via a second ALB (or direct ip) you can still log in as the admin user and do everything you would expect. You just can't expect the admin user to work through the OIDC ALB since it would have to be a legit user in your IDP (and my admin user is not).

The admin user (coming through side channel) can turn the jwt populated users into Admins! Which is nice. That way you don't need to mess with claims if you don't want to in your IDP, you can just pick users to be editors or managers or full admins and the next time they open the site through OIDC ALB they have those permissions..

Now passwords don't exist for OIDC populated users. Which is fine. I think? As for API access here is what I did....
An admin user can create tokens in the admin ui and assign those tokens to any user. So for API interaction of an OIDC populated user I'm going to (and have already tested this works!) issue manually created tokens and distribute them via our internal secrets management to the users that need API access.

... the code diff (which I based off of 6fd9a7d37f2b273b0171ab77af35dde506e2fb2e)

diff --git a/cms/settings.py b/cms/settings.py
index 4c313f8..e36aaba 100644
--- a/cms/settings.py
+++ b/cms/settings.py
@@ -273,7 +273,6 @@ LOGIN_REDIRECT_URL = "/"
 AUTHENTICATION_BACKENDS = (
     "django.contrib.auth.backends.ModelBackend",
     "allauth.account.auth_backends.AuthenticationBackend",
-    "users.awsauth.JWTHeaderBackend",
 )
 
 INSTALLED_APPS = [
@@ -308,7 +307,6 @@ MIDDLEWARE = [
     "django.middleware.common.CommonMiddleware",
     "django.middleware.csrf.CsrfViewMiddleware",
     "django.contrib.auth.middleware.AuthenticationMiddleware",
-    "users.middleware.AWSJWTUserMiddleware",
     "django.contrib.messages.middleware.MessageMiddleware",
     "django.middleware.clickjacking.XFrameOptionsMiddleware",
     "debug_toolbar.middleware.DebugToolbarMiddleware",
diff --git a/deploy/local_install/uwsgi.ini b/deploy/local_install/uwsgi.ini
index 45d984c..7c2d552 100644
--- a/deploy/local_install/uwsgi.ini
+++ b/deploy/local_install/uwsgi.ini
@@ -4,8 +4,6 @@ chdir = /home/mediacms.io/mediacms/
 virtualenv = /home/mediacms.io
 module = cms.wsgi
 
-buffer-size=65535
-
 uid=www-data
 gid=www-data
 
diff --git a/users/awsauth.py b/users/awsauth.py
deleted file mode 100644
index c66a156..0000000
--- a/users/awsauth.py
+++ /dev/null
@@ -1,114 +0,0 @@
-import jwt
-import requests
-import base64
-import json
-from django.conf import settings
-from django.contrib.auth.backends import BaseBackend
-from users.models import User
-
-# Inspired by ...
-# https://github.com/django/django/blob/3.1.12/django/contrib/auth/middleware.py
-# we want something like the remote user, but looking at AWS ALB OIDC details
-# this middleware is setup in the settings.py.
-
-header = 'HTTP_X_AMZN_OIDC_DATA'
-
-
-def aws_jwt_validate(encoded_jwt):
-    # Step 1: Get the key id from JWT headers (the kid field)
-    jwt_headers = encoded_jwt.split('.')[0]
-    decoded_jwt_headers = base64.b64decode(jwt_headers)
-    decoded_jwt_headers = decoded_jwt_headers.decode("utf-8")
-    decoded_json = json.loads(decoded_jwt_headers)
-    if 'kid' not in decoded_json:
-        print('kid is missing from jwt header')
-        raise Exception("Invalid JWT")
-    else:
-        kid = decoded_json['kid']
-        # Step 2: Get the public key from regional endpoint
-        # https://s3-us-gov-west-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-west-1/key-id
-        # https://s3-us-gov-east-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-east-1/key-id
-        # url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid
-        url = "https://s3-us-gov-west-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-west-1/" + kid
-        req = requests.get(url)
-        # Access denied if kid is invalid, http 200 w/xml response for error.
-        pub_key = req.text
-
-        # Step 3: Get the payload,
-        # ... pyjwt documentation suggests that
-        # decode(...) without disabling signature verification will perform a verification
-        # That was confirmed with valid jwt.io token which fails validition against AWS pub key. 
-        payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])
-        return payload
-
-
-class JWTHeaderBackend(BaseBackend):
-
-    """
-    Authenticate against AWS JWT signing service
-
-    """
-
-    def authenticate(self, request, username=None, password=None):
-        login_valid = False
-        pwd_valid = False
-        name = None
-        try:
-            username = request.META[header]
-            payload = aws_jwt_validate(username)
-            if not payload:
-                raise Exception("Missing jwt payload")
-            username = payload['email']
-            if not username:
-                raise Exception("Missing email")
-
-            username = username.split('@')[0]
-            name = payload['name']
-            login_valid = True
-            pwd_valid = True
-        except Exception as exp:
-            print("validate exception: " + str(exp))
-            login_valid = False
-            pwd_valid = False
-
-        if login_valid and pwd_valid:
-            try:
-                user = User.objects.get(username=username)
-            except User.DoesNotExist:
-                # Create a new user. There's no need to set a password
-                # because only the password from settings.py is checked.
-                user = User(username=username)
-                user.is_staff = False
-                user.is_superuser = False
-                user.is_featured = False
-                user.is_manager = False
-                user.is_editor = False
-                user.name = name
-                user.save()
-            return user
-
-        print("User not found")
-        return None
-
-    def get_user(self, user_id):
-        try:
-            return User.objects.get(pk=user_id)
-        except User.DoesNotExist:
-            return None
-
-    def clean_username(self, username):
-        payload = username.split('.')[1]
-        # without obligatory padding added you get b64 decode errors.
-        # https://stackoverflow.com/a/49459036
-        decoded = base64.b64decode(payload+'==')
-        decoded = decoded.decode("utf-8")
-        payload = json.loads(decoded)
-        if 'email' in payload:
-            username = payload['email']
-        elif 'unique_name' in payload:
-            username = payload['unique_name']
-
-        if username:
-            username = username.split('@')[0]
-
-        return username
diff --git a/users/middleware.py b/users/middleware.py
deleted file mode 100644
index c98b0c6..0000000
--- a/users/middleware.py
+++ /dev/null
@@ -1,89 +0,0 @@
-from django.contrib import auth
-from django.utils.deprecation import MiddlewareMixin
-from django.contrib.auth import load_backend
-
-
-class AWSJWTUserMiddleware(MiddlewareMixin):
-    """
-    Middleware for utilizing AWS ALB authentication.
-    Read up on the docs AWS provides: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#user-claims-encoding
-    The basic idea is, AWS OIDC configured ALB will place values in headers.
-    You can grab those headers (after USWGI modifies the names) and use known good AWS crypto assets to
-    confirm the JWT token is valid.
-    # x-amzn-oidc-accesstoken
-    # The access token from the token endpoint, in plain text.
-    #
-    # x-amzn-oidc-identity
-    # The subject field (sub) from the user info endpoint, in plain text.
-    #
-    # x-amzn-oidc-data
-    # The JWT Token
-    #
-    """
-    # WSGI changes headers to uppercase, underscore and prefixes HTTP_
-    header = 'HTTP_X_AMZN_OIDC_ACCESSTOKEN'
-
-    def process_request(self, request):
-        # AuthenticationMiddleware is required so that request.user exists.
-        if not hasattr(request, 'user'):
-            raise ImproperlyConfigured(
-                "The AWS JWT user auth middleware requires the"
-                " authentication middleware to be installed.  Edit your"
-                " MIDDLEWARE setting to insert"
-                " 'django.contrib.auth.middleware.AuthenticationMiddleware'"
-                " before the RemoteUserMiddleware class.")
-        try:
-            username = request.META[self.header]
-        except KeyError:
-            # If specified header doesn't exist then it could be dual auth
-            if request.user.is_authenticated:
-                # this allows dual authentication (typical for original admin user + aws alb users)
-                # the admin user has to enter the website from outside the aws alb 
-                # ... ie. (direct ip or another alb that public can't reach)
-                username = request.user.get_username()
-            else:
-                # a user exists on the header but it hasn't auth'd so lets clear out.
-                self._remove_invalid_user(request)
-                return
-        # If the user is already authenticated and that user is the user we are
-        # getting passed in the headers, then the correct user is already
-        # persisted in the session and we don't need to continue.
-        if request.user.is_authenticated:
-            if username:
-                if request.user.get_username() == self.clean_username(username, request):
-                    return
-                else:
-                    # An authenticated user is associated with the request, but
-                    # it does not match the authorized user in the header.
-                    self._remove_invalid_user(request)
-            else:
-                return
-
-        # We are seeing this user for the first time in this session, attempt
-        # to authenticate the user.
-        user = auth.authenticate(request, username=username)
-        if user:
-            # User is valid.  Set request.user and persist user in the session
-            # by logging the user in.
-            request.user = user
-            auth.login(request, user)
-
-    def clean_username(self, username, request):
-        """
-        Allow the backend to clean the username, if the backend defines a
-        clean_username method.
-        """
-        backend_str = request.session[auth.BACKEND_SESSION_KEY]
-        backend = auth.load_backend(backend_str)
-        try:
-            username = backend.clean_username(username)
-        except AttributeError:  # Backend has no clean_username method.
-            pass
-        return username
-
-    def _remove_invalid_user(self, request):
-        """
-        Remove the current authenticated user in the request which is invalid
-        """
-        request.user = None
-        auth.logout(request)

For anyone that is more knowledgeable about Django or Python or general authentication techniques and practices, I'd love feedback on how to make this better.
I don't think my code is going to be flexible enough to handle general cases, or at least there will be a significant amount of configuration design to handle the cases well.

[alfred-stokespace]

One quirky thing I just remembered...

If you are coming through OIDC ALB, you can't signout. If you click

you see the typical "are you sure you want to sign out" thing, you select "Sign out" and then come right back to the home page signed in.
So essentially, there is no anonymous user once you us my code above. Unless you have an anonymous user in your IDP, which is ... unlikely.

[mgogoulos]

Hey @alfred-stokespace , will try to have a detailed look and see if I can contribute anything useful.

And thanks for your good words and for this work! It would be great if you can share a few words on what scenario you're working on.

Cheers

[alfred-stokespace]

Sure thing. So, the broader context is that we have lots of video content. We want our internal users to have access to it. Despite being an internal audience we have very high security requirements. Letsencrypt is awkward because it requires a public facing presence for letsencrypt to engage in the ACME protocol - https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment
A public presence on the internet is always, always an attack vector (would prefer not have those if I don't need them).
And the alternative of managing ssl key material personally creates the hazard of getting it wrong.
So it's much easier to use these AWS ALB options where you never ever have to deal with the private key material for SSL termination. You literally can't get that part of the security wrong because they handle SSL certificates for you. From there you can lock done the security groups (ie. firewalls) so that only the ALB and the hosts or containers can speak to one another. So http between ALB and Nginix is fine, although probably could be done with private signed keys, but not like it maters a whole lot at that point.
From there we don't want our internal users having to create accounts in all our internal services, ie. we want SSO & identity federation.
AWS ALB's have you covered there also. Configure the ALB to talk with your IDP and now can get the user profile information through a standards based approach, OIDC/Oauth2 in this case.

So the benefits here are...

1. High security
2. Ease of use ($ -> AWS)
3. We always know who is accessing the site,
4. Users needed to login with our IDP provider which is MFA'd and all the standards for company security are enforced there.

[alfred-stokespace]

I found a problem with this approach recently. And I suspect this issue will hit anyone else that tries to connect any identity authority to MediaCMS in an SSO implementation.

When you populate username in MediaCMS you have to be careful to respect the "only letters and numbers" requirement. My identity provider (and our administration rules on usernames) allow for things like - and . in what we consider our username.

This meant that a user logging in would get a user created in the db but would then get a 500 during page loading while trying to execute the edit_url reverse function.

  File "/home/mediacms.io/mediacms/users/models.py", line 78, in edit_url
    return reverse("edit_user", kwargs={"username": self.username})
  File "/home/mediacms.io/lib/python3.8/site-packages/django/urls/base.py", line 87, in reverse
    return iri_to_uri(resolver._reverse_with_prefix(view, prefix, *args, **kwargs))
  File "/home/mediacms.io/lib/python3.8/site-packages/django/urls/resolvers.py", line 685, in _reverse_with_prefix
    raise NoReverseMatch(msg)
django.urls.exceptions.NoReverseMatch: Reverse for 'edit_user' with keyword arguments '{'username': 'steve-workerperson'}' not found. 1 pattern(s) tried: ['user/(?P<username>[\\w@.]*)/edit$']

I "fixed" this issue in my installation by adding some protection code on authentication that converts non-conformant characters to some other character.

Basically, the point of all this is Media CMS doesn't support having a consistent "username" with the rest of your organization. The rest of your software systems might display/refer to your user "steve-worker" but mediaCMS has no way to support "steve-worker" and poor Steve will have to be something like "steveworker" in mediacms.