Identité et autorisation

Une liste de rôles ne suffit pas à décider d’un accès. Il faut répondre séparément à trois questions : quelle capacité l’utilisateur possède-t-il ? sur quelles ressources ? et les conditions sont-elles réunies maintenant ?

Trois questions, trois mécanismes

Mécanisme	Ce qu’il décide	Exemples
Rôles	les capacités métier, peu nombreuses et stables	gestionnaire d’entreprises, analyste conformité
Relations	le périmètre réel d’exercice	portefeuille, file de travail, dossier affecté, compte détenu
Attributs	les conditions ici et maintenant	montant, état, sensibilité, délégation, séparation des tâches

Un rôle est un nom métier. Il ne contient jamais un nom d’entreprise ni un identifiant de portefeuille, et il agrège des permissions nommées par domaine, ressource et action, dans un catalogue versionné que les cas d’usage déclarent.

Le périmètre se lit dans les relations réelles (équipe → portefeuille → entreprise ; dossier affecté → épargnant), jamais dans une hiérarchie organisationnelle unique. Un dossier clos ou réaffecté retire le périmètre qu’il ouvrait. Un distributeur agit dans le cadre d’un mandat : c’est la nature du mandat qui détermine ses capacités, jamais le rattachement commercial.

Ce que le jeton porte, et ce qu’il ne porte pas

Le jeton est émis par le fournisseur d’identité selon OpenID Connect, ou par échange de client credentials OAuth 2.0 pour un client machine — le cas du serveur d’un TCC appelant Diapason.

Il porte l’identité authentifiée, le tenant actif, la qualité active pour une personne, l’audience du composant visé, et le niveau d’authentification s’il est utile.

Il ne porte pas les habilitations fines. Portefeuilles, entreprises autorisées, files, délégations et plafonds changent trop souvent : les y inscrire rendrait les droits volumineux et périmés. Le jeton a une durée de vie courte, et aucune agrégation de droits ne lui survit.

La qualité active est le point le moins intuitif. Une même personne peut être épargnante, représentante des ressources humaines et utilisatrice professionnelle ; ces capacités ne se mélangent jamais dans une même action. Le choix de l’espace fixe la qualité active, et tout changement est visible, tracé et validé côté serveur.

Chaque service valide lui-même signature, émetteur, audience, expiration et algorithmes — dans chaque service, pas seulement à l’entrée.

L’audience refuse, elle n’accorde pas

Chaque composant est un resource server dont l’audience est le filtre d’entrée. Un composant qui expose plusieurs contrats à des tiers porte une audience par facette exposée, et un jeton obtenu pour l’une est refusé sur l’autre. Le motif est le confinement : le serveur d’un tiers qui ne sert qu’une facette ne peut pas obtenir de jeton valide pour une autre, donc sa compromission ne franchit pas cette frontière.

Trois bornes en font une acceptation et non une habilitation :

• elle refuse, elle n’accorde jamais : un jeton à la bonne audience n’ouvre rien tant que la décision d’autorisation n’a pas été rendue ;
• elle n’entre pas dans la demande d’autorisation ;
• son échec est un 401, jamais un 403 : le jeton ne nous était pas adressé, ce n’est pas un droit qui manque.

Corollaire pour l’intégrateur : répondre à « qui peut appeler cette opération ? » suppose de lire les politiques d’autorisation, pas le contrat. Le contrat décrit la forme de l’échange ; il ne double pas la règle d’accès.

Où la décision est prise

Le composant d’interface n’est jamais la seule barrière. Il authentifie la session, impose le contexte actif, applique un premier contrôle grossier et adapte les réponses à l’écran. Il conserve les jetons côté serveur et n’expose au navigateur qu’un cookie protégé.

Quand il appelle un domaine, il relaie le jeton de l’utilisateur — le domaine voit l’utilisateur réel — accompagné d’un contexte interne signé : application appelante, corrélation, émission, expiration, et le périmètre d’entreprise là où il est requis. Le jeton reste le véhicule de l’identité ; le contexte l’accompagne sans le remplacer, et il ne porte pas de permissions. Un droit inscrit dans un véhicule d’appel serait périmé à sa lecture.

Le service propriétaire de la ressource est la dernière barrière. Autoriser la route ne suffit pas : le service vérifie le droit d’agir sur cette ressource précise, au niveau du cas d’usage, avant toute lecture complète ou modification. Les interfaces exposent des représentations dédiées à chaque finalité, jamais la sérialisation d’une entité interne, et jamais un filtrage tardif au navigateur.

D’où la règle générale : un tenant, une entreprise ou un épargnant présents dans le corps, l’URL ou un en-tête non signé désignent ce qui est demandé ; ils ne prouvent jamais un droit.

Le refus par défaut, et la preuve

Le refus est le comportement par défaut. Permission absente, relation introuvable, contexte incohérent, moteur de décision indisponible : tous produisent un refus, sans repli sur une décision ancienne.

Toute décision doit pouvoir être expliquée par sa règle, sa version et les relations qui l’ont fondée. Décisions et accès sont tracés, ce qui rend un contrôle a posteriori possible.

Chaque contrat synchrone documente ses réponses 401 et 403. Le premier dit que l’identité n’est pas établie, ou que le jeton ne s’adressait pas à cette facette ; le second qu’un droit manque.