Odoo inneholder ofte informasjon som er viktig for hele organisasjonen: kundedata, salgsaktivitet, fakturaer, medarbeideropplysninger, prosjekter, lager og operative dokumenter. Tilgangen til denne informasjonen fortjener samme oppmerksomhet som tilgang til e-post, filer og andre kjerneprosesser i virksomheten.
Likevel kan Odoo bli en identitetsøy. Ansatte kan ha ett passord for Microsoft 365 og et annet for Odoo. Administratorer kan måtte håndtere tilgang flere steder. Når noen bytter rolle eller slutter, kan prosessen avhenge av at en sjekkliste fullføres riktig i hver enkelt applikasjon.
Microsoft single sign-on gir organisasjoner et annet alternativ. Ved å koble Odoo til Microsoft Entra ID kan brukere autentisere seg via Microsoft-kontoen sin, og virksomheten kan bruke sine etablerte Microsoft-identitetskontroller i Odoo-påloggingsløpet.
Din Microsoft-identitetsplattform kan allerede være på plass
Hvis organisasjonen bruker Microsoft 365, har den vanligvis allerede en Microsoft Entra workforce tenant. Microsoft forklarer at en workforce tenant opprettes for ansatte, interne applikasjoner og organisatoriske ressurser når en virksomhet registrerer seg for en Microsoft skytjeneste som Microsoft 365. Det gjør Entra til en naturlig identitetsleverandør å vurdere for Odoo, i stedet for å innføre enda et separat kontosystem. Se Microsofts forklaring av workforce and external tenant configurations.
Odoo anerkjenner også dette bruksområdet. Den offisielle Odoo 19 Microsoft Azure sign-in documentation beskriver hvordan Odoo-brukere kan logge inn med Microsoft-kontoer. Den gjør også klart at konfigurasjon kreves på begge sider av integrasjonen.
Den større fordelen er at Microsoft blir stedet der organisasjonen kan bruke autentiseringspolicy før en Odoo-økt starter.
Legg til sterkere autentisering i Odoo-påloggingsløpet
Microsoft Entra multifaktorautentisering kan kreve to eller flere former for verifisering. Disse faktorene kan inkludere noe en bruker vet, noe vedkommende har, eller noe vedkommende er. Microsoft beskriver hvordan utfordringen håndteres som en del av Entra-påloggingsprosessen i sin MFA overview.
Når Odoo delegerer pålogging til Entra, kan en organisasjon kreve en godkjent MFA-metode. Den kan også flytte utvalgte brukere mot phishing-resistente metoder som passkeys, FIDO2-sikkerhetsnøkler, Windows Hello for Business eller sertifikatbasert autentisering. Microsoft anbefaler disse metodene i sin authentication guidance.
Denne forskjellen er viktig. Tradisjonell MFA er generelt sterkere enn kun passordbasert tilgang, men ikke alle MFA-metoder er phishing-resistente. NIST oppgir at passord ikke er phishing-resistente, og at manuelt innskrevne engangskoder heller ikke er phishing-resistente fordi en angriper kan videresende dem. NIST identifiserer WebAuthn, brukt av FIDO2-autentiseringsenheter, som et eksempel på phishing-resistens gjennom domenebinding. Detaljene finnes i NIST SP 800-63B-4.
En SSO-integrasjon gir virksomheten en vei til å bruke disse Entra-funksjonene for Odoo. Virksomheten må likevel fortsatt aktivere og håndheve de riktige policyene.
Ta tilgangsbeslutninger med mer kontekst
Microsoft Entra Conditional Access kan evaluere signaler som bruker, gruppe, applikasjon, plassering, enhetstilstand og innloggingsrisiko. Deretter kan det blokkere tilgang eller kreve kontroller som MFA, en bestemt autentiseringsstyrke eller en compliant enhet. Microsoft kaller Conditional Access sin Zero Trust policy-motor og dokumenterer tilgjengelige signaler og beslutninger i Conditional Access overview.
For en Odoo-utrulling kan dette støtte policyer som:
- Krev MFA for Odoo-administratorer og økonomibrukere.
- Krev en phishing-resistent autentiseringsstyrke for privilegerte roller.
- Blokker Odoo-pålogging fra steder virksomheten ikke betjener.
- Krev en compliant eller administrert enhet for sensitiv intern tilgang.
- Bruk en strengere policy for eksterne eller mer risikable pålogginger.
Dette er eksempler, ikke universelle innstillinger. En policy som passer for et internt økonomiteam, kan være uegnet for en kundeportal. Les how Conditional Access strengthens Odoo sign-in før du velger kontroller.
Conditional Access har også lisenskrav. Microsoft Entra ID P1 kreves for Conditional Access, mens risikobaserte policyer krever P2. Microsoft 365 Business Premium inkluderer funksjoner for Conditional Access. Lisensiering og gjeldende funksjonstilgjengelighet bør kontrolleres mot Microsoft's official documentation.
Knytt identitet og Odoo-tilgang tettere sammen
Autentisering svarer på hvem brukeren er. Odoo-autorisering avgjør fortsatt hva brukeren kan gjøre.
En godt utformet integrasjon kan matche en godkjent Microsoft-identitet til en eksisterende Odoo-konto, opprette en godkjent konto ved første innlogging og mappe utvalgte Entra-grupper eller applikasjonsroller til Odoo-tilgangsgrupper. Dette kan redusere duplisert administrasjon og gjøre tilgangsbeslutninger enklere å gjennomgå.
Det er viktig å bevare grensen mellom identitet og autorisasjon. Å fjerne noen fra en Entra-gruppe bør påvirke Odoo-mappingen i henhold til integrasjonens dokumenterte synkroniseringsatferd, men det avslutter ikke nødvendigvis en eksisterende Odoo-økt umiddelbart. Hvis tilgang synkroniseres ved innlogging, trer endringen i kraft når brukeren logger inn på nytt, med mindre en annen øktkontroll griper inn.
E-postmatching krever også omtanke. Microsoft advarer om at e-postadresser og user principal names kan endres eller gjenbrukes. Dets ID token claims guidance anbefaler uforanderlige identifikatorer som sub eller oid, med tenant-kontekst der det er nødvendig, for varig identitet. E-post kan være nyttig under en kontrollert første kobling, men bør ikke være den permanente identitetsnøkkelen.
For en dypere tilgangsdesign, les centralising Odoo access with Entra groups and app roles.
Hva Microsoft SSO ikke erstatter
Microsoft SSO erstatter ikke Odoo-oppdateringer, roller med minste privilegium, postregler, sikker hosting, sikkerhetskopier, overvåking, øktkontroller eller hendelseshåndtering. Den offisielle Odoo-dokumentasjonen advarer også Odoo.com-hostede databaser mot å bruke den dokumenterte OAuth-flyten for databaseeieren eller administratoren, fordi portaladministrasjon kan bli påvirket. Bekreft eier og nødadministrasjon før utrulling.
En tryggere måte å introdusere Microsoft-pålogging på
Start med en liten testgruppe. Valider Microsofts oppdagelsesmetadata og signeringsnøkler, bekreft callback-URL-en, test kontotilpasning og kontroller resultatene for nye og uautoriserte brukere. Behold en nødspor for administrasjon til flyten er testet ende til ende.
Dokumenter deretter policyene som gjelder for Odoo, hvilke Entra-lisenser de krever, hvordan gruppe- eller rolleafringer overføres til Odoo, og hvordan support vil svare hvis Microsoft-pålogging ikke er tilgjengelig. Hvis kunder og partnere trenger tilgang, bør du vurdere en egen identitetsdesign for kunder i stedet for å behandle dem som ansatte. Vår veiledning til Microsoft Entra External ID for Odoo customers and partners forklarer dette skillet.
Ta guidet Microsoft SSO til Odoo 19 i bruk
Vår Microsoft Entra SSO for Odoo module gir en guidet tilkobling for Odoo 19, inkludert ansatte og eksterne målgrupper, kontrollert første innlogging, kartlegging av grupper og app-roller, innloggingstesting og Microsoft-only interaktiv innlogging etter validering. Den bruker OpenID Connect autorisasjonskodeflyt med PKCE.
Modulen velger ikke sikkerhetspolicyen din. Organisasjonen din er fortsatt ansvarlig for Entra-konfigurasjon, utforming av Odoo-tilgang og utrulling.