Single sign-on besvarer et autentiseringsspørsmål: har Microsoft bekreftet denne brukeren i tråd med organisasjonens policy? Det besvarer ikke alle autorisasjonsspørsmål i Odoo.
En autentisert bruker kan trenge tilgang til salg, men ikke regnskap, prosjekter, men ikke lønn, eller en kundeportal, men ikke det interne grensesnittet. Disse beslutningene forblir Odoo sitt ansvar. Microsoft Entra-grupper og applikasjonsroller kan gi pålitelige input for å gjøre dem mer konsekvente.
Grupper og app-roller har ulike formål
Microsoft Entra-grupper tilhører tenant-en. De kan representere avdelinger, jobbfunksjoner, prosjekter eller sikkerhetsgrenser. Applikasjonsroller tilhører en bestemt appregistrering og beskriver roller som er meningsfulle for den applikasjonen.
Microsofts app-role documentation forklarer at app-roller kan tildeles til brukere eller grupper. Når en tildelt bruker logger inn, kan Entra inkludere de tildelte rollene i en roles-claim. Microsoft sier også at app-roller og grupper ikke er gjensidig utelukkende.
Dette gir en Odoo-tilgangsløsning to hovedmønstre:
- Kartlegg stabile Entra sikkerhetsgruppe Object ID-er direkte til utvalgte Odoo-grupper.
- Definer Odoo-tilpassede app-roller i Entra-applikasjonen, tildel brukere eller grupper til disse rollene, og kartlegg de resulterende rolleverdiene til Odoo-grupper.
Direkte kartlegging fungerer godt med styrte sikkerhetsgrupper. App-roller kan gi en renere applikasjonsgrense fordi intensjonen følger appregistreringen i stedet for å være avhengig av tenant-spesifikke navn.
Start med Odoos faktiske tilgangsmodell
Ikke begynn med å kopiere hver Microsoft-gruppe inn i Odoo. Begynn med Odoo-tillatelsene virksomheten faktisk trenger.
List opp Odoo-gruppene som gir vesentlige rettigheter. For hver av dem, dokumenter:
- Forretningsformålet med tilgangen.
- Hvem som har ansvar for å godkjenne den.
- Hvilken Entra-gruppe eller app-rolle som representerer godkjenningen.
- Hvor raskt en endring skal nå Odoo og hva som skjer med en aktiv økt etter fjerning.
Bruk prinsippet om minste privilegium. En bred avdelingsgruppe kan være praktisk, men den kan gi mer Odoo-tilgang enn hvert medlem trenger. En mindre Odoo-spesifikk sikkerhetsgruppe eller app-rolle er ofte enklere å revidere.
Behandle identitetsbinding som en sikkerhetskontroll
Mange systemer matcher først en eksisterende konto ved hjelp av en e-postadresse. Det er praktisk, særlig når Odoo og Microsoft allerede bruker samme bedrifts-e-post. Det er ikke en varig identitetsnøkkel.
Microsoft advarer i sin ID token claims reference om at e-postadresser, telefonnumre og user principal names kan endres og kan gjenbrukes. Microsoft anbefaler uforanderlige claims som sub eller oid, med tid der tenant-kontekst er nødvendig, for pålitelig identifisering.
Et sikrere mønster er:
- Tillat bare en forventet tenant og et godkjent audience.
- Bruk e-post for en kontrollert første matching der det er passende.
- Avvis tvetydige eller dupliserte treff.
- Lagre den uforanderlige Microsoft-identiteten og tenant-identifikatorene etter kobling.
- Bruk disse uforanderlige verdiene for fremtidige innlogginger.
For tilgang med flere tenanter er tenant-kontekst avgjørende. Den samme personen kan ha forskjellige object identifiers i ulike tenanter, og tilgang fra én tenant skal ikke stille arve tillatelser knyttet til en annen.
Forstå overage-tilfellet for gruppe-claims
Gruppe-claims er praktiske, men de er ikke ubegrensede. Microsoft dokumenterer en grense på 200 gruppe-Object IDs i en JWT. Når et medlemskap for en bruker overstiger grensen, utelater Entra den vanlige gruppelisten og returnerer en overage-indikator som leder applikasjonen til å spørre Microsoft Graph. Se groups overage guidance.
Dette er viktig hvis en integrasjon tilbyr gruppemapping uten forhøyede Microsoft Graph API-tillatelser. En bruker med omfattende gruppemedlemskap får kanskje ikke det forventede settet med gruppe-claims.
Før du stoler på direkte gruppemapping, bekreft hvordan overage håndteres. Alternativer inkluderer mindre app-spesifikke grupper, app-roller, claim-filtrering eller et Graph-basert oppslag med minst mulig privilegium.
Synkronisering ved innlogging er ikke provisjonering i sanntid
En SSO-modul kan sammenligne gjeldende Entra-claims med konfigurerte Odoo-mappinger når en bruker logger inn. Det er nyttig fordi tilgang kan justeres under en normal autentiseringshendelse.
Det er ikke det samme som kontinuerlig provisjonering. Hvis en ansatt fjernes fra en Entra-gruppe mens en Odoo-økt er aktiv, kan den økten fortsette til utlogging, utløp eller en annen tilbakekallingskontroll gjelder. Hvis en tidligere ansatt aldri logger inn igjen, arkiverer ikke en synkroniseringsprosess ved innlogging Odoo-kontoen i seg selv.
Microsoft Entra ID Governance tilbyr Lifecycle Workflows for joiner, mover og leaver-prosesser, inkludert å deaktivere kontoer og fjerne tilgangstildelinger. Se Microsofts Lifecycle Workflows guidance. Disse funksjonene krever lisensiering for Microsoft Entra ID Governance eller Microsoft Entra Suite.
Automatisering av livssyklus kan forbedre tilstanden til kilden for identitet, men den oppdaterer fortsatt ikke Odoo med mindre en integrasjon bruker endringen. Din offboarding-prosedyre bør eksplisitt dekke tilbakekall av Odoo-økter og kontotilstand.
Bygg en reviderbar kartleggingsmodell
Hold antallet kartlegginger oversiktlig. For hver gruppe eller rolle, bruk en stabil identifikator og en beskrivende tekst på et menneskelig lesbart språk. Registrer hvorfor den tilknyttede Odoo-tilgangen finnes, hvem som godkjente den og når den sist ble gjennomgått.
Test minst disse tilfellene:
- Eksisterende bruker med én forventet kartlegging.
- Bruker uten godkjent kartlegging eller med en ikke-tillatt tenant.
- Ny bruker som tillates ved første innlogging.
- Bruker fjernet fra en kartlagt gruppe eller med mange gruppemedlemskap.
- Omdøpt bruker hvis uforanderlige identitet ikke har endret seg.
- Deaktivert Microsoft-konto med en eksisterende Odoo-økt.
Påloggingshendelser bør hjelpe administratorer med å diagnostisere utfallet av claims og mapping uten å eksponere tokens, legitimasjon eller hemmeligheter. Logger bør identifisere tilkoblingen og resultatet, men sensitive verdier bør maskeres.
Kombiner mapping med autentiseringspolicy
Gruppe- og rollemapping styrer Odoo-autorisasjon. Microsoft Entra Conditional Access styrer om Microsoft vil fullføre autentiseringen under de gjeldende betingelsene. De to lagene utfyller hverandre.
For eksempel kan en Entra-approlle mappe til en Odoo-finansgruppe, mens Conditional Access krever en phishing-resistent autentiseringsstyrke for brukerne som er tildelt den rollen. Les hvordan Microsoft Entra Conditional Access styrker Odoo-pålogging for autentiseringspolicy-delen.
For kunder og partnere bør du ikke automatisk gjenbruke ansattmappinger. En egen målgruppe og et portalorientert design kan være tryggere. Se Microsoft Entra External ID for Odoo-kunder og partnere.
Map godkjent Microsoft-tilgang inn i Odoo 19
Vår Microsoft Entra SSO for Odoo-modul støtter mapping av konfigurerte Entra-sikkerhetsgruppe-Object ID-er eller approller til valgte Odoo-tilgangsgrupper. Den kan synkronisere disse mappingene ved pålogging, koble til en kontrollert eksisterende konto og opprette godkjente ansatte- eller portalbrukere i henhold til tilkoblingstypen.
Modulen erstatter ikke tilgangsstyring, tilbakekalling av økter eller en dokumentert strategi for overforbruk. Gjennomgå gruppeskalaen, kravene til identitetsbinding og Odoo-tillatelsesmodellen før du aktiverer mappinger. Hvis disse grunnlagene er klare, gir modulen en veiledet måte å koble dem sammen på.