Jednotné přihlášení odpovídá na ověřovací otázku: ověřil Microsoft tohoto uživatele podle zásad organizace? Neodpovídá na každou autorizační otázku v rámci Odoo.

Ověřený uživatel může potřebovat přístup k prodeji, ale ne k účetnictví, k projektům, ale ne k mzdám, nebo k zákaznickému portálu, ale ne k internímu rozhraní. Tyto rozhodnutí zůstávají odpovědností Odoo. Skupiny Microsoft Entra a aplikační role mohou poskytnout důvěryhodné vstupy, aby byla konzistentnější.

Skupiny a aplikační role slouží k různým účelům

Skupiny Microsoft Entra patří k tenantu. Mohou reprezentovat oddělení, pracovní funkce, projekty nebo bezpečnostní hranice. Aplikační role patří ke konkrétní registraci aplikace a popisují role, které jsou pro tuto aplikaci smysluplné.

Dokumentace Microsoftuk aplikačním rolím uvádí, že aplikační role lze přiřadit uživatelům nebo skupinám. Když se přiřazený uživatel přihlásí, Entra může do claimu roles zahrnout udělené role. Microsoft také uvádí, že aplikační role a skupiny se vzájemně nevylučují.

To dává návrhu přístupu v Odoo dva hlavní vzory:

  • Mapujte stabilní Object ID bezpečnostních skupin Entra přímo na vybrané skupiny Odoo.
  • Definujte v aplikaci Entra aplikační role zaměřené na Odoo, přiřaďte k těmto rolím uživatele nebo skupiny a namapujte výsledné hodnoty rolí na skupiny Odoo.

Přímé mapování funguje dobře s řízenými bezpečnostními skupinami. Aplikační role mohou poskytnout čistší aplikační hranici, protože jejich záměr je svázán s registrací aplikace a nezávisí na názvech specifických pro tenant.

Začněte skutečným modelem přístupu v Odoo

Nezačínejte tím, že do Odoo zkopírujete každou skupinu Microsoftu. Začněte oprávněními Odoo, která podnik skutečně potřebuje.

Seznamte skupiny Odoo, které udělují podstatné možnosti. U každé z nich zdokumentujte:

  • Obchodní účel přístupu.
  • Osobu odpovědnou za jeho schválení.
  • Skupinu Entra nebo aplikační roli, která schválení představuje.
  • Jak rychle by se změna měla projevit v Odoo a co se stane s aktivní relací po odebrání.

Používejte princip nejmenších oprávnění. Široká skupina oddělení může být praktická, ale může udělit více přístupu do Odoo, než každý člen potřebuje. Menší bezpečnostní skupina nebo aplikační role specifická pro Odoo se často lépe audituje.

Berete vazbu identity jako bezpečnostní kontrolu

Mnoho systémů nejprve porovnává existující účet pomocí e-mailové adresy. To je pohodlné, zejména když Odoo i Microsoft používají stejný firemní e-mail. Není to ale trvalý identifikátor identity.

Microsoft ve svéreferenční příručce k ID token claims upozorňuje, že e-mailové adresy, telefonní čísla a uživatelské principal names se mohou měnit a mohou být znovu použity. Microsoft pro spolehlivou identifikaci doporučuje neměnné claims, jako jsou sub nebo oid, s tid tam, kde je vyžadován kontext tenantu.

Bezpečnější je tento postup:

  1. Připusťte pouze očekávaný tenant a schválené audience.
  2. Použijte e-mail pro řízené první spárování, kde je to vhodné.
  3. Odmítněte nejednoznačné nebo duplicitní shody.
  4. Po propojení uložte neměnné identifikátory Microsoft identity a tenantu.
  5. Pro budoucí přihlášení používejte tyto neměnné hodnoty.

U přístupu mezi více tenanty je kontext tenantu zásadní. Stejná osoba může mít v různých tenantech různé object identifiers a přístup z jednoho tenantu by neměl tiše dědit oprávnění spojená s jiným.

Pochopte případ přesahu group claimů

Group claims jsou praktické, ale nejsou neomezené. Microsoft uvádí limit 200 Object ID skupin v JWT. Když členství uživatele tento limit překročí, Entra vynechá běžný seznam skupin a vrátí indikátor přesahu, který aplikaci nasměruje na dotaz do Microsoft Graph. Vizpokyny k přesahu skupin.

To je důležité, pokud integrace slibuje mapování skupin bez zvýšených oprávnění Microsoft Graph API. Uživatel s rozsáhlým členstvím ve skupinách nemusí obdržet očekávanou sadu group claimů.

Než se spolehnete na přímé mapování skupin, ověřte, jak se přesah řeší. Možnosti zahrnují menší aplikací specifické skupiny, aplikační role, filtrování claimů nebo vyhledávání přes Graph s consentem s nejmenšími oprávněními.

Synchronizace při přihlášení není průběžné zřizování

SSO modul může při přihlášení uživatele porovnat aktuální claims Entra s nakonfigurovanými mapováními Odoo. To je užitečné, protože přístup lze sladit během běžné autentizační události.

Není to totéž jako průběžné zřizování. Pokud je zaměstnanec odebrán ze skupiny Entra, zatímco je relace Odoo aktivní, tato relace může pokračovat až do odhlášení, vypršení platnosti nebo uplatnění jiného kontrolního mechanismu pro odvolání. Pokud bývalý zaměstnanec už nikdy znovu nepřihlásí, proces synchronizace při přihlášení sám o sobě účet Odoo nearchivuje.

Microsoft Entra ID Governance nabízí Lifecycle Workflows pro procesy joiner, mover a leaver, včetně deaktivace účtů a odebrání přístupových přiřazení. Viz dokumentace Microsoftu kLifecycle Workflows. Tyto možnosti vyžadují licenci Microsoft Entra ID Governance nebo Microsoft Entra Suite.

Automatizace životního cyklu může zlepšit stav zdrojové identity, ale stále neaktualizuje Odoo, pokud změnu nespotřebuje integrace. Váš offboarding postup by měl výslovně pokrývat odvolání relace Odoo a stav účtu.

Vytvořte auditovatelný model mapování

Udržujte počet mapování srozumitelný. Pro každou skupinu nebo roli používejte stabilní identifikátor a lidsky čitelný popis. Zaznamenejte, proč související přístup v Odoo existuje, kdo jej schválil a kdy byl naposledy zkontrolován.

Otestujte alespoň tyto případy:

  • Existující uživatel s jedním očekávaným mapováním.
  • Uživatel bez schváleného mapování nebo s nepovoleným tenantem.
  • Nový uživatel připuštěný pro první přihlášení.
  • Uživatel odebraný z namapované skupiny nebo s mnoha členstvími ve skupinách.
  • Přejmenovaný uživatel, jehož neměnná identita se nezměnila.
  • Zakázaný účet Microsoft s existující relací v Odoo.

Události přihlášení by měly administrátorům pomoci diagnostikovat výsledky nároků a mapování, aniž by odhalovaly tokeny, přihlašovací údaje nebo tajné informace. Záznamy by měly identifikovat připojení a výsledek, ale citlivé hodnoty by měly být redigovány.

Kombinujte mapování s politikou ověřování

Mapování skupin a rolí řídí autorizaci v Odoo. Podmíněný přístup Microsoft Entra řídí, zda Microsoft dokončí ověření za aktuálních podmínek. Tyto dvě vrstvy se doplňují.

Například role aplikace Entra může být mapována na finanční skupinu Odoo, zatímco Podmíněný přístup vyžaduje pro uživatele přiřazené k této roli autentizační sílu odolnou vůči phishingu. Přečtěte si jak Microsoft Entra Conditional Access posiluje přihlášení do Odoo pro část týkající se zásad ověřování.

U zákazníků a partnerů nepoužívejte automaticky znovu mapování zaměstnanců. Samostatné publikum a návrh orientovaný na portál mohou být bezpečnější. Viz Microsoft Entra External ID for Odoo customers and partners.

Mapujte schválený přístup Microsoft do Odoo 19

Náš Microsoft Entra SSO for Odoo module podporuje mapování nakonfigurovaných Object ID bezpečnostních skupin Entra nebo rolí aplikací na vybrané přístupové skupiny Odoo. Při přihlášení může tato mapování synchronizovat, propojit řízený existující účet a vytvářet schválené pracovní nebo portálové uživatele podle typu připojení.

Modul nenahrazuje správu přístupu, odvolání relací ani zdokumentovanou strategii pro případ překročení kapacity. Před povolením mapování zkontrolujte rozsah skupin, požadavky na vazbu identity a model oprávnění Odoo. Pokud jsou tyto základy jasné, modul poskytuje řízený způsob, jak je propojit.