Le single sign-on répond à une question d’authentification : Microsoft a-t-il vérifié cet utilisateur selon la politique de l’organisation ? Il ne répond pas à toutes les questions d’autorisation dans Odoo.
Un utilisateur authentifié peut avoir besoin d’accéder aux ventes mais pas à la comptabilité, aux projets mais pas à la paie, ou à un portail client mais pas à l’interface interne. Ces décisions restent de la responsabilité d’Odoo. Les groupes Microsoft Entra et les rôles d’application peuvent fournir des entrées de confiance pour les rendre plus cohérentes.
Les groupes et les rôles d’application ont des objectifs différents
Les groupes Microsoft Entra appartiennent au tenant. Ils peuvent représenter des départements, des fonctions, des projets ou des périmètres de sécurité. Les rôles d’application appartiennent à une inscription d’application particulière et décrivent des rôles pertinents pour cette application.
La documentation sur les rôles d’application de Microsoft explique que les rôles d’application peuvent être attribués à des utilisateurs ou à des groupes. Lorsqu’un utilisateur assigné se connecte, Entra peut inclure les rôles accordés dans une revendication roles. Microsoft indique aussi que les rôles d’application et les groupes ne sont pas mutuellement exclusifs.
Cela donne à une conception d’accès Odoo deux grands modèles :
- Mapper directement les Object ID des groupes de sécurité Entra stables vers des groupes Odoo sélectionnés.
- Définir des rôles d’application centrés sur Odoo dans l’application Entra, attribuer des utilisateurs ou des groupes à ces rôles, puis mapper les valeurs de rôle obtenues vers des groupes Odoo.
Le mapping direct fonctionne bien avec des groupes de sécurité gouvernés. Les rôles d’application peuvent offrir une frontière applicative plus nette, car leur intention suit l’inscription de l’application plutôt que de dépendre de noms propres au tenant.
Commencez par le modèle d’accès réel d’Odoo
Ne commencez pas par copier chaque groupe Microsoft dans Odoo. Commencez par les permissions Odoo dont l’entreprise a réellement besoin.
Listez les groupes Odoo qui accordent des capacités concrètes. Pour chacun, documentez :
- Le but métier de l’accès.
- La personne responsable de son approbation.
- Le groupe Entra ou le rôle d’application qui représente l’approbation.
- La vitesse à laquelle un changement doit atteindre Odoo et ce qui se passe à une session active après suppression.
Appliquez le principe du moindre privilège. Un groupe de département large peut être pratique, mais il peut accorder plus d’accès Odoo que nécessaire à chaque membre. Un groupe de sécurité ou un rôle d’application plus petit, spécifique à Odoo, est souvent plus facile à auditer.
Traitez la liaison d’identité comme un contrôle de sécurité
De nombreux systèmes font d’abord correspondre un compte existant à l’aide d’une adresse e-mail. C’est pratique, surtout lorsque Odoo et Microsoft utilisent déjà le même e-mail professionnel. Ce n’est pas une clé d’identité durable.
Microsoft indique dans sa référence des revendications de jetons ID que les adresses e-mail, les numéros de téléphone et les user principal names peuvent changer et être réutilisés. Microsoft recommande des revendications immuables telles que sub ou oid, avec tid lorsque le contexte du tenant est requis, pour une identification fiable.
Un modèle plus sûr est le suivant :
- N’accepter qu’un tenant attendu et une audience approuvée.
- Utiliser l’e-mail pour une correspondance initiale contrôlée lorsque c’est approprié.
- Refuser les correspondances ambiguës ou en double.
- Stocker l’identité Microsoft immuable et les identifiants du tenant après la liaison.
- Utiliser ces valeurs immuables pour les connexions futures.
Pour un accès multi-tenant, le contexte du tenant est essentiel. Une même personne peut avoir des identifiants d’objet différents dans des tenants différents, et l’accès depuis un tenant ne doit pas hériter silencieusement des permissions associées à un autre.
Comprenez le cas de dépassement des revendications de groupe
Les revendications de groupe sont pratiques, mais elles ne sont pas illimitées. Microsoft documente une limite de 200 Object ID de groupe dans un JWT. Lorsque l’appartenance d’un utilisateur dépasse cette limite, Entra omet la liste normale des groupes et renvoie un indicateur de dépassement qui oriente l’application vers Microsoft Graph. Consultez les consignes sur le dépassement des groupes.
C’est important si une intégration annonce un mapping des groupes sans autorisations Microsoft Graph API élevées. Un utilisateur ayant une appartenance étendue à des groupes peut ne pas recevoir l’ensemble attendu de revendications de groupe.
Avant de vous appuyer sur un mapping direct des groupes, vérifiez comment le dépassement est géré. Les options incluent des groupes plus petits spécifiques à l’application, des rôles d’application, le filtrage des revendications ou une recherche via Graph avec un consentement au moindre privilège.
La synchronisation à la connexion n’est pas un provisionnement en temps réel
Un module SSO peut comparer les revendications Entra actuelles avec les mappings Odoo configurés lorsqu’un utilisateur se connecte. C’est utile, car l’accès peut être aligné pendant un événement d’authentification normal.
Ce n’est pas la même chose qu’un provisionnement continu. Si un employé est retiré d’un groupe Entra alors qu’une session Odoo est active, cette session peut continuer jusqu’à la déconnexion, l’expiration ou l’application d’un autre contrôle de révocation. Si un ancien employé ne se reconnecte jamais, un processus de synchronisation à la connexion n’archive pas à lui seul le compte Odoo.
Microsoft Entra ID Governance propose des Lifecycle Workflows pour les processus d’arrivée, de mobilité et de départ, y compris la désactivation des comptes et la suppression des attributions d’accès. Consultez les consignes sur Lifecycle Workflows. Ces fonctionnalités nécessitent une licence Microsoft Entra ID Governance ou Microsoft Entra Suite.
L’automatisation du cycle de vie peut améliorer l’état de l’identité source, mais elle ne met toujours pas à jour Odoo à moins qu’une intégration ne consomme le changement. Votre procédure de départ doit couvrir explicitement la révocation de session Odoo et l’état du compte.
Construisez un modèle de mapping auditable
Gardez un nombre de mappings compréhensible. Pour chaque groupe ou rôle, utilisez un identifiant stable et une description lisible. Notez pourquoi l’accès Odoo associé existe, qui l’a approuvé et à quand remonte sa dernière revue.
Testez au moins ces cas :
- Utilisateur existant avec un seul mapping attendu.
- Utilisateur sans mapping approuvé ou avec un tenant non autorisé.
- Nouvel utilisateur admis pour la première connexion.
- Utilisateur retiré d’un groupe mappé ou ayant de nombreuses appartenances à des groupes.
- Utilisateur renommé dont l’identité immuable n’a pas changé.
- Compte Microsoft désactivé avec une session Odoo existante.
Les événements de connexion doivent aider les administrateurs à diagnostiquer les résultats des revendications et du mappage sans exposer les jetons, les identifiants ou les secrets. Les journaux doivent identifier la connexion et le résultat, mais les valeurs sensibles doivent être masquées.
Combiner le mappage avec la stratégie d’authentification
Le mappage des groupes et des rôles contrôle l’autorisation Odoo. Microsoft Entra Conditional Access contrôle si Microsoft finalisera l’authentification dans les conditions actuelles. Les deux couches sont complémentaires.
Par exemple, un rôle d’application Entra peut être associé à un groupe finance Odoo, tandis que Conditional Access exige un niveau d’authentification résistant au phishing pour les utilisateurs affectés à ce rôle. Lisez comment Microsoft Entra Conditional Access renforce la connexion Odoo pour la partie stratégie d’authentification.
Pour les clients et les partenaires, ne réutilisez pas automatiquement les mappages des employés. Une conception distincte, adaptée à un public et à un portail, peut être plus sûre. Voir Microsoft Entra External ID for Odoo customers and partners.
Mapper l’accès Microsoft approuvé dans Odoo 19
Notre module Microsoft Entra SSO for Odoo prend en charge le mappage des ID d’objet des groupes de sécurité Entra configurés ou des rôles d’application vers les groupes d’accès Odoo sélectionnés. Il peut synchroniser ces mappages à la connexion, associer un compte existant contrôlé et créer des utilisateurs approuvés, employés ou portail, selon le type de connexion.
Le module ne remplace pas la gouvernance des accès, la révocation de session ni une stratégie documentée de dépassement. Examinez l’échelle de vos groupes, les exigences de liaison d’identité et le modèle d’autorisations Odoo avant d’activer les mappages. Si ces fondations sont claires, le module offre une manière guidée de les connecter.