Hi there Missy. I love it when you appear on stream.
Isn’t access control matter of adding a layer that checks for permission to run actions involving entities in between the user interface and the actual code of the integrations that executes actions? If the action takes an entity, then that entity should be evaluated at that point or that layer. There is more sophisticated processing needed in the case of devices as well. But if the device referenced by the action implies an entity will be managed, then the permission for the entity should count.
As for the view or read side of things, there should be a layer in the web socket communication that sends status updates and renders Jinja templates (id est the code powering the hass object in the frontend) that filters out entities a user shouldn’t be able to see, coupled with the same filter at the history / logbook entr points.
One thing that I’m thinking of people would find extremely useful is if I make a dashboard, I should be able to, for example, in the case of a tile in a section, go to the condition step and hide a section or a tile if the entity it’s referencing is forbidden for the user. This could mean that there is a check that doesn’t exist yet that verifies that the entity is visible from the standpoint of the user based on the permissions that the administrator has delegated on the entity and user.
This would make for very adaptive dashboards that hide entire sections if a user has not been granted permission to a specific entity. Or putting it into other words, if the home assistant frontend cannot see that an entity exists because the backend has filtered it before sending any data to the frontend.
You can not examine all the use cases people have in their minds. Some may control their fish tank with it, their woodworking shop full of machinery or a small hotel. HA became a general purpose automation tool and may also contain a ton of sensitive data. It should offer the highest grade security possible. As should any software by the way. This is trivial.
But if you need more examples:
Lots of us are controlling high power equipment or moving objects like gates and garage doors. Those can kill someone or burn down the whole neighborhood. Security in such applications must be implemented in all layers from a photocell at the gate and torque sensing in its motor driving electronics up to Home Assistant. A kid opens and closes the gate just for fun because he has access to all the entities in HA? Not in my house.
So my answer to your “Why is that important to you?” question is: I like to sleep well.
As someone being involved with home automation since 1980 (yes, you read that right) and have used several home automation platforms throughout the years, I too am shocked that there is no RBAC in a product as sophisticated as HASS. I’m currently using HomeSeer and trying to migrate to HASS, but the lack of access control is troubling and an actual risk to privacy and safety. I won’t state individual use cases because others here have already stated exact scenarios where privacy or safety are jeopardized due to anyone having complete access to the system via the app or a web browser.
I’m also thinking of going back to being a home automation integrator/consultant once I retire from my corporate job and I would love to be able to recommend HASS to non-technical people. But without the ability to prevent casual users from messing up their systems, there’s no way I can responsibly recommend using HASS.
Another vote for making 2025 The Year of Security.
I like to expose some very specific entities (like solar production, hot water and heating temperatures, garden lights) to my granny flat within our house. Currently this is not possible because of the missing implementation of RBAC. Working around with a second HA instance and pushing values over MQTT, which is very complex to manage…
IMHO this topic can no longer be ignored by the core team. The votes speak for them self. Looking forward to a secure 2025.
hi @anakinsbrn , thanks for collecting more feedback!
First, I want to highlight how frustrating it is not being able to give my kid access, as HA don’t really support multi-user - it doesn’t have a permission system (RBAC…)
Just want to illustrate it from my perspective. First, kids today have access to AI assistance. In my house we prefer Perplexity, which happens to be a real HA expert, So, it is trivial to find out in a couple of minutes how to workaround any artificial limit I can impose as an admin today. Anyway, once a kid deletes something like an automation (accidently or even on purpose to prank or annoy), it would be just a world of pain:
First finding out about it hours of days later when HA seems like it not working.
Spending time trying to debug, only to find out eventually that an automation is missing.
Trying to understand if it is a UI bug (for some reason it does not appear), or an HA bug etc
Eventually either trying to recreate the automation (if simple), or having to create a new VM somewhere to restore an older backup, trying to extract the automation. Can require multiple tries - for example starting yesterday’s backup, it is not there, trying an older backup etc.
After restoring it, there is no way to block the kid from doing it again.
Same with messing with helpers, dashboard logic etc
@anakinsbrn One more thing, I thought I’d suggest an MVP that would cover the use case of allowing untrusted kids or guest accounts, basically operating or using the smart home itself, without being able to mess anything. It might be useful focus the discussion. Entity permissions
For each entity, the admin can give each user one of four permissions level:
NONE - cannot view or update
VIEW - can view current states. Need to define per category. For example, for lights maybe only on/off and dimmer. For AC, maybe state (off/cool/heat etc), temperature, and fan level. etc
USE- just use the basic actions - change the states they can see, that were defined (hard-coded) for VIEW permission level.
ADMIN- full permission on that entity, like viewing log entry and history, renaming entity_id or name, changing icon, labels, area, voice assist config, disabling it etc.
I don’t think HA core needs to let admins define groups of entities (“roles”) for MVP, as I am sure the community can quickly offer solution (for example. “grant USE on all existing and future lights to spouse and kid”).
Other permissions
Non-admin should be entirely blocked from accessing anything that is included in setting, develop tools. Not by UI and not by calling the backend API.
That includes creating/modifiying/deleting automations and dashboard, installing addons, installing anything through HACS or adding/deleting devices (+ a miliion things like deleting backups etc)
UI
The UI should be adapted to gray out or hide any link to a page that is “none of their business”, such as logbook/develop tools/setting, opening properties or history of an entity etc. Those are pages where they have no permission to see or modify anything, so there is no point showing them.
There would be great to have a UI to see and modify the permissions per users, basically a table of entities (with all the grouping / filters today), with additional column per user of the current permission (and ability to modify it).
OUT OF SCOPE
Cool things that are very useful but are not a blocker for this specific use case (kids/spouse/guests). I think it is most fine-grained permissions - having a specific permission for each action (on entities or admin), allowing great fine-tuning.
Why add it eventually?
Ability to tailor regular access - maybe the USE permission category for lights will not include letting regular user change lights color (great potential for creating a mess, not super common to manually adjust day-to-day). But I may want to give my kid access to it in their room.
Getting spouse and kids into basic programming the smart home - maybe giving them permission to create automations (owned by them, limited by their permissions - likely harder) or their own dashboards.
That is pretty cool but is not required to unblock the basic use case.
It would be tedious work to add as there would be hundreds of specific permissions, one per HA action.
I hope that helps move the discussion forward, maybe this is a good basis for discussing and scoping the access control work.
BTW - will be happy to hear from others if that is enough for them to unblock the guest / kid / spouse challenge
I would be happy if it was possible to at least create a dashboard and share it - to the user or via link (without login).
Dashboard without the possibility of editing and going deeper into the system - only see what is directly in dashboard and control only these devices.
In this case, even the sidebar will not be needed because there will only be access to this dashboard, without access to history, energy, settings, etc.
I agree by all users saying making 2025 The Year of Security.
I’m using Linux for more than 20 years as a non-IT-pro and Domotica setups for as long as >15 years (buying my first hardware controller a Mios Vera device…)
Anyway, to go on-topic again, I love to see things changed as HA also should have add the label ‘Security by design’ to their slogan " privacy, choice, and sustainability, IMHO. That, in my opinion, goes hand in hand.
But how to get there, that’s the million dollar question…
1 - Logging and anable blocking. See what’s happening and react.
2 - Security by design can, maybe, be resulting in a massive rewrite of the current system. But if you don’t start, implemantation will be increasingly harder by time.
3 - Learn from the best implemantations used by others. For example, Linux is open source, and it vision and lessons could be very valuable.
4 - Listen to, learn and use the power of the community. I think no comments is needed for HA…
I think, IMHO, implementing basics like read/write/execute (rwx) and group/users to the core should be fundamentally for future HA development and grow.
How this sould be made useable for users and UI? Let’s see what the community/developers will come up with.
2025 will be a very interesting year, that’s for sure!
ps Sorry for any mistakes in my english writing, it’s not my native language…
Being able to disable logbook and history for non-admin users would be a great start – this would make our non-editable dashboards slightly more secure:
Any real security system must default to denial. IMHO it’s a naive question to ask why I want to hide something.
But let’s assume I rent my flat for a couple of days. I really thinks it’s none of the renters business to browse the history. Except maybe for devices like ligths which the have access to. And even then access must be restricet to the time of their rent.
But that’s so complicated that it’s much easier to deny them access altogether.
It’s probably a leftover from the time when the only user that had direct access to the system via the UI was the administrator of the system. Home Assistant has evolved to the point where many users want to allow things that the original users never anticipated. That’s why they’ve brought in outside people to help them gain an understanding of what the users need.
I think some of people (like me) didn’t answer because all of their concern was already written (kids, home employee…).
I know I’m not representative but 6 of 7 people I know who are using HA are waiting for this feature, and for most of them if a competitor to HA introduces a RBAC system, that alone would be enough to make them switch to a different home automation platform.
Could this RBAC system lead to dashboard configuration saved on HA and not anymore in the browser session ? small win for me
Well, as far as I know, they do plan to address the User Acceptance Factor (I don’t think the official chosen label makes sense since a person’s home isn’t self-aware) by working on improving security, so perhaps this will happen this coming year.
I really want to simplify the UI for my spouse and kids. Too many UI options are overwhelming. I can ignore them, but I need to present something simpler for them.
Can we extend what we did for assistants? For Assist/Alexa/Google, there’s a way to expose entities to those devices. That’s basically what I want but at a user level.
