Users/Groups

Users and Groups can be configured at any place in the node tree. The way permissions work is users have access to the parent node and the parent nodes children. In the below example, Joe has access to the SBC device because both Joe and SBC are members of the Site 1 group. Joe does have access to the root node.

If Joe logs in, the following view will be presented:

Schema

The configuration of a group and a user in it:

nodes:
  - group:
      description: Site 1
  - user:
      parent: Site 1
      email: joe@example.com
      firstName: Joe
      lastName: Smith
      pass: his-password
      phone: "+12155551212"
      edgePoints:
        role: admin

A group carries a description and nothing else. Its place in the tree is what gives it meaning, and the users and devices below it are what it groups.

A user is the one node type with no description, so a file finds it by email, and by name when there is no email. phone is written as text so the leading + is kept.

role is admin or user and lives under edgePoints rather than with the points, because a role belongs to the connection between the user and the node above rather than to the user. The same user mirrored into two places can hold a different role in each.

Passwords

A password is stored as a bcrypt hash, never as the plaintext value. A pass value written through the UI, the API, an import, or a provisioning file is hashed before it is stored, so the store, sync streams, and exports carry only the hash. A password stored in plaintext by an earlier release keeps working and is converted to a hash the next time that user signs in.

An export carries pass as the stored hash, which cannot be converted back to the password. A plaintext pass in an import file is hashed when it is applied, so a file that sets passwords should still be treated with care until it is applied and deleted.

The password field in the UI shows blank rather than the stored hash; typing in it sets a new password.

Where a user signs in

A user belongs to the instance whose tree holds it, and signs in there. A user under a device node is that device’s user: when the device syncs to an upstream, the user is replicated there with the rest of the device’s tree and appears under the device in the upstream’s UI, but is not accepted at the upstream’s sign-in. Setting that user’s password from the upstream changes the password on the device, and does not make the user an account on the upstream. A user who needs the upstream is created under the upstream’s root or one of its groups. This also means a device still carrying the default admin account is not a way into its upstream.

Sign-in attempts are limited per account: after five failures in a row the account is refused for a second, doubling with each further failure up to five minutes, and every failure is logged.