It’s a monster-in-the-middle proxy that intercepts all the traffic between the client and the backend, and only forwards data and service calls for “allowed” entities/services. What’s allowed can be configured (in a yaml config) per-user.
It needs a ton of polish and at the moment it only works for a couple domains (light, switch, and script) because that’s what I needed it for personally, but that part can be fleshed out without a lot of work.
Please play around with it and ask any questions and I’ll try to keep up if anyone’s interested. Especially if any security-minded folks wanna hammer on it I’d love feedback.
Interesting idea, but the requirement for having auth0 as well is sorta a non-starter IMO. I’ve already got user credentials in HA, why would / should I need to use yet another authentication provider. Especially one that is cloud hosted and pay for?
Auth0 has a free dev account that will be sufficient for this. Mostly I didn’t want to build my own auth; auth is hard. It shouldn’t be too hard to replace auth0 with any other oauth2 id provider, including self-hosted ones.
The whole problem is that you can’t use an HA login because all HA users can access everything. If someone had a login to your HA, what would stop them from just logging in to HA instead of this filtering proxy? You need to have an independent identity and auth system.
I hear you. Personally, I like Auth0, my company uses it for our SSO and I’ve played with the free dev account. But it expires configuration (or at least it did last time I used it). In any case, it’s a good idea, but pushing a reliance on a cloud service wouldn’t fly for anything I’m trying to do with my HA.
Auth0 is usually really stable, but when they aren’t, it can be hours of non-access, and if my HA wasn’t available because of that for the folks I need to limit access that would be a major show stopper.