Single sign-on besvarar en autentiseringsfråga: har Microsoft verifierat den här användaren enligt organisationens policy? Det besvarar inte varje auktoriseringsfråga i Odoo.
En autentiserad användare kan behöva åtkomst till försäljning men inte redovisning, projekt men inte lön, eller en kundportal men inte det interna gränssnittet. De besluten ligger kvar hos Odoo. Microsoft Entra-grupper och applikationsroller kan ge betrodda indata för att göra dem mer konsekventa.
Grupper och approller har olika syften
Microsoft Entra-grupper hör till tenantet. De kan representera avdelningar, arbetsfunktioner, projekt eller säkerhetsgränser. Applikationsroller hör till en viss appregistrering och beskriver roller som är meningsfulla för just den applikationen.
Microsofts dokumentation om approller förklarar att approller kan tilldelas användare eller grupper. När en tilldelad användare loggar in kan Entra inkludera de beviljade rollerna i en roles-claim. Microsoft anger också att approller och grupper inte utesluter varandra.
Detta ger en Odoo-åtkomstdesign två huvudmönster:
- Mappa stabila Entra-säkerhetsgruppers Object ID direkt till valda Odoo-grupper.
- Definiera Odoo-fokuserade approller i Entra-applikationen, tilldela användare eller grupper till dessa roller och mappa de resulterande rollvärdena till Odoo-grupper.
Direkt mappning fungerar bra med styrda säkerhetsgrupper. Approller kan ge en renare applikationsgräns eftersom deras avsikt följer med appregistreringen i stället för att bero på tenantspecifika namn.
Börja med Odoo:s faktiska åtkomstmodell
Börja inte med att kopiera varje Microsoft-grupp in i Odoo. Börja med de Odoo-behörigheter som verksamheten verkligen behöver.
Lista de Odoo-grupper som ger väsentliga möjligheter. För varje grupp, dokumentera:
- Affärssyftet med åtkomsten.
- Vem som ansvarar för att godkänna den.
- Den Entra-grupp eller approll som representerar godkännandet.
- Hur snabbt en ändring ska nå Odoo och vad som händer med en aktiv session efter borttagning.
Använd principen om minsta privilegium. En bred avdelningsgrupp kan vara praktisk, men den kan ge mer Odoo-åtkomst än varje medlem behöver. En mindre Odoo-specifik säkerhetsgrupp eller approll är ofta lättare att granska.
Behandla identitetskoppling som en säkerhetskontroll
Många system matchar initialt ett befintligt konto med hjälp av en e-postadress. Det är praktiskt, särskilt när Odoo och Microsoft redan använder samma företagsadress. Det är inte en beständig identitetsnyckel.
Microsoft varnar i sin referens för ID-tokenclaims för att e-postadresser, telefonnummer och user principal names kan ändras och återanvändas. Microsoft rekommenderar oföränderliga claims som sub eller oid, med tid när tenantkontext krävs, för tillförlitlig identifiering.
Ett säkrare mönster är:
- Tillåt endast en förväntad tenant och godkänd audience.
- Använd e-post för en kontrollerad första matchning när det är lämpligt.
- Avvisa tvetydiga eller dubbla matchningar.
- Spara den oföränderliga Microsoft-identiteten och tenantidentifierarna efter länkning.
- Använd dessa oföränderliga värden för framtida inloggningar.
För åtkomst i flera tenant är tenantkontexten avgörande. Samma person kan ha olika objektidentifierare i olika tenant, och åtkomst från ett tenant ska inte i tysthet ärva behörigheter kopplade till ett annat.
Förstå fallet med group-claim-överskjutning
Group claims är praktiska, men de är inte obegränsade. Microsoft dokumenterar en gräns på 200 gruppers Object ID i en JWT. När en användares medlemskap överskrider gränsen utelämnar Entra den normala grupplistan och returnerar en överflödesindikator som leder applikationen till att fråga Microsoft Graph. Se vägledning om groups overage.
Detta spelar roll om en integration annonserar gruppmappning utan förhöjda behörigheter för Microsoft Graph API. En användare med omfattande gruppmedlemskap kanske inte får den förväntade uppsättningen group claims.
Innan du förlitar dig på direkt gruppmappning, bekräfta hur överflödet hanteras. Alternativ inkluderar mindre appspecifika grupper, approller, claim-filtrering eller en Graph-baserad uppslagning med samtycke enligt minsta privilegium.
Synkronisering vid inloggning är inte provisionering i realtid
En SSO-modul kan jämföra aktuella Entra-claims med konfigurerade Odoo-mappningar när en användare loggar in. Det är användbart eftersom åtkomsten kan anpassas vid en vanlig autentiseringshändelse.
Det är inte samma sak som kontinuerlig provisionering. Om en anställd tas bort från en Entra-grupp medan en Odoo-session är aktiv kan den sessionen fortsätta tills utloggning, utgång eller en annan återkallningskontroll tillämpas. Om en före detta anställd aldrig loggar in igen arkiverar inte en synkroniseringsprocess vid inloggning i sig Odoo-kontot.
Microsoft Entra ID Governance erbjuder Lifecycle Workflows för processer för joiner, mover och leaver, inklusive att inaktivera konton och ta bort åtkomsttilldelningar. Se Microsofts vägledning för Lifecycle Workflows. Dessa funktioner kräver licens för Microsoft Entra ID Governance eller Microsoft Entra Suite.
Livscykelautomation kan förbättra källidentitetens tillstånd, men den uppdaterar fortfarande inte Odoo om inte en integration tar emot ändringen. Din offboardingprocess bör uttryckligen omfatta återkallning av Odoo-sessioner och kontots status.
Bygg en granskbar mappningsmodell
Håll antalet mappningar överskådligt. För varje grupp eller roll, använd en stabil identifierare och en beskrivning i klarspråk. Dokumentera varför den associerade Odoo-åtkomsten finns, vem som godkände den och när den senast granskades.
Testa minst dessa fall:
- Befintlig användare med en förväntad mappning.
- Användare utan godkänd mappning eller med en otillåten tenant.
- Ny användare som tillåts vid första inloggningen.
- Användare som tagits bort från en mappad grupp eller som har många gruppmedlemskap.
- Bytt namn på användaren vars oföränderliga identitet inte har ändrats.
- Inaktiverat Microsoft-konto med en befintlig Odoo-session.
Inloggningshändelser bör hjälpa administratörer att diagnostisera claim- och mappningsresultat utan att exponera tokens, autentiseringsuppgifter eller hemligheter. Loggar bör identifiera anslutningen och resultatet, men känsliga värden bör maskeras.
Kombinera mappning med autentiseringspolicy
Grupp- och rollmappning styr Odoo-auktorisering. Microsoft Entra Conditional Access styr om Microsoft slutför autentiseringen under de aktuella förutsättningarna. De två lagren kompletterar varandra.
Till exempel kan en Entra-approll mappas till en Odoo-ekonomigrupp, medan Conditional Access kräver en phishing-resistent autentiseringsstyrka för användarna som tilldelats rollen. Läs hur Microsoft Entra Conditional Access stärker Odoo-inloggning för autentiseringspolicy-sidan.
För kunder och partners, återanvänd inte automatiskt medarbetarmappningar. En separat målgrupps- och portalorienterad design kan vara säkrare. Se Microsoft Entra External ID för Odoo-kunder och partners.
Mappa godkänd Microsoft-åtkomst till Odoo 19
Vårt Microsoft Entra SSO för Odoo-modulen stöder mappning av konfigurerade Entra-säkerhetsgruppers Object IDs eller applikationsroller till valda Odoo-åtkomstgrupper. Den kan synkronisera dessa mappningar vid inloggning, koppla ett kontrollerat befintligt konto och skapa godkända användare för medarbetare eller portal enligt anslutningstypen.
Modulen ersätter inte åtkomststyrning, sessionsåterkallelse eller en dokumenterad strategi för överskridande. Granska din gruppskala, krav på identitetsbindning och Odoo:s behörighetsmodell innan du aktiverar mappningar. Om dessa grunder är klara, ger modulen ett vägledande sätt att koppla ihop dem.