Need to be able to distinguish between different types of user
Opened this issue ยท 5 comments
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 theAuth
system. -
We could implement a proper role-based system upstream in
Auth
. This is currently being discussed in dwyl/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
Role based-access also being discussed in dwyl/auth#31
@th0mas can you please indicate how many different roles and permissions you expect to need for Home Sec Auth? e.g:
admin
(default
) - can administer the whole system including adding/removing doors and people.housemaster
(custom
) - has access to all doors, can revoke access to anyone (other thanadmin
)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.visitor
(custom
) - can access main door only.
Any others you can think of?
@nelsonic No, I think that looks good. So do you want per-person access on top of RBAC?
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:
- We are using roles to control access to the
doors
; no content-level access. - Each
person
in the system can be granted one or more roles. - 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?
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