Az Odoo portálok hozzáférést adnak az ügyfeleknek és partnereknek a releváns dokumentumokhoz, tranzakciókhoz és szolgáltatásokhoz. Ez felvet egy identitás-tervezési kérdést: meg kell-e osztaniuk a külső felhasználóknak az alkalmazotti címtárat és hozzáférési modellt?
Néha egy üzleti vendégfiók a munkaerőcélú bérlőben megfelelő. Nagyobb léptékben, vagy amikor márkázott ügyfél-bejelentkezésre és önkiszolgáló regisztrációra van szükség, a Microsoft Entra External ID külön ügyfélidentitás- és hozzáférés-kezelési modellt biztosít.
Ennek a modellnek az Odoohoz való kapcsolása tisztább határt teremthet a belső felhasználók és a portálfelhasználók között. A határhoz azonban továbbra is szükség van kifejezett beléptetésre, fióklétrehozásra és Odoo-engedélyezési szabályokra.
A munkaerőcélú és a külső bérlők eltérő közönségre készültek
A Microsoft a munkaerőcélú bérlőt olyan környezetként definiálja, amely az alkalmazottak, a belső üzleti alkalmazások és a szervezeti erőforrások számára készült. Meghívott üzleti partnereket és vendégeket is tartalmazhat. A külső bérlő egy külön konfiguráció a fogyasztóknak és üzleti ügyfeleknek kínált alkalmazásokhoz. A Microsoft a különbséget a bérlőkonfigurációs útmutatóban ismerteti.
A külső bérlő saját ügyfélcímtárral és alkalmazásregisztrációkkal rendelkezik. Az External ID önkiszolgáló regisztrációt, bejelentkezést, jelszó-visszaállítást, fiókkezelést és identitásszolgáltató-federációt ad hozzá. Az External ID áttekintése ismerteti ezt a dedikált modellt.
Ez az elkülönítés segíthet egy szervezetnek elkerülni, hogy az ügyfelet alkalmazottként kezelje pusztán azért, mert mindkettőnek hozzáférésre van szüksége egy Odoo szolgáltatáshoz.
Válassza ki a közönséget a bejelentkezés konfigurálása előtt
Legalább három különálló Odoo-közönséget érdemes megfontolni:
Alkalmazottak és belső felhasználók
Ezek a felhasználók általában a szervezet munkaerőcélú bérlőjébe tartoznak. Ha be vannak engedve az Odooba, általában belső Odoo-felhasználói fiókra van szükségük gondosan leképezett hozzáférési csoportokkal.
Jóváhagyott partner szervezetekből érkező emberek
Egyes vállalkozások olyan felhasználókat szeretnének, akik egy meghatározott ügyfél- vagy partner Entra bérlőlistáról érkeznek. Egy többbérlős munkaerőcélú kapcsolat pontos bérlő-engedélyezési listával megfelelő lehet, ha minden szervezet ismert, és a hozzáférés szerződés szerint jóváhagyott.
A bérlő-ellenőrzés kritikus. Az e-mail domain egyezése önmagában nem elég, mert a domainek és e-mail címek változhatnak. A kapcsolat kialakítása szerint ellenőrizze a token bérlőjét, valamint a nem változó subject vagy object azonosítókat.
Ügyfelek és külső felhasználók
Ügyfélfelületeknél az External ID bérlő külön címtárat és bejelentkezési élményt biztosíthat. Az ehhez a közönséghez létrehozott Odoo-fiókoknak általában portálfelhasználóknak kell lenniük, nem belső felhasználóknak.
Ezeket a modelleket külön kapcsolatokként kell konfigurálni, ha a beléptetési és Odoo-fiókszabályaik eltérnek. Egyetlen, átfogó kapcsolat nehezebben áttekinthető és könnyebben rosszul konfigurálható.
Az External ID támogatja az ügyfél bejelentkezési folyamatát
Az External ID felhasználói folyamatok meghatározzák az ügyfélhitelesítési módszereket és a regisztráció során gyűjtött információkat. Egy folyamat a regisztrált alkalmazásokhoz kapcsolódik a regisztráció és a bejelentkezés aktiválásához. A Microsoft ezt a alkalmazás hozzáadásával egy External ID felhasználói folyamathoz dokumentálja.
Az External ID támogatja a helyi fiókokat és az identitásszolgáltatókkal, köztük a Microsoft Entra ID-val és egyéni OpenID Connect szolgáltatókkal való federációt. A regisztráció során beépített és egyéni attribútumok is gyűjthetők, ahogy azt a Microsoft ügyfélattribútumokra vonatkozó útmutatója ismerteti.
Csak olyan információkat gyűjtsön, amelyekre az Odoonak valóban szüksége van, és minden attribútumhoz dokumentálja a célt, a megőrzési időt és az adatvédelmi kezelést.
Az alapértelmezett engedélyek segítenek megőrizni az elkülönítést
A Microsoft szerint a külső bérlő felhasználói korlátozott alapértelmezett engedélyekkel indulnak. Általában elérhetik az alkalmazásokat és kezelhetik saját profiljukat, de nem kapnak széles körű címtáradminisztrátori jogokat. Lásd: alapértelmezett engedélyek külső bérlőkben.
Ez a címtárhatár nem konfigurálja automatikusan az Odoo portálengedélyeket. Az Odoo továbbra is a saját hozzáférési jogai és rekordszabályai révén szabályozza, hogy egy portálfelhasználó mely rekordokat láthatja. Tesztelje a portálélményt reprezentatív ügyfélrekordokkal és egynél több céggel vagy fiókkal, hogy az adatok megfelelően elkülönüljenek.
Ne emeljen újonnan létrehozott külső felhasználót belső Odoo-felhasználóvá, hacsak nincs erre külön, jóváhagyott üzleti folyamat.
Használjon modern, ellenőrzött OpenID Connect folyamatot
A Microsoft támogatja az OAuth 2.0 authorization code flow-t Proof Key for Code Exchange-szel és az OpenID Connectet szerveroldali webalkalmazásokhoz. Az authorization code flow dokumentációja leírja ezt a támogatott kombinációt.
Az OIDC kiterjeszti az OAuth 2.0-t hitelesítésre. A Microsoft közzéteszi a discovery metaadatokat, az végpontadatokat és a nyilvános aláírási kulcsokat. Azt is javasolja, hogy ellenőrizze a visszaadott tokent, és a replay kockázat csökkentése érdekében vizsgálja meg a noncet. Lásd: OpenID Connect a Microsoft identity platformon.
Egy biztonságos integrációnak ellenőriznie kell a várt kibocsátót, célközönséget, aláírást, bérlői környezetet és nonce értéket. A PKCE nem helyettesíti a tokenellenőrzést, a pontos visszahívási konfigurációt, a TLS-t vagy az ügyfél titkos kulcsának védelmét.
Az alapvető bejelentkezés kérhet szabványos OIDC hatóköröket, például openid, profile és email. A Microsoft megjegyzi, hogy ezek a hatókörök a Microsoft Graphon vannak hosztolva, és azt javasolja, hogy csak az alkalmazás által szükséges engedélyeket kérje le. Lásd: Microsoft identity platform hatókörök. Pontos termékállítás tehát az, hogy "nincs magas jogosultságú Microsoft Graph API-engedély a standard bejelentkezéshez", nem pedig az a kategorikus állítás, hogy a Graph nem érintett.
Döntse el, hogyan érik el a külső felhasználók az Odoót
Az első bejelentkezés engedélyezése előtt határozza meg:
- A self-registration nyitott-e, vagy jóváhagyás szükséges.
- Mely bérlők vagy identitásszolgáltatók engedélyezettek.
- Kapcsolható-e meglévő Odoo portálfiók.
- Melyik változatlan Microsoft-azonosító kerül tárolásra az összekapcsolás után.
- Melyik Odoo cég- és partnerrekordhoz tartozik a felhasználó.
- Mely portálcsoportok és rekordszabályok érvényesek.
- Mi történik, amikor a hozzáférést visszavonják.
- Hogyan vonnak vissza egy aktív Odoo-munkamenetet.
Az automatikus fióklétrehozás csökkentheti az adminisztrációt, de csak akkor történjen meg, miután az identitás teljesíti a kapcsolat felvételi szabályait. A sikeres Microsoft-hitelesítés igazolja az elfogadott identitás feletti ellenőrzést. Önmagában nem bizonyítja, hogy az illetőnek látnia kell egy adott ügyfél Odoo-rekordjait.
Készüljön fel az ügyféltámogatásra és a helyreállításra
Előfordulhat, hogy a külső felhasználóknak nincs belső helpdeskük. Tegyen közzé támogatási útvonalat, és jelölje meg, ki kezeli az identitást. Tesztelje a jelszó-visszaállítás, a helyreállítás, a tenant eltávolítása és a módosított e-mail cím forgatókönyveit. A diagnosztikai események maradjanak hasznosak, de legyenek kitakarva.
Ha azonnali igénye az alkalmazotti hozzáférés, olvassa el miért érdemes Microsoft SSO-val védeni az Odoo-példányát. A belső jogosultságokhoz lásd ezt: az Odoo-hozzáférés központosítása Entra-csoportokkal és alkalmazásszerepekkel.
Kösse össze a külső közönségeket az Odoo 19-cel
A Microsoft Entra SSO for Odoo modulunk külön kapcsolatokat támogat az alkalmazottak, az jóváhagyott szervezetek és a Microsoft Entra External ID ügyfélközönségek számára. Az External ID kapcsolatok alapértelmezés szerint portálfelhasználókat hoznak létre, míg a munkaerőhöz tartozó kapcsolatok belső felhasználókat hoznak létre. Az irányított beállítás ellenőrzi a felderítési információkat és az aláíró kulcsokat, majd egy interaktív tesztet igényel, mielőtt a Microsoft bejelentkezés engedélyezve lenne.
A modul nem dönti el, kit szabad beléptetni, és azt sem, hogy mely ügyfélrekordokat láthatják. Ezek továbbra is üzleti és Odoo-hozzáférési döntések maradnak. Tekintse át a modult, ha ellenőrzött hidat szeretne a Microsoft ügyfélidentitás és egy Odoo 19 portál között, közönségspecifikus fiókkezeléssel, nem pedig egyetlen, egységes bejelentkezési folyamattal.