Odoo-Portale geben Kunden und Partnern Zugriff auf relevante Dokumente, Transaktionen und Services. Das wirft eine Identitätsfrage auf: Sollten externe Benutzer das Verzeichnis und das Zugriffsmodell der Mitarbeiter teilen?
Manchmal ist ein Business-Gastkonto in einem Workforce-Tenant sinnvoll. In größerem Umfang oder wenn ein markenspezifischer Kunden-Login und eine Self-Service-Registrierung erforderlich sind, bietet Microsoft Entra External ID ein dediziertes Modell für Kundenidentität und Zugriffsverwaltung.
Die Anbindung dieses Modells an Odoo kann eine klarere Trennung zwischen internen Benutzern und Portalbenutzern unterstützen. Diese Trennung erfordert dennoch eine explizite Zulassung, Kontoerstellung und Odoo-Autorisierungsregeln.
Workforce- und externe Tenants sind für unterschiedliche Zielgruppen konzipiert
Microsoft definiert einen Workforce-Tenant als die Umgebung für Mitarbeiter, interne Geschäftsanwendungen und organisatorische Ressourcen. Er kann auch eingeladene Geschäftspartner und Gäste enthalten. Ein externer Tenant ist eine separate Konfiguration für Anwendungen, die Verbrauchern und Geschäftskunden angeboten werden. Microsoft beschreibt den Unterschied in seiner Leitlinie zur Tenant-Konfiguration.
Ein externer Tenant enthält sein eigenes Kundenverzeichnis und eigene Anwendungsregistrierungen. External ID ergänzt Self-Service-Registrierung, Anmeldung, Zurücksetzen des Kennworts, Kontoverwaltung und Föderation mit Identitätsanbietern. Die Übersicht zu External ID erläutert das dedizierte Modell.
Diese Trennung kann einer Organisation helfen, einen Kunden nicht wie einen Mitarbeiter zu behandeln, nur weil beide Zugriff auf einen Odoo-Dienst benötigen.
Wählen Sie die Zielgruppe, bevor Sie die Anmeldung konfigurieren
Es gibt mindestens drei unterschiedliche Odoo-Zielgruppen zu berücksichtigen:
Mitarbeiter und interne Benutzer
Diese Benutzer gehören normalerweise in den Workforce-Tenant der Organisation. Wenn sie zu Odoo zugelassen werden, benötigen sie in der Regel interne Odoo-Benutzerkonten mit sorgfältig zugeordneten Zugriffsgruppen.
Personen aus freigegebenen Partnerorganisationen
Manche Unternehmen möchten Benutzer aus einer definierten Liste von Kunden- oder Partner-Entra-Tenants zulassen. Eine mandantenübergreifende Workforce-Verbindung mit einer exakten Allowlist für Tenants kann sinnvoll sein, wenn jede Organisation bekannt ist und der Zugriff vertraglich genehmigt wurde.
Die Tenant-Validierung ist entscheidend. Die bloße Übereinstimmung einer E-Mail-Domäne reicht nicht aus, da Domänen und E-Mail-Adressen veränderbar sind. Validieren Sie den Tenant des Tokens sowie unveränderliche Subject- oder Objektkennungen gemäß dem Verbindungsdesign.
Kunden und externe Benutzer
Für kundenorientierte Anwendungen kann ein External-ID-Tenant ein separates Verzeichnis und eine separate Anmeldeerfahrung bereitstellen. Für diese Zielgruppe erstellte Odoo-Konten sollten normalerweise Portalbenutzer und nicht interne Benutzer sein.
Diese Modelle sollten als separate Verbindungen konfiguriert werden, wenn sich ihre Zulassungs- und Odoo-Kontoregeln unterscheiden. Eine einzige breite Verbindung ist schwerer zu beurteilen und leichter falsch zu konfigurieren.
External ID unterstützt einen Kunden-Anmeldeprozess
External ID-Benutzerflows definieren Authentifizierungsmethoden für Kunden und die bei der Registrierung erfassten Informationen. Ein Flow ist mit registrierten Anwendungen verknüpft, um Registrierung und Anmeldung zu aktivieren. Microsoft dokumentiert dies unter Hinzufügen einer Anwendung zu einem External-ID-Benutzerflow.
External ID kann lokale Konten und Föderation mit Identitätsanbietern einschließlich Microsoft Entra ID und benutzerdefinierten OpenID-Connect-Anbietern unterstützen. Integrierte und benutzerdefinierte Attribute können bei der Registrierung erfasst werden, wie in Microsofts Leitlinie zu Kundenattributen beschrieben.
Erfassen Sie nur Informationen, die Odoo tatsächlich benötigt, und dokumentieren Sie den Zweck, die Aufbewahrung und die datenschutzrechtliche Behandlung jedes Attributs.
Standardberechtigungen helfen, die Trennung zu wahren
Microsoft gibt an, dass Benutzer externer Tenants mit eingeschränkten Standardberechtigungen beginnen. Sie können im Allgemeinen auf Anwendungen zugreifen und ihr eigenes Profil verwalten, erhalten jedoch keine weitreichenden Verwaltungsrechte für das Verzeichnis. Siehe Standardberechtigungen in externen Tenants.
Diese Verzeichnisgrenze konfiguriert die Odoo-Portalberechtigungen nicht automatisch. Odoo steuert weiterhin über eigene Zugriffsrechte und Datensatzregeln, welche Datensätze ein Portalbenutzer sehen kann. Testen Sie die Portal-Erfahrung mit repräsentativen Kundendatensätzen und mehr als einem Unternehmen oder Konto, um sicherzustellen, dass Daten korrekt isoliert sind.
Stufen Sie einen neu erstellten externen Benutzer nicht ohne einen separaten, genehmigten Geschäftsprozess zu einem internen Odoo-Benutzer hoch.
Verwenden Sie einen modernen, validierten OpenID-Connect-Flow
Microsoft unterstützt den OAuth-2.0-Autorisierungscode-Flow mit Proof Key for Code Exchange und OpenID Connect für serverbasierte Webanwendungen. Die Dokumentation zum Autorisierungscode-Flow beschreibt diese unterstützte Kombination.
OIDC erweitert OAuth 2.0 um Authentifizierung. Microsoft veröffentlicht Discovery-Metadaten, Endpunktdetails und öffentliche Signaturschlüssel. Außerdem empfiehlt Microsoft, das zurückgegebene Token zu validieren und eine Nonce zu prüfen, um das Replay-Risiko zu verringern. Siehe OpenID Connect auf der Microsoft Identity Platform.
Eine sichere Integration sollte den erwarteten Issuer, die Audience, die Signatur, den Tenant-Kontext und die Nonce validieren. PKCE ersetzt nicht die Token-Validierung, eine exakte Callback-Konfiguration, TLS oder den Schutz des Client-Geheimnisses.
Die grundlegende Anmeldung kann standardmäßige OIDC-Scopes wie openid, profile und email anfordern. Microsoft weist darauf hin, dass diese Scopes auf Microsoft Graph gehostet werden, und empfiehlt, nur die Berechtigungen anzufordern, die die Anwendung benötigt. Siehe Scopes der Microsoft Identity Platform. Eine präzise Produktaussage lautet daher "keine Microsoft-Graph-API-Berechtigungen mit hohen Rechten für die Standardanmeldung", statt zu behaupten, dass Graph generell nicht beteiligt ist.
Entscheiden Sie, wie externe Benutzer auf Odoo zugreifen
Bevor Sie die erste Anmeldung aktivieren, legen Sie fest:
- Ob die Selbstregistrierung offen ist oder eine Genehmigung erforderlich ist.
- Welche Tenants oder Identitätsanbieter zugelassen sind.
- Ob ein bestehendes Odoo-Portal-Konto verknüpft werden kann.
- Welcher unveränderliche Microsoft-Bezeichner nach dem Verknüpfen gespeichert wird.
- Zu welcher Odoo-Firma und zu welchem Partner der Benutzer gehört.
- Welche Portalgruppen und Datensatzregeln gelten.
- Was passiert, wenn der Zugriff entzogen wird.
- Wie eine aktive Odoo-Sitzung widerrufen wird.
Die automatische Kontenerstellung kann den Administrationsaufwand verringern, sollte jedoch erst erfolgen, nachdem die Identität die Zulassungsregeln der Verbindung erfüllt. Eine erfolgreiche Microsoft-Authentifizierung belegt die Kontrolle über die akzeptierte Identität. Sie belegt für sich allein nicht, dass die Person bestimmte Odoo-Datensätze eines Kunden sehen sollte.
Planen Sie für Kundensupport und Wiederherstellung
Externe Benutzer haben möglicherweise keinen internen Helpdesk. Veröffentlichen Sie einen Supportweg und legen Sie fest, wer die Identität verwaltet. Testen Sie Szenarien für Passwortzurücksetzung, Wiederherstellung, Mandantenentfernung und geänderte E-Mail-Adressen. Halten Sie Diagnoseereignisse nützlich, aber geschwärzt.
Wenn Sie kurzfristig Mitarbeiterzugriff benötigen, lesen Sie warum Sie Ihre Odoo-Instanz mit Microsoft SSO schützen sollten. Für interne Berechtigungen siehe Odoo-Zugriff mit Entra-Gruppen und App-Rollen zentralisieren.
Externe Zielgruppen mit Odoo 19 verbinden
Unser Microsoft Entra SSO für das Odoo-Modul unterstützt separate Verbindungen für Mitarbeiter, freigegebene Organisationen und Microsoft Entra External ID-Kundenzielgruppen. External-ID-Verbindungen erstellen standardmäßig Portalbenutzer, während Workforce-Verbindungen interne Benutzer erstellen. Die geführte Einrichtung validiert Erkennungsinformationen und Signaturschlüssel und erfordert dann einen interaktiven Test, bevor die Microsoft-Anmeldung aktiviert wird.
Das Modul entscheidet nicht, wer zugelassen werden soll oder welche Kundendatensätze diese Personen sehen sollten. Das bleiben geschäftliche Entscheidungen und Odoo-Zugriffsentscheidungen. Prüfen Sie das Modul, wenn Sie eine kontrollierte Brücke zwischen der Microsoft-Kundenidentität und einem Odoo-19-Portal benötigen, mit zielgruppenspezifischer Kontobehandlung statt eines einzelnen, undifferenzierten Anmeldepfads.