Aller au contenu principal

Contrôle d'Accès Basé sur les Rôles

Rôles, Permissions et Utilisateurs dans OmniCRM​

OmniCRM utilise le contrôle d'accès basé sur les rôles (RBAC) : les personnes (Utilisateurs) se voient attribuer un ou plusieurs Rôles, et chaque Rôle est un ensemble de Permissions. Les Permissions sont la plus petite unité d'accès (par exemple, view_customer, create_inventory). L'accès effectif d'un utilisateur est l'union des permissions de tous les rôles attribués.

Objectif​

Le RBAC permet :

  1. Protection des Données --- Les utilisateurs ne voient et ne font que ce qu'ils sont autorisés à faire.
  2. Adaptation Opérationnelle --- Les rôles reflètent les fonctions de travail (Admin, Support, Finance, Administrateur Client).
  3. Administration Simple --- Accorder l'accès en attribuant des rôles ; éviter la microgestion par utilisateur.
  4. Isolation des Locataires --- Les permissions "voir ses propres ..." limitent la visibilité aux données client/locataire propres à un utilisateur.

Permissions RBAC

Comment les Utilisateurs, Rôles et Permissions S'Intègrent​

  • Utilisateurs --- Personnes réelles qui se connectent à OmniCRM.
  • Permissions --- Capacités atomiques (par exemple, view_customer, delete_product).
  • Rôles --- Ensembles nommés de permissions (par exemple, Admin, Support, Finance).
  • Attribution --- Les utilisateurs reçoivent un ou plusieurs rôles ; les permissions s'agrègent.

Permissions RBAC

L'authentification prouve qui vous êtes (JWT, clé API ou IP sur liste blanche). L'autorisation (rôles/permissions) décide ce que vous pouvez faire.

Gestion des Utilisateurs​

Le système de gestion des utilisateurs d'OmniCRM permet aux administrateurs de créer et de gérer des utilisateurs (administrateurs, agents de service client), de visualiser et de modifier les rôles des utilisateurs, de réinitialiser les mots de passe, de gérer l'authentification à deux facteurs et de contrôler l'accès des utilisateurs.

Types d'Utilisateurs​

Utilisateurs Clients - Créés via auto-inscription ou par des administrateurs. Attribués automatiquement le rôle "Client". Ces utilisateurs accèdent au portail d'auto-assistance pour gérer leurs services, visualiser leur utilisation, payer des factures, etc.

Utilisateurs du Personnel - Créés par des administrateurs avec les permissions appropriées. Peuvent se voir attribuer des rôles comme Admin, Support, Finance, etc. Ces utilisateurs accèdent à l'interface CRM pour gérer les clients, provisionner des services, gérer la facturation, etc.

Utilisateurs Administrateurs - Utilisateurs avec la permission admin. Ont un accès complet au système, y compris la gestion des utilisateurs, la gestion des rôles et tous les points de terminaison protégés.

L'utilisateur administratif initial est créé par l'équipe Omnitouch lors du déploiement du système.

Ajout de Nouveaux Utilisateurs (Administrateurs et CSA)​

Les administrateurs peuvent créer de nouveaux utilisateurs du personnel via l'interface Web ou l'API.

Via l'Interface Web​

  1. Naviguer vers Utilisateurs & Rôles - Accéder à l'interface de gestion des utilisateurs depuis le menu d'administration
  2. Cliquer sur "Ajouter un Utilisateur" - Ouvre le formulaire de création d'utilisateur

Ajout d'un Utilisateur

  1. Remplir les Détails de l'Utilisateur :
    • Nom d'utilisateur - Nom d'utilisateur unique pour la connexion (obligatoire)
    • Email - Adresse email de l'utilisateur (obligatoire, doit être unique)
    • Mot de passe - Mot de passe temporaire (obligatoire, l'utilisateur doit le changer lors de la première connexion)
    • Prénom - Prénom de l'utilisateur (obligatoire)
    • Deuxième prénom - Deuxième prénom de l'utilisateur (optionnel)
    • Nom de famille - Nom de famille de l'utilisateur (obligatoire)
    • Numéro de téléphone - Numéro de téléphone de contact (optionnel)
    • Rôle - Sélectionner un ou plusieurs rôles à attribuer (obligatoire)
    • Contact Client - Lier optionnellement l'utilisateur à un enregistrement de contact client (pour les utilisateurs clients)
  2. Cliquer sur "Créer Utilisateur" - L'utilisateur est créé et peut immédiatement se connecter avec les identifiants fournis
  3. L'utilisateur reçoit une notification - Envoyer optionnellement un email de bienvenue avec des instructions de connexion

Meilleures Pratiques :

  • Utiliser un mot de passe temporaire comme TempP@ssw0rd! et exiger que l'utilisateur le change lors de la première connexion
  • Attribuer des rôles appropriés en fonction de la fonction de travail (voir les Conceptions de Rôles Typiques ci-dessous)
  • Activer la 2FA pour tout le personnel administratif et de support
  • Lier les utilisateurs clients à leur enregistrement de contact client pour un bon cadrage des données

Via l'API​

Créer un utilisateur par programmation :

Point de terminaison : POST /auth/users

Permission Requise : admin

Corps de la Requête :

{
  "username": "john.smith",
  "email": "john.smith@company.com",
  "password": "TempP@ssw0rd!",
  "first_name": "John",
  "middle_name": "D",
  "last_name": "Smith",
  "phone_number": "+61412345678",
  "role": "Support"
}

Réponse :

{
  "id": 123,
  "username": "john.smith",
  "email": "john.smith@company.com",
  "first_name": "John",
  "last_name": "Smith",
  "roles": ["Support"],
  "created": "2025-01-04T10:30:00Z"
}

Attribution de Plusieurs Rôles :

Les utilisateurs peuvent avoir plusieurs rôles. Les permissions sont additives (union de toutes les permissions de rôle attribuées).

Pour attribuer plusieurs rôles, incluez-les dans la requête :

{
  "username": "jane.doe",
  "email": "jane.doe@company.com",
  "password": "TempP@ssw0rd!",
  "first_name": "Jane",
  "last_name": "Doe",
  "role": "Support,Finance"
}

Ou utilisez le point de terminaison d'attribution de rôle après la création de l'utilisateur :

POST /auth/roles/{role_id}/users/{user_id}

Visualiser et Rechercher des Utilisateurs​

Lister Tous les Utilisateurs (Admin) :

GET /auth/users

Renvoie une liste paginée de tous les utilisateurs avec leurs rôles et informations de base.

Rechercher des Utilisateurs :

GET /auth/users/search?search={query}&filters={"role":["Support"]}&page=1&per_page=50

Filtrer par :

  • Nom de rôle
  • Domaine email
  • Statut actif/supprimé
  • Statut 2FA activé
  • Date de dernière connexion

Obtenir un Utilisateur Spécifique :

GET /auth/users/{user_id}

Renvoie les détails complets de l'utilisateur, y compris :

  • Informations personnelles
  • Rôles attribués et permissions effectives
  • Statut 2FA
  • Dernière connexion et informations de session
  • Contact client lié (le cas échéant)

Création et Gestion des Rôles​

Les rôles sont des collections de permissions qui peuvent être attribuées aux utilisateurs. Au lieu d'attribuer des permissions individuellement à chaque utilisateur, vous créez des rôles qui regroupent des permissions connexes et attribuez ces rôles aux utilisateurs.

Création d'un Nouveau Rôle​

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Rôles
  2. Cliquer sur "Créer un Rôle"
  3. Entrer les détails du rôle :
    • Nom - Nom court et descriptif (par exemple, "Tier2_Support")
    • Description - Expliquer le but et les responsabilités du rôle
  4. Cliquer sur "Créer"
  5. Le rôle est créé sans permissions ; ajoutez des permissions à l'étape suivante

Via l'API :

Point de terminaison : POST /auth/roles

Permission Requise : admin

Requête :

{
  "name": "Tier2_Support",
  "description": "Équipe de support de niveau 2 avec accès de provisioning élevé"
}

Réponse :

{
  "id": 45,
  "name": "Tier2_Support",
  "description": "Équipe de support de niveau 2 avec accès de provisioning élevé",
  "permissions": [],
  "users": []
}

Ajout de Permissions à un Rôle​

Une fois qu'un rôle est créé, attribuez des permissions pour définir ce que les utilisateurs avec ce rôle peuvent faire.

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Rôles
  2. Cliquer sur le nom du rôle pour voir les détails
  3. Dans la section Permissions, cliquer sur "Ajouter une Permission"
  4. Sélectionner une ou plusieurs permissions dans la liste
  5. Cliquer sur "Ajouter" - Les permissions sont immédiatement attribuées

Gestion des Permissions de Rôle

Attribution de Permissions au Rôle

Via l'API :

Point de terminaison : POST /auth/roles/{role_id}/permissions

Requête :

{
  "permission_id": 123
}

Ou ajouter plusieurs permissions :

{
  "permission_ids": [123, 124, 125]
}

Exemple : Création d'un Rôle "Spécialiste du Provisioning"

Ce rôle peut voir les clients, gérer les services et provisionner :

  1. Créer le rôle :

    POST /auth/roles
    {
      "name": "Provisioning_Specialist",
      "description": "Peut provisionner des services et gérer les services client"
    }

  2. Ajouter des permissions :

    POST /auth/roles/45/permissions
    {
      "permission_ids": [
        1,   # view_customer
        20,  # view_customer_service
        21,  # create_customer_service
        22,  # update_customer_service
        30,  # view_provision
        31,  # create_provision
        40,  # view_inventory
        50,  # view_product
      ]
    }

Suppression de Permissions d'un Rôle​

Via l'Interface Web :

  1. Naviguer vers les détails du rôle
  2. Dans la liste Permissions, cliquer sur le bouton "X" ou "Supprimer" à côté de la permission
  3. Confirmer la suppression

Via l'API :

Point de terminaison : DELETE /auth/roles/{role_id}/permissions/{permission_id}

Exemple :

DELETE /auth/roles/45/permissions/31

Cela supprime la permission create_provision du rôle.

Édition des Détails du Rôle​

Mettre à jour le nom ou la description du rôle :

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Rôles
  2. Cliquer sur le rôle à modifier
  3. Modifier le nom ou la description du rôle
  4. Cliquer sur "Enregistrer"

Édition des Détails du Rôle

Via l'API :

Point de terminaison : PUT /auth/roles/{role_id}

{
  "name": "Senior_Support",
  "description": "Équipe de support senior avec accès complet aux clients"
}

Suppression d'un Rôle​

Avertissement : La suppression d'un rôle le retire de tous les utilisateurs auxquels il a été attribué. Assurez-vous que les utilisateurs ont des rôles alternatifs ou ils perdront l'accès.

Via l'API :

DELETE /auth/roles/{role_id}

Meilleure Pratique : Au lieu de supprimer, envisagez d'archiver ou de renommer les rôles qui ne sont plus nécessaires.

Attribution de Rôles aux Utilisateurs​

Lors de la Création d'un Utilisateur :

Incluez le rôle dans la requête de création d'utilisateur (voir "Ajout de Nouveaux Utilisateurs" ci-dessus).

Pour les Utilisateurs Existants :

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Utilisateurs
  2. Cliquer sur l'utilisateur à modifier
  3. Dans la section Rôles, sélectionner/désélectionner les rôles
  4. Cliquer sur "Enregistrer"

Édition des Rôles d'Utilisateur

Via l'API :

Mettre à jour les rôles de l'utilisateur :

Point de terminaison : PUT /auth/users/{user_id}

{
  "role": "Support,Finance"
}

Ou attribuer un seul rôle à un utilisateur via le point de terminaison de rôle :

Point de terminaison : POST /auth/roles/{role_id}/users/{user_id}

Visualiser les Attributions de Rôle​

Tous les utilisateurs dans un rôle :

GET /auth/roles/{role_id}/users

Renvoie la liste de tous les utilisateurs attribués à ce rôle.

Tous les rôles pour un utilisateur :

GET /auth/users/{user_id}

La réponse inclut un tableau roles avec tous les rôles attribués.

Gestion des Mots de Passe des Utilisateurs​

OmniCRM fournit plusieurs méthodes pour la gestion des mots de passe en fonction du contexte.

Réinitialisation de Mot de Passe en Libre-Service par l'Utilisateur​

Les utilisateurs qui ont oublié leur mot de passe peuvent le réinitialiser eux-mêmes via la page de connexion :

  1. Cliquer sur "Mot de passe oublié" sur la page de connexion
  2. Entrer l'adresse email - Le système envoie un email de réinitialisation de mot de passe
  3. Vérifier l'email - L'email contient un lien de réinitialisation sécurisé avec un token (valide pendant 1 heure)
  4. Cliquer sur le lien - Ouvre le formulaire de réinitialisation de mot de passe
  5. Entrer un nouveau mot de passe - Doit répondre aux exigences de complexité du mot de passe :
    • Minimum 8 caractères
    • Au moins une lettre majuscule
    • Au moins une lettre minuscule
    • Au moins un chiffre
    • Au moins un caractère spécial
  6. Soumettre - Le mot de passe est immédiatement mis à jour ; l'utilisateur peut se connecter avec le nouveau mot de passe

Flux API :

  1. Demander la réinitialisation :

    Point de terminaison : POST /auth/forgot_password

    {
      "email": "user@example.com"
    }

    Le système génère un token de réinitialisation et envoie un email.

  2. Réinitialiser avec le token :

    Point de terminaison : POST /auth/reset_password

    {
      "token": "abc123...",
      "new_password": "NewSecureP@ssw0rd!"
    }

Réinitialisation de Mot de Passe par l'Administrateur​

Les administrateurs peuvent réinitialiser le mot de passe d'un utilisateur sans nécessiter de vérification par email. Cela définit un mot de passe temporaire que l'utilisateur doit changer lors de la prochaine connexion.

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Utilisateurs
  2. Trouver l'utilisateur et cliquer sur le bouton "Réinitialiser le Mot de Passe"
  3. Entrer un mot de passe temporaire
  4. Cliquer sur "Réinitialiser"
  5. Informer l'utilisateur de son mot de passe temporaire (via un canal sécurisé)
  6. L'utilisateur doit changer le mot de passe lors de la prochaine connexion

Via l'API :

Point de terminaison : POST /auth/users/{user_id}/admin_reset_password

Permission Requise : admin

Requête :

{
  "new_password": "TempP@ssw0rd!",
  "force_change": true
}

Paramètres :

  • new_password - Mot de passe temporaire à définir
  • force_change (optionnel) - Si vrai, l'utilisateur doit changer le mot de passe lors de la prochaine connexion

Changement de Mot de Passe par l'Utilisateur​

Les utilisateurs authentifiés peuvent changer leur propre mot de passe depuis leur profil :

Point de terminaison : POST /auth/change_password

Requête :

{
  "current_password": "OldP@ssw0rd!",
  "new_password": "NewSecureP@ssw0rd!"
}

Le système valide le mot de passe actuel avant de permettre le changement.

Sécurité des Mots de Passe​

  • Les mots de passe sont hachés en utilisant bcrypt (sécurité werkzeug)
  • Jamais stockés en texte clair
  • Les tokens de réinitialisation expirent après 1 heure
  • Les tentatives de connexion échouées peuvent déclencher un verrouillage de compte (configurable)
  • Le suivi de l'historique des mots de passe empêche la réutilisation (configurable)
  • Exigences de complexité appliquées

Gestion de l'Authentification à Deux Facteurs (2FA)​

OmniCRM prend en charge l'authentification à deux facteurs basée sur TOTP pour une sécurité renforcée. Les administrateurs peuvent activer, désactiver et réinitialiser la 2FA pour les utilisateurs.

Popup de nag de 2FA d'OmniCRM montré aux utilisateurs administrateurs

Activation de la 2FA pour un Utilisateur​

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Utilisateurs
  2. Cliquer sur l'utilisateur pour voir les détails
  3. Dans la section Sécurité, cliquer sur "Activer 2FA"
  4. Le système génère :
    • Secret TOTP (QR code affiché)
    • 10 codes de sauvegarde (usage unique)
  5. L'utilisateur scanne le QR code avec l'application d'authentification (Google Authenticator, Authy, etc.)
  6. L'utilisateur entre le code de vérification de l'application pour confirmer la configuration
  7. L'utilisateur sauvegarde les codes de sauvegarde dans un endroit sécurisé
  8. La 2FA est maintenant activée ; requise pour toutes les connexions futures

Page d'inscription 2FA d'OmniCRM

Via l'API :

  1. Générer le secret TOTP :

    Point de terminaison : POST /2fa/enable/user/{user_id}

    Réponse :

    {
      "totp_secret": "JBSWY3DPEHPK3PXP",
      "qr_code_url": "otpauth://totp/OmniCRM:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=OmniCRM",
      "backup_codes": [
        "12345678",
        "23456789",
        "34567890",
        ...
      ]
    }

  2. Vérifier la configuration :

    Point de terminaison : POST /2fa/verify-setup/user/{user_id}

    {
      "code": "123456"
    }

    Renvoie {"verified": true} en cas de succès.

Flux de Connexion 2FA​

Une fois la 2FA activée, le processus de connexion change :

  1. L'utilisateur entre son nom d'utilisateur et son mot de passe
  2. Le système valide les identifiants
  3. Si valide, demande le code 2FA
  4. L'utilisateur entre le code de l'application d'authentification OU le code de sauvegarde
  5. Le système vérifie le code
  6. En cas de succès, l'utilisateur est connecté

Connexion 2FA d'OmniCRM

Codes de Sauvegarde :

  • 10 codes générés lors de la configuration de la 2FA
  • Usage unique seulement (consommés après utilisation)
  • Utilisés si l'application d'authentification n'est pas disponible
  • Peuvent être régénérés par l'utilisateur ou l'administrateur

Vérification du Code 2FA​

Point de terminaison : POST /2fa/verify/user/{user_id}

{
  "code": "123456"
}

Accepte les deux :

  • Code TOTP (6 chiffres de l'application d'authentification)
  • Code de sauvegarde (8 chiffres de la liste de codes de sauvegarde)

Régénération des Codes de Sauvegarde​

Si un utilisateur épuise les codes de sauvegarde ou les perd, générez-en de nouveaux :

Via l'Interface Web :

  1. Naviguer vers les détails de l'utilisateur
  2. Cliquer sur "Régénérer les Codes de Sauvegarde"
  3. Afficher ou envoyer de nouveaux codes à l'utilisateur
  4. Les anciens codes sont invalidés

Via l'API :

Point de terminaison : POST /2fa/backup-codes/regenerate/user/{user_id}

Réponse :

{
  "backup_codes": [
    "98765432",
    "87654321",
    "76543210",
    ...
  ]
}

Réinitialisation 2FA par l'Administrateur​

Si un utilisateur perd l'accès à son application d'authentification et à tous les codes de sauvegarde, un administrateur peut désactiver et réactiver la 2FA.

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Utilisateurs
  2. Cliquer sur l'utilisateur
  3. Cliquer sur le bouton "Réinitialiser 2FA"
  4. Confirmer la réinitialisation
  5. La 2FA est désactivée ; l'utilisateur peut se connecter uniquement avec le mot de passe
  6. Guider l'utilisateur pour configurer à nouveau la 2FA avec un nouveau secret

Réinitialisation 2FA d'OmniCRM

Via l'API :

Point de terminaison : POST /2fa/admin/disable/user/{user_id}

Permission Requise : admin

Cela désactive complètement la 2FA pour l'utilisateur :

  • Secret TOTP effacé
  • Codes de sauvegarde effacés
  • Drapeau is_2fa_enabled défini sur faux

L'utilisateur peut ensuite réactiver la 2FA pour obtenir un nouveau secret et de nouveaux codes de sauvegarde.

Réinitialisation de 2FA en Libre-Service par l'Utilisateur (Nouvel Appareil)​

Si un utilisateur obtient un nouvel appareil mais a toujours accès aux codes de sauvegarde :

Point de terminaison : POST /2fa/reset-for-new-device/user/{user_id}

{
  "backup_code": "12345678"
}

Le système valide le code de sauvegarde, puis génère un nouveau secret TOTP et de nouveaux codes de sauvegarde. L'utilisateur peut configurer l'application d'authentification sur le nouvel appareil.

Meilleures Pratiques pour la 2FA​

  • Exiger la 2FA pour tout le personnel administratif et de support
  • Stocker les codes de sauvegarde en toute sécurité (gestionnaire de mots de passe ou note sécurisée)
  • Régénérer les codes de sauvegarde après en avoir utilisé plusieurs
  • Utiliser des applications d'authentification réputées (Google Authenticator, Authy, Microsoft Authenticator)
  • Documenter les procédures de réinitialisation de la 2FA pour le personnel de support
  • Auditer l'utilisation de la 2FA - surveiller quels utilisateurs ont la 2FA activée

Mise à Jour des Informations Utilisateur​

Les administrateurs peuvent mettre à jour les détails des utilisateurs à tout moment.

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Utilisateurs
  2. Cliquer sur l'utilisateur à modifier
  3. Modifier tous les champs modifiables :
    • Prénom, deuxième prénom, nom de famille
    • Adresse email (nécessite une vérification)
    • Numéro de téléphone
    • Rôles
    • Lien de contact client
  4. Cliquer sur "Enregistrer"

Via l'API :

Point de terminaison : PUT /auth/users/{user_id}

{
  "first_name": "Jane",
  "last_name": "Doe-Smith",
  "email": "jane.doesmith@newcompany.com",
  "phone_number": "+61498765432",
  "role": "Support,Finance"
}

Changements d'Email :

Lorsque l'email est changé, le nouvel email est marqué comme en attente jusqu'à vérification :

  • Le champ pending_email stocke le nouvel email
  • Un email de vérification est envoyé à la nouvelle adresse
  • L'utilisateur clique sur le lien pour vérifier
  • Le champ email est mis à jour avec la nouvelle valeur
  • Le drapeau email_verified est défini sur vrai

Suppression des Utilisateurs​

OmniCRM utilise des suppressions douces pour les utilisateurs - ils sont marqués comme supprimés mais ne sont pas retirés de la base de données. Cela préserve les pistes d'audit et les données historiques.

Suppression d'un Utilisateur​

Via l'Interface Web :

  1. Naviguer vers Utilisateurs & Rôles → Onglet Utilisateurs
  2. Trouver l'utilisateur à supprimer
  3. Cliquer sur le bouton "Supprimer"
  4. Confirmer la suppression
  5. L'utilisateur est immédiatement déconnecté et ne peut plus se connecter

Via l'API :

Point de terminaison : DELETE /auth/users/{user_id}

Permission Requise : admin

Ce Qui Se Passe :

  • Le drapeau deleted est défini sur True
  • L'horodatage deleted_at est enregistré
  • L'utilisateur ne peut pas se connecter
  • Toutes les sessions actives sont invalidées
  • L'utilisateur apparaît toujours dans les journaux d'audit et les enregistrements historiques
  • Les données liées (contacts clients, activités) sont préservées

Visualiser les Utilisateurs Supprimés​

Filtrer pour les utilisateurs supprimés :

GET /auth/users/search?filters={"deleted":[true]}

Restaurer un Utilisateur Supprimé​

Si un utilisateur a été supprimé par erreur, les administrateurs peuvent le restaurer :

Point de terminaison : PUT /auth/users/{user_id}

{
  "deleted": false
}

Cela efface le drapeau deleted et permet à l'utilisateur de se reconnecter.

Remarque : Le mot de passe de l'utilisateur reste inchangé, donc il peut utiliser son mot de passe précédent.

Suppression Permanente d'un Utilisateur​

Avertissement : Ceci est irréversible et supprime toutes les données de l'utilisateur de la base de données.

Non exposé via l'UI. Disponible uniquement par accès direct à la base de données pour des raisons de conformité (par exemple, demandes de suppression de données GDPR).

Meilleures Pratiques pour la Suppression d'Utilisateurs​

  • Suppression douce par défaut - Préserve les pistes d'audit
  • Documenter les raisons de la suppression - Ajouter une note dans le journal d'activité avant de supprimer
  • Transférer la propriété - Réaffecter les tickets ouverts et les tâches de l'utilisateur avant de supprimer
  • Réviser l'accès - S'assurer qu'aucun processus critique ne dépend de l'utilisateur
  • Archiver les données - Exporter l'historique de travail de l'utilisateur si nécessaire
  • Notifier les équipes concernées - Informer les responsables/collègues de la suppression

Catalogue des Permissions​

Les permissions suivent généralement des modèles CRUD :

  • view\_\* --- lire/parcourir
  • create\_\* --- créer/ajouter
  • update\_\* --- éditer/modifier
  • delete\_\* --- supprimer/enlever

Certaines entités incluent également des variantes "voir ses propres ..." qui restreignent la visibilité aux données associées au propre client/locataire de l'utilisateur.

Permissions RBAC

Global / Administratif​

  • admin --- Accès administratif complet (gérer les utilisateurs, rôles et permissions ; accéder à tous les points de terminaison protégés).
  • can_impersonate --- Agir temporairement en tant qu'un autre utilisateur (audité ; pour support/dépannage).

Clients & Enregistrements Associés​

  • Client
    • view_customer, create_customer, update_customer, delete_customer
    • Portée propre : voir son propre client
  • Site Client
    • view_customer_site, create_customer_site, update_customer_site, delete_customer_site
    • Portée propre : voir son propre site client
  • Contact Client
    • view_customer_contact, create_customer_contact, update_customer_contact, delete_customer_contact
    • Portée propre : voir son propre contact client
  • Attribut Client (voir Attributs Client)
    • view_customer_attribute, create_customer_attribute, update_customer_attribute, delete_customer_attribute
    • Portée propre : voir son propre attribut client
  • Tag Client (voir Tags Client)
    • view_customer_tag, create_customer_tag, update_customer_tag, delete_customer_tag
    • Portée propre : voir son propre tag client
  • Service Client
    • view_customer_service, create_customer_service, update_customer_service, delete_customer_service
    • Portée propre : voir son propre service client
  • Activité Client
    • view_customer_activity, create_customer_activity, update_customer_activity, delete_customer_activity
    • Portée propre : voir sa propre activité client

Facturation​

  • Carte Stripe
    • view_customer_stripe_card, create_customer_stripe_card, update_customer_stripe_card, delete_customer_stripe_card
    • Portée propre : voir sa propre carte stripe client
  • Transactions
    • view_customer_transaction, create_customer_transaction, update_customer_transaction, delete_customer_transaction
    • Portée propre : voir sa propre transaction client
  • Factures
    • view_customer_invoice, create_customer_invoice, update_customer_invoice, delete_customer_invoice
    • Portée propre : voir sa propre facture client

Communications​

  • view_communication, create_communication, update_communication, delete_communication
  • Portée propre : voir sa propre communication

Inventaire & Modèles​

  • Inventaire
    • view_inventory, create_inventory, update_inventory, delete_inventory
    • Portée propre : voir son propre inventaire
  • Modèle d'Inventaire
    • view_inventory_template, create_inventory_template, update_inventory_template, delete_inventory_template
    • Portée propre : voir son propre modèle d'inventaire

Produits​

  • view_product, create_product, update_product, delete_product

Diffusion de Cellules (CBC)​

  • view_cbc_message, create_cbc_message, update_cbc_message, delete_cbc_message

Provisioning​

  • Provisionner
    • view_provision, create_provision, update_provision, delete_provision
    • Portée propre : voir son propre provisionnement
  • Événement de Provisioning
    • view_provision_event, create_provision_event, update_provision_event, delete_provision_event

Accès "Voir Ses Propres"​

Les permissions "voir ses propres ..." restreignent les lectures (et éventuellement les modifications, où cela est implémenté) aux données associées au propre client/locataire de l'utilisateur. Par exemple, un rôle Administrateur Client peut gérer les contacts, sites, factures et services de son locataire, mais ne peut pas voir d'autres locataires.

Conceptions de Rôles Typiques​

Rôle Permissions Typiques Remarques

Administrateur Système admin, optionnellement can_impersonate ; plus un large CRUD selon les besoins Contrôle total sur les utilisateurs/rôles/permissions Support view_customer, view_customer_service, view_communication, view_provision ; mises à jour optionnelles Ajouter can_impersonate si permis Finance view_customer_invoice, view_customer_transaction, view_product ; optionnel create_customer_invoice Fortement orienté lecture ; écriture limitée Administrateur Client (locataire) "voir ses propres ..." à travers clients, sites, contacts, services, inventaire, factures, transactions, communications, provisioning Gestion à portée de locataire Auditeur en Lecture Seule Large view_* uniquement Pas de création/mise à jour/suppression

: Exemples de Rôles et Permissions Incluses (résumé)

Gestion des Rôles & Permissions via l'API​

Tous les points de terminaison nécessitent la permission admin.

Lister les permissions​

Point de terminaison : GET /auth/permissions

Créer une permission (rare)​

Point de terminaison : POST /auth/permissions

Corps de la Requête :

{
    "name": "view_example",
    "description": "Accès en lecture seule aux objets d'exemple"
}

Lister les rôles​

Point de terminaison : GET /auth/roles

Créer un rôle​

Point de terminaison : POST /auth/roles

Corps de la Requête :

{
"name": "Support",
"description": "Équipe de support de niveau 1"
}

Ajouter une permission à un rôle​

Point de terminaison : POST /auth/roles/{role_id}/permissions

Corps de la Requête :

{
  "permission_id": 123
}

Supprimer une permission d'un rôle​

Point de terminaison : DELETE /auth/roles/{role_id}/permissions/{permission_id}

Attribution de Rôles aux Utilisateurs​

Créer un utilisateur avec un rôle​

Point de terminaison : POST /auth/users

Corps de la Requête :

{
  "username": "sara",
  "email": "sara@example.com",
  "password": "TempP@ssw0rd!",
  "first_name": "Sara",
  "last_name": "Ng",
  "phone_number": "+61...",
  "role": "Support"
}

Mettre à jour le rôle d'un utilisateur​

Point de terminaison : PUT /auth/users/{user_id}

Corps de la Requête :

{
  "role": "Finance"
}

Lister les utilisateurs (Admin uniquement)​

Point de terminaison : GET /auth/users

Usurpation d'Identité (Contrôlée)​

  • Requis : can_impersonate ou admin

Commencer l'usurpation d'identité​

Point de terminaison : POST /auth/impersonate

Corps de la Requête :

{ "user_id": 42 }

Arrêter l'usurpation d'identité​

Point de terminaison : POST /auth/stop_impersonation

Meilleures Pratiques​

  • Moins de privilèges d'abord. Commencez avec des rôles minimaux ; ajoutez des permissions selon les besoins.
  • Préférer "voir ses propres ...". Utilisez des permissions à portée de locataire pour les rôles orientés client.
  • Maintenir des rôles stables. Mettez à jour les permissions de rôle lorsque les fonctionnalités changent---ne modifiez pas chaque utilisateur.
  • Auditer régulièrement. Révisez qui a admin ou can_impersonate.

FAQ​

Un utilisateur peut-il avoir plusieurs rôles ? Oui. Les permissions sont additives.

Ai-je besoin de permissions personnalisées ? Généralement non. Le catalogue intégré couvre la plupart des besoins.

Comment les règles "voir ses propres ..." savent-elles ce qui est à moi ? Elles évaluent le lien entre votre utilisateur/contact et votre client (locataire).