Example of configuration

This section is a tutorial that will show you how to configure roles and privileges for a HealthCare application handling patients and appointments, including confidential data.

It includes the support of both public and authenticated application accesses.

Application overview

Here are the main characteristics of the HealthCare application.

Model

The data model contains the following dataclasses:

note

The AppSettings dataclass is used only by the administrator to set up application settings, no external access is ever allowed.

Users

The following personaes are identified, along with their access:

Mary and Arthur are registered as Qodly users and use the authenticated endpoint. The administrator assigns them a role in the console.​

Once a Qodly app user is authentified, they can only run the actions allowed for the assigned role (because the privileges assigned to this role have the permissions to run specific actions on some resources).

X will use the public access without any role and will be only able to run actions allowed for the public access.​

note

The developer is free to implement an authentication for public users and to assign them a role. This case is not covered here.​

Actions

In this example, only the read action is considered, to simplify the story. However, the exposed principles are the same for other actions (create, update...) ​

Configuration target

We want to configure the following accesses:

Configuring registered users

Protecting all data

By default in new Qodly applications, no permissions are set up, which means that all data are available for any Qodly app registered user (Reminder: public endpoint is disabled by default).​ Thus, the initial configuration is:

The first step in activating safety is to protect all data by default. Accesses will then be opened for each resource.

1. Create a None privilege with a granted Read action on the Datastore​.

By the inheritance principles, the whole datastore is then protected.

2. Do never assign this privilege to any role, so that the whole datastore will always remain protected by default​.

Creating the viewPatient privilege

Doctor and Secretary roles can read patient's data.

1. Create the viewPatient privilege with a granted Read action on the Patients dataclass.​

2. Assign it to the Doctor and Secretary roles (see roles below).​

However, this privilege will give access to all patient data to the Secretary role, including by default any confidential. You still need to restrict access to this level of information.

Creating the viewConfidentialInfo privilege

Only the Doctor role can view the patient's confidential data (gathered in a confidentialInfo attribute).

1. Create the viewConfidentialInfo privilege with a granted Read action on the Patients.confidentialInfo attribute.​

2. Assign it to the Doctor role (see roles below). This will exclude all other roles). ​

Roles

Here are the corresponding role definitions.

Secretary

Doctor

Configuring public access

By default in new Qodly applications, the public access is disabled. The public access is the access granted for public users (like X) without any role.

1. Activate the Public access explicitely in the console.

2. Allow the guest privilege to read the appointments.

By default, all users, including public users have the guest privilege. By simply allowing the guest privilege to read appointments, we allow all users, registered and not registered, to read the appointments.

The final picture

Here is a complete overview of the roles and privileges for our HealthCare application: