Nabu Kasa keeps ignoring the elephant in the room of security and permissions. They have no native ability to set user groups and permissions. There is no serious RBAC. I guess it doesn't sell cloud subscriptions. I cant keep my children from affecting devices they shouldn't. I ended up replacing my automation with mqtt
I think they're reading their audience and making the correct product choice.
Home Assistant users are the power users of the home automation world, but even among their user base I think the number of users who would use a full set of groups and permissions controls in their home is very small.
This is a feature that would take a lot of engineering effort and only make the product more complicated for most of their users. The part of their user base that did use it would probably never be happy because they wanted something even more specific.
Their basic permissions and control structure covers most of the common use cases. Going further would be 100X more work for something that would only be used by a very small minority of users.
I think a lot of people have a wrong perception of how "complicated" authorization systems need to be, most likely because they've been confrontend with badly built ones their whole career.
These days if you build it with a central policy engine, e.g. on top of Open Policy Agent with Rego as a policy language, and stick to a (actor, object, action) triple system, you can build an extensible and powerful authorization system that usually also is less polluting to the codebase as many other approaches. For HA specifically, where you have a quite low numbers of actors and objects, most of the headaches that could come with such a system in terms of scaling also fall away.
> These days if you build it with a central policy engine, e.g. on top of Open Policy Agent with Rego as a policy language, and stick to a (actor, object, action) triple system, you can build an extensible and powerful authorization system that usually also is less polluting to the codebase as many other approaches.
...and if they forget that, they can just edit the source code in command.com!
Are you saying the other comment is describing something impractical for average users? But they're talking about a way to build good authorization, not how users would interact with it. The implication is that the approach would be easier for users.
Don't take this personally, but - I don't believe you. I've never seen complex abstractions that didn't leak. Maybe the feature is worth the complexity, I don't know, but I can't fault the authors for thinking not.
Authentication, authorization, and security in general are complex problems that are demonstrably difficult to get right. Any solution is going to have implementation complexity. The comment you responded to was actually describing a way to manage that complexity.
voidnullvalue · · focus · HN ↗
Aurornis · · focus · HN ↗
Home Assistant users are the power users of the home automation world, but even among their user base I think the number of users who would use a full set of groups and permissions controls in their home is very small.
This is a feature that would take a lot of engineering effort and only make the product more complicated for most of their users. The part of their user base that did use it would probably never be happy because they wanted something even more specific.
Their basic permissions and control structure covers most of the common use cases. Going further would be 100X more work for something that would only be used by a very small minority of users.
hobofan · · focus · HN ↗
These days if you build it with a central policy engine, e.g. on top of Open Policy Agent with Rego as a policy language, and stick to a (actor, object, action) triple system, you can build an extensible and powerful authorization system that usually also is less polluting to the codebase as many other approaches. For HA specifically, where you have a quite low numbers of actors and objects, most of the headaches that could come with such a system in terms of scaling also fall away.
stickfigure · · focus · HN ↗
...and if they forget that, they can just edit the source code in command.com!
antonvs · · focus · HN ↗
stickfigure · · focus · HN ↗
antonvs · · focus · HN ↗
> Maybe the feature is worth the complexity
What feature? Security?