All of the default / built-in dashboards should be able to be restricted to admin only. I understand that at least one dashboard is needed for a user of the system and as such the default Overview is fine. But allow us to make all of the other dashboards admin only.
I hesitate to give standard user accounts to anyone because of them getting access to dashboards that they shouldn’t have access to!
Dashboards that should be restrictable but are not:
Map (further inspection shows that this is now controllable but last WTH it wasn’t!)
Energy
Logbook
History
Calendar
HACS (if installed)
To-do lists (if installed)
The Media dashboard has at least one item on it that could be considered an admin, or privileged only section and that is the Camera section.
Basically, if a dashboard isn’t the Overview dashboard, then it should be something that can be configured to be admin only / manage being shown in the navigation pane. This includes dashboards added by integrations, they should be manageable for visibility from the dashboard settings page.
I would be happy too with a limited access control. I’m not dreaming about users, groups, inherited rights etc. Just to have 2 levels of access control - All users, Admin Only. Admin only is only viewable and interactable by admins. I could solve most of my problems with that. Better is to have 3 levels. Best: having full ACL on every entity, dashboards, helpers etc (view, change status, full access like delete rename etc.)
I’d say that for me this is absolutely the 1st thing that should be on the to-do list for the HA team.
Ha went very, very far in recent years. It’s gone from a geeky, hobby kind of a thing where you need to tinker around with it semy-constantly to keep it working, to a fairly stable and robust system that I can trust to run my home environment. It even gained approval and some admiration from my spouse, which is amazing in on its own.
But, like multiple people before had said, it sadly misses a few things to make it a tool that can be safely deployed to all family members (maybe even some that are not part of direct household).
Ability to restrict who can see what (hiding entities)
Ability to restrict who can change what
Ability to define which user gets which dashboarsd and sidepanel items (similar, but not the same as 1st option)
Without those it’s a real risk to give access to HA to almost anyone. Not even necessarily because you don’t trust them to do something intentionally. It’s also that they could mess stuff up unintentionally, while honestly being curious and exploring things out of interest.
I share the same perspective as many others: perhaps it would be a good idea to start by introducing a “light” version. For instance, this could involve restricting users’ access to search/assist functions and limiting their use of dashboards.
While it’s true that an experienced user can bypass these limitations by customizing requests, such an approach would still provide a solid foundation—especially for scenarios like setting up a tablet for a child or guest. For me, that would be a meaningful first step.
This is probably the single most important core feature that is still missing.
Be it for guest access, or for kids (I want them to have the HA app on their phones for their convenience and for certain automations, but don’t want them to wreak havok on my setup), HA really needs this.
I have kids with smartphones and want to be able to track their location in Home Assistant. So AFAIK the normal way to do this is to install the Home Assistant Companion App, but then I need to create HA user accounts for each of them to be able to log in the app.
And now they can access easily a ton of things they should not, as already described in other posts in this thread.
DISCLAIMER: Apologies in advance if something like this already exists, I have not search extensively!
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.
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.
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!
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.
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.
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.
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.
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!).
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.