Odoo-portaler giver kunder og partnere adgang til relevante dokumenter, transaktioner og tjenester. Det rejser et identitetsdesignspørgsmål: bør eksterne brugere dele medarbejderkataloget og adgangsmodellen?
Nogle gange er en gæstekonto i en workforce-tenant passende. I større skala, eller hvor der kræves et brandet kundelogin og selvbetjent registrering, tilbyder Microsoft Entra External ID en dedikeret model for kundeidentitet og adgangsstyring.
Forbindelse af denne model til Odoo kan understøtte en klarere grænse mellem interne brugere og portalbrugere. Grænsen kræver stadig eksplicit adgang, kontooprettelse og Odoo-autoriseringsregler.
Workforce- og eksterne tenants er designet til forskellige målgrupper
Microsoft definerer en workforce-tenant som miljøet for medarbejdere, interne forretningsapplikationer og organisatoriske ressourcer. Den kan også indeholde inviterede forretningspartnere og gæster. En external tenant er en separat konfiguration til applikationer, der tilbydes til forbrugere og erhvervskunder. Microsoft beskriver forskellen i sin vejledning om tenantkonfiguration.
En external tenant indeholder sin egen kundekatalog og appregistreringer. External ID tilføjer selvbetjent registrering, login, nulstilling af adgangskode, kontoadministration og federation med identitetsudbydere. Oversigten over External ID forklarer den dedikerede model.
Denne adskillelse kan hjælpe en organisation med at undgå at behandle en kunde som en medarbejder, blot fordi begge har brug for adgang til en Odoo-tjeneste.
Vælg målgruppen, før du konfigurerer login
Der er mindst tre forskellige Odoo-målgrupper at overveje:
Medarbejdere og interne brugere
Disse brugere hører normalt hjemme i organisationens workforce-tenant. Hvis de får adgang til Odoo, har de som regel brug for interne Odoo-brugerkonti med nøje tilknyttede adgangsgrupper.
Personer fra godkendte partnerorganisationer
Nogle virksomheder ønsker brugere fra en defineret liste af kunde- eller partner-Entra-tenants. En multi-tenant workforce-forbindelse med en præcis tenant-allowlist kan være passende, når hver organisation er kendt, og adgang er godkendt kontraktligt.
Tenantvalidering er afgørende. Det er ikke nok kun at matche et e-maildomæne, fordi domæner og e-mailadresser kan ændres. Valider tokenets tenant og de uforanderlige subject- eller object-identifikatorer i henhold til forbindelsesdesignet.
Kunder og eksterne brugere
For kundevendte applikationer kan en External ID-tenant give et separat katalog og en separat loginoplevelse. Odoo-konti, der oprettes til denne målgruppe, bør normalt være portalbrugere, ikke interne brugere.
Disse modeller bør konfigureres som separate forbindelser, når deres adgangs- og Odoo-kontoregler er forskellige. En enkelt bred forbindelse er sværere at forstå og lettere at konfigurere forkert.
External ID understøtter et kundeloginforløb
External ID-brugerflows definerer kundernes autentificeringsmetoder og de oplysninger, der indsamles under tilmelding. Et flow knyttes til registrerede applikationer for at aktivere tilmelding og login. Microsoft dokumenterer dette i tilføjelse af en applikation til et External ID-brugerflow.
External ID kan understøtte lokale konti og federation med identitetsudbydere, herunder Microsoft Entra ID og brugerdefinerede OpenID Connect-udbydere. Indbyggede og brugerdefinerede attributter kan indsamles under tilmelding, som beskrevet i Microsofts vejledning om kundeattributter.
Indsaml kun de oplysninger, som Odoo reelt har brug for, og dokumentér formålet, opbevaringsperioden og den privatlivsmæssige behandling af hver attribut.
Standardtilladelser hjælper med at bevare adskillelsen
Microsoft oplyser, at brugere i external tenants starter med begrænsede standardtilladelser. De kan som regel få adgang til applikationer og administrere deres egen profil, men får ikke brede rettigheder til katalogadministration. Se standardtilladelser i external tenants.
Denne kataloggrænse konfigurerer ikke automatisk Odoo-portalrettigheder. Odoo styrer stadig, hvilke poster en portalbruger kan se, gennem egne adgangsrettigheder og record rules. Test portaloplevelsen med repræsentative kundeposter og mere end én virksomhed eller konto for at sikre, at data er korrekt isoleret.
Opryk ikke en nyligt oprettet ekstern bruger til en intern Odoo-bruger, medmindre der findes en separat, godkendt forretningsproces.
Brug et moderne, valideret OpenID Connect-flow
Microsoft understøtter OAuth 2.0 authorization code flow med Proof Key for Code Exchange og OpenID Connect til serverbaserede webapplikationer. Deres dokumentation om authorization code flow beskriver den understøttede kombination.
OIDC udvider OAuth 2.0 til autentificering. Microsoft udgiver discovery-metadata, endepunktsdetaljer og offentlige signeringsnøgler. De anbefaler også at validere det returnerede token og kontrollere en nonce for at reducere risikoen for replay-angreb. Se OpenID Connect på Microsoft identity platform.
En sikker integration bør validere den forventede issuer, audience, signatur, tenantkontekst og nonce. PKCE erstatter ikke tokenvalidering, præcis callback-konfiguration, TLS eller beskyttelse af client secret.
Grundlæggende login kan anmode om standard OIDC-scopes såsom openid, profile og email. Microsoft bemærker, at disse scopes ligger på Microsoft Graph, og anbefaler kun at anmode om de tilladelser, applikationen har brug for. Se Microsoft identity platform-scopes. Derfor er en præcis produktpåstand "ingen Microsoft Graph API-tilladelser med høj privilegieniveau for standard login," snarere end en generel påstand om, at Graph ikke er involveret.
Beslut, hvordan eksterne brugere får adgang til Odoo
Før du aktiverer første login, skal du definere:
- Om selvregistrering er åben, eller om godkendelse er påkrævet.
- Hvilke tenants eller identitetsudbydere der er tilladt.
- Om en eksisterende Odoo-portal konto kan tilknyttes.
- Hvilken uforanderlig Microsoft-identifikator der gemmes efter tilknytning.
- Hvilket Odoo-selskab og partnerregister brugeren tilhører.
- Hvilke portalgrupper og postregler der gælder.
- Hvad der sker, når adgangen trækkes tilbage.
- Hvordan en aktiv Odoo-session tilbagekaldes.
Automatisk oprettelse af konti kan reducere administrationen, men det bør kun ske, når identiteten opfylder forbindelseens adgangsregler. En vellykket Microsoft-godkendelse beviser kontrol over den accepterede identitet. Den beviser ikke i sig selv, at personen bør se en bestemt kundes Odoo-poster.
Planlæg kundesupport og gendannelse
Eksterne brugere har måske ikke en intern helpdesk. Offentliggør en supportvej, og identificer, hvem der administrerer identiteten. Test scenarier for nulstilling af adgangskode, gendannelse, fjernelse af tenant og ændret e-mail. Bevar diagnostiske hændelser nyttige, men anonymiserede.
Hvis dit umiddelbare behov er medarbejderadgang, så læs hvorfor du bør beskytte din Odoo-instans med Microsoft SSO. For interne tilladelser, se centralisering af Odoo-adgang med Entra-grupper og app-roller.
Kobl eksterne målgrupper til Odoo 19
Vores Microsoft Entra SSO til Odoo-modul understøtter separate forbindelser for medarbejdere, godkendte organisationer og Microsoft Entra External ID-kundemålgrupper. External ID-forbindelser opretter som standard portalbrugere, mens workforce-forbindelser opretter interne brugere. Den guidede opsætning validerer opdagelsesoplysninger og signeringsnøgler, og kræver derefter en interaktiv test, før Microsoft-login aktiveres.
Modulet afgør ikke, hvem der skal få adgang, eller hvilke kundeposter de պետք should see. Det er fortsat forretnings- og Odoo-adgangsbeslutninger. Gennemgå modulet, hvis du har brug for en kontrolleret bro mellem Microsoft-kundeidentitet og en Odoo 19-portal, med målgruppespecifik kontohåndtering i stedet for en enkelt, udifferentieret loginvej.