Odoo pogosto hrani informacije, ki so pomembne za celotno organizacijo: evidence strank, prodajne aktivnosti, račune, podatke o zaposlenih, projekte, zaloge in operativne dokumente. Dostop do teh informacij si zasluži enako pozornost kot dostop do e-pošte, datotek in drugih ključnih poslovnih sistemov.

Kljub temu lahko Odoo postane identitetni otok. Zaposleni imajo lahko eno geslo za Microsoft 365 in drugo za Odoo. Skrbniki bodo morda morali dostop upravljati na več ločenih mestih. Ko nekdo zamenja vlogo ali zapusti podjetje, je lahko postopek odvisen od tega, ali je kontrolni seznam pravilno izpolnjen v vsaki aplikaciji.

Microsoftova enotna prijava organizacijam ponuja še eno možnost. S povezavo Odoo z Microsoft Entra ID se lahko uporabniki avtentificirajo prek svojega Microsoft računa, podjetje pa lahko uveljavi že vzpostavljene Microsoftove kontrole identitete na poti prijave v Odoo.

Vaša Microsoftova temeljna identiteta morda že obstaja

Če vaša organizacija uporablja Microsoft 365, običajno že ima Microsoft Entra delovni najemnik. Microsoft pojasnjuje, da se delovni najemnik ustvari za zaposlene, notranje aplikacije in organizacijske vire, ko se podjetje prijavi za Microsoftovo storitev v oblaku, kot je Microsoft 365. To naredi Entra naravnega ponudnika identitete, ki ga je smiselno upoštevati za Odoo, namesto da uvajate še en samostojen sistem računov. Glejte Microsoftovo razlago konfiguracij delovnega in zunanjega najemnika.

Odoo prav tako prepoznava ta primer uporabe. Uradna dokumentacija za prijavo Odoo 19 z Microsoft Azure opisuje, kako se lahko uporabniki Odoo prijavijo z Microsoft računi. Prav tako jasno pove, da je konfiguracija potrebna na obeh straneh integracije.

Večja prednost je, da Microsoft postane točka, kjer lahko organizacija uporabi politiko avtentikacije, preden se seja Odoo sploh začne.

Dodajte močnejšo avtentikacijo na pot prijave v Odoo

Večfaktorska avtentikacija Microsoft Entra lahko zahteva dve ali več oblik preverjanja. Ti dejavniki lahko vključujejo nekaj, kar uporabnik ve, nekaj, kar ima v lasti, ali nekaj, kar je. Microsoft opisuje, kako se izziv obravnava kot del postopka prijave Entra v svojem pregledu MFA.

Ko Odoo delegira prijavo na Entra, lahko organizacija zahteva odobren način MFA. Prav tako lahko izbrane uporabnike usmeri k metodam, odpornim proti ribarjenju, kot so passkeys, varnostni ključi FIDO2, Windows Hello for Business ali avtentikacija na podlagi potrdil. Microsoft te metode priporoča v svojih navodilih za avtentikacijo.

Ta razlika je pomembna. Običajna MFA je praviloma močnejša od dostopa samo z geslom, vendar niso vse metode MFA odporne proti ribarjenju. NIST navaja, da gesla niso odporna proti ribarjenju in da ročno vnesene enkratne kode prav tako niso odporne proti ribarjenju, ker jih lahko napadalec posreduje naprej. NIST kot primer odpornosti proti ribarjenju zaradi vezave na domeno navaja WebAuthn, ki ga uporabljajo overjevalniki FIDO2. Podrobnosti so na voljo v NIST SP 800-63B-4.

Integracija SSO podjetju omogoča pot, da te Entra zmogljivosti uporabi za Odoo. Podjetje mora še vedno omogočiti in uveljaviti ustrezne politike.

Odločitve o dostopu sprejemajte z več konteksta

Pogojni dostop Microsoft Entra lahko ovrednoti signale, kot so uporabnik, skupina, aplikacija, lokacija, stanje naprave in tveganje prijave. Nato lahko blokira dostop ali zahteva kontrole, vključno z MFA, določeno jakostjo avtentikacije ali skladno napravo. Microsoft imenuje Conditional Access svoj Zero Trust mehanizem pravilnikov in dokumentira razpoložljive signale ter odločitve v pregledu Conditional Access.

Za uvedbo Odoo lahko to podpira politike, kot so:

  • Zahteva po MFA za skrbnike Odoo in uporabnike financ.
  • Zahteva po avtentikaciji, odporni proti ribarjenju, za privilegirane vloge.
  • Blokada prijave v Odoo z lokacij, ki jih podjetje ne pokriva.
  • Zahteva po skladni ali upravljani napravi za občutljiv notranji dostop.
  • Uporaba strožje politike za zunanje ali bolj tvegane prijave.

To so primeri, ne univerzalne nastavitve. Politika, ki je primerna za interno finančno ekipo, je morda neustrezna za portal za stranke. Pred izbiro kontrol preberite kako Conditional Access krepi prijavo v Odoo.

Pogojni dostop ima tudi zahteve glede licenciranja. Za Conditional Access je potreben Microsoft Entra ID P1, medtem ko tveganostno temelječe politike zahtevajo P2. Microsoft 365 Business Premium vključuje zmožnosti Conditional Access. Licenciranje in trenutno razpoložljivost funkcij je treba preveriti glede na Microsoftovo uradno dokumentacijo.

Približajte identiteto in dostop do Odoo

Avtentikacija odgovori na vprašanje, kdo je uporabnik. Avtorizacija Odoo pa še vedno določa, kaj ta uporabnik lahko naredi.

Dobro zasnovana integracija lahko odobreno Microsoft identiteto poveže z obstoječim računom Odoo, ob prvi prijavi ustvari odobren račun in izbrane Entra skupine ali vloge aplikacije preslika v skupine dostopa Odoo. To lahko zmanjša podvojeno administracijo in olajša pregled odločitev o dostopu.

Pomembno je ohraniti mejo med identiteto in avtorizacijo. Odstranitev nekoga iz skupine Entra bi morala vplivati na preslikavo Odoo v skladu z dokumentiranim vedenjem sinhronizacije integracije, vendar ne pomeni nujno takojšnjega preklica obstoječe seje Odoo. Če je dostop sinhroniziran ob prijavi, sprememba začne veljati ob naslednji prijavi uporabnika, razen če ne posreduje drug nadzor seje.

Tudi ujemanje e-pošte zahteva previdnost. Microsoft opozarja, da se e-poštni naslovi in UPN lahko spremenijo ali ponovno uporabijo. Njegova navodila za ID token claims za trajno identiteto priporočajo nespremenljive identifikatorje, kot sta sub ali oid, po potrebi skupaj s kontekstom najemnika. E-pošta je lahko koristna pri nadzorovanem prvem povezovanju, vendar ne bi smela biti trajni identifikator identitete.

Za bolj poglobljen načrt dostopa preberite centralizacijo dostopa do Odoo s skupinami Entra in vlogami aplikacij.

Česa Microsoft SSO ne nadomesti

Microsoft SSO ne nadomesti posodobitev Odoo, vlog z najmanjšimi privilegiji, pravil za zapise, varnega gostovanja, varnostnih kopij, nadzora, upravljanja sej ali odzivanja na incidente. Uradna dokumentacija Odoo tudi opozarja baze podatkov, gostovane na Odoo.com, da ne uporabljajo njegove dokumentirane poti OAuth za lastnika baze ali skrbnika, ker lahko to vpliva na upravljanje portala. Pred uvedbo potrdite lastništvo in nujno administracijo.

Varnejši način za uvedbo Microsoft prijave

Začnite z manjšo testno skupino. Preverite metapodatke za odkrivanje Microsofta in podpisne ključe, potrdite povratni URL, preizkusite ujemanje računov ter preverite izide za nove in nepooblaščene uporabnike. Rezervirajte skrbniško reševalno pot, dokler pretok ni preizkušen od začetka do konca.

Nato dokumentirajte pravilnike, ki veljajo za Odoo, licence Entra, ki jih zahtevajo, kako spremembe skupin ali vlog dosežejo Odoo, in kako se bo podpora odzvala, če prijava Microsoft ne bo na voljo. Če morajo dostopati stranke in partnerji, razmislite o ločeni zasnovi identitete za stranke, namesto da bi jih obravnavali kot zaposlene. Naš vodnik o Microsoft Entra External ID za stranke in partnerje Odoo pojasnjuje to razliko.

Uvedite vodeno Microsoft SSO v Odoo 19

Naš modul Microsoft Entra SSO za Odoo zagotavlja vodeno povezavo za Odoo 19, vključno z zaposlenimi in zunanjimi uporabniki, nadzorovano prvo prijavo, preslikavo skupin in vlog aplikacij, testiranje prijave ter interaktivno prijavo samo prek Microsofta po validaciji. Uporablja avtorizacijski kodo potek OpenID Connect z PKCE.

Modul ne izbere vaše varnostne politike. Vaša organizacija ostaja odgovorna za konfiguracijo Entra, zasnovo dostopa do Odoo in uvedbo.