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).
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.
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.
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.
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.
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.
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.
I don’t know enough about IT security to what is considered a security hole and what isn’t. To me, the fact my 13 year old son has an account on my HA instance that can delete all of my automations is a risk to the security of my home automation system. If there is a more accurate technical term for this risk I am glad to be educated.
BTW, you were the one that brought up security holes in the first place stating more or less that a half-arsed implementation of RBAC would lead to security holes, and when I argued that the current implementation of RBAC already has security holes, you brought up an audit that says there are no authentication bypasses, which in my mind is unrelated. Can you give me an example how an incomplete implementation of RBAC would create a security hole that is worse than what we have now? (No sarcasm intended, I’m not trying to win an argument here, trying to determine whether this is a matter of taste/preference or I am lacking knowledge)
That’s a matter of expectation management, isn’t it? I would prefer that they roll it out like they are doing with the voice. Start with small steps and let people know more is coming. They could have also waited with releasing that until it had everything people expected from voice control if they were switching from Google or Alexa. But by making clear that this was a lengthy process, and features would be implemented one at a time, I think they did pretty well with the expectation management.
My point is that there is RBAC now. There is just only one role and it has access to everything.
Why couldn’t you improve RBAC from what it is now and release it with the explicit message that it isn’t watertight, but it’s better than nothing?
Right now my only mitigation is either to use the setting that hides all the settings from my kids, which is neither secure nor practical, or not giving them an account at all, which is secure but not practical.
Also, in my mind this issue is fully separate from authentication, I think ‘authorization’ is the more correct term?
Imagine creating a guest account for your B&B that has Home Assistant, assuming that your guests had no access to your secrets file, yet because of the poor implementation this assumption was unfounded.
Where as at the moment you know they would have access to it thus it is not a ‘hole’ but a missing feature and you should not give untrusted users access.
Let’s take an example of a fairly well implemented security system. Windows Hello
Windows hello is pretty good. But can be completely bypassed with a bad implementation of say a certain fingerprint scanner. (yes this is a real thing - and is being dealt with in the biz.) so the it admin implements Hello with biometric auth because they think they’re covered but hey hammered by someone who notices the bad fingerprint scanner choice in the laptop fleet of company x.
Whats worse - thinking you’re good and getting hammered or pre Hello implementation when they didn’t trust the fingerprint reader? (and didn’t turn it on)
Right now you know you need to go into the UI for dashboards and panels and throw visibility switches that you don’t want the non admin to access. But what if you thought the system had it handled for you?
I guess it is a matter of taste, then. I think there are already people who give out guest accounts without fully realizing the risk that implies, and I also think that a system that makes it harder for some users - even if not completely impossible - to access certain features, with the proper communication about the limitations, would be better than the current system.
Anyone who’s seen a James Bond movie knows it’s possible to fake a fingerprint (though I’ve been told it’s not as easy as it is in the movies).
Of course the more secure option would be not to use any authentication method for regular users, but to only have computers operated by specially selected employees, who have root access to everything. Anyone else that needs to send an email stands in line at their desk and dictates the content to the computer operators
I feel this is where we are with HA now. And it may look secure from a certain standpoint but I don’t think it is. Because if you make it extremely impractical for people to do things in a secure way, they will just go around it and do it in a very insecure way.
I think good communication about the limitations is key here.
(BTW, is there a way to throw visibility switches for individual users on anything else than complete dashboards? I didn’t even know)
(No it’s not that easy to fool a fingerprint reader. That said go passkeys. Waaaaay better)
I any dashboard hit edit
Now you see the icons for the views across the top… Hit the edit pencil next to the one you want to work with. Here I picked my ‘rooms’ dashboard and I’m going to edit the it closet view. (there’s no reason for a guest to see that in my panel)
For specific cards I create two separate views for different user types of its that complicated s Or use custom cards that have the ability to show/hide cards based on user context.
Edit: in fact ‘conditional card’ just got an update to support user as a condition…
Very much a pain and I would rather not. But it’s what I have to do to trust leaving an open panel in my hall with friends who like to test my stuff.
My kids can effortlessly locate smart plugs controlling the boiler through the logbook. This poses a risk of inadvertently disrupting our home’s systems, including disrupting our internet connection. I’d prefer selectively exposing Home Assistant devices through Apple HomeKit to a shared iOS device.
