Advanced Authentication

Feature Requests
1

Overview

This will describe a proposed addition to Home Assistant to add multi user authentication and authorization. Home Assistant (Hass) up to this point has focused on the single user use case. It expects all users of a system to authenticate with the same credentials. Some user stories to get started:

  1. An owner of a Hass setup would like to remove all the extra features and panels from their spouse, giving them access to just controlling the components they care about.

  2. An owner would like to prevent their roommate from being able to turn their bedroom lights on and off, but still give them access to controlling the common room lights.

  3. An owner would like to delegate authentication to a third party (OpenId / OAuth provider).

Glossary

Authentication - The act of a user presenting credentials and verifying they are who they say they are.

Authorization - The act of asserting that an authenticated user can do a specific action.

Admin - A entity in Hass that has no limit on there permissions (akin to root in Linux)

User - A entity in Hass that can get restricted access to components within the system.

Web Interface changes

The default home assistant experience will go unchanged. The default, unauthenticated web page will give users an easy on boarding. If auth is enabled on your home assistant instance, you will be required to login to the server. Bootstrapping the user database requires Hass be launched in a trusted environment. That is, the first person to connect to the server in “auth” mode gets to set up the first user. From there, the first user can add new users as needed. This would be accomplished through the “Admin Users” panel. Users can also be set to “Admin” in this panel, to allow for more than one Admin.

There will be an option in the “Admin Users” panel to delegate authentication to a reverse proxy. This would allow advanced users to set up a proxy in front of there Hass server to authenticate users. If this option is selected, only user names are needed to be populated in the “Admin Users” panel, passwords would not be required.

There will be a “User” panel that will allow individual users to manage their own passwords. There could be other information in this panel, mobile number, email address, etc. for notifications.

There will be a “Admin Permissions” Panel that will allow Admins to set permissions on users. Admins would be able to check an uncheck the components that the users have access to view and modify.

I’d like to get feedback on this, both features that people would be looking for and areas in the code base to look into to add these features.

2

+1 . On this

3

I’d also like a “read only” view option for unauthenticated access. Basically, if you don’t authenticate you get a limited access “guest” account, much like Samba supports. Being able to also specify IP addresses/netmasks that automatically get guest access would be handy.

1 Like
4

I am all for a more sophisticated authentication and authorisation model.

I just wanted to share a few thoughts on this:

  • Re use-case #1: This could be as well be solved with a different view instead of permissions. Maybe that new kiosk mode may help to show a user only the relevant controls. Or, a tool like the HADashboard could be used to create different dashboards for different users.
  • Re use-case #2: I usually like to compare HA’s capabilities with the real world. In this case, your flatmate could as well just open the door to your room and flick the wall switch. Does this happen frequently? Probably not. A similar use-case I heard in a different thread was to prevent kids from having too much access to devices. And again, even though I understand that for example kids should not operate the washing machine, I am not locking my laundry door to keep them out, I just tell them not to touch the washing machine.
  • Re permissions: I haven’t quite understood on which level you were planning to implement permissions. Components are a fairly broad concept in HA. I can’t imagine allowing/denying access to say all Philips Hue lights, or any Z-Wave accessory. From your use-cases it sound more like permissions per entity or per device or per UI control?
  • I would suggest to implement this very carefully and start simple. I would not like to end up with a system that for example denies access for all users to anything, and I as an admin would need to go through and hand-pick every single UI control that users should get access to.
  • It would be interesting to learn a bit more about how users of HA are currently accessing the UI. Personal phone/tablet/laptop - with authentication or without, or shared tablets hanging on the wall, or specialised controllers (like wall switches, or remote controls, etc.). This would allow for a better understanding of the use-cases, and how authentication/authorisation or permissions may help.
  • Auto discovery: Since many components support some level of auto discovery, it would be good to think about how that may work with permissions. Would a newly discovered device be automatically available to anyone, or no one?
  • One use-case that I would like to add is simply having different credentials for different users and/or devices. A single shared password is not a good solution design from my point of view. If a device or user account is compromised, I would like to change that password without affecting any other users.
5

You usually use some authentication means to map a “person” into some role, and then the role has some set of access capabilities associated with it. (It could be 1:1 - a new role for every authenticated entity…). You also need some sort of mechanism to apply role-based access control to stuff in HASS. I think without having some sort of access control means available, more authentication will not be nearly as useful.

Probably entities need access control. How this affects groups which has mixed entities within it (that is, with different access) is not obvious. If 1 of the 3 lamps in the group doesn’t have READ permission, then should the overall group “ON”/“OFF” state be exposed? This is a hidden channel that exposes information if you’re not careful. I think the access control “problem” is by far more difficult to understand.

6

I definitely want multi-user support - and I want each user to process a unique groups.yaml file which I as administrator would set up with the devices each user is allowed to see and control. Any views that are not defined in a users groups.yaml file would be hidden.

It would probably also be desirable to hide individual items on the left side - such as the “Configuration” item and the “Developer Tools”.

Finally - I would want the ability to log what actions different users do - Date/time, username, entity and action.

Obviously - new devices/entities would be hidden by default until the administrator updates the groups for the individual users.

3 Likes
7

I’d love this functionality as well.

8

Most of this functionality is in the software aside from #3