Re-Design

Proposal #1: Multiple Roles per User and separation between Permissions and Access Scopes

This design tries to address two of the missing features of the current implementation:

Multiple Roles per User
Separation between Access Scopes (Organization, Facility, Workspace, Room) and Permissions

Multiple Roles per User

Allowing a User to have more than 1 Role give us the possibility to define very specific Roles and then compose them in different ways to create different logical roles. This composition of Roles also makes possible to reuse already defined Roles simplifying their configuration.

In the application, when a permission needs to be enforced, the group of all the Permissions from all the Roles the User has is going to be used. Permissions are always added when creating the group of all the Permissions a User has.

Access Scopes

In the current implementation, some Permissions are associated to an Organization and some of them are not. This tightly-coupled relationship between Permissions and Organizations makes impossible (or very cumbersome) to create a more fine-grained and friendly way of defining Permissions.

The new approach is to define different Access Scopes. An Access Scope grants access to one or more Organization, Facility, Workspace and/or Room. The Access Scope is defined by the Role/s a User has and all the Permissions are evaluated in this scope.

All the Permissions a User has are evaluated in the same Access Scope

The proposed solution sacrifices the possibility of having different Access Scopes for different Permissions in order to gain simplicity both in the implementation and in the configuration of the Roles.

Proposed EM

Each organizational unit (Organization, Facility, Workspace and Role) now has a corresponding table that grants access to individual roles. In this way, we could have a granularity up to the Room level.

In this new approach, the table RolePermission doesn't have the column OrganizationId anymore. The scope where a permission is applied is given by the join of all the *Access tables where the Role is present.

Access Scopes are inclusive

A Role that has access to Organization 'A' also has access to any organizational unit below it.

Permission Mappings

The application currently supports 31 different permissions. The new design will reduce the number of permissions to 14. Some of the old permissions had a 'list' and 'read' version (i.e. read_users and list_users) that were actually never used in reality. The new design will merge those 2 kind of permissions into a single 'read' one.

The current implementation also has some permissions of the form *_from_all_organizations (i.e. list_users_from_all_organizations) that are no longer needed given the new Access Scopes. Same thing happens to the permissions of the form *_from_current_organization and *_from_current_facility.

Some other permissions like list_organizations, list_facilities, list_workspaces and list_rooms are no longer explicit permissions. They can now be related to a particular Access Scope.

The mappings between the current permissions and the proposed ones are:

Current Permission	New Permission	Used In	Comment
list_organizations		List Organizations	This permissions has no counterpart in the new design. List Organizations operation will return all the Organizations that are in the Access Scope of the user that is invoking the operation. Read Organization operation will fail if the invoker doesn't has access to the requested Organization.
read_organization		Read Organization
list_facilities		List Organization's Facilities	This permissions has no counterpart in the new design. List Facilities operation will return all the Facilities that are in the Access Scope of the user that is invoking the operation. Read Facility operation will fail if the invoker doesn't has access to the requested Facility.
read_facility		Read Organization's Facility
list_workspaces		List Facility's Workspaces	This permissions has no counterpart in the new design. List Workspaces operation will return all the Workspaces that are in the Access Scope of the user that is invoking the operation. Read Workspace operation will fail if the invoker doesn't has access to the requested Workspace.
read_workspace		Read Facility's Workspace
list_rooms		List Workspace's Rooms Rooms Search	This permissions has no counterpart in the new design. List Rooms operation will return all the Rooms that are in the Access Scope of the user that is invoking the operation. Read Room operation will fail if the invoker doesn't has access to the requested Room.
read_room		Read Workspace's Room Rooms Search
list_roles	read_role	List Organization's Roles
read_role	read_role	Read Organization's Role
list_users	read_user	List Users
list_users_from_all_organizations		List Users (if 'location' is not specified, this permission is required)
read_user		Read User Information
delete_user	delete_user	Delete User
modify_user	modify_user	Update User Information	There is no longer a distinction between modify_user and modify_user_nfc_tag
modify_user_nfc_tag	modify_user	Update User Information
modify_own_user	modify_own_user	Update User Information
list_patients_from_all_organizations	read_patient	List Patients Patients Assignments
list_patients_from_current_organization		List Patients Patients Assignments
list_patients_from_current_facility		List Patients Patients Assignments
modify_patients_from_all_organizations	modify_patient	Form Submission Patient Tag Id modification
modify_patients_from_current_organization		Form Submission Patient Tag Id modification
modify_patients_from_current_facility		Form Submission Patient Tag Id modification
list_discharged_patients	read_discharge_patient	List Patients
discharge_patients	discharge_patient	Forms Submission
final_discharge_patients	final_discharge_patient	Forms Submission
send_messages	send_messages	Send Message
read_alerts_only_from_associated_patients	read_alerts_only_from_associated_patients	List Messages
read_alerts_from_entire_organization	read_alerts_from_entire_organization	List Messages
re_schedule_alerts_from_all_organizations	re_schedule_alerts	TimeBasedAlerts Job Scheduler
re_schedule_alerts_from_organization	re_schedule_alerts	TimeBasedAlerts Job Scheduler

It is important to notice that, when configuring permissions, some permissions are not compatible with some scopes. For example, a User having read_user permission only in a Room Access Scope will not be able to list users in the application. The reason behind this is that, in the application, Users are associated to Facilities and not to Rooms.