Trusted Networks Auth Provider enhancement

[awarecan]

Current

Since 0.89, Trusted Networks Auth Provider will load its own config.

homeassistant:
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 127.0.0.1
        - ::1
        - 192.168.0.0/24
        - fd00::/8

Proposed Change

homeassistant:
  auth_providers:
    - type: trusted_networks
      trusted_networks:
        - 127.0.0.1
        - ::1
        - 192.168.0.0/24
        - fd00::/8
      trusted_users:
        192.168.0.0/24:
          - user1_id
          - user2_id
        192.168.0.1: user1_id
        fd00::/8: 
           - group: group_1
      bypass_login: false

The changes around the user list provided in the login form, depends on where the request is coming from, the user list could be different

trusted_users key in the example	explain
192.168.0.0/24	two users allow to choice
192.168.0.1	only one user allow to choice, this has overlap with above entry, we will do AND logic
fd00::/8	all users in group_1
rest	all active, non-system users are in the option list

Especially if bypass_login is enabled and only one user could be chosen, the login form could be skipped.

Migration / Breaking Changes
No issue, all options are additional

EDIT: modify group base on feedback

[balloob]

How are you differentiating between group and user ids ?

bypass is one word.

[awarecan]

First version will only support user. No good way in my mind to distinguish user and group. Maybe we can use g:some_id?

[balloob]

In YAML, you can actually do - group: abcdefg and it will be a list with a dictionary with 1 key 😬 Not sure if that is going to be acceptable 😉

For auth config, it needs to be crystal clear. I rather have it be too verbose, there is no room for mistakes.

[bob1de]

Maybe allow for a dictionary as value for trusted_networks as an alternative to the list?

# traditional
trusted_networks:
- 10.1.2.0/24

# alternative
trusted_networks:
  10.1.2.0/24:
    users:
    - user1
    - user2
    groups:
    - group1
    - group2

Would maintain backwards-compatibility while allowing for the new options to be used without duplicating the network cidrs under multiple keys.

[bob1de]

BTW, Do we want to sort the networks by longest prefix as in routing tables, so that smaller parts of a larger subnet can have a different config?

[awarecan]

I am not the fun mixed networks and users together. Because user may choose only assign user to partial of trusted network. In that case, you can select all available users from login form.

Sort networks is a good idea. We should do it.

[bob1de]

Hmm, wouldn't sorting the networks by prefix length provide just that - the ability to assign particular users to a smaller subnet of a larger trusted network?

For a backwards-compatible syntax, I could also think of something like this:

trusted_networks:
- 10.1.2.0/24  # traditional, just a string
- network: 10.1.2.32/28  # new, dict
  users:
  - user1
  - user2
  groups: [ group1 ]