Autorisation

L'autorisation définit ce que les utilisateurs peuvent et ne peuvent pas faire après leur authentification. Aptli combine deux niveaux indépendants : des droits d'administrateur permissifs (ce que vous pouvez faire) et des restrictions de rôle restrictives (ce que vous ne pouvez pas voir). Ensemble, ils offrent aux administrateurs un contrôle précis tant sur les capacités que sur la visibilité des données.

Présentation du modèle d'autorisation

Le modèle de sécurité complet d'Aptli comporte trois couches :

Authentification — Qui vous êtes (abordé dans la section Authentification)
Droits d'administrateur — Ce que vous POUVEZ modifier (autorisations permissives)
Restrictions de rôle — Ce que vous NE POUVEZ PAS voir (filtres restrictifs)

Toutes les restrictions sont appliquées au niveau du serveur — aucune donnée non autorisée n'est jamais envoyée à votre navigateur, quelles que soient vos tentatives via l'interface utilisateur, l'API ou les exportations.

Ce modèle offre une grande flexibilité tout en garantissant la sécurité.

Droits d'administrateur (permissifs)

Les droits d'administrateur accordent l'autorisation de modifier des informations ou de changer un statut. Sans ces droits, les utilisateurs peuvent uniquement consulter les données et modifier leur propre profil.

Droits d'administrateur courants :

usersUpdate - Modifier les profils des autres utilisateurs (nom, titre, division — PAS l'adresse e-mail/le mot de passe)
usersLogout - Forcer la déconnexion ou verrouiller définitivement les utilisateurs
usersDelete - Supprimer des comptes utilisateurs
usersCreate - Créer de nouveaux utilisateurs ou restaurer des comptes
pointsCreate, pointsUpdate, pointsDelete - Modifier les entités ponctuelles
workOrdersCreate, workOrdersUpdate, workOrdersDelete - Gérer les ordres de travail
assignmentsCreate - Créer des affectations de travail
reportsCreate - Soumettre des rapports de travail
transactionsCreate - Créer des transactions d'inventaire

Droits supérieurs (priment sur tous les autres) :

appSettingSchemasModify - Modifier les paramètres au niveau de l'application (domaines, délais d'expiration, sécurité)
adminRightsModify - Attribuer des droits d'administrateur à d'autres utilisateurs
viewDeleted - Afficher les enregistrements supprimés (presque universel, partiellement remplacé par les restrictions de rôle)

Vérification des droits d'administrateur d'un utilisateur :

Accédez à Admin → Utilisateurs
Ouvrez le profil de l'utilisateur
La section « Droits d'administrateur » répertorie toutes les autorisations accordées

Restrictions de rôle (restrictives)

Liste des rôles Page d'administration des rôles affichant les restrictions de rôle configurées

Les rôles sont des ensembles de restrictions qui empêchent la consultation et la modification d'enregistrements présentant certaines caractéristiques. L'appartenance à un rôle applique toutes les restrictions à cet utilisateur.

Composants des rôles :

Membres - Utilisateurs auxquels ces restrictions s'appliquent
Propriétaire - Utilisateur qui contrôle l'appartenance (ou utilisateurs disposant du droit d'administration rolesUpdate)
Restrictions de rôle - Filtres au niveau des champs masquant des données spécifiques

Structure des restrictions de rôle

Page de détails du rôle affichant la configuration des restrictions au niveau des champs

Chaque restriction définit :

Modèle - Quel type de données (points, polygones, affectations, etc.)
Champ - Quelle propriété filtrer (propriétaire, statut, catégorie, champs personnalisés)
Comparaison - Comment effectuer la correspondance (=, !=, >, <, contient, etc.)
Valeur de filtre - Quelle valeur faire correspondre
Autorisations - Ce qui est bloqué (lecture, modification, création, suppression)

Exemple d'utilisation : Séparation des sous-traitants

Scénario : Empêcher le sous-traitant A de voir le travail du sous-traitant B

Configuration :

Créer un rôle : « Sous-traitant A »
Ajouter une restriction de rôle :
- Modèle : Point (entités)
- Champ : propriétaire
- Comparaison : =
- Valeur de filtrage : Sous-traitant B
- Autorisations : Lecture ✓, Modification ✓, Création ✓, Suppression ✓ (toutes vraies = aucune de ces actions n'est possible)
Ajouter les utilisateurs du sous-traitant A en tant que membres

Résultat :

Les membres du sous-traitant A ne peuvent voir aucun point dont le propriétaire = « Sous-traitant B »
Pas seulement masqué dans l'interface utilisateur : l'API renvoie les données comme si les enregistrements n'existaient pas
Impossible de les voir accidentellement via une capture d'écran, un appel API ou une exportation
Entièrement appliqué côté serveur

Cas d'utilisation supplémentaires

Par étape de travail : Empêcher les travailleurs sur le terrain de voir les rapports de validation QC :

Role: "Field Workers"
Restriction:
  Model: Validation
  Field: status
  Comparison: !=
  Filter Value: "" (any value)
  Permissions: Read ✓

Les travailleurs sur le terrain ne peuvent voir aucune validation.

Par type d'actif : Séparer les équipes d'infrastructure (poteaux/conduits vs. équipements actifs) :

Role: "Civil Team"
Restriction:
  Model: Point
  Field: category
  Comparison: =
  Filter Value: "Active Equipment"
  Permissions: Read ✓, Edit ✓, Create ✓, Delete ✓

L'équipe des travaux publics ne peut ni voir ni modifier les points d'équipements actifs.

Par aspect physique/logique : Séparer l'accès aux données des bureaux (relations de capacité vs. emplacements des bureaux) :

Role: "Capacity Analysts"
Restriction:
  Model: Point
  Field: layer
  Comparison: =
  Filter Value: "Office Locations"
  Permissions: Edit ✓, Create ✓, Delete ✓

Les analystes peuvent consulter les bureaux mais ne peuvent pas modifier les emplacements (lecture seule).

Combinaison des droits d'administrateur et des restrictions de rôle

Comportement par défaut : Tous les utilisateurs peuvent tout voir mais ne peuvent rien modifier (sans droits d'administrateur).

Ajout d'un accès en écriture avec restrictions :

Exemple : Les travailleurs sur le terrain peuvent modifier leur propre travail mais pas celui des autres

Admin Rights:
  - reportsCreate: true
  - reportsUpdate: true

Role Restrictions:
  Model: Report
  Field: reportedBy
  Comparison: !=
  Filter Value: [current user ID]
  Permissions: Edit ✓

Résultat :

Les travailleurs peuvent créer des rapports (droit d'administrateur accordé)
Les employés peuvent modifier UNIQUEMENT leurs propres rapports (les restrictions de rôle filtrent les autres)
Impossible de voir ou de modifier les rapports des autres employés

Application côté serveur

Fonctionnement :

Toutes les requêtes sont filtrées avant que les données ne soient renvoyées
Les restrictions de rôle sont appliquées sur le serveur (pas seulement masquées dans l'interface utilisateur)
Les utilisateurs ne peuvent pas contourner ces restrictions via des appels API directs, des outils de navigateur ou des exportations
Les données n'existent tout simplement pas pour les utilisateurs non autorisés

Implications en matière de sécurité :

Une capture d'écran de l'écran d'une autre personne ne servira à rien (les données ne s'afficheront pas pour vous)
Impossible d'exporter des données restreintes (le serveur applique les filtres)
Impossible de « deviner » les identifiants d'enregistrement (filtrés avant la recherche d'identifiant)
Les enregistrements hors de votre champ d'autorisation sont renvoyés comme introuvables, même si vous connaissez l'identifiant

Gestion des rôles

Création de rôles :

Accédez à Admin → Rôles
Cliquez sur « Créer un rôle »
Saisissez le nom et la description du rôle
Ajoutez des membres (faites glisser les utilisateurs dans le champ des membres)
Ajoutez des restrictions de rôle (vous pouvez en avoir plusieurs)
Enregistrez

Modification des rôles :

Uniquement le propriétaire du rôle OU les utilisateurs disposant du droit d'administration rolesUpdate
Possibilité d'ajouter/supprimer des membres
Possibilité de modifier les restrictions
Possibilité de supprimer le rôle (libère les membres des restrictions)

Appartenance à un rôle :

Les utilisateurs peuvent occuper plusieurs rôles (restrictions combinées)
Départ de l'organisation : retirer de tous les rôles avant de supprimer le compte
Appartenance groupée : faire glisser plusieurs utilisateurs à la fois

Personnalisation de l'autorisation pour les nouveaux utilisateurs

Configuration des paramètres de l'application (nécessite appSettingSchemasModify) :

Accédez à Paramètres de l'application → Authentification
« Rôles pour les nouveaux utilisateurs » - Attribuer automatiquement des rôles aux nouveaux comptes
« Droits d'administrateur pour les nouveaux utilisateurs » - Autorisations par défaut accordées
Enregistrer

Configurations types :

Paramètres par défaut pour les travailleurs de terrain :

Roles: ["Field Workers"]
Admin Rights: {
  reportsCreate: true,
  assignmentsRead: true
}

Paramètres par défaut pour les coordinateurs administratifs :

Roles: []
Admin Rights: {
  assignmentsCreate: true,
  ordersCreate: true,
  stockItemsView: true
}

Pas d'attribution automatique (vérification manuelle) :

Roles: []
Admin Rights: {} (none)

Les administrateurs attribuent manuellement les droits après vérification du compte.

Affichage des autorisations effectives

Pour un utilisateur spécifique :

Accédez au profil de l'utilisateur
Section « Droits d'administrateur » - Ce qu'il PEUT faire
Section « Rôles » - Ce qu'il NE PEUT PAS voir (via les restrictions)
La vue combinée affiche les autorisations effectives

Test des autorisations :

Connectez-vous en tant qu'utilisateur (ou usurpez son identité avec des droits d'administrateur)
Naviguez normalement
Les données restreintes n'apparaissent tout simplement pas
Les actions nécessitant des droits d'administrateur sont désactivées/masquées

Bonnes pratiques

Commencez par des restrictions, accordez les droits au fur et à mesure :

Les nouveaux utilisateurs reçoivent des autorisations minimales
Ajoutez des droits d'administrateur en fonction des rôles
Il est plus facile d'accorder des droits que de les révoquer (évite la « dérive des autorisations »)

Utilisez les rôles pour la visibilité des données :

Séparez les sous-traitants (pour empêcher l'espionnage concurrentiel)
Séparez les étapes de travail (contrôle qualité et personnel de terrain)
Séparez les types d'actifs (infrastructure et équipement en service)

Utilisez les droits d'administrateur pour les capacités :

Qui peut créer des affectations
Qui peut modifier l'inventaire
Qui peut accorder des autorisations

Documentez l'objectif du rôle :

Nom de rôle clair (« Sous-traitant A » vaut mieux que « Rôle 1 »)
La description explique les restrictions
Aide les futurs administrateurs à comprendre l'intention

Audits réguliers des autorisations :

Révision trimestrielle des droits d'administration des utilisateurs
Supprimer les droits inutilisés (changement de rôle de l'utilisateur)
Vérifier l'appartenance aux rôles (utilisateurs ayant quitté l'organisation)

Surveiller les tentatives d'accès :

Enregistrer les tentatives d'autorisation échouées
Une série de refus indique qu'un utilisateur tente un accès non autorisé
Enquêter et ajuster les autorisations ou former l'utilisateur

Principe du moindre privilège :

Accorder les autorisations minimales requises pour la fonction
Accès temporairement élevé pour les projets (à supprimer après)
Super-droits (adminRightsModify) réservés aux administrateurs de confiance