The last major piece for me to be able to use the Mud System is dealing with identity and access. In the long term I would really like to find a solution for implementing security controls in a distributed system but for now I think I will go with what is easy: JSON Web Tokens. This will require the service to have secret key material to verify the tokens, however I think I can live with that.

When invoking this application via the command line passing a file with secret key material is not a problem. However when you run a Docker container you find yourself in an interesting place. You could mount a volume within the container and use that. For now I think that will be the approach I would recommend, as again, ideally you would have a centralized system which would deal with those details.

So the for right now the service will simply use the JWT to verify the request is authorized to perform the action.

Locking down the API

With the exception of operating systems, most security layers I have worked with had role based access control (RBAC). This tends to be a balance between flexibility, ease of implementation, and reduction in complexity. A capability model offers much better flexibility however is much harder to reason about and verify the implementation of. At this point the minimum viable product I need is just a boolean gate: was the user given a token to perform operations?

For backwards compatibility this results in two implementations: a JSON Web Token (JWT) being required and a unit which allows all operations. This will be controlled by a simple switch on the start.

Updating the client

Due to needing to read the tokens from a file the CLI client needs to be updated. This was another step away from being a synchronous API due to file loading. At this point I am wondering if it makes sense to wrap all fs modules in the junk-bucket so I do not have to keep rewriting this segment:

const fs = require("fs");
const {promisify} = require("util");

const fs_readFile = promisify(fs.readFile);

Probably have a cleaner API too! In truth I have not done this because I was hoping the NodeJS folks would come up with a way to do this, thus making it obsolete…but sigh, they have not. promisify is a better alternative than the es6_node method I created but es6_node has been around long before the whole promisify utility.

Looking towards the future

This accomplishes the very least I need to have a network storage layer exposed of HTTP. This is awesome as it allows me to build and test a number of items, such as image analysis. I expect to find a number of desired items over times which will make this nicer. Right off the bat, a more granular permissions system would be nice. After that, probably using HTTPS would be awesome.

There are still additional extension I would like to provide. Secure and transparent storage to an external system like Dropbox or S3 would be good. Those will have to wait for another day.