Exactly my situation too!
I have currently solved this by running a separate Home Assistant instance for each family member, connected via the Remote Home Assistant integration.
For each instance, I only share the entities that the respective person needs or is allowed to control. While this approach ensures privacy and tailored access, it is very time-consuming to set up and maintain, especially when it comes to updating add-ons and configurations across multiple instances.
In my opinion, this is currently the only viable solution.
2 Likes
this is actually a neat idea. I wonder if you could create an addon that just runs home assistant core and allows access to a list of entities that can be defined via configuration. that would probably solve 80% of the usecases and could be implemented in a fraction of the time that the “ideal” solution would require.
I see two issues with doing it as an addon:
-
AFAIK addons have a globally unique name. You can’t just install multiple of the same addon without multiple different addons being defined at the addon level itself. That is, whoever ends up creating this would then have to have a user1, user2, user3, user4, etc… addon available for install. I’ve seen a few posts related to this issue with folks trying to run multiple ZWave-JS UI addons because each one can only service a single mesh, but the there is only one addon available so it’s difficult
-
The it could take quite a bit of work to keep the addon properly in sync with the base HA.
Other than that, it’s definitely a brilliant idea for a way around the current limitations!
Another +1 here.
I would love the ability to create a login for my HVAC company and limit them to a single dashboard that tracked the HVAC status for when we’re trying to troubleshoot an issue…
… or a login for my neighbor to enable them to view the street-facing cameras…
RBAC for being able to toggle which Dashboards (even, say One Dashboard, all pages on it) on & off for a user would go a long way towards being able to expose the UI to someone outside of the house.
2 Likes
It’s not sexy, nor is it simple, but in my opinion, RBAC is likely the single biggest feature holding back Home Assistant from significant widespread adoption. Until I can say my kids have limited access, or I can create a locked-down service provider account, or any other scope-limiting access control, I don’t see how people can truly expand use of HA to the masses. As it stands, I don’t let my own kids access HA, because they’re both highly likely to find ways to accidentally or deliberately break things.
4 Likes
My wth contribution
I believe this is a long standing ask so to be constructive I’d like to share some tech ideas which may help to bring (or not) a technical architecture.
I suspect that one of the concern may be on how to retrofit the access control in a way that it provides the right level of security without impacting the performance of the overall stack. The other issue is to apply it a such away that the maintenance is reasonable and without being bypassable (otherwise what’s the point).
One approach would be to get an RBAC directly on the SQL layer (where the permissions are set) - however SQLite does not allow user authentication. This type of architecture passes different SQL user based on the authentication and is there controlled by the SQL layer, which means that only the SQL access control need to be done, modern SQL can control row access.
As a user I would be happy to have a db requirement (ie not SQLite) to benefit of an access control.
Another approach would be to perform similar access control as linux file system, the object as an additional meta information (Integer) on which bitwise operation would be performed to allow read write and administrative access.
From a modification point of view this may be the most compatible way after the recent modifications. From a control point of view this would nod add significant complexe SQL queries and may allow a centralised code.
The benefits is that all ‘object’ including function could be covered by the access control. Bitwise operation are extremely fast and accurate.
This solution would work regardless of the SQL stack, and could be directly integrated in the API.
Happy to extend if the dev see benefits in any of the two solutions.
2 Likes
Guest user would be an ask beyond what i’m asking, but it needs implementation of what i’m asking too. Controlling access to a dashboard is fine and good, but without access control of the entities anyone can open web developer console and sabotage any HA entity state.
This. Exactly this. Not a guest user, but access control per entity so the kids can safely play around and discover without breaking stuff. Please make it a top priority.
4 Likes
Kids! So many of us have graduated from single to couple (OK, we can be the IT help there) to children. And kids have tractor hands. RBAC would basically close the gate on potentially destructive actions (I don’t want an enterprising 7 year old shutting off a gas valve!).
5 Likes
Mine is the breaker boxes. But same exact use case. Some things simply don’t need access by all users. There needs to be a security model
And that model needs to be zero trust guest and standard user off by default they get access to NOTHING unless explicitly exposed to the guest or non priveliged user.
Id even go so far as preferring thag they get sequestered into one dashboard and everything that goes on that dashboard throws an error until it’s ‘allowed’ in the security model.
1 Like
While not an easy thing to implement it should definitely be a target for next year’s improvements. +1
Hass is good but really have som things missing that are basic for a “smart” home system.
User access control for devices, scenes, dashboards etc is fundamental and I really hope that we get this prioritised.
I would also appreciate the option to actually lock the hamburger menu, (not have it shown) and only navigate with buttons in a GUI that i control, very useful for smart home panels.
If anything, that would be merged into this one, not the other way around.
2 Likes
That WTH is unrelated to this one.
1 Like
This is a significant concern for me as well from a safety perspective. I can connect my Unifi router to HA and this exposes entities for firewall entries. This is great from an automation perspective, but basically nobody in the house should be able to fiddle with those. I’ve considered running multiple HA instances, but to me that’s too much overhead and sidesteps the issue that HA should be able to handle it internally in a single instance.
6 Likes
I would like permissions for what users are able to open the sidebar history, map, logs and media tabs.
Usecase: i have friends as users in my hass instance. They have access to a single dashboard view. Yet they are able to see logs and history at will. I, as an admistrator, would like to hide these sidebar options for those users so they can basicly only see the single dashboard i wand them to see.
Admin options are already hidden for users.
2 Likes
Thanks for sharing! I’m Annika, User Researcher at Nabu Casa. I’m trying to get a better understanding of the user needs and pain points around access control.
Can you please elaborate why a privilege system feels important in the context of Home Assistant being used to control your house’s heating and hot water production? What challenges or concerns are you looking to address with it?