Hello! I try to implement but I have no idea about the filter.cgi shortcut? Where should he be? In the event that I can log in with different users but the android application does not work?
Regards!
Hello, I am a little late to the party.
Anyway I would like to introduce the following project to you:
A few, very short words
Technology involved
It uses NGINX as reverse proxy and mutual TLS authentication (client certificates) to determine (with the help of a NodeJS app) which Sitemaps, MainUI pages and Items a client has access to.
Concept
Each client has a unique username and can be member of multiple organizations.
Each organization can have multiple Sitemaps.
The authorization of Item access is build on top of the Sitemap authorization, my project does not require any real configuration outside of openHAB & your CA for the client certificates.
Hi to All.
I want follow-up to the earlier message of Florian H. and let you know that I have created a fork of his great Multiuser proxy project.
His project is no longer maintained and has been archived. I have done major update to it and now it fully supports the MainUI of openHAB 3 and 4, granular filtering of user access at the level of individual Items, Pages and Sitemaps. Iām now using it in production for my quite sizable OH instance. It has been tested with both OpenHAB 3 and 4.
Feel free to look at it and test it. The documentation is fully updated as well and shall be quite self-explanatory.
GitHub - Davek145/openhab-multiuser-proxy: openHAB Multi-User support for the REST API v 2.0.2
Does this work via openhabcloud?
It cannot - openHAB cloud connects to openHAB via localhost (however there is a way to put a proxy in between, but mTLS doesnāt work via openHAB Cloud, so you donāt have the user information).
If you mean openHAB Cloud hosted at myopenHAB.org than not really. For filtering to work, you need to place this filtering proxy in front of openHAB instance and prevent direct access to the REST API.
For public cloud service you can limit items pushed from your local instance in the connector instead.
However, if you have cloud instance under your control, than yes, you can use it as well. You will likely need to adjust nginx proxy setup and verify how is the REST API exposed in your cloud instance. But in principle, it shall work.
David
Thatās what I thought so since openhabcloud access openhab instance via openhab connector.
In my opinion you need to consider overall security architecture of your OH rollout.
If I have use case that requires securing OH Rest API and user authorization on item by item basis (that is what the multiuser-openhab-proxy with mTLS does), I shall not expose my items for remote access to shared public openhabcloud via the connector. And similar to any other third party not under my control. As this opens other attack vector to my OH instance.
Instead I would access the local OH instance via properly configured VPN. Or, if I need other features of the openhabcloud like notifications, I would roll out my own dedicated instance of it at proven SOC2 attested cloud provider, embed logic of the multiuser-proxy to it for segregating access of individual users to specific items including third party services (i.e. Alexa). Properly secure communication between it and my local OH instance, add WAF, IDS and monitoring to public facing interface etc.
It is doable to do it securely, but for sure it is not effort and cost free. And probably too complex for majority of OH users.
On the other hand, if my use case is OK with exposing my OH items to shared public openhabcloud, than I would not bother with additional filtering of REST API access. For such use case using visibleTo (+custom roles added by Karaf console) to filter items for users at presentation layer only shall be sufficient.
If you only need notifications, you can use the openHAB Foundation-operated openHAB Cloud, just disable remote access in the cloud connectorās settings.
What do you exactly mean with āFor public cloud service you can limit items pushed from your local instance in the connector instead.ā Actually Iām looking for a way to have all items in the openHAB Cloud at http://myopenHAB.org read-only. Only very few items shall be able to be written. Is there a way to achieve this? Another approach would be to have certain things like KNX not accessible over the cloud.
Iām afraid that you cannot get this done with public instance at http://myopenHAB.org. Look into Advance configuration of the openHAB Cloud Connector. As described by Florian, you can set-it up to provide notifications only (=disable remote access). But you cannot limit items exposed via remote access and/or set granular setting of ACL on per item basis.
I have such granular ACL done for my OH instance, but at Rest API level using the filtering proxy described earlier. Iām not using Cloud Connector and openHAB Foundation-operated openHAB Cloud instance.
I think it is possible to somehow configure the cloud connector to forward the cloud requests to a different port than where the REST API normally sits, so you can put a proxy in between ā however nothing mTLS based.
If this is possible even with the public instance of openHAB Cloud, than openhab-multiuser-proxy can be used to achieve the goal @STSC have described = have all items read only and only selected items would be allowed for control.
However, as Florian described, mTLS authentication is not available. So either one would have to apply different way to differentiate users (can not think of one now, depends on the data cloud connector can actually pass to the proxy). Or access will be the same set of RO and RW items for all users = proxy will be filtering access to API to only allowed actions on fixed set of items, but it will not be multi-user.
Also, both config of nginx as well as backend node part of openhab-multiuser-proxy would have to be slightly modified to allow separate ACL for GET and POST on the /items/ part of API. But it is nothing difficult to be done.