Odoo často uchovává informace, které mají význam pro celou organizaci: záznamy o zákaznících, prodejní aktivitu, faktury, údaje o zaměstnancích, projekty, skladové zásoby a provozní dokumenty. Přístup k těmto informacím si zaslouží stejnou pozornost jako přístup k e-mailu, souborům a dalším klíčovým firemním systémům.

Přesto se z Odoo může stát izolovaný ostrov identity. Zaměstnanci mohou mít jedno heslo pro Microsoft 365 a jiné pro Odoo. Správci mohou potřebovat řídit přístup na více místech. Když někdo změní roli nebo z firmy odejde, proces může záviset na tom, zda byl správně splněn kontrolní seznam v každé aplikaci.

Microsoft single sign-on dává organizacím další možnost. Propojením Odoo s Microsoft Entra ID se mohou uživatelé ověřovat přes svůj účet Microsoft a firma může na přihlašovací proces do Odoo uplatnit své zavedené identity politiky Microsoftu.

Vaše základna identity Microsoft už možná existuje

Pokud vaše organizace používá Microsoft 365, obvykle už má tenanta Microsoft Entra pro zaměstnance. Microsoft uvádí, že tenant pro pracovní účty se vytváří pro zaměstnance, interní aplikace a organizační zdroje, když se firma přihlásí k odběru cloudové služby Microsoft, například Microsoft 365. To dělá z Entra přirozeného poskytovatele identity, kterého je vhodné zvážit pro Odoo, místo zavádění dalšího samostatného systému účtů. Viz vysvětlení společnosti Microsoft o konfiguracích tenantů pro pracovní a externí účty.

Odoo tento scénář také podporuje. Oficiální dokumentace Odoo 19 pro přihlášení přes Microsoft Azure popisuje, jak se uživatelé Odoo mohou přihlašovat pomocí účtů Microsoft. Zároveň jasně uvádí, že konfigurace je nutná na obou stranách integrace.

Větším přínosem je, že Microsoft se stává místem, kde může organizace uplatnit ověřovací zásady ještě před zahájením relace Odoo.

Přidejte silnější ověřování do přihlašovací cesty Odoo

Vícefaktorové ověřování Microsoft Entra může vyžadovat dvě nebo více forem ověření. Mezi tyto faktory může patřit něco, co uživatel zná, něco, co vlastní, nebo něco, čím je. Microsoft popisuje, jak se tato výzva zpracovává v rámci přihlašovacího procesu Entra, ve svém přehledu MFA.

Když Odoo deleguje přihlášení na Entra, může organizace vyžadovat schválenou metodu MFA. Může také vybrané uživatele postupně převádět na odolné metody proti phishingu, například passkeys, bezpečnostní klíče FIDO2, Windows Hello for Business nebo ověřování na základě certifikátu. Microsoft tyto metody doporučuje ve svém průvodci ověřováním.

Tento rozdíl je důležitý. Běžné MFA je obecně silnější než přístup pouze s heslem, ale ne každá metoda MFA je odolná proti phishingu. NIST uvádí, že hesla nejsou odolná proti phishingu a že ručně zadávané jednorázové kódy také nejsou odolné proti phishingu, protože je může útočník přeposlat. NIST označuje WebAuthn, používaný autentizátory FIDO2, jako příklad odolnosti proti phishingu díky vazbě na doménu. Podrobnosti jsou uvedeny v NIST SP 800-63B-4.

Integrace SSO dává firmě cestu, jak tyto možnosti Entra využít pro Odoo. Firma však stále musí příslušné zásady zapnout a vynucovat.

Rozhodujte o přístupu s větším kontextem

Podmíněný přístup Microsoft Entra může vyhodnocovat signály, jako je uživatel, skupina, aplikace, poloha, stav zařízení a riziko přihlášení. Poté může přístup zablokovat nebo vyžadovat kontroly, včetně MFA, určité síly ověření nebo vyhovujícího zařízení. Microsoft nazývá Conditional Access svým zásadovým enginem Zero Trust a dostupné signály a rozhodnutí popisuje v přehledu Conditional Access.

Pro nasazení Odoo to může podpořit zásady, jako jsou:

  • Vyžadovat MFA pro administrátory Odoo a uživatele financí.
  • Vyžadovat odolnou sílu ověření proti phishingu pro privilegované role.
  • Blokovat přihlášení do Odoo z míst, které firma neobsluhuje.
  • Vyžadovat vyhovující nebo spravované zařízení pro citlivý interní přístup.
  • Uplatnit přísnější zásady pro externí nebo rizikovější přihlášení.

Jde o příklady, ne univerzální nastavení. Zásada, která je vhodná pro interní finanční tým, může být nevhodná pro zákaznický portál. Před výběrem kontrol si přečtěte jak Conditional Access posiluje přihlášení do Odoo.

Conditional Access má také licenční požadavky. Pro Conditional Access je vyžadován Microsoft Entra ID P1, zatímco zásady založené na riziku vyžadují P2. Microsoft 365 Business Premium zahrnuje funkce Conditional Access. Licencování a aktuální dostupnost funkcí je třeba ověřit podle oficiální dokumentace Microsoftu.

Přibližte identitu a přístup k Odoo

Ověření odpovídá na otázku, kdo je uživatel. Oprávnění v Odoo stále určuje, co může tento uživatel dělat.

Dobře navržená integrace může propojit schválenou identitu Microsoft s existujícím účtem Odoo, vytvořit schválený účet při prvním přihlášení a namapovat vybrané skupiny Entra nebo aplikační role na přístupové skupiny Odoo. To může snížit duplicitu správy a usnadnit kontrolu přístupových rozhodnutí.

Je důležité zachovat hranici mezi identitou a oprávněním. Odebrání osoby ze skupiny Entra by mělo ovlivnit mapování v Odoo podle zdokumentovaného chování synchronizace integrace, ale nemusí okamžitě ukončit stávající relaci Odoo. Pokud je přístup synchronizován při přihlášení, změna se projeví při dalším přihlášení uživatele, pokud nezasáhne jiné řízení relace.

Pozor je třeba věnovat i shodě e-mailů. Microsoft upozorňuje, že e-mailové adresy a user principal names se mohou měnit nebo znovu používat. Jeho průvodce claims v ID tokenu doporučuje pro trvalou identitu neměnné identifikátory, jako jsou sub nebo oid, případně kontext tenanta, kde je to potřeba. E-mail může být užitečný při řízeném prvním propojení, ale neměl by být trvalým klíčem identity.

Pro hlubší návrh přístupu si přečtěte centralizaci přístupu k Odoo pomocí skupin Entra a aplikačních rolí.

Co Microsoft SSO nenahrazuje

Microsoft SSO nenahrazuje aktualizace Odoo, role s principem nejmenších oprávnění, pravidla záznamů, bezpečný hosting, zálohy, monitoring, řízení relací ani reakci na incidenty. Oficiální dokumentace Odoo také varuje databáze hostované na Odoo.com před použitím jeho zdokumentovaného OAuth flow pro vlastníka nebo správce databáze, protože může být ovlivněna správa portálu. Před nasazením potvrďte vlastníka a nouzovou administraci.

Bezpečnější způsob zavedení přihlášení Microsoft

Začněte s malou testovací skupinou. Ověřte metadata zjišťování v Microsoftu a podpisové klíče, potvrďte URL callbacku, otestujte přiřazování účtů a zkontrolujte chování pro nové i neoprávněné uživatele. Zachovejte nouzovou administrátorskou cestu, dokud nebude celý tok otestován od začátku do konce.

Poté zdokumentujte zásady, které se vztahují na Odoo, licence Entra, které vyžadují, jak se změny skupin nebo rolí propisují do Odoo, a jak bude podpora reagovat, pokud nebude přihlášení přes Microsoft k dispozici. Pokud potřebují přístup zákazníci a partneři, zvažte samostatný návrh identity pro zákazníky místo toho, abyste je považovali za zaměstnance. Náš průvodceMicrosoft Entra External ID pro zákazníky a partnery Odoo toto rozlišení vysvětluje.

Zaveďte řízené Microsoft SSO do Odoo 19

Náš modul Microsoft Entra SSO pro Odoo poskytuje řízené propojení pro Odoo 19, včetně zaměstnanců i externích uživatelů, řízeného prvního přihlášení, mapování skupin a rolí aplikace, testování přihlášení a po ověření také interaktivního přihlášení pouze přes Microsoft. Používá autorizační kódový tok OpenID Connect s PKCE.

Modul neurčuje vaši bezpečnostní politiku. Vaše organizace zůstává odpovědná za konfiguraci Entra, návrh přístupu do Odoo a nasazení.