I hope you’re all doing well! I would like to seek your opinions on an idea I’ve been exploring, which could bring benefits to our community.
I’m currently working on developing a new application that would focus on user management for Node-RED. The goal would be to simplify the security of your Node-RED projects by providing access management to both the editor and Dashboards. The aim is to offer a straightforward solution that enhances security and user experience without overlapping with the features of existing solutions such as FlowForge. Additionally, I’m also considering a multi-instance/project variant that could cater to diverse needs.
Before moving forward, I would appreciate your insights:
1. Do you see value in such a user management application for Node-RED?
2. Which access management and security features do you consider essential in this application?
3. Would you be inclined to use a solution of this kind? If so, would you consider a subscription model or a one-time payment for advanced features?
4. Are there specific challenges you’re currently facing regarding security and user management in your Node-RED projects?
Your feedback and suggestions are crucial in shaping this application to best meet the needs of the Node-RED community. Thank you in advance for your engagement and contribution!
I think I'd first like to know how you will get round the current limitations of Dashboard? As Dashboard is a front-end SPA, how will you ensure that Dashboard behaves properly when dealing with multiple users?
I think you would also need to consider that Dashboard and http-in/-out nodes are not the only ones that can and do make use of Node-RED's node.js http(s) server along with the 2 ExpressJS instances (admin and user) and the Socket.IO instances. uibuilder, for example, also makes use of the http(s) and ExpressJS instances. I expect there are others too.
In general, my preference for security would be to have an agreed way to use external authentication and authorisation via a proxy. Providing some examples and agreeing some standardised data exchange (how to identify a user, passing session timeouts, and how to declare user roles for example).
That has a number of advantages such as being able to update your security tools independently of Node-RED as well as being able to use a battle-hardened tool that has a much wider user based than Node-RED (NGINX for example). It would also let you use the same secure front-end for other web apps as well.
Any security NEEDS to be independently auditable if you want it to support enterprise-grade IT. Using well-known tools is very advantageous for that.
Some of the challanges for securing Node-RED:
Need to be able to connect to different user data sets so that it is scalable and can integrate with identity solutions.
Should not just secure the http(s) connections but also the websocket/socket.io connections - this is especially tricky since, once a websocket connection "upgrades" to ws(s) from its initial http(s) handshake, it has no access to custom headers. This means that many traditional security handshakes cannot maintain ongoing safe (and timed where needed) connections.
Should use well-known security and identity management standards.
Ideally (IMO), should allow for multiple Node-RED instance back-ends as with any other microservice horizontally scaling architecture.
And it all still needs to be easy enough to install and configure that novices can do it if needed without necessarily needing expensive IT support (though honestly, if your data/service has any value at all, getting expert help for security and identity is a must). Recognising that Node-RED is used in simple 1-device data processing & automation, through home automation, through industrial automation right up to enterprise-grade high-value environments.
Thank you very much for these detailed insights. Your vision regarding how to address the security and authentication challenges in Node-RED aligns closely with mine. Regarding websockets, I believe that authenticating up until the upgrade to ws is a reasonable way to approach the matter (I do not intend to authenticate every ws message).
I also fully understand your perspective on multi-user management, but that is not the focus of this development.
With that said, I'm curious whether you believe the Node-RED community would be interested in this enhanced security approach and external authentication through a proxy. Security is undoubtedly a crucial topic, and I'm confident that many individuals within the community could benefit from your expertise in this domain.
Note - my comments are based on the assumption that you intent to monetize a security solution aimed for enterprise purposes.
There are 2 things -
node-red - the editor
dashboard
Node-RED by its very nature just runs and executes - only specific people (one that develops flows) require access to the editor. I don't see how this could be done in a multi-user setup, other than having user accountability with an audit trail and perhaps read-only capabilities.
That solution is already available: adminAuth settings can be customized for use with other authentication methods. If they can play easily along with today's security requirements I am not sure.
Many enterprises are moving to dynamic credential solutions like Hashicorp Vault.
The dashboard is in my opinion a different aspect/beast that should require separate security requirements and could/should have things like RBAC, but then in turn also LDAP, Radius etc integration.
But then again - if one is thinking about these complex strategies - a custom dashboard would also show up in the picture - with data as API served over http-in with custom authentication via httpNodeAuth
My own view is that, while security for web services via a proxy is a well trodden path, it is quite complex to set up and get right. There is also a need to pass some information on into Node-RED and again, this can be challenging to get right. So those are certainly areas where the community would benefit from having some more well worked examples.
Without session management though, including expiry, that works closely with websockets - since Node-RED based web apps rarely need to reload pages - the benefits are limited.
Security needs to be managed holistically, not in parts.
Two? Even native Node-RED has 2. The Editor and the http-in/-out nodes. Then add Dashboard for a 3rd and contributed nodes such as uibuilder and Flexdash for more.
That is correct. Security has several facets:
Preventing unwarranted access (that bypasses the other facets).
Authentication - the identity part, who is accessing the system.
Authorisation - For a given set of identities, what access to they have to specific parts of the system.
Thankfully, since Node-RED uses different URL's for different parts of the service, the broad-brush aspects of authorisation are easy enough. Just give specific user id's/groups access to specific URL's. A proxy can easily do that.
But if your Node-RED flows need to be able to make authorisation decisions, an external security feature needs to be able to pass information into the flows. This is certainly doable for web page loads using custom headers. But for a websocket based solution, it is harder because you need to attach the information to every websocket message. Socket.IO certainly has features to support this. But it is complex to get right. At least in part because you are now working not only with the Node-RED service but also with the users browser.
Correct. As must http-in/-out, uibuilder, etc. But this is just an authorisation issue if you raise up the overall security tooling to an external service like a proxy. Different URL's get different authorisations.
For Enterprises, they will almost certainly already have an existing set of Identity Management tools that they mandate. Things like Azure Active Directory, Okta, etc. If they have sensible Enterprise Architects , those IdM tools will use open standards for interoperability. SAML or OAuth nearly 100% these days.
But not forgetting websockets again. A REST API is great for intermittent grabbing of information but generally poor for 2-way near realtime comms. That type of comms makes for a great user experience, making web services often the equal of installed software but without the management overheads of local software. But that comms still needs securing.
Because, and no slight intended against Flowforge, it is a largely untried, unknown small business solution at present. Whereas services such as IIS, NGINX, Apache, etc have been battle hardened and tested over many years and are well known and understood by a lot of professionals. It would also be another licensing cost that might not be needed in an enterprise environment where the tools almost certainly already exist and may well already be sufficiently licensed.
Having a well presented and documented architecture for Node-RED security using well-known, industry-standard tools would greatly reduce the friction for the adoption of Node-RED in an enterprise setting.
And perhaps I should finish by presenting my credentials in this matter. They are that I am an Enterprise Architect for NHS England. We look after architectures and standards not only for NHSE but across the NHS as well. So our IdM solutions range from our 15-20,000 users, through the 1.7 million users of central NHS services up to the 70-odd million patients and public in the UK.
Large enterprises rather have support and negotiate SLA's with 3rd parties than managing the complexities themselves - it becomes a moneypit. Support contracts are cheaper than employing an x number of people to manage all aspects plus you can shift the burden when things go south (depending on the contract).
It does not make much sense to run nginx/apache in a devops/platform engineering environment - orchestration capabilities like kubernetes (which flowfuse/forge supports) to facilitate self-service functionality is a more likely path and it seems that flowforge is paving a path in that direction.
it is a largely untried
That does not matter for an enterprise, they perform internal assessments, create requirements, look at the market, deploy some vm's with various selected products and determine via review boards which product ticks most boxes (and security is usually near the top of the list).
Anyway, I digress. I wish the OP good luck on this endeavor
Yes, we are off topic now. Let's just agree to disagree here. There is much more to this topic than we should explore in this thread. Such as whether Kubernetes is a good fit for an enterprise DevOps environment - in many cases it no longer is.
It really does matter. And you have described much of my job The proven health (financial as well as procedural) of a vendor is as important a measure of "security" in its wider sense than any review of cyber security. You don't, for example, commit a large enterprise to be reliant on a small business without some very careful risk mitigations. But that is even further off-topic.
Yes sorry, I meant security in the broad sense of the word, not just technical - including financial stability/backing and which parties are using it etc. Full market research is key for the assessment.
Then again, node-red fulfills a very specific niche in the market, there are not many alternatives.
As FlowForge (we've rebranded since to FlowFuse) is mentioned a few times, I wanted to chime in here and clarify a few things.
The main reason for our offering to exist is to make operating Node-RED at scale (either in terms of many users, or many instances) a breeze. Including security. While it's achievable to secure Node-RED outside of FlowFuse, and we're trying to help you achieve just that, it's a core feature for us to help anyone setup 1 or many Node-RED instance in around 1 minute - with secure defaults. The defaults might differ from what the NHS England needs, though I bet the requirements of your case @TotallyInformation can be set as default on a self hosted FlowFuse instance too.
Then regarding the uncertainty a young company has around it, that's certainly true. What I can say is the following: Our Seed round was rather large precisely to reduce the risk for our customers. We've gone through multiple risk assessment questionnaires including financial and security assessments, for councils, region government, and multiple $Xb ARR companies which we've sold to.
"No one gets fired for buying IBM" is a well known trope, and we still have a long way to go before people say "No one gets fired for buying FlowFuse", but if you have questions, ideas or concerns I'm very happy listen and discuss.
Wishing you all the best on the endeavour. I wasn't criticising of course, merely pointing out the issues faced in enterprise grade IT, especially in regulated and government industries. We DO have some Node-RED instances deployed - though actually not by us but rather by one of our vendors ATOS as part of their operations and monitoring support. They are deeply buried inside private architecture though and a long way from even my access, certainly not accessible from the Internet. I did get a bit excitable when I saw it in the architecture I have to admit
Node-RED, even without FlowFuse, could deliver a lot of value to the organisation but that has to be balanced against people misusing/misconfiguring it and against the security & privacy reviews and governance we have to go through. I've used Node-RED a few times myself to get specific tasks done but never managed to get it introduced as a corporate tool. Too much other competing noise and work so it is very hard to get something like this introduced. Hopefully FlowFuse will make that easier in the future and we will see more of our suppliers proposing it for practical solutions.
As soon as you start to target enterprise solutions, multi-user support is an obvious requirement, it must have it, it has been mentioned so many times already. Look at all commercial & professional solutions, they all have it. But without also having support for multi-tenant, it becomes useless, like jumping on one leg only, you will find out yourself once you implement such a solution. I think if flow forge missed that part, they better dive into it soon since it will most likely affect the architecture (ownership related). Even if it just is a bunch of distributed RPi's you should assume different ownership and admin rights for those
In summary, multi-user and multi-tenant, yes, that is a mandatory requirement to fulfill if you say you can provide an enterprise solution
Thanks, it wasn't taken as criticism at all. Just as this is a public forum, I wanted to take the opportunity to provide insights into our operations. We'll keep working on making Node-RED approachable for enterprises and regulated entities!
, those IdM tools will use open standards for interoperability. SAML or OAuth nearly 100% these days.
The proven health (financial as well as procedural) of a vendor is as important a measure of "security" in its wider sense than any review of cyber security. You don't, for example, commit a large enterprise to be reliant on a small business without some very careful risk mitigations. But that is even further off-topic.
