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:
- Some ability to restrict which URLs or control-points a given user can access
- Some ability to define groups of users and set control-point limits on the group
- Opt-in permissions are probable better than Opt-out (e.g. a user/group gets a list of things they are allowed to do (and can’t do anything not on the list) rather than a list of things they are not allowed to do (and can do anything not on the list)).
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.
