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

Microsoft Entra ID permet deux usages distincts : authentifier les administrateurs MSP avec Microsoft et autoriser Wadyu à accéder aux données Microsoft 365 nécessaires au service. Cette séparation facilite la gouvernance et rassure le client sur le périmètre demandé.

Le client doit surtout comprendre quelles permissions sont demandées, pourquoi elles sont nécessaires et comment elles s’inscrivent dans le service Wadyu. Les détails opérés par Wadyu restent hors documentation publique.

Redirect URI et domaines

Les URLs de redirection doivent utiliser HTTPS et pointer vers app.wadyu.tech. Les domaines de test ou les URLs locales ne doivent pas être utilisés dans un environnement client ou MSP en production.

Le domaine MSP autorisé sert à rattacher un utilisateur Microsoft au bon tenant MSP. Le SSO doit rester tenant-scoped : un utilisateur externe ne doit pas être accepté simplement parce qu’il possède un compte Microsoft valide.

Configuration administrateur

Les paramètres sensibles Microsoft sont gérés par les administrateurs habilités et l’équipe opérant Wadyu. La documentation publique décrit le résultat attendu sans exposer l’emplacement technique, les noms de fichiers internes ou les valeurs secrètes.

Les secrets ne doivent jamais être copiés dans un ticket public, une capture, un export ou une réponse support. Les changements sensibles doivent être réalisés selon la procédure d’administration prévue, puis validés par un test de connexion Microsoft et un contrôle de synchronisation.

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 retour arrière.

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 et validation

Chaque secret Microsoft doit avoir une date d’expiration connue et un processus de rotation. Après rotation, les administrateurs doivent vérifier que le SSO fonctionne, que le tenant client reste lié et que les synchronisations prévues reprennent normalement.

En cas d’échec, le diagnostic doit rester fonctionnel et redigé sans exposer de secret. Les journaux et messages de support doivent contenir le contexte utile, pas les valeurs confidentielles.