Need to be able to distinguish between different types of user

[th0mas]

Currently, once authenticated users have no individual roles. To be able to implement a secure system, we need to be able to properly limit what users can access based on their role. E.g.

Admin - Can control everything
Resident - Can register their devices and open some/most doors
Visitor - Can only use some doors when invited by Admin/Resident

We need to work out where we implement role-based control.

• We could tack it on to the existing user stub in this application but I want to avoid adding too much extra data here, as we
  get most of our user info from the Auth system.

• We could implement a proper role-based system upstream in Auth. This is currently being discussed in Add Role-Based Access Control (RBAC) to auth? auth#27.

I believe the second option will be better long term, as then all user info is centralised and roles easily accessed through JWTs

[th0mas]

Role based-access also being discussed in dwyl/auth#31

[nelsonic]

@th0mas can you please indicate how many different roles and permissions you expect to need for Home Sec Auth? e.g:

1. admin (default) - can administer the whole system including adding/removing doors and people.
2. housemaster (custom) - has access to all doors, can revoke access to anyone (other than admin)
3. resident (custom) - can access doors on all floors that they have been granted access to. Cannot access rooms that they are not authorised to enter, e.g. server closet.
4. visitor (custom) - can access main door only.

Any others you can think of?

[th0mas]

@nelsonic No, I think that looks good. So do you want per-person access on top of RBAC?

[nelsonic]

Ah, yes, RBAC is quite course when it comes to high-security environments.
Someone could have Top Secret clearance in general but still not be permitted to view the Roswell Archives 👽 ... 😉
Using only Roles to control access, we would end up having individual roles or at least a role per room/door in order to control access to specific areas, this could be "workable" for a simple use-case like a house because there are "only" 20 Doors so the highest roles we would need are n+4 or 24. But it doesn't scale very well beyond the simple use-case. 💭

Our plan for the "dwyl App" is to have content-level access controls similar to a CMS or Google Docs.
So a person can share a specific record with another person (e.g. a team mate or family member) and grant them a specific level of permission to the content (Read|Write|Admin).

In this scenario the doors would be considered items of "content" and grants would be made on the content-level.
However ... as I write this and think it through, I am re-considering using content-level access controls for the House as it will create unnecessary complexity/coupling between systems. Maybe it doesn't need to be "scalable", if we have a means to return all the Roles to the Auth Server on the Boot

So for now, let's operate under the following assumptions/criteria:

1. We are using roles to control access to the doors; no content-level access.
2. Each person in the system can be granted one or more roles.
3. Each door in the system must list the role(s) that can gain access to it.
   e.g. the Front door could list the following roles:

roles = ["home_door_front", "home_doors_external", "home_resident", "home_housemaster", "admin"]

Where the first role is the specific to that door ideally it's the name of the door in the system,
the second role is a group of doors, then a list of the roles that have access.

The individual door firmware should then check that the person has (at least one of the required roles):

RBAC.has_role(person, roles) 

We are expecting to allow checking multiple roles in a List: dwyl/rbac#2

@th0mas thoughts?

[th0mas]

Yeah this makes sense and should work well 👍

We could always fake content level access later by using single use roles with a thin abstraction over them