Single sign-on besvarer et autentificeringsspørgsmål: har Microsoft verificeret denne bruger i henhold til organisationens politik? Det besvarer ikke alle autorisationsspørgsmål i Odoo.

En autentificeret bruger kan have brug for adgang til salg, men ikke regnskab, projekter, men ikke løn, eller en kundeportal, men ikke den interne grænseflade. Disse beslutninger forbliver Odoos ansvar. Microsoft Entra-grupper og applikationsroller kan give pålidelige input, så de bliver mere ensartede.

Grupper og app-roller tjener forskellige formål

Microsoft Entra-grupper hører til i tenant'en. De kan repræsentere afdelinger, jobfunktioner, projekter eller sikkerhedsgrænser. Applikationsroller hører til en bestemt app-registrering og beskriver roller, der er meningsfulde for den pågældende applikation.

Microsofts dokumentation om app-roller forklarer, at app-roller kan tildeles til brugere eller grupper. Når en tildelt bruger logger ind, kan Entra inkludere de tildelte roller i en roles-claim. Microsoft siger også, at app-roller og grupper ikke udelukker hinanden.

Det giver et Odoo-adgangsdesign to hovedmønstre:

  • Kortlæg stabile Entra-sikkerhedsgruppers Object IDs direkte til udvalgte Odoo-grupper.
  • Definér Odoo-fokuserede app-roller i Entra-applikationen, tildel brugere eller grupper til disse roller, og kortlæg de resulterende rolleværdier til Odoo-grupper.

Direkte kortlægning fungerer godt med styrede sikkerhedsgrupper. App-roller kan give en renere applikationsgrænse, fordi deres hensigt følger app-registreringen i stedet for at afhænge af tenant-specifikke navne.

Start med Odoos faktiske adgangsmodel

Begynd ikke med at kopiere alle Microsoft-grupper ind i Odoo. Begynd med de Odoo-rettigheder, forretningen reelt har brug for.

Liste over de Odoo-grupper, der giver væsentlige funktioner. For hver af dem, dokumentér:

  • Forretningsformålet med adgangen.
  • Den person, der er ansvarlig for at godkende den.
  • Den Entra-gruppe eller app-rolle, der repræsenterer godkendelsen.
  • Hvor hurtigt en ændring skal nå Odoo, og hvad der sker med en aktiv session efter fjernelse.

Brug princippet om mindst mulige rettigheder. En bred afdelingsgruppe kan være praktisk, men den kan give mere Odoo-adgang, end hvert medlem har brug for. En mindre Odoo-specifik sikkerhedsgruppe eller app-rolle er ofte lettere at revidere.

Behandl identitetsbinding som en sikkerhedskontrol

Mange systemer matcher i første omgang en eksisterende konto ved hjælp af en e-mailadresse. Det er praktisk, især når Odoo og Microsoft allerede bruger den samme virksomheds-e-mail. Det er ikke en holdbar identitetsnøgle.

Microsoft advarer i sin ID token claims reference om, at e-mailadresser, telefonnumre og user principal names kan ændres og kan genbruges. Microsoft anbefaler uforanderlige claims som sub eller oid, med tid hvor der kræves tenant-kontekst, for pålidelig identifikation.

Et sikrere mønster er:

  1. Tillad kun en forventet tenant og en godkendt audience.
  2. Brug e-mail til et kontrolleret førstegangs-match, hvor det er relevant.
  3. Afvis tvetydige eller duplikerede matches.
  4. Gem den uforanderlige Microsoft-identitet og tenant-identifikatorerne efter sammenknytning.
  5. Brug disse uforanderlige værdier ved fremtidige login.

Ved adgang på tværs af flere tenants er tenant-kontekst afgørende. Den samme person kan have forskellige objektidentifikatorer i forskellige tenants, og adgang fra én tenant bør ikke stille og roligt arve rettigheder, der er knyttet til en anden.

Forstå overagescenariet for gruppe-claims

Gruppe-claims er praktiske, men de er ikke ubegrænsede. Microsoft dokumenterer en grænse på 200 gruppe-Object IDs i en JWT. Når en brugers medlemskab overstiger grænsen, udelader Entra den normale gruppliste og returnerer en overage-indikator, som leder applikationen til at forespørge Microsoft Graph. Se vejledningen om gruppe-overage.

Det er vigtigt, hvis en integration markedsfører gruppemapping uden forhøjede Microsoft Graph API-rettigheder. En bruger med omfattende gruppemedlemskab modtager muligvis ikke det forventede sæt af gruppe-claims.

Før du stoler på direkte gruppemapping, skal du bekræfte, hvordan overage håndteres. Muligheder inkluderer mindre app-specifikke grupper, app-roller, claim-filtrering eller et Graph-baseret opslag med mindst mulige rettigheders samtykke.

Synkronisering ved login er ikke provisionering i realtid

Et SSO-modul kan sammenligne aktuelle Entra-claims med konfigurerede Odoo-mappinger, når en bruger logger ind. Det er nyttigt, fordi adgangen kan blive justeret under en normal autentificeringshændelse.

Det er ikke det samme som løbende provisionering. Hvis en medarbejder fjernes fra en Entra-gruppe, mens en Odoo-session er aktiv, kan den session fortsætte, indtil der logges ud, den udløber, eller en anden tilbagekaldelseskontrol træder i kraft. Hvis en tidligere medarbejder aldrig logger ind igen, arkiverer en login-synkroniseringsproces ikke i sig selv Odoo-kontoen.

Microsoft Entra ID Governance tilbyder Lifecycle Workflows til joiner-, mover- og leaver-processer, inklusive deaktivering af konti og fjernelse af adgangstildelinger. Se Microsofts vejledning om Lifecycle Workflows. Disse funktioner kræver Microsoft Entra ID Governance- eller Microsoft Entra Suite-licensering.

Livscyklusautomatisering kan forbedre kildens identitetstilstand, men den opdaterer stadig ikke Odoo, medmindre en integration forbruger ændringen. Din offboarding-procedure bør udtrykkeligt dække tilbagekaldelse af Odoo-sessioner og kontotilstand.

Opbyg en auditerbar mappingsmodel

Hold antallet af mappinger overskueligt. For hver gruppe eller rolle skal du bruge en stabil identifikator og en beskrivende tekst på menneskeligt sprog. Registrér, hvorfor den tilknyttede Odoo-adgang findes, hvem der godkendte den, og hvornår den sidst blev gennemgået.

Test mindst disse tilfælde:

  • Eksisterende bruger med én forventet mapping.
  • Bruger uden godkendt mapping eller med en ikke-tilladt tenant.
  • Ny bruger, der tillades ved første login.
  • Bruger fjernet fra en mappet gruppe eller med mange gruppemedlemskaber.
  • Omdøbt bruger, hvis uforanderlige identitet ikke har ændret sig.
  • Deaktiveret Microsoft-konto med en eksisterende Odoo-session.

Logonhændelser bør hjælpe administratorer med at diagnosticere resultater af claims og mapping uden at afsløre tokens, legitimationsoplysninger eller hemmeligheder. Logger bør identificere forbindelsen og resultatet, men følsomme værdier skal maskeres.

Kombinér mapping med godkendelsespolitik

Gruppe- og rollemapping styrer Odoo-godkendelse. Microsoft Entra Conditional Access styrer, om Microsoft vil fuldføre godkendelsen under de aktuelle betingelser. De to lag supplerer hinanden.

For eksempel kan en Entra-approlle maps til en Odoo-finansgruppe, mens Conditional Access kræver en phishing-resistent godkendelsesstyrke for de brugere, der er tildelt den rolle. Læs hvordan Microsoft Entra Conditional Access styrker Odoo-logon for den godkendelsespolitiske side.

For kunder og partnere bør du ikke automatisk genbruge medarbejdermappinger. Et separat målgruppe- og portalorienteret design kan være sikrere. Se Microsoft Entra External ID til Odoo-kunder og partnere.

Map godkendt Microsoft-adgang til Odoo 19

Vores Microsoft Entra SSO for Odoo-modul understøtter mapping af konfigurerede Entra-sikkerhedsgruppe-objekt-id'er eller applikationsroller til udvalgte Odoo-adgangsgrupper. Det kan synkronisere disse mappinger ved logon, knytte en styret eksisterende konto og oprette godkendte medarbejder- eller portalbrugere i henhold til forbindelsestypen.

Modulet erstatter ikke adgangsstyring, sessionstilbagekaldelse eller en dokumenteret strategi for overskridelse. Gennemgå din gruppeskala, krav til identitetsbinding og Odoo-tilladelsesmodel, før du aktiverer mappinger. Hvis disse grundlæggende elementer er klare, giver modulet en guidet måde at forbinde dem på.