Security Roles- Kids Account

I don’t have kids yet, but I can see how this would be useful later down the road…

If we could have user roles where certain features of the companion app were unavailable to be changed from certain accounts.

The use case I’m picturing, is when I have kids later and they are old enough to have a phone, I’d have the HA App on there, but I don’t want them controlling what sensors they can turn on/off. If you could have a “kids” role assigned to a user where you can lock out certain features of the companion app when that account is logged in that would be beneficial. To unlock/gain access to those locked out features, an administrator has to be logged in. It could prompt for admin credentials to gain access, or could be as simple as locking out that section of the app with a pin code.

I’m thinking this would allow me to be able to send controls to the phone as the parent to turn features on/off, have some device control without them being able to change the settings in the companion app.

Nope. 10 charrrr

1 Like

I just made separate dashboards for my kids and set them up as their default dashboards.
Every once and a while there’s a glitch and they get the default dashboard but I’ve set each tab on the board to only be visible to select users.
Screenshot 2023-11-01 at 1.06.49 PM

Do you just have them set to a wall panel or kiosk mode to prevent access to the settings within their companion app?

How is this a duplicate? Your post seems to be about specifically physical access control, I’m talking about security roles within HA based on user for access to system settings, companion app settings, etc.

They are set to non administrators. It says this on the setting:
“The user group feature is a work in progress. The user will be unable to administer the instance via the UI. We’re still auditing all management API endpoints to ensure that they correctly limit access to administrators.”
For the most part if they don’t know what it is they don’t touch it.
I hope they can’t change anything on the backend from their accounts.
They just use it to control their colored lights in their rooms so far.

Nope. 10 charrrr


Dredging this up…

I agree with the OP on this.
I just setup my 8yr old’s ipad for home assistant to tame/tone down the “Daddy can you make my lights blue, 2min later… green, 30sec later red…” and so on. Technology is great sometimes and other times requires a beer for reasons like this.

So I did the user visibility for the “Kids Room” tab on my main dashboard, which works great! However we now have the Assist option and I tested this out. Oh boy, this is gonna be fun! Even with my Office Desk Light not being visible on her iPad, she is able to type in the response to Assist for “Turn off Desk Light” and now I am typing this in the dark again!

The companion app options let me “hide” other dashboards like energy, keymaster, and other critical things. But once she figures out what security by obscurity means she will know how to unhide these.

So, I am +1 on having a better RBAC system in place.
Kids are the future, so there will soon be no way to keep them from only getting in the cookie jar! They will someday run circles around us.

1 Like

Make sure you up vote the original RBAC post:

That’s a feature request about door locks, FYI.

I was told that it was the general RBAC request, they just had door locks as their use case.

“Access Control” in that thread’s title is entirely around access to a physical site and asking for a core integration around managing doors/gates/locks/etc to replace some of the custom/HACS options. It’s definitely not a request for a RBAC system for HA generally.

A door lock manager isn’t about controlling who can do what when they’re interacting with home assistant, it’s about who can do what when they’re interacting with a physical ingress point. True, they may be doing that via a HA app or UI, but more likely, they’re doing it with NFC, bluetooth, biometrics (fingerprint), or a pin keypad.

RBAC would cover how to handle unauthenticated users, but that doesn’t fit the physical access model, either. It wouldn’t make sense to have to create a new HA user just to grant a contractor the ability to use a temporary door pin, and you wouldn’t want to generically grant the ‘unauthenticated user’ any access to HA itself.

I wholehearted agree on a general RBAC model where we can set who can do what and possible when.

Currently I am only interested in “who has access to which doors”, but I also have Zigbee enabled thermostats, where it might be relevant who can change the temperature settings on the radiators.