Odoo dažnai saugo informaciją, kuri svarbi visai organizacijai: klientų įrašus, pardavimų veiklą, sąskaitas, darbuotojų duomenis, projektus, atsargas ir veiklos dokumentus. Prieiga prie šios informacijos nusipelno tokio pat dėmesio kaip prieiga prie el. pašto, failų ir kitų pagrindinių verslo sistemų.

Vis dėlto Odoo gali tapti tapatybės sala. Darbuotojai gali turėti vieną slaptažodį Microsoft 365 ir kitą Odoo. Administratoriams gali tekti valdyti prieigą atskirai. Kai žmogus pakeičia pareigas arba palieka įmonę, procesas gali priklausyti nuo to, ar kiekvienoje programoje teisingai atliktas kontrolinis sąrašas.

Microsoft vienkartinis prisijungimas suteikia organizacijoms dar vieną pasirinkimą. Sujungus Odoo su Microsoft Entra ID, naudotojai gali autentifikuotis per savo Microsoft paskyrą, o verslas gali taikyti nusistovėjusias Microsoft tapatybės kontrolės priemones Odoo prisijungimo procese.

Jūsų Microsoft tapatybės pagrindas gali būti jau sukurtas

Jei jūsų organizacija naudoja Microsoft 365, ji paprastai jau turi Microsoft Entra darbo aplinkos nuomininką. Microsoft aiškina, kad darbo aplinkos nuomininkas sukuriamas darbuotojams, vidinėms programoms ir organizacijos ištekliams, kai įmonė užsiregistruoja Microsoft debesijos paslaugai, tokiai kaip Microsoft 365. Tai daro Entra natūraliu tapatybės teikėju, kurį verta apsvarstyti Odoo, užuot diegus dar vieną atskirą paskyrų sistemą. Žr. Microsoft paaiškinimą apie workforce and external tenant configurations.

Odoo taip pat atpažįsta šį naudojimo atvejį. Oficiali Odoo 19 Microsoft Azure sign-in documentation aprašo, kaip Odoo naudotojai gali prisijungti su Microsoft paskyromis. Joje taip pat aiškiai nurodoma, kad integraciją reikia sukonfigūruoti abiejose pusėse.

Didžiausias privalumas yra tas, kad Microsoft tampa vieta, kur organizacija gali taikyti autentifikavimo politiką dar prieš prasidedant Odoo sesijai.

Pridėkite stipresnį autentifikavimą prie Odoo prisijungimo kelio

Microsoft Entra daugiafaktorinis autentifikavimas gali reikalauti dviejų ar daugiau patvirtinimo būdų. Šie veiksniai gali būti tai, ką naudotojas žino, tai, ką jis turi, arba tai, kas jis yra. Microsoft aprašo, kaip šis procesas vyksta kaip Entra prisijungimo dalis, savo MFA overview.

Kai Odoo perduoda prisijungimą Entra, organizacija gali reikalauti patvirtinto MFA metodo. Ji taip pat gali nukreipti pasirinktus naudotojus į apsaugos nuo sukčiavimo metodus, tokius kaip passkeys, FIDO2 saugos raktai, Windows Hello for Business arba sertifikatais pagrįstas autentifikavimas. Microsoft šiuos metodus rekomenduoja savo authentication guidance.

Šis skirtumas svarbus. Įprastas MFA paprastai yra stipresnis nei vien tik slaptažodžiu paremtas prisijungimas, tačiau ne kiekvienas MFA metodas yra atsparus sukčiavimui. NIST nurodo, kad slaptažodžiai nėra atsparūs sukčiavimui, o rankiniu būdu įvedami vienkartiniai kodai taip pat nėra atsparūs sukčiavimui, nes juos gali perimti užpuolikas. NIST WebAuthn, naudojamą su FIDO2 autentifikatoriais, įvardija kaip atsparumo sukčiavimui pavyzdį dėl susiejimo su domenu. Daugiau informacijos rasite NIST SP 800-63B-4.

SSO integracija suteikia verslui kelią naudoti šias Entra galimybes Odoo. Tačiau verslas vis tiek turi įjungti ir taikyti tinkamas politikos nuostatas.

Priimkite prieigos sprendimus turėdami daugiau konteksto

Microsoft Entra Conditional Access gali vertinti signalus, tokius kaip naudotojas, grupė, programa, vieta, įrenginio būsena ir prisijungimo rizika. Tada jis gali blokuoti prieigą arba reikalauti kontrolės priemonių, įskaitant MFA, tam tikrą autentifikavimo stiprumą arba atitinkantį reikalavimus įrenginį. Microsoft Conditional Access vadina savo Zero Trust politikos varikliu ir dokumentuoja prieinamus signalus bei sprendimus Conditional Access overview.

Odoo diegime tai gali padėti taikyti tokias politikos nuostatas kaip:

  • Reikalauti MFA Odoo administratoriams ir finansų naudotojams.
  • Reikalauti apsaugai nuo sukčiavimo atsparaus autentifikavimo stiprumo privilegijuotoms rolėms.
  • Blokuoti Odoo prisijungimą iš vietovių, kurių verslas neteikia paslaugų.
  • Reikalauti atitinkančio reikalavimus arba valdomo įrenginio jautriai vidinei prieigai.
  • Taikyti griežtesnę politiką išoriniams arba didesnės rizikos prisijungimams.

Tai yra pavyzdžiai, o ne visuotiniai nustatymai. Politika, tinkama vidinei finansų komandai, gali netikti klientų portalui. Prieš pasirinkdami kontrolės priemones, perskaitykite how Conditional Access strengthens Odoo sign-in.

Conditional Access taip pat turi licencijavimo reikalavimų. Conditional Access reikalingas Microsoft Entra ID P1, o rizika pagrįstoms politikoms reikia P2. Microsoft 365 Business Premium apima Conditional Access galimybes. Licencijavimą ir dabartinį funkcijų prieinamumą reikėtų patikrinti pagal Microsoft's official documentation.

Sujunkite tapatybę ir Odoo prieigą labiau tarpusavyje

Autentifikavimas atsako į klausimą, kas yra naudotojas. Odoo autorizacija vis dar nustato, ką tas naudotojas gali daryti.

Gerai suprojektuota integracija gali susieti patvirtintą Microsoft tapatybę su esama Odoo paskyra, sukurti patvirtintą paskyrą pirmo prisijungimo metu ir susieti pasirinktas Entra grupes arba programų roles su Odoo prieigos grupėmis. Tai gali sumažinti dubliuojamą administravimą ir palengvinti prieigos sprendimų peržiūrą.

Svarbu išlaikyti ribą tarp tapatybės ir autorizacijos. Pašalinus žmogų iš Entra grupės, pagal dokumentuotą integracijos sinchronizavimo elgseną tai turėtų paveikti Odoo susiejimą, tačiau nebūtinai iš karto nutrauks esamą Odoo sesiją. Jei prieiga sinchronizuojama prisijungimo metu, pokytis įsigalios, kai naudotojas prisijungs iš naujo, nebent įsikiš kita sesijos kontrolė.

El. pašto atitikimas taip pat reikalauja atsargumo. Microsoft įspėja, kad el. pašto adresai ir user principal names gali keistis arba būti pakartotinai naudojami. Jo ID token claims guidance rekomenduoja nekintamus identifikatorius, tokius kaip sub arba oid, su nuomininko kontekstu, jei reikia, patvariai tapatybei. El. paštas gali būti naudingas kontroliuojant pirmą susiejimą, tačiau jis neturėtų būti nuolatinis tapatybės raktas.

Jei norite gilesnio prieigos dizaino, skaitykite centralising Odoo access with Entra groups and app roles.

Ko Microsoft SSO nepakeičia

Microsoft SSO nepakeičia Odoo atnaujinimų, mažiausių teisių principu paremtų rolų, įrašų taisyklių, saugaus talpinimo, atsarginių kopijų, stebėsenos, sesijų kontrolės ar reagavimo į incidentus. Oficiali Odoo dokumentacija taip pat įspėja Odoo.com talpinamas duomenų bazes nenaudoti jos dokumentuoto OAuth srauto duomenų bazės savininkui arba administratoriui, nes gali būti paveiktas portalo valdymas. Prieš diegdami patvirtinkite savininko ir avarinio administravimo procedūras.

Saugesnis būdas įdiegti Microsoft prisijungimą

Pradėkite nuo mažos testavimo grupės. Patvirtinkite „Microsoft“ atradimo metaduomenis ir pasirašymo raktus, patikrinkite grįžtamojo ryšio URL, išbandykite paskyrų atitikimą ir peržiūrėkite naujų bei neįgaliotų naudotojų rezultatus. Pasilikite avarinį administravimo kelią, kol srautas bus patikrintas nuo pradžios iki pabaigos.

Tada dokumentuokite „Odoo“ taikomas taisykles, jiems reikalingas „Entra“ licencijas, kaip grupių ar vaidmenų pakeitimai pasiekia „Odoo“, ir kaip palaikymas reaguos, jei „Microsoft“ prisijungimas bus nepasiekiamas. Jei prieigą turi turėti klientai ir partneriai, apsvarstykite atskirą klientų tapatybės sprendimą, o ne traktuokite juos kaip darbuotojus. Mūsų gidas apie Microsoft Entra External ID for Odoo customers and partners paaiškina šį skirtumą.

Pateikite valdomą „Microsoft“ SSO į „Odoo 19

Mūsų Microsoft Entra SSO for Odoo module suteikia valdomą ryšį su „Odoo 19“, įskaitant darbuotojus ir išorines auditorijas, kontroliuojamą pirmą prisijungimą, grupių ir programos vaidmenų susiejimą, prisijungimo testavimą ir tik „Microsoft“ interaktyvų prisijungimą po patvirtinimo. Jis naudoja OpenID Connect autorizacijos kodo srautą su PKCE.

Modulis nepasirenka jūsų saugumo politikos. Jūsų organizacija lieka atsakinga už „Entra“ konfigūraciją, „Odoo“ prieigos dizainą ir diegimą.