There is obviously a community desire for this, such a shame it keeps getting ignored.
2 Likes
Fixed it for you.
3 Likes
The only way we’re getting this feature is to fork HA to a new project without the current lead devs that are actively blocking it.
1 Like
There are very few genuine arguments against the implementation of a solid authentication solution in any project. It is, quite honestly, shameful that the lead developers for HA are actively shutting down conversations on this topic. There are many well-informed, thorough, self-critical thoughts laid out in the original post that all got holistically addressed with a simple too niche, you can’t have it response. As has been pointed out, there are so many highly-technical, niche features baked into HA, not the least of all is the inclusion of a YAML-based configuration backend, which to many of us may not seem highly-technical, but try explaining that to your dad.
The exclusion of this feature is a shame, and one that is easily avoided, if only the project leads would view this not as a threat to their vision, but as a way of supporting their most die-hard fans, the people to tinker, hack, and build their platform into what it already is today.
8 Likes
You are only partially correct. There have been multiple attempts to add this to HA but the lead devs have rejected these pull requests for reasons other than code quality.
Their primary concerns have been stated:
- How to handle de-authentication.
- Not wishing to be responsible for maintaining the integration.
- This is a commercial use case outside home use (I disagree with this vehemently).
OP did attempt to provide extra capabilities to the login screen which would allow add-on’s to fill this gap but requires some additional work at this time.
2 Likes
Just adding my voice as another home user who would love to see an interface to link HomeAssistant to a central identity provider.
Though stand-alone pass-key support would be pretty damn good too!
3 Likes
I provided some input a while back, and this has been a great discussion. I do want to add some more feedback and perhaps other context.
Several comments were made that doing some of this would require a complete rewrite of the auth system. There should be some consideration that this may not be necessary. Using Windows as an example, the basic local login authentication hasn’t fundamentally changed in several decades. There is still a local user database. So it shouldn’t be necessary to rewrite the current authentication process.
Adding outside Identity providers (i.e. Azure AD) via SAML can simply add claims based auth. It actually wouldn’t be necessary to have HA handle all the variations. Whether or not MFA is required for that ID, whether the User in question s
hould still have access, etc. All of those things can and should be controlled by the external provider. What gets configured in HA is the specific claim (group ID, group name, etc.) has been given specific access. The Idp controls the use of MFA, and refresh, and whether the token requires validation again. None of this should be the responsibility of HA.
For example, using Azure AD, this would be governed by a conditional access policy to stipulate how long a given auth token is good for and how often MFA is required. HA needs to do nothing but validate via Azure if the token is still valid.
All this being said, the authorization part of HA absolutely needs to be improved. There is a need to have at least basic permissions (owner, versus admin, versus user). Owner can do anything, admin can do most things, users can only do what is enabled for them, just as an example.
While other auth options could be considered, SAML auth is by far one of the easiest to implement, and on its own gives options (in addition to any loca users defined), for numerous other Identity platforms.
3 Likes
This is a good summary.
I’m not an expert in SAML, but we use it at work and I was surprised how easy it was to implement, especially where we had to adapt legacy systems.
If I got it right, there’s a community which is willing to implement the feature and there are enough use cases that are not enterprise related. So the last remaining obstacle is the cost of maintenance.
Given that, what are the specific pain points the core team (could) have? What has actually to be maintained?
Maybe there is a way to address these in an acceptable manner?
1 Like
My understanding is they don’t want to maintain the authentication methodologies or the inherent risks involved with having them in the core software (e.g. methodologies becoming out of date, vulnerabilities being introduced or complexities leading to developer error in implementations they are not experts in.). They would most likely be fine with third parties maintaining their own authentication plugins like the Header authentication plugin. The biggest question left unanswered is if they would accept extending the ability for plugins to have deeper interaction with HomeAssistant.
It looks like hooking into the existing login screen for challenge response isn’t straight forward at this time, hence the Header authentication being a bit buggy at times.
I’m not an expert here, but it seems to me that trying to maintain a satisfactory security implementation for all users has costs as well. Again, stick to your core competency and let someone else handle the ever-changing security landscape.
I’m a subscriber to Nabu Casa not so much because I need what it offers, but because I want to support the project. I see many integrations with <.5% adoption. This would likely be well above that and would harden security for those that want it.
I’d rather not see this get “corporatized” and ignore community requests. I can appreciate slow adoption, but the hesitancy seems to be of the “no” variety than “let’s see.”
I’m genuinely confused about the naysayers. It’s been explained over and over that it would always be opt-in and can readily be done locally.
Is there something I’m missing? I don’t understand the concern about maintenance (beyond initial development); not having to try to be security experts seems a worthy trade-off to me.
3 Likes
This.
Keeping authentication, authorization, and access control exclusively internal to the project seems to assume greater responsibility and liability than providing facilities to support robust, well-audited, fit-for-purpose third party implementations. With all due respect, it shouldn’t be on every project maintainer to handle every possible security implementation themselves. What is the point of well-established standards like SAML and OIDC if not to create reliably secure ways for an application to support a variety of mechanisms?
4 Likes
I also use Authentik and have tried using this method, but hit a wall so I know it’s somewhat possible. Too much for me to diagnose right now so I’ve moved on.
I found that with Authentik at least, it can also function as a reverse proxy so you could technically put Home Assistant behind that and have your first login step but then it would prevent your mobile app from logging in. So a plugin would need to account for such a thing unless the mobile app sends a header or something in which you can tell it to just move the user on. I have not examined any mobile traffic from my phone so I may not be on the right track, I also have NOT tested this and am only just starting to scratch the surface of what can be done in the software.
My point for all of this though is, if a plugin was developed or even a repo for HACS to integrate this, it would be massively adopted based on the comments here.
Home Assistant is aimed at a Home user, the home environment. IMHO this proposal/open letter is for feeding the enterprise smart home syndrome. I am pretty sure my dad (or any other average user of Home Assistant) isn’t using SSO to log in to his home devices.
As a home user, home assistant is one of many apps I rely on every day, other examples of applications I use at home include Bitwarden (Supports SSO), Firezone (Supports SSO), Hedgedoc (Supports SSO), Immich (Supports SSO), Jellyfin (SSO coming soon and supports LDAP for now), Nextcloud (Supports SSO). I use these applications because I am in your target audience, I am a user with that puts “local control and privacy first”.
As a home user, I find it tedious to maintain separate accounts on separate services for each of the people that live at my home, I like automation, which kinda makes sense, given that’s what home assistant is about.
As a home user, home assistant is the only application in my self hosted stack that I have to manually manage separate accounts for.
As a home user, I have even spent many hours trying to work around this, such as the hass-auth-header and using a proxy to do authentication, but of course, as others have pointed out, the mobile app doesn’t like this.
3 Likes
With the advent of supportable Commercially available and PREFERRED FIDO2 passkeys in all of the top authentication providers (MSFT, Google and Amazon all support end user passkeys as of October 11,2023 when window 11 moment 4 released)
I suddenly feel this is no longer an option. We should have Oauth and Fido2 support at the HAOS level.
Just wanted to add +1 comment on top of my vote on this feature, I’ve long connected everything to Authentik now, and regarding comments that “home users” won’t need it… I AM a home users, have nothing to do with sysadmin stuff and me and my family are using it 
1 Like
I wish I get webauthn support in Home Assistant.
3 Likes
The HA devs wouldn’t have to worry about the latest auth methods (webauthn) and all the edge cases that people wants (2fa, etc), if there was proper integration with something like OIDC or oAuth etc.
Authentik can allow any type of login flow you want. 2FA, 3FA, require hardware key, etc. HA just needs to allow integration with oAuth, OIDC or SAML and authentik will take care of the rest.
For example I just setup seafile and it has oAuth integration. In Authentik I was able to set up an oAuth provider and then I can choose any set of rules I want for which users can access, what type of login they need etc.
I don’t think have HA devs spending time constant re-implementing the latest auth (webauthn) is worth it when they can just provide a standard auth method like oAuth and then let the provider (authentik) take care of all the details that the user wants.
3 Likes
+1 for OIDC and better management of user’s permissions!
1+ for me as well