I understand the concept of RBAC and find it interesting that there isn’t one in HA.
In my home setup I don’t really have an “alarm” in the classic sense. We don’t have an alarm panel that we turn on/off. Instead I have set up different automations that are always on.
This weekend I was out for half a day, and my gfs dad was working on the planter that happens to be in the small porch area where the main entrance is. Every minute and a half all of the Alexas in the house would say “there is someone at the front door” and it drove anyone (except me since I wasn’t home) nuts! They ended up having to turn down the volume in all the Alexas.
When I got home and was told about the issue, I told my gf she should have just turned off the automation, and that is when I realized since she is a regular user she has no access to the automations so she can’t even enable or disable them.
Figured I could easily add automation access to all users, but that is not the case. I either make them all admins with full access or they stay as users.
I plan to find a work around tomorrow, plan b. I know I can create buttons to run scripts, so looks like at worst I would have to set up two scripts for each automation I want them to be able to turn on/off. One script would be to turn off the automation, and the other would be to turn it back on. Being able to create a switch directly to turn automation on/off would be even better, but not sure if that is possible.
That said, for my home setup, doing this work around isn’t really a big deal, but I could see how it would be MUCH better if users could be created with RBAC.
Since you are open to workarounds, make an input boolean that you check for being on in your automations or scripts. You can put that entity on a dashboard. Much simpler.
Thanks for your feedback. I actually got sidetracked today so couldn’t play with it much, but it seems I can set up a “button” card to turn on/off automations similar to how I am able to do with scripts. So will probably end up creating a new tab where I can have a list of automations my family might want to turn on/off on demand.
This nice thing about input booleans vs buttons is that you can easily see if they’re on or off. I have an automation that resets a bunch of “disable” booleans for the notifications each day at midnight.
you can have a button which calls an automation or service, can’t you?
BTW I’ve read about 100+ unread post and it’s sad how some users defend missing rbac or even disregard some other’s users legit use-cases just for sake of justifying this shortcoming.
So, I have tried to collect some thoughts and thinking into what a really good access control integration for Home Assistant might look like… Everyone’s house has a door right? So this is something that would be used by many and I think would offer a great improvement to the Home Assistant Core if there was a unified system architecture for access control built into the HA Core…
I think rather than homebrew solutions, it would be good to try and have an access control solution in Core that was based around interacting with off-the-shelf devices. It could be expandable and provide an architecture that home-brew solutions could feed in to, but I think there are a good few off-the-shelf locks that offer a lot of performance for modest investment, and trying to develop a unified solution to Access Control, rather than just manufacturer specific integrations would be a worthy goal.
A good example of a HACS extension to serve as a starting point is Keymaster. and evolution of Lock Manager. In the lockmanager documentation, it mentioned the inspiration of rBoyApps Smart Things Lock User Manager, and there is a good table that compares the features of a range of Z-Wave locks on the market:
I think that this provides a smashing framework for integrating access control into Home Assistant, and it would be good to see this adapted and developed into a permanent part of the Core and maybe augmented with some more UI thinking…
Some really good work towards this has been done by @mang0 but using button cards to bring up a dialogue box, see here… KeyMaster Z-Wave lock manager and scheduler - #1775 by mang0 I just wonder whether this could be made into a more compact grid such as the above that would work with large numbers of users / doors.
Within Keymaster, there are already a range of conditions that can be used to set when a lock can be accessed, Usage · FutureTense/keymaster Wiki · GitHub, but I think that this could be made part of a really slick UI/UX given work.
Support For Different Types of Tokens
So my understanding is that Keymaster supports PIN entry, but some locks come with different types of token, RFID e.t.c. You could even imagine a building scenario with different types of lock according to different types of application, and needing to assign multiple different types of token to the same user depending on the lock type - so being able to manage different types of access token and assign to different types of lock could be useful.
An Event Log With The Ability To Filter
So having a log of different access events, who has tried to enter and exit the building when and where at what time e.t.c. and the ability to go into the log and filter it and interrogate it in an easy way.
Some interesting info on how Paxton’s interface works here: https://www.paxton-access.com/wp-content/uploads/2019/03/AN1058-US.pdf
Access Control for Elevators
Looking at other use-cases that are in the market, Loxone for example also give an example of how their Access Control Module might be used in Elevators. It isn’t my use case, but good to see how well-rounded acess control integrations figure in other Home Automation systems:
Generate Roll Call
So this idea comes from the software of a commercial firm, Paxton, and could be more value added for making a smart system truly smart - generating a roll call… so a list of when users last entered the building (exits I guess wouldn’t be tracked though)… but could be useful to generate in the event of a fire status e.t.c. In turn, the red exclamation icons can be clicked to turn them into green ticks to mark users as safe.
These are just some ideas, I hope that this turns into a rolling thread where people can discuss and refine what an integrated approach to access control in the HA Core might look like. I hope it is a good conversation starter.
An interesting thread. I am trying to set up a simple one-door access system, but even for that I have stumbled at finding a commercially available solution. There are plenty of boxes that will read PIN and NFC or RFID and output the details over a Wiegand (wired serial) interface, but it needs something like an Arduino to decode that and send it via WiFi, Zigbee, ZWave or Bluetooth to HA. Have you seen such a unit available commercially?
I had implemented that kind of mechnism using HA, NodeRED and NVR,
Once the NVR notifies someone is identified (specific threshold) - NR is getting the event, checks if the face is registered as a user with permission in HA (custom attribute),
Based on the camera position, it opens the door.
Averge processing of face is less than 80ms, so it’s working pretty fast.
on top of that, I have set a dashboard of Grafana to monitor processing time and number of identification vs. failures per camera.
My solution uses the last of these combined with a custom ESP32 relay board programmed with ESPHome. I found some Wiegand code on GitHub that I included but have not yet tested.
Since my FR was closed as Duplicate, I just wanted to add my thoughts and concept here, too… It might be already there in one of the comments - at least, in a similar way… but anyway…
ok, I am still not sure how I should describe this Request… it is a bit difficult to explain - and this request will be more of a description how I could imagine the user profiles should work in the future, rather than a specific request of a single functionallity… so I will just try it to explain…
With the recent change on how the login ‘should’ work and the resulting complains about a possible security breach, the requirement of a real and well designed user-management system should be considered.
In my opinion, HA should come with a default Administration account that will be created during installation.
Within this Admin profile, you should have to create new User Profiles to work with.
Installing integrations:
when you install an integration, you can do this from the Admin Account *
You should be able to decide, if an integration should be available for all user accounts, or only for specific users.
especially, if the integration is cloud based and works with specific user logins.
this would allow to have integrations that can run within the user-context of a specific profile and only this particular user could use the integration.
There should be a setting, what a user is allowed to do:
for example: is the user allowed to change settings on a thermostat or is the user only allowed to see the current thermostat settings.
this should be possible on integration level, device level and MAYBE even on entity level
if a User is allowed to install integrations, they should only be available within the user context of the user that has installed the integration.
This can be changed within the admin account
This would allow to have profiles for other family members, but you would prevent that someone can modify your task list, your calendar, or that your child could change settings of a specific device.
Decide, which user profiles should be visible in the login page (the now reverted, new login screen) - and if this user should be exposed on remote computers or onyl within the local network (only the local network, not just “private subnet”)…
→ The Admin Account should NEVER be exposed in this way.
On a User-Level:
Use Auto-Logout after x-Minutes
This would allow users with a Wall-Tablet to login into their account… after x minutes, the system should log out the current user and then show the login page again.
The LogBook should show, what device / state changed by which user:
→ User A has switched on the Light xyz / → System has switched on the Light ABC
→ User B has changed the Thermostat gde to 123… and so on. (seems to be already available)
I know, that such changes are a big refactoring of the current user-profile system - and would also be a big “breaking change” for existing installations.
But in my opinion, the User-Privileges and User Profile system is something, that is not “state of the art” for a couple of years now - and should get more focus with a growing user base - and becomes more and more important compared to design changes (which I still like [at least most of them] )
RBAC is so critical. In my opinion HA is near perfect, it simply lacks access control. In a perfect world this wouldn’t be necessary, but it would be nice to not have to grant guests and kids full access to everything, instead of being able to limit them via RBAC simply to the devices/rooms/UI required.
IMO, we should split the RBAC rules on an entity level, because permissions may not suffice on a device level. For example multi-channel relays, where each channel may control one room. (…and I’m confident that children figure out how to control the light of their siblings if they had write access to the whole device. )
Just a bit of an update: I merged a Month of "What the heck?!" with a Feature Requests. Partly a mistake on my part because I didn’t realize a FR already existed. Sorry about that.
Once again, RBAC is discussed in the “month of WTH” - to everybody wanting this feature for a long time, let’s also vote for it here: WTH no access control - #20 by InventoCasa
Yes! This is my number 1 missing feature! I would love to only expose certain entities to my kids. They don’t need to be able to open gates and garage doors or even unlock doors.
My oldest has figured out that by using CarPlay he can see everything whereas before I only allowed him to see a specific dashboard.
Control on entities sounds great. I am also looking for more control to UI actions, i.e., allow users to enable disable automations, but perhaps not view them.
HA has the opportunity to capture both the home consumer and ‘enterprise’ home automation markets. As an ‘installer’, hoping to give users a different level of control.
I just wanted to chime in – I live with a few friends, and the reason they tell me they avoid using our home automation controls is that it’s too easy to change something they don’t intend to or feel they shouldn’t have access to, like a light in someone else’s bedroom. Conversely they end up keeping devices in those rooms unconnected to automation so that no one else can toggle them.
As a systems administrator and cloud engineer, running multiple HA instances for each member of the household is anathema. RBAC controls around who can access what would solve this reluctance problem completely.
Ideally, there would be an interface that allows the administrator to add/remove entities (preferably with view+change or just view option) to a role. We already have something similar in the Voice assistant “expose to assistant” dialogs.
“Change” in this context also implies calling a compatible action, with that entity as a target, where the entity state will change, and “view” implies calling a compatible action that doesn’t change the state of the entity.
Then roles can be assigned to specific users.
Functionally, any entity not viewable by the user would be filtered out of the websocket/API for that user. Actions invoked on entities not in the users’s role set of entities would error out with either a permission denied error or act as if the entities don’t exist. This filtering automatically implies that logbook/history don’t show unviewable entities, and dashboard-initiated actions don’t change entity state for unchangeable entities.
Eventually the same mechanism can be extended to individual dashboards.
Open questions:
Can globs / regexes be used to add entities for read/write to a role?
How are groups handled? (Does action implicitly apply to all entities of group if group entity is whitelisted for write?)
How to keep codebase impact minimal?
How to minimize risks that future code changes accidentally let unauthorized accesses slip into the codebase?
)