Jednotné prihlásenie odpovedá na otázku autentifikácie: overil Microsoft tohto používateľa podľa zásad organizácie? Neodpovedá na každú otázku autorizácie v rámci Odoo.

Autentifikovaný používateľ môže potrebovať prístup k predaju, ale nie k účtovníctvu, projektom, ale nie k mzdám, alebo k zákazníckemu portálu, ale nie k internému rozhraniu. Tieto rozhodnutia zostávajú na Odoo. Skupiny Microsoft Entra a aplikačné roly môžu poskytnúť dôveryhodné vstupy, aby boli konzistentnejšie.

Skupiny a aplikačné roly slúžia na rôzne účely

Skupiny Microsoft Entra patria do tenanta. Môžu predstavovať oddelenia, pracovné funkcie, projekty alebo bezpečnostné hranice. Aplikačné roly patria ku konkrétnej registrácii aplikácie a popisujú roly, ktoré sú pre danú aplikáciu zmysluplné.

Dokumentácia Microsoftu k aplikačným rolám uvádza, že aplikačné roly možno prideliť používateľom alebo skupinám. Keď sa prihlási pridelený používateľ, Entra môže zahrnúť udelené roly do claimu roles. Microsoft tiež uvádza, že aplikačné roly a skupiny sa navzájom nevylučujú.

To dáva návrhu prístupu k Odoo dva hlavné vzory:

  • Priraďte stabilné Object ID bezpečnostných skupín Entra priamo k vybraným skupinám Odoo.
  • Definujte v aplikácii Entra aplikačné roly zamerané na Odoo, priraďte k nim používateľov alebo skupiny a mapujte výsledné hodnoty rolí na skupiny Odoo.

Priame mapovanie funguje dobre so spravovanými bezpečnostnými skupinami. Aplikačné roly môžu poskytnúť čistejšiu hranicu aplikácie, pretože ich zámer je viazaný na registráciu aplikácie a nie na názvy špecifické pre tenant.

Začnite so skutočným modelom prístupu v Odoo

Nezačínajte kopírovaním každej skupiny Microsoft do Odoo. Začnite s oprávneniami Odoo, ktoré podnik skutočne potrebuje.

Vypíšte skupiny Odoo, ktoré udeľujú podstatné možnosti. Pre každú z nich zdokumentujte:

  • Obchodný účel prístupu.
  • Osobu zodpovednú za jeho schválenie.
  • Skupinu Entra alebo aplikačnú rolu, ktorá predstavuje schválenie.
  • Ako rýchlo sa má zmena prejaviť v Odoo a čo sa stane s aktívnou reláciou po odstránení.

Používajte princíp najmenších oprávnení. Široká skupina oddelenia môže byť pohodlná, ale môže udeliť viac prístupu k Odoo, než potrebuje každý člen. Menšia bezpečnostná skupina alebo aplikačná rola špecifická pre Odoo sa často ľahšie audituje.

Považujte viazanie identity za bezpečnostnú kontrolu

Mnohé systémy najprv párujú existujúci účet pomocou e-mailovej adresy. Je to pohodlné, najmä keď Odoo aj Microsoft používajú rovnaký firemný e-mail. Nie je to však trvalý identifikačný kľúč.

Microsoft upozorňuje vo svojej referencii na claimy ID tokenu , že e-mailové adresy, telefónne čísla a user principal names sa môžu meniť a môžu sa znovu použiť. Microsoft odporúča nemenné claimy, ako sú sub alebo oid, s tid, keď je potrebný kontext tenanta, pre spoľahlivú identifikáciu.

Bezpečnejší vzor je:

  1. Povoliť iba očakávaný tenant a schválené audience.
  2. Použiť e-mail na riadené počiatočné spárovanie, kde je to vhodné.
  3. Odmietnuť nejednoznačné alebo duplicitné zhody.
  4. Po prepojení uložiť nemennú identitu Microsoft a identifikátory tenanta.
  5. Na budúce prihlásenia používať tieto nemenné hodnoty.

Pri prístupe viacerých tenantov je kontext tenanta nevyhnutný. Tá istá osoba môže mať v rôznych tenantoch rôzne objektové identifikátory a prístup z jedného tenanta by nemal ticho dediť oprávnenia spojené s iným.

Pochopte prípad prekročenia limitu group claimov

Group claimy sú praktické, ale nie sú neobmedzené. Microsoft uvádza limit 200 Object ID skupín v JWT. Keď členstvo používateľa prekročí limit, Entra vynechá bežný zoznam skupín a vráti indikátor prekročenia, ktorý aplikáciu nasmeruje na dotaz do Microsoft Graph. Pozrite si usmernenie k groups overage.

To je dôležité, ak integrácia inzeruje mapovanie skupín bez zvýšených oprávnení Microsoft Graph API. Používateľ s rozsiahlym členstvom v skupinách nemusí dostať očakávanú sadu group claimov.

Pred spoliehaním sa na priame mapovanie skupín overte, ako sa rieši prekročenie limitu. Možnosti zahŕňajú menšie aplikácii špecifické skupiny, aplikačné roly, filtrovanie claimov alebo vyhľadanie cez Graph s udelením najmenších oprávnení.

Synchronizácia pri prihlásení nie je provisioning v reálnom čase

SSO modul môže pri prihlásení porovnať aktuálne claimy Entra s nakonfigurovanými mapovaniami Odoo. To je užitočné, pretože prístup sa dá zosúladiť počas bežnej autentifikačnej udalosti.

Nie je to to isté ako priebežné provisioning. Ak je zamestnanec odstránený zo skupiny Entra, zatiaľ čo je aktívna relácia Odoo, táto relácia môže pokračovať až do odhlásenia, vypršania alebo do použitia inej kontroly zrušenia prístupu. Ak sa bývalý zamestnanec už nikdy neprihlási, proces synchronizácie pri prihlásení sám o sebe nearchivuje účet Odoo.

Microsoft Entra ID Governance ponúka Lifecycle Workflows pre procesy joiner, mover a leaver, vrátane deaktivácie účtov a odstraňovania priradení prístupu. Pozrite si usmernenie k Lifecycle Workflows. Tieto funkcie vyžadujú licenciu Microsoft Entra ID Governance alebo Microsoft Entra Suite.

Automatizácia životného cyklu môže zlepšiť stav zdrojovej identity, ale stále neaktualizuje Odoo, pokiaľ zmenu nespracuje integrácia. Váš proces odchodu by mal výslovne pokrývať zrušenie relácie Odoo a stav účtu.

Vytvorte auditovateľný model mapovania

Udržujte počet mapovaní zrozumiteľný. Pre každú skupinu alebo rolu použite stabilný identifikátor a ľudsky čitateľný popis. Zaznamenajte, prečo pridelený prístup k Odoo existuje, kto ho schválil a kedy bol naposledy skontrolovaný.

Otestujte aspoň tieto prípady:

  • Existujúci používateľ s jedným očakávaným mapovaním.
  • Používateľ bez schváleného mapovania alebo s nepovoleným tenantom.
  • Nový používateľ povolený pre prvé prihlásenie.
  • Používateľ odstránený z mapovanej skupiny alebo s mnohými členstvami v skupinách.
  • Premenovaný používateľ, ktorého nemenná identita sa nezmenila.
  • Zakázaný účet Microsoft s existujúcou reláciou Odoo.

Prihlasovacie udalosti by mali správcom pomôcť diagnostikovať výsledky claimov a mapovania bez odhalenia tokenov, poverení alebo tajomstiev. Záznamy by mali identifikovať pripojenie a výsledok, ale citlivé hodnoty by mali byť začiernené.

Kombinujte mapovanie s autentifikačnou politikou

Mapovanie skupín a rolí riadi autorizáciu v Odoo. Podmienený prístup Microsoft Entra riadi, či Microsoft za aktuálnych podmienok dokončí autentifikáciu. Tieto dve vrstvy sa navzájom dopĺňajú.

Napríklad rola aplikácie v Entra môže byť namapovaná na finančnú skupinu v Odoo, zatiaľ čo Podmienený prístup vyžaduje pre používateľov priradených k tejto roli autentifikačnú silu odolnú voči phishingu. Prečítajte si ako Microsoft Entra Conditional Access posilňuje prihlasovanie do Odoo na strane autentifikačnej politiky.

Pre zákazníkov a partnerov automaticky opätovne nepoužívajte mapovania zamestnancov. Samostatné publikum a návrh zameraný na portál môžu byť bezpečnejšie. Pozrite si Microsoft Entra External ID pre zákazníkov a partnerov Odoo.

Namapujte schválený prístup Microsoft do Odoo 19

Náš Microsoft Entra SSO for Odoo module podporuje mapovanie nakonfigurovaných Object ID bezpečnostných skupín Entra alebo aplikačných rolí na vybrané prístupové skupiny Odoo. Tieto mapovania môže synchronizovať pri prihlásení, prepojiť riadený existujúci účet a vytvoriť schválených používateľov pre zamestnancov alebo portál podľa typu pripojenia.

Modul nenahrádza správu prístupov, zrušenie relácie ani zdokumentovanú stratégiu pre prekročenie limitu. Pred povolením mapovaní skontrolujte rozsah vašich skupín, požiadavky na viazanie identity a model oprávnení Odoo. Ak sú tieto základy jasné, modul poskytuje riadený spôsob, ako ich prepojiť.