Yes, but in his case, I think he’s actually complaining about the need to configure each device and that the configuration doesn’t stay with the user account across devices.
This is a problem unique to HASS and has to do with construction of the application and not anything related to security.
A lot of homes have kids that also can’t necessarily be trusted. Mischief is a natural part of childhood and if I can’t protect my HASS installation from them, I simply can’t give them access to it at all, which kind of defeats the point.
Turns out that meeting the needs of people with kids in terms of RBAC would also meet the needs of AirBNB users for the most part, so really, it’s time to consider doing RBAC in HASS regardless. Lots of people have expressed lots of reasons this is needed, most are valid even if you exclude business/AirBNB purposes.
Further, it’s kind of ridiculous that a system this complex ever got built without any attention to this need.
So I’m going to summarize the comments to date…
LOTS of people want RBAC in HA for a variety of reasons.
LOTS of people want dashboards and/or views that can be configured to follow the user account and not have to be configured per device. Currently this can be done with views to some extent, but is completely lacking in dashboards.
RBAC is hard to do right and there’s little agreement about what would be “right” and it will be difficult to achieve such agreement without even having one or more straw-man proposals to choose from.
Minimum requirements expressed by most of the users in this thread so far seem to include:
I’m not (yet) well versed in the HA architecture and construction, but it appears from what I have learned so far that this would require each HTTP end-point to implement the RBAC separately. Since there is a large number of authors, especially for plugins, adding, and the like, getting universal implementation in these external projects is likely hard and will likely take a long time.
Presumably before any user can (usefully) access any HTTP end-point, they have to be authenticated. As such, it should be relatively simple to implement an API for RBAC authorization that could be imported and called by any end-point implementation. Endpoint usage could be as simple as something like:
from RBAC import RBAC_auth
allowed = RBAC.auth(<username>,<module_id>,<object_id>,<operation_id>)
<username> would be the currently authenticated user.
<module_id> would be a unique identifier for the end point (plugin, add-on, core-module, etc.)
<object_id> would be a unique identifier of the object the operation is to be performed on
<operation_id> would be a unique identifier for the operation being attempted by the user (e.g. turning on a light, etc.)
the return value (allowed) would be a boolean True for operation is permitted and False for operation is not permitted.
Obviously, the API for managing user permissions, groups, group permissions, etc. would be more complex, but that has the advantage of existing entirely within core HASS so as long as we can define the above single API call well enough that it covers all cases (and/or is sufficiently extensible without breaking prior implementations), I think this would be what is necessary to allow external developers to start implementing RBAC capabilities in their projects.
An initial stub that just returns True for everything could be deployed to provide equivalent/compatible current behavior until the full API reaches a release-worthy state.
So far, this thread has been mostly complaining about what isn’t available without having any concrete suggestions for a way forward. I’m hoping that my above suggestions if not wholly implementable can at least start a discussion moving in that direction so that we can talk about how to do this and getting it done. I think we have clearly identified the use cases for it and the need for it.
In addition to your suggestion, I’ll re-up my previous suggestion to re-use the RBAC that is already implemented for voice assistants for users.
Please implement this on an entity level. It is more relevant for privacy than security.
Authorization is hard to do right. There are use cases for privacy scenarios, and for security.
In my previouus life, when I’ve gone into an existing code base as part of a team and re-architected systems for more fine grained control, you have to start at the top, which might seem too coarse. The most straightforward design pattern in REST is thinking about the URL namespace and mapping parts of the URL path to specific permissions (sometimes called scopes). Then you can start chopping into more and more fine grained pieces over time.
So, for example, you could assign a permission to any dashboard or add-on (things after the instance root in the URL like /lovelace/default_view or /energy. Scopes as simple as lovelace:read or energy:read.
We did open source an authorization server, see the-usher-server/docs/GLOSSARY.md at 2f33a30e97d0361bd180a4acae2fd35b5a11db07 · DMGT-TECH/the-usher-server · GitHub - it has a good discussion on the complexity and an approach that is possible. This approach assumes authorization results in auth tokens, and these tokens can be quickly turned into permissions so the main dispatch loop can use it.
Really fine grained permissions are a lot more complex. But I don’t think that is what 90% of the use cases require.
My 2 cents. 
Speaking as a user - not a developer; I think a majority of people would be satisfied at first, with simply being able to hide pages like energy and map dashboard from certain users. I trust the people I want to give access, I just not want them to have (for example) the map right there, because then curiosity will take over. A solution as simple as that would be greatly appreciated, probably by many people, while a more comprehensive API/URL RBAC is being discussed and developed.
What do you think?
I think you’re right. Although you can do it case by case in the app or in the users settings I think it should be doable from and admin point of view.
The thing is, it used to be there, although it was “custom” at that time…
Yes, even if, for example the option to hide sidebar elements is not a per browser setting but a setting for the user from whereever they go into their dashboard, this would be very helpful. Then maybe have the option to also not allow this user to make changes to their settings and it would be good enough for family members…
+1
Despite my ignorance, I think it would be possible to just add Map, Logbook, History and so on to the Settings/Dashboard section to edit what is Admin only and what is not.
If we wanna push it further, you could also implement the possibility to enable/disable the possibility to visualize each board for any user.
You could start from something simple, like hiding it from the sidebar. I know this won’t prevent to see them from the browser but at least we can control a bit what users can see from the app and even quickly change the permissions (ie I wanna enable the Map view for a user for a couple of hours and then disable it again).
I think that this would be already hugely appreciated from the community…
That’s available in 2024.4 for Map, which will be released tomorrow.
Also, I believe the groundwork was added to potentially expand that functionality to other “default” dashboards like history and logbook.
Great. Thanks for the heads up!
It looks like the History dashboard was included in the official 2024.4.0 release.
It was not. If you go to Settings → Dashboards, then click + Add Dashboard, you’ll see it’s not in the list.
True enough, but you can set it as Administrator only, which I’m not sure you could before.
I just tried the new version. Apparently History, Media, Logbook and if you have it also Calendar and To-Do List still don’t appear as dashboards, hence you can’t make them for Administrator only.
Especially Media is a bit concerning given that from there you can access to cameras…
But I’m sure they will do something about it.
Did ya miss my explanation? I already stated that The change is only available for map and iframe/webpage.
EDIT: Sorry, my original post was not clear on that. But now you know from this post.
Calendar and To-do list are integrations, so if you want private ones, make a feature request for that and I’ll support it. History isn’t on the list of dashboards you can add, but it does appear in my list of existing dashboards and can be made admin only.
Thank you for the clarification
Ok, I understood the part about Calendar and To-do list. I will look for existing feature requests regarding that otherwise I will create it.
For what concern History, sorry for the stupid question, but how can be made it admin only? It doesn’t appear in my dashboards list.
More details:
I tried to look around and I also have another instance in a remote house (parent’s house) but I couldn’t find a way to make it admin only. Both the instances have been updated to core 2024.4, one is HAOS on a rpi4, the other a core container.
