Portály Odoo dávají zákazníkům a partnerům přístup k relevantním dokumentům, transakcím a službám. To vyvolává otázku návrhu identity: mají externí uživatelé sdílet adresář zaměstnanců a model přístupu?

Někdy je vhodný účet obchodního hosta v tenantovi pro pracovní sílu. Ve větším měřítku, nebo tam, kde je vyžadováno značkové přihlášení zákazníka a samoobslužná registrace, poskytuje Microsoft Entra External ID vyhrazený model správy identity a přístupu pro zákazníky.

Propojení tohoto modelu s Odoo může podpořit jasnější hranici mezi interními uživateli a uživateli portálu. Tato hranice však stále vyžaduje výslovné přijetí, vytvoření účtu a pravidla autorizace Odoo.

Tenanty pro pracovní sílu a externí tenanty jsou navrženy pro různé publikum

Microsoft definuje tenant pro pracovní sílu jako prostředí pro zaměstnance, interní podnikové aplikace a organizační prostředky. Může také obsahovat pozvané obchodní partnery a hosty. Externí tenant je samostatná konfigurace pro aplikace určené spotřebitelům a firemním zákazníkům. Microsoft tento rozdíl popisuje ve svém průvodci konfigurací tenantů.

Externí tenant obsahuje svůj vlastní adresář zákazníků a registrace aplikací. External ID přidává samoobslužnou registraci, přihlášení, resetování hesla, správu účtu a federaci s poskytovateli identit. Přehled External ID vysvětluje tento vyhrazený model.

Toto oddělení může pomoci organizaci vyhnout se tomu, aby zákazníka považovala za zaměstnance jen proto, že oba potřebují přístup ke službě Odoo.

Než nakonfigurujete přihlášení, zvolte cílové publikum

Je třeba zvážit alespoň tři odlišná publika Odoo:

Zaměstnanci a interní uživatelé

Tito uživatelé obvykle patří do tenantu organizace pro pracovní sílu. Pokud jsou připuštěni do Odoo, obecně potřebují interní uživatelské účty Odoo s pečlivě namapovanými přístupovými skupinami.

Lidé z schválených partnerských organizací

Některé firmy chtějí uživatele z definovaného seznamu zákaznických nebo partnerských tenantů Entra. Více-tenantové připojení pro pracovní sílu s přesným allow-listem tenantů může být vhodné, když je každá organizace známá a přístup je smluvně schválen.

Ověření tenanta je zásadní. Samotná shoda podle e-mailové domény nestačí, protože domény a e-mailové adresy se mohou měnit. Ověřte tenant tokenu a neměnné identifikátory subject nebo object podle návrhu připojení.

Zákazníci a externí uživatelé

Pro aplikace zaměřené na zákazníky může tenant External ID poskytnout samostatný adresář a přihlašovací prostředí. Účty Odoo vytvořené pro toto publikum by měly být obvykle portal uživatelé, nikoli interní uživatelé.

Tyto modely by měly být nakonfigurovány jako samostatná připojení, pokud se liší jejich pravidla přijetí a účtů Odoo. Jedno široké připojení je hůře srozumitelné a snáze se chybně nakonfiguruje.

External ID podporuje cestu přihlášení zákazníka

Toky uživatelů External ID definují metody ověřování zákazníků a informace shromažďované během registrace. Tok je přiřazen k registrovaným aplikacím, aby aktivoval registraci a přihlášení. Microsoft to dokumentuje v článku přidání aplikace do toku uživatelů External ID.

External ID může podporovat místní účty a federaci s poskytovateli identit včetně Microsoft Entra ID a vlastních poskytovatelů OpenID Connect. Vestavěné i vlastní atributy lze shromažďovat během registrace, jak popisuje Microsoft v části pokyny k atributům zákazníků.

Shromažďujte jen informace, které Odoo skutečně potřebuje, a zdokumentujte účel, dobu uchování a způsob zpracování soukromí pro každý atribut.

Výchozí oprávnění pomáhají zachovat oddělení

Microsoft uvádí, že uživatelé externího tenanta začínají s omezenými výchozími oprávněními. Obecně mohou přistupovat k aplikacím a spravovat svůj vlastní profil, ale nedostávají široká oprávnění pro správu adresáře. Viz výchozí oprávnění v externích tenantech.

Tato hranice adresáře sama o sobě nenakonfiguruje oprávnění portálu Odoo. Odoo stále řídí, které záznamy může portal uživatel vidět, prostřednictvím vlastních přístupových práv a pravidel záznamů. Otestujte prostředí portálu s reprezentativními zákaznickými záznamy a s více než jednou společností nebo účtem, abyste se ujistili, že jsou data správně izolována.

Nedávejte nově vytvořeného externího uživatele do role interního uživatele Odoo, pokud k tomu neexistuje samostatný schválený obchodní proces.

Použijte moderní, ověřený tok OpenID Connect

Microsoft podporuje autorizační kódový tok OAuth 2.0 s Proof Key for Code Exchange a OpenID Connect pro webové aplikace na straně serveru. Jeho dokumentace k autorizačnímu kódovému toku popisuje tuto podporovanou kombinaci.

OIDC rozšiřuje OAuth 2.0 pro ověřování. Microsoft publikuje metadata pro zjišťování, podrobnosti o koncových bodech a veřejné podpisové klíče. Doporučuje také ověřit vrácený token a zkontrolovat nonce, aby se snížilo riziko opakovaného přehrání. Viz OpenID Connect na platformě Microsoft identity platform.

Bezpečná integrace by měla ověřit očekávaného issuer, audience, podpis, kontext tenanta a nonce. PKCE nenahrazuje ověřování tokenu, přesnou konfiguraci callbacku, TLS ani ochranu klientského tajemství.

Základní přihlášení může požadovat standardní OIDC scope, jako jsou openid, profile a email. Microsoft uvádí, že tyto scope jsou hostovány na Microsoft Graph a doporučuje vyžadovat pouze oprávnění, která aplikace potřebuje. Viz scope platformy Microsoft identity platform. Přesné tvrzení o produktu je tedy "žádná vysoce privilegovaná oprávnění Microsoft Graph API pro standardní přihlášení", nikoli obecné tvrzení, že Graph není zapojen.

Rozhodněte, jak se externí uživatelé dostanou do Odoo

Před povolením prvního přihlášení definujte:

  • Zda je samoobslužná registrace otevřená, nebo je vyžadováno schválení.
  • Které tenanty nebo poskytovatele identit je možné připojit.
  • Zda lze propojit existující účet portálu Odoo.
  • Který neměnný identifikátor Microsoft je uložen po propojení.
  • Ke které společnosti Odoo a kterému záznamu partnera uživatel patří.
  • Které skupiny portálu a pravidla záznamů se uplatňují.
  • Co se stane, když je přístup odebrán.
  • Jak je zneplatněna aktivní relace Odoo.

Automatické vytváření účtů může snížit administrativu, ale mělo by proběhnout až poté, co identita splní přístupová pravidla daného propojení. Úspěšné ověření Microsoft potvrzuje kontrolu nad přijatou identitou. Neprokazuje samo o sobě, že by daná osoba měla vidět konkrétní záznamy Odoo určitého zákazníka.

Naplánujte podporu zákazníků a obnovení přístupu

Externí uživatelé nemusí mít interní helpdesk. Zveřejněte cestu podpory a určete, kdo spravuje identitu. Otestujte scénáře resetu hesla, obnovení přístupu, odebrání tenantu a změny e-mailu. Zachovejte diagnostické události užitečné, ale anonymizované.

Pokud je vaší okamžitou potřebou přístup zaměstnanců, přečtěte si proč byste měli chránit svou instanci Odoo pomocí Microsoft SSO. Pro interní oprávnění se podívejte na centralizaci přístupu do Odoo pomocí skupin Entra a rolí aplikace.

Propojte externí publika s Odoo 19

Náš Microsoft Entra SSO for Odoo module podporuje samostatná propojení pro zaměstnance, schválené organizace a zákaznická publika Microsoft Entra External ID. Připojení External ID ve výchozím nastavení vytvářejí uživatele portálu, zatímco pracovní propojení vytvářejí interní uživatele. Řízené nastavení ověřuje údaje pro zjištění a podepisovací klíče, poté před povolením přihlášení Microsoft vyžaduje interaktivní test.

Modul nerozhoduje o tom, kdo má být přijat, ani které záznamy zákazníků smí vidět. To zůstává obchodním rozhodnutím a rozhodnutím přístupu v Odoo. Prohlédněte si modul, pokud potřebujete řízený most mezi identitou zákazníka Microsoft a portálem Odoo 19, se zpracováním účtů podle publika namísto jediné neodlišené přihlašovací cesty.