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.
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.
...and if they forget that, they can just edit the source code in command.com!
> Maybe the feature is worth the complexity
What feature? Security?
It depends what the authorization requirements are. For consumer-grade security, you're right. But when you start getting into the requirements of large, security-sensitive organizations, there's a lot of unavoidable complexity.
But those contexts often influence the development of security systems, so some of the complexity you're referring to relate to requirements most users don't have.
Most complexity that usually plagues authorization systems comes from complex authentication requirements, and can thus be largely isolated there. That's also where many (often legacy systems) lay a bad foundation, because they from the get-go tangle authentication & authorization into thing.
In a model as described above, that just turns into a slightly different `actor`. With that you can also handle things like context-aware authorization without littering your codebase.
OPA can be a component of a secure authorization system - low-level policy definition and evaluation - but there are many aspects of an authorization subsystem that OPA doesn't even try to address.
For a start, policy languages like Rego operate at the policy decision level, they have no awareness of any authorization model. If you're implementing anything with high-level authorization semantics - think MLS, Bell-LaPadula, or pretty much anything else that defines a non-trivial authorization model - you essentially have to translate the semantic properties of that system into a low-level policy decisions.
If that translation is done manually, it's highly error prone, which is not a good feature for a security system. Rego doesn't know what a clearance, classification, security compartment, etc. means. It doesn't prevent a policy author from implementing rules that aren't compatible with an authorization model.
Also, for security to be worth anything, there are inevitable cross-cutting concerns with trusted identity and attribute sources. OPA lets you tell it anything you want, but you still have to integrate that with a larger system that doesn't depend on implicit guarantees. E.g., "This is Bob because the invoking service checked it and says so" might be fine for an e-commerce site, but not for many more secure environments. Same goes for attributes other than identity. Doing all of this in secure ways is the cause of much of the complexity I mentioned.
> I think a lot of people have a wrong perception of how "complicated" authorization systems need to be,
To this
> 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,
This is the complexity that makes it not worth the effort. That’s a lot to develop, test, document, maintain, create UX for, and continue educating people about for something so few people would ever use.
I’m not saying it can’t be done. I’m saying doing it would be more effort than the upside. It’s into the part of the curve where you’re spending 10X the developer time as other features to cater to 1 in 1000 users who aren’t going to be happy anyway because it’s not exactly what they imagined they wanted.
(If I have to physically move to a different room to send a voice command about that room I lose a ton of convenience, and the whole point of home automation is convenience!)
In the age of agents everywhere this is no longer true or viable.
It's going to be hard for them to do it, for historic and legacy code reasons. But it's long past being a choice and now becoming a need.
No matter how crazy smart AI gets it's not going to be able to hack my doors, lights or thermostat.
For instance, I left my garage freezer door open, in summer, once. The loss of food almost made me cry (just from the pure waste of it all). I have temp monitors now (external, with probes into fridges and freezers) as well as door sensors. If I am dumb and leave them open, or if they break I'm going to get a notification.
Windows/doors open, and it starts raining, alert... I have a whole set of alerts on when to open the windows too based on season and inside vs outside temp. I have seen a savings on my bills for heating and cooling.
Reminders of all kinds when it's not optimal to run the oven, or appliances because of power costs.
You're trying to use technology to handle difficulty with minor adversity.
As somebody with a pretty extensive Home Assistant based home automation system AND kids, I've never once felt the need for this. I can certainly see the utility of it, but Home Assistant is already complicated enough. I'd prefer effort be spent improving the UX, simplifying the system, improving reliability and adding more (optional) integrations.
Many, going back years.
This thread is relevant. Their permissions system is just on entities, and isn't a real EBAC system.
Yes, but only very coarsly granular things.
- Permissions only work with entities. There are about ten different kinds of objects besides entities, that would also benefit a lot from being part of a uniform permission system.
- Permissions can only be defined for groups, not users, which is quite annoying if you want granular permissions
- With permissions only acting on groups, it also isn't possible to base permissions on user attributes. So you ultimately always have to model a permission set as a group, and then essentially have to have a synchronization mechanism that ensures that the right people are in the right groups
- This also makes scoped integration access impossible. You can't grant a third party app access to e.g. only your energy sensor data.
I do think the maintainers are getting better about it. The releases over the past year have reworked a lot of things to be more intuitive for casual users while also being more flexible for power users, but there is still a lot of ground left to cover.
I think with the growing popularity, and expansion of fields of use, this is something they'll ultimately have to reckon with. I've seen quite a few posts on the the HA subreddit, where it's being used for controls in e.g. hotels or other bigger buildings, because it has a great feature set and prevents vendor lock-in. There is no harm in also catering to those people & organizations.
I don't see HA as a consumer established product, as much as Nabu Kasa would like otherwise.
Then again, this is just my guesswork. I have 0 clue the demographics of Home Assistant users
https://www.reddit.com/r/homeassistant/comments/1vxw5pu/acce...
Build that and I'll be interested.
Apparently they're saying this is the wrong way to run a cloud.
Some of us in the family are logged into dashboards on our phones with different users, which update depending on which room we are in.
If you want to gate access to certain functionality on a dashboard designed for a common area, you would need to route to a different dashboard upon providing some kind of authorisation, e.g. an onscreen PIN pad.
Happy to discuss.
We didn't know you'd declared this. I hope there are temporary solutions available while your declaration is communicated to everybody else.