Odoo innehåller ofta information som är viktig för hela organisationen: kundregister, försäljningsaktivitet, fakturor, anställdas uppgifter, projekt, lager och operativa dokument. Åtkomsten till den informationen förtjänar samma uppmärksamhet som åtkomsten till e-post, filer och andra centrala affärssystem.

Men Odoo kan bli en identitetsö. Personal kan ha ett lösenord för Microsoft 365 och ett annat för Odoo. Administratörer kan behöva hantera åtkomst på flera olika ställen. När någon byter roll eller lämnar företaget kan processen bero på att en checklista genomförs korrekt i varje applikation.

Microsofts enkel inloggning ger organisationer ett annat alternativ. Genom att koppla Odoo till Microsoft Entra ID kan användare autentisera sig via sitt Microsoft-konto och företaget kan tillämpa sina etablerade Microsoft-identitetskontroller på Odoo:s inloggningsflöde.

Din Microsoft-identitetsgrund kanske redan finns

Om din organisation använder Microsoft 365 har den normalt redan en Microsoft Entra-arbetsstyrketenant. Microsoft förklarar att en arbetsstyrketenant skapas för anställda, interna applikationer och organisatoriska resurser när ett företag registrerar sig för en Microsoft molntjänst som Microsoft 365. Det gör Entra till en naturlig identitetsleverantör att överväga för Odoo, i stället för att införa ännu ett fristående kontosystem. Se Microsofts förklaring av konfigurationer för arbetsstyrke- och extern tenant.

Odoo känner också igen detta användningsfall. Den officiella Odoo 19-dokumentationen för Microsoft Azure-inloggning beskriver hur Odoo-användare kan logga in med Microsoft-konton. Den gör också klart att konfiguration krävs på båda sidor av integrationen.

Den större fördelen är att Microsoft blir den plats där organisationen kan tillämpa autentiseringspolicy innan en Odoo-session börjar.

Lägg till starkare autentisering i Odoo:s inloggningsväg

Microsoft Entra multifaktorautentisering kan kräva två eller fler former av verifiering. Dessa faktorer kan omfatta något användaren vet, något användaren har eller något användaren är. Microsoft beskriver hur utmaningen hanteras som en del av Entra-inloggningsprocessen i sin MFA-översikt.

När Odoo delegerar inloggning till Entra kan en organisation kräva en godkänd MFA-metod. Den kan också styra utvalda användare mot phishing-resistenta metoder som passkeys, FIDO2-säkerhetsnycklar, Windows Hello for Business eller certifikatbaserad autentisering. Microsoft rekommenderar dessa metoder i sin autentiseringsvägledning.

Denna skillnad är viktig. Traditionell MFA är i allmänhet starkare än lösenordsbaserad åtkomst, men inte varje MFA-metod är phishing-resistent. NIST anger att lösenord inte är phishing-resistenta och att manuellt inmatade engångskoder inte är phishing-resistenta eftersom en angripare kan vidarebefordra dem. NIST identifierar WebAuthn, som används av FIDO2-autentiserare, som ett exempel på phishing-resistens genom domänbindning. Detaljerna finns i NIST SP 800-63B-4.

En SSO-integration ger företaget en väg att använda dessa Entra-funktioner för Odoo. Företaget måste fortfarande aktivera och tillämpa rätt policyer.

Fatta åtkomstbeslut med mer kontext

Microsoft Entra villkorad åtkomst kan utvärdera signaler som användaren, gruppen, applikationen, platsen, enhetens status och inloggningsrisk. Den kan sedan blockera åtkomst eller kräva kontroller, inklusive MFA, en viss autentiseringsstyrka eller en kompatibel enhet. Microsoft kallar villkorad åtkomst sin Zero Trust-policymotor och dokumenterar de tillgängliga signalerna och besluten i översikten över villkorad åtkomst.

För en Odoo-installation kan detta stödja policyer som:

  • Krav på MFA för Odoo-administratörer och ekonomianvändare.
  • Krav på en phishing-resistent autentiseringsstyrka för privilegierade roller.
  • Blockera Odoo-inloggning från platser som företaget inte betjänar.
  • Kräv en kompatibel eller hanterad enhet för känslig intern åtkomst.
  • Tillämpa en striktare policy på externa eller mer riskfyllda inloggningar.

Detta är exempel, inte universella inställningar. En policy som passar för ett internt ekonomiteam kan vara olämplig för en kundportal. Läs hur villkorad åtkomst stärker Odoo-inloggning innan du väljer kontroller.

Villkorad åtkomst har också licenskrav. Microsoft Entra ID P1 krävs för villkorad åtkomst, medan riskbaserade policyer kräver P2. Microsoft 365 Business Premium inkluderar funktioner för villkorad åtkomst. Licensiering och aktuell tillgänglighet för funktioner bör kontrolleras mot Microsofts officiella dokumentation.

För samman identitet och Odoo-åtkomst

Autentisering svarar på vem användaren är. Odoo-auktorisering avgör fortfarande vad den användaren kan göra.

En väl utformad integration kan matcha en godkänd Microsoft-identitet till ett befintligt Odoo-konto, skapa ett godkänt konto vid första inloggning och mappa utvalda Entra-grupper eller applikationsroller till Odoo:s åtkomstgrupper. Detta kan minska dubbel administration och göra åtkomstbeslut enklare att granska.

Det är viktigt att bevara gränsen mellan identitet och auktorisering. Om någon tas bort från en Entra-grupp bör det påverka Odoo-mappningen enligt integrationens dokumenterade synkroniseringsbeteende, men det avslutar inte nödvändigtvis en befintlig Odoo-session omedelbart. Om åtkomsten synkroniseras vid inloggning träder ändringen i kraft när användaren loggar in igen, om inte en annan sessionskontroll ingriper.

E-postmatchning kräver också omsorg. Microsoft varnar för att e-postadresser och användarens huvudnamn kan ändras eller återanvändas. Dess vägledning för ID-tokenanspråk rekommenderar oföränderliga identifierare som sub eller oid, med tenantkontext där det behövs, för varaktig identitet. E-post kan vara användbart vid en kontrollerad första länkning, men det bör inte vara den permanenta identitetsnyckeln.

För en djupare åtkomstdesign, läs centralisera Odoo-åtkomst med Entra-grupper och approller.

Vad Microsoft SSO inte ersätter

Microsoft SSO ersätter inte Odoo-uppdateringar, roller med minsta privilegium, postregler, säker hosting, säkerhetskopior, övervakning, sessionskontroller eller incidenthantering. Den officiella Odoo-dokumentationen varnar också Odoo.com-hostade databaser från att använda dess dokumenterade OAuth-flöde för databasägaren eller administratören, eftersom portalhanteringen kan påverkas. Bekräfta ägare och nödadministration före driftsättning.

Ett säkrare sätt att införa Microsoft-inloggning

Börja med en liten testgrupp. Verifiera Microsofts metadata för identifiering och signeringsnycklar, bekräfta callback-URL:en, testa kontomatchning och kontrollera resultat för nya och obehöriga användare. Behåll en administrativ nödväg tills flödet har testats från början till slut.

Dokumentera sedan de policyer som gäller för Odoo, de Entra-licenser de kräver, hur grupp- eller rolländringar når Odoo och hur supporten svarar om Microsoft-inloggning inte är tillgänglig. Om kunder och partners behöver åtkomst, överväg en separat identitetsdesign för kunder i stället för att behandla dem som anställda. Vår guide tillMicrosoft Entra External ID för Odoo-kunder och partners förklarar den skillnaden.

Ta styrd Microsoft SSO till Odoo 19

Vår Microsoft Entra SSO för Odoo-modulen ger en styrd anslutning för Odoo 19, inklusive personal och externa målgrupper, kontrollerad första inloggning, mappning av grupper och approller, test av inloggning och endast Microsoft-interaktiv inloggning efter validering. Den använder OpenID Connect-auktoriseringskodflöde med PKCE.

Modulen väljer inte din säkerhetspolicy. Din organisation ansvarar fortsatt för Entra-konfiguration, Odoo-åtkomstdesign och utrullning.