just dicovering smart home stuf, and of course trying Home Assistant and starting playing with it.
One of the first things that came to me is looking for sharing the gate remote with my friends using anesp32, but WTH ???.. I shall share everything if I share just one ?
Really looking forward to get such a feature. Thank you !
1 Like
It’s almost September, 3rd WTH.
I’ll take the honour to create the WTH3 topic then 
This probably should be raised as a feature request and have the next WTH point at it 
1 Like
You mean next year
2 Likes
Now you mention it 
+1 for this one.
I really need this, to be able to control / restrict users to only use certain devices and even limited functionality for those devices such no administration/configuration access, but only general usage access.
What is ETC for this feature?
Whenever somebody takes the time to work with the core dev team to architect, develop, and then submit the code required.
So, roughly between next year and never.
+1 for this. HA won’t be wife friendly for me without this.
It really surprises me that a dev team that is mainly driven by a company, has not given this more priority. It must be a show stopper for so many potential users, from parents of experimenting kids to people who rent out guest homes, let alone commercial business owners.
But who knows, maybe next year will be ‘year of the user rights’. I know I don’t have the skills to contribute or the time to develop them but if I could choose, this would be my #1 feature request.
Please let ‘year of the voice’ first be succesfully finished. The year is almost up…
I’d like to add my +1 or RBAC. At a minimum, I’d like to be able to:
- Restrict the default dashboard to Admin Only – There’s no reason any non-admin user needs to see the dashboard that contains EVERYTHING automatically.
- Ideally be able to define user access as the union of permissions granted to groups of which the user is a member.
- Ideally define the permissions of a group to be the intersection (not union) of dashboards and entities which have been configured as accessible to the particular user. I’m fine if this is default open and I need to turn off permissions for each device/dashboard to which the group shouldn’t have access, but would prefer it to work as opt-in (default closed, group can’t see anything until they are granted access).
I would see this as an additional page (or 2) on the group settings/profile where there would be two columns of check boxes with each row representing a dashboard or an entity. The first column would be view access, the second column would be set access. Optionally, a third column for configure access.
The ability to add and/or delete entities could be an additional configurable permission (which obviously can’t really be entity specific), although I think it’s fine to leave that as a function of being an admin user.
I’m open to any solution that grants equivalent functionality, not wedded to the particular UI described, but do want to be able to (relatively easily) limit what things a user can see and what they can touch.
For example, the teenager should be able to see the thermostat and temperature, but not adjust them. She should be able to turn lights on and off, but not modify their defaults. She should be able to open and close the garage door. She should not be able to add users to the system or change permissions. She should not be able to see or control the linked GitHub entities, etc.
OTOH, other adult in the household should be able to see most things (not the GitHub stuff – not for security in this case, but for lack of interest) and should be able to adjust most things as well.
Select guests would have other customized permissions and generic guests would have much more limited permissions.
I realize that there’s probably major development effort required to achieve this, but I think as others have said that it is hard to take HA seriously as anything other than a tinkerer’s system without it. I’m certainly not going to give the teenager access to it without this, which is seriously inconvenient for me as it would solve a number of problems (right now, I’m having to manage her access to multiple different apps to control things. Being able to integrate that into HA would be very desirable).
As such, I hope this is a useful recommendation and that it will receive some priority, especially given the high vote count on this topic.
1 Like
Why would it surprise you? It’s just that they want to make a proprietary cloud version of Home Assistant with such features.
First thy lure in people with free software and once it actually becomes useful, they make an “enhanced” version. Creating a completely redundant (and less secure, because of more maintenance) operating system can also be seen as such a strategy at play. It would be best for the “community” (=set of users) to just see it for what it is: an attempt at divide and conquer, literally as old as the Romans.
You said it yourself: these features are so important that people even resort to hosting multiple instances of Home Assistant and yet it doesn’t happen.
The “reasons” mentioned for no SAML support is because the dad of one of the most prolific developers and potentially the “lead” doesn’t need it.
I don’t particularly care whether or not the development team adds the feature, but I do care about them saying “Yes, we want this” (with a $100,000 fine if they change their mind because their mom suddenly forbids it). I wouldn’t mind running a fork of the project, if that’s what’s needed. A fork with SAML, RBAC and a Google Backup working against Core (instead of only on hass) would probably take over HA in popularity in a year or so (assuming it’s a drop in replacement and it’s packaged in major distributions).
You need to adjust your tinfiol hat.
This is nothing short of conspiracy theory of the worst kind. There is zero evidence for this. In fact all mission statements by the project team say the complete opposite.
The actual reason is that RBAC is hard to do correctly. And they want to get it right and not release some half-arsed system full of security holes. So some patience will be required.
10 Likes
Indeed. I agree fully with this statement. Level of patience will vary from person to person though and people need some encouragement.
I think if the HA team is working on this then they need to say…ok, yeah we hear you…you want RBAC…we’re trying to figure it out, but we want to do it right so bear with us.
It seems like they are ignoring the fact that people really want this. I don’t know that they are, I am just speaking for what I’ve seen. If there was an announcement like this I missed it.
Here’s hoping that they are working on it and it comes sooner rather than later.
3 Likes
I don’t know if this is actually being worked on now. I do know the team is definitely aware of the demand for it. It has been mentioned a few times in release party videos that it is something they want to get right.
2 Likes
Fully agree with this. I, and probably a lot of other people, understand that this is not a Friday afternoon project. But a bit more communication about the decision process would be much appreciated. It does feel to many like they are just ignoring it (I don’t watch release party videos, but I do read the blogs)
I don’t understand this reasoning. They are releasing a system full of security holes multiple times a month! It’s maybe 1/32th arsed now, I’d be very happy with a half-arsed system to bridge the time until the really good version comes out.
My system is fully local, I don’t need to be protected against hacker collectives trying to switch my lights off. I just want my son to be able to create new light scenes for his room and edit his own dashboards without also letting him delete my heating automations by accident.
1 Like
Do not confuse missing features with security holes.
Latest security audit:
4 Likes
Because right now the dev core team and even Nabu Casa do not even pretend that the system is designed for roles that separate various portions of the system. So we as end users know it’s something to be aware of.
If they instead threw together a crappy RBA implementation that had more holes than Swiss cheese it would be a far worse issue. Thinking you’re covered when you aren’t. It’s way easier to mitigate something you know you need to mitigate.
Edit. Also I’m firmly I the camp that a GOOD RBAC implementation that supports industry standard open authentication and fidonis DESPERATELY needed but ive seen a LOT of bad ‘security’ implementations that end badly.
2 Likes
I’m not talking about authentication bypasses. That has (to me at least) nothing to do with this. For me, this is about what a user can and cannot do in the system once they have successfully authenticated.
I find the fact that my 13 year old son has an account on my HA instance that can completely delete all my automations, comprises a security risk. I haven’t read the auditing report but I don’t quite understand why they think this is just fine.
1 Like
Again,
6 Likes