Contrôle d'accès — Modèle & Cascade

Le contrôle d'accès est double : le backend bloque toujours (source d'autorité), le frontend masque (UX). Ne faites jamais confiance au frontend seul pour sécuriser une action.

Concepts clés

• adminLevel : niveau hiérarchique, détermine la portée des opérations CRUD.
• wakaRoles : rôles métier transversaux (CONFIG, EXPLOIT, etc.), indépendants de la hiérarchie.
• appRights : droits fins sur des ressources spécifiques (users.create, infra.deploy…).
• features : activation en cascade App ∧ Network ∧ Customer. Si une feature est désactivée à n'importe quel niveau, elle est indisponible.
• Profile : ensemble de AppRight assigné à un utilisateur. Un utilisateur peut avoir plusieurs profils.

---

Les 3 vecteurs de droits

1. adminLevel — portée hiérarchique

Contrôle qui peut voir et modifier quoi selon la position dans la hiérarchie multi-tenant.

textCopier
WakaAdmin     → Tout (plateforme complète, tous les Partners)
OwnerAdmin    → Tout (propriétaire du Partner)
AppsAdmin     → Applications + Profils + Droits (dans son Network)
NetworkAdmin  → Réseaux + Customers + Apps (dans son Network)
CustomerAdmin → Customers + Users + Teams (dans son Customer)
User          → Son propre profil uniquement
None          → Aucun accès admin

Règle de hiérarchie : un NetworkAdmin possède implicitement les droits de CustomerAdmin et User. La vérification côté backend utilise une comparaison ordinale.

2. wakaRoles — rôles métier

Rôles transversaux indépendants de la hiérarchie. Un utilisateur peut avoir plusieurs rôles.

3. appRights — droits applicatifs fins

Droits de type {resource}.{action} accumulés depuis les profils de l'utilisateur.

Format : resource.action ou resource.sub-resource.action

Exemples :

textCopier
partners.read          users.create           infra.deploy
partners.write         users.update           infra.services.scale
apps.read              users.delete           audit.read
apps.create            teams.read             billing.manage
apps.delete            teams.members.add      api-keys.read
profiles.read          teams.members.remove   api-keys.create
profiles.assign        invitations.create     api-keys.revoke
profiles.rights.write  invitations.read       media.upload

---

Cascade de features

Une feature doit être activée à trois niveaux pour être disponible :

Chargement du diagramme…

Le payload /me agrège ce résultat dans le champ features: string[].

Exemple concret :

typescriptCopier
// Si "invitations" n'est pas dans me.features → masquer tout le module
const hasInvitations = me.features.includes("invitations");

---

Vérification combinée via /token/authorize

Pour des vérifications complexes (admin level + rôle + droit) en un seul appel :

httpCopier
POST /api/token/authorize
x-api-key: sk_live_...
Content-Type: application/json

{
  "token": "eyJ...",
  "checks": {
    "adminLevel": {
      "requiredLevel": "CustomerAdmin"
    },
    "roles": {
      "roles": ["CONFIG", "AUDIT"],
      "mode": "any"
    },
    "appRights": {
      "rights": ["users.create", "users.update"],
      "mode": "all"
    }
  }
}

jsonCopier
{
  "authorized": true,
  "details": {
    "adminLevel": {
      "hasLevel": true,
      "actualLevel": "NetworkAdmin"
    },
    "roles": {
      "hasRoles": true,
      "matchedRoles": ["CONFIG"]
    },
    "appRights": {
      "hasRights": true,
      "missingRights": []
    }
  }
}

---

Bonnes pratiques

• Principe du moindre privilège : n'accordez que les droits strictement nécessaires dans les profils.
• Backend = autorité : vérifiez toujours les droits côté serveur. Le frontend ne fait que masquer.
• Granularité fine : préférez users.create à users.* — les wildcards n'existent pas dans le modèle.
• Features en premier : avant de vérifier un droit, vérifiez si la feature est activée.

Pièges classiques

• Confondre userLevel et adminLevel : userLevel (ADMIN, MEMBER, etc.) est le niveau au sein d'une équipe ; adminLevel est la portée administrative sur la hiérarchie.
• appRights vide = aucun accès : un utilisateur sans profil assigné a appRights: [] et ne voit rien.
• Feature désactivée → 403 : si invitations est absent de me.features et que votre code appelle quand même l'API, vous obtiendrez un 403 Feature désactivée.
• Droits cumulatifs : si l'utilisateur a deux profils, ses appRights sont l'union des deux.

Aller plus loin

• Implémentation guards & hooks : code complet frontend et backend
• Feature flags et cascade : AppFeature, NetworkAppFeature, CustomerAppFeature
• Contexte utilisateur /me : source des droits