Organisation, entités et permissions | Documentation Conformitly

L’organisation vient du jeton

Chaque utilisateur appartient à une organisation. L’API la lit dans la revendication org_id du jeton d’accès et filtre toutes les données en conséquence. Il n’existe aucun en-tête pour choisir une organisation ou une entité (pas de X-Organization-Id, par exemple) : un jeton donne accès aux données d’une seule organisation.

L’entité vient du chemin

L’organisation est découpée en entités (siège, filiales, succursales, divisions). Les ressources opérationnelles appartiennent à une entité et sont exposées sous /api/v1/entities/{entityId}/… : contrôles, risques, études EBIOS RM, incidents, actifs, fournisseurs, politiques, RGPD, tâches, automatisations, rapports, tableau de bord.

Un utilisateur a au plus un rôle par entité, et des rôles différents selon les entités. Les droits se vérifient ainsi :

Chemin avec {entityId} : il faut un rôle sur cette entité précise, et ce rôle doit accorder la permission demandée. Il n’y a pas d’héritage : un administrateur du siège n’a pas accès à une filiale s’il n’y détient pas lui-même un rôle. (À la création d’une entité, son créateur et les administrateurs de l’entité parente en deviennent automatiquement administrateurs.)
Chemin sans {entityId} (organisation, utilisateurs, invitations, journal d’audit, référentiels personnalisés, modèles…) : il suffit que l’un des rôles de l’utilisateur, sur n’importe quelle entité de l’organisation du jeton, accorde la permission. Exception : l’attribution, la modification et le retrait d’un rôle (/api/v1/users/{userId}/roles/{entityId}) exigent la permission sur l’entité visée.

Seuls comptent les rôles détenus sur les entités de l’organisation du jeton (org_id). Un rôle que le compte détiendrait dans une autre organisation n’ouvre rien, ni sur ses entités ni dans l’organisation du jeton. Les rôles sur une entité archivée restent valables sur cette entité.

Les rôles sont lus en base à chaque requête, pas dans le jeton : un rôle attribué ou retiré prend effet sans renouveler le jeton, au plus tard 5 secondes après le changement (immédiatement sur l’instance qui l’a enregistré). La revendication roles du jeton n’est qu’un instantané, utile à l’affichage.

Un paramètre de requête entityId (sur le journal d’audit ou la liste des utilisateurs, par exemple) sert de filtre, pas de contrôle d’accès.

Rôles et permissions

Les quatre rôles et les permissions qu’ils accordent, tels que définis dans le code :

Ressource	Administrateur (`admin`)	RSSI (`rssi`)	Contributeur (`contributor`)	Auditeur (`auditor`)
Organisation	lecture, modification	lecture	lecture	lecture
Entités	lecture, création, modification, archivage	lecture	lecture	lecture
Utilisateurs	lecture, gestion	lecture	—	—
Contrôles	lecture, écriture	lecture, écriture	lecture, écriture	lecture
Référentiels personnalisés	lecture, écriture, publication	lecture, écriture, publication	—	lecture
Mises à jour de référentiels (acceptation)	oui	oui	—	—
Contrôles personnalisés et surcharges des référentiels adoptés	oui	oui	—	—
Risques, incidents, actifs	lecture, écriture	lecture, écriture	lecture, écriture	lecture
Fournisseurs	lecture, écriture	lecture, écriture	—	lecture
Modèles de questionnaires fournisseurs	lecture, écriture, publication	lecture, écriture, publication	—	lecture
Politiques	lecture, écriture	lecture, écriture	—	lecture
RGPD	lecture, écriture	lecture, écriture	lecture, écriture	lecture
Modèles d’activités de traitement	lecture, écriture	lecture, écriture	—	lecture
Tâches et automatisations	lecture, écriture	lecture, écriture	lecture, écriture	lecture
Rapports	lecture, planification	lecture, planification	lecture	lecture
Journal d’audit	lecture (toute l’organisation)	lecture (toute l’organisation)	—	lecture (entités auditées)
Trust Center	lecture, écriture	lecture, écriture	—	lecture

La référence de l’API indique pour chaque opération la permission vérifiée (par exemple Controls.Write). Quelques correspondances utiles :

AuditLogs.Read ouvre /api/v1/audit-logs aux Administrateurs, RSSI et Auditeurs. Un Administrateur ou un RSSI (sur n’importe quelle entité) lit tout le journal de l’organisation ; un Auditeur ne lit que les entrées rattachées aux entités sur lesquelles il est Auditeur, sans les entrées de niveau organisation (sans entité). La liste, le détail (404 hors de ce périmètre), la recherche, les filtres et l’export CSV appliquent le même périmètre.
Le Rapport d’Audit contient la piste d’audit de l’entité : POST /api/v1/entities/{entityId}/reports/generate et …/reports/preview avec "reportType": "Audit" exigent, en plus de Reports.Read, AuditLogs.Read sur cette entité (Administrateur, RSSI, Auditeur), sinon 403 avec un message. Sans elle, …/reports/types ne propose pas ce type, et les exports d’audit sont exclus de …/reports/exports et des compteurs de …/reports/metrics ; leur téléchargement répond 404. Les planifications d’audit sont de même exclues de …/reports/schedules et de son détail. Une planification d’audit refuse les destinataires sans userId (400), et à chaque envoi seuls les utilisateurs détenant alors AuditLogs.Read sur l’entité reçoivent le rapport.
Users.Manage couvre l’invitation, le changement de rôle et la désactivation d’utilisateurs. Pour un invité externe (compte d’une autre organisation qui détient des rôles sur vos entités, isGuest: true dans GET /api/v1/users), seuls la modification et le retrait de ses rôles sont possibles ; POST /api/v1/users/{userId}/deactivate lui retire tous les rôles de votre organisation sans toucher à son compte ; la réactivation, la suppression et l’attribution d’un nouveau rôle sont refusées.
Les études EBIOS RM et les seuils de risque utilisent les permissions des risques ; les automatisations et les tâches proposées, celles des tâches ; le tableau de bord, la lecture des contrôles.
L’acceptation d’une mise à jour de référentiel (POST /api/v1/frameworks/upgrades/{code}/accept) utilise Frameworks.AcceptUpgrade, et les contrôles personnalisés et surcharges d’un référentiel adopté (/api/v1/frameworks/{code}/control-definitions/… : ajout, modification, suppression, PATCH …/override) Frameworks.CustomizeControls, toutes deux accordées aux seuls Administrateurs et RSSI : elles s’appliquent à toute l’organisation, l’écriture des contrôles ne suffit pas ; l’activation d’un référentiel sur une entité, la modification de l’entité.

Certaines règles sont vérifiées en plus par le service, après la permission. Par exemple, passer un contrôle en « Non applicable » exige le rôle Administrateur ou RSSI sur l’entité et une justification d’au moins 20 caractères ; le passer en « Non conforme » est réservé au responsable du contrôle, à un Administrateur ou à un RSSI. Ces refus arrivent en 400 avec un message explicite, par exemple { "error": "Seuls les rôles Admin ou RSSI peuvent marquer un contrôle comme non applicable." } (voir Erreurs).

Réponses en cas de refus

Situation	Réponse
Jeton absent, expiré ou invalide, compte désactivé	`401`, corps vide, en-tête `WWW-Authenticate: Bearer`
Permission manquante sur l’entité ou l’organisation	`403`, corps vide
Règle métier refusée par le service (rôle, justification…)	le plus souvent `400`, avec un message
Adresse IP non autorisée par l’organisation	`403`, type `ip-not-allowed`
Entité d’une autre organisation dans le chemin	`403` (aucun rôle sur cette entité)
Identifiant de ressource inconnu ou d’une autre organisation	`404` : les données des autres organisations sont filtrées

Rappel : les rôles sont lus en base, pour l’organisation du jeton. Après un changement de rôle, attendez quelques secondes avant de conclure à un refus ; renouveler le jeton (POST /api/v1/auth/refresh) ne sert qu’à mettre à jour la revendication roles.