Implement Trusted Upstream Auth Proxy as Auth Provider

[shbatm]

Context

Was curious if there is interest in adding an Auth Provider that can authenticate a user upstream and pass the user name to Home Assistant to be logged in?

Best example of what I'm looking for is Grafana's AuthProxy, more details

For some additional background: I run a Traefik proxy in front of most of my home services that uses the Traefik Forward Auth docker image to provide OAUTH2 authentication (in my case via Google). This provides a HMAC Cookie header back to the reverse proxy once authenticated. I have it disabled for my HA host address, otherwise I'd have to go through 2 OAUTH flows to get access. I would like to be able to use a SSO for all of my home services (helps with the Wife-Approval-Factor greatly).

Another user who was previously tackling the same problem.

Proposal

Add an Auth Provider which works very similarly to Trusted Networks, but accepts user information from the request headers on those trusted networks. Optionally, it can provide a HMAC verification of a header token to verify the token is still valid.

I've created a working mock-up on this fork. Aside from the new provider file, the only change needed is access to the headers in the auth flow. I've done this by just passing request.headers in the context from the auth component login_flow.

Consequences

I know there is a lot of distaste for IP-based or Header-based authentication--this is a pretty specific use case, but I believe there are enough HA users advanced enough to want to be able to use another controller for authentication but not via command line.

Another challenge would be managing the different incoming cookie formats and how to validate them. I added the method for traefik-forward-auth into the example above, but this may need to be an external call to validate the tokens in more specific cases.

I do like using the Cookie header, because it stays out of the way of Hass' Bearer token/Authentication headers.

[sidoh]

I'm also interested in support for delegation to external auth mechanism.

My setup is similar in spirit. I'm using client certificates and have some nginx stuff that issues JWTs in cookies with info from the client cert subject DN in the JWT claims. My general desire is to plumb these JWTs+signing key into HA and have it delegate auth to what I've got set up.

Stuff I've tried:

Apparently, exactly what you tried!

Looks like we landed on the same approach 😆 -- sidoh/home-assistant@6914c5c.

This is what I've got now. It works well, but had to override a core component to get it to work. Obviously not ideal.

LoginFlow external step

I also briefly looked at having a LoginFlow that has an external step + a callback. This is used by components to support oauth config flows, so it seemed like a nice approach that could enable auth delegation via an OpenID Connect flow.

Unfortunately, I hit a wall. From what I could tell, login flow does not support external steps in a pretty deep way. I was able to add support for the step types in the UI, but you can't tell the login page to progress to the next step after the callback is hit. This normally happens through a websocket connection, but that isn't opened until the user is logged in.

More background

Had some interesting discussion with @balloob about this on the dev_backend channel on Discord. He had a suggestion which I've not been able to look into yet involving a custom component with an un-authenticated HTTP endpoint. Not yet clear to me if it's possible to have the login page work seamlessly with it, but need to think about it.

[balloob]

External step wont' work because it depends on listening to events inside Home Assistant but there is no connection with HA yet (because no auth).

My main issue is that every auth feature that we add to Home Assistant exposes the vulnerable surface. Our resources are limited and security is difficult to get right.

[sidoh]

Thanks for the reply, @balloob!

External step wont' work because it depends on listening to events inside Home Assistant but there is no connection with HA yet (because no auth).

Right, that's precisely what I discovered (detailed it in the second paragraph). I think it could still be possible with window.postMessage from the opened tab, although it seems like it potentially defeats the point of using the external flow stuff at all. Rough flow would be:

1. Click a link on login page to open a new window or a popup
2. Complete the oauth flow within the new popup, which would end up at the callback endpoint
3. Callback endpoint renders some javascript posting some indicator message to the login form that the flow is complete
4. Login form renders some different UI components allowing progression to the next step

My guess is that this is an uncomfortable contortion of how the login flow works, but figured I'd throw the idea out there.

My main issue is that every auth feature that we add to Home Assistant exposes the vulnerable surface. Our resources are limited and security is difficult to get right.

I definitely respect this. It's a healthy concern.

That said --

1. I do think an OIDC-backed auth provider -- done correctly -- would only serve to improve HomeAssistant's overall security. My guess is that some number of users are setting weak passwords. Given the opportunity, though, they might instead choose to enable a flow using google, facebook, github, etc. I realize this is probably a pretty big undertaking, but wanted to share how I'd thought about it.

2. Providing optional safety valves for advanced users seems like it gets everyone what they want. Folks like myself and @shbatm get our unified internal auth, and users who don't enable anything aren't affected. One of the concrete proposals here just forwards client HTTP headers to the auth provider, which seems very safe from a security perspective, and unlikely to constrain future design choices.

I'm personally very happy with (2), but it seems like there might be an appetite for a more general solution.

[donnib]

I would love to be able to add SSO to my home assistant

[elupus]

Seems this is missing a link to my oidc backend. home-assistant/core#32926

[mateuszdrab]

Is there any change we could resume the conversation on this issue?

Home Assistant really could benefit from supporting an industry standard OIDC provider - especially considering the built-in authentication framework is already using it.

Use case for me is simple, my parents' phones are Azure AD registered, they have SSO on everything except Home Assistant. I'm trying to go passwordless as such I want to change passwords to long almost token like strings as all authentication is done via SSO with conditional access and/or certificates.

For other users, I think they would love to be able to share access to their instance simply by authorizing a Google or Microsoft account whether it's through built in functionality or an external Oauth2 proxy or Keycloak, etc.

[quentinus95]

I agree that OIDC would be a huge plus for this app (I was actually expecting it to be supported when I saw that some OAuth2 flow was involved when authenticating with the app).

• Regarding @balloob's remark that every added authentication feature increases the risk: I believe this is a question about who is we exactly. Nextcloud, for instance, allows authentication providers to be developed and installed as plugins in the application. Home Assistant could provide such solution if we want the core team to avoid being responsible for an authentication provider. It is then the responsibility of the user to install and use, or not, this plugin. I strongly believe that such option would be used by knowledgeable users, so I do not believe that it would put other users at risk.
• Regarding OIDC itself: it is definitely, with OAuth2, a leader in the software industry. It is used by most of the main online providers, it is integrated with a huge library ecosystem. Highly qualitative libraries can be found and can sometimes even be certified and/or audited to decrease the risk.

Home Assistant could provide a bridge for authentication solutions to be provided as a plugin. I would, in my opinion, be in favor of having OIDC being integrated by the core team itself, because it is pretty standard and would provide better integration guarantees when updating it. But if it is not possible, a Nextcloud-like solution would be a huge step. An implementation solution could be to have OIDC be the main authentication mechanism and have a local user provider in Home Assistant. This way you have a single way of authenticating users (OIDC) and you provide a local preconfigured mechanism using the local OIDC provider.

I would also add that having an OIDC server instance sometimes actually increases security. Those instances can either be public (in such situations it reduces the risk of misconfiguration, e.g. using GitHub as an identity provider to authenticate on Home Assistant), or private and provide a lot of auditability tooling (plus features to enable two factor authentication, logs, alerting, password strength rules, ...).

Please reconsider enabling this solution in Home Assistant 🙏

[jberger]

I wouldn't necessarily suggest that homeassistant try to implement being an OIDC provider. If you don't already have a provider you can use, Keycloak is an excellent self-hostable OIDC provider that is battle tested. It is what I wish I could use to provide SSO for my HA

[quentinus95]

@jberger yes, I was thinking of replacing local users by local-users-through-local-oidc, which would allow to have a single way of authenticating users, and decreasing the risk @balloob was mentioning.

[balloob]

Going to close this issue as we are not currently considering expanding auth possibilities in Home Assistant.

[quentinus95]

@balloob sad that you do not address remarks in this issue

[mateuszdrab]

@balloob sad that you do not address remarks in this issue

Disappointing, not even added as some long-term milestone, let's shove it under the rug :(
I wonder if this could be done as a custom component.

[Helvio88]

@balloob I was researching this capability for HA. Any chance it can be resurrected? Maybe it's time! :)

[dougmaitelli]

For anyone interested, it is possible to achieve this in HA currently using an add-on: https://github.com/BeryJu/hass-auth-header

I agree such feature should be native and supported by any self hosted service, but since we don't have it natively, this is one way of achieving it.

[acelinkio]

https://github.com/BeryJu/hass-auth-header only provides ProxyAuth and not OIDC implementation. That integration experience is pretty terrible despite community efforts to make it better.

Here are some additional context where the community has attempted to engage developers to deliver authentication options, but ultimately shut down.

Community Solution Proposal, punted to forums: #832 (comment)
Related forum post, crickets: https://community.home-assistant.io/t/open-letter-for-improving-home-assistants-authentication-system-oidc-sso/494223

PR for LDAP support, shut down: home-assistant/core#37645 (comment)
PR for ProxyAuth support, shut down: home-assistant/core#38175 (comment)
PR for OIDC support, shut down: home-assistant/core#32926 (comment)
Then an earlier comment in this issue shutting down any additional talk on the subject. #286 (comment)

The community is willing to create add-on, but it does require some amount of engagement for smooth implementation. If the developers could respond these authentication proposals and provide an approach for the community to build towards that would go a long way.

[mateuszdrab]

I'm also not convinced about using hass-auth-header because of security reasons. I've been delaying implementation of it due to added layers of complexity with my ingress setup requiring quite a reshuffle to support oauth proxy.

I'm quite disappointed with this whole situation, as a project made to integrate everything together, overlooking an industry standard authentication protocol is in favor of own implementation is just bizarre...

The treatment we receive from the contributors is quite disheartening.

[frenck]

This architectural issue has been closed.