Authentication vs Authorization.

It’s been a while since I last wrote about this project. My Kubernetes server had a meltdown and I had to go through the process of setting it all up again. This time I stuck with a premade solution,  MicroK8s as described in  Exposing your Home Server to the Big Bad Internet. The ingress is hooked up directly to the Internet and SSL is handled through  Cloudflare. Also, the volume claims are direct disk access since MicroK8s is a one-node cluster. The new Kubernetes description files are still in my GitHub repository  blackbook-deploy.

Part 2 of this series ended when we had the backend server simply return the JWT cracked open and the front end displayed it as basic text. It was pretty ugly. Most of the fields of the JWT aren’t going to be used. But there is one, claims.sub that will be used to index into a MongoDB database to return a user record. That value is the user’s email address and will become the user identifier for this system.

Our read profile service will return one user record with all of the basic information about the user, and will only be available for that user. The endpoint will be seemingly misnamed ‘users’. I picked users because there might also be a class of administration users that can get all of the users, or users other than themselves. But that will be done later. For now, it will only return information about the person that is logged on.

This is an important feature of authorization. Once you are authenticated by sending your credentials through the logon screen, the system knows who you are, and what roles you have. Currently, there is only one role, that of a user. But we still need to prevent that user from seeing the private data of other people. Since we can’t have a role for each user, we will discriminate based on the user id, which we get from the JWT that is returned when you authenticate (log in).

We will store this data in MongoDB in a collection called users. To get MongoDB up and running in our system, we can follow the process outlined in my article How to use Kubernetes Cron Jobs to Periodically Read the News. If you have been following along with my Blackbook series, you should already have a Kubernetes namespace called blackbook. If not, you should create one now, as everything will go in that namespace. Change directory to blackbook-deploy on the Kubernetes host, create a file called namespace.yaml and enter the following:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    name: blackbook
  name: blackbook

#mongodb #nodejs #expressjs #kubernetes