Graphe des permissions

Les grants ouvrent, les permissions resserrent phase par phase (Permissions). Au chargement, Core construit deux graphes pour prouver que ces règles ne se contredisent pas : le graphe des profils dit qui peut être qui, puis le graphe des droits dit ce que chacun peut faire, à chaque phase.

Le graphe des profils

Une identité peut correspondre à plusieurs profils, et ses droits sont l'union de leurs grants. Vérifier profil par profil ne suffit donc pas : il faut savoir quels profils peuvent se cumuler. Core le lit dans les conditions when :

relation	exemple	conséquence
exclusifs	anonyme (identity.authenticated == false) et premium (identity.authenticated and …)	jamais ensemble
inclus	premium implique client quand sa condition contient celle de client	un premium a aussi les droits du client
cumulables	support et manager, deux rôles	les droits sont vérifiés pour le cumul

Les nœuds du graphe sont les combinaisons de profils qu'une identité peut atteindre, plus le cas « aucun profil » : une identité qui n'entre dans aucun profil n'a droit à rien.

Le chargement refuse, ou signale :

écrit	effet
un profil qu'aucune identité ne peut remplir (sa condition se contredit)	erreur : il ne servirait à personne
deux profils à la condition identique	avertissement : un seul suffit
une porte qui admet des identités qu'aucun profil ne couvre (un client connecté sans rôle, par exemple)	signalé : elles n'auront droit à rien

Le graphe des droits

Pour chaque combinaison de profils, chaque skill, chaque kind et chaque phase, Core calcule le droit effectif : les grants de la combinaison, croisés avec les permissions de cette phase. Pour une même combinaison, chaque phase doit être incluse dans la précédente :

grants ⊇ invoke ⊇ present ⊇ select

Le submit se vérifie à part, car celui qui choisit n'est pas toujours celui qui soumet : les RH réservent un compte, l'IT le crée. Ceux que submitted_by désigne doivent avoir le grant de chaque opération d'écriture que la sélection peut contenir.

Ce qui sort de cette chaîne est une contradiction, refusée au chargement :

écrit	effet
une permission donnée à un profil qui n'a pas le grant de l'opération	erreur : elle ne servirait jamais
un kind qu'un profil peut choisir sans pouvoir le voir	erreur : le modèle pourrait l'ajouter en devinant son id
un kind qu'on peut choisir, alors qu'aucun de ceux que submitted_by désigne n'a le grant de son opération d'écriture	erreur : la sélection ne pourrait jamais être soumise
une skill que personne ne peut invoquer, un kind que personne ne voit	erreur : de la config morte
une tâche requise qu'aucun profil ne peut faire	erreur : le playbook ne pourrait jamais être soumis
une automatisation dont le propriétaire désigné (owner) n'a pas les grants du playbook qu'elle lance	erreur : elle échouerait à chaque fois
une règle qui exige une preuve qu'aucun fournisseur de la station ne sait faire	erreur : la demande d'authentification serait impossible
une skill exposée sur un portail dont le fournisseur ne peut pas ouvrir sa règle	avertissement : indisponible sur ce portail, sans demande

La matrice

Le graphe des droits se lit comme une matrice, publiée avec la config :

combinaison	articles · les autres items	articles · kind premium
anonyme	invoke, present, select	invoke ; retiré au present
premium	invoke, present, select	invoke, present, select
aucun profil	—	—

Les tests: de la config peuvent l'affirmer :

tests:
  - name: "un visiteur ne voit pas les produits premium"
    given: {profile: anonyme}
    when: {invoke: {skill: articles}}
    expect: {never_kinds: [premium]}

Ce que le graphe ne décide pas

• Une condition dynamique — un montant, un budget, $params.team in identity.teams — ne se décide pas au chargement. Le graphe la compte comme « peut-être », jamais comme « toujours ».
• Une condition de profil que Core ne sait pas comparer (au-delà de ==, !=, in, and, or, not sur les champs de l'identité) rend ses profils « cumulables » par prudence : le graphe vérifie alors l'union.

Deux clés

Le graphe prouve que la config est cohérente, au chargement. Il ne remplace pas le contrôle à l'exécution : quand Core appelle l'API du tenant, il revérifie les grants dans la config, et le filtre de present s'applique au vrai résultat. Si le graphe se trompait, l'exécution refuserait quand même.