Guides pratiques
Configuration Microsoft Entra ID
Microsoft Entra ID fournit le SSO MSP, le consentement tenant et l’accès aux données Graph nécessaires à Wadyu.
Rôles des app registrations
Une installation Wadyu peut utiliser une app registration dédiée à Microsoft Graph et une app registration dédiée au SSO MSP. Cette séparation facilite la gouvernance, limite l’impact d’une rotation et clarifie les permissions accordées.
L’app Graph sert à interroger les tenants clients consentis. L’app SSO sert à authentifier les administrateurs MSP. Les deux usages ne doivent pas être confondus, car un problème de login MSP ne doit pas élargir les permissions Graph et inversement.
Redirect URI et domaines
Les redirect URI doivent utiliser HTTPS et pointer vers app.wadyu.tech. Les origines autorisées côté API doivent inclure https://app.wadyu.tech et ne pas garder de localhost en production. La documentation publique doc.wadyu.tech ne doit pas être ajoutée comme origine API si elle n’appelle pas l’API.
Le domaine MSP autorisé sert à rattacher un utilisateur Microsoft au bon tenant MSP. Pour Wadyu, le SSO doit rester tenant-scoped : un utilisateur externe ne doit pas être accepté simplement parce qu’il possède un compte Microsoft valide.
Variables serveur
Les variables sensibles sont stockées dans /etc/wadyu/api.env. Les familles principales sont GRAPH_ pour les accès Graph, MSP_AUTH_ pour le SSO MSP, APP_BASE_URL pour l’URL publique et TRUSTED_ORIGINS pour les origines acceptées.
Les secrets ne doivent jamais être copiés dans un ticket, une capture ou une réponse support. Avant toute modification, sauvegardez le fichier env. Après modification, redémarrez uniquement les processus nécessaires et vérifiez health, SSO et logs.
Permissions minimales
Le MVP doit privilégier des permissions de lecture. Les permissions capables de modifier Microsoft 365, retirer des licences ou appliquer des politiques doivent être introduites plus tard avec workflow explicite, consentement renforcé, journal d’audit et possibilité de rollback.
Documentez pourquoi chaque permission est nécessaire. Si une permission ne sert pas à un module actif, elle doit rester absente. C’est un point important pour rassurer les clients et réduire la surface d’exposition.
Rotation des secrets
Chaque secret client Microsoft doit avoir une date d’expiration connue. Planifiez une rotation avant expiration, ajoutez le nouveau secret, mettez à jour /etc/wadyu/api.env, redémarrez PM2 et vérifiez un login Microsoft ainsi qu’un appel Graph simple.
Ne supprimez l’ancien secret qu’après validation du nouveau. En cas d’échec, revenez au secret précédent sans exposer sa valeur. Les logs doivent contenir l’erreur fonctionnelle, pas le secret.
Contrôles production
Après configuration, vérifiez que APP_BASE_URL vaut https://app.wadyu.tech, que TRUSTED_ORIGINS contient https://app.wadyu.tech, que la health API répond et qu’un démarrage SSO Microsoft renvoie une redirection plutôt qu’une erreur JSON.
Vérifiez aussi que PM2 tourne avec l’environnement production et que les placeholders Microsoft ont disparu du fichier env. Un placeholder restant doit bloquer le démarrage plutôt que laisser une application semi-configurée en production.