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.
> 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.
I had to check that this wasn’t sarcasm when the post went from this
> 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.
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?
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.
Aurornis · · focus · HN ↗
> 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.