Odoo-portaler ger kunder och partners åtkomst till relevanta dokument, transaktioner och tjänster. Det väcker en fråga om identitetsdesign: bör externa användare dela katalogen och åtkomstmodellen för anställda?
I vissa fall är ett gästkonto för en affärsbesökare i en workforce-tenant lämpligt. I större skala, eller där varumärkesanpassad kundinloggning och självbetjänad registrering krävs, erbjuder Microsoft Entra External ID en särskild identitets- och åtkomsthanteringsmodell för kunder.
Genom att koppla den modellen till Odoo kan man skapa en tydligare gräns mellan interna användare och portalanvändare. Gränsen kräver fortfarande uttryckligt godkännande, kontoskapande och Odoo-auktoriseringsregler.
Workforce- och externa tenants är utformade för olika målgrupper
Microsoft definierar en workforce-tenant som miljön för anställda, interna affärsapplikationer och organisatoriska resurser. Den kan också innehålla inbjudna affärspartners och gäster. En extern tenant är en separat konfiguration för appar som erbjuds till konsumenter och företagskunder. Microsoft beskriver skillnaden i sin guidning för tenantkonfiguration.
En extern tenant innehåller sin egen kundkatalog och sina egna appregistreringar. External ID lägger till självregistrering, inloggning, lösenordsåterställning, kontohantering och federation med identitetsleverantörer. Översikten över External ID förklarar den särskilda modellen.
Denna uppdelning kan hjälpa en organisation att undvika att behandla en kund som en anställd bara för att båda behöver åtkomst till en Odoo-tjänst.
Välj målgrupp innan du konfigurerar inloggning
Det finns minst tre olika Odoo-målgrupper att ta hänsyn till:
Anställda och interna användare
Dessa användare bör normalt tillhöra organisationens workforce-tenant. Om de får åtkomst till Odoo behöver de i regel interna Odoo-användarkonton med noggrant mappade åtkomstgrupper.
Personer från godkända partnerorganisationer
Vissa företag vill använda användare från en definierad lista över kund- eller partner-tenant i Entra. En workforce-anslutning med flera tenants och en exakt allow-list för tenants kan vara lämplig när varje organisation är känd och åtkomsten är avtalsmässigt godkänd.
Validering av tenant är avgörande. Det räcker inte att matcha en e-postdomän eftersom domäner och e-postadresser kan ändras. Validera tokenens tenant och oföränderliga subjekt- eller objektidentifierare enligt anslutningsdesignen.
Kunder och externa användare
För kundorienterade applikationer kan en External ID-tenant ge en separat katalog och inloggningsupplevelse. Odoo-konton som skapas för denna målgrupp bör normalt vara portalanvändare, inte interna användare.
Dessa modeller bör konfigureras som separata anslutningar när deras regler för tillträde och Odoo-konton skiljer sig åt. En enda bred anslutning är svårare att förstå och lättare att konfigurera fel.
External ID stöder en kundanpassad inloggningsresa
External ID user flows definierar kundautentiseringsmetoder och information som samlas in under registreringen. Ett flöde kopplas till registrerade applikationer för att aktivera registrering och inloggning. Microsoft dokumenterar detta i att lägga till en applikation i ett External ID user flow.
External ID kan stödja lokala konton och federation med identitetsleverantörer, inklusive Microsoft Entra ID och anpassade OpenID Connect-leverantörer. Inbyggda och anpassade attribut kan samlas in under registreringen, som beskrivs i Microsofts guidning för kundattribut.
Samla bara in information som Odoo faktiskt behöver, och dokumentera syftet, lagringstiden och integritetshanteringen för varje attribut.
Standardbehörigheter hjälper till att bevara separationen
Microsoft anger att användare i externa tenants börjar med begränsade standardbehörigheter. De kan i allmänhet komma åt applikationer och hantera sin egen profil, men får inte breda administrativa rättigheter i katalogen. Se standardbehörigheter i externa tenants.
Den kataloggränsen konfigurerar inte automatiskt Odoo-portalbehörigheter. Odoo styr fortfarande vilka poster en portalanvändare kan se genom sina egna åtkomsträttigheter och postregler. Testa portalupplevelsen med representativa kundposter och mer än ett företag eller konto för att säkerställa att data isoleras korrekt.
Uppgradera inte en nyss skapad extern användare till en intern Odoo-användare om det inte finns en separat, godkänd affärsprocess.
Använd ett modernt, validerat OpenID Connect-flöde
Microsoft stöder OAuth 2.0 authorization code flow med Proof Key for Code Exchange och OpenID Connect för serverbaserade webbapplikationer. Dess dokumentation om authorization code flow beskriver den stödda kombinationen.
OIDC utökar OAuth 2.0 för autentisering. Microsoft publicerar metadata för discovery, endpoint-detaljer och offentliga signeringsnycklar. De rekommenderar också att den returnerade token valideras och att en nonce kontrolleras för att minska risken för återspelning. Se OpenID Connect på Microsoft identity platform.
En säker integration bör validera förväntad issuer, audience, signatur, tenantkontext och nonce. PKCE ersätter inte tokenvalidering, korrekt callback-konfiguration, TLS eller skydd av klienthemligheten.
Grundläggande inloggning kan begära vanliga OIDC-scopes som openid, profile och email. Microsoft noterar att dessa scopes finns på Microsoft Graph och rekommenderar att bara begära de behörigheter som applikationen behöver. Se Microsoft identity platform scopes. Ett exakt produktpåstående är därför "inga Microsoft Graph API-behörigheter med hög privilegienivå för standardinloggning", snarare än ett generellt påstående att Graph inte är inblandat.
Bestäm hur externa användare når Odoo
Innan du aktiverar den första inloggningen, definiera:
- Om självregistrering är öppen eller kräver godkännande.
- Vilka tenants eller identitetsleverantörer som tillåts.
- Om ett befintligt Odoo-portal konto kan kopplas.
- Vilken oföränderlig Microsoft-identitet som lagras efter koppling.
- Vilket Odoo-företag och partner som användaren tillhör.
- Vilka portalgrupper och postregler som gäller.
- Vad som händer när åtkomsten återkallas.
- Hur en aktiv Odoo-session återkallas.
Automatisk kontoskapande kan minska administrationen, men det bör endast ske efter att identiteten uppfyller anslutningens inträdesregler. En lyckad Microsoft-autentisering bevisar kontroll över den accepterade identiteten. Den bevisar inte i sig att personen ska se en viss kunds Odoo-poster.
Planera för kundsupport och återställning
Externa användare kanske inte har en intern helpdesk. Publicera en supportväg och ange vem som hanterar identiteten. Testa scenarier för lösenordsåterställning, återställning, borttagning av tenant och ändrad e-postadress. Håll diagnostiska händelser användbara men anonymiserade.
Om ditt omedelbara behov är åtkomst för anställda, läs varför du bör skydda din Odoo-instans med Microsoft SSO. För interna behörigheter, se centralisera Odoo-åtkomst med Entra-grupper och approller.
Koppla externa målgrupper till Odoo 19
Vår Microsoft Entra SSO för Odoo-modul stöder separata anslutningar för anställda, godkända organisationer och Microsoft Entra External ID-kundmålgrupper. External ID-anslutningar skapar portalanvändare som standard, medan arbetsstyrkeanslutningar skapar interna användare. Den guidade konfigurationen validerar upptäcktsinformation och signeringsnycklar, och kräver sedan ett interaktivt test innan Microsoft-inloggning aktiveras.
Modulen avgör inte vem som ska släppas in eller vilka kundposter de ska se. Det förblir affärs- och Odoo-åtkomstbeslut. Granska modulen om du behöver en kontrollerad brygga mellan Microsofts kundidentitet och en Odoo 19-portal, med målgruppsspecifik kontohantering i stället för en enda odifferentierad inloggningsväg.