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.
> I think a lot of people have a wrong perception of how "complicated" authorization systems need to be
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.
I disagree that that leads to a huge amount of unavoidable complexity. I am (and have been) building systems that are deployed into exactly those security sensitive organizations, with exactly the stack I described above. The only main requirements that those systems usually have is audit logging, which is becomes easy with a centralized policy engine.
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 is an authorization engine, with some supporting capabilities, but it's not a complete authorization subsystem.
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.
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.
antonvs · · focus · HN ↗
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.
hobofan · · focus · HN ↗
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.
antonvs · · focus · HN ↗
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.