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
That is something not required in a domestic setting, that is what HomeAssistant is designed for. I don't know why your children needs to have access to HA (or the internet afterall).
You can choose whether to make a user an admin, and you can specify certain dashboards to be admin only. My wall panels are all logged in with a non-admin user specific to that panel, set to show only what I want anyone to access.
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.
This is false.
<a href="https://developers.home-assistant.io/docs/auth_permissions/" rel="nofollow">https://developers.home-assistant.io/docs/auth_permissions/
I don't understand, why is it a joke? HA permissions are just to lock certain users or groups out of controlling certain things. You wouldn't be randomly giving out accounts to people you don't know or trust. It's the controls to your smarthome after all, not a shell account on an open sign-up server.
> HA permissions are just to lock certain users or groups out of controlling certain things
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.
Is it really an Elephant in the Room situation? Are there upvoted ticket/issues or community threads asking for it? I don't really know, it's an honest question.
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.
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.
What about giving different agents varying sets of tightly scoped permissions? Is there a good way to achieve that today? If not, it might warrant the effort down the road
Basically the only people I could imagine that'd actually want a complex user permission group is someone with 1 or more Airbnbs that wants to have an overarching view of their properties but also wants to give "guest" access.
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.
I don’t know, this seems like a pretty basic feature that I would expect all the mainstream smart home ecosystems to support. Do they not? Is it possible with Alexa/Google Home/ etc. for anyone to say “turn off all the lights in the house” into any smart speaker? I’d honestly expect the defaults to only allow commands to apply to the devices in the same room/group as the smart speaker.
Alexa devices know what room they're in, so if I say "turn off the lights" in the kitchen, the kitchen lights turn off. But if I say "turn off the living room lights" in the kitchen, the living room lights turn off.
(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!)
The thing is there are tons of "passive" automations that you still might want.
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.
To each their own, but honestly I wouldn't want any of those. I don't even like that my car has electronic locks and a keyfob, I just couldn't find a used car with mechanical locks/ignition that wasn't likely to be a money pit.
> 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.
You're trying to use technology to handle difficulty with minor adversity.
Their ethos is that Home Assistant should be deployed in a non-complicated way and that many things that "IT people" want to do with HA are not actually necessary. I can't find the source but I recall frenck (one of the lead devs) explaining that people ask him about stuff like setting up HA using Terraform and he just wonders why someone would want that.
That the default should be non-complicated isn't necessarily in conflict with features for power users, and I feel like in the HA forums it often is portrayed as an unresolvable conflict, when it isn't.
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 need to see end-to-end encryption on this service before I am in any way interested, it should be a "rendezvous service" connecting clients with servers only, with full end-to-end encryption between them, and Nabu Casa should have zero ability to control the server.
That's exactly how it's build. Nabu Casa has never been able to see any user data. You can read more about it here <a href="https://support.nabucasa.com/hc/en-us/articles/26508882007581-Remote-access-Security-aspects" rel="nofollow">https://support.nabucasa.com/hc/en-us/articles/2650888200758...
voidnullvalue · · focus · HN ↗
alerighi · · focus · HN ↗
voidnullvalue · · focus · HN ↗
peterclary · · focus · HN ↗
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.
pessimizer · · focus · HN ↗
We didn't know you'd declared this. I hope there are temporary solutions available while your declaration is communicated to everybody else.
phoghed · · focus · HN ↗
montjoy · · focus · HN ↗
voidnullvalue · · focus · HN ↗
This thread is relevant. Their permissions system is just on entities, and isn't a real EBAC system.
hobofan · · focus · HN ↗
wildzzz · · focus · HN ↗
hobofan · · focus · HN ↗
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.
bmurphy1976 · · focus · HN ↗
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.
[deleted] · · focus · HN ↗
[deleted]
MC995 · · focus · HN ↗
Many, going back years.
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.
papercruncher · · focus · HN ↗
cogman10 · · focus · HN ↗
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.
tshaddox · · focus · HN ↗
wlonkly · · focus · HN ↗
(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!)
zer00eyz · · focus · HN ↗
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.
krapp · · focus · HN ↗
No matter how crazy smart AI gets it's not going to be able to hack my doors, lights or thermostat.
zer00eyz · · focus · HN ↗
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.
krapp · · focus · HN ↗
antonvs · · focus · HN ↗
You're trying to use technology to handle difficulty with minor adversity.
frantathefranta · · focus · HN ↗
hobofan · · focus · HN ↗
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.
lurking_swe · · focus · HN ↗
voidnullvalue · · focus · HN ↗
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
floatrock · · focus · HN ↗
Apparently they're saying this is the wrong way to run a cloud.
wlesieutre · · focus · HN ↗
<a href="https://www.reddit.com/r/homeassistant/comments/1vxw5pu/access_control_real_peruser_permissions_as_a/" rel="nofollow">https://www.reddit.com/r/homeassistant/comments/1vxw5pu/acce...
rekoil · · focus · HN ↗
Build that and I'll be interested.
balloob · · focus · HN ↗