How to set user permissions for Node-RED Editor when the users are defined from a Reverse Proxy?

General
1

Description

I have a Traefik Reverse-Proxy with the some users which provides a middleware for HTTP Basic Authentication and node-RED is deployed behind this reverse-proxy.

So far the Admin API and Editor are "secure" with basic authentication logic i.e. Browser asks for the credentials and curl commands require -u <username>:<password> input upon accessing the APIs.

From the documentation each user within the users array has permissions for * and read. If I were to stick to the basic authentication users defined at the reverse proxy, could I build a middleware that reads some additional http header that would set the permissions for me for the authenticated user?

What I am trying currently?

I am currently trying to parse the Basic <base64encodedCreds> using the documentation for tokens middleware to add to the users array using the middlware documentation for Auth Administration. However is there some logic in the HTTP Requests forwarded by the reverse proxy where I can can set the permissions key according to some logic as opposed to hard-coded logic at the moment?

2

At this point, a middleware based on the HTTP Header forwarded by the Reverse Proxy has solved the problem temporarily:

Middleware: user-authentication.js 

module.exports = {
  tokens: function(token) {
    return new Promise(function(resolve, reject) {
      console.debug(token);
      var user = {username: token, permissions: ""};
      if (token == "admin") {
        user['permissions'] = "*";
      } else {
        user['permissions'] = "read";
      }
      console.debug(user);
      resolve(user);
    });
  },
  tokenHeader: 'X-WebAuth-User'
};

The X-WebAuth-User is an HTTP Header that sends the authenticated user (authentication happens at the reverse proxy) to Node-RED. This header is then used to determine the permissions for the user e.g. admin must have all permissions and others have only read permission (very primitive).

Settings: settings.js 

 // ... snip
  adminAuth: require('./user-authentication'),
// ...snip

Make sure to have the settings.js and user-authentication.js in the same directory (either in docker container / native machine)

Drawbacks

Node-RED does not provide possibility to parse multiple tokenHeader settings. The implication for this is that one cannot send additional Headers e.g. X-WebAuth-Permissions: Read, which can be parsed further to make the middleware more dynamic.

3

I believe that Node-RED's middleware function features are indeed the correct way to handle this. Use your reverse proxy to manage the authentication and set one or more headers if needed (possibly not needed for basic auth) and write a middleware fn to check the header.

Of course, you should also ensure that you've changed the node-red settings so that you cannot get to Node-RED except via the proxy. If both run on the same server, it is easy since you can get Node-RED to only listen on localhost instead of the default which is to listen on all network endpoints. If the two are on different servers, you will need a local firewall on the node-red server to prevent access from anywhere but the proxy. You should also configure node-red to trust the proxy so that you don't run into problems.

4

agreed. my case is single instance on single server. since my setup is with docker I have a tight coupling in terms of proxy and nodered. I do wanted to clarify whether there is a possibility to parse more headers in tokenHeader? so far there is only single header parsing

5

Not used this myself so somewhat guessing here. However, it looks fairly clear that you can only process a single header. To process more headers, you would need to use the general middleware functions instead. I think this relates to the use of Passport under the skin?

A possible workaround would be to switch to using a JWT. That way, you could embed additional data in the token.

Just remember that JWT's themselves are NOT a security "feature", they are a convenience - and by default they are designed for very short lifespans (minutes to hours, not the 7-day default in Node-RED sessions). They are subject to fairly easy token hijack attacks. So you may want to consider adding other protection to reduce hijack attacks.

1 Like
6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.