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?
1 Like
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.
Nope. 10 charrrr
3 Likes
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.
2 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.
2 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
+1 from me too. I have a dozen services I run for my family to retain privacy and control over our data and home assistant is the only one that has a “different” login method.
+1
Sidenode: I have installed oauth2proxy with keycloak as access security service, which works fine. Unfortunately, HA’s in-app browser does not allow WebAuthn (Passkeys). To the extent that HA does not integrate SSO, it would be a good start if at least the in-app browser in iOS would allow WebAuthn requests.
1 Like
+1 count me in reg. OIDC SSO SAML2
+1 SAML authentication and better RBAC would be great
Before sharing my thoughts, I am a technical pre-sales (principal Solutions Engineer) for Okta and have worked on numerous OAuth2.0, OIDC and SAML project in the past 8 years I have been at the company. I work closely with some of the people that author the RFC’s around those specs.
I agree with @christiaangoossens and are willing to share some of my thoughts as well, as I have been looking to integrate my HA with Okta/Auth0 for a while now.
First of all: Yes HA should allow external IdP’s to integrate for authentication, and potentially even for authorization (allowing external AuthZ servers for OAuth2.0 on API’s). This will allow for a range of functionality:
- Self-Service or approval based registration of new accounts
- Integrate with much stronger authentication like passkeys, biometrics, etc to open use cases like passwordless authentication (boosting security)
- Access Recertification campaigns so that admins are prompted to review and revoke access regularly
- Advanced features around brute force and credential stuffing attacks
- etc
Happy to further detail the benefits, but I will not bore you’ll with the sales pitch.
Now to the two “problems” at hand, let me respond to the decline message first:
“Credentials are only validated during login” and “no one will check back with the OpenID provider if the user is still valid” are not entirely true (anymore) - This is a decision to be made by how the thing is deployed. RFC’s like introspection (RFC7662) and token revocation (RFC7009) allow for token validation at the IdP, rather than local. But to Christiaans point, sensitive tokens should have a short lifetime, which means that the app should hit the IdP to get a new access token more often. When the account is blocked, the token will not be issued.
“Okta is actually smart enough in that if you are already logged in to it” - This is correct and incorrect at the same time. What happens it that when the app redirects to the IdP for authentication, the IdP may still have an active session cookie, due to recent login. This means no username and password (or passkey!!) is required. When a user is blocked, suspended or deleted, the session cookie will be invalidated and it WILL prompt for credentials.
To Christiaans point “where all your users have 2FA” and “you can circumvent the original 2FA”, this would indicate a bad deployment. This is called automatic matching and is considered bad practice. If a user exists locally and tries to authenticate with social, SIWApple or any other external identity, HA should always prompt for the local credentials before linking the two together. We documented this risk in the link below: “Insecurely linking accounts can allow malicious actors to access legitimate user accounts. Please remain aware of the following: For both manual and automatic account links, your tenant should request authentication for both accounts before linking occurs. In addition, every manual account link should prompt the user to enter credentials.”
Secondly “User logout at the IdP (OIDC provider) are not propagated to the consuming app” - This used to be true, as @christiaangoossens mentions in the 2nd issue solution part, meaning that when you logout from the Idp, it sends a signal to the apps to destroy any session, cookie, token it uses to keep the user logged in.
I agree with the solutions @christiaangoossens points out, however on this point “Alternatively, you could always prefix usernames with the OIDC provider name” I disagree. Much account linking (disclaimer above) is done on a user identifier. This ways you can easily allow a user to hook up their social accounts like facelook for login. If you mod the username, you will need to do a load of mapping magic and you will end up with duplicate accounts.
Please consider this my offer to help …
Thanks @balloob and @christiaangoossens for your thoughts … all of the above is not to criticise in any way, you seem very well aware of what we can and should do for SSO … Just trying to add to what you already mentioned in my own way.
Resources:
21 Likes
+1000 for RBAC & SSO from me.
These features are certainly not Enterprise-only. A “trust everyone all the time” policy is a tricky sell, potentially inhibiting larger adoption. I know I would absolutely not entrust all family members or guests to handle my Home Assistant installation responsibly; there’s simply too much available to each user by default, something RBAC alone would resolve.
1 Like
Hello!
Is it possible to disable showing user profiles on log in page for local network in HA 2023.12 ?
I use external server as virtual hosting via SSH-tunnel because I have no external static IP.
So when I log in from outside my home network my HA detects it as local and uses Local Auth Provider.