I’ve looked at a number of authorization and authentication frameworks for NodeJS in the last year. While there are a number of good authentication libraries around, most of them bill themselves as authorization, as well – which is very wrong. There just aren’t very many good authorization frameworks… maybe one well rounded framework that I found. Unfortunately for me, I didn’t agree with the opinions of this framework, so I’ve spent the last year building my own for my apps and my needs. Having been using it in production for quite some time now, I found myself needing to extend it for additional scenarios and at this point, I’m happy to say that it is ready for the general public to use.
MustBe does not bill itself as a complete framework for all of your authorization needs. Rather, it is the plumbing that you need to integrate authorization in to your NodeJS / Express applications. In other words, it will provide the core features that you need for configuring and authorizing access to your Express application’s routes. It will not provide data access, user models or other application specific logic for you. It provides a way for you to integrate your app’s logic and code, with NodeJS / Express, to create a complete authorization
I built MustBe with the knowledge that I will be (and am) using it across multiple projects, with varying data access and user authentication strategies. Therefore, MustBe requires a necessary amount of configuration to be used with both your data access / authentication strategy, and for the various activities that you wish to secure in your system.
Activities Based Authorization
One of the more important points in my deciding to build MustBe, was the need for activities based authorization. The idea behind this, is to not have your code check for specific roles in order to authorize access to a feature. That creates problems in the long run, as it hard codes your application to a specific set of roles.
Instead, activity based authorization allows you to specify that access to a feature or function within your code requires authorization for a given activity. For example, updating a user may require authorization for the “user.update” activity. Creating a new Widget for your store to sell might require authorization for the “widget.create” activity.
Thinking in terms of activities allows your system to remain flexible, as you can decide which roles have access to which activities in your system, in any manner that suits you. You can use data access to load the roles and access rules. You can hard code the relationship between a user and an activity. You can even grant access to everything, in an unlimited manner, by providing an override and specifying “admin” users as always being allowed to do everything.
The manner in which you configure whether or not someone is allowed to do a given activity is up to you – and this is where MustBe steps out of the way, so that you can provide your own logic and code. MustBe will take the code that you write to check for authorization, and apply it to your Express routes and middleware, handling both the success and failure of the authorization request.
Authorizing Users And Other Things
One of the more recent additions to MustBe, is the ability to authorize things that are not users. Most applications depend on users being logged in, to be authorized, but not all of them or all the time. There are scenarios where you need something other than a user to be authorized.
In my case, I have Accounts inside of my SignalLead podcast hosting service. These accounts must be authorized to serve podcasts. Being authorized entails a number of things, including the account being “active”, having a podcast to serve, etc.
When I set out to implement this originally, I hacked in some code and features to make it work but it was ugly. I’ve recently rebuilt MustBe through a series of refactorings and restructuring, allowing me to add the notion of custom Identities to MustBe. Using custom Identities, an application can now authorize anything that needs to be authorized – and can authorize as many things as are needed, from within a single application.
The default identity for authorization is still a user – but that is only the default. If you need to authorize something other than a user, you only need to provide a few lines of code to define the thing that needs authorization, and then configure what it is allowed to do through the normal activities configuration.
Securing Routes, And Security As Middleware
Another aspect of MustBe that makes it powerful, is the ability to use its “routeHelpers” as both a security mechanism for a single route handler, or as middleware for an entire set of routes or the application as a whole.
While MustBe can be applied to a single route quite easily, it is not fun to copy & paste the same authorization check in to dozens of routes. Using MustBe as middleware for your Express application, you can reduce the configuration of authorization checks down to a single location in many cases. I’ve personally used it to secure entire sites, and single routes and sub-route tree structures, quite easily.
Check Out MustBe, And Authorize Your Users Easily
I’ve built this system from within my own sphere of needs, meaning it may still be missing some features or configuration to be truly useful to others. But the beauty of open source, is the ability to see a need, modify the system and send in a pull request.