Odoo často uchováva informácie, ktoré sú dôležité pre celú organizáciu: záznamy o zákazníkoch, predajné aktivity, faktúry, údaje o zamestnancoch, projekty, skladové zásoby a prevádzkové dokumenty. Prístup k týmto informáciám si zaslúži rovnakú pozornosť ako prístup k e-mailu, súborom a iným kľúčovým podnikovým systémom.

Napriek tomu sa Odoo môže stať ostrovom identity. Zamestnanci môžu mať jedno heslo pre Microsoft 365 a iné pre Odoo. Správcovia môžu potrebovať riadiť prístup na viacerých miestach. Keď niekto zmení pozíciu alebo odíde z firmy, proces môže závisieť od toho, či sa kontrolný zoznam správne dokončí v každej aplikácii.

Microsoft jednotné prihlásenie prináša organizáciám ďalšiu možnosť. Prepojením Odoo s Microsoft Entra ID sa môžu používatelia overiť cez svoj účet Microsoft a firma môže na prihlasovanie do Odoo uplatniť svoje zavedené identity kontroly Microsoftu.

Vaše základy identity Microsoft už možno existujú

Ak vaša organizácia používa Microsoft 365, zvyčajne už má pracovný tenant Microsoft Entra. Microsoft vysvetľuje, že pracovný tenant sa vytvára pre zamestnancov, interné aplikácie a organizačné zdroje, keď sa firma zaregistruje do cloudovej služby Microsoft, napríklad Microsoft 365. Vďaka tomu je Entra prirodzený poskytovateľ identity, ktorý sa oplatí zvážiť pre Odoo, namiesto zavádzania ďalšieho samostatného systému účtov. Pozrite si vysvetlenie Microsoftu o konfiguráciách pracovného a externého tenanta.

Aj Odoo tento prípad použitia rozpoznáva. Oficiálna dokumentácia Odoo 19 k prihlasovaniu cez Microsoft Azure popisuje, ako sa používatelia Odoo môžu prihlasovať pomocou účtov Microsoft. Zároveň jasne uvádza, že konfigurácia je potrebná na oboch stranách integrácie.

Väčším prínosom je, že Microsoft sa stáva miestom, kde organizácia môže uplatniť autentifikačnú politiku ešte pred začiatkom relácie v Odoo.

Pridajte silnejšiu autentifikáciu do prihlásenia do Odoo

Viacfaktorová autentifikácia Microsoft Entra môže vyžadovať dve alebo viac foriem overenia. Tieto faktory môžu zahŕňať niečo, čo používateľ vie, niečo, čo vlastní, alebo niečo, čím je. Microsoft opisuje, ako sa táto výzva rieši ako súčasť procesu prihlásenia Entra, vo svojom prehľade MFA.

Keď Odoo deleguje prihlasovanie na Entra, organizácia môže vyžadovať schválenú metódu MFA. Môže tiež posúvať vybraných používateľov k metódam odolným voči phishingu, ako sú passkeys, bezpečnostné kľúče FIDO2, Windows Hello for Business alebo autentifikácia založená na certifikáte. Microsoft tieto metódy odporúča vo svojom sprievodcovi autentifikáciou.

Tento rozdiel je dôležitý. Tradičná MFA je vo všeobecnosti silnejšia než prístup založený iba na hesle, ale nie každá metóda MFA je odolná voči phishingu. NIST uvádza, že heslá nie sú odolné voči phishingu a že ručne zadávané jednorazové kódy tiež nie sú odolné voči phishingu, pretože ich útočník môže preposlať. NIST označuje WebAuthn, používaný autentifikátormi FIDO2, ako príklad odolnosti voči phishingu prostredníctvom viazania na doménu. Podrobnosti sú uvedené v NIST SP 800-63B-4.

Integrácia SSO dáva firme cestu, ako využiť tieto možnosti Entra pre Odoo. Firma však musí stále zapnúť a presadzovať vhodné politiky.

Robte rozhodnutia o prístupe s väčším kontextom

Microsoft Entra Conditional Access môže vyhodnocovať signály ako používateľ, skupina, aplikácia, poloha, stav zariadenia a riziko prihlásenia. Následne môže blokovať prístup alebo vyžadovať kontroly vrátane MFA, konkrétnej sily autentifikácie alebo kompatibilného zariadenia. Microsoft označuje Conditional Access ako svoj Zero Trust policy engine a dostupné signály a rozhodnutia dokumentuje v prehľade Conditional Access.

Pri nasadení Odoo to môže podporiť zásady ako:

  • Vyžadovanie MFA pre správcov Odoo a používateľov financií.
  • Vyžadovanie autentifikácie odolnej voči phishingu pre privilegované roly.
  • Blokovanie prihlasovania do Odoo z lokalít, ktoré firma neobsluhuje.
  • Vyžadovanie kompatibilného alebo spravovaného zariadenia pre citlivý interný prístup.
  • Uplatnenie prísnejšej politiky na externé alebo rizikovejšie prihlásenia.

Toto sú príklady, nie univerzálne nastavenia. Politika, ktorá je vhodná pre interný finančný tím, môže byť nevhodná pre zákaznícky portál. Pred výberom kontrol si prečítajte ako Conditional Access posilňuje prihlasovanie do Odoo.

Conditional Access má aj licenčné požiadavky. Microsoft Entra ID P1 je potrebný pre Conditional Access, zatiaľ čo politiky založené na riziku vyžadujú P2. Microsoft 365 Business Premium obsahuje možnosti Conditional Access. Licencie a aktuálnu dostupnosť funkcií je potrebné overiť podľa oficiálnej dokumentácie Microsoftu.

Zblížte identitu a prístup do Odoo

Autentifikácia odpovedá na otázku, kto je používateľ. Autorizácia v Odoo stále rozhoduje, čo môže tento používateľ robiť.

Dobre navrhnutá integrácia môže priradiť schválenú identitu Microsoft k existujúcemu účtu Odoo, vytvoriť schválený účet pri prvom prihlásení a namapovať vybrané skupiny Entra alebo roly aplikácie na prístupové skupiny Odoo. To môže znížiť duplicitnú administratívu a uľahčiť kontrolu rozhodnutí o prístupe.

Je dôležité zachovať hranicu medzi identitou a autorizáciou. Odstránenie niekoho zo skupiny Entra by malo ovplyvniť mapovanie do Odoo podľa zdokumentovaného správania synchronizácie integrácie, ale nemusí to okamžite ukončiť existujúcu reláciu Odoo. Ak sa prístup synchronizuje pri prihlásení, zmena sa prejaví pri ďalšom prihlásení používateľa, pokiaľ ju neovplyvní iný mechanizmus riadenia relácie.

Opatrnosť je potrebná aj pri zhodovaní e-mailov. Microsoft upozorňuje, že e-mailové adresy a používateľské hlavné mená sa môžu meniť alebo opakovane používať. Jeho usmernenie k ID token claims odporúča nemenné identifikátory, ako sú sub alebo oid, s kontextom tenanta, ak je potrebný, pre trvalú identitu. E-mail môže byť užitočný pri kontrolovanom prvom prepojení, ale nemal by byť trvalým kľúčom identity.

Pre hlbší návrh prístupu si prečítajte centralizáciu prístupu do Odoo pomocou skupín Entra a aplikačných rolí.

Čo Microsoft SSO nenahrádza

Microsoft SSO nenahrádza aktualizácie Odoo, roly s princípom minimálnych oprávnení, pravidlá záznamov, bezpečný hosting, zálohy, monitorovanie, riadenie relácií ani reakciu na incidenty. Oficiálna dokumentácia Odoo tiež varuje databázy hostované na Odoo.com pred používaním jeho zdokumentovaného OAuth toku pre vlastníka databázy alebo administrátora, pretože správa portálu môže byť ovplyvnená. Pred nasadením potvrďte vlastníka a núdzovú administráciu.

Bezpečnejší spôsob zavedenia Microsoft sign-in

Začnite s malou testovacou skupinou. Overte metadata zisťovania Microsoft a podpisové kľúče, potvrďte spätnú URL adresu, otestujte párovanie účtov a skontrolujte výsledky pre nových a neoprávnených používateľov. Zachovajte núdzovú administratívnu cestu, kým nebude tok otestovaný od začiatku do konca.

Potom zdokumentujte zásady, ktoré sa vzťahujú na Odoo, licencie Entra, ktoré vyžadujú, ako sa zmeny skupín alebo rolí dostanú do Odoo, a ako bude podpora reagovať, ak nebude dostupné prihlásenie cez Microsoft. Ak potrebujú prístup zákazníci a partneri, zvážte samostatný návrh identity pre zákazníkov namiesto toho, aby ste ich považovali za zamestnancov. Náš sprievodcaMicrosoft Entra External ID for Odoo customers and partners vysvetľuje tento rozdiel.

Priveďte riadené Microsoft SSO do Odoo 19

Náš Microsoft Entra SSO for Odoo module poskytuje riadené prepojenie pre Odoo 19, vrátane zamestnancov aj externých publík, kontrolovaného prvého prihlásenia, mapovania skupín a rolí aplikácie, testovania prihlásenia a interaktívneho prihlásenia iba cez Microsoft po overení. Používa autorizačný kódový tok OpenID Connect s PKCE.

Modul neurčuje vašu bezpečnostnú politiku. Vaša organizácia zostáva zodpovedná za konfiguráciu Entra, návrh prístupu do Odoo a nasadenie.