Odoo rummer ofte oplysninger, der er vigtige på tværs af hele organisationen: kundedata, salgsaktivitet, fakturaer, medarbejderoplysninger, projekter, lager og driftsdokumenter. Adgang til disse oplysninger fortjener samme opmærksomhed som adgang til e-mail, filer og andre centrale forretningssystemer.
Alligevel kan Odoo blive en identitetssilo. Medarbejdere kan have ét kodeord til Microsoft 365 og et andet til Odoo. Administratorer kan skulle håndtere adgang forskellige steder. Når nogen skifter rolle eller forlader virksomheden, kan processen afhænge af, at en tjekliste bliver fulgt korrekt i alle applikationer.
Microsoft single sign-on giver organisationer endnu en mulighed. Ved at forbinde Odoo til Microsoft Entra ID kan brugere autentificere via deres Microsoft-konto, og virksomheden kan anvende sine etablerede Microsoft-identitetskontroller på Odoo-loginforløbet.
Din Microsoft-identitetsgrundlag findes måske allerede
Hvis din organisation bruger Microsoft 365, har den normalt allerede en Microsoft Entra workforce tenant. Microsoft forklarer, at en workforce tenant oprettes til medarbejdere, interne applikationer og organisatoriske ressourcer, når en virksomhed tilmelder sig en Microsoft cloud-tjeneste som Microsoft 365. Det gør Entra til en naturlig identitetsudbyder at overveje til Odoo, frem for at indføre endnu et selvstændigt kontosystem. Se Microsofts forklaring på konfiguration af workforce- og eksterne tenants.
Odoo understøtter også dette use case. Den officielle Odoo 19 Microsoft Azure sign-in-dokumentation beskriver, hvordan Odoo-brugere kan logge ind med Microsoft-konti. Den gør også klart, at der kræves konfiguration på begge sider af integrationen.
Den større fordel er, at Microsoft bliver det sted, hvor organisationen kan anvende autentificeringspolitik, før en Odoo-session begynder.
Tilføj stærkere autentificering til Odoo-loginforløbet
Microsoft Entra multifaktorautentificering kan kræve to eller flere former for verificering. Disse faktorer kan omfatte noget, en bruger ved, noget vedkommende har, eller noget vedkommende er. Microsoft beskriver, hvordan udfordringen håndteres som en del af Entra-loginprocessen i sin MFA-oversigt.
Når Odoo delegerer login til Entra, kan en organisation kræve en godkendt MFA-metode. Den kan også flytte udvalgte brugere mod phishing-resistente metoder såsom passkeys, FIDO2-sikkerhedsnøgler, Windows Hello for Business eller certifikatbaseret autentificering. Microsoft anbefaler disse metoder i sin autentificeringsvejledning.
Denne forskel er vigtig. Traditionel MFA er generelt stærkere end adgang med kun kodeord, men ikke alle MFA-metoder er phishing-resistente. NIST fastslår, at kodeord ikke er phishing-resistente, og at manuelt indtastede engangskoder ikke er phishing-resistente, fordi en angriber kan videresende dem. NIST identificerer WebAuthn, som bruges af FIDO2-autentificeringsenheder, som et eksempel på phishing-resistens gennem domænebinding. Detaljen findes i NIST SP 800-63B-4.
En SSO-integration giver virksomheden en vej til at bruge disse Entra-funktioner til Odoo. Virksomheden skal stadig aktivere og håndhæve de relevante politikker.
Træf adgangsbeslutninger med mere kontekst
Microsoft Entra Conditional Access kan evaluere signaler som bruger, gruppe, applikation, placering, enhedsstatus og loginrisiko. Det kan derefter blokere adgang eller kræve kontroller, herunder MFA, en bestemt autentificeringsstyrke eller en kompatibel enhed. Microsoft kalder Conditional Access sin Zero Trust-politikmotor og dokumenterer de tilgængelige signaler og beslutninger i oversigten over Conditional Access.
For en Odoo-implementering kan det understøtte politikker som:
- Krav om MFA for Odoo-administratorer og økonomibrugere.
- Krav om phishing-resistent autentificeringsstyrke for privilegerede roller.
- Blokering af Odoo-login fra placeringer, som virksomheden ikke betjener.
- Krav om en kompatibel eller administreret enhed for følsom intern adgang.
- Anvendelse af en strengere politik på eksterne eller mere risikofyldte logins.
Dette er eksempler, ikke universelle indstillinger. En politik, der er passende for et internt økonomiteam, kan være uegnet for en kundeportal. Læs hvordan Conditional Access styrker Odoo-login før du vælger kontroller.
Conditional Access har også licenskrav. Microsoft Entra ID P1 kræves til Conditional Access, mens risikobaserede politikker kræver P2. Microsoft 365 Business Premium inkluderer funktioner til Conditional Access. Licensering og aktuel tilgængelighed af funktioner bør kontrolleres mod Microsofts officielle dokumentation.
Bring identitet og Odoo-adgang tættere sammen
Autentificering besvarer, hvem brugeren er. Odoo-autorisation afgør stadig, hvad den bruger kan gøre.
En veldesignet integration kan matche en godkendt Microsoft-identitet med en eksisterende Odoo-konto, oprette en godkendt konto ved første login og mappe udvalgte Entra-grupper eller applikationsroller til Odoo-adgangsgrupper. Det kan reducere dobbelt administration og gøre adgangsbeslutninger lettere at gennemgå.
Det er vigtigt at bevare grænsen mellem identitet og autorisation. Hvis nogen fjernes fra en Entra-gruppe, bør det påvirke Odoo-mappingen i henhold til integrationens dokumenterede synkroniseringsadfærd, men det afslutter ikke nødvendigvis en eksisterende Odoo-session med det samme. Hvis adgang synkroniseres ved login, træder ændringen i kraft, når brugeren logger ind igen, medmindre en anden sessionskontrol griber ind.
E-mailmatchning kræver også omhu. Microsoft advarer om, at e-mailadresser og brugernes hovednavne kan ændre sig eller genbruges. Dets vejledning om ID-token claims anbefaler uforanderlige identifikatorer som sub eller oid, med tenant-kontekst hvor det er nødvendigt, for en holdbar identitet. E-mail kan være nyttig under en kontrolleret første sammenknytning, men bør ikke være den permanente identitetsnøgle.
For et dybere design af adgang, læs centralisering af Odoo-adgang med Entra-grupper og app-roller.
Hvad Microsoft SSO ikke erstatter
Microsoft SSO erstatter ikke Odoo-opdateringer, mindst mulige rettigheder, record rules, sikker hosting, sikkerhedskopier, overvågning, sessionkontroller eller incident response. Den officielle Odoo-dokumentation advarer også Odoo.com-hostede databaser mod at bruge dens dokumenterede OAuth-flow til databaseejeren eller administratoren, fordi portaladministration kan blive påvirket. Bekræft ejer- og nødadministration før implementering.
En sikrere måde at indføre Microsoft-login på
Start med en lille testgruppe. Validér Microsoft-opdagelsesmetadata og signeringsnøgler, bekræft callback-URL'en, test kontotilpasning, og kontroller resultater for nye og uautoriserede brugere. Behold en nødadministrativ adgangsvej, indtil flowet er testet fra ende til anden.
Dokumentér derefter de politikker, der gælder for Odoo, de Entra-licenser de kræver, hvordan gruppe- eller rolleafringer når Odoo, og hvordan support vil reagere, hvis Microsoft-login ikke er tilgængeligt. Hvis kunder og partnere har brug for adgang, så overvej et separat design for kunders identitet i stedet for at behandle dem som medarbejdere. Vores guide til Microsoft Entra External ID for Odoo customers and partners forklarer den forskel.
Bring guidet Microsoft-SSO til Odoo 19
Vores Microsoft Entra SSO for Odoo module giver en guidet forbindelse til Odoo 19, inklusive medarbejder- og eksterne målgrupper, kontrolleret første login, mapping af grupper og app-roller, login-test og Microsoft-only interaktiv login efter validering. Den bruger OpenID Connect authorization code flow med PKCE.
Modulet vælger ikke din sikkerhedspolitik. Din organisation er fortsat ansvarlig for Entra-konfiguration, Odoo-adgangsdesign og udrulning.