Odoo-portaler gir kunder og partnere tilgang til relevante dokumenter, transaksjoner og tjenester. Det reiser et identitetsspørsmål: bør eksterne brukere dele katalog og tilgangsmodell med ansatte?
Noen ganger er en gjestekonto i en workforce-tenant passende. I større skala, eller der en profilert kundeinnlogging og selvbetjent registrering er nødvendig, gir Microsoft Entra External ID en dedikert modell for kundeidentitet og tilgangsstyring.
Å koble denne modellen til Odoo kan bidra til en tydeligere grense mellom interne brukere og portalbrukere. Grensen må fortsatt ha eksplisitt godkjenning, kontoopprettelse og Odoo-regler for autorisasjon.
Workforce- og eksterne tenanter er laget for ulike målgrupper
Microsoft definerer en workforce-tenant som miljøet for ansatte, interne forretningsapplikasjoner og organisatoriske ressurser. Den kan også inneholde inviterte forretningspartnere og gjester. En ekstern tenant er en egen konfigurasjon for applikasjoner som tilbys til forbrukere og bedriftskunder. Microsoft beskriver forskjellen i sin veiledning for tenant-konfigurasjon.
En ekstern tenant har sin egen kundekatalog og appregistreringer. External ID legger til selvbetjent registrering, innlogging, passordtilbakestilling, kontoadministrasjon og føderasjon med identitetsleverandører. Oversikten over External ID forklarer den dedikerte modellen.
Denne separasjonen kan hjelpe en organisasjon med å unngå å behandle en kunde som en ansatt bare fordi begge trenger tilgang til en Odoo-tjeneste.
Velg målgruppen før du konfigurerer innlogging
Det finnes minst tre ulike Odoo-målgrupper å vurdere:
Ansatte og interne brukere
Disse brukerne hører normalt hjemme i organisasjonens workforce-tenant. Hvis de får tilgang til Odoo, trenger de vanligvis interne Odoo-brukerkontoer med nøye tilordnede tilgangsgrupper.
Personer fra godkjente partnerorganisasjoner
Noen virksomheter ønsker brukere fra en definert liste over kunde- eller partner-tenanter i Entra. En fler-tenant workforce-tilkobling med en nøyaktig allow-liste for tenanter kan være passende når hver organisasjon er kjent og tilgang er kontraktsmessig godkjent.
Tenant-validering er kritisk. Det holder ikke å matche bare et e-postdomene, fordi domener og e-postadresser kan endres. Valider tokenets tenant og de uforanderlige subject- eller object-identifikatorene i tråd med tilkoblingsdesignet.
Kunder og eksterne brukere
For kundeorienterte applikasjoner kan en External ID-tenant tilby en egen katalog og innloggingsopplevelse. Odoo-kontoer som opprettes for denne målgruppen bør normalt være portalbrukere, ikke interne brukere.
Disse modellene bør konfigureres som separate tilkoblinger når reglene for opptak og Odoo-kontoer er forskjellige. Én bred tilkobling er vanskeligere å forstå og lettere å konfigurere feil.
External ID støtter en innloggingsreise for kunder
External ID-user flows definerer autentiseringsmetoder for kunder og informasjon som samles inn under registrering. En flyt knyttes til registrerte applikasjoner for å aktivere registrering og innlogging. Microsoft dokumenterer dette i å legge til en app i en External ID-user flow.
External ID kan støtte lokale kontoer og føderasjon med identitetsleverandører, inkludert Microsoft Entra ID og egendefinerte OpenID Connect-leverandører. Innebygde og egendefinerte attributter kan samles inn under registrering, slik Microsoft beskriver i sin veiledning om kundeattributter.
Samle bare inn informasjon som Odoo faktisk trenger, og dokumenter formål, lagringstid og personvernbehandling for hvert attributt.
Standardtillatelser bidrar til å bevare separasjonen
Microsoft opplyser at brukere i eksterne tenanter starter med begrensede standardtillatelser. De kan vanligvis bruke applikasjoner og administrere sin egen profil, men får ikke brede rettigheter til katalogadministrasjon. Se standardtillatelser i eksterne tenanter.
Denne kataloggrensen konfigurerer ikke automatisk Odoo-portaltillatelser. Odoo styrer fortsatt hvilke poster en portalbruker kan se gjennom egne tilgangsrettigheter og postregler. Test portalopplevelsen med representative kundeposter og mer enn ett selskap eller én konto for å sikre at data er riktig isolert.
Ikke oppgrader en nyopprettet ekstern bruker til en intern Odoo-bruker med mindre det finnes en egen, godkjent forretningsprosess.
Bruk en moderne, validert OpenID Connect-flyt
Microsoft støtter autorisasjonskodeflyt med Proof Key for Code Exchange og OpenID Connect for serverbaserte webapplikasjoner. Dokumentasjonen for autorisasjonskodeflyt beskriver denne støttede kombinasjonen.
OIDC utvider OAuth 2.0 for autentisering. Microsoft publiserer oppdagelsesmetadata, endepunktsdetaljer og offentlige signeringsnøkler. De anbefaler også å validere det returnerte tokenet og sjekke en nonce for å redusere risikoen for gjenavspilling. Se OpenID Connect på Microsoft identity platform.
En sikker integrasjon bør validere forventet issuer, audience, signatur, tenant-kontekst og nonce. PKCE erstatter ikke tokenvalidering, presis callback-konfigurasjon, TLS eller beskyttelse av klienthemmeligheten.
En enkel innlogging kan be om standard OIDC-scopes som openid, profile og email. Microsoft bemerker at disse scopene er hostet på Microsoft Graph og anbefaler å be om bare de tillatelsene applikasjonen trenger. Se Microsoft identity platform-scopes. En presis produktpåstand er derfor "ingen Microsoft Graph API-tillatelser med høy privilegienivå for standard innlogging", snarere enn en generell påstand om at Graph ikke er involvert.
Bestem hvordan eksterne brukere skal nå Odoo
Før du aktiverer første innlogging, definer:
- Om selvregistrering er åpen eller krever godkjenning.
- Hvilke tenanter eller identitetsleverandører som er tillatt.
- Om en eksisterende Odoo-portalbruker kan kobles til.
- Hvilken uforanderlig Microsoft-identifikator som lagres etter tilkobling.
- Hvilket Odoo-selskap og partner den brukeren tilhører.
- Hvilke portalgrupper og postregler som gjelder.
- Hva som skjer når tilgangen trekkes tilbake.
- Hvordan en aktiv Odoo-økt tilbakekalles.
Automatisk kontoopprettelse kan redusere administrasjon, men den bør bare skje etter at identiteten oppfyller tilkoblingens opptaksregler. Vellykket Microsoft-autentisering bekrefter kontroll over den aksepterte identiteten. Den beviser ikke i seg selv at personen skal se en bestemt kundes Odoo-poster.
Planlegg for kundestøtte og gjenoppretting
Eksterne brukere har kanskje ikke en intern helpdesk. Publiser en støttekanal og angi hvem som forvalter identiteten. Test scenarier for tilbakestilling av passord, gjenoppretting, fjerning av tenant og endret e-postadresse. Hold diagnostiske hendelser nyttige, men maskerte.
Hvis ditt umiddelbare behov er ansatttilgang, les hvorfor du bør beskytte Odoo-instansen din med Microsoft SSO. For interne tillatelser, se sentralisering av Odoo-tilgang med Entra-grupper og app-roller.
Koble eksterne målgrupper til Odoo 19
Vår Microsoft Entra SSO for Odoo-modulen støtter separate tilkoblinger for ansatte, godkjente organisasjoner og Microsoft Entra External ID-kundemålgrupper. External ID-tilkoblinger oppretter portalbrukere som standard, mens arbeidsstyrketilkoblinger oppretter interne brukere. Den veiledede oppsettet validerer oppdagelsesinformasjon og signeringsnøkler, og krever deretter en interaktiv test før Microsoft-pålogging aktiveres.
Modulen avgjør ikke hvem som skal slippes inn, eller hvilke kundeposter de skal se. Dette forblir forretnings- og Odoo-tilgangsbeslutninger. Se nærmere på modulen hvis du trenger en kontrollert bro mellom Microsoft kundeidentitet og en Odoo 19-portal, med målgruppespesifikk kontohåndtering i stedet for en enkelt, udifferensiert påloggingsvei.